I think I've experienced the same behaviour (that drove me craze for two
weeks).
My problem description:
http://forums.java.net/jive/thread.jspa?messageID=272498
(just to check it is the same issue)
I "found a workaround"/"solved" putting each EJB in a different package.
Hope this can help.
> Folks,
>
> having a _rather_ strange error to deal with, right now. Project structure
> see the NetBeans screenshot attached, basically it boils down to having
>
> - three different entity classes (extending a common base class), each one
> of them persisted using JPA,
>
> - three stateless session beans (auto-generated) to access these classes
> using the JPA entity manager,
>
> - the "find(String id)" method of each of these EJBs exposed via @WebMethod
> annotation as JAX-WS web services.
>
>
>
> Deploying this to GFv2u2 in our test system, the phenomenon is like this:
>
> - The first of the three web services invoked using the "Test" button from
> within the GF Admin Console works flawlessly, returning the result expected
> while providing a valid ID for "find".
>
> - By then, the two other web services reproducibly fail dumping an
> exception like this:
>
> [...]
> [#|2008-08-06T09:27:53.311+0200|SEVERE|sun-appserver9.1|com.sun.xml.ws.serv
>er.sei.EndpointMethodHandler|_ThreadID=126;_ThreadName=httpSSLWorkerThread-8
>082-0; _RequestID=98ddd859-6b6f-4b56-af00-8390bb31013d;|Can not set
> de.planconnect.lib.persistence.entities.RPartner field
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> de.planconnect.lib.persistence.access.jax
> ws.FindResponse._return to
> de.planconnect.lib.persistence.entities.APlanDocument
> java.lang.IllegalArgumentException: Can not set
> de.planconnect.lib.persistence.entities.RPartner field
> de.planconnect.lib.persistence.access.jaxws.FindRespon
> se._return to de.planconnect.lib.persistence.entities.APlanDocument
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unsafe
>FieldAccessorImpl.java:146) [...]
>
>
> - More surprisingly, the marked entity that "Can not set" (RPartner, in
> this example) is the entity to be accessed / returned by the first web
> service invoked, the one that used to work. This entirely depends upon
> which of these web services is to be invoked for the first time after
> completely undeploying and redeploying the application.
>
>
> Overally, it definitely seems a web-service related issue as, building a
> JAX-WS web service using a Facade EJB to include access methods referencing
> the three other EJBs, access to each entity works as expected. What on
> earth is wrong here? Glassfish issue? Web service stack problem? Sort of
> reminds me of the behaviour I reported earlier while dealing with NetBeans
> [1] though it is different in some cases, this time happening in the server
> not on the client. Could this be issue [2]? Or something unrelated?
>
> Cheers & thanks,
> Kristian
>
>
> [1] https://jax-ws.dev.java.net/issues/show_bug.cgi?id=504
> [2] https://glassfish.dev.java.net/issues/show_bug.cgi?id=4267