Keith,
Thanks for the try but this is not working, I tested it using the test case I sent in the first mail but I got the same results.
I tried to modify the ClassDescriptorResolverImpl in such a way that, instead of using the class of the object to be marshalled to lookup the class descriptior in the cache, it reloads the class from its name using the class loader of the Mapping and use this one.
This is working until castor tries to access getters of the object. It looks like introspected Method(s) are retreived through the Class object from the Mapping's class loader and cached in the class descriptor but when time comes to invoke them on the object to be marshalled the reflexion framework is shouting because the Method does not belong to the given object's Class (which is true provided the fact that they are neither "==" nor "equals"). Solving this problem would require much work than it seems at first sight...
Anyway I found a workaround: instead of creating a new ClassLoader to be given to the mapping, I use the one held by the Class of the object to be marshalled (which seems an obvious way of doing it, not sure I can continue calling that a workaround but just the right way :-)
Thanks,
Claude
> -----Original Message-----
> From: Keith Visco [mailto:[EMAIL PROTECTED]]
> Sent: 19 November 2002 21:25
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Marshalling, mapping files and class loaders
>
>
>
> Hi Claude,
>
> The Loader can be indirectly set for the Marshaller by doing the
> following:
>
> import org.exolab.castor.xml.util.ClassDescriptorResolverImpl;
>
>
> ClassDescriptorResolverImpl cdr = new ClassDescriptorResolverImpl();
> cdr.setLoader(cl);
> marshaller.setResolver(cdr);
> marshaller.setMapping(mapping);
>
> Note the order for setting the mapping and the resolver. Unfortunately
> it has to be done in this specific order or the mapping will
> be ignored.
>
> I hope that helps, We'll look into comparing classes by fully
> qualified
> name in the future.
>
> --Keith
>
> > Claude Vedovini wrote:
> >
> > Hi Keith,
> >
> > Unfortunately I cannot use the same class loader, the marshaller is
> > implementing a framework API that does not allow passing a class
> > loader.
> >
> > Anyway I can imagine a simpler case where this will not
> work although
> > it should...
> > If we are in an application server and have castor at the server
> > level, if I marshall some objects using a mapping file
> map.xml when I
> > am in the web container (which is in its own class loader) and
> > afterward I do the same in the EJB container (which is in its own
> > class loader), at this moment the mapping file (which is
> cached using
> > its systemId) is already loaded and in a different class loader, and
> > then this should not work?
> >
> > I first thought it may come from using the "==" operator instead of
> > the "equals" to compare classes instances but both return false when
> > the class does not belong to the same class loader, this leads me to
> > think that comparison between classes should be done on the
> class name
> >
> > Claude
> >
> > > -----Original Message-----
> > > From: Keith Visco [mailto:[EMAIL PROTECTED]]
> > > Sent: 18 November 2002 20:30
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [castor-dev] Marshalling, mapping files and class
> > loaders
> > >
> > >
> > >
> > > HI Claude,
> > >
> > > The issue is probably that you are using two separate class
> > > loaders. The
> > > one for the mapping file is different than the one used for
> > > loading your
> > > class, so the classes in the mapping file are different
> than that of
> >
> > > your loaded class, hence why there is no "match" and default
> > > introspection takes place.
> > >
> > > I recommend using the same ClassLoader.
> > >
> > > --Keith
> > >
> > > > Claude Vedovini wrote:
> > > >
> > > > Hi all,
> > > >
> > > > It seems we found here an interesting problem (not to say a bug
> > ;-)
> > > >
> > > > Let's assume I have a jar file, somwhere on my HD called
> > > > marshaller-test.jar where I can find a class named
> > > > "MyMarshallTestClass" and a mapping file called
> > > > "MyTestMappingFile.xml" (there is no packaging but the problem
> > does
> > > > not lie there)
> > > >
> > > > Here is the code for MyMarshallTestClass:
> > > >
> > > > public class MyMarshallTestClass {
> > > > private String name = null;
> > > > private String value = null;
> > > >
> > > > public MyMarshallTestClass(String name,
> String value)
> > {
> > > > this.name = name;
> > > > this.value = value;
> > > > }
> > > >
> > > > public void setName(String name) {
> > > > this.name = name;
> > > > }
> > > >
> > > > public String getName() {
> > > > return name;
> > > > }
> > > >
> > > > public void setValue(String value) {
> > > > this.value = value;
> > > > }
> > > >
> > > > public String getValue() {
> > > > return value;
> > > > }
> > > > }
> > > >
> > > > and the mapping file:
> > > >
> > > > <mapping>
> > > > <class name="MyMarshallTestClass ">
> > > > <map-to xml="marshaller-test"/>
> > > > <field name="name" type="string">
> > > > <bind-xml name="name" node="attribute"/>
> > > > </field>
> > > > <field name="value" type="string">
> > > > <bind-xml name="value" node="attribute"/>
> > > > </field>
> > > > </class>
> > > > </mapping>
> > > >
> > > > Now I have the following code, which I run in order not to have
> > the
> > > > previous marshaller-test.jar in the classpath:
> > > >
> > > > URL jar = new URL("file:marshaller-test.jar");
> > > > ClassLoader cl = new URLClassLoader(new URL[] { jar },
> > > >
> > > > getClass().getClassLoader());
> > > >
> > > > Mapping mapping = new Mapping(cl);
> > > > URL map = cl.getResource("MyTestMappingFile.xml");
> > > > mapping.loadMapping(map);
> > > >
> > > > StringWriter writer = new StringWriter();
> > > > Marshaller marshaller = new Marshaller(writer);
> > > > marshaller.setMapping(mapping);
> > > >
> > > > marshaller.setDebug(true);
> > > >
> > > > ClassLoader cl2 = new URLClassLoader(new URL[] { jar },
> > > >
> > > > getClass().getClassLoader());
> > > >
> > > > Class testClass =
> Class.forName("MyMarshallTestClass", true,
> >
> > > > cl2);
> > > > Constructor cons = testClass.getConstructor(
> > > > new Class[] { String.class,
> > > > String.class });
> > > > Object obj = cons.newInstance(new Object[] { "toto",
> > > "tata" });
> > > >
> > > > marshaller.marshal(obj);
> > > > writer.close();
> > > >
> > > > System.out.println(writer.getBuffer().toString());
> > > >
> > > > And then the outputed XML is:
> > > >
> > > >
> > > >
> > > <my-marshall-test-class><name>toto</name><value>tata</value></
> > > my-marshall-test-class>
> > > >
> > > > (which is the default output when castor is using
> > > introspection) where
> > > > it should be:
> > > >
> > > > <marshaller-test name="toto" value="tata"/>
> > > >
> > > > Please do not ask why I have to do such a strange thing, I
> > > have to...
> > > > In fact, at the origin, the problem arose in a
> application server,
> >
> > > > where some part of our technical framework hosted at the
> > > server level
> > > > is configured with an extra class-path which is used to load the
> > > > mapping files. Some EJBs are passing it some java beans to be
> > > > marshalled but as the EJBs do not even know the beans will be
> > > > marshalled, it cannot load the mapping file by itself.
> > > >
> > > > As a result, the framework (and Castor) are in the server
> > > > class-loader, the mapping in another class-loader which is
> > > a child of
> > > > the latter and the bean instances to marshall stand in their own
> > > > class-loader, which is also child of the server class-loader.
> > > >
> > > > Here is my current big issue and if someone could give
> me an hint
> > I
> > > > would be gratefull :-)
> > > >
> > > > Claude
> > > >
> > > ______________________________________________________________
> > > ____________
> > > >
> > > > � This email and any files transmitted with it are CONFIDENTIAL
> > and
> > > > intended
> > > > solely for the use of the individual or entity to which they are
> > > > addressed.
> > > > � Any unauthorized copying, disclosure, or distribution of the
> > > > material within
> > > > this email is strictly forbidden.
> > > > � Any views or opinions presented within this e-mail are
> > > solely those
> > > > of the
> > > > author and do not necessarily represent those of Odyssey Asset
> > > > Management
> > > > Systems SA unless otherwise specifically stated.
> > > > � An electronic message is not binding on its sender.
> Any message
> >
> > > > referring to
> > > > a binding engagement must be confirmed in writing and
> duly signed.
> >
> > > > � If you have received this email in error, please notify the
> > sender
> > > > immediately
> > > > and delete the original.
> > >
> > > -----------------------------------------------------------
> > > If you wish to unsubscribe from this mailing, send mail to
> > > [EMAIL PROTECTED] with a subject of:
> > > unsubscribe castor-dev
> > >
> >
> ______________________________________________________________
> ____________
> >
> > � This email and any files transmitted with it are CONFIDENTIAL and
> > intended
> > solely for the use of the individual or entity to which they are
> > addressed.
> > � Any unauthorized copying, disclosure, or distribution of the
> > material within
> > this email is strictly forbidden.
> > � Any views or opinions presented within this e-mail are
> solely those
> > of the
> > author and do not necessarily represent those of Odyssey Asset
> > Management
> > Systems SA unless otherwise specifically stated.
> > � An electronic message is not binding on its sender. Any message
> > referring to
> > a binding engagement must be confirmed in writing and duly signed.
> > � If you have received this email in error, please notify the sender
> > immediately
> > and delete the original.
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
__________________________________________________________________________
· This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
· Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
· Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Asset Management
Systems SA unless otherwise specifically stated.
· An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
· If you have received this email in error, please notify the sender immediately
and delete the original.
