[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] OneToOne AND ManyToOne Mapping works with FetchType.EAGER but not with FetchType.LAZY -> Exception when deploying (SGES 2.1)
|
The fact that isolating the LAZY mappings avoids the failure tells me that the
problem lies somewhere else in the way your persistence unit is defined.
Earlier, you mentioned you were getting some exceptions during deployment.
There is a good chance it is those exceptions that are causing the issues for you.
If you have not done so already, set logging to FINEST and enable exception
logging by setting the following properties in your persistence.xml.
eclipselink.logging.level=FINEST
eclipselink.logging.exceptions=true
The goal is to find the exceptions that occur during your deployment and
identify why they occur.
-Tom
zebhed wrote:
Sorry, I do not understand what I should look for. Can you be a little bit
more specific please?
My model classes are only available in my application (the EAR file),
nowhere else.
I have tried to get a test case, but it seems it isn´t that simple.
For example:
In my application I have 2 entities A and B that are completely isolated
from all other entities. There is just a OneToOne mapping from entity A to
entity B. There are no additional relationships from or to other entities.
In my application, this OneToOne mapping from A to B requires
FetchType.EAGER to deploy without the exceptions I have already shown.
So, I copied these two entities A and B to a new EJB module and deployed
that module. The module deploys fine, no matter if I chose EAGER or LAZY.
This was not my only test. I have isolated many problematic entites and
their mappings by copying them into a new EJB module. The module always
deployed fine, no matter if I chose EAGER or LAZY.
So, my application as a whole seems to be affected. But this, as I already
said, is only the case when I try to deploy on SGES 2.1. On SJSAS 9.1 Upd 2
my application deploys fine without any exceptions.
