| Autor |
Mensagem |
|
|
louds wrote:Marcio, vale lembrar que nem sempre é possivel ter um ambiente de homologação igual ao de produção.
Correto. Especificando um pouco mais, como o Marcio Tavares comentou: o problema eh ter ambientes diferentes mas politica inadequada para isso (agir como se fossem iguais quando nao sao). 
Marcio Kuchma
|
 |
|
|
danieldestro wrote:O problema é que quando algum destes servidores, por obra dos administradores (principalmente terceiros), tem alguma config diferente ou algo faltando, ai sofremos para descobrir onde está o problema, sendo que em desenvolvimento ou homologação tudo funciona bem.
Exatamente.
Ja passei por esse tipo de situacao e minha opiniao eh: o problema nao eh nao ter acesso a producao (isso eh normal, compreensivo e totalmente saudavel). O problema eh o maldito ambiente de homologacao nao refletir o de producao. Teoricamente voce deveria homologar e, uma vez homologado, colocar em producao numa boa. Mas sabe como eh - sempre tem um detalhezinho a mais ou a menos para ajudar.
Pra piorar, em certos ambientes o cara que implanta a aplicacao deve (por politica da empresa) comportar-se como um simples "operador". Ou seja, se tem uma virgula fora do lugar de um ambiente pra outro, ele nada pode fazer.
Enfim, juntando tudo isso o resultado eh stress garantido para o desenvolvedor.
Marcio Kuchma
|
|
|
|
O nome ficou otimo. Ruva. Imagine os comentarios: Ruva rules! Melhor do que "Jaby".
RUVA is intended for (my) experimentation and play only. Obviously.
Trata-se de um projeto pessoal. Deixem o cara desenvolver o projeto dele sossegado.
Marcio Kuchma
|
|
|
|
A stacktrace mostra que esta dando NullPointerException na classe HibernateUtility, linha 24. Veja o que tem nessa linha e porque esta null. Chute: a SessionFactory que fornece os objetos Session esta nula devido a algum problema de configuracao do Hibernate (nesse caso veja os logs do teu servidor pra descobrir detalhes do erro - supondo que o Hibernate esta logando, claro).
Marcio Kuchma
|
|
|
|
Se o banco fosse utilizado apenas como repositorio de dados, voce poderia utilizar o PostgreSQL ou ate mesmo o MySQL. Mesmo assim, com certas ressalvas (diferencas de sintaxe SQL).
Como esse nao parece ser o teu caso, tente usar o Oracle mesmo, seja local, seja remoto. Vai evitar retrabalho e/ou dor-de-cabeca depois.
BTW, porque sempre chamam o PostgreSQL de "postgre"? Nunca vi ninguem chamar o MySQL de "my". 
Marcio Kuchma
|
|
|
|
boaglio wrote:O CLOB é a maneira viável de armazenar informação de texto no Oracle com mais de 4000 caracteres (menos que isso use Varchar2).
Com CLOB da pra trabalhar normalmente como se a coluna fosse de texto (set/getString no JDBC, tipo String no Hibernate, etc) ou eh necessario alguma precaucao especial? (nao, ainda nao testei isso )
Marcio Kuchma
|
|
|
|
fabgp2001 wrote:CLOB?
O teu problema parece se o legado mesmo. Que versao do Oracle é isso ai?
Oi - a versao eh 10g, ou seja, a mais atual. Fiquei assustado ao perceber a limitacao de 30 caracteres. Mas ja passou.
Sobre o CLOB: obrigado pela dica, vou investigar.
Marcio Kuchma
|
|
|
|
Pois eh... sobre usar menos caracteres - o problema eh a palavra "migracao".
Depois que descobri que uma string vazia eh tratada como NULL no Oracle e que nao eh possivel ter mais de uma coluna LONG por tabela (porque cargas d'agua nao existe um tipo simples, facil e direto para textos longos no Oracle, como o TEXT do PostgreSQL?), essa dos 30 caracteres virou fichinha.
Marcio Kuchma
|
|
|
|
Pessoal,
Estou migrando algumas tabelas de MySQL/PostgreSQL para Oracle e me deparei com uma limitacao estranha (IMHO) do Oracle.
Nao eh possivel criar identificadores com mais do que 30 caracteres. Por identificador, entenda-se nome de tabela, coluna, indice, etc.
O erro eh bem simples:
ORA-00972: identifier is too long.
Procurando encontrei varias referencias sobre esse erro... nada sobre como alterar essa configuracao - apenas variacoes de:
Cause: The name of a schema object exceeds 30 characters. Schema objects are tables, clusters, views, indexes, synonyms, tablespaces, and usernames.
Action: Shorten the name to 30 characters or less.
E a pergunta fatidica: realmente nao ha como contornar essa limitacao exceto diminuindo o tamanho dos identificadores? E se essa for a saida, alguem mais acha isso ridiculo tratando-se de um produto como Oracle?
Marcio Kuchma
|
|
|
|
allan_net wrote:Alguém sabe se existe um componente capaz de abrir um página Web dentro de um programa java?
O projeto JDIC tem um componente Browser, que pode ser utilizado para isso. Mas nao se trata de um browser em si, ele utiliza o browser do SO.
https://jdic.dev.java.net/
Marcio Kuchma
|
|
|
|
Em Java nao eh possivel. Procure por "keyloggers". Mas cuidado, o feitico pode se virar contra o feiticeiro.
Creio previamente na boa intencao das pessoas, mas se voce pretende virar um "h4ck0", saiba que a coisa nao eh tao simples e perguntar isso em foruns de programacao nao eh o caminho. 
Marcio Kuchma
|
|
|
|
Tem suas vantagens, tem suas desvantagens. Pesquise no forum pois esse assunto ja foi debatido varias vezes - as informacoes obtidas podem ser uteis como parte do seu processo de decisao (nao devem ser a unica fonte, mas podem ser uma das).
Marcio Kuchma
|
|
|
|
Kebe wrote:Os tópicos que encontrei sobre este assunto não me esclareceram bem.
Qual a técnica mais usada para evitar de instanciar duas vezes a mesma classe JInternalFrame, e consequentemente, abrir duas janelas de uma mesma rotina ?
Tenho um cadastro de clientes aberto e quero evitar que o usuário acesse os menus e chame esta janela novamente !
Oi,
Voce precisa definir melhor o escopo do teu problema ou detalha-lo com mais exatidao aqui no post... olha soh:
- "instanciar duas vezes a mesma classe JInternalFrame": crie tua classe herdando de JInternalFrame e use o pattern Singleton (se voce nao souber o que eh isso, pergunte).
- "evitar [...] abrir duas janelas de uma mesma rotina": aqui entendo que voce nao quer abrir janelas "duplicadas" digamos assim, certo? Nesse caso voce pode criar dois metodos centrais para abrir e fechar com uma especie de "cache" para os frames. No "abrir" voce verifica se o frame ja esta em "cache". Se nao estiver, abre e poe em cache. Se estiver, apenas restaura o que ja estiver aberto. No metodo "fechar" voce remove o frame do "cache".
- "quero evitar que o usuário acesse os menus e chame esta janela novamente": se voce quer fazer esse controle no proprio menu, tera que desabilitar o item de menu correspondente no momento em que voce abrir o frame.
Se voce detalhar melhor quais dos tres caminhos voce quer seguir podemos aprofundar a discussao.
Marcio Kuchma
|
|
|
|
farribeiro wrote:Como eu entendi uma vez não existe JEE e sim J2SE(favor corrigir-me se estiver errado), mas na verdade JEE é uma especificação de como construir, é como "bons modos" e padrões para construção de sua aplicação  mas tudo é J2SE
Existe JEE sim.
Tanto JSE quanto JEE sao controladas por especificacoes (e existem implementacoes de ambas as especificacoes, claro). Talvez os "bons modos" a que voce se refere sejam os "blueprints" da Sun, mas isso eh outra historia.
- JSE: biblioteca basica do Java, collections, JDBC, RMI, Swing, etc.
- JEE: recursos "enterprise", Servlets, JSP, EJB, etc.
Mas acho que esse negocio de dividir em duas partes rigidas nao eh legal para quem esta buscando aprender a plataforma (como o colega que inicialmente postou). A divisao mais granular de APIs, como o Luca colocou, eh muito mais real, objetiva e "entendivel".
Marcio Kuchma
|
|
|
|
fabiofns wrote:Por favor, preciso de uma luz, para que eu possa me dedicar em uma tecnologia e não ter problemas futuros.
Em termos simples, nao ha como usar Java EE sem Java SE. Entao voces devem investir primeiro no aprendizado no JSE e na sequencia, se for o caso, JEE.
Da uma olhada no site da Sun para ver certinho que tem em cada plataforma... novamente, em termos bem simples:
- Se for desenvolver uma aplicacao grafica utilizando Swing e recursos da biblioteca padrao do Java, JSE atende o caso.
- Se for desenvolver aplicacoes para rodar em um servidor/container Web, com Servlets e JSP p.ex., sera necessario utilizar JEE.
Marcio Kuchma
|
|
|
|