Thanks, Mattias. I will follow-up with some comments through the issue. Werner
Mattias Jiderhamn wrote: > http://jira.codehaus.org/browse/CASTOR-2378 > > Werner Guttmann wrote (2008-04-25 10:01): >> Mattias, >> >> can you please open a new Jira issue, attach the files there and I will >> take care of the rest. >> >> Thanks >> Werner >> >> Mattias Jiderhamn wrote: >> >>> Ok, I have a minimized demo now. Seems I cannot attach it to >>> http://jira.codehaus.org/browse/CASTOR-203 since it is closed. >>> I'll try to attach it to this mail, but I guess it will be blocked (or >>> maybe the whole e-mail will be blocked). >>> Should I send it directly to you Werner? >>> >>> /Mattias >>> >>> Mattias Jiderhamn wrote (2008-04-24 09:40): >>> >>>> Werner, sorry I missed this subject coming to life again. >>>> Here is an old JIRA issue with a patch that would solve this for me: >>>> http://jira.codehaus.org/browse/CASTOR-203 >>>> (As I workaround I have basically copied that code) >>>> >>>> I *might* be able to find some time for a test case, or at least parts >>>> thereof. >>>> >>>> /Mattias >>>> >>>> >>>> Werner Guttmann wrote (2008-04-23 21:52): >>>> >>>>> Hi Godmar, >>>>> >>>>> provide a new unmarshal(AnyNode) method that would automate part of >>>>> that >>>>> business you are doing yourself, i.e. use a StringWriter et alias. Far >>>>> from perfect, still a long way to go .... but a first step. >>>>> >>>>> You could then 'introspect' the AnyNode, set the root class on the >>>>> Unmarshaller (using setClass(Class), and call unmarshal(AnyNode). >>>>> >>>>> Werner >>>>> >>>>> Godmar Back wrote: >>>>> >>>>> >>>>>> This is not really a request for time or resources - you work on >>>>>> Castor at whatever pace you feel comfortable - this is a technical >>>>>> comment only. >>>>>> >>>>>> If you consider my proposal as a step 2 to be taken after step 1, >>>>>> then >>>>>> I'm not sure I understand what you have in mind for step 1 is. I note >>>>>> that Castor as is unmarshals to AnyNodes, and that I can easily >>>>>> marshal an AnyNode into a StringWriter, and unmarshal manually to the >>>>>> target name space's binding (provided I know which one it is.) That >>>>>> part works. >>>>>> >>>>>> Can you clarify what you mean by "unmarshalling from AnyNode?" >>>>>> >>>>>> - Godmar >>>>>> >>>>>> On Tue, Apr 22, 2008 at 2:03 PM, Werner Guttmann >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> Godmar, >>>>>>> >>>>>>> I hear what you are trying to say, but I'd introduce such features >>>>>>> step >>>>>>> by step. In other words, yes, I'd like to head for a more advanced >>>>>>> solution as well, but let's introduce basic features as well .... >>>>>>> >>>>>>> It's basically trying to manage the time I have at hands as >>>>>>> well. I'd >>>>>>> like to spend 20+ hours a week on Castor, but unless somebody >>>>>>> makes some >>>>>>> cash available to me in one way or the other, I have to earn a >>>>>>> living as >>>>>>> well. >>>>>>> >>>>>>> Bye >>>>>>> Werner >>>>>>> >>>>>>> >>>>>>> >>>>>>> Godmar Back wrote: >>>>>>> > Are you thinking of the issue discussed in >>>>>>> > >>>>>>> http://www.mail-archive.com/[email protected]/msg05901.html ? >>>>>>> > >>>>>>> > If so, let me point out that to handle the case in which XML >>>>>>> described >>>>>>> > by schema B is embedded in an <xs:any> location occurring in >>>>>>> schema A, >>>>>>> > I would much rather not "see" an AnyNode at all. That is, I >>>>>>> don't want >>>>>>> > to have to invoke marshal/unmarshal if Castor can infer what >>>>>>> > marshaling and unmarshaling needs to be done ----- it would be >>>>>>> even >>>>>>> > better if it could avoid any unnecessary unmarshaling in the >>>>>>> first >>>>>>> > place. >>>>>>> > >>>>>>> > I believe that the correct unmarshaling strategy can be inferred >>>>>>> from >>>>>>> > the namespace used for the element. For instance, if an element >>>>>>> that >>>>>>> > occurs in a ##any position is, in a concrete XML document: >>>>>>> > >>>>>>> > <larger document> ..... >>>>>>> > <ad:aboutData >>>>>>> > xmlns:ad="info:rfa/rfaRegistry/xmlSchemas/Institutions/aboutData" >>>>>>> > .... >>>>>>> > .... >>>>>>> > >>>>>>> > then castor should use the "info:rfa/...." name space to >>>>>>> unmarshal >>>>>>> > this part of the document. >>>>>>> > >>>>>>> > To accomplish the correct unmarshalig, Castor would at runtime >>>>>>> need >>>>>>> > access to a set of mappings between XML name spaces and Java >>>>>>> classes >>>>>>> > --- I do not know if Castor already has this ability, but I >>>>>>> wouldn't >>>>>>> > be surprised if it did. >>>>>>> > >>>>>>> > Implementation wise, I'd expect that whenever I run >>>>>>> > "org.exolab.castor.builder.SourceGenerator" on a schema, an entry >>>>>>> > should be added that associates the targetNamespace of the >>>>>>> schema with >>>>>>> > the Java classes created. In the example above, suppose I run >>>>>>> > SourceGenerator on a schema "aboutData.xsd" which contains: >>>>>>> > >>>>>>> > <xs:schema >>>>>>> targetNamespace="info:rfa/rfaRegistry/xmlSchemas/Institutions/aboutData" >>>>>>> >>>>>>> >>>>>>> > ..... > >>>>>>> > >>>>>>> > then I'd expect that instance of the Java classes generated by >>>>>>> this >>>>>>> > schema will show up when I unmarshal a document that contains the >>>>>>> > "ad:aboutData" mentioned above, without me having to do anything. >>>>>>> > >>>>>>> > - Godmar >>>>>>> > >>>>>>> > On Tue, Apr 22, 2008 at 1:15 PM, Werner Guttmann >>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>> >> Hi, >>>>>>> >> >>>>>>> >> as there have been some requests recently to support >>>>>>> unmarshalling from >>>>>>> >> an AnyNode instance, I have started working on this. Can I >>>>>>> please ask >>>>>>> >> anybody to supply me with one or more test cases that allowed >>>>>>> me to >>>>>>> >> think and code against a contract. >>>>>>> >> >>>>>>> >> And if there is no Jira issue, feel free to add a new one >>>>>>> (marked as >>>>>>> >> feature request) or point me to an existing one. >>>>>>> >> >>>>>>> >> Regards >>>>>>> >> Werner >>>>>>> >> >>>>>>> >> PS Yes, I could equally build this myself, but I'd rather >>>>>>> spend the time >>>>>>> >> trying to help you as much as possible, and reuse your time an >>>>>>> knowledge >>>>>>> >> as much asp possible. >>>>>>> > > > --------------------------------------------------------------------- > 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
