Hi!
I'm getting an java.lang.IllegalAccessError when trying to access the fields in
the getInnerCollection method. Is there a workaround for this ?
java.lang.IllegalAccessError: tried to access field
org.hibernate.collection.PersistentBag.bag from class
Since the challenge still exists, here is an even further improved version.
The behaviour is the same, simply some performance improvements were added.
package org.hibernate.collection;
|
| import java.lang.reflect.InvocationTargetException;
| import java.util.Collection;
| import
Some really nice stuff in there, James. I like how you've removed the need for
a base class. I wonder how far we can take this now...
The latest revision of our class is now in package org.hibernate.collection to
take advantage of the internal members of other classes in this package - I see
anonymous wrote : Which got me to thinking. Why, if we're using EJB3 to manage
our POJO Entities, it is acceptable to return an object with Hibernate classes
to the client in the first place? JBoss itself is requiring EJB3 clients to
know Hibernate's involved?! Shouldn't the container be
Looks good, I've made some slight adjustments, will post code later on tonight
regards
James
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3969824#3969824
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3969824
Looking forward to it.
Also crossposted on Hibernate to get input there:
http://forum.hibernate.org/viewtopic.php?t=964452sid=ade6a882a46b1af525a3c4068f298459
One thing to look out for:
new ArrayList();
...not every Collection is a List. We need some more checking in there to
determine if
Thanks, your code works well, I made a few adjustment though to suit my
particular needs.
I think it only makes sense to use this function outside the persistance
session/transaction. This way you can decide how far you wish to traverse the
object graph by populating the data you require
Actually I think a better implementation is that included below;
it should certain perform much better as it now gets the inner hibernate
collection object rather than creating a new object to replicate it.
Note - the package name so we can get the inner collection.
It still needs further
Nice - looking forward to checking it out in more detail tomorrow. :)
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3969927#3969927
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3969927
Yes that's exactly the kind of function and I agree with you it does seem
slightly hacky implementing this ourself, which is why I was surprised to find
there wasn't such a function within Hibernate iteself.
I suppose in a perfect world hibernate could return the clean pojo from
within a
Great; going to play around with this today. Might have to break out some of
those college books about object graph traversal and not getting stuck in
infinite recursion when obtaining circular references within objects...
Really? This hasn't been done before? And if not - there wasn't a
Allright; I've got something. Would love to hear opinions as to whether this
makes for good design, and I'll probably cross-post this somewhere on the
Hibernate forums to get thoughts from there...
Given a static utility method (code all below) that will return a non-Hibernate
Collection of
A note on the code above:
My Base Entity class is called itself PersistedEntity.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3969585#3969585
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3969585
Not sure if I'm necessarily understanding the issue but...
Most times we encounter a LazyInitilizationException when trying to iterate
over relationships outside the scope of the session/transaction; when sent to a
remote client, for example.
In these cases I like to call on a little utility
I'm aware of why LazyInitilizationException's are thrown, and know I could do
something like you demonstrated. My point though is this, as I understand
things DTO's are no longer fashionable in EJB3 and entiy classes are POJO's
which can be populated, then moved between the application tiers.
OK; cool.
Would a function that does the following meet your objectives?
* Obtain all internal members of the POJO via reflection/BeanUtils
* Iterate through 'em
* If the current is of type java.lang.Collection, run my above method on it
(which replaces any Hibernate Collections with a standard
I also need to obtain a completely clean Pojo.
I currently serialise detached entities then send them over a network to a
remote client which is an applet that has no concept of EJB3 (no ejb jars on
classpath). Here the client treats them as Pojos.
When running a full round trip unit test in
...also, this method would ideally return an object that does not use any
hibernate classes such as PersistentSet etc, so the client doesn't require the
hibernate.jars.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3969101#3969101
Reply to the post :
18 matches
Mail list logo
