Re: classloader for JDO classes

[Craig L Russell]

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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: 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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature