Ralf, there's a test case in SVN trunk that checks the correct working of both XMLContext and (XML)ClassDescriptorResolver. And - apart from an issue that has been fixed breifly after the 1.2 release - this test has been working all time.
What is the problem you are seeing, if I may ask ? Werner Ralf Joachim wrote: > Werner, > > try to use the XMLClassDescriptorResolver yourself first. According to > my experience this doesn't work any more since the introduction of > XMLContext. I had to change all my marshaling code to fix that after > upgrade to 1.2. > > Regards > Ralf > > > Werner Guttmann schrieb: >> Hi, >> >> how about trying things with the XMLClassDescriptorResolver document >> first, to get and/or keep you going. >> >> Have a look at the XML best practise document at http://www.castor.org, >> and let us know whether this is enough information. >> >> Werner >> >> brandywheat wrote: >>> Hi, >>> I do not have enough experience with castor (yet) to see either method >>> being beneficial over the other ... so I will take what ever you suggest. >>> Working from the snapshot is not an issue, nor is waiting a couple of days >>> a problem - what ever is best for you - I'll be happy when it is working! >>> >>> I do have a couple of class to marshal and these include quite a few >>> classes (30+) which are included in the output structure - I am not sure if >>> this would be an issue with option b (do I have to add a >>> classDescriptionResolver for each class ?). >>> >>> Many, many thanks for the super response on this, I am suitably impressed >>> :-) >>> >>> Thanks, >>> Brian >>> >>> >>> >>> Werner Guttmann wrote: >>>> Well, in that case, there's two options: >>>> >>>> a) switch to XMLContext (where we'd have to add a setClassLoader() >>>> method, which is sufficiently easy; if you are fine working against a >>>> snapshot releaswe, this could be done within one or two days). >>>> >>>> b) Set an XMLClassDescriptorResolver on your Marshaller, and use >>>> XMLClassDescriptorResolver.setClassLoader() to set a custom class loader. >>>> >>>> Does this make sense ... >>>> >>>> Werner >>>> >>>> >>>> brandywheat wrote: >>>>> Hi, >>>>> I'm on the latest castor version (1.2) ... >>>>> >>>>> Thanks, >>>>> Brian >>>>> >>>>> >>>>> >>>>> Werner Guttmann wrote: >>>>>> Hi, >>>>>> >>>>>> What version of Castor are you using ? There's a solution to this >>>>>> problem, but it depends on whether you are on a release that has support >>>>>> for XMLContext already (or not). >>>>>> >>>>>> Werner >>>>>> >>>>>> brandywheat wrote: >>>>>>> Hi, >>>>>>> I am currently having problems with the castor marshaller and >>>>>>> classloaders. >>>>>>> My code works in the unit tests but fails once included in a netbeans >>>>>>> RPC - >>>>>>> the problem looks to be the classloader and the modules within the RPC. >>>>>>> >>>>>>> I can resolve the issue of the classloader with the code: >>>>>>> Marshaller m = new Marshaller(); >>>>>>> Mapping mapping = new >>>>>>> Mapping(Thread.currentThread().getContextClassLoader()); >>>>>>> mapping.loadMapping("c:\\temp\\mapping.xml"); >>>>>>> m.setMapping(mapping); >>>>>>> m.marshal(this, writer); >>>>>>> >>>>>>> But this forces me to write a mapping file, which I do not have >>>>>>> available >>>>>>> and do not really want to generate. >>>>>>> >>>>>>> Is it possible to set the classloader for the marshaller without >>>>>>> having >>>>>>> to >>>>>>> define a mapping file, e.g. have it use the default structure it would >>>>>>> generated without a mapping file? (If I skip the loadMapping then the >>>>>>> setMapping gives an exception saying a mapping must be loaded >>>>>>> first....) >>>>>>> >>>>>>> Thanks in Advance, >>>>>>> Brian >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe from this list, please visit: >>>>>> >>>>>> http://xircles.codehaus.org/manage_email >>>>>> >>>>>> >>>>>> >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>>> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
