Hi Ozgur,
Ozgur Balsoy wrote:
>
> Keith,
>
> No problem. It's a huge package, and I don't know of a lot of things in the
> architecture.
Yes...I can imagine the architecture probably takes a while to learn. I
appreciate your initiative in trying to learn it, we can always use more
people who know the code.
>
> My patch solved my problems, but, of course, as the community
> we would appreciate more generalized solutions.
>
I've checked in what I believe is the appropriate patch.
MemberFactory.java and DescriptorSourceFactory.java were ignoring the
namespace of the imported schema.
Hopefully it works for you. It works against the original bug report.
>
> Also, I'll use 'diff -u' next time.
>
Great thanks! I appreciate it!
--Keith
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Keith Visco
> Sent: Tuesday, February 19, 2002 12:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] fix for bug 838
>
> Hi Ozgur,
>
> I believe your patch is incorrect. It appears to fix the problem for
> this specific example, but in reality it doesn't fix the problem and
> actually causes other problems. The descriptors are already being
> checked in the proper order. The XMLFieldDescriptor takes higher
> priority over the ClassDescriptor. The real problem is that the
> generated source code is using the incorrect namespace in the generated
> field descriptor.
>
> Thanks for trying to fix the problem however. I'll see if I can get the
> real fix into the builder package.
>
> I appreciate your continued contributions.
>
> Thanks,
>
> --Keith
>
> Ozgur Balsoy wrote:
> >
> > I have checked this bug with the today's (2/18/02) CVS copy, and it is
> > still there. (http://bugzilla.exolab.org/show_bug.cgi?id=838)
> >
> > I think the problem is the following:
> >
> > In this section (lines 951-956) of Marshaller, there are two
> > descriptors: descriptor and classDesc. The former belongs to the current
> > or parent element while the latter is searched for a child element. The
> > current namespace decision is ill-structured because if the parent
> > element has a namespace defined, this code disregards the child's
> > namespace. It assumes they are the same. However, if the child element
> > is from another namespace it is not reflected here.
> >
> > This is a similar example to the one submitted on the bug report.
> >
> > <?xml version="1.0"?>
> > <x2:TwoThing xmlns:x1="bugtest1" xmlns:x2="bugtest2">
> > <x2:OneThing>HELLO</x2:OneThing>
> > </x2:TwoThing>
> >
> > This is after the patch:
> >
> > <?xml version="1.0"?>
> > <x2:TwoThing xmlns:x1="bugtest1" xmlns:x2="bugtest2">
> > <x1:OneThing>HELLO</x1:OneThing>
> > </x2:TwoThing>
> >
> > The following is my patch for this problem. This problem also exists for
> > unbounded content models because each XXXXItem classes generated by
> > SourceGen assumes that XXXXItem classes are in the same namespace and
> > wrongfully set child elements' namespaces.
> >
> > Ozgur
> >
> > cvs diff Marshaller.java (in directory
> > C:\java\castor\castor\src\main\org\exolab\castor\xml\)
> > Index: Marshaller.java
> > ===================================================================
> > RCS file:
> > /cvs/castor/castor/src/main/org/exolab/castor/xml/Marshaller.java,v
> > retrieving revision 1.93
> > diff -r1.93 Marshaller.java
> > 951,952c951,952
> > < String nsPrefix = descriptor.getNameSpacePrefix();
> > < if (nsPrefix == null) nsPrefix =
> > classDesc.getNameSpacePrefix();
> > ---
> > > String nsPrefix = classDesc.getNameSpacePrefix();
> > > if (nsPrefix == null) nsPrefix =
> > descriptor.getNameSpacePrefix();
> > 954,955c954,955
> > < String nsURI = descriptor.getNameSpaceURI();
> > < if (nsURI == null) nsURI = classDesc.getNameSpaceURI();
> > ---
> > > String nsURI = classDesc.getNameSpaceURI();
> > > if (nsURI == null) nsURI = descriptor.getNameSpaceURI();
> >
> > -----------------------------------------------------------
> > If you wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> > unsubscribe castor-dev
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
