Skip to main content

[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)

I just wanted to inform you that I switched to GF 2.1.1 and EclipseLink 2.0.0
and the problems mentioned in this thread are magically gone away :).

zebhed wrote:
> "When you say "The application did never deploy", do you mean you cannot
> get the 
> application to deploy at all?  (i.e. There is no set of mappings that
> allow the 
> application to deploy.)  In that case, the issue with LAZY is likely just
> a side 
> effect of something greater."
> I can deploy the application. But I have to change approximately 20
> OneToOne/ManyToOne mappings from FetchType.LAZY to FetchType.EAGER. If
> only one of those 20 mappings has defined FetchType.LAZY the application
> does not deploy.
> "If there is a way you can successfully deploy the 
> application, ideally, you could identify one mapping that when changed
> from 
> EAGER to LAZY causes the failure and post how that mapping is defined."
> I cannot identify one mapping that when changed from EAGER to LAZY causes
> the failure. I have tested every single of these 20 mappings separately by
> changing the FetchType to LAZY. But the application did not deploy. In
> other words, all these 20 mappings require FetchType.EAGER to deploy the
> application. If only one of those mappings has declared FetchType.LAZY the
> application does not deploy. For every single of those 20 mappings that
> have declared FetchType.LAZY instead of EAGER I get the exceptions that I
> have shown in my previous postings. 
> Note: Besides these OneToOne/ManyToOne 20 mappings that absolutely require
> FetchType.EAGER to successfully deploy the application without any
> exceptions there are approximately 10 OneToOne/ManyToOne mappings left
> that have defined FetchType.LAZY. For these 10 mappings I do not have to
> change the FetchType to EAGER to deploy the application successfully and
> without any exceptions.
> Please remember: Originally, every OneToOne/ManyToOne mapping in my
> application had declared FetchType.LAZY and it deployed fine on SJSAS 9.1
> Update 2. But since I switched to SGES 2.1 I get this odd behavior
> described above. EclipseLink version was and is 1.0.2. So (I think) it
> must have something to do with SGES 2.1.
> "- I assume "[...]" is not the actual value for mappedby"
> That is true. It is always the same schema: the name of the entity in
> lowercase letters without any special characters.
> "- Include the cooresponding variable declarations"
> The schema is also always the same. It is "private EntityClass name;".
> Example: "private User user;"
> "- If you are using PROPERTY access, include the cooresponding
> getter/setter 
> declarations"
> These getters and setters are all "standard" getters/setters as NetBeans
> creates them without any additional business logic.
> "- Include the class declaration along with any annotations on the class 
> declaration for all mappings you include"
> I would have to post my whole ERM (lots of code). I do not think it will
> be helpful. Besides, all my entity classes have almost the same schema and
> the same annotations. Here is an example of class "User":
> @Entity
> @Table(name = "users")
> @TableGenerator(table = "_pk_generators", pkColumnName = "_pk",
> valueColumnName = "value", name = "user", initialValue = 1000,
> allocationSize = 100)
> @Cache(type=CacheType.FULL, size = 10000)
> public class User implements Serializable, Comparable<User> {
> 	@Id
> 	@GeneratedValue(strategy = GenerationType.TABLE, generator = "user")
> 	@Column(name = "_id", nullable = false, updatable = false)
> 	private long id;
> 	@Version
> 	private int version;
>         //... some columns here
>         //... some mappings here
>         //... constructor
>         //... "standard" getters/setters 
>         //... overridden methods equals(...), hashCode(), compareTo(...)
> }
> -----
> Currently I am little bit short of time, but I will investigate further.

View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top