Comment on JPA in google-guice

[google...@googlecode.com]

Comment by mendapar...@gmail.com:

I have a different *persistence.xml* in *src/test/resources/META-INF* in my
maven project for unit tests but it seems that the *persistence.xml* in
*src/main/resources/META-INF* gets precedence.

Is it possible to specify different *persistence.xml* for tests?

For more information:
http://code.google.com/p/google-guice/wiki/JPA

[google...@googlecode.com]

Comment by brian.bl...@gmail.com:

Is there a way to load the properties for a persistence unit from a
properties file? I can do this with standard JPA, but I don't see a way to
inject custom properties into the JpaPersistService where it creates the
EntityManagerFactory.

[google...@googlecode.com]

Comment by brian.bl...@gmail.com:

I found it. You can pass properties to the JpaPersistModule. For example,
when creating JpaPeristModule, you can invoke:

new JpaPersistModule("myapp-db").properties(hibernateJpaProperties)

[google...@googlecode.com]

Comment by zyskow...@gmail.com:

It looks that injecting EntityManager this way:

@Inject
EntityManager em;

breaks persist() and merge() functionality. I tested it on Jboss
5/Hibernate. Everyting else works, but objects just won't be saved. We had
to change it to:

@Inject
Provider<EntityManager> em;

There are great warp-persist examples here:
http://code.google.com/p/warp-persist-sample/. With minor modifications it
will work with guice-persist engine.

[google...@googlecode.com]

Comment by ungar...@gmail.com:

I quote zyskow, the EntityManager injection does not work also on
Tomcat7.0.19/Hibernate3.6.7.

[google...@googlecode.com]

Comment by moha...@gmail.com:

Hello,

I'd like to ask you if it's possible to make the PersistFilter class not
final.

Cause I need to start the PersistService when the servlet context is
initialized. But when the filter starts it throws an error.

If it wasn't final or if it could check if the PersistService is already
initialized would solve my problem.

[google...@googlecode.com]

Comment by anu...@gmail.com:

There is the hint "Note that if you make MyService a @Singleton, then you
should inject Provider<EntityManager> instead." IMHO this not only is true
if MyService is a @Singleton but also if MyOtherService is a @Singleton and
is using MyService which itself is NOT @Singleton.

[google...@googlecode.com]

Comment by pmmi...@gmail.com:

