I don't have a nice solution for you (at least not yet). I may have an explanation for the warning that you're getting. The javaAccessorNotSet can happen if a JNDI namespace is not available. In this case the JPA code is looking for the Transaction Synchronization Registry in JNDI, but it's not available in your unit test environment. For what it's worth, the lookup in question appears to come from the WebSphere JPA provider, not OpenJPA.
Since you're using generated primary keys you're going to have to get the value from the database before you can detach the entity. That communication with the database will trigger a JNDI lookup, and this message will be logged. For your unit test you can ignore it (unless you want to set up a JNDI namespace for your unit test). I don't think this helps with your serialization / DTO question, but the error message you're getting seems to be benign. -mike On Fri, Jul 29, 2011 at 3:39 AM, M. Walter <[email protected]> wrote: > No there are no exceptions. And enabling openjpa.Log Enhance=TRACE did not > help either. > > But I did some debugging and I could isolate the problem. > When I persist my entities I do a flush and a refresh in order to return > the > entity instance just after the INSERT to the client. This is done because > the client does not have to explicitly call a business entity finder method > again to get the entity with the now set primary key back. So my persist > method does four things: > em.persist(myEntity); > em.flush(); > em.refresh(myEntity); > return myEntity; > > Now it shows that this is the problem. If I remove the flush and refresh > calls the "SEVERE: javaAccessorNotSet" errors disappear in my JUnit tests > but now I get a stale (meaning the entity has the state BEFORE the INSERT - > no primary key is set) entity back. I'm not sure whether this is a good > practice because I do a commit in the middle of the business transaction. > But the RCP client needs the primary key because after saving the data the > client has to execute further business methods which need the primary key. > A > new remote call to the service facade in order to get the whole entity > object tree with all relationships converted to DTOs first, serialized, > shipped over the network and then deserialized again is very costly. But > maybe you have a nice solution for me? :-) > > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/openjpa-Runtime-Unable-to-locate-Transaction-Synchronization-Registry-tp6626607p6632770.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
