| Autor |
Mensagem |
|
|
|
O nome deve ser "JSESSIONID" independente do fabricante. Logo a D está correta e a C, não.
|
 |
|
|
Olha, entre chamadas de métodos dentro do mesmo EJB você não tem mudança no tipo da transaction.
Se na sua primeira situação o método "alter()" foi chamado pelo client, o tipo de transação q irá vigorar será o REQUIRED, mesmo você fazendo a chamada ao "alter2()" posteriormete. Caso o serviço de outro EJB seja consumido (como no segundo caso), aí sim será verificado novamente o tipo da transaction e vc receberá o exception.
|
|
|
|
f2pro wrote:Pessoal.. já resolvi
com as pistas que me deram.. eu criei outro equals... dai comparando campo a campo, nao todos até agora...
segue o codigo a baixo...
alguem sabe de outro modo mais efetivo? caso tenha vários campos..
abraços...
Pra definir a igualdade, vc precisa sobrescrever tanto o método "hashcode()" quanto "equals()" da classe Object.
Geralmente se vc gerou o hashcode utilizando apenas o atributo "id" da classe, vc implementa o "equals" utilizando apenas esse mesmo atributo. Ou seja, utilize os mesmos atributos pra definir tanto o hashcode qt a igualdade pelo método "equals".
Eu colocaria o atributo "codigo_contato" como "int" e usaria uma implementaçaõ mais simples:
|
|
|
|
f2pro wrote:
brrodo wrote:
f2pro wrote:creio que sim cara...
ele foi gerado automaticamente com o hibernate ...
Me parece que o método "List.remove()" está usando o método "Object.equals()" para determinar a igualdade entre os objetos de Contato no momento da remoção, por isso o comportamento inesperado.
Você deve sobrescrever o método em Contato.
segue abaixo o meu equals...
Cheque se o atributo "codigo_contato" do "contato_selecionado" não está null.
Eu colocaria um breakpoint no método "equals" da classe Contato e debugaria para ver se o comportamento dele está adequado.
Esse problema não tem a ver com o JSF, tem a ver com o método "List.remove" q não consegue identificar qual objeto da lista é igual ao objeto "contato_selecionado" q é passado como parâmetro para removê-lo.
|
|
|
|
f2pro wrote:creio que sim cara...
ele foi gerado automaticamente com o hibernate ...
Me parece que o método "List.remove()" está usando o método "Object.equals()" para determinar a igualdade entre os objetos de Contato no momento da remoção, por isso o comportamento inesperado.
Você deve sobrescrever o método em Contato.
|
|
|
|
|
Sua classe Contato implementa o método "equals" corretamente?
|
|
|
|
programadora wrote:Erro de compilação porque? O código do diegohsi funciona perfeitamente após a mudança que sugeri.
Teríamos erro de compilação caso o problema fosse o modificador de acesso do método "run()" estar em "default" e não "public" e não o erro de que eu "não foi implementado runnable".
|
|
|
|
programadora wrote:O erro que ocorre, provavelmente decorre do fato de vc não implementar o método run() corretamente. O correto é:
você esqueceu do "public".
vlw
É, mais aí teríamos erro de compilação.
|
|
|
|
diegohsi wrote:Mesmo eu corrigindo o metodo run(), ainda ocorre o erro de que eu não implementei runnable. Segue a minha pergunta novamente, "eu posso executar uma thread sem criar um objeto runnable nesse caso, ou sem implementar Runnable, extendendo apenas Thread??
A classe Thread implementa Runnable. Isso responde sua pergunta?
|
|
|
|
Jaba wrote:E aew pessoal.
Bom, lá vai a dúvida: Digamos que eu tenha feito um Dispatcher normal, para uma JSP qualquer, mas depois desse Dispatcher, nesse mesmo servlet, eu tenha escrevido, por exemplo, uma chamada a um método qualquer.
A dúvida é: O Dispatcher chama a JSP antes dessa chamada do método na Servlet ou espera todo o conteúdo da Servlet terminar antes de fazer o despache?
Valew!
O Servlet é como uma classe qualquer. No caso que vc descreveu, o q conta é se vc usou o método "include" ou "forward" do requestDispatcher.
No caso do "include", o conteúdo HTML gerado pelo JSP usado no dispatcher é incluído no objeto "response" e o servlet de origem continua a sua execução abaixo dessa linha.
Se utilizar o "forward", tudo q estiver abaixo desse dispatcher no servlet não será executado.
Note tbm que uma excessão é lançada caso haja linhas de código sendo executadas depois de já ter sido chamado o método "flush" do objeto response.
|
|
|
|
Pessoal,
Vi que mudou um pouco o processo para adquirir o voucher pra essa certificação depois da entrada da Oracle.
No site diz que a compra deve ser feita diretamente pelo site da Prometric.
Alguém sabe me dizer se depois da compra pelo site da Prometric, se o procedimento vai ser o mesmo?! Por onde receberei a descrição do projeto, etc?
A única maneira de se adquirir o voucher pra essa certificação é pelo site da Prometric, ou algum voucher das antigas SCJP, SCWCD, e afins também pode ser comprado de terceiros para prestar à OCD?
|
|
|
|
TiagoTC wrote:As seguintes declarações para fazer um método ou uma classe genérica existem?
Nunca vi a palavra "implements" sendo usada neste contexto. Ela pode ser usada em algum caso?
Não. Para tanto é usado "extends" mesmo, afinal se "E" implementa "InterfaceAqui", ele É deste tipo.
|
|
|
|
|
Na prática, nenhuma.
|
|
|
|
Na verdade não é possível afirmar se o bloco de código citado é ou não é thread safe, portanto a alternativa A não é correta.
A classe StringBuffer só é thread safe em seus métodos internos. Isso não faz com que o código que a utiliza se torne thread safe.
|
|
|
|
Frango wrote:
fabiofalci wrote:Tenho 29 e tirei a SCEA com 27 
Pô que legal..
Quantos anos de experiência tinha quando tirou ela?
Você acha que com uns 2~3 anos de experiência e com SCJP, SCWCD e SCBCD dá pra tentar? (Falei das certificações apenas pra referir ao conhecimento que ganha ao estudar para elas.)
Tenho 22 anos, 4 de experiência e tenho a SCEA.
Digo seguramente que ter pelo menos a SCJP, SCWCD e SCBCD já te dá meio caminho andado pra essa certificação. Se possui a SCJWS também irá ajudar bastante.
Fazer a SCEA de primeira sem ter feito nehuma outra certificação antes, é ter o triplo de dor de cabeça que teria se tivesse mais experiência já com as outras certificações.
|
|
|
|