You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Frank Budinsky <fr...@ca.ibm.com> on 2006/03/22 23:55:30 UTC
new XSD to SDO mapping
I just committed a change to the SDO XSDHelper.define() method which
changes the behavior significantly. It used to mangle names (using EMF's
mangling algorithm) and it didn't map simple types (like xsd:int) to the
proper SDO Types as specified in the SDO 2 spec.
With this change, many of the sca schemas no longer generated valid Java
classes. For example things like <element name="binding.java" ...> now
produces a get method named getBinding.java(), which doesn't compile
because of the "." character. Don't blame me, that's what the SDO spec
says it should do :-)
The solution is to add sdo annotations (e.g., sdo:name="bindingJava") in
the schema with the bad names. I fixed all of the existing places with
this problem ... seemed like hundreds of them :-) ... so everything is
still working. Please beware of this issue, though, when adding new
schemas.
Longer term, we might want to think about adding some mangling to the
Tuscany SDO generator as an option (value-add feature).
Frank.
Re: new XSD to SDO mapping
Posted by Daniel Kulp <da...@iona.com>.
It's definitely due to improper/non-existent teardowns and the
ContextClassloader. I'll have a patch ready shortly.
For everyones information, do NOT ever do:
Setup:
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
Teardown:
Thread.currentThread().setContextClassLoader(null);
That is wrong. The original classloader may not be null. Thus, after
the teardown, the VM is not back to it's original state. You need to do
something like:
Setup:
origLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
Teardown:
Thread.currentThread().setContextClassLoader(origLoader);
Enjoy!
Dan
On Thursday 23 March 2006 09:46, Daniel Kulp wrote:
> Ick... OK. Another set of tests that only fail on my machine.
> (like the rhino ones)
>
> I just did a fresh checkout into a completely new directory, deleted my
> ~/.m2/repository dir, and rebuilt and I'm still seeing the failures.
> Probably some more teardown methods that need to be implemented to
> reset things back to pre-test state. I'll investigate more.
>
> Thanks for confirming. I really wonder what it is with my machine
> that is exposing these problem. Is anyone else using JDK 1.5.0_06 on
> Linux? I'm using ext3 filesystem which I expect everyone else is using
> as well.
>
> Dan
>
> On Thursday 23 March 2006 09:04, ant elder wrote:
> > svn st and svn up say I'm current and mvn clean, mvn for
> > container.java are successful for me.
> >
> > ...ant
> >
> > On 3/23/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
> > > Hi Dan,
> > >
> > > Are the container.java tests run as part of "mvn" from the root? I
> > > can run "mvn clean" and then "mvn" from the tuscany/java directory
> > > and everything works fine for me.
> > >
> > > Could somebody else please confirm that they are also having
> > > problems like Dan?
> > >
> > > Thanks,
> > > Frank.
> > >
> > >
> > >
> > >
> > > Daniel Kulp <da...@iona.com>
> > > 03/22/2006 10:57 PM
> > > Please respond to
> > > tuscany-dev
> > >
> > >
> > > To
> > > tuscany-dev@ws.apache.org
> > > cc
> > > Frank Budinsky/Toronto/IBM@IBMCA
> > > Subject
> > > Re: new XSD to SDO mapping
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Frank,
> > >
> > > This commit seams to have REALLY broken the sca builds. The
> > > container.java tests are failing pretty badly. Are you (or
> > > someone else) working on fixing them?
> > >
> > > For now, I'm going to revert my SDO dir to -r 387955.
> > >
> > > Thanks!
> > > Dan
> > >
> > > On Wednesday 22 March 2006 17:55, Frank Budinsky wrote:
> > > > I just committed a change to the SDO XSDHelper.define() method
> > > > which changes the behavior significantly. It used to mangle names
> > > > (using EMF's mangling algorithm) and it didn't map simple types
> > > > (like xsd:int) to the proper SDO Types as specified in the SDO 2
> > > > spec.
> > > >
> > > > With this change, many of the sca schemas no longer generated
> > > > valid Java classes. For example things like <element
> > > > name="binding.java" ...> now produces a get method named
> > > > getBinding.java(), which doesn't compile because of the "."
> > > > character. Don't blame me, that's what the SDO spec says it
> > > > should do :-)
> > > >
> > > > The solution is to add sdo annotations (e.g.,
> > > > sdo:name="bindingJava") in the schema with the bad names. I fixed
> > > > all of the existing places with this problem ... seemed like
> > > > hundreds of them :-) ... so everything is still working. Please
> > > > beware of this issue, though, when adding new schemas.
> > > >
> > > > Longer term, we might want to think about adding some mangling to
> > > > the Tuscany SDO generator as an option (value-add feature).
> > > >
> > > > Frank.
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727 C: 508-380-7194
> > > daniel.kulp@iona.com
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: new XSD to SDO mapping
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Daniel Kulp wrote:
> Ick... OK. Another set of tests that only fail on my machine. (like
> the rhino ones)
>
> I just did a fresh checkout into a completely new directory, deleted my
> ~/.m2/repository dir, and rebuilt and I'm still seeing the failures.
> Probably some more teardown methods that need to be implemented to reset
> things back to pre-test state. I'll investigate more.
>
> Thanks for confirming. I really wonder what it is with my machine that
> is exposing these problem. Is anyone else using JDK 1.5.0_06 on Linux?
> I'm using ext3 filesystem which I expect everyone else is using as well.
>
> Dan
>
>
> On Thursday 23 March 2006 09:04, ant elder wrote:
>
>> svn st and svn up say I'm current and mvn clean, mvn for container.java
>> are successful for me.
>>
>> ...ant
>>
>> On 3/23/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
>>
>>> Hi Dan,
>>>
>>> Are the container.java tests run as part of "mvn" from the root? I
>>> can run "mvn clean" and then "mvn" from the tuscany/java directory
>>> and everything works fine for me.
>>>
>>> Could somebody else please confirm that they are also having problems
>>> like Dan?
>>>
>>> Thanks,
>>> Frank.
>>>
>>>
>>>
>>>
>>> Daniel Kulp <da...@iona.com>
>>> 03/22/2006 10:57 PM
>>> Please respond to
>>> tuscany-dev
>>>
>>>
>>> To
>>> tuscany-dev@ws.apache.org
>>> cc
>>> Frank Budinsky/Toronto/IBM@IBMCA
>>> Subject
>>> Re: new XSD to SDO mapping
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Frank,
>>>
>>> This commit seams to have REALLY broken the sca builds. The
>>> container.java tests are failing pretty badly. Are you (or someone
>>> else) working on fixing them?
>>>
>>> For now, I'm going to revert my SDO dir to -r 387955.
>>>
>>> Thanks!
>>> Dan
>>>
>>> On Wednesday 22 March 2006 17:55, Frank Budinsky wrote:
>>>
>>>> I just committed a change to the SDO XSDHelper.define() method
>>>> which changes the behavior significantly. It used to mangle names
>>>> (using EMF's mangling algorithm) and it didn't map simple types
>>>> (like xsd:int) to the proper SDO Types as specified in the SDO 2
>>>> spec.
>>>>
>>>> With this change, many of the sca schemas no longer generated valid
>>>> Java classes. For example things like <element name="binding.java"
>>>> ...> now produces a get method named getBinding.java(), which
>>>> doesn't compile because of the "." character. Don't blame me,
>>>> that's what the SDO spec says it should do :-)
>>>>
>>>> The solution is to add sdo annotations (e.g.,
>>>> sdo:name="bindingJava") in the schema with the bad names. I fixed
>>>> all of the existing places with this problem ... seemed like
>>>> hundreds of them :-) ... so everything is still working. Please
>>>> beware of this issue, though, when adding new schemas.
>>>>
>>>> Longer term, we might want to think about adding some mangling to
>>>> the Tuscany SDO generator as an option (value-add feature).
>>>>
>>>> Frank.
>>>>
>>> --
>>> J. Daniel Kulp
>>> Principal Engineer
>>> IONA
>>> P: 781-902-8727 C: 508-380-7194
>>> daniel.kulp@iona.com
>>>
>
>
Dan,
I'm running Linux as well but JDK 1.5.0_05. I'll update to 1.5.0_06
later today and will let you know if I run into the same issues.
--
Jean-Sebastien
Re: new XSD to SDO mapping
Posted by Daniel Kulp <da...@iona.com>.
Ick... OK. Another set of tests that only fail on my machine. (like
the rhino ones)
I just did a fresh checkout into a completely new directory, deleted my
~/.m2/repository dir, and rebuilt and I'm still seeing the failures.
Probably some more teardown methods that need to be implemented to reset
things back to pre-test state. I'll investigate more.
Thanks for confirming. I really wonder what it is with my machine that
is exposing these problem. Is anyone else using JDK 1.5.0_06 on Linux?
I'm using ext3 filesystem which I expect everyone else is using as well.
Dan
On Thursday 23 March 2006 09:04, ant elder wrote:
> svn st and svn up say I'm current and mvn clean, mvn for container.java
> are successful for me.
>
> ...ant
>
> On 3/23/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
> > Hi Dan,
> >
> > Are the container.java tests run as part of "mvn" from the root? I
> > can run "mvn clean" and then "mvn" from the tuscany/java directory
> > and everything works fine for me.
> >
> > Could somebody else please confirm that they are also having problems
> > like Dan?
> >
> > Thanks,
> > Frank.
> >
> >
> >
> >
> > Daniel Kulp <da...@iona.com>
> > 03/22/2006 10:57 PM
> > Please respond to
> > tuscany-dev
> >
> >
> > To
> > tuscany-dev@ws.apache.org
> > cc
> > Frank Budinsky/Toronto/IBM@IBMCA
> > Subject
> > Re: new XSD to SDO mapping
> >
> >
> >
> >
> >
> >
> >
> > Frank,
> >
> > This commit seams to have REALLY broken the sca builds. The
> > container.java tests are failing pretty badly. Are you (or someone
> > else) working on fixing them?
> >
> > For now, I'm going to revert my SDO dir to -r 387955.
> >
> > Thanks!
> > Dan
> >
> > On Wednesday 22 March 2006 17:55, Frank Budinsky wrote:
> > > I just committed a change to the SDO XSDHelper.define() method
> > > which changes the behavior significantly. It used to mangle names
> > > (using EMF's mangling algorithm) and it didn't map simple types
> > > (like xsd:int) to the proper SDO Types as specified in the SDO 2
> > > spec.
> > >
> > > With this change, many of the sca schemas no longer generated valid
> > > Java classes. For example things like <element name="binding.java"
> > > ...> now produces a get method named getBinding.java(), which
> > > doesn't compile because of the "." character. Don't blame me,
> > > that's what the SDO spec says it should do :-)
> > >
> > > The solution is to add sdo annotations (e.g.,
> > > sdo:name="bindingJava") in the schema with the bad names. I fixed
> > > all of the existing places with this problem ... seemed like
> > > hundreds of them :-) ... so everything is still working. Please
> > > beware of this issue, though, when adding new schemas.
> > >
> > > Longer term, we might want to think about adding some mangling to
> > > the Tuscany SDO generator as an option (value-add feature).
> > >
> > > Frank.
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: new XSD to SDO mapping
Posted by ant elder <an...@gmail.com>.
svn st and svn up say I'm current and mvn clean, mvn for container.java are
successful for me.
...ant
On 3/23/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> Hi Dan,
>
> Are the container.java tests run as part of "mvn" from the root? I can run
> "mvn clean" and then "mvn" from the tuscany/java directory and everything
> works fine for me.
>
> Could somebody else please confirm that they are also having problems like
> Dan?
>
> Thanks,
> Frank.
>
>
>
>
> Daniel Kulp <da...@iona.com>
> 03/22/2006 10:57 PM
> Please respond to
> tuscany-dev
>
>
> To
> tuscany-dev@ws.apache.org
> cc
> Frank Budinsky/Toronto/IBM@IBMCA
> Subject
> Re: new XSD to SDO mapping
>
>
>
>
>
>
>
> Frank,
>
> This commit seams to have REALLY broken the sca builds. The
> container.java tests are failing pretty badly. Are you (or someone
> else) working on fixing them?
>
> For now, I'm going to revert my SDO dir to -r 387955.
>
> Thanks!
> Dan
>
>
>
> On Wednesday 22 March 2006 17:55, Frank Budinsky wrote:
> > I just committed a change to the SDO XSDHelper.define() method which
> > changes the behavior significantly. It used to mangle names (using
> > EMF's mangling algorithm) and it didn't map simple types (like xsd:int)
> > to the proper SDO Types as specified in the SDO 2 spec.
> >
> > With this change, many of the sca schemas no longer generated valid
> > Java classes. For example things like <element name="binding.java" ...>
> > now produces a get method named getBinding.java(), which doesn't
> > compile because of the "." character. Don't blame me, that's what the
> > SDO spec says it should do :-)
> >
> > The solution is to add sdo annotations (e.g., sdo:name="bindingJava")
> > in the schema with the bad names. I fixed all of the existing places
> > with this problem ... seemed like hundreds of them :-) ... so
> > everything is still working. Please beware of this issue, though, when
> > adding new schemas.
> >
> > Longer term, we might want to think about adding some mangling to the
> > Tuscany SDO generator as an option (value-add feature).
> >
> > Frank.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
>
>
>
Re: new XSD to SDO mapping
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Dan,
Are the container.java tests run as part of "mvn" from the root? I can run
"mvn clean" and then "mvn" from the tuscany/java directory and everything
works fine for me.
Could somebody else please confirm that they are also having problems like
Dan?
Thanks,
Frank.
Daniel Kulp <da...@iona.com>
03/22/2006 10:57 PM
Please respond to
tuscany-dev
To
tuscany-dev@ws.apache.org
cc
Frank Budinsky/Toronto/IBM@IBMCA
Subject
Re: new XSD to SDO mapping
Frank,
This commit seams to have REALLY broken the sca builds. The
container.java tests are failing pretty badly. Are you (or someone
else) working on fixing them?
For now, I'm going to revert my SDO dir to -r 387955.
Thanks!
Dan
On Wednesday 22 March 2006 17:55, Frank Budinsky wrote:
> I just committed a change to the SDO XSDHelper.define() method which
> changes the behavior significantly. It used to mangle names (using
> EMF's mangling algorithm) and it didn't map simple types (like xsd:int)
> to the proper SDO Types as specified in the SDO 2 spec.
>
> With this change, many of the sca schemas no longer generated valid
> Java classes. For example things like <element name="binding.java" ...>
> now produces a get method named getBinding.java(), which doesn't
> compile because of the "." character. Don't blame me, that's what the
> SDO spec says it should do :-)
>
> The solution is to add sdo annotations (e.g., sdo:name="bindingJava")
> in the schema with the bad names. I fixed all of the existing places
> with this problem ... seemed like hundreds of them :-) ... so
> everything is still working. Please beware of this issue, though, when
> adding new schemas.
>
> Longer term, we might want to think about adding some mangling to the
> Tuscany SDO generator as an option (value-add feature).
>
> Frank.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: new XSD to SDO mapping
Posted by Daniel Kulp <da...@iona.com>.
Frank,
This commit seams to have REALLY broken the sca builds. The
container.java tests are failing pretty badly. Are you (or someone
else) working on fixing them?
For now, I'm going to revert my SDO dir to -r 387955.
Thanks!
Dan
On Wednesday 22 March 2006 17:55, Frank Budinsky wrote:
> I just committed a change to the SDO XSDHelper.define() method which
> changes the behavior significantly. It used to mangle names (using
> EMF's mangling algorithm) and it didn't map simple types (like xsd:int)
> to the proper SDO Types as specified in the SDO 2 spec.
>
> With this change, many of the sca schemas no longer generated valid
> Java classes. For example things like <element name="binding.java" ...>
> now produces a get method named getBinding.java(), which doesn't
> compile because of the "." character. Don't blame me, that's what the
> SDO spec says it should do :-)
>
> The solution is to add sdo annotations (e.g., sdo:name="bindingJava")
> in the schema with the bad names. I fixed all of the existing places
> with this problem ... seemed like hundreds of them :-) ... so
> everything is still working. Please beware of this issue, though, when
> adding new schemas.
>
> Longer term, we might want to think about adding some mangling to the
> Tuscany SDO generator as an option (value-add feature).
>
> Frank.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com