Jeff Norris wrote:
>
> Keith and Arnaud,
>
> Thank you very much for your help on this. Fortunately, since you guys built
> Castor to accept a custom classloader (a good design choice),
I knew that design decision would come in handy some day :-)
>the workaround for
> this problem is actually very simple. All that has to be done is as follows.
> If you have installed Castor as a java extension and want to use xsi:type
> attributes, then instead of calling the unmarshal method created by the
> SourceGenerator like this...
>
> Root root = Root.unmarshalRoot(reader);
>
> You just have to build the Unmarshaller yourself and give it a more suitable
> classloader, like this:
>
> Unmarshaller unm = new Unmarshaller(Root.class,
> Root.class.getClassLoader());
> Root root = (Root) unm.unmarshal(reader);
>
> You can pass in a classloader from any class NOT installed as an extension or
> ClassLoader.getSystemClassLoader(). Note that this workaround does not require
> Java 1.2.
>
> This is not a tough workaround, although it should probably be documented
> somewhere.
Yes, we should document it in a FAQ...Hey Arnaud, can you add this to
your FAQ? :-)
> FYI, if you ever wanted to fix this permanently for all users, you'd
> need to make a change in the SourceGenerator or Unmarshaller.java so that Castor
> tries to use the classloader of the class being unmarshalled when no custom
> classloader is present instead of resorting to the extclassloader, which is what
> you get when you call Class.forName() from an installed extension. Note that
> this should have zero impact on existing users of Castor because of how the Java
> classloaders work. Again, the details are all in this whitepaper...
>
> http://www.javageeks.com/Papers/ClassForName/ClassForName.pdf
>
> ... but basically, if you use the classloader of the class being unmarshalled,
> it will FIRST give the extclassloader an opportunity to find the class. Only if
> it fails does the classloader of the class being unmarshalled get a chance to
> find the class. Basically, this is equivalent to calling Class.forName and if
> this fails, trying to load the class with the classloader of the class being
> unmarshalled (but it takes less code!) This change doesn't require Java 1.2,
> and should not negatively impact any Java 1.1 users. I haven't spent much time
> in the Castor code so I'm not sure exactly where you guys would like to make
> such a change, and again it's not a tough workaround, so I'll leave it with you
> guys at that.
Well we need to be careful...because Class#getClassLoader seems to
always return null in JDK 1.1 (or at least whenever I try to go it)
However...we can probably provide some built in workarounds.
Never-the-less, I am glad that you found a current workaround until we
have a chance to provide a built in one.
>
> Keith- thank you *very* much for the modification you checked into the CVS
> regarding the use of schema names in xsi:type instead of the "java:" tagged
> names. I just checked it out and everything is working perfectly now.
>
Great! I knew it was working here, but I wanted to make sure it would
work in your environment.
Thanks,
--Keith
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
