Ugh. It took quite a while to figure this out, mostly because I'm just an old C
developer and not a Database/Java/WebServices/SOAP/JAX/BlahBlahBlah person. But after
actually considering switching to Glassfish just to solve this last problem (but deciding
it wasn't necessarily any easier to understand), I sat back down and thought through
what I new was the problem.
Hibernate generates the EJB classes from my existing MySQL db. If any tables in the db
have Foreign Keys defined, Hibernate will produce the set/get methods with the OneToMany
annotations. These methods cannot be converted to XML (by whatever internal mechanisms
are doing that) because they cause infinitely deep XML to be produced.
The way out of this trap is to drop the use of Foreign Keys in my database. As far as I
can tell, the only drawback to this is that my own code will need to check to guarantee
data integrity between the old foreign key and it's associated table field - in other
words, I need to make sure the other table has an entry with the specified value before
adding a new entry to the table that was originally configured with the foreign key
reference.
So I pulled out the foreign keys from my test db and sure enough, I'm now able to pull
a row from the db via the Web Services interface and return it to the remote client as a
class object. This is exactly what my old EJB2.1/JBOSS 4.0.5GA/Middlegen based setup used
to do. Now I can do it (sans foreign keys) with EJB3.0/JBOSS 4.2.2GA/Hibernate.
Whew. That was a painful month. Here's hopin' it gets easier from here on out.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4118456#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...