Hello,

I'm having a linkage issue that is proving time consuming to track down and
am hoping some of the bright sparks here may be able to give me some
pointers - this may turn out to be something blindingly obvious, or to be
not relevant to Tapestry but some java issue I haven't spotted - I would be
grateful for any observations / ideas.  The issue is:

[ERROR] TapestryModule.RequestExceptionHandler Processing of request failed
with uncaught exception: loader constraints violated when linking
com/x/y/base/IPersistentObjectRef class
java.lang.LinkageError: loader constraints violated when linking
x/y/z/base/IPersistentObjectRef class

... when run against java 1.5x and when run against java 1.6x I get a little
more info:

[ERROR] TapestryModule.RequestExceptionHandler Processing of request failed
with uncaught exception: loader constraint violation: when resolving
interface method
"com.x.y.services.MenuEntityManager.getExistingEntity(Lcom/x/y/base/IPersist
entObjectRef;)Lcom/x/y/entities/menu/Menu;" the class loader (instance of
org/apache/tapestry5/internal/services/ComponentInstantiatorSourceImpl$Packa
geAwareLoader) of the current class, com/x/y/pages/menu/MenuSearchResults,
and the class loader (instance of runjettyrun/ProjectClassLoader) for
resolved class, com/x/y/services/MenuEntityManager, have different Class
objects for the type com/x/y/base/IPersistentObjectRef used in the signature
java.lang.LinkageError: loader constraint violation: when resolving
interface method
"com.x.y.services.MenuEntityManager.getExistingEntity(Lcom/x/y/base/IPersist
entObjectRef;)Lcom/x/y/entities/menu/Menu;" the class loader (instance of
org/apache/tapestry5/internal/services/ComponentInstantiatorSourceImpl$Packa
geAwareLoader) of the current class, com/x/y/pages/menu/MenuSearchResults,
and the class loader (instance of runjettyrun/ProjectClassLoader) for
resolved class, com/x/y/services/MenuEntityManager, have different Class
objects for the type com/x/y/base/IPersistentObjectRef used in the signature


I'm using Tapestry 5.1.0.5 under maven 1.6 Jetty plugin and java 1.5 / 1.6
(for testing).

The package hierarchy is:

com.x.y.abstractclasses
        SuperClass A for persistent classes (contains embeddedID for Hibernate,
PersistentObjectRef p)

com.x.y.base
        PersistentObjectRef
        IPersistentObjectRef

com.x.y.entities
        EntityB extends SuperClass A

com.x.y.pages
        SearchResults
        EditEntity

com.x.y.services
        EntityBManager (search, add, edit methods)

com.x.y.services.impl
        EntityBManagerImpl

The following steps are the sequence of execution:

        1) calling a method within my 'SearchResults' page via
'@OnEvent(component="detailsLink")' from search results grid component

        2) reference String from grid component ActionLink is used to create a 
new
PersistentObjectRef

        3) PersistentObjectRef is then passed into my EntityBManager service to
locate relevant Entity

        4) Relevant Entity is set in subsequent detail Page which is then 
returned
to user


The failure is at step two, where the PersistentObjectRef is created, before
being sent into the service method.  I've tried moving the
PersistentObjectRef to the abstractclasses package, in case Tapestry is
decorating it and causing an issue, but with no success.  The hashcode and
equals methods for the PersistentObjectRef are pretty ordinary, based on a
composite key that is used as a common embedded id for a number of entities.
It is serializable.

I can't figure out why the runjettyrun/ProjectClassLoader has a different
version of the class than the
org/apache/tapestry5/internal/services/ComponentInstantiatorSourceImpl$Packa
geAwareLoader - I've tried using passing around both the concrete class and
the interface without success.  The class is a class that is internal to the
project and no other versions of the class are available on the classpath,
or contained in jarred up resources.

If there is any other relevant information I can provide please let me know.
I can workaround by de/reconstructing keys etc. but think this is something
fundamental I am missing and will probably pop up again.

Regards,
Jim.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to