Would look to add something for newcomers like me. Don't know how obvious
or not this is (it wasn't for me), but if you instantiate MyService
MANUALLY your EntityManager will be null and calls will throw
NullPointerException. Since we are using Guice already, just create a new
module which you can add after MyModule when you call createInjector

public class ServiceModule extends AbstractModule {
@Override
protected void configure() {
bind(Service.class).to(MyService.class);

[google...@googlecode.com]

Comment by alexande...@gmail.com:

http://google-guice.googlecode.com/git/javadoc/com/google/inject/persist/PersistFilter.html

For multiple providers, you should register this filter once per
provider, inside a private module for each persist module installed (this
must be the same private module where the specific persist module is itself
installed).

Is there an example somewhere? I tried several things but was not able to
use multiple persistence units with the PersistFilter.

https://groups.google.com/forum/#!topic/google-guice/2VK-bdsnjZc/discussion

[google...@googlecode.com]

Comment by sekaran....@gmail.com:

The module file for this sample may also be kindly furnished for the
benefit of users new to Guice but have used Jpa earlier.

[google...@googlecode.com]

Comment by alex.che...@gmail.com:

I'm using an environment with guice-servlet running on a tomcat and
hibernate under guice-persist. The problem I've encountered is that when I
use em.getReference() in one request the loaded proxy object stays in the
entitymanager cache and may appear in another request where I expect to
have an object completely loaded from the DB.

I'm used to using hibernate in EJB3 environment where it is a default
behavior. The entity manager cache is clear for each new request. Isn't it
a more safe behavior for guice-persist to clear the session for each
request? Or at least to give it as a setting for JpaPersistModule?

There is a special flag in hibernate SessionImpl "autoClear" which is
responsible for EJB3-behavior. Is there any way I could enable the flag
when the new entity manager is being created by JpaPersistModule?

[google...@googlecode.com]

Comment by owen.k.b...@gmail.com:

"Note that if you make MyService a @Singleton, then you should inject
Provider<EntityManager> instead."

When should MyService be a singleton? If I am using the DAO without state,
i.e. injecting it into my Servlets for processing through a Provider,
should it be a one and done created object? I am creating a new one each
time, but have noticed that on message boards people say to make the DAO
Services singletons, is that right?

[google...@googlecode.com]

Comment by cr...@spiekerpoint.com:

I am attempting to disable flushing in my entityManager.
So I have: <property name="org.hibernate.FlushMode" value="NEVER" />
in my persistence.xml file.

However, this seems to be getting completely ignored when the EntityManager
is created.

Is there something I need to be doing when I create my JpaPersistModule to
get this to work properly?

[google...@googlecode.com]

Comment by alex.che...@gmail.com:

I'm using the following solution for the problem mentioned above (my msg
dated Feb 4, 2012).

I've bound an Interceptor for method returning an EntityManager in my main
module:
<code language='java'>
bindInterceptor(Matchers.subclassesOf(PersistService.class),
Matchers.returns(Matchers.identicalTo(EntityManager.class)),
new EntityManagerTuner()
);
</code>

In an interceptor i'm enabling the desired behavior before returning the
EntityManager

<code language='java'>
public class EntityManagerTuner implements MethodInterceptor {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
Object result = invocation.proceed();
if (result instanceof EntityManagerImpl) {
EntityManagerImpl castedEm = (EntityManagerImpl) result;
((SessionImpl) castedEm.getSession()).setAutoClear(true);
}
return result;
}
}
</code>

Quite rough but works )
Hope this will help.

[google...@googlecode.com]

Comment by alex.che...@gmail.com:

I'm using the following solution for the problem mentioned above (my msg
dated Feb 4, 2012).

I've bound an Interceptor for method returning an EntityManager? in my main
module:
{{{

bindInterceptor(Matchers.subclassesOf(PersistService.class),
Matchers.returns(Matchers.identicalTo(EntityManager.class)),
new EntityManagerTuner()
);
}}}

In an interceptor i'm enabling the desired behavior before returning the
EntityManager

{{{

public class EntityManagerTuner implements MethodInterceptor {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
Object result = invocation.proceed();
if (result instanceof EntityManagerImpl) {
EntityManagerImpl castedEm = (EntityManagerImpl) result;
((SessionImpl) castedEm.getSession()).setAutoClear(true);
}
return result;
}
}
}}}

[google...@googlecode.com]

Comment by xiong.yu...@playfish.com:

"There is the hint "Note that if you make MyService? a @Singleton, then you

should inject Provider<EntityManager> instead." IMHO this not only is true

if MyService? is a @Singleton but also if MyOtherService? is a @Singleton
and is using MyService? which itself is NOT @Singleton."
That's true, it seems that guice get the first generated EntityManager that
bind to Main thread.

[google...@googlecode.com]

Comment by BlueNigh...@gmail.com:

[google...@googlecode.com]

Comment by nigel.ma...@gmail.com:

I think the documentation on this could be very much improved -- I
discovered the exact same things as above.

For users coming from a hibernate background, @Injecting an EntityManager
is akin to a Session. That's fine if the outer object is created when a
session is already in-progress (I.E: the unit-of-work is already active).

However, If it isn't, this is really bad. The session creation starts the
UOW, so the transaction end doesn't close the session. This leads to all
sorts of unexpected issues.

You almost certainly always want to always, always, always use
Provider<EntityManager>. This is the spring-equivalent of injecting your
SessionFactory.

For more information:
https://code.google.com/p/google-guice/wiki/JPA