Hi Erik,

If your Employee is loaded by classloader 1 and your implementation is loaded by classloader 2 then the implementation won't work using the standard JDO 2 binary compatible contracts.

Your implementation implements cl2.StateManager but the Employee expects cl1.StateManager. I don't see how it can work.

Craig

On Jan 11, 2006, at 1:27 AM, erik@jpox.org wrote:

Craig,

We can make it work easily. We are able to verify by class name the interfaces
implemented, but I wonder if there is some security restriction on that.

Regards,

Erik Bengtson

Quoting Craig L Russell <Craig.Russell@Sun.COM>:

Hi Erik,

No, this is not ok.

The problem is for example when the application calls
pm.makePersistent(employee). If the jdoimpl does a check (if (! o
instanceof PersistenceCapable) throw JDOUserException("Object was not
enhanced");) then the different classes will be an issue. The
PersistenceCapable in the 2nd jar is not the same class as in the 1st
jar even though they have the same name.

Have you tried it?

Craig

On Jan 10, 2006, at 4:09 PM, erik@jpox.org wrote:



Hi,

An app has two classloaders, the 1st with jdoimpl.jar+jdo2.jar and
the 2nd with
persistent classes +jdo2.jar.

The PCclass links to jdo2.jar(2) and the jdoImpl links to jdo2.jar
(1). I guess
that's ok, right? In any case, it may worth mentioning that in the
spec.

Regards,

Erik Bengtson

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!






Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!