| Autor |
Mensagem |
|
|
Roger75 wrote:Olá,
Eu não entendi direito esta parte
Isto feito, adiciono um IP à minha placa, usando o procedimento padrão do SO em que vc. estiver trabalhando (ex: em Linux, /sbin/ifconfig eth0:1 192.168.0.55 ).
Você sabe como eu faço isso no Windows XP Professional?
Obrigado
1. Control Panel/Network Connections/Local Area Connection
2. Selecione o item Internet Protocol
3. Clique em "Properties"
4. Caso não esteja já configurado assim, troque a opção "Obtain an IP address automatically" para "Use the following IP address".
5. Preencha os dados com os da sua conexão "normal"
6. Clique em Advanced...
7. Adicione outros endereços/gateways à vontade.
Se isto não resolver, contate seu administrador de rede (pela sua dúvida, assumo que vc. não é o da sua).
|
 |
|
|
Alguém já instalou 2 JBoss na mesma máquina com sucesso?
Obrigado
Até mais do que isto 
Prefiro, no entanto usar múltiplos IPs/configurações e usar uma única instalação
do JBOSS. Desta forma mantenho a instalação original do JBOSS "intocada", o que facilita eventuais upgrades.
Para tanto, basta adicionar IPs à sua máquina e usar a opção --host=um.dos.ips na hora de iniciar a configuração desejada.
Por exemplo, digamos que eu precise de duas configurações - teste e homologação - na mesma máquina (você não faz desenvolvimento e homologação na máquina de produção, certo ?  ).
A primeira coisa que faço é criar as configurações do JBoss, tipicamente copiando o diretório $JBOSS_HOME/server/default para $JBOSS_HOME/server/teste e $JBOSS_HOME/server/homologacao.
Em cada um dos diretórios, crio os recursos necessários para a aplicação (datasources, mail, etc).
Isto feito, adiciono um IP à minha placa, usando o procedimento padrão do SO em que vc. estiver trabalhando (ex: em Linux, /sbin/ifconfig eth0:1 192.168.0.55 ).
Agora, para executar:
- configuração de homologação:
cd $JBOSS_HOME/bin
./run.sh -c homolog --host=seu.ip.normal
- configuração de homologação
cd $JBOSS_HOME/bin
./run.sh -c teste --host=ip.de.teste
|
|
|
|
AllMighty wrote:
psevestre wrote:
Numa Dr. Dobbs +/- recente (acho que do ano passado), saiu um artigo de um cara advogando o uso do XML para o código fonte.
esse?
Possivelmente. Ao menos a linha de argumentação é a mesma. Mas o artigo que li não era este, nem o da ACM.
|
|
|
|
urubatan wrote:a vantagem de anotações sobre XML é qu anotações são verificadas em tempo de compilação, e não só em runtime
No fundo, será que o problema não é das IDEs ?
Tanto annotations quanto os XMLs são usados para adicionar
metadados aos elementos da linguagem que serão usados em
determinado contexto.
Eu, particularmente, acho que as anotações, quando visualizadas da forma
atual, poluem o código. Acho que é aí o nó da questão.
Numa Dr. Dobbs +/- recente (acho que do ano passado), saiu um artigo de um cara advogando o uso do XML para o código fonte. Seu argumento: Qualquer equipe de desenvolvimento que quiser ter uma produtividade decente precisa de uma IDE. Todo mundo usa editores WYSIWYG, mas ninguem está precocupado como eles armazenam internamente (e no arquivo) a fonte utilizada em um parágrafo. Por que então deveríamos nos preocupar com isto no caso de código-fonte ? Quem determinou que, para toda existência, o fonte de um programa será texto-puro ? BTW, até o VB4 acho que ainda havia a opção de salvar o fonte em "formato binário".
Tanto o XML quanto as anotações são pouco legíveis, encaremos este fato...
Imagino que a evolução natural das IDEs irá levá-las a ocultar as anotações, pelo menos na visão padrão do editor do fonte. O programador, clicando com o botão direito do mouse sobre um atributo ou usando um atalho, teria acesso a um diálogo amigável para preencher os metadados. Preencheu, fechou, pronto: de volta para um fonte limpo - pelo menos na aparência.
Para suportar isto, uma representação XML do fonte cai bem. Usando namespaces seria fácil suportar novas extensões e, em princípio, o próprio processo de compilação poderia expandido para incluir passos de verificação adicionais. Pex, no caso do Hibernate, um plugin para o compilador poderia acessar a base de dados e verificar se as tabelas criadas existem, se são compatíveis, etc.
|
|
|
|
Pelo log, vc. está usando o Hibernate 3. Vc. checou se o XDoclet em uso é
compatível e está configurado para gerar os mappings desta versão ?
|
|
|
|
Quando tive minha "primeira vez" com o Java, vinha de muito C/C++, de forma que entendo sua dúvida.
Devo confessar que demorei a me habituar a poder alocar objetos a torto e a direito sem ter que me preocupar com violações de acesso e vazamentos de memória. Acho que parte desta "neura" persiste até hoje, pois meu reflexo
instintivo me leva a tentar evitar o uso do "new" quando possível...
Anyway, como vc. está iniciando no Java com background de C/C++, acho que a melhor forma de entender o que acontece é imaginar que, na verdade, todos as variáveis cujo tipo descende da classe Object _são_ ponteiros. Ou seja, em C/C++ vc. pode ter uma variável automática (aka stack-based) de um tipo complexo, que será desalocada no retorno da função. Em java, isto não existe. Tirando os tipos primitivos (char, int, byte, float, double, boolean - equeci algum ?), _todos_ os outros são alocados no heap.
Isto significa que algumas contruções comuns em C/C++ não
terão o efeito esperado em Java. P.ex., atribuições do tipo a=b, onde "a" e "b" são variáveis não primitivas correspondem à uma cópia de ponteiros, ou seja, "a" aponta para a mesma área do heap apontada por "b".
|
|
|
|
|
Acho que tem um monte de gente por aqui que trabalha com XDoclet. Quanto a poder ajudar, só dá para saber se vc. postar a dúvida
|
|
|
|
vonlinkerstain wrote:
Principalmente esta idéia de deixar um servidor de bd externo. Eu sou meio contra isto, mas não tenho argumentos. É mais gosto e opnião pessoal mesmo.
Olhando do ponto de vista de segurança, não há diferença entre ter um
banco de dados local com apenas as informações relevantes e ter acesso ao banco remoto. Se alguem invadir o servidor, os dados estão espostos da mesma maneira.
Na prática, o acesso remoto ao servidor tende a ser mais arriscado. É muito mais prático para o DBA simplesmente criar um login de aplicação com acesso irrestrito às tabelas...
Sei que cuidar de segurnaça em um servidor web é coisa feia e de uma responsabilidade muito grande.
Quem toma as decisões aqui sou eu, e eu tenho muito receio de escolher uma empresa que não seja assim tão segura quanto se pensa, pois eu mesmo já vi vários provedores com Linux, se dizendo seguros, mas utilizando versões de apache e CIA muito antigas e com falhas de segurnaça.
Talvez ai resida o meu medo/receio.
Custo x Benefício, de novo. Segurança custa caro. A IBM, p.ex., vende um serviço de "hacker ético" que faz avaliações periódicas do seu site, tentando invadí-lo.
Por que não deveria fazer nem os session bean acessar os dados diretamente?
Para ter um nível a mais de segurança. Use o session bean apenas como um wrapper de uma stored procedure (ou o equivalente disto no seu ERP) que retorna os dados necessários.
Deveria deixar um servidor de aplicativos separado de um servidor de dados?
Depende... Tente estimar os dados a manipular nos cenários típicos e faça o desenho de forma a minimizar "round-trips".
|
|
|
|
vonlinkerstain wrote:é que aqui trabalhamos com produção em cima dos pedidos,
Vendas vai ficar na internet, e ai. Isto que ser online com o bd aqui.. senão não tem como programar a produção, ou pior, encavalar pedidos...
Se vc. diz que seu processo é assim, sou obrigado a acreditar ;^)
Enfim, o ponto é que sempre vale questionar necessidades deste tipo. Com disse anteriormente, é uma questão custo x benefício que deve ser avaliada e entendida pelos patrocinadores do sistema.
Já participei do desenho de sistemas com necessidades semelhantes e, quase sempre, questões como esta puderam ser resolvidas através de processos batch que faziam o sincronismo dos dados.
Em um sistema de naterial promocional, p.ex, o sistema recebia quotas que cada revenda poderia solicitar sem necessidade de aprovação. Os pedidos eram consolidados diariamente e agrupados para otimizar os processos de compra e distribuição.
Em outros casos, o sistema era apenas um front-end para um conjunto de transações que foram desenvolvidas no ERP (SAP no caso). Esta , aliás, é uma alternativa que vc. deve considerar seriamente. Se, após todas as considerações voce chegar à conclusão que o acesso ao ERP deve ser online, faça o desenho do sistema de forma que não exista necessidade de acesso direto às tabelas do banco, nem mesmo pelos SessionBeans !
|
|
|
|
saoj wrote:
psevestre wrote:
Algo contra implementar "tools" com funcionalidades semelhantes às tags ?
Acho que não dá pois os tools não possuem acesso ao request.
Dê uma olhada na implementação dos Tools p/ struts. No caso eles fizeram um servlet específico para views Velocity e utilizam o método init() do tool para passar o contexto da view, que inclui o request, response, etc.
|
|
|
|
saoj wrote:Acho que vc não entendeu o ponto da questão:
Suporte a Velocity é importante pois tem muita gente como tu que prefere velocity a JSTL + EL.
Só que quando vc usa Velocity vc perde as taglibs do framework, isto é, todas aquelas mágicas e facilidades das tags do mentawai são perdidas.
Só curiosidade...
Chegou a pensar em seguir o mesmo caminho da turma do velocity-tools ?
Algo contra implementar "tools" com funcionalidades semelhantes às tags ?
|
|
|
|
No servidor web ou em uma máquina acessível por este, mas que não o servidor principal.
Quanto à atualização contínua, é uma questão de custo x benefício.
Nesta hora o papel do analista é deixar claro para o usuário/cliente, o que significa a necessidade que ele apresenta.
Se os dados _realmente_ são tão voláteis ao ponto de ser necessário acesso aos dados do "último commit", isto terá influência decisiva na solução que será necessária.
Com uma relação consulta / atualização for próxima da unidade, e/ou se o custo de negócio associado a dar uma posição que pode não ser a atual justificar, possivelmente justifica-se o acesso direto ao ERP. De outra forma, uma arquitetura baseada em réplica dos dados deve atender.
|
|
|
|
Alem de usar o JAAS, sugiro que o sistema acesse uma réplica
da base, e não a base real. Principais motivos:
- Segurança: Seu servidor pode ficar numa DMZ e/ou um datacenter externo, limitando o impacto de uma eventual invasão;
- Performance: Vc. pode definir um modelo de dados otimizado para as consultas e alimentar a base em batch apenas com a informação necssária, a qual, tipicamente, é apenas um subconjunto de tudo que vc. terá no ERP.
|
|
|
|
Já deu uma olhada no jBPM e assemelhados ?
O paradigma neste caso é o de diagrama de atividade, que é mais flexível que uma máquina de estados simples.
|
|
|
|
Se a a motivação do post foi procurar exemplos de sites em struts na área de governo, tem o da CAIXA Internacional. Vá no site da caixa e siga o link CAIXA Internacional.
|
|
|
|
|
|