| Autor |
Mensagem |
|
|
cara, continuo na mesma.
Posso usar a classe que vc indicou (ReloadableResourceBundleMessageSource) pra carregar minhas constantes numa boa mas e depois que elas forem carregadas? Lembre que estou usando membros estáticos (isso pra poder identificar qq erro de digitação em tempo de compilação e não ter de procurar nada em cache - fica tudo em mémória).
Essa abordagem precisa ser usada com cautela - eu sei. Carregar muita coisa em memória em vez de só carregar qdo necessário é sempre perigoso. Tento balancear o uso desse artifício limitando-o a alguns casos bem específicos.
Vamos aos exemplos, acho que vai ficar mais fácil de me fazer entender:
ServiceConstants.properties
E o problema persiste: como recarregar as constantes definidas na classe ServiceConstants ?
Woody
|
 |
|
|
vou dar uma olhada e te digo.
valeu
|
|
|
|
Vc só vai ter de violar essas boas práticas pq teu código sob teste já não as segue. Pense bem: o objetivo dos testes é validar contratos dos trechos relevantes. RELEVANTES - não devo testar tudo, devo testar apenas as entradas e saídas que realmente importam.
Se tuas classes tem 99 % de métodos privados isso cheira mal - tem certeza de que vc está programando OO? Muito método privado acaba gerando baixo número de classes (o que em projetos grandes significam baixa coesão e alto acoplamente não é?).
Só um lembrete: não adianta tentar ser purista (ou acadêmico) - o dia a dia nos prova que sempre devemos buscar outras soluções, esse negócio de torcer o nariz toda vez que vc tem de escrever uma linha torta não leva a lugar nenhum.
Não sou nehum expert em testes.
Afinal de contas estamos todos aprendendo não é?
Woody
|
|
|
|
Estava a rever algumas classes que escrevi para um projeto ejb e me deparei com a seguinte situação:
Uso direto e reto bundles e constant object [hardcore java 2004] em meus componentes contudo ainda fico fulo da vida por ter de reiniciar as instâncias dos meus servers quando algum bundle é alterado (duvido que niguém aqui não tenha se deparado com o mesmo problema).
Enfim: preciso de uma forma de reinicializar essas "constantes" só que isso fica difícil com membros estáticos.
Pensei em descarregar as classes com as constantes mas vi que o buraco é mais embaixo (classloader).
Achei o seguinte na web:
http://blog.taragana.com/index.php/archive/how-to-unload-java-class/
http://portal.acm.org/citation.cfm?id=609750
Alguém aqui já fez algo semelhante?
Woody
|
|
|
|
whizlabs.
Tô procurando gente pra uma vaquinha, estas afins?
Woody
|
|
|
|
isso não é pegadinha não gente?
Na última frase da e eu entendi " ..., uma vez que todas superclasses possuem um construtor default" - meu inglês é fraco okay?
Se a tradução estiver correta essa opção não rola pois nem toda superclasse tem construtor default (óbviamente posso escrever uma classe sem construtor default, estendê-la numa outra qq e nessa última tentar executar super() - que não vai funcar).
Eu vou na B tb.
Woody
|
|
|
|
desculpem, falei m., autoboxing não cria array onde não tem.
Woody
|
|
|
|
acho que o código (da forma como vc apresentou - sem alteração) vai funcionar numa boa no java 5 por causa do autoboxing.
Alguém pode confirmar isso?
Woody
|
|
|
|
é, joguei no eclipse aqui (jdk 1.4.2_11) e deu erro na compilação mesmo.
tentaí:
output.format( "%d\n", new Object[]{ new Integer( location ) } ); // envia a posição ao servidor
não testei ok?
Woody
|
|
|
|
vê no mysql como é que vc faz pra configurar o conjunto de caracters que ele vai usar (codepage, alguma coisa assim).
Woody
|
|
|
|
oi javax, pra começar eu acho que já está bom mas vamos estender um pouco:
- normalmente não se misturam ejbs com views de qq tipo - aconselho que vc quebre em projetos distintos: lembre que a view vai usar o projeto ejb
- onde vc irá por as classes para uso geral? a famosa util? (essa acaba virando um ou dois jar - util-client.jar e util-ejb.jar só como sugestão faça isso num projeto separado pois no decorrer do tempo isso tende a crescer conforme sua experiência vai aumentando).
- o pacote negócios vai conter seus ejbs de serviço certo?
- a pasta modelo acredito que conterá os entitys - se vc tem entitys provavelmente vc vai precisar de VOs para transportar dados então será conveniente uma pasta para tal - tipo: transpote - isso irá se transformar em outro pacote que será compartilhado pelo projeto ejb;
recentemente eu usei:
projeto cliente (view/controlador)
com.gec.client
---util
projeto ejb (model)
com.gec
---transport
---jaas
------ejb
---util
---ejb
------services
------model
------util
espero que tenha ajudado.
Woody
|
|
|
|
pcalais, concordo plenamente.
Por questão de educação é sempre polido remover os excessos do currículo - quem não o faz corre o risco de passar por metido (humildade sempre faz bem e qdo se trata de procurar emprego vc precisa sempre procurar o equilíbrio entre o que vc sabe e o que realmente é necessário).
Imagina o seguinte: a muito tempo atrás, muito tempo mesmo, fui premiado no macdonald´s, e aí? acha que essa m (que teve certificação ok?) deve entrar no currículo?
Seguindo esse mesmo exemplo tenho uma penca de outras (agora na área ok?) mas que expiraram e nem morto eu quero mencionar no meu currículo (tipo: certificado ms vb, owa, etc)
Woody
|
|
|
|
ou o TPTP do eclipse - bem mais complicado mas muito mais completinho ...
Woody
PS: respondendo tua pergunta a vm não tem isso não.
|
|
|
|
renato3110 wrote:
agodinhost wrote:cara, esquece reflexão...
O framework de teste poderia abstrair isso...
Exatamente.
O objetivo da reflexão é descobrir detalhes do teu código em tempo de execução.
O objetivo do teste é certificar que os contratos do teu código estão ok.
Internamente o JUnit já usa reflexão ...
Woody
|
|
|
|
sem problema.
qdo escolher o tema manda uma mensagem - se puder te ajudar em mais algo ...
Woody
|
|
|
|