| Autor |
Mensagem |
|
|
|
As respostas para maioria das suas dúvidas estão aqui: http://rubylearning.com/satishtalim/tutorial.html.
|
 |
|
|
|
Acho que o XStream pode ajudar.
|
|
|
|
Luca wrote:Este papo só está acontecendo porque o Genesis induz o usuário a adotar esta arquitetura engrunvinhada, acoplada, pesada, enxuriçada, etc. e tal que para mim não faz sentido. Já comentei isto com o Michael e ele respondeu que esta não é a única arquitetura do Genesis e que só usa quem quer. Para mim seria melhor que o Genesis não admitisse esta arquitetura com EJBs/RMI/etc. no cliente.
Só uma observação quanto a isso: usamos o Genesis apenas para binding e outras pequenas coisas no cliente. Neste caso, não usamos o esquema de chamadas remotas do Genesis - tanto que implementamos algo diferente usando o Spring. Aliás, como falei na resposta anterior, já havia um outro projeto usando uma arquitetura parecida, por isso não podemos nem falar que o Genesis nos influenciou a usar RPC.
Nada que acrescente muito a discussão, mas gostaria de deixar claro esse ponto. 
|
|
|
|
Luca wrote:Se você for passar mensagens sem serializar classes, crie suas classes de separadas no cliente e no servidor de modo que as classe no cliente sejam as ideiais para apresentar e no servidor as ideais para persistir.
Perfeito. Nesse caso seriam dois sistemas completamente independentes, com classes independentes, trocando mensagens por algum protocolo específico - XML, CSV, JSON, etc. O responsável por manter o protocolo seria o servidor e, para acessar seus serviços, basta seguir o protocolo. Qualquer alteração na aplicação servidora, desde que não altere esse protocolo, não causa impacto algum no cliente.
Luca wrote:Se enviar serializado, crie métodos usando reflection que serialize/deserialize de forma genérica. Você terá que replicar no servidor as classes do cliente e pode ser que ainda tenha que usar outras classes para fazer a persistência e construir as respostas das consultas.
Agora, neste caso, mesmo não havendo RPC, depender das mesmas classes tanto no cliente quanto no servidor não acaba deixando o sistema tão acoplado quanto? O ponto é qualquer alteração nas classes do servidor afeta diretamente o cliente - não necessariamente nessa mesma ordem  . E acho que é exatamente isso que você sugeriu evitar, certo?
Ter as mesmas classes no cliente e servidor, apenas usando servlets e serialização via XML, etc, ao invés de um proxy fazendo as chamadas aos métodos remotos, ainda deixa os dois sistemas acoplados. A conclusão que chego é que o ideal seria usar a primeira alternativa, onde não há dependência entre o cliente e servidor.
Luca wrote:De acordo com o grau de conhecimentos da equipe, a solução adotada pelo Matheus pode ter preferência.
Na verdade, quando iniciamos esse projeto eu sugeri uma arquitetura REST. Mas como já havia um projeto feito em uma arquitetura muito semelhante, optamos por usá-la. Também acredito que não seja a melhor escolha, mas neste caso, fui voto vencido. 
|
|
|
|
Luca wrote:Este papo só está acontecendo porque o Genesis induz o usuário a adotar esta arquitetura engrunvinhada, acoplada, pesada, enxuriçada, etc. e tal que para mim não faz sentido. Já comentei isto com o Michael e ele respondeu que esta não é a única arquitetura do Genesis e que só usa quem quer. Para mim seria melhor que o Genesis não admitisse esta arquitetura com EJBs/RMI/etc. no cliente.
Olá Luca.
Só pra entender melhor: qual problema você vê no cliente usando RPC? Estou perguntando isso pra entender melhor mesmo, não estou defendendo o meu ponto de vista.
Por que o cliente usar HttpClient enviando e recebendo objetos serializados é melhor?
Usando RPC, no caso do Spring Remoting, você executa um método remoto, através de um proxy via http, que pode enviar e receber objetos serializados. Qual seria a diferença do HttpClient? O proxy no cliente?
Desculpe a quantidade de perguntas (ainda tinha outras), mas realmente quero entender melhor o seu ponto.
|
|
|
|
No projeto que trabalho atualmente usamos uma arquitetura parecida: cliente em Swing - também usamos Genesis; acessando uma aplicação web - usamos JPA/Hibernate.
A grande diferença fica no fato que não temos servlets no nosso projeto. Usamos o Spring, tanto no cliente quanto no servidor, e disponibilizamos serviços usando o Spring Remoting. Veja: http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-httpinvoker.
Dessa forma, a arquitetura fica bem parecida com o que seria usado com EJB 3. Seria algo como RMI/RPC via http.
No servidor temos o modelo com a lógica de negócio, os DAOs e os serviços - que recebem os DAOs por injeção de dependências. Os serviços apenas delegam as chamadas para o modelo e os DAOs.
Só pra ter uma idéia, vou colocar alguns trechos de código para ilustrar melhor como fazemos:
 No servidor:
