Hi Mohnish, That's what I thought/hoped it would be. Thanks for letting us know.
Regards Werner mohn3310 wrote: > Hi guys, > > It looks like this was an osgi specific issue. I had two bundles; one of > which was using castor to persist objects handed to it by the other. It > turns out the bundle using castor did not include an import of the package > the object it was handed resided in. Adding that seemed to do the trick. > > I'm still trying to figure this out exactly. Why were there no errors when > the import was missing. It just failed silently. > > Thanks for your help. > > Mohnish > > > Werner Guttmann wrote: >> Hi Joachim, >> >> Joachim Grüneis wrote: >>> Hello, >>> I try to help you with some hints... but to be more precise >>> I have not enough information >>> >>> It seams that you use the static methods of marshaller and unmarshaller - >> But that's exactly what he user is looking for. All he wants to use is >> introspection mode, soo usage of the static methods is just fine. >> >>> this often leads to problems as no configuration step takes place which >>> e.g. >>> would load the mapping information... >>> >>> so please instantiate an XMLContext, introduce the classes to map by >>> using >>> addClass or loadMapping, create marshaller and unmarshaller instance and >>> work with this instance - that might already solve your problem >> Well, it might be still owrth it to try this, even though there's no >> mapping information to be loaded. >> >>> on the other >>> hand you might have a problem caused by class loading mechanisms of felix >>> (OSGi) >>> marshaling takes existing Java >>> objects instances and serializes them into XML - no problem there, all >>> Java classes are known and can easily be >>> marshaled to XML without any mapping information... >>> the other way round is more complicated >>> Caster has to find a corresponding class for each element found in the >>> XML >>> and needs to be able to >>> instantiate this class - this is where two problems might occur: >>> 1) no matching class can be found, mapping information is not >>> available cause static methods are used so nothing is unmarshalled >>> 2) no matching class can be found because Castor is not allowed to >>> access these classes because they are bound to a different class >>> loader >>> >>> These are just some ideas of what might have happend... >>> >>> to really help it is required to know more about your implementation: >>> Is an XSD definition existing? >> No, I guess. >>> Has the Java code been generated using code generator? >> No, I guess. >>> Have you included the .cdr files into the jar? >> Well, no classes have been generated. >> >>> Do you use a mapping file? >> No, as introspection mode is used. >> >>> How does the marshaling/unmarshaling code look like? >>> Hth Joachim >>> >>> 2009/6/24 mohn3310 <[email protected]> >>> >>>> Hello, >>>> >>>> I'm using castor-xml in introspection mode to write out simple POJOs to >>>> files (one POJO per file). I've written unit tests and verified that >>>> this >>>> works. I've also inspected the files and made sure they have appropriate >>>> xml. >>>> >>>> I then packaged this up into an osgi bundle and deployed it to a >>>> container >>>> (felix). For some reason when I run it, it ends up creating the file but >>>> it >>>> is empty... i.e. no xml in the file. Yet another strange thing is that I >>>> use >>>> Unmarshaller.unmarshall() to convert the xml files back to their >>>> associated >>>> POJOs. As a test I generated the xml by hand and it was able to load it. >>>> So >>>> Marshaller.marshall() doesn't work, but Unmarshaller.unmarshall() does! >>>> >>>> Any idea why it is behaving this way? Same code... works great >>>> "normally", >>>> but doesn't work inside an osgi container. >>>> >>>> Thanks, >>>> Mohnish >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/castor-xml-writing-empty-file-tp24175804p24175804.html >>>> Sent from the Castor - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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
