JPA Desktop manipular persistence.xml para acesso ao banco

Assuntos Gerais
#1

Aew galera tenho uma aplicação Desktop rodando com JPA e o Hibernate como provedor e gostaria de saber como faço para manipular o persistence.xml que fica dentro do jar da aplicaçao em tempo real para alterar dados de conexão com servidor etc…
e outra coisa tem como bloquear esse arquivo xml para que ninguem possa abrir o jar e editar o xml ou visualizar os dados de conexão?

#2

Manipular os dados desse arquivo não tem jeito não, até pq ele só é lido uma vez. Mas a especificação garante q vc pode alterar “qualquer” propriedade do seu
persistence-unit em runtime.

Da uma olhada nesse link aqui q ele explica melhor: http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html/configuration.html

1 curtida
#3

dei uma olhada no EntityManagerFactory e consegui passar um Map

funcionou tranquilo mas agora a duvida ele soh passa uma vez nessa factory no case se eu tiver que editar esses dados na aplicação nao tem como criar uma nova instancia no EntityManager para que assim nao rpecise reiniciar a aplicação?

#4

Vc tentou?

#5

creio que va funcionar vou tentar tirar o singleton e instanciar outro EntityManager pra ver

#6

Cria um hashmap setando as configuração como citado acima:

persistenceProperties.put("hibernate.connection.url",p.getProperty("url"));
persistenceProperties.put("hibernate.connection.driver_class",p.getProperty("driver"));
persistenceProperties.put("hibernate.connection.password",p.getProperty("password"));
persistenceProperties.put("hibernate.connection.username",p.getProperty("user"));

onde persistenceProperties é um Map…

depois

Persistence.createEntityManagerFactory("name",persistenceProperties);

Dae deixa o singleton só pro EntityManagerFactory, no EntityManager cria um novo cada ves que for usar…

até

#7

ta belezinha agora só preciso fazer alguma criptografia nesses dados de conexao do arquivo properties pois se não qualquer um consegue visualizar o usuario e senha do banco.

O que me recomendam?

#8

Ai já é firula demais!!!

Se vc realmente precisa de toda essa segurança na sua aplicação, então ela devia usar uma arquitetura de 3 camadas. Assim vc poderia colocar a sua lógica, bem como esses dados sensíveis, em um servidor q os usuários não pudessem acessar diretamente.

#9

a aplicação esta toda separada em camadas mas o problema é que o sistema é de altomação comercial, entao roda no proprio caixa nao tenho como configurar um servidor pra isso até pq tem de funcionar local a melhor maneira que pensei foi em fazer alguma criptografia no properties para que nao fique na cara o usuario e senha do banco

#10

Eu acho pouco provável q vc consiga isso e, o mais importante, q isso realmente valha a pena. Vc deveria aceitar o risco ou partir p/ um de 3 camadas afinal vc já tem q se conectar ao servidor de banco, então coloca o seu servidor de aplicações lá logo!!

#11

Entao mas o problema é que com ECF não se pode fazer conexao a outro servidor tem de funcionar local entao o banco fica local rodando junto com a aplicação no caixa não tem como adicionar um servidor de aplicação, no caso da parte de cadastro ae sim pode rodar em outro banco de dados outra maquina etc mas o de ECF/PDV nao

#12

Se usar essa tecnologia é um requisito do seu cliente, então explique p/ ele os riscos de se usar tal tecnologia. A menos q esse seja um requisito do cliente, eu jamais tentaria esse tipo de artifício, até pq vc não sabe se é possível. Vc vai acabar perdendo muito tempo q, d outra forma, poderia ser dedicado à codificação da lógica da aplicação. Eu posso te assegurar q a velocidade no desenvolvimento da aplicação vai agradar muito mais o seu cliente do q essa firula tuda, q ele provavelmente nem vai entender p/ q serve.

#13