Mensagens enviadas por: Luiz_Gustavo
Índice dos Fóruns » Perfil de Luiz_Gustavo » Mensagens enviadas por Luiz_Gustavo
Autor Mensagem
Já estou no grupo! Ótima iniciativa. =)
Meus parabéns Loiane!
Que venham outros livros.

[]'s
ViniGodoy, nem acho que seja questão de preguiça. Como ele mesmo disse faz pouco tempo que está programando, e no começo é difícil ter um senso crítico quanto às soluções que são passadas por outras pessoas. Como ele não conhece nada de JTable ele pode ter achado que esta solução apresentada pelo primeiro exemplo é a melhor (ou única).

Cesar, neste link que passei tem um exemplo completo de como criar uma AbstractTableModel, com DefaultTableColumnModel e DefaultTableCellRenderer.


[]'s
Aí é que está jakefrog,

como só descobrimos em produção não conseguimos tirar o Hibernate, pois não daria tempo de reimplementar em JDBC puro (o que ajudaria a resolver o problema).
A medida paleativa (que está longe de ser a ideal) foi colocar a aplicação em um cluster e monitorar o uso da memória, reiniciando um dos servers quando necessário.

Na época um consultor me disse que havia um recurso no JBoss que permitia configurar a segurança declarativa integrada com o datasource, fazendo com que o datasource (sem pool) criasse conexões personalizadas para cada usuário. Eu já fiz 2 cursos de JBoss, e nunca encontrei este tal recurso, e para quem perguntei ninguém nunca ouviu falar. Sem dizer que um datasource sem um pool não serve de muita coisa.

Resumindo, foi um caminho sem volta.

Na API do JPA (1.0, que foi o que usamos) havia uma maneira de criar o EntityManager passando um Properties com algumas configurações. Eu até tentei criar um único EntityManagerFactory com um usuário padrão, e ao criar o EM tentei passar os dados de usuário, mas não adiantou nada.


[]'s
Um detalhe que esqueci de mencionar:
Este problema que citei pode ser difícil de identificar em tempo de desenvolvimento, pois costumamos testar a aplicação com apenas um usuário. Quando a aplicação vai para a produção, com vários usuários, o problema aparece.
Foi difícil identificarmos que era este o problema. Analisando a heap utilizada pela aplicação víamos que a quantidade de objetos do Hibernate aumentava gradativamente, mas demorou até percebermos que estava relacionado à criação de EMF para cada usuário.
Para se ter uma ideia, a cada login de usuário 10MB eram ocupados na memória, e estes objetos tem uma vida longa na heap. Imagine 100 usuários se logando na aplicação...

[]'s
ameliapessoa,

me permite te alertar sobre uma coisa (pois já tive problemas com este tipo de cenário)?
Se você for usar JPA ou Hibernate nesta aplicação tome muito cuidado! Se você for usar um destes frameworks para persistência, terá que criar um EntityManagerFactory para cada usuário da aplicação, para que sua aplicação funcione como espera, e estas instâncias de EMF costumam ocupar muito espaço em memória (o espaço é proporcional ao tamanho do banco de dados).
Quando trabalhei em uma aplicação web com este cenário (um usuário no banco para cada usuário da aplicação) criávamos um EMF para o usuário no momento do login, e armazenávamos na sessão. Mesmo depois da sessão expirada os objetos (metadados) referenciados pelo EMF permaneciam na memória, e em pouco tempo levavam o servidor de aplicações a um esgotamento de memória.

Pense nisso!

[]'s
Cesar,

apensar de você ter aparentemente resolvido seu problema dá uma olhada neste post: http://www.guj.com.br/java/35481-alimentar-um-jtable-com-uma-select

[]'s
Legal!
Vamos ver como fica agora a convivência do Flex e do Pivot como projetos da Apache, já que ambos almejam o mesmo nicho de aplicações.
Galera, estou ressucitando este tópico para saber se alguém conseguiu resolver as questões postas, e colocar mais uma questão sobre o mesmo assunto:

O que vocês fazem, por exemplo, quando o totalGeral utilizado na expressão abaixo é obtido apenas no final de um agrupamento:



Digamos que eu queira obter, linha a linha, o valor percentual da linha relativo ao total do agrupamento (e não relativo ao total do relatório).


Abraços!
viren wrote:Hi,

I am viren, founder of Weaverfx.com
We took inputs from various sources [including this user group]and we revisited and restructured our deployment structure.

With the betterment the user doesn't have to download the runtime to start the apps, now we have web start examples also

Weaverfx is primarily for developing for more of complex UI with extreme ease.

Please take a look at the following examples[which shows weaverfx capabilities of complex UI], we will soon be posting the code for the above, all the examples are of the tune of 30 to 50kb

http://weaverfx.com/Weaver33
http://weaverfx.com/Weaver34
http://weaverfx.com/Weaver35 [this is a facebook demo application built using weaverfx, will be slow as not optimized yet]

We look forward for suggestions and improvements

thanks
viren



Hi viren,

that's a great initiative to visit the user groups and read what people are saying about the platform.
I guess it's worth to take another look at the examples, and try the new features.


Thanks end welcome to GUJ.
dederocker,


