| Autor |
Mensagem |
|
|
Acredito que a estratégia sera parecida como da IBM com o Websphere CE.
O Websphere CE, de nada tem haver com o IBM Webshepere Application Server. Todos sabem que na verdade o primeiro é simplesmente o Apache Geronimo com uma GUI de administração semelhante com a do segundo. Mas a IBM promete compatibilidade entre os dois produtos.
Penso que a Oracle deve com o tempo, colocar uma cara mais "Weblogic" no Glassfish e garantir alguns pontos de compatibilidades em seus deployment descriptors. Isso iria facilitar futuras migrações de uma versão para outra e assim construir uma porta de entrada para a familia Weblogic.
|
 |
|
|
rogelgarcia wrote:
O que foi criado no Next então. Tags com templates.
Ele faz isso de maneira diferente do que seria feito com facelet, tiles, freemaker ou velocity?
|
|
|
|
Eu acho boa a iniciativa de qualquer projeto opensource.
Como mencionado, utiliza quem quer.
|
|
|
|
glaucogoca wrote:
Cara, o JBoss Seam só é produtivo se você criar tags personalizadas ou utilizar algumas que alguém já criou. Isso foi dito pelo profissional da JBoss que veio na minha empresa vender o produto e a criação das tags.
Vai lá no Richfaces, olha o upload de arquivos e conta quantas linhas tem pra ver se são poucas. Sem contar que se usar aquele upload o debug não funciona. (isso pra mim é bizarro.) 
Eu já usei os dois, o JBoss Seam é bom, com as tags personalizadas e tal, mas o Next ainda é bem melhor. 
[]'s
Glauco, provavelmente você não entendeu o que o profissional estava dizendo. As tags personalizadas proveem do projeto opensource chamado "X-Seam" (https://xseam.dev.java.net), e a idéia é simplesmente fornecer templates facelets para atividades comuns ao DESENVOLVIMENTO JSF. O foco é muito mais View, do que qualquer outra coisa. O Seam sem X-Seam continua tendo todas suas funcionalidades como bijeção, escopos de conversação e BPM, envio de e-mail, transformações de conteúdo (PDF, Spreadshet, etc), independência de View (JSF, GWT, Wicket e SPIs portáveis), crud framework, tooling, remoting, processamento assíncrono, etc.
|
|
|
|
Leonardo3001 wrote:O JSF é uma merda, desculpe o palavreado, mas é isso o que ele é. Mas antes, adianto duas coisas:
1) Não sou troll, porque quando solto uma declaração como essa, nunca volto ao tópico pra treplicar.
2) Conheço bem JSF, e até respondo a dúvida de alguns aqui no GUJ, coisa que muito fã de Faces não faz.
Bem, pra entender o porque do JSF não prestar, você precisa conhecer a lei da abstração vazada, criada por Joel Spolsky (antes de virar o idiota que é hoje):
Todas as abstrações não-triviais, em algum grau, vazam.
Essa frase é uma luva de pelica pra qualquer desenvolvedor metido que fica matutando a solução "elegante". E se aplica como uma luva no caso do JSF, que pretende criar uma visão de componentes (leia-se: arrasta-e-solta) pra um protocolo que lida com envio e recebimento remoto de documentos. Usando esse framework, sempre haverá o problema de quando precisar criar janelas ou algum tipo de ajax (como o label que vira input), ou qualquer coisa não-trivial.
Aí, é claro, alguém lembra que precisa usar, além do JSF, um outro plugin que resolva situação X. Bom, você só está adiando o vazamento de abstração pra um outro momento. Chegará logo aquele dia em que você precisa fazer algo específico, e o framework não fará direito, nem com a ajuda de nenhum outro plugin.
Bons frameworks MVC não tentam ser abstrações não-triviais em cima do protocolo HTTP, o Rails é um exemplo clássico disso, onde você entende como são geradas as URLs e como serão as páginas html resultantes. Frameworks bons são o Spring MVC (quem acha ruim, só o conhece numa versão antiga), e o VRaptor do pessoal da Caelum. E quem prefere (não sei porquê) os frameworks orientados a componente, uma excelente pedida é o Wicket, que não esconde noções como form e evento de submit.
Leonardo, entendo seu posicionamento mas não acredito ser verdade para toda e qualquer situação. Se for falar em preciosíssimo em abstração, então todos deveríamos utilizar apenas Servlets. Todo framework especializa APIs para abstrair interações entre desenvolvedores e a tecnologia subjacente, definir se algo é trivial ou não, pode ser um parâmetro um tanto quanto particular.
Você pode optar por utilizar um determinado framework em um projeto de acordo com as especificações deste, e um outro para demais projetos com caracterísitcas diferentes.
Nos projetos JBoss por exemplo, a interface para o novo jBPM Console é baseada em GWT, assim como no Guvnor(Business rules management system). Ambos projetos possuem pouquíssimas páginas, mas MUITO ricas, com vários estados que se resolvem via Ajax (como o GMail, por exemplo). Em sistemas maiores, como o projeto JOPR (plataforma de monitoramento de servidores), a tecnologia é JSF, tendo em vista que o foco são formulários, tabelas e menus... típico da maioria de sistemas convencionais. As vantagens de usar JSF foi possuir todos os componentes para o cenários prontos, como menus, estrutura de árvores, ajax de campos e bind para geração de gráficos sem grandes esforços.
Ja trabalhei em projetos, que acredite, a melhor solução ainda agora foi Struts 1.x. A equipe precisava fazer um sistema rapidamente, com poucas páginas, todos da equipe dominavam apenas Struts por estarem a muito tempo com projetos efetivos com estes... eu iria sugerir aprender um novo framework? Não, para o prazo e para o projeto a melhor escolha é o Struts, com certeza.
Sou cético quando se refere ao "melhor framework". Isso deve levar em consideração projeto, equipe e prazos. Sem isso, não acho sensato qualquer avaliação mais profunda.
|
|
|
|
rogelgarcia wrote:Uma outra coisa que gostaria de perguntar...
No inicio, não tinhamos um framework orientado a componentes, e tinhamos o controle do que acontecia com a requisição. Se utilizarmos um framework como JSF, esse controle fica com o JSF. Vejo que grande parte dos problemas que acontecem com o JSF, são devidos a não sabermos o que realmente acontece por baixo dos panos.
O que não sabemos acontecer por debaixo dos panos? Alguma coisa você gostaria de alterar ou ter o comportamento diferente e o JSF não lhe permite? Explique esta colocação com algum exemplo se possível.
rogelgarcia wrote:
Uma pergunta, é necessário que a parte View de uma aplicação seja orientada a componentes? Será que isso não aumenta a complexidade e com isso o tempo de desenvolvimento?
Pelo contrário, sinto-me bem mais confortável com component based do que action based. A programação para GUIs utilizam essa abordagem a anos, não vejo mal algum nisso.
rogelgarcia wrote:
Se o mesmo investimento que foi feito no JSF, tivesse sido feito em uma solução para agilizar o desenvolvimento request-response (baseado em controllers), não teriamos menos problemas, e uma solução mais estável do que temos hoje com JSF?
Mais uma vez, não sei a qual problema de estabilidade quanto ao JSF (como framework) você se refere. Exemplos?
|
|
|
|
Difícil localizar a origem do erro sem ver de fato seu ambiente.
Mas uma dica, JAMAIS confie em deployment feito diretamente pelo Eclipse. Utilize uma ferramenta de build como o Ant ou Maven para projetos reais.
|
|
|
|
Aqui na Red Hat, todos utilizam Lenovo Thinkpad.
Placas som/video, leitor biométrico, webcam... tudo é reconhecido sem nenhuma dor de cabeça ( T60/T61/T400 etc ).
Os notes vem com Windows, portanto todo o hardware tbm é compativel com o sistema da microsoft.
OBS: Cuidado com Linux que já vem instalados em algumas máquinas. Minha irmã comprou uma estação Quadcore com 4 giga de ram... uma carroça, graças ao FeniX Linux. Um lixo, dá pra entender perfeitamente pq os usuarios formatam e instalam Windows e passam a detestar o pinguim. Vá de Fedora ou Ubuntu que não tem como errar.
|
|
|
|
MauroOliveira wrote:Alguém mais gostaria de comentar sobre um caso de sucesso ? (independente da metodologia...).
A questão é que muitos programadores já descobriram que a metodologia e todo ciclo de vida utilizado no desenvolvimento de projetos, influenciam DIRETAMENTE no que se refere ao título da thread - "Empresas boas para se trabalhar" - e não apenas o salário que se recebe.
|
|
|
|
|
Você pode copiar aqui a stack trace do erro?
|
|
|
|
PS:Se vc quer utilizar o EJB como local, como você fez no lookup, anote a interface do EJB como local, não como remote (embora o JBoss otimize interfaces remotas que são invocadas localmente, as tratando como local).
|
|
|
|
Legal que funcionou Gabriel, mas vá com calma.
Se vc utiliza a tecnologia JavaEE 5 o interessante é tirar proveito de seus recursos, como Dependency Injection. Embora lookup funcione, o mais indicado hoje, seja por produtividade, clareza no código e testabilidade, é usar DI.
Não desista, reveja seu código e vá atrás do erro. Se você esta tentando aprender a tecnologia, não utilize atalhos.
|
|
|
|
É a linha 15 + 16:
... ou seja, seu ejb esta em "HelloUserBean/remote"
Utilize o JBoss na versão 5.1.
|
|
|
|
A série 4.x do JBoss não é inteiramente compatível com a especificação JavaEE 5, embora suporte o uso de EJB3. Uma das incompatibilidades é injeção via @EJB fora do container EJB, como em uma servlet, isso de fato não funciona.
A versão 5.x é 100% certificada JavaEE5 portanto injeção de EJBs em Servlets funcionam sem problemas.
Portanto pra fazer o que vc quer, utilize as versões da série 5 do JBoss, e não a versão 4.
|
|
|
|
Tente cololocar a classe Aluno dentro de algum pacote como br.com.nomedesuaempresa.entity, se ainda não estiver.
No mapeamento do hbm.xml, coloque em classe o nome inteiramente qualificado desta, ou seja, o pacote + classe. Exemplo:
'<class name="br.com.nomedesuaempresa.entity.Aluno '
Mas de verdade mesmo, utilize anotações no lugar de arquivos .hbm.xml. É bem mais simples de escrever os mapeamentos.
Estude também JPA.
Um ótimo livro sobre utilização do hibernate e JPA é :
http://www.manning.com/bauer2/ (Java Persistence with Hibernate)
Leitura indispensável.
[]s
|
|
|
|
|
|
|