No cliente:
Lembrando que os códigos são apenas de exemplo por isso não coloquei a implementação da interface.
Também não sei se é a melhor opção, mas tem funcionado bem para o nosso projeto.
[edit]
Esqueci de comentar: o Spring no servidor também nos dá outras vantagens como controle de transações declarativo e suporte para JMS.
[/edit]
|
|
|
|
Use um ListSelectionListener:
Segue um exemplo completo para você entender melhor:
Alguns links:
How to Use Tables
Listening for Selection Events in a JTable Component
|
|
|
|
Eu também tentei me registrar no site da Prometric e não consegui. Mandei um email para eles e a resposta foi exatamente essa que o Rafael informou.
Segue o email:
pro.globalcandidateservices at thomson.com wrote:Unfortunately due to higher than expected demand, SUN decided to close this exam yesterday.
If you have any additional questions about it please visit the following webpage at www.sun.com
Também vou tentar ligar no Senac pra ver se consigo marcar direto com eles.
[edit]
Tentei ligar no Senac, mas como o pessoal da Prometric tirou o exame da lista, nem assim dá mais. 
[/edit]
|
|
|
|
saga_fuel wrote:O problema galera é que eu tenho uma unica conexão statica para todo meu projeto...
Faça o seguinte:
Em uma situação dessas, quando o sistema travar (coisa que vai acontecer com bastante frequencia), é só reiniciar sua aplicação. Ou, se quiser que seu sistema funcione, faça o que já lhe falaram: use um pool de conexões!
Alias, esse negócio de ficar abrindo e fechando conexões na unha é complicado (pra não dizer algo pior). Estude a possibilidade de usar uma camada de abstração que faça o trabalho sujo para você.
|
|
|
|
Use o DefaultListModel.
Para remover todos os itens, use o método clear().
Leia: Adding Items to and Removing Items from a List
|
|
|
|
RafaelVS wrote:Continuo achando que eh impossivel acessasr os atributos privados... no maximo quando vc mapeia seus atributos usando JPA, vc consegue porque vc tb cria os get/set que sao public...
Pode acreditar: é possível!
Leia a documentação do Hibernate:
Hibernate Reference Documentation wrote:You can see that Hibernate can access public, private, and protected accessor methods, as well as (public, private, protected) fields directly.
Faça um teste do tipo:
E depois:
|
|
|
|
Não uso o GWT, mas acho que isso pode te ajudar:
http://hibernate4gwt.sourceforge.net/hibernate_gwt_type_issue.html
http://hibernate4gwt.sourceforge.net/index.html
|
|
|
|
Para usar o Hibernate com annotations você não precisa do Java EE 5. Se você já tem instalado o JDK >= 1.5 é só fazer o seguinte:
- No Netbeans, clique com o botão direito no seu projeto e em Properties (Propriedades);
- Na categoria Sources, mude o Source Level para 1.5;
Isso já resolve o seu problema.
Pesquise no google sobre o que é, pra que serve e quais são as features do Java EE 5.
Um bom começo é: http://java.sun.com/javaee/sdk/features.jsp
Aliás, olhando no site do Hibernate, você pode ver quais são os requisitos para usá-lo:
Hibernate Annotations wrote:Requirements: At a minimum, you need JDK 5.0 and Hibernate Core, but no application server or EJB 3.0 container. You can use Hibernate Core and Hibernate Annotations in any Java EE 5.0 or Java SE 5.0 environment.
|
|
|
|
Realmente, neste caso, o funcionamento é um pouco diferente do que expliquei.
Ai já entra um elemento extra: ordem de avaliação dos operandos.
Mas essa dúvida já foi bastante discutida, inclusive aqui mesmo no GUJ.
http://www.guj.com.br/posts/list/2853.java
http://www.guj.com.br/posts/list/30723.java
http://www.javafree.org/javabb/viewtopic.jbb?t=11245
http://www.javafree.org/javabb/viewtopic.jbb?t=10563
Esse tipo de dúvida é apenas coisas de certificação (se bem que não me lembro de ter visto isso quando fiz a minha).
Não vejo porque alguém utilizaria uma atribuição dessas num caso real.
|
|
|
|
fabioEM wrote:... pq em java
y=0;
y=y++;
...
As operações de pré e pós incremento funcionam da mesma forma para Java e C (e tantas outras linguagens).
Em java:
Imprime 0.
Em C:
Imprime 0 também.
Isso porque a operação de pós-incremento primeiro avalia o valor da variável e depois faz a atribuição (i = i + 1).
Já com a operação de pré-incremento:
Em java:
Imprime 1.
Em C:
Imprime 1 também.
Porque acontece o processo inverso, atribuição depois avaliação.
Veja a recomendação que coloquei no meu último post.
|
|
|
|
|
|