se você está aprendendo agora, não há nada que te impeça de usar netbeans ou eclipse, mas as configurações iniciais e diversas opções das ferramentas podem confundir você no começo.
Para aprender a sintaxe básica da linguagem eu lhe aconselharia ferramentas como o blueJ (http://www.bluej.org/) ou JCreator (http://www.jcreator.com/).
Se mesmo assim você quiser utilizar o eclipse, por exemplo, este tutorial que escrevi mostra passo-a-passo (e mastigado) como configurar um ambiente do zero, com todos os links necessários: http://luizgustavoss.wordpress.com/2009/12/13/preparando-um-ambiente-de-desenvolvimento-java-ee-baseado-em-eclipse/

Boa sorte e bons estudos!
Entendi =)

Neste caso me parece mais fácil.

Supondo que você está usando um datasource gerenciado pelo seu servidor de aplicações para obter as conexões (que é o recomendado), você terá que criar vários datasources no seu servidor, um para cada banco, dando a cada um o seu devido nome JNDI.

No seu arquivo persistence.xml você pode criar várias unidades de persistência, cada uma com um nome e referenciando um datasource diferente.

Depois você pode criar as instâncias de EntityManagerFactory, uma para cada unidade de persistência, armazenar estas instâncias em um cache, e recuperar cada uma no momento com base nos dados de login.

ederfreitas,

neste projeto em que trabalhei, em um determinado momento, deixamos de usar EJB, e passamos a usar somente JPA, controlando as transações manualmente.

Para a questão de mudar dinamicamente os dados de conexão havíamos adotado a estratégia de criar instâncias de EntityManagerFactory com as configurações necessárias, mas isto nos levou a um grande problema de performance no final.

Quando se trata de EntityManagerFactory o ideal é que se tenha apenas uma instância no sistema, pois cada instância costuma ser muito cara em termos de recursos, ocupando muito espaço em memória (isso varia de acordo com o tamanho do banco).

Como criávamos um EntityMaganerFactory para cada usuário do sistema (a cada vez que um usuário realizava o login criávamos a instância personalizada e mantínhamos em um cache) em pouco tempo a memória estava cheia, com os objetos de metadados do banco.

Tentamos personalizar os dados de conexão passando propriedades no momento da criação das instâncias de EntityManager, mas não tivemos sucesso.

Um consultor que tentou nos ajudar, na ocasião, disse que havia uma forma de configurar o JBoss para que o mesmo realizasse a autenticação dos usuários, e com as mesmas credenciais fornecer as conexões ao EntityManager, de acordo com o usuário logado. Bom, a consultoria nunca conseguiu nos mostrar isso, e eu também não consegui encontrar este recurso. (A autenticação dos usuários é beleza, mas me refiro à passagem de conexões personalizadas ao EM).

Na configuração de datasource do JBoss há uma opção que permite especificar para a fábrica de conexões qual usuário e senha utilizar para recuperar conexões, mas não testei ainda para ver como isso poderia ser utilizado com o JPA:

application-managed-security: Se true, o login e senha para conexão serão fornecidos pelo código Java que requisita a conexão ao servidor de aplicações, em vez de pela definição do datasource;


Olá!

Você tentou executar o processo em uma thread separada?
Pelo que entendi você está executando o processo a partir da tela, ou seja, a partir da mesma thread que a tela. Se o processo for demorado (como imagino que é, por usar um JProgressBar) a tela ficará "travada" até que o processo termine.

Neste link você encontra exemplo de como usar uma instância de Task para execução do processo:

http://download.oracle.com/javase/tutorial/uiswing/components/progress.html

Task is a subclass of javax.swing.SwingWorker. The Task instance does three important things for ProgressBarDemo:

1. The instance invokes the doInBackground in a separate thread. This is where the long-running task is actually executed. Using a background thread instead of the event-dispatching thread prevents the user interface from freezing while the task is running.
2. When the background task is complete, the instance invokes the done method in the event-dispatching thread.
3. The instance maintains a bound property, progress, that is updated to indicate the progress of the task. The propertyChange method is invoked each time progress changes.



Abraço!

Pessoal,

alguém aqui já trabalhou com o Mondrian e JPivot, e precisou realizar a internacionalização do catálogo xml?
Não estou usando o Pentaho, apenas o Mondrian com o JPivot.

Tentei segui as instruções presentes nestes links, mas sem sucesso.

http://forums.pentaho.com/showthread.php?64015-Property-quot-mondrian.rolap.localePropFile-quot-set-in-web-application-code
http://forums.pentaho.com/showthread.php?48095-Problems-with-the-Internationalization
http://forums.pentaho.com/showthread.php?64066-SOLVED-localePropFile-with-relative-path&p=194720

Independentemente do que eu faça, de onde eu coloque os arquivos de propriedades com os locales suportados, o resultado final (o texto apresentado) é sempre %{entrada.do.properties}

Já tentei configurar os arquivos properties como um caminho absoluto no sistema de arquivos.
Já tentei configurar os arquivos properties dentro de um pacote de classes e referenciá-los no padrão nome.do.pacote.ArquivoProperties
Já tentei deixar os arquivos na raiz do diretório de fontes.
Já tentei uma configuração direta na página JSP, como mostra um dos links acima:



Mas nada disso adiantou ¬¬


Nas páginas onde são realizadas as consultas, tenho o seguinte:




e nesta tag não há um local para as mesmas configurações feitas no mondrian.properties, na string de conexão.


Enfim, alguém já fez com sucesso a internacionalização desses recursos, e teria o caminho das pedras para compartilhar?


Abraços!
 
Índice dos Fóruns » Perfil de Luiz_Gustavo » Mensagens enviadas por Luiz_Gustavo
Ir para:   
Powered by JForum 2.1.8 © JForum Team