| Autor |
Mensagem |
|
|
Use o metodo init() do Servlet:
http://thejavatrainer.com/?src=the-init-method.htm
|
 |
|
|
O caminho mais rapido eh tentar diretamente o metodo Context.bind. Se vc estah em um ambiente estritamente gerenciado(como um container EJB do Websphere, por exemplo), vc terah q alterar configuracoes de container(se elas existirem) para tal codigo funcionar.
Vc pode tb tentar referenciar no java:comp/env via web.xml(resource-ref) um objeto jah definido pelo container, porem da ultima vez q fiquei sabendo, somente era possivel referenciar objetos gerenciados(ejb, filas jms, etc) ou tipos primitivos, nada de um objeto qualquer. Se isso mudou eu nao sei, ateh gostaria de ouvir a opniao de outro membro q (REALMENTE) soubesse. Se isso for padrao, eh o caminho a seguir sem duvida, preservando portabilidade. Porem, alguns containers jah suportam isso(Jetty), mesmo nao sendo padrao...
Mais uma coisa: provavelmente esse seu codigo nao serah portavel usando as dicas acima. Se portabilidade for importante para vc, sugiro uma implementacao do pattern Registry, sempre observando possiveis(mas pouco provaveis) questoes de classloading nessa solucao.
|
|
|
|
Crie um wrapper para esse pojo q implemente Externalizable, onde vc possui o controle da serializacao desse objeto e do target(classe em questao) q ele contem.
Sugiro q busque exemplos sobre o assunto.
|
|
|
|
|
Ok, mas qual a classe dessa List e quem gera ela? Se isso for oriundo de codigo de framework, talvez seja impossivel fazer isso sem patch, contando ainda q tal patch seja liberado por licenca
|
|
|
|
|
Stacktrace?
|
|
|
|
Application Server: Jetty. Performatico e sem memory leaks.
SO: Linux Centos ou OpenSolaris
|
|
|
|
Olah pessoal,
Jah fiz a primeira versao dessa prova e acredito ter ainda o material de estudo. Ela basicamente aborda o conhecimento de padroes(XML, XSD, WSDL, SOAP, etc) e aplicabilidade de APIs java(JAXP, SAAJ, JAXR, JAX-WS, etc). Se vc souber o proposito de cada padrao, aplicabilidade em java e como usar superficialmente cada API nesse *ecosistema*, jah garante a certificacao ao menos.
Enfim, acredito q focar nos objetivos da prova e estudar via Javaranch seja bem mais eficiente, pois existem varios *feras* em certificacao lah q podem nos dar dicas preciosas...
|
|
|
|
|
http://denistek.blogspot.com/2008/08/list-jndi-names.html
|
|
|
|
Sei q esse topico eh meio antigo, mesmo assim seguem meus .02 cents pois precisei disso ha pouco, e tive q correr atras...
Se sua classe foi compilada com os simbolos de debug, o .class possui internamente o q se chama de LocalVariableTable, acessivel somente(pelo menos por enquanto) por instrumentacao de codigo, via ASM, Javassist, etc...
Se vc precisar disso, olhe o utilitario LocalVariableTableParameterNameDiscoverer.getParameterNames do Spring. Cabe lembrar q eh necessario ler os javadocs dessa classe, pois existem dicas de otimizacao de uso dessa classe.
|
|
|
|
Procure por *Java deepClone ou deepCopy* no Google.
Uma das formas de fazer isso de modo simples e relativamente rapido eh via serializacao:
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(this);
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bais);
Object deepCopy = ois.readObject();
Porem, se for um objeto instrumentado, vc terah grandes dores de cabeça. Em minha empresa implementei um deepCopy especializado para hibernate, q tem como proposito remover a serie de instrumentacoes q o hibernate retorna em seus pojos.
Vc *deve* se preocupar com performance ao fazer esse tipo de operacao. Procure medir o tempo q esse procedimento leva.
|
|
|
|
class javax.mail.SendFailedException: 550 5.1.1 User unknown
Na verdade seu codigo estah certo. Essa mensagem de erro eh emitida pelo SMTP server, indicando provavelmente que o endereço de mail origem(from) utilizado nesse em sua mensagem nao eh desse servidor, e ao mesmo tempo seu servidor nao permite relay para dominios os quais ele nao eh destinatario.
|
|
|
|
Portanto não sei se é uma boa idéia fazer reflection em um SessionBean.
Ele nao estah fazendo reflection dentro de um SB, e sim em um cliente SB.
|
|
|
|
Tente substituir:
por:
|
|
|
|
vinidouradoh wrote:wandersonxs,
são poucas as pessoas que ainda utilizam o EJB 2.1, o EJB 3.0 elimina os XML's a serem configurados, sendo muito mais fácil dar manutenção. Mas no EJB você pode definir uma session como Stateless (perde a referência do objeto) ou Statefull(guarda a referência do Objeto). Dá um pesquisada nisso, se nao me engano, você pode definir isso no ejb-jar.xml com a TAG <session-type>Stateless</session-type>.
Espero ter ajudado.
vlw
Eu acho q EJB Stateful nao resolve, pois seu escopo eh semelhante a Web Session: per user.
O q ele precisa eh algo como ApplicationContext porem para EJB. Como EJB ainda nao eh tao flexivel quanto o uso de pojos, acho q um Singleton resolve o caso dele...
|
|
|
|
No seu caso, eu faria um Singleton com lazy-loading. Entao o estado desse singleton estaria disponivel para toda sua aplicacao EJB.
Nao faça um EJB acessar a camada web, pois isso fere o isolamento entre essas camadas proposto em J2EE.
|
|
|
|