You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by kelvin goodson <ke...@gmail.com> on 2007/03/15 16:42:18 UTC
SDO Java M3 Release Candidate RC1
I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.apache.org/%7Erobbinspg/M3-RC1/>
Please take a look at this and try it out, so that I can pick up any errors
quickly and move towards a vote on a proper release in the short term.
Thanks, Kelvin.
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 (IBMers involved
with EMF code)
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Paul Golick <go...@us.ibm.com> wrote on 04/02/2007 01:23:21 PM:
[snip]
> Is it accurate to categorize the code as "common to Apache Tuscany and
to
> Eclipse EMF"? or would you prefer a different description?
We won't have exactly the same code in both projects. The two EMF classes,
described below, are "code that IBM has contributed to both Eclipse EMF
and Apache Tuscany".
Thanks,
Frank.
[snip]
> Frank Budinsky <fr...@ca.ibm.com>
> 2007-03-22 09:01 AM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> Thank goodness, common sense applies :-)
>
> Now we can proceed with the release candidate.
>
> Thanks,
> Frank.
>
> sa3ruby@gmail.com wrote on 03/21/2007 05:27:35 PM:
>
> > On 3/21/07, Jeremy Boynes <jb...@apache.org> wrote:
> > > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
> > >
> > > > I've confirmed that IBM, the copyright holder, gives permission to
> > > > Apache
> > > > to reuse the two EMF files in question.
> > >
> > > Thanks for confirming this.
> > >
> > > >
> > > > I've opened TUSCANY-1185 to contribute the two base classes,
> > > > provided in
> > > > an attachment.
> > > >
> > > > Jeremy, let me know if this is good enough for you, or if you
still
> > > > want
> > > > me to remove the Tuscany subclasses and resubmit them.
> > >
> > > I can't ack this for the ASF - that has to be done by an Officer as
> > > described in the IP Clearance process. They would probably want
> > > something official from IBM (Software Grant).
> >
> > I am a director of the ASF.
> >
> > Apparently the original copyright holder desires to contribute the
> > same code to two different places under two different licenses. They
> > are certainly within their rights to do so. The contribution under
> > the other license isn't particularly relevant to me. Now, concerning
> > the contribution which is presumably being made in good faith under
> > the ASF license to the Tuscany project, I see no ASF wide legal or
> > policy issue here, which means that the only remaining issue a
> > technical one, namely whether or not tuscany wishes to accept this
> > code.
> >
> > Now, if anybody has any reason to believe that the assertion of
> > authorship is false (i.e., if there are Eclipse CVS or SVN logs which
> > show contributions by others), then the issue is an entirely different
> > one...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 (IBMers involved
with EMF code)
Posted by Paul Golick <go...@us.ibm.com>.
Frank,
Were you the only IBM employee involved in the contribution of this code
that is common to Apache Tuscany and to Eclipse EMF?
If not, who were the other IBM employees?
If it accurate to categorize the code as "common to Apache Tuscany and to
Eclipse EMF"? or would you prefer a different description?
This will answer a question for the "enhanced pedigree review" of the
Tuscany code so that we can ship SOA Feature Pack Iteration 1.
Regards,
Paul Golick
P. O. Box 12195, Dept. 6HSA (503 D224)
3039 Cornwallis Rd.
Research Triangle Park, NC 27709-2195
office phone: 919-543-7177
cell phone: 919-943-2578
home phone: 919-493-3570
e-mail: golick@us.ibm.com
Frank Budinsky <fr...@ca.ibm.com>
2007-03-22 09:01 AM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Thank goodness, common sense applies :-)
Now we can proceed with the release candidate.
Thanks,
Frank.
sa3ruby@gmail.com wrote on 03/21/2007 05:27:35 PM:
> On 3/21/07, Jeremy Boynes <jb...@apache.org> wrote:
> > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
> >
> > > I've confirmed that IBM, the copyright holder, gives permission to
> > > Apache
> > > to reuse the two EMF files in question.
> >
> > Thanks for confirming this.
> >
> > >
> > > I've opened TUSCANY-1185 to contribute the two base classes,
> > > provided in
> > > an attachment.
> > >
> > > Jeremy, let me know if this is good enough for you, or if you still
> > > want
> > > me to remove the Tuscany subclasses and resubmit them.
> >
> > I can't ack this for the ASF - that has to be done by an Officer as
> > described in the IP Clearance process. They would probably want
> > something official from IBM (Software Grant).
>
> I am a director of the ASF.
>
> Apparently the original copyright holder desires to contribute the
> same code to two different places under two different licenses. They
> are certainly within their rights to do so. The contribution under
> the other license isn't particularly relevant to me. Now, concerning
> the contribution which is presumably being made in good faith under
> the ASF license to the Tuscany project, I see no ASF wide legal or
> policy issue here, which means that the only remaining issue a
> technical one, namely whether or not tuscany wishes to accept this
> code.
>
> Now, if anybody has any reason to believe that the assertion of
> authorship is false (i.e., if there are Eclipse CVS or SVN logs which
> show contributions by others), then the issue is an entirely different
> one...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Thank goodness, common sense applies :-)
Now we can proceed with the release candidate.
Thanks,
Frank.
sa3ruby@gmail.com wrote on 03/21/2007 05:27:35 PM:
> On 3/21/07, Jeremy Boynes <jb...@apache.org> wrote:
> > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
> >
> > > I've confirmed that IBM, the copyright holder, gives permission to
> > > Apache
> > > to reuse the two EMF files in question.
> >
> > Thanks for confirming this.
> >
> > >
> > > I've opened TUSCANY-1185 to contribute the two base classes,
> > > provided in
> > > an attachment.
> > >
> > > Jeremy, let me know if this is good enough for you, or if you still
> > > want
> > > me to remove the Tuscany subclasses and resubmit them.
> >
> > I can't ack this for the ASF - that has to be done by an Officer as
> > described in the IP Clearance process. They would probably want
> > something official from IBM (Software Grant).
>
> I am a director of the ASF.
>
> Apparently the original copyright holder desires to contribute the
> same code to two different places under two different licenses. They
> are certainly within their rights to do so. The contribution under
> the other license isn't particularly relevant to me. Now, concerning
> the contribution which is presumably being made in good faith under
> the ASF license to the Tuscany project, I see no ASF wide legal or
> policy issue here, which means that the only remaining issue a
> technical one, namely whether or not tuscany wishes to accept this
> code.
>
> Now, if anybody has any reason to believe that the assertion of
> authorship is false (i.e., if there are Eclipse CVS or SVN logs which
> show contributions by others), then the issue is an entirely different
> one...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Sam Ruby <ru...@apache.org>.
On 3/21/07, Jeremy Boynes <jb...@apache.org> wrote:
> On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
>
> > I've confirmed that IBM, the copyright holder, gives permission to
> > Apache
> > to reuse the two EMF files in question.
>
> Thanks for confirming this.
>
> >
> > I've opened TUSCANY-1185 to contribute the two base classes,
> > provided in
> > an attachment.
> >
> > Jeremy, let me know if this is good enough for you, or if you still
> > want
> > me to remove the Tuscany subclasses and resubmit them.
>
> I can't ack this for the ASF - that has to be done by an Officer as
> described in the IP Clearance process. They would probably want
> something official from IBM (Software Grant).
I am a director of the ASF.
Apparently the original copyright holder desires to contribute the
same code to two different places under two different licenses. They
are certainly within their rights to do so. The contribution under
the other license isn't particularly relevant to me. Now, concerning
the contribution which is presumably being made in good faith under
the ASF license to the Tuscany project, I see no ASF wide legal or
policy issue here, which means that the only remaining issue a
technical one, namely whether or not tuscany wishes to accept this
code.
Now, if anybody has any reason to believe that the assertion of
authorship is false (i.e., if there are Eclipse CVS or SVN logs which
show contributions by others), then the issue is an entirely different
one...
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Ant, perhaps that is the question. I certainly don't think this is a
substantial contribution, but who can confirm that?
Frank.
"ant elder" <an...@gmail.com> wrote on 03/21/2007 02:53:10 PM:
> I think it may not be completely clear to everyone yet why this code
does
> not have to follow the IP clearance process as described at:
> http://incubator.apache.org/ip-clearance/
>
> From that link it doesn't seem completely clear when you need to follow
the
> IP clearance process or when a code attached to a JIRA can be treated
just
> as any other patch from a community member. Is the question whether or
not
> these two classes "represents a substantial contribution"?
>
> ...ant
>
> On 3/21/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> >
> > I believe this issue is resolved. I spent a good part of the last two
days
> > chasing this down with the Lawyers to alleviate Jeremy's concern.
> >
> > Does anyone other than Jeremy believe that this issue is not already
> > resolved? If so, can you please explain exactly what else I need to
do?
> >
> > Thanks,
> > Frank.
> >
> >
> >
> >
> > Jeremy Boynes <jb...@apache.org>
> > 03/21/2007 01:56 PM
> > Please respond to
> > tuscany-dev@ws.apache.org
> >
> >
> > To
> > tuscany-dev@ws.apache.org
> > cc
> >
> > Subject
> > Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:
> >
> > > Jeremy, I don't understand your last comment:
> > >
> > >> I can't ack this for the ASF - that has to be done by an Officer as
> > >> described in the IP Clearance process. They would probably want
> > >> something official from IBM (Software Grant).
> > >
> > > By attaching the two files to the JIRA, and selecting the "Grant
> > > license
> > > to ASF ..." button, I (on behalf of IBM) am contributing the
> > > classes. If I
> > > didn't have the right to do that, I would obviously be personally
> > > liable.
> > > How is this contribution different from any other contributed source
> > > files?
> >
> > It isn't. And Apache has a IP Clearance process for handling them.
> > Please don't shoot the messenger.
> >
> > >
> > > What I was specifically asking is whether there is some stringent
> > > timeline
> > > issue that I still need to deal with? The code had been in SVN
> > > before the
> > > license was officially granted.
> >
> > The big one is that we can't release this code until this resolved.
> > --
> > Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by ant elder <an...@gmail.com>.
I think it may not be completely clear to everyone yet why this code does
not have to follow the IP clearance process as described at:
http://incubator.apache.org/ip-clearance/
>From that link it doesn't seem completely clear when you need to follow the
IP clearance process or when a code attached to a JIRA can be treated just
as any other patch from a community member. Is the question whether or not
these two classes "represents a substantial contribution"?
...ant
On 3/21/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> I believe this issue is resolved. I spent a good part of the last two days
> chasing this down with the Lawyers to alleviate Jeremy's concern.
>
> Does anyone other than Jeremy believe that this issue is not already
> resolved? If so, can you please explain exactly what else I need to do?
>
> Thanks,
> Frank.
>
>
>
>
> Jeremy Boynes <jb...@apache.org>
> 03/21/2007 01:56 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:
>
> > Jeremy, I don't understand your last comment:
> >
> >> I can't ack this for the ASF - that has to be done by an Officer as
> >> described in the IP Clearance process. They would probably want
> >> something official from IBM (Software Grant).
> >
> > By attaching the two files to the JIRA, and selecting the "Grant
> > license
> > to ASF ..." button, I (on behalf of IBM) am contributing the
> > classes. If I
> > didn't have the right to do that, I would obviously be personally
> > liable.
> > How is this contribution different from any other contributed source
> > files?
>
> It isn't. And Apache has a IP Clearance process for handling them.
> Please don't shoot the messenger.
>
> >
> > What I was specifically asking is whether there is some stringent
> > timeline
> > issue that I still need to deal with? The code had been in SVN
> > before the
> > license was officially granted.
>
> The big one is that we can't release this code until this resolved.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Luciano Resende <lu...@gmail.com>.
I'd recommend asking a question on general@a.o. They would give you all
necessary guidance needed.
On 3/21/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> I believe this issue is resolved. I spent a good part of the last two days
> chasing this down with the Lawyers to alleviate Jeremy's concern.
>
> Does anyone other than Jeremy believe that this issue is not already
> resolved? If so, can you please explain exactly what else I need to do?
>
> Thanks,
> Frank.
>
>
>
>
> Jeremy Boynes <jb...@apache.org>
> 03/21/2007 01:56 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:
>
> > Jeremy, I don't understand your last comment:
> >
> >> I can't ack this for the ASF - that has to be done by an Officer as
> >> described in the IP Clearance process. They would probably want
> >> something official from IBM (Software Grant).
> >
> > By attaching the two files to the JIRA, and selecting the "Grant
> > license
> > to ASF ..." button, I (on behalf of IBM) am contributing the
> > classes. If I
> > didn't have the right to do that, I would obviously be personally
> > liable.
> > How is this contribution different from any other contributed source
> > files?
>
> It isn't. And Apache has a IP Clearance process for handling them.
> Please don't shoot the messenger.
>
> >
> > What I was specifically asking is whether there is some stringent
> > timeline
> > issue that I still need to deal with? The code had been in SVN
> > before the
> > license was officially granted.
>
> The big one is that we can't release this code until this resolved.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
I believe this issue is resolved. I spent a good part of the last two days
chasing this down with the Lawyers to alleviate Jeremy's concern.
Does anyone other than Jeremy believe that this issue is not already
resolved? If so, can you please explain exactly what else I need to do?
Thanks,
Frank.
Jeremy Boynes <jb...@apache.org>
03/21/2007 01:56 PM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:
> Jeremy, I don't understand your last comment:
>
>> I can't ack this for the ASF - that has to be done by an Officer as
>> described in the IP Clearance process. They would probably want
>> something official from IBM (Software Grant).
>
> By attaching the two files to the JIRA, and selecting the "Grant
> license
> to ASF ..." button, I (on behalf of IBM) am contributing the
> classes. If I
> didn't have the right to do that, I would obviously be personally
> liable.
> How is this contribution different from any other contributed source
> files?
It isn't. And Apache has a IP Clearance process for handling them.
Please don't shoot the messenger.
>
> What I was specifically asking is whether there is some stringent
> timeline
> issue that I still need to deal with? The code had been in SVN
> before the
> license was officially granted.
The big one is that we can't release this code until this resolved.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:
> Jeremy, I don't understand your last comment:
>
>> I can't ack this for the ASF - that has to be done by an Officer as
>> described in the IP Clearance process. They would probably want
>> something official from IBM (Software Grant).
>
> By attaching the two files to the JIRA, and selecting the "Grant
> license
> to ASF ..." button, I (on behalf of IBM) am contributing the
> classes. If I
> didn't have the right to do that, I would obviously be personally
> liable.
> How is this contribution different from any other contributed source
> files?
It isn't. And Apache has a IP Clearance process for handling them.
Please don't shoot the messenger.
>
> What I was specifically asking is whether there is some stringent
> timeline
> issue that I still need to deal with? The code had been in SVN
> before the
> license was officially granted.
The big one is that we can't release this code until this resolved.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Jeremy, I don't understand your last comment:
> I can't ack this for the ASF - that has to be done by an Officer as
> described in the IP Clearance process. They would probably want
> something official from IBM (Software Grant).
By attaching the two files to the JIRA, and selecting the "Grant license
to ASF ..." button, I (on behalf of IBM) am contributing the classes. If I
didn't have the right to do that, I would obviously be personally liable.
How is this contribution different from any other contributed source
files?
What I was specifically asking is whether there is some stringent timeline
issue that I still need to deal with? The code had been in SVN before the
license was officially granted.
Thanks,
Frank.
Jeremy Boynes <jb...@apache.org> wrote on 03/21/2007 12:41:29 PM:
> On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
>
> > I've confirmed that IBM, the copyright holder, gives permission to
> > Apache
> > to reuse the two EMF files in question.
>
> Thanks for confirming this.
>
> >
> > I've opened TUSCANY-1185 to contribute the two base classes,
> > provided in
> > an attachment.
> >
> > Jeremy, let me know if this is good enough for you, or if you still
> > want
> > me to remove the Tuscany subclasses and resubmit them.
>
> I can't ack this for the ASF - that has to be done by an Officer as
> described in the IP Clearance process. They would probably want
> something official from IBM (Software Grant).
>
> --
> Jeremy
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
> I've confirmed that IBM, the copyright holder, gives permission to
> Apache
> to reuse the two EMF files in question.
Thanks for confirming this.
>
> I've opened TUSCANY-1185 to contribute the two base classes,
> provided in
> an attachment.
>
> Jeremy, let me know if this is good enough for you, or if you still
> want
> me to remove the Tuscany subclasses and resubmit them.
I can't ack this for the ASF - that has to be done by an Officer as
described in the IP Clearance process. They would probably want
something official from IBM (Software Grant).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
I've confirmed that IBM, the copyright holder, gives permission to Apache
to reuse the two EMF files in question.
I've opened TUSCANY-1185 to contribute the two base classes, provided in
an attachment.
Jeremy, let me know if this is good enough for you, or if you still want
me to remove the Tuscany subclasses and resubmit them.
Frank.
Simon Nash <na...@hursley.ibm.com> wrote on 03/20/2007 08:37:21 AM:
> Frank,
> Standard disclaimer: I am not a lawyer and I am not qualified to give
> legal interpretations. However, I have heard many lawyers give talks
> on copyright :-) Based on this, I'd expect that the "new" method would
> need to follow standard legal guidelines for defence against a claim
> of copyright infringement. In the particlular case you have given,
> I don't think this would be a problem. But it is the nature of this
> beast that no precise formula could be given for where the line is.
>
> None of this would apply if the copyright holder had given permission
> to Apache to include their code and derivative works under the Apache
> license.
>
> Simon
>
> Frank Budinsky wrote:
>
> > Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 06:14:58 PM:
> >
> >
> >>On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote:
> >>
> >>
> >>>Hmm, this seems like an example of where "legal red tape" may be
> >>>getting
> >>>in the way of the "spirit of reuse".
> >>
> >>One man's "spirit of reuse" is another's copyright infringement. This
> >>is not something to take lightly.
> >
> >
> > I'm sure that's true. Nobody's taking this lightly.
> >
> > In this particular case, however, both parties, the EMF contributors
at
> > Eclipse, and the Tuscany consumers (us) here at Apache agree that this
is
> > not a case of copyright infringement. So, it seems to me that a
> > light-weight process for dealing with this kind of scenario is needed.
If
> > need be, we'll pull out this code temporarily, but I'd prefer to see
some
> > sensible way to deal with it without doing that.
> >
> > I'm also still looking for an answer to my question from below: I also
> > wonder where is the fine line between providing a "changed method" vs
"a
> > copied method with a change" in a subclass?
> >
> > According to the strict interpretation of the two licenses, you really
> > can't do much with EPL code at Apache. Something as trivial as
overriding
> > a base method that looks like this:
> >
> > void foo() {
> > x = 3;
> > bar();
> > }
> >
> > to set x to 4 instead of 3:
> >
> > void foo() {
> > x = 4;
> > bar();
> > }
> >
> > could be considered copyright infringement. If not, then where is the
fine
> > line?
> >
> > Thanks,
> > Frank.
> >
> >
> >>EPL is very specific:
> >> When the Program is made available in source code form:
> >> a) it must be made available under this Agreement; and
> >> b) a copy of this Agreement must be included with each copy of
> >>the Program.
> >>
> >>Distributing EPL code in source form under the Apache License is a
> >>violation of these EPL terms. Period.
> >>
> >>To distribute this code under the Apache License it needs to be
> >>relicensed by the copyright owner. This is not an ongoing
> >>contribution as covered by a CCLA but a grant of software written
> >>elsewhere to the Foundation. There is a process for this, handled by
> >>the Incubator:
> >> http://incubator.apache.org/ip-clearance/index.html
> >>
> >>Another alternative might be to distribute the code in binary form.
> >>This would involve making the "necessary change" elsewhere (say at
> >>Eclipse), releasing that derivative under the EPL in binary form.
> >>Tuscany would then be able to redistribute that code in its binary
> >>form. That's a suggestion - you probably want to talk to a lawyer and
> >>I would suggest running it past legal-discuss@a.o
> >>
> >>
> >>>Here's the general problem:
> >>>
> >>>1) We need to override a base class' behavior to do something
> >>>"slightly
> >>>different".
> >>>2) Looking at the base class, we notice that it requires a tiny
> >>>change in
> >>>the middle of a medium to large sized method. We request a slight
> >>>refactoring of the base (EMF) code, which they agree to fix in
> >>>their next
> >>>version.
> >>>3) We can't move to the next version yet, so we add a copy of the
> >>>method
> >>>(with the change) in our subclass and then proceed as if it was
> >>>already in
> >>>the base class.
> >>>
> >>>Note that we really don't want to do this in the first place
> >>>because if we
> >>>later forget to remove the override and EMF fixes some other bug in
> >>>the
> >>>same method, we won't ever pick up the fix. Unfortunately, however,
we
> >>>have no choice in the short term other than to rewrite the whole
> >>>method,
> >>>but since it's intricately tied to the rest of the base class
> >>>implementation it really couldn't be much different. We could
> >>>rewrite the
> >>>entire class, but that completely defeats the purpose of reuse.
> >>>
> >>>Does anybody know how this kind of "necessary copying" is addressed?
I
> >>>also wonder where is the fine line between providing a "changed
> >>>method" vs
> >>>"a copied method with a change" in a subclass? For example, what if
> >>>one of
> >>>the copied methods was only 3 lines and we changed one of them? Is
> >>>that
> >>>still a copy?
> >>>
> >>>Thanks,
> >>>Frank.
> >>>
> >>>Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 10:27:52 AM:
> >>>
> >>>
> >>>>The original code here is EPL (I assume), which Apache projects can
> >>>>include in binary form but not in source form. See here for details:
> >>>> http://www.apache.org/legal/3party.html
> >>>>
> >>>>We need to remove the original code from the repo. After that, there
> >>>>are two options:
> >>>>* Have the IP owner (I presume this is IBM code) relicense it under
> >>>>AL and contribute
> >>>> via the IP Clearance process
> >>>>* Do an alternative implementation, best done by someone who has not
> >>>>seen the Eclipse code
> >>>>
> >>>>--
> >>>>Jeremy
> >>>>
> >>>>On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
> >>>>
> >>>>
> >>>>>We may be talking about two different things here.
> >>>>>
> >>>>>Regarding the two EMF classes: BasicExtendedMetaData and
> >>>>>XSDEcoreBuilder,
> >>>>>here's what we did.
> >>>>>
> >>>>>Both of these classes (in EMF) create metadata (Types and
> >>>>>Properties)
> >>>>>scattered in various places in the classes. Unfortunately, for us,
> >>>>>it does
> >>>>>it using those evil singletons: EcoreFactory.eINSTANCE.createXXX
> >>>>>(). We
> >>>>>asked the EMF team if they could switch this to the IOC pattern,
> >>>>>so we
> >>>>>could inject our SDO specific metadata factories. They said they
> >>>>>would,
> >>>>>but can't before EMF version 2.3 which is Java 5 dependent. Since
> >>>>>we won't
> >>>>>(can't) move to EMF 2.3, our interim solution was to create
> >>>>>subclasses in
> >>>>>Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
> >>>>>override the methods that create metadata. The subclasses contain
> >>>>>copies
> >>>>>of the base method, only using a factory instance variable instead
> >>>>>of the
> >>>>>singleton. For example:
> >>>>>
> >>>>>class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
> >>>>> protected EcoreFactory ecoreFactory;
> >>>>>
> >>>>> void someXSDEcoreBuilderMethod() {
> >>>>> bla ... bla ... bla ...
> >>>>> // replaced this line: someVariable =
> >>>>>EcoreFactory.eINSTANCE.createXXX();
> >>>>> someVariable = ecoreFactory.createXXX();
> >>>>> bla ... bla ... bla ..
> >>>>> }
> >>>>>
> >>>>> ... etc.
> >>>>>
> >>>>>}
> >>>>>
> >>>>>So, the question is, what kind of license do we need in these two
> >>>>>Tuscany
> >>>>>classes?
> >>>>>
> >>>>>1. Apache.
> >>>>>2. Apache + Eclipse
> >>>>>3. Other?
> >>>>>
> >>>>>Currently, I think we just have #1. If anyone can provide
> >>>>>guidance on
> >>>>>this, it would be much appreciated.
> >>>>>
> >>>>>Thanks,
> >>>>>Frank.
> >>>>>
> >>>>>
> >>>>>Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
> >>>>>
> >>>>>
> >>>>>>Those are the ones. You said before that you thought this might be
> >>>>>>generated but that you were sure Frank would confirm. He has not
> >>>>>>done
> >>>>>>so.
> >>>>>>
> >>>>>>What seems odd to me is that if this was generated then I would
> >>>>>>have
> >>>>>>expected consistent text to have been produced by the generator.
> >>>>>>Instead we have things like:
> >>>>>>
> >>>>>>+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28
> >>>>>>emerks
> >>>>>>Exp $
> >>>>>>
> >>>>>>and
> >>>>>>
> >>>>>>+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks
> >>>>>>Exp $
> >>>>>>
> >>>>>>which correlate directly to headers found in files in the Eclipse
> >>>>>>repo. This makes the provenance of the code uncertain which is
> >>>>>>why we
> >>>>>>need clarification of what happened.
> >>>>>>
> >>>>>>--
> >>>>>>Jeremy
> >>>>>>
> >>>>>>On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
> >>>>>>
> >>>>>>
> >>>>>>>I think you are freferring to commit r513560 .* *There was no
code
> >>>>>>>copied
> >>>>>>>from eclipse. The EMF generator puts an eclipse header in to
> >>>>>>>generated code
> >>>>>>>by default. That code was simply the result of using that
> >>>>>>>generator
> >>>>>>>against
> >>>>>>>our own schemas.
> >>>>>>>
> >>>>>>>Regards, Kelvin.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
> >>>>>>>
> >>>>>>>>Not to be a party-pooper, but what was the outcome with the code
> >>>>>>>>copied from Eclipse?
> >>>>>>>>--
> >>>>>>>>Jeremy
> >>>>>>>>
> >>>>>>>>On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I have posted an SDO Java M3 release candidate here:
> >>>>>>>>>http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
> >>>>>>>>><http://
>
>>>>>>>>>people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
> >>>>>>>>
> >>>>>>>>~robbinspg/M3-RC1/>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Please take a look at this and try it out, so that I can pick
up
> >>>>>>>>>any errors
> >>>>>>>>>quickly and move towards a vote on a proper release in the
short
> >>>>>>>>
> >>>>>>>>term.
> >>>>>>>>
> >>>>>>>>>Thanks, Kelvin.
> >>>>>>>>
> >>>>>>>>
>
>>>>>>>>-----------------------------------------------------------------
> >
> >
> >>>>>>>>--
> >>>
> >>>>>>>>--
> >>>>>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>>>>
> >>>>>>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Simon Nash <na...@hursley.ibm.com>.
Frank,
Standard disclaimer: I am not a lawyer and I am not qualified to give
legal interpretations. However, I have heard many lawyers give talks
on copyright :-) Based on this, I'd expect that the "new" method would
need to follow standard legal guidelines for defence against a claim
of copyright infringement. In the particlular case you have given,
I don't think this would be a problem. But it is the nature of this
beast that no precise formula could be given for where the line is.
None of this would apply if the copyright holder had given permission
to Apache to include their code and derivative works under the Apache
license.
Simon
Frank Budinsky wrote:
> Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 06:14:58 PM:
>
>
>>On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote:
>>
>>
>>>Hmm, this seems like an example of where "legal red tape" may be
>>>getting
>>>in the way of the "spirit of reuse".
>>
>>One man's "spirit of reuse" is another's copyright infringement. This
>>is not something to take lightly.
>
>
> I'm sure that's true. Nobody's taking this lightly.
>
> In this particular case, however, both parties, the EMF contributors at
> Eclipse, and the Tuscany consumers (us) here at Apache agree that this is
> not a case of copyright infringement. So, it seems to me that a
> light-weight process for dealing with this kind of scenario is needed. If
> need be, we'll pull out this code temporarily, but I'd prefer to see some
> sensible way to deal with it without doing that.
>
> I'm also still looking for an answer to my question from below: I also
> wonder where is the fine line between providing a "changed method" vs "a
> copied method with a change" in a subclass?
>
> According to the strict interpretation of the two licenses, you really
> can't do much with EPL code at Apache. Something as trivial as overriding
> a base method that looks like this:
>
> void foo() {
> x = 3;
> bar();
> }
>
> to set x to 4 instead of 3:
>
> void foo() {
> x = 4;
> bar();
> }
>
> could be considered copyright infringement. If not, then where is the fine
> line?
>
> Thanks,
> Frank.
>
>
>>EPL is very specific:
>> When the Program is made available in source code form:
>> a) it must be made available under this Agreement; and
>> b) a copy of this Agreement must be included with each copy of
>>the Program.
>>
>>Distributing EPL code in source form under the Apache License is a
>>violation of these EPL terms. Period.
>>
>>To distribute this code under the Apache License it needs to be
>>relicensed by the copyright owner. This is not an ongoing
>>contribution as covered by a CCLA but a grant of software written
>>elsewhere to the Foundation. There is a process for this, handled by
>>the Incubator:
>> http://incubator.apache.org/ip-clearance/index.html
>>
>>Another alternative might be to distribute the code in binary form.
>>This would involve making the "necessary change" elsewhere (say at
>>Eclipse), releasing that derivative under the EPL in binary form.
>>Tuscany would then be able to redistribute that code in its binary
>>form. That's a suggestion - you probably want to talk to a lawyer and
>>I would suggest running it past legal-discuss@a.o
>>
>>
>>>Here's the general problem:
>>>
>>>1) We need to override a base class' behavior to do something
>>>"slightly
>>>different".
>>>2) Looking at the base class, we notice that it requires a tiny
>>>change in
>>>the middle of a medium to large sized method. We request a slight
>>>refactoring of the base (EMF) code, which they agree to fix in
>>>their next
>>>version.
>>>3) We can't move to the next version yet, so we add a copy of the
>>>method
>>>(with the change) in our subclass and then proceed as if it was
>>>already in
>>>the base class.
>>>
>>>Note that we really don't want to do this in the first place
>>>because if we
>>>later forget to remove the override and EMF fixes some other bug in
>>>the
>>>same method, we won't ever pick up the fix. Unfortunately, however, we
>>>have no choice in the short term other than to rewrite the whole
>>>method,
>>>but since it's intricately tied to the rest of the base class
>>>implementation it really couldn't be much different. We could
>>>rewrite the
>>>entire class, but that completely defeats the purpose of reuse.
>>>
>>>Does anybody know how this kind of "necessary copying" is addressed? I
>>>also wonder where is the fine line between providing a "changed
>>>method" vs
>>>"a copied method with a change" in a subclass? For example, what if
>>>one of
>>>the copied methods was only 3 lines and we changed one of them? Is
>>>that
>>>still a copy?
>>>
>>>Thanks,
>>>Frank.
>>>
>>>Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 10:27:52 AM:
>>>
>>>
>>>>The original code here is EPL (I assume), which Apache projects can
>>>>include in binary form but not in source form. See here for details:
>>>> http://www.apache.org/legal/3party.html
>>>>
>>>>We need to remove the original code from the repo. After that, there
>>>>are two options:
>>>>* Have the IP owner (I presume this is IBM code) relicense it under
>>>>AL and contribute
>>>> via the IP Clearance process
>>>>* Do an alternative implementation, best done by someone who has not
>>>>seen the Eclipse code
>>>>
>>>>--
>>>>Jeremy
>>>>
>>>>On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
>>>>
>>>>
>>>>>We may be talking about two different things here.
>>>>>
>>>>>Regarding the two EMF classes: BasicExtendedMetaData and
>>>>>XSDEcoreBuilder,
>>>>>here's what we did.
>>>>>
>>>>>Both of these classes (in EMF) create metadata (Types and
>>>>>Properties)
>>>>>scattered in various places in the classes. Unfortunately, for us,
>>>>>it does
>>>>>it using those evil singletons: EcoreFactory.eINSTANCE.createXXX
>>>>>(). We
>>>>>asked the EMF team if they could switch this to the IOC pattern,
>>>>>so we
>>>>>could inject our SDO specific metadata factories. They said they
>>>>>would,
>>>>>but can't before EMF version 2.3 which is Java 5 dependent. Since
>>>>>we won't
>>>>>(can't) move to EMF 2.3, our interim solution was to create
>>>>>subclasses in
>>>>>Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
>>>>>override the methods that create metadata. The subclasses contain
>>>>>copies
>>>>>of the base method, only using a factory instance variable instead
>>>>>of the
>>>>>singleton. For example:
>>>>>
>>>>>class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
>>>>> protected EcoreFactory ecoreFactory;
>>>>>
>>>>> void someXSDEcoreBuilderMethod() {
>>>>> bla ... bla ... bla ...
>>>>> // replaced this line: someVariable =
>>>>>EcoreFactory.eINSTANCE.createXXX();
>>>>> someVariable = ecoreFactory.createXXX();
>>>>> bla ... bla ... bla ..
>>>>> }
>>>>>
>>>>> ... etc.
>>>>>
>>>>>}
>>>>>
>>>>>So, the question is, what kind of license do we need in these two
>>>>>Tuscany
>>>>>classes?
>>>>>
>>>>>1. Apache.
>>>>>2. Apache + Eclipse
>>>>>3. Other?
>>>>>
>>>>>Currently, I think we just have #1. If anyone can provide
>>>>>guidance on
>>>>>this, it would be much appreciated.
>>>>>
>>>>>Thanks,
>>>>>Frank.
>>>>>
>>>>>
>>>>>Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
>>>>>
>>>>>
>>>>>>Those are the ones. You said before that you thought this might be
>>>>>>generated but that you were sure Frank would confirm. He has not
>>>>>>done
>>>>>>so.
>>>>>>
>>>>>>What seems odd to me is that if this was generated then I would
>>>>>>have
>>>>>>expected consistent text to have been produced by the generator.
>>>>>>Instead we have things like:
>>>>>>
>>>>>>+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28
>>>>>>emerks
>>>>>>Exp $
>>>>>>
>>>>>>and
>>>>>>
>>>>>>+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks
>>>>>>Exp $
>>>>>>
>>>>>>which correlate directly to headers found in files in the Eclipse
>>>>>>repo. This makes the provenance of the code uncertain which is
>>>>>>why we
>>>>>>need clarification of what happened.
>>>>>>
>>>>>>--
>>>>>>Jeremy
>>>>>>
>>>>>>On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
>>>>>>
>>>>>>
>>>>>>>I think you are freferring to commit r513560 .* *There was no code
>>>>>>>copied
>>>>>>>from eclipse. The EMF generator puts an eclipse header in to
>>>>>>>generated code
>>>>>>>by default. That code was simply the result of using that
>>>>>>>generator
>>>>>>>against
>>>>>>>our own schemas.
>>>>>>>
>>>>>>>Regards, Kelvin.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>>>>>>>
>>>>>>>>Not to be a party-pooper, but what was the outcome with the code
>>>>>>>>copied from Eclipse?
>>>>>>>>--
>>>>>>>>Jeremy
>>>>>>>>
>>>>>>>>On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>I have posted an SDO Java M3 release candidate here:
>>>>>>>>>http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
>>>>>>>>><http://
>>>>>>>>>people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
>>>>>>>>
>>>>>>>>~robbinspg/M3-RC1/>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>Please take a look at this and try it out, so that I can pick up
>>>>>>>>>any errors
>>>>>>>>>quickly and move towards a vote on a proper release in the short
>>>>>>>>
>>>>>>>>term.
>>>>>>>>
>>>>>>>>>Thanks, Kelvin.
>>>>>>>>
>>>>>>>>
>>>>>>>>-----------------------------------------------------------------
>
>
>>>>>>>>--
>>>
>>>>>>>>--
>>>>>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>>>
>>>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 06:14:58 PM:
> On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote:
>
> > Hmm, this seems like an example of where "legal red tape" may be
> > getting
> > in the way of the "spirit of reuse".
>
> One man's "spirit of reuse" is another's copyright infringement. This
> is not something to take lightly.
I'm sure that's true. Nobody's taking this lightly.
In this particular case, however, both parties, the EMF contributors at
Eclipse, and the Tuscany consumers (us) here at Apache agree that this is
not a case of copyright infringement. So, it seems to me that a
light-weight process for dealing with this kind of scenario is needed. If
need be, we'll pull out this code temporarily, but I'd prefer to see some
sensible way to deal with it without doing that.
I'm also still looking for an answer to my question from below: I also
wonder where is the fine line between providing a "changed method" vs "a
copied method with a change" in a subclass?
According to the strict interpretation of the two licenses, you really
can't do much with EPL code at Apache. Something as trivial as overriding
a base method that looks like this:
void foo() {
x = 3;
bar();
}
to set x to 4 instead of 3:
void foo() {
x = 4;
bar();
}
could be considered copyright infringement. If not, then where is the fine
line?
Thanks,
Frank.
>
> EPL is very specific:
> When the Program is made available in source code form:
> a) it must be made available under this Agreement; and
> b) a copy of this Agreement must be included with each copy of
> the Program.
>
> Distributing EPL code in source form under the Apache License is a
> violation of these EPL terms. Period.
>
> To distribute this code under the Apache License it needs to be
> relicensed by the copyright owner. This is not an ongoing
> contribution as covered by a CCLA but a grant of software written
> elsewhere to the Foundation. There is a process for this, handled by
> the Incubator:
> http://incubator.apache.org/ip-clearance/index.html
>
> Another alternative might be to distribute the code in binary form.
> This would involve making the "necessary change" elsewhere (say at
> Eclipse), releasing that derivative under the EPL in binary form.
> Tuscany would then be able to redistribute that code in its binary
> form. That's a suggestion - you probably want to talk to a lawyer and
> I would suggest running it past legal-discuss@a.o
>
> > Here's the general problem:
> >
> > 1) We need to override a base class' behavior to do something
> > "slightly
> > different".
> > 2) Looking at the base class, we notice that it requires a tiny
> > change in
> > the middle of a medium to large sized method. We request a slight
> > refactoring of the base (EMF) code, which they agree to fix in
> > their next
> > version.
> > 3) We can't move to the next version yet, so we add a copy of the
> > method
> > (with the change) in our subclass and then proceed as if it was
> > already in
> > the base class.
> >
> > Note that we really don't want to do this in the first place
> > because if we
> > later forget to remove the override and EMF fixes some other bug in
> > the
> > same method, we won't ever pick up the fix. Unfortunately, however, we
> > have no choice in the short term other than to rewrite the whole
> > method,
> > but since it's intricately tied to the rest of the base class
> > implementation it really couldn't be much different. We could
> > rewrite the
> > entire class, but that completely defeats the purpose of reuse.
> >
> > Does anybody know how this kind of "necessary copying" is addressed? I
> > also wonder where is the fine line between providing a "changed
> > method" vs
> > "a copied method with a change" in a subclass? For example, what if
> > one of
> > the copied methods was only 3 lines and we changed one of them? Is
> > that
> > still a copy?
> >
> > Thanks,
> > Frank.
> >
> > Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 10:27:52 AM:
> >
> >> The original code here is EPL (I assume), which Apache projects can
> >> include in binary form but not in source form. See here for details:
> >> http://www.apache.org/legal/3party.html
> >>
> >> We need to remove the original code from the repo. After that, there
> >> are two options:
> >> * Have the IP owner (I presume this is IBM code) relicense it under
> >> AL and contribute
> >> via the IP Clearance process
> >> * Do an alternative implementation, best done by someone who has not
> >> seen the Eclipse code
> >>
> >> --
> >> Jeremy
> >>
> >> On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
> >>
> >>> We may be talking about two different things here.
> >>>
> >>> Regarding the two EMF classes: BasicExtendedMetaData and
> >>> XSDEcoreBuilder,
> >>> here's what we did.
> >>>
> >>> Both of these classes (in EMF) create metadata (Types and
> >>> Properties)
> >>> scattered in various places in the classes. Unfortunately, for us,
> >>> it does
> >>> it using those evil singletons: EcoreFactory.eINSTANCE.createXXX
> >>> (). We
> >>> asked the EMF team if they could switch this to the IOC pattern,
> >>> so we
> >>> could inject our SDO specific metadata factories. They said they
> >>> would,
> >>> but can't before EMF version 2.3 which is Java 5 dependent. Since
> >>> we won't
> >>> (can't) move to EMF 2.3, our interim solution was to create
> >>> subclasses in
> >>> Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
> >>> override the methods that create metadata. The subclasses contain
> >>> copies
> >>> of the base method, only using a factory instance variable instead
> >>> of the
> >>> singleton. For example:
> >>>
> >>> class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
> >>> protected EcoreFactory ecoreFactory;
> >>>
> >>> void someXSDEcoreBuilderMethod() {
> >>> bla ... bla ... bla ...
> >>> // replaced this line: someVariable =
> >>> EcoreFactory.eINSTANCE.createXXX();
> >>> someVariable = ecoreFactory.createXXX();
> >>> bla ... bla ... bla ..
> >>> }
> >>>
> >>> ... etc.
> >>>
> >>> }
> >>>
> >>> So, the question is, what kind of license do we need in these two
> >>> Tuscany
> >>> classes?
> >>>
> >>> 1. Apache.
> >>> 2. Apache + Eclipse
> >>> 3. Other?
> >>>
> >>> Currently, I think we just have #1. If anyone can provide
> >>> guidance on
> >>> this, it would be much appreciated.
> >>>
> >>> Thanks,
> >>> Frank.
> >>>
> >>>
> >>> Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
> >>>
> >>>> Those are the ones. You said before that you thought this might be
> >>>> generated but that you were sure Frank would confirm. He has not
> >>>> done
> >>>> so.
> >>>>
> >>>> What seems odd to me is that if this was generated then I would
> >>>> have
> >>>> expected consistent text to have been produced by the generator.
> >>>> Instead we have things like:
> >>>>
> >>>> + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28
> >>>> emerks
> >>>> Exp $
> >>>>
> >>>> and
> >>>>
> >>>> + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks
> >>>> Exp $
> >>>>
> >>>> which correlate directly to headers found in files in the Eclipse
> >>>> repo. This makes the provenance of the code uncertain which is
> >>>> why we
> >>>> need clarification of what happened.
> >>>>
> >>>> --
> >>>> Jeremy
> >>>>
> >>>> On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
> >>>>
> >>>>> I think you are freferring to commit r513560 .* *There was no code
> >>>>> copied
> >>>>> from eclipse. The EMF generator puts an eclipse header in to
> >>>>> generated code
> >>>>> by default. That code was simply the result of using that
> >>>>> generator
> >>>>> against
> >>>>> our own schemas.
> >>>>>
> >>>>> Regards, Kelvin.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
> >>>>>>
> >>>>>> Not to be a party-pooper, but what was the outcome with the code
> >>>>>> copied from Eclipse?
> >>>>>> --
> >>>>>> Jeremy
> >>>>>>
> >>>>>> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
> >>>>>>
> >>>>>>> I have posted an SDO Java M3 release candidate here:
> >>>>>>> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
> >>>>>>> <http://
> >>>>>>> people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
> >>>>>> ~robbinspg/M3-RC1/>
> >>>>>>>
> >>>>>>>
> >>>>>>> Please take a look at this and try it out, so that I can pick up
> >>>>>>> any errors
> >>>>>>> quickly and move towards a vote on a proper release in the short
> >>>>>> term.
> >>>>>>>
> >>>>>>> Thanks, Kelvin.
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> --
> >
> >>>>>> --
> >>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote:
> Hmm, this seems like an example of where "legal red tape" may be
> getting
> in the way of the "spirit of reuse".
One man's "spirit of reuse" is another's copyright infringement. This
is not something to take lightly.
EPL is very specific:
When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy of
the Program.
Distributing EPL code in source form under the Apache License is a
violation of these EPL terms. Period.
To distribute this code under the Apache License it needs to be
relicensed by the copyright owner. This is not an ongoing
contribution as covered by a CCLA but a grant of software written
elsewhere to the Foundation. There is a process for this, handled by
the Incubator:
http://incubator.apache.org/ip-clearance/index.html
Another alternative might be to distribute the code in binary form.
This would involve making the "necessary change" elsewhere (say at
Eclipse), releasing that derivative under the EPL in binary form.
Tuscany would then be able to redistribute that code in its binary
form. That's a suggestion - you probably want to talk to a lawyer and
I would suggest running it past legal-discuss@a.o
> Here's the general problem:
>
> 1) We need to override a base class' behavior to do something
> "slightly
> different".
> 2) Looking at the base class, we notice that it requires a tiny
> change in
> the middle of a medium to large sized method. We request a slight
> refactoring of the base (EMF) code, which they agree to fix in
> their next
> version.
> 3) We can't move to the next version yet, so we add a copy of the
> method
> (with the change) in our subclass and then proceed as if it was
> already in
> the base class.
>
> Note that we really don't want to do this in the first place
> because if we
> later forget to remove the override and EMF fixes some other bug in
> the
> same method, we won't ever pick up the fix. Unfortunately, however, we
> have no choice in the short term other than to rewrite the whole
> method,
> but since it's intricately tied to the rest of the base class
> implementation it really couldn't be much different. We could
> rewrite the
> entire class, but that completely defeats the purpose of reuse.
>
> Does anybody know how this kind of "necessary copying" is addressed? I
> also wonder where is the fine line between providing a "changed
> method" vs
> "a copied method with a change" in a subclass? For example, what if
> one of
> the copied methods was only 3 lines and we changed one of them? Is
> that
> still a copy?
>
> Thanks,
> Frank.
>
> Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 10:27:52 AM:
>
>> The original code here is EPL (I assume), which Apache projects can
>> include in binary form but not in source form. See here for details:
>> http://www.apache.org/legal/3party.html
>>
>> We need to remove the original code from the repo. After that, there
>> are two options:
>> * Have the IP owner (I presume this is IBM code) relicense it under
>> AL and contribute
>> via the IP Clearance process
>> * Do an alternative implementation, best done by someone who has not
>> seen the Eclipse code
>>
>> --
>> Jeremy
>>
>> On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
>>
>>> We may be talking about two different things here.
>>>
>>> Regarding the two EMF classes: BasicExtendedMetaData and
>>> XSDEcoreBuilder,
>>> here's what we did.
>>>
>>> Both of these classes (in EMF) create metadata (Types and
>>> Properties)
>>> scattered in various places in the classes. Unfortunately, for us,
>>> it does
>>> it using those evil singletons: EcoreFactory.eINSTANCE.createXXX
>>> (). We
>>> asked the EMF team if they could switch this to the IOC pattern,
>>> so we
>>> could inject our SDO specific metadata factories. They said they
>>> would,
>>> but can't before EMF version 2.3 which is Java 5 dependent. Since
>>> we won't
>>> (can't) move to EMF 2.3, our interim solution was to create
>>> subclasses in
>>> Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
>>> override the methods that create metadata. The subclasses contain
>>> copies
>>> of the base method, only using a factory instance variable instead
>>> of the
>>> singleton. For example:
>>>
>>> class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
>>> protected EcoreFactory ecoreFactory;
>>>
>>> void someXSDEcoreBuilderMethod() {
>>> bla ... bla ... bla ...
>>> // replaced this line: someVariable =
>>> EcoreFactory.eINSTANCE.createXXX();
>>> someVariable = ecoreFactory.createXXX();
>>> bla ... bla ... bla ..
>>> }
>>>
>>> ... etc.
>>>
>>> }
>>>
>>> So, the question is, what kind of license do we need in these two
>>> Tuscany
>>> classes?
>>>
>>> 1. Apache.
>>> 2. Apache + Eclipse
>>> 3. Other?
>>>
>>> Currently, I think we just have #1. If anyone can provide
>>> guidance on
>>> this, it would be much appreciated.
>>>
>>> Thanks,
>>> Frank.
>>>
>>>
>>> Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
>>>
>>>> Those are the ones. You said before that you thought this might be
>>>> generated but that you were sure Frank would confirm. He has not
>>>> done
>>>> so.
>>>>
>>>> What seems odd to me is that if this was generated then I would
>>>> have
>>>> expected consistent text to have been produced by the generator.
>>>> Instead we have things like:
>>>>
>>>> + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28
>>>> emerks
>>>> Exp $
>>>>
>>>> and
>>>>
>>>> + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks
>>>> Exp $
>>>>
>>>> which correlate directly to headers found in files in the Eclipse
>>>> repo. This makes the provenance of the code uncertain which is
>>>> why we
>>>> need clarification of what happened.
>>>>
>>>> --
>>>> Jeremy
>>>>
>>>> On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
>>>>
>>>>> I think you are freferring to commit r513560 .* *There was no code
>>>>> copied
>>>>> from eclipse. The EMF generator puts an eclipse header in to
>>>>> generated code
>>>>> by default. That code was simply the result of using that
>>>>> generator
>>>>> against
>>>>> our own schemas.
>>>>>
>>>>> Regards, Kelvin.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>>>>>>
>>>>>> Not to be a party-pooper, but what was the outcome with the code
>>>>>> copied from Eclipse?
>>>>>> --
>>>>>> Jeremy
>>>>>>
>>>>>> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
>>>>>>
>>>>>>> I have posted an SDO Java M3 release candidate here:
>>>>>>> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
>>>>>>> <http://
>>>>>>> people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
>>>>>> ~robbinspg/M3-RC1/>
>>>>>>>
>>>>>>>
>>>>>>> Please take a look at this and try it out, so that I can pick up
>>>>>>> any errors
>>>>>>> quickly and move towards a vote on a proper release in the short
>>>>>> term.
>>>>>>>
>>>>>>> Thanks, Kelvin.
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> --
>
>>>>>> --
>>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hmm, this seems like an example of where "legal red tape" may be getting
in the way of the "spirit of reuse". Here's the general problem:
1) We need to override a base class' behavior to do something "slightly
different".
2) Looking at the base class, we notice that it requires a tiny change in
the middle of a medium to large sized method. We request a slight
refactoring of the base (EMF) code, which they agree to fix in their next
version.
3) We can't move to the next version yet, so we add a copy of the method
(with the change) in our subclass and then proceed as if it was already in
the base class.
Note that we really don't want to do this in the first place because if we
later forget to remove the override and EMF fixes some other bug in the
same method, we won't ever pick up the fix. Unfortunately, however, we
have no choice in the short term other than to rewrite the whole method,
but since it's intricately tied to the rest of the base class
implementation it really couldn't be much different. We could rewrite the
entire class, but that completely defeats the purpose of reuse.
Does anybody know how this kind of "necessary copying" is addressed? I
also wonder where is the fine line between providing a "changed method" vs
"a copied method with a change" in a subclass? For example, what if one of
the copied methods was only 3 lines and we changed one of them? Is that
still a copy?
Thanks,
Frank.
Jeremy Boynes <jb...@apache.org> wrote on 03/19/2007 10:27:52 AM:
> The original code here is EPL (I assume), which Apache projects can
> include in binary form but not in source form. See here for details:
> http://www.apache.org/legal/3party.html
>
> We need to remove the original code from the repo. After that, there
> are two options:
> * Have the IP owner (I presume this is IBM code) relicense it under
> AL and contribute
> via the IP Clearance process
> * Do an alternative implementation, best done by someone who has not
> seen the Eclipse code
>
> --
> Jeremy
>
> On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
>
> > We may be talking about two different things here.
> >
> > Regarding the two EMF classes: BasicExtendedMetaData and
> > XSDEcoreBuilder,
> > here's what we did.
> >
> > Both of these classes (in EMF) create metadata (Types and Properties)
> > scattered in various places in the classes. Unfortunately, for us,
> > it does
> > it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
> > asked the EMF team if they could switch this to the IOC pattern, so we
> > could inject our SDO specific metadata factories. They said they
> > would,
> > but can't before EMF version 2.3 which is Java 5 dependent. Since
> > we won't
> > (can't) move to EMF 2.3, our interim solution was to create
> > subclasses in
> > Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
> > override the methods that create metadata. The subclasses contain
> > copies
> > of the base method, only using a factory instance variable instead
> > of the
> > singleton. For example:
> >
> > class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
> > protected EcoreFactory ecoreFactory;
> >
> > void someXSDEcoreBuilderMethod() {
> > bla ... bla ... bla ...
> > // replaced this line: someVariable =
> > EcoreFactory.eINSTANCE.createXXX();
> > someVariable = ecoreFactory.createXXX();
> > bla ... bla ... bla ..
> > }
> >
> > ... etc.
> >
> > }
> >
> > So, the question is, what kind of license do we need in these two
> > Tuscany
> > classes?
> >
> > 1. Apache.
> > 2. Apache + Eclipse
> > 3. Other?
> >
> > Currently, I think we just have #1. If anyone can provide guidance on
> > this, it would be much appreciated.
> >
> > Thanks,
> > Frank.
> >
> >
> > Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
> >
> >> Those are the ones. You said before that you thought this might be
> >> generated but that you were sure Frank would confirm. He has not done
> >> so.
> >>
> >> What seems odd to me is that if this was generated then I would have
> >> expected consistent text to have been produced by the generator.
> >> Instead we have things like:
> >>
> >> + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
> >> Exp $
> >>
> >> and
> >>
> >> + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
> >>
> >> which correlate directly to headers found in files in the Eclipse
> >> repo. This makes the provenance of the code uncertain which is why we
> >> need clarification of what happened.
> >>
> >> --
> >> Jeremy
> >>
> >> On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
> >>
> >>> I think you are freferring to commit r513560 .* *There was no code
> >>> copied
> >>> from eclipse. The EMF generator puts an eclipse header in to
> >>> generated code
> >>> by default. That code was simply the result of using that generator
> >>> against
> >>> our own schemas.
> >>>
> >>> Regards, Kelvin.
> >>>
> >>>
> >>>
> >>>
> >>> On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
> >>>>
> >>>> Not to be a party-pooper, but what was the outcome with the code
> >>>> copied from Eclipse?
> >>>> --
> >>>> Jeremy
> >>>>
> >>>> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
> >>>>
> >>>>> I have posted an SDO Java M3 release candidate here:
> >>>>> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ <http://
> >>>>> people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
> >>>> ~robbinspg/M3-RC1/>
> >>>>>
> >>>>>
> >>>>> Please take a look at this and try it out, so that I can pick up
> >>>>> any errors
> >>>>> quickly and move towards a vote on a proper release in the short
> >>>> term.
> >>>>>
> >>>>> Thanks, Kelvin.
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by Jeremy Boynes <jb...@apache.org>.
The original code here is EPL (I assume), which Apache projects can
include in binary form but not in source form. See here for details:
http://www.apache.org/legal/3party.html
We need to remove the original code from the repo. After that, there
are two options:
* Have the IP owner (I presume this is IBM code) relicense it under
AL and contribute
via the IP Clearance process
* Do an alternative implementation, best done by someone who has not
seen the Eclipse code
--
Jeremy
On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
> We may be talking about two different things here.
>
> Regarding the two EMF classes: BasicExtendedMetaData and
> XSDEcoreBuilder,
> here's what we did.
>
> Both of these classes (in EMF) create metadata (Types and Properties)
> scattered in various places in the classes. Unfortunately, for us,
> it does
> it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
> asked the EMF team if they could switch this to the IOC pattern, so we
> could inject our SDO specific metadata factories. They said they
> would,
> but can't before EMF version 2.3 which is Java 5 dependent. Since
> we won't
> (can't) move to EMF 2.3, our interim solution was to create
> subclasses in
> Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
> override the methods that create metadata. The subclasses contain
> copies
> of the base method, only using a factory instance variable instead
> of the
> singleton. For example:
>
> class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
> protected EcoreFactory ecoreFactory;
>
> void someXSDEcoreBuilderMethod() {
> bla ... bla ... bla ...
> // replaced this line: someVariable =
> EcoreFactory.eINSTANCE.createXXX();
> someVariable = ecoreFactory.createXXX();
> bla ... bla ... bla ..
> }
>
> ... etc.
>
> }
>
> So, the question is, what kind of license do we need in these two
> Tuscany
> classes?
>
> 1. Apache.
> 2. Apache + Eclipse
> 3. Other?
>
> Currently, I think we just have #1. If anyone can provide guidance on
> this, it would be much appreciated.
>
> Thanks,
> Frank.
>
>
> Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
>
>> Those are the ones. You said before that you thought this might be
>> generated but that you were sure Frank would confirm. He has not done
>> so.
>>
>> What seems odd to me is that if this was generated then I would have
>> expected consistent text to have been produced by the generator.
>> Instead we have things like:
>>
>> + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
>> Exp $
>>
>> and
>>
>> + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
>>
>> which correlate directly to headers found in files in the Eclipse
>> repo. This makes the provenance of the code uncertain which is why we
>> need clarification of what happened.
>>
>> --
>> Jeremy
>>
>> On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
>>
>>> I think you are freferring to commit r513560 .* *There was no code
>>> copied
>>> from eclipse. The EMF generator puts an eclipse header in to
>>> generated code
>>> by default. That code was simply the result of using that generator
>>> against
>>> our own schemas.
>>>
>>> Regards, Kelvin.
>>>
>>>
>>>
>>>
>>> On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>>>>
>>>> Not to be a party-pooper, but what was the outcome with the code
>>>> copied from Eclipse?
>>>> --
>>>> Jeremy
>>>>
>>>> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
>>>>
>>>>> I have posted an SDO Java M3 release candidate here:
>>>>> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ <http://
>>>>> people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
>>>> ~robbinspg/M3-RC1/>
>>>>>
>>>>>
>>>>> Please take a look at this and try it out, so that I can pick up
>>>>> any errors
>>>>> quickly and move towards a vote on a proper release in the short
>>>> term.
>>>>>
>>>>> Thanks, Kelvin.
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
We may be talking about two different things here.
Regarding the two EMF classes: BasicExtendedMetaData and XSDEcoreBuilder,
here's what we did.
Both of these classes (in EMF) create metadata (Types and Properties)
scattered in various places in the classes. Unfortunately, for us, it does
it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
asked the EMF team if they could switch this to the IOC pattern, so we
could inject our SDO specific metadata factories. They said they would,
but can't before EMF version 2.3 which is Java 5 dependent. Since we won't
(can't) move to EMF 2.3, our interim solution was to create subclasses in
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain copies
of the base method, only using a factory instance variable instead of the
singleton. For example:
class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;
void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}
... etc.
}
So, the question is, what kind of license do we need in these two Tuscany
classes?
1. Apache.
2. Apache + Eclipse
3. Other?
Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.
Thanks,
Frank.
Jeremy Boynes <jb...@apache.org> wrote on 03/18/2007 12:33:25 PM:
> Those are the ones. You said before that you thought this might be
> generated but that you were sure Frank would confirm. He has not done
> so.
>
> What seems odd to me is that if this was generated then I would have
> expected consistent text to have been produced by the generator.
> Instead we have things like:
>
> + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
> Exp $
>
> and
>
> + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
>
> which correlate directly to headers found in files in the Eclipse
> repo. This makes the provenance of the code uncertain which is why we
> need clarification of what happened.
>
> --
> Jeremy
>
> On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
>
> > I think you are freferring to commit r513560 .* *There was no code
> > copied
> > from eclipse. The EMF generator puts an eclipse header in to
> > generated code
> > by default. That code was simply the result of using that generator
> > against
> > our own schemas.
> >
> > Regards, Kelvin.
> >
> >
> >
> >
> > On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> Not to be a party-pooper, but what was the outcome with the code
> >> copied from Eclipse?
> >> --
> >> Jeremy
> >>
> >> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
> >>
> >> > I have posted an SDO Java M3 release candidate here:
> >> > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ <http://
> >> > people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
> >> ~robbinspg/M3-RC1/>
> >> >
> >> >
> >> > Please take a look at this and try it out, so that I can pick up
> >> > any errors
> >> > quickly and move towards a vote on a proper release in the short
> >> term.
> >> >
> >> > Thanks, Kelvin.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by Jeremy Boynes <jb...@apache.org>.
Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not done
so.
What seems odd to me is that if this was generated then I would have
expected consistent text to have been produced by the generator.
Instead we have things like:
+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
Exp $
and
+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
which correlate directly to headers found in files in the Eclipse
repo. This makes the provenance of the code uncertain which is why we
need clarification of what happened.
--
Jeremy
On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
> I think you are freferring to commit r513560 .* *There was no code
> copied
> from eclipse. The EMF generator puts an eclipse header in to
> generated code
> by default. That code was simply the result of using that generator
> against
> our own schemas.
>
> Regards, Kelvin.
>
>
>
>
> On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> Not to be a party-pooper, but what was the outcome with the code
>> copied from Eclipse?
>> --
>> Jeremy
>>
>> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
>>
>> > I have posted an SDO Java M3 release candidate here:
>> > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ <http://
>> > people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
>> ~robbinspg/M3-RC1/>
>> >
>> >
>> > Please take a look at this and try it out, so that I can pick up
>> > any errors
>> > quickly and move towards a vote on a proper release in the short
>> term.
>> >
>> > Thanks, Kelvin.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
I think you are freferring to commit r513560 .* *There was no code copied
from eclipse. The EMF generator puts an eclipse header in to generated code
by default. That code was simply the result of using that generator against
our own schemas.
Regards, Kelvin.
On 17/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> Not to be a party-pooper, but what was the outcome with the code
> copied from Eclipse?
> --
> Jeremy
>
> On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
>
> > I have posted an SDO Java M3 release candidate here:
> > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ <http://
> > people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/~robbinspg/M3-RC1/>
> >
> >
> > Please take a look at this and try it out, so that I can pick up
> > any errors
> > quickly and move towards a vote on a proper release in the short term.
> >
> > Thanks, Kelvin.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SDO Java M3 Release Candidate RC1
Posted by Jeremy Boynes <jb...@apache.org>.
Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy
On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://
> people.apache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up
> any errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
Similarly I don't understand the inclusion of asm since its scope is
"provided"
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<version>2.2</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
On 21/03/07, kelvin goodson <ke...@gmail.com> wrote:
>
> Yang,
>
> I've been battling with Maven trying to remove the junit jar from the
> archive. As far as I can see it seems to be a (spurious?) transitive
> dependency coming in from the plugin project's dependency on
> org.apache.maven:maven-plugin-descriptor:jar (see attached html file) --
> but so far my edits to the poms have failed to remove the jar from the
> distro,. Any suggestions most welcome.
>
> Regards, Kelvin.
>
> On 20/03/07, Yang ZHONG <le...@gmail.com> wrote:
> >
> > Agree with Ant, we probably don't need jUnit into the binary distro.
> > At the same time, do we really need ASM?
> >
> > On the other hand, roughly I see 2 kinds of audience:
> > 2-1. developers who participate in development. I guess they might lean
> > to
> > work upon the source repository instead of the release
> > 2-2. users who don't participate in development yet. I guess they
> > concern
> > binary distro much more than the source counterpart
> > If users are the majority of the *release* audience, it'll be nice to
> > make
> > sample build easy against binary distro.
> > Currectly, I have to do some work to build sample.
> >
> > I see some errors running the samples:
> > 1. NullPointerException @ CreateDataObjectFromXmlString.java:153
> > 2. ClassCastException @ ObtainingDataGraphFromXml.java:156
> > 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13)
> >
> > On 3/15/07, ant elder <an...@gmail.com> wrote:
> > >
> > > On 3/15/07, kelvin goodson <ke...@gmail.com> wrote:
> > > >
> > > > I have posted an SDO Java M3 release candidate here:
> > > > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.apache.org/%7Ekelvingoodson/sdo_java/M3/RC1/>
> > <
> > > > http://people.apache.org/%7Erobbinspg/M3-RC1/>
> > > >
> > > > Please take a look at this and try it out, so that I can pick up any
> >
> > > > errors
> > > > quickly and move towards a vote on a proper release in the short
> > term.
> > > >
> > > > Thanks, Kelvin.
> > > >
> > >
> > > Looks pretty good to me. The binary distro includes JUnit, do you
> > really
> > > need that? If so you need to add it to the LICENSE and NOTICE files.
> > Also
> > > should probably include the ASM copyright in the NOTICE file.
> > >
> > > ...ant
> > >
> >
> >
> >
> > --
> >
> > Yang ZHONG
> >
>
>
>
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
Yang,
I've been battling with Maven trying to remove the junit jar from the
archive. As far as I can see it seems to be a (spurious?) transitive
dependency coming in from the plugin project's dependency on
org.apache.maven:maven-plugin-descriptor:jar<file:///C:/Development/JiraDev/M3Release/svn/M3ImplRelease/plugin/target/site/dependencies.html#org.apache.maven:maven-plugin-descriptor:jar>(see
attached html file) -- but so far my edits to the poms have failed to
remove the jar from the distro,. Any suggestions most welcome.
Regards, Kelvin.
On 20/03/07, Yang ZHONG <le...@gmail.com> wrote:
>
> Agree with Ant, we probably don't need jUnit into the binary distro.
> At the same time, do we really need ASM?
>
> On the other hand, roughly I see 2 kinds of audience:
> 2-1. developers who participate in development. I guess they might lean to
> work upon the source repository instead of the release
> 2-2. users who don't participate in development yet. I guess they concern
> binary distro much more than the source counterpart
> If users are the majority of the *release* audience, it'll be nice to make
> sample build easy against binary distro.
> Currectly, I have to do some work to build sample.
>
> I see some errors running the samples:
> 1. NullPointerException @ CreateDataObjectFromXmlString.java:153
> 2. ClassCastException @ ObtainingDataGraphFromXml.java:156
> 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13)
>
> On 3/15/07, ant elder <an...@gmail.com> wrote:
> >
> > On 3/15/07, kelvin goodson <ke...@gmail.com> wrote:
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<
> > > http://people.apache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up any
> > > errors
> > > quickly and move towards a vote on a proper release in the short term.
> > >
> > > Thanks, Kelvin.
> > >
> >
> > Looks pretty good to me. The binary distro includes JUnit, do you really
> > need that? If so you need to add it to the LICENSE and NOTICE files.
> Also
> > should probably include the ASM copyright in the NOTICE file.
> >
> > ...ant
> >
>
>
>
> --
>
> Yang ZHONG
>
Re: SDO Java M3 Release Candidate RC1
Posted by Yang ZHONG <le...@gmail.com>.
I'm looking into revising samples.
On 3/22/07, kelvin goodson <ke...@gmail.com> wrote:
>
> Looking back at the samples, it's clear they haven't been significantly
> revisited since M2 at the 2.0.1 level. It's going to take a little time
> to
> put these straight. They have also been affected by generator template
> bugs
> which are now being fixed, so this will sort the issues that Yang pointed
> out.
>
> Regards, Kelvin.
>
> On 20/03/07, Yang ZHONG <le...@gmail.com> wrote:
> >
> > Agree with Ant, we probably don't need jUnit into the binary distro.
> > At the same time, do we really need ASM?
> >
> > On the other hand, roughly I see 2 kinds of audience:
> > 2-1. developers who participate in development. I guess they might lean
> to
> > work upon the source repository instead of the release
> > 2-2. users who don't participate in development yet. I guess they
> concern
> > binary distro much more than the source counterpart
> > If users are the majority of the *release* audience, it'll be nice to
> make
> > sample build easy against binary distro.
> > Currectly, I have to do some work to build sample.
> >
> > I see some errors running the samples:
> > 1. NullPointerException @ CreateDataObjectFromXmlString.java:153
> > 2. ClassCastException @ ObtainingDataGraphFromXml.java:156
> > 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13)
> >
> > On 3/15/07, ant elder <an...@gmail.com> wrote:
> > >
> > > On 3/15/07, kelvin goodson <ke...@gmail.com> wrote:
> > > >
> > > > I have posted an SDO Java M3 release candidate here:
> > > > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<
> > > > http://people.apache.org/%7Erobbinspg/M3-RC1/>
> > > >
> > > > Please take a look at this and try it out, so that I can pick up any
> > > > errors
> > > > quickly and move towards a vote on a proper release in the short
> term.
> > > >
> > > > Thanks, Kelvin.
> > > >
> > >
> > > Looks pretty good to me. The binary distro includes JUnit, do you
> really
> > > need that? If so you need to add it to the LICENSE and NOTICE files.
> > Also
> > > should probably include the ASM copyright in the NOTICE file.
> > >
> > > ...ant
> > >
> >
> >
> >
> > --
> >
> > Yang ZHONG
> >
>
--
Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
Looking back at the samples, it's clear they haven't been significantly
revisited since M2 at the 2.0.1 level. It's going to take a little time to
put these straight. They have also been affected by generator template bugs
which are now being fixed, so this will sort the issues that Yang pointed
out.
Regards, Kelvin.
On 20/03/07, Yang ZHONG <le...@gmail.com> wrote:
>
> Agree with Ant, we probably don't need jUnit into the binary distro.
> At the same time, do we really need ASM?
>
> On the other hand, roughly I see 2 kinds of audience:
> 2-1. developers who participate in development. I guess they might lean to
> work upon the source repository instead of the release
> 2-2. users who don't participate in development yet. I guess they concern
> binary distro much more than the source counterpart
> If users are the majority of the *release* audience, it'll be nice to make
> sample build easy against binary distro.
> Currectly, I have to do some work to build sample.
>
> I see some errors running the samples:
> 1. NullPointerException @ CreateDataObjectFromXmlString.java:153
> 2. ClassCastException @ ObtainingDataGraphFromXml.java:156
> 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13)
>
> On 3/15/07, ant elder <an...@gmail.com> wrote:
> >
> > On 3/15/07, kelvin goodson <ke...@gmail.com> wrote:
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<
> > > http://people.apache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up any
> > > errors
> > > quickly and move towards a vote on a proper release in the short term.
> > >
> > > Thanks, Kelvin.
> > >
> >
> > Looks pretty good to me. The binary distro includes JUnit, do you really
> > need that? If so you need to add it to the LICENSE and NOTICE files.
> Also
> > should probably include the ASM copyright in the NOTICE file.
> >
> > ...ant
> >
>
>
>
> --
>
> Yang ZHONG
>
Re: SDO Java M3 Release Candidate RC1
Posted by Yang ZHONG <le...@gmail.com>.
Agree with Ant, we probably don't need jUnit into the binary distro.
At the same time, do we really need ASM?
On the other hand, roughly I see 2 kinds of audience:
2-1. developers who participate in development. I guess they might lean to
work upon the source repository instead of the release
2-2. users who don't participate in development yet. I guess they concern
binary distro much more than the source counterpart
If users are the majority of the *release* audience, it'll be nice to make
sample build easy against binary distro.
Currectly, I have to do some work to build sample.
I see some errors running the samples:
1. NullPointerException @ CreateDataObjectFromXmlString.java:153
2. ClassCastException @ ObtainingDataGraphFromXml.java:156
3. NullPointerException @ PurchaseOrderControl.java:438 (option 13)
On 3/15/07, ant elder <an...@gmail.com> wrote:
>
> On 3/15/07, kelvin goodson <ke...@gmail.com> wrote:
> >
> > I have posted an SDO Java M3 release candidate here:
> > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<
> > http://people.apache.org/%7Erobbinspg/M3-RC1/>
> >
> > Please take a look at this and try it out, so that I can pick up any
> > errors
> > quickly and move towards a vote on a proper release in the short term.
> >
> > Thanks, Kelvin.
> >
>
> Looks pretty good to me. The binary distro includes JUnit, do you really
> need that? If so you need to add it to the LICENSE and NOTICE files. Also
> should probably include the ASM copyright in the NOTICE file.
>
> ...ant
>
--
Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
Posted by ant elder <an...@gmail.com>.
On 3/15/07, kelvin goodson <ke...@gmail.com> wrote:
>
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<
> http://people.apache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
>
Looks pretty good to me. The binary distro includes JUnit, do you really
need that? If so you need to add it to the LICENSE and NOTICE files. Also
should probably include the ASM copyright in the NOTICE file.
...ant
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
Christian,
yes, you need to use the DataFactory instance that is contained in the
HelperContext. this is the idea of a Helpercontext, it is a collection of
helper instances all sharing a type scope. So instead of
DataFactory.INSTANCE you need to use hc.getDataFactory(). Only this
instance will have access to the types you defined with the XSDHelper that
belongs to the hc instance of HelperContext.
regards, Kelvin.
On 26/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
>
> In M2 & M3 this works for a specific schema:
>
> XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
> But this doesn't
>
> HelperContext hc = SDOUtil.createHelperContext(true);
> hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
>
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
>
> java.lang.IllegalArgumentException
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:63)
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:46)
> at
> sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> ndExtensibleNamespaces.java:153)
> at
> sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> tensibleNamespaces.java:77)
>
>
> Any ideas?
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 22. marts 2007 13:38
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Sorry, there's not much documentation, just the JavaDoc. You need to get
> a
> HelperContext by calling SDOUtil.createHelperContext() and then get your
>
> XSDHelper from it.
>
> If you want the new extensible namespaces behavior you need to pass
> "true"
> to createHelperContext:
>
> HelperContext hc = SDOUtil.createHelperContext(true);
>
> Frank.
>
>
>
>
> "Christian Landbo Frederiksen" <Ch...@ementor.dk>
>
> 03/22/2007 06:30 AM
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
>
> Subject
> RE: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> The testcase I used the last time does not function using SDO M3, but I
> guess It is because I can't just use XSDHelper.INSTANCE. I remember
> Frank
> mentioning something about helpercontexts. Have you got any
> documentation
> as to hov this is done.
>
> /Chr
>
> ps. the test case is the one from:
> https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> <
> https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> .issuetabpanels:comment-tabpanel%23action_12473251
> >
>
>
>
> ________________________________
>
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: Fri 3/16/2007 9:14 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO Java M3 Release Candidate RC1
>
>
>
> Christian,
> The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
> the
> binary release.
> Regards, Kelvin.
>
> On 15/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> >
> > What version of EMF and SDO api is needed for this release?
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 15. marts 2007 16:42
> > To: tuscany-dev; Tuscany Users
> > Subject: SDO Java M3 Release Candidate RC1
> >
> > I have posted an SDO Java M3 release candidate here:
> >
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > pache.org/%7Erobbinspg/M3-RC1/>
> >
> > Please take a look at this and try it out, so that I can pick up any
> > errors
> > quickly and move towards a vote on a proper release in the short term.
> >
> > Thanks, Kelvin.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
It was a remain in my testcase.
I figured out it was the wrong way to go when I ran into getting
different xpaths finding my root through 'DocumentRoot' and just loading
an xml-instance.
/Chr
-----Original Message-----
From: Yang ZHONG [mailto:leiwang.yangzhong@gmail.com]
Sent: 26. marts 2007 19:19
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Christian,
On the other hand, "DocumentRoot" has no support from the spec.
XMLDocument serves some "document" features such as
NoNamespaceSchemaLocation, SchemaLocation and RootElement,
if some of them are what you're looking for.
On 3/26/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> You need to get your DataFactory from the HelperContext:
>
> DataObject documentDataObject = hc.getDataFactory().create(namespace,
> "DocumentRoot");
>
> You should generally stop using INSTANCE fields in all cases, because
they
> are probably going to be deprecated in the next version of SDO.
> HelperContext is the replacement. It defines a metadata scope, so you
> should always use it to get the helpers for your scope.
>
> Frank.
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
> wrote on 03/26/2007 01:01:00 PM:
>
> >
> > In M2 & M3 this works for a specific schema:
> >
> > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> > But this doesn't
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> >
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> >
> > java.lang.IllegalArgumentException
> > at
> >
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:63)
> > at
> >
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> > at
> >
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > ndExtensibleNamespaces.java:153)
> > at
> >
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > tensibleNamespaces.java:77)
> >
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 22. marts 2007 13:38
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Sorry, there's not much documentation, just the JavaDoc. You need to
get
> > a
> > HelperContext by calling SDOUtil.createHelperContext() and then get
your
> >
> > XSDHelper from it.
> >
> > If you want the new extensible namespaces behavior you need to pass
> > "true"
> > to createHelperContext:
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> >
> > Frank.
> >
> >
> >
> >
> > "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
> >
> > 03/22/2007 06:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > The testcase I used the last time does not function using SDO M3,
but I
> > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > Frank
> > mentioning something about helpercontexts. Have you got any
> > documentation
> > as to hov this is done.
> >
> > /Chr
> >
> > ps. the test case is the one from:
> >
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > <
> >
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> >
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > .issuetabpanels:comment-tabpanel%23action_12473251
> > >
> >
> >
> >
> > ________________________________
> >
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: Fri 3/16/2007 9:14 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> >
> >
> > Christian,
> > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
in
> > the
> > binary release.
> > Regards, Kelvin.
> >
> > On 15/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > >
> > > What version of EMF and SDO api is needed for this release?
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 15. marts 2007 16:42
> > > To: tuscany-dev; Tuscany Users
> > > Subject: SDO Java M3 Release Candidate RC1
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > >
> >
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > pache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up
any
> > > errors
> > > quickly and move towards a vote on a proper release in the short
term.
> > >
> > > Thanks, Kelvin.
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Schema references unavailable
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Hi guys
Is there a way to make Tuscany SDO fetch referenced schemas locally (or
from another location)?
If I have a schema containing the following:
...
xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
...
<import namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_StreetName.xsd"/>
...
<element ref="DKCC:StreetName"/>
...
If the site holding the DKCC_StreetName.xsd schema is temporarily down
the XSDHelper.define will eventually throw an exception.
So my question is whether it is possible to cache the referenced schemas
locally (or something)?
/Chr
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: Schema references unavailable
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
No good ideas?
I vaguely remember hearing about something like this with regards to
tld's and references to the sun site.
Is there a xsd equivalent?
/Chr
-----Original Message-----
From: Christian Landbo Frederiksen
Sent: 27. marts 2007 16:13
To: 'tuscany-user@ws.apache.org'
Subject: Schema references unavailable
Hi guys
Is there a way to make Tuscany SDO fetch referenced schemas locally (or
from another location)?
If I have a schema containing the following:
...
xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
...
<import namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_StreetName.xsd"/>
...
<element ref="DKCC:StreetName"/>
...
If the site holding the DKCC_StreetName.xsd schema is temporarily down
the XSDHelper.define will eventually throw an exception.
So my question is whether it is possible to cache the referenced schemas
locally (or something)?
/Chr
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by Yang ZHONG <le...@gmail.com>.
Christian,
On the other hand, "DocumentRoot" has no support from the spec.
XMLDocument serves some "document" features such as
NoNamespaceSchemaLocation, SchemaLocation and RootElement,
if some of them are what you're looking for.
On 3/26/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> You need to get your DataFactory from the HelperContext:
>
> DataObject documentDataObject = hc.getDataFactory().create(namespace,
> "DocumentRoot");
>
> You should generally stop using INSTANCE fields in all cases, because they
> are probably going to be deprecated in the next version of SDO.
> HelperContext is the replacement. It defines a metadata scope, so you
> should always use it to get the helpers for your scope.
>
> Frank.
>
> "Christian Landbo Frederiksen" <Ch...@ementor.dk>
> wrote on 03/26/2007 01:01:00 PM:
>
> >
> > In M2 & M3 this works for a specific schema:
> >
> > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> > But this doesn't
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> >
> > DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> >
> > java.lang.IllegalArgumentException
> > at
> > org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:63)
> > at
> > org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> > at
> > sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > ndExtensibleNamespaces.java:153)
> > at
> > sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > tensibleNamespaces.java:77)
> >
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 22. marts 2007 13:38
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Sorry, there's not much documentation, just the JavaDoc. You need to get
> > a
> > HelperContext by calling SDOUtil.createHelperContext() and then get your
> >
> > XSDHelper from it.
> >
> > If you want the new extensible namespaces behavior you need to pass
> > "true"
> > to createHelperContext:
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> >
> > Frank.
> >
> >
> >
> >
> > "Christian Landbo Frederiksen" <Ch...@ementor.dk>
> >
> > 03/22/2007 06:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > The testcase I used the last time does not function using SDO M3, but I
> > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > Frank
> > mentioning something about helpercontexts. Have you got any
> > documentation
> > as to hov this is done.
> >
> > /Chr
> >
> > ps. the test case is the one from:
> > https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > <
> > https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > .issuetabpanels:comment-tabpanel%23action_12473251
> > >
> >
> >
> >
> > ________________________________
> >
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: Fri 3/16/2007 9:14 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> >
> >
> > Christian,
> > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
> > the
> > binary release.
> > Regards, Kelvin.
> >
> > On 15/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > >
> > > What version of EMF and SDO api is needed for this release?
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 15. marts 2007 16:42
> > > To: tuscany-dev; Tuscany Users
> > > Subject: SDO Java M3 Release Candidate RC1
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > >
> > http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > pache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up any
> > > errors
> > > quickly and move towards a vote on a proper release in the short term.
> > >
> > > Thanks, Kelvin.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
I'm also wondering if you only see this problem when you create your
HelperContext using SDOUtil.createHelperContext(true), or if it also
happens in the false case?
There have been a number of changes in the SDO implementation lately that
might be causing this problem. So, as Kelvin said, a test case
illustrating the problem would be much appreciated.
Thanks,
Frank.
"kelvin goodson" <ke...@gmail.com> wrote on 03/28/2007 03:53:21
AM:
> Hi Christian,
> could you please post some code snippets or better still a test case.
It
> appears that the Type that you are trying to create an instance of is
> associated with an EMF factory rather than an SDO Factory.
>
> On the subject of HelperContext lifecycle, there's no constraint on the
> longevity of a HelperContext instance. At the moment I imagine that
each
> instance would be relatively long lived, since there are no fine
grained
> controls on the lifecycle of the Types within a scope. So I imagine
that
> for many applications a single HelperContext will suffice for the
lifetime
> of the application.
>
> It may be the case that in the future we provide ways of associating
> HelperContexts in order that one may delegate to another/others. I can
> imagine in that scenario more opportunities to control the type system
by
> having short lived HelperContext instances, but as I say, we don't
have
> that yet.
>
> Regards, Kelvin.
>
>
> On 27/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> > Hi Frank et. al.
> >
> > I applied the fix and it helped, but I also get an error like the one
> > mentioned in this thread (NullPointerException), when a referenced
> > schema cannot be found!
> >
> > But that is not the worst part. Once I run into that error, all later
> > attempts to create using a dataFactory from the context also fail, but
> > this time with the following error:
> >
> > java.lang.ClassCastException:
> > org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
> > commonj.sdo.DataObject
> > at
> >
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:61)
> > at
> >
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> >
> > Any ideas?
> >
> > Could you describe some helpercontext scenarios? I am specifically
> > wondering how long the helperContext instance should live. Currently I
> > am trying to use a long living context inside a singleton - imagining
it
> > is the most efficient way. Is that recommendable?
> >
> > /Chr
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 27. marts 2007 16:27
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Hi Christian,
> >
> > Your schema seems to be using http:// schemaLocations. For performance
> > reasons, we recently disabled that, but I guess we really shouldn't do
> > that, without it being an option. We will fix it in the next driver.
> >
> > If you want to try it out yourself, the fix is to comment out line
2473
> > in
> > DataObjectUtil:
> >
> > //resourceSet.setURIConverter(new SDOURIConverterImpl());
> >
> > Frank.
> >
> > "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
> >
> > wrote on 03/27/2007 03:51:43 AM:
> >
> > > Hi again.
> > >
> > > Though my simple testcase now functions, I have run into a
nullpointer
> > > exception with a schema that functions in M2.
> > >
> > > java.lang.NullPointerException
> > > at
> > >
> >
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> > > oreBuilder.java:123)
> > >
> > > As far as I can tell: In BaseSDOXSDEcoreBuilder:
> > >
> > > protected EStructuralFeature createFeature
> > > (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> > > String name, XSDComponent xsdComponent, int minOccurs, int
> > > maxOccurs) {
> > >
> > > XSDTypeDefinition elementTypeDefinition =
> > > getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
> > >
> > > The call to getEffectiveTypeDefinition returns null, resulting in
the
> > > nullpointer in the next call to
> > >
> > > EClassifier eClassifier = getEClassifier(elementTypeDefinition);
> > >
> > > The schema has references to other schemas and it is in the first of
> > > those (StreetName) it fails.
> > >
> > > This is the schema I try to define:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > >
> >
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> > > mas/2007/01/01/"
> > > xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> > > xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> > > /01/01/" elementFormDefault="qualified" xml:lang="en">
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _PostCodeIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _DistrictName.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _StreetName.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _StreetBuildingIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _DistrictSubdivisionIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _FloorIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _SuiteIdentifier.xsd"/>
> > > <annotation>
> > > <documentation/>
> > > </annotation>
> > > <element name="InstitutionAddress"
> > > type="brugerinformation:InstitutionAddressType"/>
> > > <complexType name="InstitutionAddressType">
> > > <sequence>
> > > <element name="DaycareServiceName"
> > > type="string"/>
> > > <element ref="DKCC:StreetName"/>
> > > <element ref="DKCC2:StreetBuildingIdentifier"/>
> > > <element ref="DKCC2:FloorIdentifier"
> > > minOccurs="0"/>
> > > <element ref="DKCC2:SuiteIdentifier"
> > > minOccurs="0"/>
> > > <element ref="DKCC:PostCodeIdentifier"/>
> > > <element ref="DKCC:DistrictName"/>
> > > <element
> > > ref="DKCC:DistrictSubdivisionIdentifier"/>
> > > <element name="InstitutionPhonenrText"
> > > type="string"/>
> > > <element name="EmailaddText" type="string"/>
> > > <element name="WeblinkText" type="string"/>
> > > </sequence>
> > > </complexType>
> > > </schema>
> > >
> > > Any ideas?
> > >
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 26. marts 2007 19:12
> > > To: tuscany-user@ws.apache.org
> > > Subject: RE: SDO Java M3 Release Candidate RC1
> > >
> > > You need to get your DataFactory from the HelperContext:
> > >
> > > DataObject documentDataObject =
hc.getDataFactory().create(namespace,
> > > "DocumentRoot");
> > >
> > > You should generally stop using INSTANCE fields in all cases,
because
> > > they
> > > are probably going to be deprecated in the next version of SDO.
> > > HelperContext is the replacement. It defines a metadata scope, so
you
> > > should always use it to get the helpers for your scope.
> > >
> > > Frank.
> > >
> > > "Christian Landbo Frederiksen"
> > <Ch...@ementor.dk>
> > >
> > > wrote on 03/26/2007 01:01:00 PM:
> > >
> > > >
> > > > In M2 & M3 this works for a specific schema:
> > > >
> > > > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > > > DataObject documentDataObject =
> > DataFactory.INSTANCE.create(namespace,
> > > > "DocumentRoot");
> > > >
> > > > But this doesn't
> > > >
> > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> > > >
> > > > DataObject documentDataObject =
> > DataFactory.INSTANCE.create(namespace,
> > > > "DocumentRoot");
> > > >
> > > >
> > > > java.lang.IllegalArgumentException
> > > > at
> > > >
> > >
> >
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > a:63)
> > > > at
> > > >
> > >
> >
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > a:46)
> > > > at
> > > >
> > >
> >
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > > > ndExtensibleNamespaces.java:153)
> > > > at
> > > >
> > >
> >
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > > > tensibleNamespaces.java:77)
> > > >
> > > >
> > > > Any ideas?
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: 22. marts 2007 13:38
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO Java M3 Release Candidate RC1
> > > >
> > > > Sorry, there's not much documentation, just the JavaDoc. You need
to
> > > get
> > > > a
> > > > HelperContext by calling SDOUtil.createHelperContext() and then
get
> > > your
> > > >
> > > > XSDHelper from it.
> > > >
> > > > If you want the new extensible namespaces behavior you need to
pass
> > > > "true"
> > > > to createHelperContext:
> > > >
> > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > >
> > > > Frank.
> > > >
> > > >
> > > >
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <Ch...@ementor.dk>
> > > >
> > > > 03/22/2007 06:30 AM
> > > > Please respond to
> > > > tuscany-user@ws.apache.org
> > > >
> > > >
> > > > To
> > > > <tu...@ws.apache.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: SDO Java M3 Release Candidate RC1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The testcase I used the last time does not function using SDO M3,
> > but
> > > I
> > > > guess It is because I can't just use XSDHelper.INSTANCE. I
remember
> > > > Frank
> > > > mentioning something about helpercontexts. Have you got any
> > > > documentation
> > > > as to hov this is done.
> > > >
> > > > /Chr
> > > >
> > > > ps. the test case is the one from:
> > > >
> > >
> >
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > > > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > > > <
> > > >
> > >
> >
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > > >
> > >
> >
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > > > .issuetabpanels:comment-tabpanel%23action_12473251
> > > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: Fri 3/16/2007 9:14 AM
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: Re: SDO Java M3 Release Candidate RC1
> > > >
> > > >
> > > >
> > > > Christian,
> > > > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
> > in
> > > > the
> > > > binary release.
> > > > Regards, Kelvin.
> > > >
> > > > On 15/03/07, Christian Landbo Frederiksen <
> > > > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > > > >
> > > > >
> > > > > What version of EMF and SDO api is needed for this release?
> > > > >
> > > > > -----Original Message-----
> > > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > > Sent: 15. marts 2007 16:42
> > > > > To: tuscany-dev; Tuscany Users
> > > > > Subject: SDO Java M3 Release Candidate RC1
> > > > >
> > > > > I have posted an SDO Java M3 release candidate here:
> > > > >
> > > >
> > >
> >
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > > > pache.org/%7Erobbinspg/M3-RC1/>
> > > > >
> > > > > Please take a look at this and try it out, so that I can pick up
> > any
> > > > > errors
> > > > > quickly and move towards a vote on a proper release in the short
> > > term.
> > > > >
> > > > > Thanks, Kelvin.
> > > > >
> > > > >
> > >
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
It looks like we sometimes leave the type registry in a corrupt state
after a type fails to resolve.
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/28/2007 12:35:31 PM:
>
> Ok I'll do that - but do you know why this happens after something has
> failed on otherwise correct schemas?
>
> /Chr
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 28. marts 2007 17:03
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Christian,
>
> This is definitely a bug. It is supposed to treat elements of
> "unresolved
> types" as "anyType", but we seem to have missed a couple of guards for
> null (unresolved) type in our XSDEcoreBuilder subclass.
>
> Please open a JIRA, and we will fix it soon.
>
> Thanks,
> Frank.
>
> "Christian Landbo Frederiksen" <Ch...@ementor.dk>
>
> wrote on 03/28/2007 09:47:02 AM:
>
> > Hi Kelvin
> >
> > I can't seem to find out precisely what causes it, because I can
> > generate a test case where this does not occur.
> > Fortunately I can also generate one where it does.
> >
> > Let me first say that if I create a new helperContext when the
> > IllegalArgumentException occurs the problem can be avoided...
> >
> > Since I am not sure how else to supply this I have just done a
> > copy/paste og the test case (JUnit 3.8):
> >
> > --------------- COPY -------------------
> >
> >
> > package dk.test;
> > import junit.framework.TestCase;
> > import org.apache.tuscany.sdo.util.SDOUtil;
> > import commonj.sdo.helper.HelperContext;
> >
> > public class TestSDOErronousSchemaReferences extends TestCase {
> > private HelperContext helperContext;
> > public TestSDOErronousSchemaReferences(String arg0) {
> > super(arg0);
> > this.helperContext = SDOUtil.createHelperContext(true);
> > }
> > public void testSDOErronousSchemaReferences() {
> >
> > try {
> > String xsd = "<?xml version=\"1.0\"
> > encoding=\"ISO-8859-1\"?> <schema
> > xmlns=\"http://www.w3.org/2001/XMLSchema\"
> >
> xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
> > emas/2007/01/01/\"
> > xmlns:XKOM=\"http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/\"
> > xmlns:DKCC=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> > xmlns:DKCC2=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> >
> targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
> > 7/01/01/\" elementFormDefault=\"qualified\" xml:lang=\"en\"><import
> > namespace=\"http://rerp.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> > C_PostCodeIdentifier.xsd\"/><import
> > namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> > C_DistrictName.xsd\"/><import
> > namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> > C_StreetName.xsd\"/><import
> > namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> > C_StreetBuildingIdentifier.xsd\"/><import
> > namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> > C_DistrictSubdivisionIdentifier.xsd\"/><import
> > namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> > C_FloorIdentifier.xsd\"/><import
> > namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> >
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> >
> C_SuiteIdentifier.xsd\"/><annotation><documentation/></annotation><eleme
> > nt name=\"InstitutionAddress\"
> > type=\"brugerinformation:InstitutionAddressType\"/><complexType
> > name=\"InstitutionAddressType\"><sequence><element
> > name=\"DaycareServiceName\" type=\"string\"/><element
> > ref=\"DKCC:StreetName\"/><element
> > ref=\"DKCC2:StreetBuildingIdentifier\"/><element
> > ref=\"DKCC2:FloorIdentifier\" minOccurs=\"0\"/><element
> > ref=\"DKCC2:SuiteIdentifier\" minOccurs=\"0\"/><element
> > ref=\"DKCC:PostCodeIdentifier\"/><element
> > ref=\"DKCC:DistrictName\"/><element
> > ref=\"DKCC:DistrictSubdivisionIdentifier\"/><element
> > name=\"InstitutionPhonenrText\" type=\"string\"/><element
> > name=\"EmailaddText\" type=\"string\"/><element name=\"WeblinkText\"
> > type=\"string\"/></sequence></complexType></schema>";
> > String root = "InstitutionAddress";
> > String namespace =
> > "http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007/01/01/";
> >
> > System.out.println("First define with erronous
> > reference");
> > try {
> > test(xsd, root, namespace);
> > } catch (IllegalArgumentException e) {
> > e.printStackTrace();
> > }
> >
> > System.out.println("\nSecond define just dummy
> > valid schema");
> > xsd = "<?xml version=\"1.0\"
> > encoding=\"ISO-8859-1\"?> <schema
> > xmlns=\"http://www.w3.org/2001/XMLSchema\"
> >
> xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
> > emas/2007/01/01/\"
> >
> targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
> > 7/01/01/\" elementFormDefault=\"qualified\"
> > xml:lang=\"EN\"><annotation><documentation/></annotation><element
> > name=\"InstitutionSpacePerkid\"
> > type=\"brugerinformation:InstitutionSpacePerkidType\"/><complexType
> > name=\"InstitutionSpacePerkidType\"><sequence><element
> > name=\"InstitutionSpacesqmQuantity\"
> >
> type=\"brugerinformation:InstitutionSpacesqmQuantityType\"/></sequence><
> > /complexType><simpleType
> > name=\"InstitutionSpacesqmQuantityType\"><restriction
> > base=\"unsignedInt\"/></simpleType></schema>";
> > root = "InstitutionSpacePerkid";
> >
> > try {
> > test(xsd, root, namespace);
> > } catch (Exception e) {
> > e.printStackTrace();
> > throw e;
> > }
> > } catch (Exception e) {
> > fail(e.toString());
> > }
> > }
> >
> > public void test(final String xsdFile, final String rootElement,
> > final String namespace) throws Exception {
> >
> > System.out.println("Calling define...");
> > this.helperContext.getXSDHelper().define(new
> > String(xsdFile.getBytes("ISO-8859-1")));
> > System.out.println("Define successful...");
> >
> > System.out.println("Calling create...");
> > this.helperContext.getDataFactory().create(namespace,
> > rootElement + "Type");
> > System.out.println("Create successful...\n");
> >
> > return;
> > }
> > }
> >
> > ------------------ END COPY --------------------
> >
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 28. marts 2007 09:53
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> > Hi Christian,
> > could you please post some code snippets or better still a test
> case.
> > It
> > appears that the Type that you are trying to create an instance of is
> > associated with an EMF factory rather than an SDO Factory.
> >
> > On the subject of HelperContext lifecycle, there's no constraint on
> the
> > longevity of a HelperContext instance. At the moment I imagine that
> > each
> > instance would be relatively long lived, since there are no fine
> > grained
> > controls on the lifecycle of the Types within a scope. So I imagine
> > that
> > for many applications a single HelperContext will suffice for the
> > lifetime
> > of the application.
> >
> > It may be the case that in the future we provide ways of associating
> > HelperContexts in order that one may delegate to another/others. I
> can
> > imagine in that scenario more opportunities to control the type system
> > by
> > having short lived HelperContext instances, but as I say, we don't
> > have
> > that yet.
> >
> > Regards, Kelvin.
> >
> >
> > On 27/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > > Hi Frank et. al.
> > >
> > > I applied the fix and it helped, but I also get an error like the
> one
> > > mentioned in this thread (NullPointerException), when a referenced
> > > schema cannot be found!
> > >
> > > But that is not the worst part. Once I run into that error, all
> later
> > > attempts to create using a dataFactory from the context also fail,
> but
> > > this time with the following error:
> > >
> > > java.lang.ClassCastException:
> > > org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
> > > commonj.sdo.DataObject
> > > at
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > a:61)
> > > at
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > a:46)
> > >
> > > Any ideas?
> > >
> > > Could you describe some helpercontext scenarios? I am specifically
> > > wondering how long the helperContext instance should live. Currently
> I
> > > am trying to use a long living context inside a singleton -
> imagining
> > it
> > > is the most efficient way. Is that recommendable?
> > >
> > > /Chr
> > >
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 27. marts 2007 16:27
> > > To: tuscany-user@ws.apache.org
> > > Subject: RE: SDO Java M3 Release Candidate RC1
> > >
> > > Hi Christian,
> > >
> > > Your schema seems to be using http:// schemaLocations. For
> performance
> > > reasons, we recently disabled that, but I guess we really shouldn't
> do
> > > that, without it being an option. We will fix it in the next driver.
> > >
> > > If you want to try it out yourself, the fix is to comment out line
> > 2473
> > > in
> > > DataObjectUtil:
> > >
> > > //resourceSet.setURIConverter(new SDOURIConverterImpl());
> > >
> > > Frank.
> > >
> > > "Christian Landbo Frederiksen"
> > <Ch...@ementor.dk>
> > >
> > > wrote on 03/27/2007 03:51:43 AM:
> > >
> > > > Hi again.
> > > >
> > > > Though my simple testcase now functions, I have run into a
> > nullpointer
> > > > exception with a schema that functions in M2.
> > > >
> > > > java.lang.NullPointerException
> > > > at
> > > >
> > >
> >
> org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> > > > oreBuilder.java:123)
> > > >
> > > > As far as I can tell: In BaseSDOXSDEcoreBuilder:
> > > >
> > > > protected EStructuralFeature createFeature
> > > > (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> > > > String name, XSDComponent xsdComponent, int minOccurs, int
> > > > maxOccurs) {
> > > >
> > > > XSDTypeDefinition elementTypeDefinition =
> > > > getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
> > > >
> > > > The call to getEffectiveTypeDefinition returns null, resulting in
> > the
> > > > nullpointer in the next call to
> > > >
> > > > EClassifier eClassifier =
> getEClassifier(elementTypeDefinition);
> > > >
> > > > The schema has references to other schemas and it is in the first
> of
> > > > those (StreetName) it fails.
> > > >
> > > > This is the schema I try to define:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > > >
> > >
> >
> xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> > > > mas/2007/01/01/"
> > > > xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> > > > xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > > xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > > >
> > >
> >
> targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> > > > /01/01/" elementFormDefault="qualified" xml:lang="en">
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > > _PostCodeIdentifier.xsd"/>
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > > _DistrictName.xsd"/>
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > > _StreetName.xsd"/>
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > > _StreetBuildingIdentifier.xsd"/>
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > > _DistrictSubdivisionIdentifier.xsd"/>
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > > _FloorIdentifier.xsd"/>
> > > > <import
> > > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > > >
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > > _SuiteIdentifier.xsd"/>
> > > > <annotation>
> > > > <documentation/>
> > > > </annotation>
> > > > <element name="InstitutionAddress"
> > > > type="brugerinformation:InstitutionAddressType"/>
> > > > <complexType name="InstitutionAddressType">
> > > > <sequence>
> > > > <element name="DaycareServiceName"
> > > > type="string"/>
> > > > <element ref="DKCC:StreetName"/>
> > > > <element ref="DKCC2:StreetBuildingIdentifier"/>
> > > > <element ref="DKCC2:FloorIdentifier"
> > > > minOccurs="0"/>
> > > > <element ref="DKCC2:SuiteIdentifier"
> > > > minOccurs="0"/>
> > > > <element ref="DKCC:PostCodeIdentifier"/>
> > > > <element ref="DKCC:DistrictName"/>
> > > > <element
> > > > ref="DKCC:DistrictSubdivisionIdentifier"/>
> > > > <element name="InstitutionPhonenrText"
> > > > type="string"/>
> > > > <element name="EmailaddText" type="string"/>
> > > > <element name="WeblinkText" type="string"/>
> > > > </sequence>
> > > > </complexType>
> > > > </schema>
> > > >
> > > > Any ideas?
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: 26. marts 2007 19:12
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO Java M3 Release Candidate RC1
> > > >
> > > > You need to get your DataFactory from the HelperContext:
> > > >
> > > > DataObject documentDataObject =
> > hc.getDataFactory().create(namespace,
> > > > "DocumentRoot");
> > > >
> > > > You should generally stop using INSTANCE fields in all cases,
> > because
> > > > they
> > > > are probably going to be deprecated in the next version of SDO.
> > > > HelperContext is the replacement. It defines a metadata scope, so
> > you
> > > > should always use it to get the helpers for your scope.
> > > >
> > > > Frank.
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <Ch...@ementor.dk>
> > > >
> > > > wrote on 03/26/2007 01:01:00 PM:
> > > >
> > > > >
> > > > > In M2 & M3 this works for a specific schema:
> > > > >
> > > > > XSDHelper.INSTANCE.define(new
> String(xsdFile.getBytes("UTF-8")));
> > > > > DataObject documentDataObject =
> > > DataFactory.INSTANCE.create(namespace,
> > > > > "DocumentRoot");
> > > > >
> > > > > But this doesn't
> > > > >
> > > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > > > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> > > > >
> > > > > DataObject documentDataObject =
> > > DataFactory.INSTANCE.create(namespace,
> > > > > "DocumentRoot");
> > > > >
> > > > >
> > > > > java.lang.IllegalArgumentException
> > > > > at
> > > > >
> > > >
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > > a:63)
> > > > > at
> > > > >
> > > >
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > > a:46)
> > > > > at
> > > > >
> > > >
> > >
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > > > > ndExtensibleNamespaces.java:153)
> > > > > at
> > > > >
> > > >
> > >
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > > > > tensibleNamespaces.java:77)
> > > > >
> > > > >
> > > > > Any ideas?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > > Sent: 22. marts 2007 13:38
> > > > > To: tuscany-user@ws.apache.org
> > > > > Subject: RE: SDO Java M3 Release Candidate RC1
> > > > >
> > > > > Sorry, there's not much documentation, just the JavaDoc. You
> need
> > to
> > > > get
> > > > > a
> > > > > HelperContext by calling SDOUtil.createHelperContext() and then
> > get
> > > > your
> > > > >
> > > > > XSDHelper from it.
> > > > >
> > > > > If you want the new extensible namespaces behavior you need to
> > pass
> > > > > "true"
> > > > > to createHelperContext:
> > > > >
> > > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > > >
> > > > > Frank.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Christian Landbo Frederiksen"
> > > > <Ch...@ementor.dk>
> > > > >
> > > > > 03/22/2007 06:30 AM
> > > > > Please respond to
> > > > > tuscany-user@ws.apache.org
> > > > >
> > > > >
> > > > > To
> > > > > <tu...@ws.apache.org>
> > > > > cc
> > > > >
> > > > > Subject
> > > > > RE: SDO Java M3 Release Candidate RC1
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The testcase I used the last time does not function using SDO
> M3,
> > > but
> > > > I
> > > > > guess It is because I can't just use XSDHelper.INSTANCE. I
> > remember
> > > > > Frank
> > > > > mentioning something about helpercontexts. Have you got any
> > > > > documentation
> > > > > as to hov this is done.
> > > > >
> > > > > /Chr
> > > > >
> > > > > ps. the test case is the one from:
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > > > > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > > > > <
> > > > >
> > > >
> > >
> >
> https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > > > >
> > > >
> > >
> >
> pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > > > > .issuetabpanels:comment-tabpanel%23action_12473251
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > > Sent: Fri 3/16/2007 9:14 AM
> > > > > To: tuscany-user@ws.apache.org
> > > > > Subject: Re: SDO Java M3 Release Candidate RC1
> > > > >
> > > > >
> > > > >
> > > > > Christian,
> > > > > The required jars for EMF 2.2.2 and the SDO 2.1 API are
> packaged
> > > in
> > > > > the
> > > > > binary release.
> > > > > Regards, Kelvin.
> > > > >
> > > > > On 15/03/07, Christian Landbo Frederiksen <
> > > > > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > > > > >
> > > > > >
> > > > > > What version of EMF and SDO api is needed for this release?
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > > > Sent: 15. marts 2007 16:42
> > > > > > To: tuscany-dev; Tuscany Users
> > > > > > Subject: SDO Java M3 Release Candidate RC1
> > > > > >
> > > > > > I have posted an SDO Java M3 release candidate here:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > > > > pache.org/%7Erobbinspg/M3-RC1/>
> > > > > >
> > > > > > Please take a look at this and try it out, so that I can pick
> up
> > > any
> > > > > > errors
> > > > > > quickly and move towards a vote on a proper release in the
> short
> > > > term.
> > > > > >
> > > > > > Thanks, Kelvin.
> > > > > >
> > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail:
> tuscany-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Ok I'll do that - but do you know why this happens after something has
failed on otherwise correct schemas?
/Chr
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 28. marts 2007 17:03
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Christian,
This is definitely a bug. It is supposed to treat elements of
"unresolved
types" as "anyType", but we seem to have missed a couple of guards for
null (unresolved) type in our XSDEcoreBuilder subclass.
Please open a JIRA, and we will fix it soon.
Thanks,
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/28/2007 09:47:02 AM:
> Hi Kelvin
>
> I can't seem to find out precisely what causes it, because I can
> generate a test case where this does not occur.
> Fortunately I can also generate one where it does.
>
> Let me first say that if I create a new helperContext when the
> IllegalArgumentException occurs the problem can be avoided...
>
> Since I am not sure how else to supply this I have just done a
> copy/paste og the test case (JUnit 3.8):
>
> --------------- COPY -------------------
>
>
> package dk.test;
> import junit.framework.TestCase;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.helper.HelperContext;
>
> public class TestSDOErronousSchemaReferences extends TestCase {
> private HelperContext helperContext;
> public TestSDOErronousSchemaReferences(String arg0) {
> super(arg0);
> this.helperContext = SDOUtil.createHelperContext(true);
> }
> public void testSDOErronousSchemaReferences() {
>
> try {
> String xsd = "<?xml version=\"1.0\"
> encoding=\"ISO-8859-1\"?> <schema
> xmlns=\"http://www.w3.org/2001/XMLSchema\"
>
xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
> emas/2007/01/01/\"
> xmlns:XKOM=\"http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/\"
> xmlns:DKCC=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> xmlns:DKCC2=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
>
targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
> 7/01/01/\" elementFormDefault=\"qualified\" xml:lang=\"en\"><import
> namespace=\"http://rerp.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_PostCodeIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_DistrictName.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_StreetName.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> C_StreetBuildingIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_DistrictSubdivisionIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> C_FloorIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
>
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
>
C_SuiteIdentifier.xsd\"/><annotation><documentation/></annotation><eleme
> nt name=\"InstitutionAddress\"
> type=\"brugerinformation:InstitutionAddressType\"/><complexType
> name=\"InstitutionAddressType\"><sequence><element
> name=\"DaycareServiceName\" type=\"string\"/><element
> ref=\"DKCC:StreetName\"/><element
> ref=\"DKCC2:StreetBuildingIdentifier\"/><element
> ref=\"DKCC2:FloorIdentifier\" minOccurs=\"0\"/><element
> ref=\"DKCC2:SuiteIdentifier\" minOccurs=\"0\"/><element
> ref=\"DKCC:PostCodeIdentifier\"/><element
> ref=\"DKCC:DistrictName\"/><element
> ref=\"DKCC:DistrictSubdivisionIdentifier\"/><element
> name=\"InstitutionPhonenrText\" type=\"string\"/><element
> name=\"EmailaddText\" type=\"string\"/><element name=\"WeblinkText\"
> type=\"string\"/></sequence></complexType></schema>";
> String root = "InstitutionAddress";
> String namespace =
> "http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007/01/01/";
>
> System.out.println("First define with erronous
> reference");
> try {
> test(xsd, root, namespace);
> } catch (IllegalArgumentException e) {
> e.printStackTrace();
> }
>
> System.out.println("\nSecond define just dummy
> valid schema");
> xsd = "<?xml version=\"1.0\"
> encoding=\"ISO-8859-1\"?> <schema
> xmlns=\"http://www.w3.org/2001/XMLSchema\"
>
xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
> emas/2007/01/01/\"
>
targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
> 7/01/01/\" elementFormDefault=\"qualified\"
> xml:lang=\"EN\"><annotation><documentation/></annotation><element
> name=\"InstitutionSpacePerkid\"
> type=\"brugerinformation:InstitutionSpacePerkidType\"/><complexType
> name=\"InstitutionSpacePerkidType\"><sequence><element
> name=\"InstitutionSpacesqmQuantity\"
>
type=\"brugerinformation:InstitutionSpacesqmQuantityType\"/></sequence><
> /complexType><simpleType
> name=\"InstitutionSpacesqmQuantityType\"><restriction
> base=\"unsignedInt\"/></simpleType></schema>";
> root = "InstitutionSpacePerkid";
>
> try {
> test(xsd, root, namespace);
> } catch (Exception e) {
> e.printStackTrace();
> throw e;
> }
> } catch (Exception e) {
> fail(e.toString());
> }
> }
>
> public void test(final String xsdFile, final String rootElement,
> final String namespace) throws Exception {
>
> System.out.println("Calling define...");
> this.helperContext.getXSDHelper().define(new
> String(xsdFile.getBytes("ISO-8859-1")));
> System.out.println("Define successful...");
>
> System.out.println("Calling create...");
> this.helperContext.getDataFactory().create(namespace,
> rootElement + "Type");
> System.out.println("Create successful...\n");
>
> return;
> }
> }
>
> ------------------ END COPY --------------------
>
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 28. marts 2007 09:53
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO Java M3 Release Candidate RC1
>
> Hi Christian,
> could you please post some code snippets or better still a test
case.
> It
> appears that the Type that you are trying to create an instance of is
> associated with an EMF factory rather than an SDO Factory.
>
> On the subject of HelperContext lifecycle, there's no constraint on
the
> longevity of a HelperContext instance. At the moment I imagine that
> each
> instance would be relatively long lived, since there are no fine
> grained
> controls on the lifecycle of the Types within a scope. So I imagine
> that
> for many applications a single HelperContext will suffice for the
> lifetime
> of the application.
>
> It may be the case that in the future we provide ways of associating
> HelperContexts in order that one may delegate to another/others. I
can
> imagine in that scenario more opportunities to control the type system
> by
> having short lived HelperContext instances, but as I say, we don't
> have
> that yet.
>
> Regards, Kelvin.
>
>
> On 27/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> > Hi Frank et. al.
> >
> > I applied the fix and it helped, but I also get an error like the
one
> > mentioned in this thread (NullPointerException), when a referenced
> > schema cannot be found!
> >
> > But that is not the worst part. Once I run into that error, all
later
> > attempts to create using a dataFactory from the context also fail,
but
> > this time with the following error:
> >
> > java.lang.ClassCastException:
> > org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
> > commonj.sdo.DataObject
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:61)
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> >
> > Any ideas?
> >
> > Could you describe some helpercontext scenarios? I am specifically
> > wondering how long the helperContext instance should live. Currently
I
> > am trying to use a long living context inside a singleton -
imagining
> it
> > is the most efficient way. Is that recommendable?
> >
> > /Chr
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 27. marts 2007 16:27
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Hi Christian,
> >
> > Your schema seems to be using http:// schemaLocations. For
performance
> > reasons, we recently disabled that, but I guess we really shouldn't
do
> > that, without it being an option. We will fix it in the next driver.
> >
> > If you want to try it out yourself, the fix is to comment out line
> 2473
> > in
> > DataObjectUtil:
> >
> > //resourceSet.setURIConverter(new SDOURIConverterImpl());
> >
> > Frank.
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > wrote on 03/27/2007 03:51:43 AM:
> >
> > > Hi again.
> > >
> > > Though my simple testcase now functions, I have run into a
> nullpointer
> > > exception with a schema that functions in M2.
> > >
> > > java.lang.NullPointerException
> > > at
> > >
> >
>
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> > > oreBuilder.java:123)
> > >
> > > As far as I can tell: In BaseSDOXSDEcoreBuilder:
> > >
> > > protected EStructuralFeature createFeature
> > > (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> > > String name, XSDComponent xsdComponent, int minOccurs, int
> > > maxOccurs) {
> > >
> > > XSDTypeDefinition elementTypeDefinition =
> > > getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
> > >
> > > The call to getEffectiveTypeDefinition returns null, resulting in
> the
> > > nullpointer in the next call to
> > >
> > > EClassifier eClassifier =
getEClassifier(elementTypeDefinition);
> > >
> > > The schema has references to other schemas and it is in the first
of
> > > those (StreetName) it fails.
> > >
> > > This is the schema I try to define:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > >
> >
>
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> > > mas/2007/01/01/"
> > > xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> > > xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
>
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> > > /01/01/" elementFormDefault="qualified" xml:lang="en">
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _PostCodeIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _DistrictName.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _StreetName.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _StreetBuildingIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _DistrictSubdivisionIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _FloorIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _SuiteIdentifier.xsd"/>
> > > <annotation>
> > > <documentation/>
> > > </annotation>
> > > <element name="InstitutionAddress"
> > > type="brugerinformation:InstitutionAddressType"/>
> > > <complexType name="InstitutionAddressType">
> > > <sequence>
> > > <element name="DaycareServiceName"
> > > type="string"/>
> > > <element ref="DKCC:StreetName"/>
> > > <element ref="DKCC2:StreetBuildingIdentifier"/>
> > > <element ref="DKCC2:FloorIdentifier"
> > > minOccurs="0"/>
> > > <element ref="DKCC2:SuiteIdentifier"
> > > minOccurs="0"/>
> > > <element ref="DKCC:PostCodeIdentifier"/>
> > > <element ref="DKCC:DistrictName"/>
> > > <element
> > > ref="DKCC:DistrictSubdivisionIdentifier"/>
> > > <element name="InstitutionPhonenrText"
> > > type="string"/>
> > > <element name="EmailaddText" type="string"/>
> > > <element name="WeblinkText" type="string"/>
> > > </sequence>
> > > </complexType>
> > > </schema>
> > >
> > > Any ideas?
> > >
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 26. marts 2007 19:12
> > > To: tuscany-user@ws.apache.org
> > > Subject: RE: SDO Java M3 Release Candidate RC1
> > >
> > > You need to get your DataFactory from the HelperContext:
> > >
> > > DataObject documentDataObject =
> hc.getDataFactory().create(namespace,
> > > "DocumentRoot");
> > >
> > > You should generally stop using INSTANCE fields in all cases,
> because
> > > they
> > > are probably going to be deprecated in the next version of SDO.
> > > HelperContext is the replacement. It defines a metadata scope, so
> you
> > > should always use it to get the helpers for your scope.
> > >
> > > Frank.
> > >
> > > "Christian Landbo Frederiksen"
> > <Ch...@ementor.dk>
> > >
> > > wrote on 03/26/2007 01:01:00 PM:
> > >
> > > >
> > > > In M2 & M3 this works for a specific schema:
> > > >
> > > > XSDHelper.INSTANCE.define(new
String(xsdFile.getBytes("UTF-8")));
> > > > DataObject documentDataObject =
> > DataFactory.INSTANCE.create(namespace,
> > > > "DocumentRoot");
> > > >
> > > > But this doesn't
> > > >
> > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> > > >
> > > > DataObject documentDataObject =
> > DataFactory.INSTANCE.create(namespace,
> > > > "DocumentRoot");
> > > >
> > > >
> > > > java.lang.IllegalArgumentException
> > > > at
> > > >
> > >
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > a:63)
> > > > at
> > > >
> > >
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > a:46)
> > > > at
> > > >
> > >
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > > > ndExtensibleNamespaces.java:153)
> > > > at
> > > >
> > >
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > > > tensibleNamespaces.java:77)
> > > >
> > > >
> > > > Any ideas?
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: 22. marts 2007 13:38
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO Java M3 Release Candidate RC1
> > > >
> > > > Sorry, there's not much documentation, just the JavaDoc. You
need
> to
> > > get
> > > > a
> > > > HelperContext by calling SDOUtil.createHelperContext() and then
> get
> > > your
> > > >
> > > > XSDHelper from it.
> > > >
> > > > If you want the new extensible namespaces behavior you need to
> pass
> > > > "true"
> > > > to createHelperContext:
> > > >
> > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > >
> > > > Frank.
> > > >
> > > >
> > > >
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <Ch...@ementor.dk>
> > > >
> > > > 03/22/2007 06:30 AM
> > > > Please respond to
> > > > tuscany-user@ws.apache.org
> > > >
> > > >
> > > > To
> > > > <tu...@ws.apache.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: SDO Java M3 Release Candidate RC1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The testcase I used the last time does not function using SDO
M3,
> > but
> > > I
> > > > guess It is because I can't just use XSDHelper.INSTANCE. I
> remember
> > > > Frank
> > > > mentioning something about helpercontexts. Have you got any
> > > > documentation
> > > > as to hov this is done.
> > > >
> > > > /Chr
> > > >
> > > > ps. the test case is the one from:
> > > >
> > >
> >
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > > > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > > > <
> > > >
> > >
> >
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > > >
> > >
> >
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > > > .issuetabpanels:comment-tabpanel%23action_12473251
> > > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: Fri 3/16/2007 9:14 AM
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: Re: SDO Java M3 Release Candidate RC1
> > > >
> > > >
> > > >
> > > > Christian,
> > > > The required jars for EMF 2.2.2 and the SDO 2.1 API are
packaged
> > in
> > > > the
> > > > binary release.
> > > > Regards, Kelvin.
> > > >
> > > > On 15/03/07, Christian Landbo Frederiksen <
> > > > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > > > >
> > > > >
> > > > > What version of EMF and SDO api is needed for this release?
> > > > >
> > > > > -----Original Message-----
> > > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > > Sent: 15. marts 2007 16:42
> > > > > To: tuscany-dev; Tuscany Users
> > > > > Subject: SDO Java M3 Release Candidate RC1
> > > > >
> > > > > I have posted an SDO Java M3 release candidate here:
> > > > >
> > > >
> > >
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > > > pache.org/%7Erobbinspg/M3-RC1/>
> > > > >
> > > > > Please take a look at this and try it out, so that I can pick
up
> > any
> > > > > errors
> > > > > quickly and move towards a vote on a proper release in the
short
> > > term.
> > > > >
> > > > > Thanks, Kelvin.
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Christian,
This is definitely a bug. It is supposed to treat elements of "unresolved
types" as "anyType", but we seem to have missed a couple of guards for
null (unresolved) type in our XSDEcoreBuilder subclass.
Please open a JIRA, and we will fix it soon.
Thanks,
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/28/2007 09:47:02 AM:
> Hi Kelvin
>
> I can't seem to find out precisely what causes it, because I can
> generate a test case where this does not occur.
> Fortunately I can also generate one where it does.
>
> Let me first say that if I create a new helperContext when the
> IllegalArgumentException occurs the problem can be avoided...
>
> Since I am not sure how else to supply this I have just done a
> copy/paste og the test case (JUnit 3.8):
>
> --------------- COPY -------------------
>
>
> package dk.test;
> import junit.framework.TestCase;
> import org.apache.tuscany.sdo.util.SDOUtil;
> import commonj.sdo.helper.HelperContext;
>
> public class TestSDOErronousSchemaReferences extends TestCase {
> private HelperContext helperContext;
> public TestSDOErronousSchemaReferences(String arg0) {
> super(arg0);
> this.helperContext = SDOUtil.createHelperContext(true);
> }
> public void testSDOErronousSchemaReferences() {
>
> try {
> String xsd = "<?xml version=\"1.0\"
> encoding=\"ISO-8859-1\"?> <schema
> xmlns=\"http://www.w3.org/2001/XMLSchema\"
> xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
> emas/2007/01/01/\"
> xmlns:XKOM=\"http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/\"
> xmlns:DKCC=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> xmlns:DKCC2=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
> 7/01/01/\" elementFormDefault=\"qualified\" xml:lang=\"en\"><import
> namespace=\"http://rerp.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_PostCodeIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_DistrictName.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_StreetName.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> C_StreetBuildingIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
> C_DistrictSubdivisionIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> C_FloorIdentifier.xsd\"/><import
> namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
> schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
> C_SuiteIdentifier.xsd\"/><annotation><documentation/></annotation><eleme
> nt name=\"InstitutionAddress\"
> type=\"brugerinformation:InstitutionAddressType\"/><complexType
> name=\"InstitutionAddressType\"><sequence><element
> name=\"DaycareServiceName\" type=\"string\"/><element
> ref=\"DKCC:StreetName\"/><element
> ref=\"DKCC2:StreetBuildingIdentifier\"/><element
> ref=\"DKCC2:FloorIdentifier\" minOccurs=\"0\"/><element
> ref=\"DKCC2:SuiteIdentifier\" minOccurs=\"0\"/><element
> ref=\"DKCC:PostCodeIdentifier\"/><element
> ref=\"DKCC:DistrictName\"/><element
> ref=\"DKCC:DistrictSubdivisionIdentifier\"/><element
> name=\"InstitutionPhonenrText\" type=\"string\"/><element
> name=\"EmailaddText\" type=\"string\"/><element name=\"WeblinkText\"
> type=\"string\"/></sequence></complexType></schema>";
> String root = "InstitutionAddress";
> String namespace =
> "http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007/01/01/";
>
> System.out.println("First define with erronous
> reference");
> try {
> test(xsd, root, namespace);
> } catch (IllegalArgumentException e) {
> e.printStackTrace();
> }
>
> System.out.println("\nSecond define just dummy
> valid schema");
> xsd = "<?xml version=\"1.0\"
> encoding=\"ISO-8859-1\"?> <schema
> xmlns=\"http://www.w3.org/2001/XMLSchema\"
> xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
> emas/2007/01/01/\"
> targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
> 7/01/01/\" elementFormDefault=\"qualified\"
> xml:lang=\"EN\"><annotation><documentation/></annotation><element
> name=\"InstitutionSpacePerkid\"
> type=\"brugerinformation:InstitutionSpacePerkidType\"/><complexType
> name=\"InstitutionSpacePerkidType\"><sequence><element
> name=\"InstitutionSpacesqmQuantity\"
> type=\"brugerinformation:InstitutionSpacesqmQuantityType\"/></sequence><
> /complexType><simpleType
> name=\"InstitutionSpacesqmQuantityType\"><restriction
> base=\"unsignedInt\"/></simpleType></schema>";
> root = "InstitutionSpacePerkid";
>
> try {
> test(xsd, root, namespace);
> } catch (Exception e) {
> e.printStackTrace();
> throw e;
> }
> } catch (Exception e) {
> fail(e.toString());
> }
> }
>
> public void test(final String xsdFile, final String rootElement,
> final String namespace) throws Exception {
>
> System.out.println("Calling define...");
> this.helperContext.getXSDHelper().define(new
> String(xsdFile.getBytes("ISO-8859-1")));
> System.out.println("Define successful...");
>
> System.out.println("Calling create...");
> this.helperContext.getDataFactory().create(namespace,
> rootElement + "Type");
> System.out.println("Create successful...\n");
>
> return;
> }
> }
>
> ------------------ END COPY --------------------
>
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 28. marts 2007 09:53
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO Java M3 Release Candidate RC1
>
> Hi Christian,
> could you please post some code snippets or better still a test case.
> It
> appears that the Type that you are trying to create an instance of is
> associated with an EMF factory rather than an SDO Factory.
>
> On the subject of HelperContext lifecycle, there's no constraint on the
> longevity of a HelperContext instance. At the moment I imagine that
> each
> instance would be relatively long lived, since there are no fine
> grained
> controls on the lifecycle of the Types within a scope. So I imagine
> that
> for many applications a single HelperContext will suffice for the
> lifetime
> of the application.
>
> It may be the case that in the future we provide ways of associating
> HelperContexts in order that one may delegate to another/others. I can
> imagine in that scenario more opportunities to control the type system
> by
> having short lived HelperContext instances, but as I say, we don't
> have
> that yet.
>
> Regards, Kelvin.
>
>
> On 27/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> > Hi Frank et. al.
> >
> > I applied the fix and it helped, but I also get an error like the one
> > mentioned in this thread (NullPointerException), when a referenced
> > schema cannot be found!
> >
> > But that is not the worst part. Once I run into that error, all later
> > attempts to create using a dataFactory from the context also fail, but
> > this time with the following error:
> >
> > java.lang.ClassCastException:
> > org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
> > commonj.sdo.DataObject
> > at
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:61)
> > at
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> >
> > Any ideas?
> >
> > Could you describe some helpercontext scenarios? I am specifically
> > wondering how long the helperContext instance should live. Currently I
> > am trying to use a long living context inside a singleton - imagining
> it
> > is the most efficient way. Is that recommendable?
> >
> > /Chr
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 27. marts 2007 16:27
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Hi Christian,
> >
> > Your schema seems to be using http:// schemaLocations. For performance
> > reasons, we recently disabled that, but I guess we really shouldn't do
> > that, without it being an option. We will fix it in the next driver.
> >
> > If you want to try it out yourself, the fix is to comment out line
> 2473
> > in
> > DataObjectUtil:
> >
> > //resourceSet.setURIConverter(new SDOURIConverterImpl());
> >
> > Frank.
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > wrote on 03/27/2007 03:51:43 AM:
> >
> > > Hi again.
> > >
> > > Though my simple testcase now functions, I have run into a
> nullpointer
> > > exception with a schema that functions in M2.
> > >
> > > java.lang.NullPointerException
> > > at
> > >
> >
> org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> > > oreBuilder.java:123)
> > >
> > > As far as I can tell: In BaseSDOXSDEcoreBuilder:
> > >
> > > protected EStructuralFeature createFeature
> > > (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> > > String name, XSDComponent xsdComponent, int minOccurs, int
> > > maxOccurs) {
> > >
> > > XSDTypeDefinition elementTypeDefinition =
> > > getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
> > >
> > > The call to getEffectiveTypeDefinition returns null, resulting in
> the
> > > nullpointer in the next call to
> > >
> > > EClassifier eClassifier = getEClassifier(elementTypeDefinition);
> > >
> > > The schema has references to other schemas and it is in the first of
> > > those (StreetName) it fails.
> > >
> > > This is the schema I try to define:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > >
> >
> xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> > > mas/2007/01/01/"
> > > xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> > > xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > > xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
> targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> > > /01/01/" elementFormDefault="qualified" xml:lang="en">
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _PostCodeIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _DistrictName.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _StreetName.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _StreetBuildingIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > > _DistrictSubdivisionIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _FloorIdentifier.xsd"/>
> > > <import
> > > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> > >
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > > _SuiteIdentifier.xsd"/>
> > > <annotation>
> > > <documentation/>
> > > </annotation>
> > > <element name="InstitutionAddress"
> > > type="brugerinformation:InstitutionAddressType"/>
> > > <complexType name="InstitutionAddressType">
> > > <sequence>
> > > <element name="DaycareServiceName"
> > > type="string"/>
> > > <element ref="DKCC:StreetName"/>
> > > <element ref="DKCC2:StreetBuildingIdentifier"/>
> > > <element ref="DKCC2:FloorIdentifier"
> > > minOccurs="0"/>
> > > <element ref="DKCC2:SuiteIdentifier"
> > > minOccurs="0"/>
> > > <element ref="DKCC:PostCodeIdentifier"/>
> > > <element ref="DKCC:DistrictName"/>
> > > <element
> > > ref="DKCC:DistrictSubdivisionIdentifier"/>
> > > <element name="InstitutionPhonenrText"
> > > type="string"/>
> > > <element name="EmailaddText" type="string"/>
> > > <element name="WeblinkText" type="string"/>
> > > </sequence>
> > > </complexType>
> > > </schema>
> > >
> > > Any ideas?
> > >
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 26. marts 2007 19:12
> > > To: tuscany-user@ws.apache.org
> > > Subject: RE: SDO Java M3 Release Candidate RC1
> > >
> > > You need to get your DataFactory from the HelperContext:
> > >
> > > DataObject documentDataObject =
> hc.getDataFactory().create(namespace,
> > > "DocumentRoot");
> > >
> > > You should generally stop using INSTANCE fields in all cases,
> because
> > > they
> > > are probably going to be deprecated in the next version of SDO.
> > > HelperContext is the replacement. It defines a metadata scope, so
> you
> > > should always use it to get the helpers for your scope.
> > >
> > > Frank.
> > >
> > > "Christian Landbo Frederiksen"
> > <Ch...@ementor.dk>
> > >
> > > wrote on 03/26/2007 01:01:00 PM:
> > >
> > > >
> > > > In M2 & M3 this works for a specific schema:
> > > >
> > > > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > > > DataObject documentDataObject =
> > DataFactory.INSTANCE.create(namespace,
> > > > "DocumentRoot");
> > > >
> > > > But this doesn't
> > > >
> > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> > > >
> > > > DataObject documentDataObject =
> > DataFactory.INSTANCE.create(namespace,
> > > > "DocumentRoot");
> > > >
> > > >
> > > > java.lang.IllegalArgumentException
> > > > at
> > > >
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > a:63)
> > > > at
> > > >
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > > a:46)
> > > > at
> > > >
> > >
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > > > ndExtensibleNamespaces.java:153)
> > > > at
> > > >
> > >
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > > > tensibleNamespaces.java:77)
> > > >
> > > >
> > > > Any ideas?
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: 22. marts 2007 13:38
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO Java M3 Release Candidate RC1
> > > >
> > > > Sorry, there's not much documentation, just the JavaDoc. You need
> to
> > > get
> > > > a
> > > > HelperContext by calling SDOUtil.createHelperContext() and then
> get
> > > your
> > > >
> > > > XSDHelper from it.
> > > >
> > > > If you want the new extensible namespaces behavior you need to
> pass
> > > > "true"
> > > > to createHelperContext:
> > > >
> > > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > >
> > > > Frank.
> > > >
> > > >
> > > >
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <Ch...@ementor.dk>
> > > >
> > > > 03/22/2007 06:30 AM
> > > > Please respond to
> > > > tuscany-user@ws.apache.org
> > > >
> > > >
> > > > To
> > > > <tu...@ws.apache.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: SDO Java M3 Release Candidate RC1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The testcase I used the last time does not function using SDO M3,
> > but
> > > I
> > > > guess It is because I can't just use XSDHelper.INSTANCE. I
> remember
> > > > Frank
> > > > mentioning something about helpercontexts. Have you got any
> > > > documentation
> > > > as to hov this is done.
> > > >
> > > > /Chr
> > > >
> > > > ps. the test case is the one from:
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > > > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > > > <
> > > >
> > >
> >
> https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > > >
> > >
> >
> pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > > > .issuetabpanels:comment-tabpanel%23action_12473251
> > > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: Fri 3/16/2007 9:14 AM
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: Re: SDO Java M3 Release Candidate RC1
> > > >
> > > >
> > > >
> > > > Christian,
> > > > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
> > in
> > > > the
> > > > binary release.
> > > > Regards, Kelvin.
> > > >
> > > > On 15/03/07, Christian Landbo Frederiksen <
> > > > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > > > >
> > > > >
> > > > > What version of EMF and SDO api is needed for this release?
> > > > >
> > > > > -----Original Message-----
> > > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > > Sent: 15. marts 2007 16:42
> > > > > To: tuscany-dev; Tuscany Users
> > > > > Subject: SDO Java M3 Release Candidate RC1
> > > > >
> > > > > I have posted an SDO Java M3 release candidate here:
> > > > >
> > > >
> > >
> >
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > > > pache.org/%7Erobbinspg/M3-RC1/>
> > > > >
> > > > > Please take a look at this and try it out, so that I can pick up
> > any
> > > > > errors
> > > > > quickly and move towards a vote on a proper release in the short
> > > term.
> > > > >
> > > > > Thanks, Kelvin.
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Hi Kelvin
I can't seem to find out precisely what causes it, because I can
generate a test case where this does not occur.
Fortunately I can also generate one where it does.
Let me first say that if I create a new helperContext when the
IllegalArgumentException occurs the problem can be avoided...
Since I am not sure how else to supply this I have just done a
copy/paste og the test case (JUnit 3.8):
--------------- COPY -------------------
package dk.test;
import junit.framework.TestCase;
import org.apache.tuscany.sdo.util.SDOUtil;
import commonj.sdo.helper.HelperContext;
public class TestSDOErronousSchemaReferences extends TestCase {
private HelperContext helperContext;
public TestSDOErronousSchemaReferences(String arg0) {
super(arg0);
this.helperContext = SDOUtil.createHelperContext(true);
}
public void testSDOErronousSchemaReferences() {
try {
String xsd = "<?xml version=\"1.0\"
encoding=\"ISO-8859-1\"?> <schema
xmlns=\"http://www.w3.org/2001/XMLSchema\"
xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
emas/2007/01/01/\"
xmlns:XKOM=\"http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/\"
xmlns:DKCC=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
xmlns:DKCC2=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
7/01/01/\" elementFormDefault=\"qualified\" xml:lang=\"en\"><import
namespace=\"http://rerp.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_PostCodeIdentifier.xsd\"/><import
namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_DistrictName.xsd\"/><import
namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_StreetName.xsd\"/><import
namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
C_StreetBuildingIdentifier.xsd\"/><import
namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_DistrictSubdivisionIdentifier.xsd\"/><import
namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
C_FloorIdentifier.xsd\"/><import
namespace=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\"
schemaLocation=\"http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
C_SuiteIdentifier.xsd\"/><annotation><documentation/></annotation><eleme
nt name=\"InstitutionAddress\"
type=\"brugerinformation:InstitutionAddressType\"/><complexType
name=\"InstitutionAddressType\"><sequence><element
name=\"DaycareServiceName\" type=\"string\"/><element
ref=\"DKCC:StreetName\"/><element
ref=\"DKCC2:StreetBuildingIdentifier\"/><element
ref=\"DKCC2:FloorIdentifier\" minOccurs=\"0\"/><element
ref=\"DKCC2:SuiteIdentifier\" minOccurs=\"0\"/><element
ref=\"DKCC:PostCodeIdentifier\"/><element
ref=\"DKCC:DistrictName\"/><element
ref=\"DKCC:DistrictSubdivisionIdentifier\"/><element
name=\"InstitutionPhonenrText\" type=\"string\"/><element
name=\"EmailaddText\" type=\"string\"/><element name=\"WeblinkText\"
type=\"string\"/></sequence></complexType></schema>";
String root = "InstitutionAddress";
String namespace =
"http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007/01/01/";
System.out.println("First define with erronous
reference");
try {
test(xsd, root, namespace);
} catch (IllegalArgumentException e) {
e.printStackTrace();
}
System.out.println("\nSecond define just dummy
valid schema");
xsd = "<?xml version=\"1.0\"
encoding=\"ISO-8859-1\"?> <schema
xmlns=\"http://www.w3.org/2001/XMLSchema\"
xmlns:brugerinformation=\"http://rep.oio.dk/brugerinformation.dk/xml/sch
emas/2007/01/01/\"
targetNamespace=\"http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
7/01/01/\" elementFormDefault=\"qualified\"
xml:lang=\"EN\"><annotation><documentation/></annotation><element
name=\"InstitutionSpacePerkid\"
type=\"brugerinformation:InstitutionSpacePerkidType\"/><complexType
name=\"InstitutionSpacePerkidType\"><sequence><element
name=\"InstitutionSpacesqmQuantity\"
type=\"brugerinformation:InstitutionSpacesqmQuantityType\"/></sequence><
/complexType><simpleType
name=\"InstitutionSpacesqmQuantityType\"><restriction
base=\"unsignedInt\"/></simpleType></schema>";
root = "InstitutionSpacePerkid";
try {
test(xsd, root, namespace);
} catch (Exception e) {
e.printStackTrace();
throw e;
}
} catch (Exception e) {
fail(e.toString());
}
}
public void test(final String xsdFile, final String rootElement,
final String namespace) throws Exception {
System.out.println("Calling define...");
this.helperContext.getXSDHelper().define(new
String(xsdFile.getBytes("ISO-8859-1")));
System.out.println("Define successful...");
System.out.println("Calling create...");
this.helperContext.getDataFactory().create(namespace,
rootElement + "Type");
System.out.println("Create successful...\n");
return;
}
}
------------------ END COPY --------------------
-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com]
Sent: 28. marts 2007 09:53
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Hi Christian,
could you please post some code snippets or better still a test case.
It
appears that the Type that you are trying to create an instance of is
associated with an EMF factory rather than an SDO Factory.
On the subject of HelperContext lifecycle, there's no constraint on the
longevity of a HelperContext instance. At the moment I imagine that
each
instance would be relatively long lived, since there are no fine
grained
controls on the lifecycle of the Types within a scope. So I imagine
that
for many applications a single HelperContext will suffice for the
lifetime
of the application.
It may be the case that in the future we provide ways of associating
HelperContexts in order that one may delegate to another/others. I can
imagine in that scenario more opportunities to control the type system
by
having short lived HelperContext instances, but as I say, we don't
have
that yet.
Regards, Kelvin.
On 27/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> Hi Frank et. al.
>
> I applied the fix and it helped, but I also get an error like the one
> mentioned in this thread (NullPointerException), when a referenced
> schema cannot be found!
>
> But that is not the worst part. Once I run into that error, all later
> attempts to create using a dataFactory from the context also fail, but
> this time with the following error:
>
> java.lang.ClassCastException:
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
> commonj.sdo.DataObject
> at
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:61)
> at
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:46)
>
> Any ideas?
>
> Could you describe some helpercontext scenarios? I am specifically
> wondering how long the helperContext instance should live. Currently I
> am trying to use a long living context inside a singleton - imagining
it
> is the most efficient way. Is that recommendable?
>
> /Chr
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 27. marts 2007 16:27
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Hi Christian,
>
> Your schema seems to be using http:// schemaLocations. For performance
> reasons, we recently disabled that, but I guess we really shouldn't do
> that, without it being an option. We will fix it in the next driver.
>
> If you want to try it out yourself, the fix is to comment out line
2473
> in
> DataObjectUtil:
>
> //resourceSet.setURIConverter(new SDOURIConverterImpl());
>
> Frank.
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
>
> wrote on 03/27/2007 03:51:43 AM:
>
> > Hi again.
> >
> > Though my simple testcase now functions, I have run into a
nullpointer
> > exception with a schema that functions in M2.
> >
> > java.lang.NullPointerException
> > at
> >
>
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> > oreBuilder.java:123)
> >
> > As far as I can tell: In BaseSDOXSDEcoreBuilder:
> >
> > protected EStructuralFeature createFeature
> > (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> > String name, XSDComponent xsdComponent, int minOccurs, int
> > maxOccurs) {
> >
> > XSDTypeDefinition elementTypeDefinition =
> > getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
> >
> > The call to getEffectiveTypeDefinition returns null, resulting in
the
> > nullpointer in the next call to
> >
> > EClassifier eClassifier = getEClassifier(elementTypeDefinition);
> >
> > The schema has references to other schemas and it is in the first of
> > those (StreetName) it fails.
> >
> > This is the schema I try to define:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >
>
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> > mas/2007/01/01/"
> > xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> > xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
>
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> > /01/01/" elementFormDefault="qualified" xml:lang="en">
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _PostCodeIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _DistrictName.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _StreetName.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > _StreetBuildingIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _DistrictSubdivisionIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > _FloorIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > _SuiteIdentifier.xsd"/>
> > <annotation>
> > <documentation/>
> > </annotation>
> > <element name="InstitutionAddress"
> > type="brugerinformation:InstitutionAddressType"/>
> > <complexType name="InstitutionAddressType">
> > <sequence>
> > <element name="DaycareServiceName"
> > type="string"/>
> > <element ref="DKCC:StreetName"/>
> > <element ref="DKCC2:StreetBuildingIdentifier"/>
> > <element ref="DKCC2:FloorIdentifier"
> > minOccurs="0"/>
> > <element ref="DKCC2:SuiteIdentifier"
> > minOccurs="0"/>
> > <element ref="DKCC:PostCodeIdentifier"/>
> > <element ref="DKCC:DistrictName"/>
> > <element
> > ref="DKCC:DistrictSubdivisionIdentifier"/>
> > <element name="InstitutionPhonenrText"
> > type="string"/>
> > <element name="EmailaddText" type="string"/>
> > <element name="WeblinkText" type="string"/>
> > </sequence>
> > </complexType>
> > </schema>
> >
> > Any ideas?
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 26. marts 2007 19:12
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > You need to get your DataFactory from the HelperContext:
> >
> > DataObject documentDataObject =
hc.getDataFactory().create(namespace,
> > "DocumentRoot");
> >
> > You should generally stop using INSTANCE fields in all cases,
because
> > they
> > are probably going to be deprecated in the next version of SDO.
> > HelperContext is the replacement. It defines a metadata scope, so
you
> > should always use it to get the helpers for your scope.
> >
> > Frank.
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > wrote on 03/26/2007 01:01:00 PM:
> >
> > >
> > > In M2 & M3 this works for a specific schema:
> > >
> > > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > > DataObject documentDataObject =
> DataFactory.INSTANCE.create(namespace,
> > > "DocumentRoot");
> > >
> > > But this doesn't
> > >
> > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> > >
> > > DataObject documentDataObject =
> DataFactory.INSTANCE.create(namespace,
> > > "DocumentRoot");
> > >
> > >
> > > java.lang.IllegalArgumentException
> > > at
> > >
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > a:63)
> > > at
> > >
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > a:46)
> > > at
> > >
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > > ndExtensibleNamespaces.java:153)
> > > at
> > >
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > > tensibleNamespaces.java:77)
> > >
> > >
> > > Any ideas?
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 22. marts 2007 13:38
> > > To: tuscany-user@ws.apache.org
> > > Subject: RE: SDO Java M3 Release Candidate RC1
> > >
> > > Sorry, there's not much documentation, just the JavaDoc. You need
to
> > get
> > > a
> > > HelperContext by calling SDOUtil.createHelperContext() and then
get
> > your
> > >
> > > XSDHelper from it.
> > >
> > > If you want the new extensible namespaces behavior you need to
pass
> > > "true"
> > > to createHelperContext:
> > >
> > > HelperContext hc = SDOUtil.createHelperContext(true);
> > >
> > > Frank.
> > >
> > >
> > >
> > >
> > > "Christian Landbo Frederiksen"
> > <Ch...@ementor.dk>
> > >
> > > 03/22/2007 06:30 AM
> > > Please respond to
> > > tuscany-user@ws.apache.org
> > >
> > >
> > > To
> > > <tu...@ws.apache.org>
> > > cc
> > >
> > > Subject
> > > RE: SDO Java M3 Release Candidate RC1
> > >
> > >
> > >
> > >
> > >
> > >
> > > The testcase I used the last time does not function using SDO M3,
> but
> > I
> > > guess It is because I can't just use XSDHelper.INSTANCE. I
remember
> > > Frank
> > > mentioning something about helpercontexts. Have you got any
> > > documentation
> > > as to hov this is done.
> > >
> > > /Chr
> > >
> > > ps. the test case is the one from:
> > >
> >
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > > <
> > >
> >
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > >
> >
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > > .issuetabpanels:comment-tabpanel%23action_12473251
> > > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: Fri 3/16/2007 9:14 AM
> > > To: tuscany-user@ws.apache.org
> > > Subject: Re: SDO Java M3 Release Candidate RC1
> > >
> > >
> > >
> > > Christian,
> > > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
> in
> > > the
> > > binary release.
> > > Regards, Kelvin.
> > >
> > > On 15/03/07, Christian Landbo Frederiksen <
> > > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > > >
> > > >
> > > > What version of EMF and SDO api is needed for this release?
> > > >
> > > > -----Original Message-----
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: 15. marts 2007 16:42
> > > > To: tuscany-dev; Tuscany Users
> > > > Subject: SDO Java M3 Release Candidate RC1
> > > >
> > > > I have posted an SDO Java M3 release candidate here:
> > > >
> > >
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > > pache.org/%7Erobbinspg/M3-RC1/>
> > > >
> > > > Please take a look at this and try it out, so that I can pick up
> any
> > > > errors
> > > > quickly and move towards a vote on a proper release in the short
> > term.
> > > >
> > > > Thanks, Kelvin.
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
Hi Christian,
could you please post some code snippets or better still a test case. It
appears that the Type that you are trying to create an instance of is
associated with an EMF factory rather than an SDO Factory.
On the subject of HelperContext lifecycle, there's no constraint on the
longevity of a HelperContext instance. At the moment I imagine that each
instance would be relatively long lived, since there are no fine grained
controls on the lifecycle of the Types within a scope. So I imagine that
for many applications a single HelperContext will suffice for the lifetime
of the application.
It may be the case that in the future we provide ways of associating
HelperContexts in order that one may delegate to another/others. I can
imagine in that scenario more opportunities to control the type system by
having short lived HelperContext instances, but as I say, we don't have
that yet.
Regards, Kelvin.
On 27/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> Hi Frank et. al.
>
> I applied the fix and it helped, but I also get an error like the one
> mentioned in this thread (NullPointerException), when a referenced
> schema cannot be found!
>
> But that is not the worst part. Once I run into that error, all later
> attempts to create using a dataFactory from the context also fail, but
> this time with the following error:
>
> java.lang.ClassCastException:
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
> commonj.sdo.DataObject
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:61)
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:46)
>
> Any ideas?
>
> Could you describe some helpercontext scenarios? I am specifically
> wondering how long the helperContext instance should live. Currently I
> am trying to use a long living context inside a singleton - imagining it
> is the most efficient way. Is that recommendable?
>
> /Chr
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 27. marts 2007 16:27
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Hi Christian,
>
> Your schema seems to be using http:// schemaLocations. For performance
> reasons, we recently disabled that, but I guess we really shouldn't do
> that, without it being an option. We will fix it in the next driver.
>
> If you want to try it out yourself, the fix is to comment out line 2473
> in
> DataObjectUtil:
>
> //resourceSet.setURIConverter(new SDOURIConverterImpl());
>
> Frank.
>
> "Christian Landbo Frederiksen" <Ch...@ementor.dk>
>
> wrote on 03/27/2007 03:51:43 AM:
>
> > Hi again.
> >
> > Though my simple testcase now functions, I have run into a nullpointer
> > exception with a schema that functions in M2.
> >
> > java.lang.NullPointerException
> > at
> >
> org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> > oreBuilder.java:123)
> >
> > As far as I can tell: In BaseSDOXSDEcoreBuilder:
> >
> > protected EStructuralFeature createFeature
> > (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> > String name, XSDComponent xsdComponent, int minOccurs, int
> > maxOccurs) {
> >
> > XSDTypeDefinition elementTypeDefinition =
> > getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
> >
> > The call to getEffectiveTypeDefinition returns null, resulting in the
> > nullpointer in the next call to
> >
> > EClassifier eClassifier = getEClassifier(elementTypeDefinition);
> >
> > The schema has references to other schemas and it is in the first of
> > those (StreetName) it fails.
> >
> > This is the schema I try to define:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >
> xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> > mas/2007/01/01/"
> > xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> > xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> > xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
> targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> > /01/01/" elementFormDefault="qualified" xml:lang="en">
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _PostCodeIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _DistrictName.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _StreetName.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > _StreetBuildingIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> > _DistrictSubdivisionIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > _FloorIdentifier.xsd"/>
> > <import
> > namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> >
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> > _SuiteIdentifier.xsd"/>
> > <annotation>
> > <documentation/>
> > </annotation>
> > <element name="InstitutionAddress"
> > type="brugerinformation:InstitutionAddressType"/>
> > <complexType name="InstitutionAddressType">
> > <sequence>
> > <element name="DaycareServiceName"
> > type="string"/>
> > <element ref="DKCC:StreetName"/>
> > <element ref="DKCC2:StreetBuildingIdentifier"/>
> > <element ref="DKCC2:FloorIdentifier"
> > minOccurs="0"/>
> > <element ref="DKCC2:SuiteIdentifier"
> > minOccurs="0"/>
> > <element ref="DKCC:PostCodeIdentifier"/>
> > <element ref="DKCC:DistrictName"/>
> > <element
> > ref="DKCC:DistrictSubdivisionIdentifier"/>
> > <element name="InstitutionPhonenrText"
> > type="string"/>
> > <element name="EmailaddText" type="string"/>
> > <element name="WeblinkText" type="string"/>
> > </sequence>
> > </complexType>
> > </schema>
> >
> > Any ideas?
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 26. marts 2007 19:12
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > You need to get your DataFactory from the HelperContext:
> >
> > DataObject documentDataObject = hc.getDataFactory().create(namespace,
> > "DocumentRoot");
> >
> > You should generally stop using INSTANCE fields in all cases, because
> > they
> > are probably going to be deprecated in the next version of SDO.
> > HelperContext is the replacement. It defines a metadata scope, so you
> > should always use it to get the helpers for your scope.
> >
> > Frank.
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > wrote on 03/26/2007 01:01:00 PM:
> >
> > >
> > > In M2 & M3 this works for a specific schema:
> > >
> > > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > > DataObject documentDataObject =
> DataFactory.INSTANCE.create(namespace,
> > > "DocumentRoot");
> > >
> > > But this doesn't
> > >
> > > HelperContext hc = SDOUtil.createHelperContext(true);
> > > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> > >
> > > DataObject documentDataObject =
> DataFactory.INSTANCE.create(namespace,
> > > "DocumentRoot");
> > >
> > >
> > > java.lang.IllegalArgumentException
> > > at
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > a:63)
> > > at
> > >
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > > a:46)
> > > at
> > >
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > > ndExtensibleNamespaces.java:153)
> > > at
> > >
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > > tensibleNamespaces.java:77)
> > >
> > >
> > > Any ideas?
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 22. marts 2007 13:38
> > > To: tuscany-user@ws.apache.org
> > > Subject: RE: SDO Java M3 Release Candidate RC1
> > >
> > > Sorry, there's not much documentation, just the JavaDoc. You need to
> > get
> > > a
> > > HelperContext by calling SDOUtil.createHelperContext() and then get
> > your
> > >
> > > XSDHelper from it.
> > >
> > > If you want the new extensible namespaces behavior you need to pass
> > > "true"
> > > to createHelperContext:
> > >
> > > HelperContext hc = SDOUtil.createHelperContext(true);
> > >
> > > Frank.
> > >
> > >
> > >
> > >
> > > "Christian Landbo Frederiksen"
> > <Ch...@ementor.dk>
> > >
> > > 03/22/2007 06:30 AM
> > > Please respond to
> > > tuscany-user@ws.apache.org
> > >
> > >
> > > To
> > > <tu...@ws.apache.org>
> > > cc
> > >
> > > Subject
> > > RE: SDO Java M3 Release Candidate RC1
> > >
> > >
> > >
> > >
> > >
> > >
> > > The testcase I used the last time does not function using SDO M3,
> but
> > I
> > > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > > Frank
> > > mentioning something about helpercontexts. Have you got any
> > > documentation
> > > as to hov this is done.
> > >
> > > /Chr
> > >
> > > ps. the test case is the one from:
> > >
> >
> https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > > <
> > >
> >
> https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> > >
> >
> pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > > .issuetabpanels:comment-tabpanel%23action_12473251
> > > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: Fri 3/16/2007 9:14 AM
> > > To: tuscany-user@ws.apache.org
> > > Subject: Re: SDO Java M3 Release Candidate RC1
> > >
> > >
> > >
> > > Christian,
> > > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
> in
> > > the
> > > binary release.
> > > Regards, Kelvin.
> > >
> > > On 15/03/07, Christian Landbo Frederiksen <
> > > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > > >
> > > >
> > > > What version of EMF and SDO api is needed for this release?
> > > >
> > > > -----Original Message-----
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: 15. marts 2007 16:42
> > > > To: tuscany-dev; Tuscany Users
> > > > Subject: SDO Java M3 Release Candidate RC1
> > > >
> > > > I have posted an SDO Java M3 release candidate here:
> > > >
> > >
> >
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > > pache.org/%7Erobbinspg/M3-RC1/>
> > > >
> > > > Please take a look at this and try it out, so that I can pick up
> any
> > > > errors
> > > > quickly and move towards a vote on a proper release in the short
> > term.
> > > >
> > > > Thanks, Kelvin.
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Hi Frank et. al.
I applied the fix and it helped, but I also get an error like the one
mentioned in this thread (NullPointerException), when a referenced
schema cannot be found!
But that is not the worst part. Once I run into that error, all later
attempts to create using a dataFactory from the context also fail, but
this time with the following error:
java.lang.ClassCastException:
org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
commonj.sdo.DataObject
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:61)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:46)
Any ideas?
Could you describe some helpercontext scenarios? I am specifically
wondering how long the helperContext instance should live. Currently I
am trying to use a long living context inside a singleton - imagining it
is the most efficient way. Is that recommendable?
/Chr
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 27. marts 2007 16:27
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line 2473
in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/27/2007 03:51:43 AM:
> Hi again.
>
> Though my simple testcase now functions, I have run into a nullpointer
> exception with a schema that functions in M2.
>
> java.lang.NullPointerException
> at
>
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> oreBuilder.java:123)
>
> As far as I can tell: In BaseSDOXSDEcoreBuilder:
>
> protected EStructuralFeature createFeature
> (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> String name, XSDComponent xsdComponent, int minOccurs, int
> maxOccurs) {
>
> XSDTypeDefinition elementTypeDefinition =
> getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
>
> The call to getEffectiveTypeDefinition returns null, resulting in the
> nullpointer in the next call to
>
> EClassifier eClassifier = getEClassifier(elementTypeDefinition);
>
> The schema has references to other schemas and it is in the first of
> those (StreetName) it fails.
>
> This is the schema I try to define:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> mas/2007/01/01/"
> xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> /01/01/" elementFormDefault="qualified" xml:lang="en">
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _PostCodeIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _StreetName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _StreetBuildingIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictSubdivisionIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _FloorIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _SuiteIdentifier.xsd"/>
> <annotation>
> <documentation/>
> </annotation>
> <element name="InstitutionAddress"
> type="brugerinformation:InstitutionAddressType"/>
> <complexType name="InstitutionAddressType">
> <sequence>
> <element name="DaycareServiceName"
> type="string"/>
> <element ref="DKCC:StreetName"/>
> <element ref="DKCC2:StreetBuildingIdentifier"/>
> <element ref="DKCC2:FloorIdentifier"
> minOccurs="0"/>
> <element ref="DKCC2:SuiteIdentifier"
> minOccurs="0"/>
> <element ref="DKCC:PostCodeIdentifier"/>
> <element ref="DKCC:DistrictName"/>
> <element
> ref="DKCC:DistrictSubdivisionIdentifier"/>
> <element name="InstitutionPhonenrText"
> type="string"/>
> <element name="EmailaddText" type="string"/>
> <element name="WeblinkText" type="string"/>
> </sequence>
> </complexType>
> </schema>
>
> Any ideas?
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 26. marts 2007 19:12
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> You need to get your DataFactory from the HelperContext:
>
> DataObject documentDataObject = hc.getDataFactory().create(namespace,
> "DocumentRoot");
>
> You should generally stop using INSTANCE fields in all cases, because
> they
> are probably going to be deprecated in the next version of SDO.
> HelperContext is the replacement. It defines a metadata scope, so you
> should always use it to get the helpers for your scope.
>
> Frank.
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
>
> wrote on 03/26/2007 01:01:00 PM:
>
> >
> > In M2 & M3 this works for a specific schema:
> >
> > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> > But this doesn't
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> >
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> >
> > java.lang.IllegalArgumentException
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:63)
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> > at
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > ndExtensibleNamespaces.java:153)
> > at
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > tensibleNamespaces.java:77)
> >
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 22. marts 2007 13:38
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Sorry, there's not much documentation, just the JavaDoc. You need to
> get
> > a
> > HelperContext by calling SDOUtil.createHelperContext() and then get
> your
> >
> > XSDHelper from it.
> >
> > If you want the new extensible namespaces behavior you need to pass
> > "true"
> > to createHelperContext:
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> >
> > Frank.
> >
> >
> >
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > 03/22/2007 06:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > The testcase I used the last time does not function using SDO M3,
but
> I
> > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > Frank
> > mentioning something about helpercontexts. Have you got any
> > documentation
> > as to hov this is done.
> >
> > /Chr
> >
> > ps. the test case is the one from:
> >
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > <
> >
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> >
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > .issuetabpanels:comment-tabpanel%23action_12473251
> > >
> >
> >
> >
> > ________________________________
> >
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: Fri 3/16/2007 9:14 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> >
> >
> > Christian,
> > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
in
> > the
> > binary release.
> > Regards, Kelvin.
> >
> > On 15/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > >
> > > What version of EMF and SDO api is needed for this release?
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 15. marts 2007 16:42
> > > To: tuscany-dev; Tuscany Users
> > > Subject: SDO Java M3 Release Candidate RC1
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > >
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > pache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up
any
> > > errors
> > > quickly and move towards a vote on a proper release in the short
> term.
> > >
> > > Thanks, Kelvin.
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
That did the trick.
I just asked another questing regarding those http references and I am
crossing my fingers that something really clever is available.
/Chr
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 27. marts 2007 16:27
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line 2473
in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/27/2007 03:51:43 AM:
> Hi again.
>
> Though my simple testcase now functions, I have run into a nullpointer
> exception with a schema that functions in M2.
>
> java.lang.NullPointerException
> at
>
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> oreBuilder.java:123)
>
> As far as I can tell: In BaseSDOXSDEcoreBuilder:
>
> protected EStructuralFeature createFeature
> (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> String name, XSDComponent xsdComponent, int minOccurs, int
> maxOccurs) {
>
> XSDTypeDefinition elementTypeDefinition =
> getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
>
> The call to getEffectiveTypeDefinition returns null, resulting in the
> nullpointer in the next call to
>
> EClassifier eClassifier = getEClassifier(elementTypeDefinition);
>
> The schema has references to other schemas and it is in the first of
> those (StreetName) it fails.
>
> This is the schema I try to define:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> mas/2007/01/01/"
> xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> /01/01/" elementFormDefault="qualified" xml:lang="en">
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _PostCodeIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _StreetName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _StreetBuildingIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictSubdivisionIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _FloorIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _SuiteIdentifier.xsd"/>
> <annotation>
> <documentation/>
> </annotation>
> <element name="InstitutionAddress"
> type="brugerinformation:InstitutionAddressType"/>
> <complexType name="InstitutionAddressType">
> <sequence>
> <element name="DaycareServiceName"
> type="string"/>
> <element ref="DKCC:StreetName"/>
> <element ref="DKCC2:StreetBuildingIdentifier"/>
> <element ref="DKCC2:FloorIdentifier"
> minOccurs="0"/>
> <element ref="DKCC2:SuiteIdentifier"
> minOccurs="0"/>
> <element ref="DKCC:PostCodeIdentifier"/>
> <element ref="DKCC:DistrictName"/>
> <element
> ref="DKCC:DistrictSubdivisionIdentifier"/>
> <element name="InstitutionPhonenrText"
> type="string"/>
> <element name="EmailaddText" type="string"/>
> <element name="WeblinkText" type="string"/>
> </sequence>
> </complexType>
> </schema>
>
> Any ideas?
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 26. marts 2007 19:12
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> You need to get your DataFactory from the HelperContext:
>
> DataObject documentDataObject = hc.getDataFactory().create(namespace,
> "DocumentRoot");
>
> You should generally stop using INSTANCE fields in all cases, because
> they
> are probably going to be deprecated in the next version of SDO.
> HelperContext is the replacement. It defines a metadata scope, so you
> should always use it to get the helpers for your scope.
>
> Frank.
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
>
> wrote on 03/26/2007 01:01:00 PM:
>
> >
> > In M2 & M3 this works for a specific schema:
> >
> > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> > But this doesn't
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> >
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> >
> > java.lang.IllegalArgumentException
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:63)
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> > at
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > ndExtensibleNamespaces.java:153)
> > at
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > tensibleNamespaces.java:77)
> >
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 22. marts 2007 13:38
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Sorry, there's not much documentation, just the JavaDoc. You need to
> get
> > a
> > HelperContext by calling SDOUtil.createHelperContext() and then get
> your
> >
> > XSDHelper from it.
> >
> > If you want the new extensible namespaces behavior you need to pass
> > "true"
> > to createHelperContext:
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> >
> > Frank.
> >
> >
> >
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > 03/22/2007 06:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > The testcase I used the last time does not function using SDO M3,
but
> I
> > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > Frank
> > mentioning something about helpercontexts. Have you got any
> > documentation
> > as to hov this is done.
> >
> > /Chr
> >
> > ps. the test case is the one from:
> >
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > <
> >
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> >
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > .issuetabpanels:comment-tabpanel%23action_12473251
> > >
> >
> >
> >
> > ________________________________
> >
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: Fri 3/16/2007 9:14 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> >
> >
> > Christian,
> > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
in
> > the
> > binary release.
> > Regards, Kelvin.
> >
> > On 15/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > >
> > > What version of EMF and SDO api is needed for this release?
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 15. marts 2007 16:42
> > > To: tuscany-dev; Tuscany Users
> > > Subject: SDO Java M3 Release Candidate RC1
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > >
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > pache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up
any
> > > errors
> > > quickly and move towards a vote on a proper release in the short
> term.
> > >
> > > Thanks, Kelvin.
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Just curious
So you recommend only local references i schemas?
My problem is that I have the schemas in a database so I can't have
relative references.
/Chr
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 27. marts 2007 16:27
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line 2473
in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/27/2007 03:51:43 AM:
> Hi again.
>
> Though my simple testcase now functions, I have run into a nullpointer
> exception with a schema that functions in M2.
>
> java.lang.NullPointerException
> at
>
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> oreBuilder.java:123)
>
> As far as I can tell: In BaseSDOXSDEcoreBuilder:
>
> protected EStructuralFeature createFeature
> (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> String name, XSDComponent xsdComponent, int minOccurs, int
> maxOccurs) {
>
> XSDTypeDefinition elementTypeDefinition =
> getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
>
> The call to getEffectiveTypeDefinition returns null, resulting in the
> nullpointer in the next call to
>
> EClassifier eClassifier = getEClassifier(elementTypeDefinition);
>
> The schema has references to other schemas and it is in the first of
> those (StreetName) it fails.
>
> This is the schema I try to define:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> mas/2007/01/01/"
> xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> /01/01/" elementFormDefault="qualified" xml:lang="en">
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _PostCodeIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _StreetName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _StreetBuildingIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictSubdivisionIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _FloorIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
>
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _SuiteIdentifier.xsd"/>
> <annotation>
> <documentation/>
> </annotation>
> <element name="InstitutionAddress"
> type="brugerinformation:InstitutionAddressType"/>
> <complexType name="InstitutionAddressType">
> <sequence>
> <element name="DaycareServiceName"
> type="string"/>
> <element ref="DKCC:StreetName"/>
> <element ref="DKCC2:StreetBuildingIdentifier"/>
> <element ref="DKCC2:FloorIdentifier"
> minOccurs="0"/>
> <element ref="DKCC2:SuiteIdentifier"
> minOccurs="0"/>
> <element ref="DKCC:PostCodeIdentifier"/>
> <element ref="DKCC:DistrictName"/>
> <element
> ref="DKCC:DistrictSubdivisionIdentifier"/>
> <element name="InstitutionPhonenrText"
> type="string"/>
> <element name="EmailaddText" type="string"/>
> <element name="WeblinkText" type="string"/>
> </sequence>
> </complexType>
> </schema>
>
> Any ideas?
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 26. marts 2007 19:12
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> You need to get your DataFactory from the HelperContext:
>
> DataObject documentDataObject = hc.getDataFactory().create(namespace,
> "DocumentRoot");
>
> You should generally stop using INSTANCE fields in all cases, because
> they
> are probably going to be deprecated in the next version of SDO.
> HelperContext is the replacement. It defines a metadata scope, so you
> should always use it to get the helpers for your scope.
>
> Frank.
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
>
> wrote on 03/26/2007 01:01:00 PM:
>
> >
> > In M2 & M3 this works for a specific schema:
> >
> > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> > But this doesn't
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> >
> > DataObject documentDataObject =
DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> >
> > java.lang.IllegalArgumentException
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:63)
> > at
> >
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> > at
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > ndExtensibleNamespaces.java:153)
> > at
> >
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > tensibleNamespaces.java:77)
> >
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 22. marts 2007 13:38
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Sorry, there's not much documentation, just the JavaDoc. You need to
> get
> > a
> > HelperContext by calling SDOUtil.createHelperContext() and then get
> your
> >
> > XSDHelper from it.
> >
> > If you want the new extensible namespaces behavior you need to pass
> > "true"
> > to createHelperContext:
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> >
> > Frank.
> >
> >
> >
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > 03/22/2007 06:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > The testcase I used the last time does not function using SDO M3,
but
> I
> > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > Frank
> > mentioning something about helpercontexts. Have you got any
> > documentation
> > as to hov this is done.
> >
> > /Chr
> >
> > ps. the test case is the one from:
> >
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > <
> >
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> >
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > .issuetabpanels:comment-tabpanel%23action_12473251
> > >
> >
> >
> >
> > ________________________________
> >
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: Fri 3/16/2007 9:14 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> >
> >
> > Christian,
> > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged
in
> > the
> > binary release.
> > Regards, Kelvin.
> >
> > On 15/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > >
> > > What version of EMF and SDO api is needed for this release?
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 15. marts 2007 16:42
> > > To: tuscany-dev; Tuscany Users
> > > Subject: SDO Java M3 Release Candidate RC1
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > >
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > pache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up
any
> > > errors
> > > quickly and move towards a vote on a proper release in the short
> term.
> > >
> > > Thanks, Kelvin.
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line 2473 in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/27/2007 03:51:43 AM:
> Hi again.
>
> Though my simple testcase now functions, I have run into a nullpointer
> exception with a schema that functions in M2.
>
> java.lang.NullPointerException
> at
> org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
> oreBuilder.java:123)
>
> As far as I can tell: In BaseSDOXSDEcoreBuilder:
>
> protected EStructuralFeature createFeature
> (EClass eClass, XSDElementDeclaration xsdElementDeclaration,
> String name, XSDComponent xsdComponent, int minOccurs, int
> maxOccurs) {
>
> XSDTypeDefinition elementTypeDefinition =
> getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
>
> The call to getEffectiveTypeDefinition returns null, resulting in the
> nullpointer in the next call to
>
> EClassifier eClassifier = getEClassifier(elementTypeDefinition);
>
> The schema has references to other schemas and it is in the first of
> those (StreetName) it fails.
>
> This is the schema I try to define:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
> mas/2007/01/01/"
> xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
> xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
> /01/01/" elementFormDefault="qualified" xml:lang="en">
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _PostCodeIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _StreetName.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _StreetBuildingIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
> _DistrictSubdivisionIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _FloorIdentifier.xsd"/>
> <import
> namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
> schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
> _SuiteIdentifier.xsd"/>
> <annotation>
> <documentation/>
> </annotation>
> <element name="InstitutionAddress"
> type="brugerinformation:InstitutionAddressType"/>
> <complexType name="InstitutionAddressType">
> <sequence>
> <element name="DaycareServiceName"
> type="string"/>
> <element ref="DKCC:StreetName"/>
> <element ref="DKCC2:StreetBuildingIdentifier"/>
> <element ref="DKCC2:FloorIdentifier"
> minOccurs="0"/>
> <element ref="DKCC2:SuiteIdentifier"
> minOccurs="0"/>
> <element ref="DKCC:PostCodeIdentifier"/>
> <element ref="DKCC:DistrictName"/>
> <element
> ref="DKCC:DistrictSubdivisionIdentifier"/>
> <element name="InstitutionPhonenrText"
> type="string"/>
> <element name="EmailaddText" type="string"/>
> <element name="WeblinkText" type="string"/>
> </sequence>
> </complexType>
> </schema>
>
> Any ideas?
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 26. marts 2007 19:12
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> You need to get your DataFactory from the HelperContext:
>
> DataObject documentDataObject = hc.getDataFactory().create(namespace,
> "DocumentRoot");
>
> You should generally stop using INSTANCE fields in all cases, because
> they
> are probably going to be deprecated in the next version of SDO.
> HelperContext is the replacement. It defines a metadata scope, so you
> should always use it to get the helpers for your scope.
>
> Frank.
>
> "Christian Landbo Frederiksen" <Ch...@ementor.dk>
>
> wrote on 03/26/2007 01:01:00 PM:
>
> >
> > In M2 & M3 this works for a specific schema:
> >
> > XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> > DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> > But this doesn't
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> > hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
> >
> > DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> > "DocumentRoot");
> >
> >
> > java.lang.IllegalArgumentException
> > at
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:63)
> > at
> >
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> > a:46)
> > at
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> > ndExtensibleNamespaces.java:153)
> > at
> >
> sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> > tensibleNamespaces.java:77)
> >
> >
> > Any ideas?
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 22. marts 2007 13:38
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO Java M3 Release Candidate RC1
> >
> > Sorry, there's not much documentation, just the JavaDoc. You need to
> get
> > a
> > HelperContext by calling SDOUtil.createHelperContext() and then get
> your
> >
> > XSDHelper from it.
> >
> > If you want the new extensible namespaces behavior you need to pass
> > "true"
> > to createHelperContext:
> >
> > HelperContext hc = SDOUtil.createHelperContext(true);
> >
> > Frank.
> >
> >
> >
> >
> > "Christian Landbo Frederiksen"
> <Ch...@ementor.dk>
> >
> > 03/22/2007 06:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO Java M3 Release Candidate RC1
> >
> >
> >
> >
> >
> >
> > The testcase I used the last time does not function using SDO M3, but
> I
> > guess It is because I can't just use XSDHelper.INSTANCE. I remember
> > Frank
> > mentioning something about helpercontexts. Have you got any
> > documentation
> > as to hov this is done.
> >
> > /Chr
> >
> > ps. the test case is the one from:
> >
> https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> > <
> >
> https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> >
> pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> > .issuetabpanels:comment-tabpanel%23action_12473251
> > >
> >
> >
> >
> > ________________________________
> >
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: Fri 3/16/2007 9:14 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: SDO Java M3 Release Candidate RC1
> >
> >
> >
> > Christian,
> > The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
> > the
> > binary release.
> > Regards, Kelvin.
> >
> > On 15/03/07, Christian Landbo Frederiksen <
> > Christian.Landbo.Frederiksen@ementor.dk> wrote:
> > >
> > >
> > > What version of EMF and SDO api is needed for this release?
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 15. marts 2007 16:42
> > > To: tuscany-dev; Tuscany Users
> > > Subject: SDO Java M3 Release Candidate RC1
> > >
> > > I have posted an SDO Java M3 release candidate here:
> > >
> >
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > > pache.org/%7Erobbinspg/M3-RC1/>
> > >
> > > Please take a look at this and try it out, so that I can pick up any
> > > errors
> > > quickly and move towards a vote on a proper release in the short
> term.
> > >
> > > Thanks, Kelvin.
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Hi again.
Though my simple testcase now functions, I have run into a nullpointer
exception with a schema that functions in M2.
java.lang.NullPointerException
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
oreBuilder.java:123)
As far as I can tell: In BaseSDOXSDEcoreBuilder:
protected EStructuralFeature createFeature
(EClass eClass, XSDElementDeclaration xsdElementDeclaration,
String name, XSDComponent xsdComponent, int minOccurs, int
maxOccurs) {
XSDTypeDefinition elementTypeDefinition =
getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
The call to getEffectiveTypeDefinition returns null, resulting in the
nullpointer in the next call to
EClassifier eClassifier = getEClassifier(elementTypeDefinition);
The schema has references to other schemas and it is in the first of
those (StreetName) it fails.
This is the schema I try to define:
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:brugerinformation="http://rep.oio.dk/brugerinformation.dk/xml/sche
mas/2007/01/01/"
xmlns:XKOM="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/"
xmlns:DKCC="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
xmlns:DKCC2="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
targetNamespace="http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
/01/01/" elementFormDefault="qualified" xml:lang="en">
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_PostCodeIdentifier.xsd"/>
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_DistrictName.xsd"/>
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_StreetName.xsd"/>
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
_StreetBuildingIdentifier.xsd"/>
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_DistrictSubdivisionIdentifier.xsd"/>
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
_FloorIdentifier.xsd"/>
<import
namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/"
schemaLocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
_SuiteIdentifier.xsd"/>
<annotation>
<documentation/>
</annotation>
<element name="InstitutionAddress"
type="brugerinformation:InstitutionAddressType"/>
<complexType name="InstitutionAddressType">
<sequence>
<element name="DaycareServiceName"
type="string"/>
<element ref="DKCC:StreetName"/>
<element ref="DKCC2:StreetBuildingIdentifier"/>
<element ref="DKCC2:FloorIdentifier"
minOccurs="0"/>
<element ref="DKCC2:SuiteIdentifier"
minOccurs="0"/>
<element ref="DKCC:PostCodeIdentifier"/>
<element ref="DKCC:DistrictName"/>
<element
ref="DKCC:DistrictSubdivisionIdentifier"/>
<element name="InstitutionPhonenrText"
type="string"/>
<element name="EmailaddText" type="string"/>
<element name="WeblinkText" type="string"/>
</sequence>
</complexType>
</schema>
Any ideas?
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 26. marts 2007 19:12
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
You need to get your DataFactory from the HelperContext:
DataObject documentDataObject = hc.getDataFactory().create(namespace,
"DocumentRoot");
You should generally stop using INSTANCE fields in all cases, because
they
are probably going to be deprecated in the next version of SDO.
HelperContext is the replacement. It defines a metadata scope, so you
should always use it to get the helpers for your scope.
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/26/2007 01:01:00 PM:
>
> In M2 & M3 this works for a specific schema:
>
> XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
> But this doesn't
>
> HelperContext hc = SDOUtil.createHelperContext(true);
> hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
>
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
>
> java.lang.IllegalArgumentException
> at
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:63)
> at
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:46)
> at
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> ndExtensibleNamespaces.java:153)
> at
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> tensibleNamespaces.java:77)
>
>
> Any ideas?
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 22. marts 2007 13:38
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Sorry, there's not much documentation, just the JavaDoc. You need to
get
> a
> HelperContext by calling SDOUtil.createHelperContext() and then get
your
>
> XSDHelper from it.
>
> If you want the new extensible namespaces behavior you need to pass
> "true"
> to createHelperContext:
>
> HelperContext hc = SDOUtil.createHelperContext(true);
>
> Frank.
>
>
>
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
>
> 03/22/2007 06:30 AM
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
>
> Subject
> RE: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> The testcase I used the last time does not function using SDO M3, but
I
> guess It is because I can't just use XSDHelper.INSTANCE. I remember
> Frank
> mentioning something about helpercontexts. Have you got any
> documentation
> as to hov this is done.
>
> /Chr
>
> ps. the test case is the one from:
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> <
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> .issuetabpanels:comment-tabpanel%23action_12473251
> >
>
>
>
> ________________________________
>
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: Fri 3/16/2007 9:14 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO Java M3 Release Candidate RC1
>
>
>
> Christian,
> The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
> the
> binary release.
> Regards, Kelvin.
>
> On 15/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> >
> > What version of EMF and SDO api is needed for this release?
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 15. marts 2007 16:42
> > To: tuscany-dev; Tuscany Users
> > Subject: SDO Java M3 Release Candidate RC1
> >
> > I have posted an SDO Java M3 release candidate here:
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > pache.org/%7Erobbinspg/M3-RC1/>
> >
> > Please take a look at this and try it out, so that I can pick up any
> > errors
> > quickly and move towards a vote on a proper release in the short
term.
> >
> > Thanks, Kelvin.
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Yep - that did the trick,
Thanks
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 26. marts 2007 19:12
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
You need to get your DataFactory from the HelperContext:
DataObject documentDataObject = hc.getDataFactory().create(namespace,
"DocumentRoot");
You should generally stop using INSTANCE fields in all cases, because
they
are probably going to be deprecated in the next version of SDO.
HelperContext is the replacement. It defines a metadata scope, so you
should always use it to get the helpers for your scope.
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/26/2007 01:01:00 PM:
>
> In M2 & M3 this works for a specific schema:
>
> XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
> But this doesn't
>
> HelperContext hc = SDOUtil.createHelperContext(true);
> hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
>
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
>
> java.lang.IllegalArgumentException
> at
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:63)
> at
>
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:46)
> at
>
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> ndExtensibleNamespaces.java:153)
> at
>
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> tensibleNamespaces.java:77)
>
>
> Any ideas?
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 22. marts 2007 13:38
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Sorry, there's not much documentation, just the JavaDoc. You need to
get
> a
> HelperContext by calling SDOUtil.createHelperContext() and then get
your
>
> XSDHelper from it.
>
> If you want the new extensible namespaces behavior you need to pass
> "true"
> to createHelperContext:
>
> HelperContext hc = SDOUtil.createHelperContext(true);
>
> Frank.
>
>
>
>
> "Christian Landbo Frederiksen"
<Ch...@ementor.dk>
>
> 03/22/2007 06:30 AM
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
>
> Subject
> RE: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> The testcase I used the last time does not function using SDO M3, but
I
> guess It is because I can't just use XSDHelper.INSTANCE. I remember
> Frank
> mentioning something about helpercontexts. Have you got any
> documentation
> as to hov this is done.
>
> /Chr
>
> ps. the test case is the one from:
>
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> <
>
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
>
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> .issuetabpanels:comment-tabpanel%23action_12473251
> >
>
>
>
> ________________________________
>
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: Fri 3/16/2007 9:14 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO Java M3 Release Candidate RC1
>
>
>
> Christian,
> The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
> the
> binary release.
> Regards, Kelvin.
>
> On 15/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> >
> > What version of EMF and SDO api is needed for this release?
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 15. marts 2007 16:42
> > To: tuscany-dev; Tuscany Users
> > Subject: SDO Java M3 Release Candidate RC1
> >
> > I have posted an SDO Java M3 release candidate here:
> >
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > pache.org/%7Erobbinspg/M3-RC1/>
> >
> > Please take a look at this and try it out, so that I can pick up any
> > errors
> > quickly and move towards a vote on a proper release in the short
term.
> >
> > Thanks, Kelvin.
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
You need to get your DataFactory from the HelperContext:
DataObject documentDataObject = hc.getDataFactory().create(namespace,
"DocumentRoot");
You should generally stop using INSTANCE fields in all cases, because they
are probably going to be deprecated in the next version of SDO.
HelperContext is the replacement. It defines a metadata scope, so you
should always use it to get the helpers for your scope.
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
wrote on 03/26/2007 01:01:00 PM:
>
> In M2 & M3 this works for a specific schema:
>
> XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
> But this doesn't
>
> HelperContext hc = SDOUtil.createHelperContext(true);
> hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
>
> DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
> "DocumentRoot");
>
>
> java.lang.IllegalArgumentException
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:63)
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
> a:46)
> at
> sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
> ndExtensibleNamespaces.java:153)
> at
> sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
> tensibleNamespaces.java:77)
>
>
> Any ideas?
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 22. marts 2007 13:38
> To: tuscany-user@ws.apache.org
> Subject: RE: SDO Java M3 Release Candidate RC1
>
> Sorry, there's not much documentation, just the JavaDoc. You need to get
> a
> HelperContext by calling SDOUtil.createHelperContext() and then get your
>
> XSDHelper from it.
>
> If you want the new extensible namespaces behavior you need to pass
> "true"
> to createHelperContext:
>
> HelperContext hc = SDOUtil.createHelperContext(true);
>
> Frank.
>
>
>
>
> "Christian Landbo Frederiksen" <Ch...@ementor.dk>
>
> 03/22/2007 06:30 AM
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
>
> Subject
> RE: SDO Java M3 Release Candidate RC1
>
>
>
>
>
>
> The testcase I used the last time does not function using SDO M3, but I
> guess It is because I can't just use XSDHelper.INSTANCE. I remember
> Frank
> mentioning something about helpercontexts. Have you got any
> documentation
> as to hov this is done.
>
> /Chr
>
> ps. the test case is the one from:
> https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
> <
> https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
> pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
> .issuetabpanels:comment-tabpanel%23action_12473251
> >
>
>
>
> ________________________________
>
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: Fri 3/16/2007 9:14 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO Java M3 Release Candidate RC1
>
>
>
> Christian,
> The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
> the
> binary release.
> Regards, Kelvin.
>
> On 15/03/07, Christian Landbo Frederiksen <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> >
> > What version of EMF and SDO api is needed for this release?
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 15. marts 2007 16:42
> > To: tuscany-dev; Tuscany Users
> > Subject: SDO Java M3 Release Candidate RC1
> >
> > I have posted an SDO Java M3 release candidate here:
> >
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> > pache.org/%7Erobbinspg/M3-RC1/>
> >
> > Please take a look at this and try it out, so that I can pick up any
> > errors
> > quickly and move towards a vote on a proper release in the short term.
> >
> > Thanks, Kelvin.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
In M2 & M3 this works for a specific schema:
XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
"DocumentRoot");
But this doesn't
HelperContext hc = SDOUtil.createHelperContext(true);
hc.getXSDHelper().define(new String(xsdFile.getBytes("UTF-8")));
DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
"DocumentRoot");
java.lang.IllegalArgumentException
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:63)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:46)
at
sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestTypeChangesA
ndExtensibleNamespaces.java:153)
at
sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeChangesAndEx
tensibleNamespaces.java:77)
Any ideas?
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 22. marts 2007 13:38
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Sorry, there's not much documentation, just the JavaDoc. You need to get
a
HelperContext by calling SDOUtil.createHelperContext() and then get your
XSDHelper from it.
If you want the new extensible namespaces behavior you need to pass
"true"
to createHelperContext:
HelperContext hc = SDOUtil.createHelperContext(true);
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
03/22/2007 06:30 AM
Please respond to
tuscany-user@ws.apache.org
To
<tu...@ws.apache.org>
cc
Subject
RE: SDO Java M3 Release Candidate RC1
The testcase I used the last time does not function using SDO M3, but I
guess It is because I can't just use XSDHelper.INSTANCE. I remember
Frank
mentioning something about helpercontexts. Have you got any
documentation
as to hov this is done.
/Chr
ps. the test case is the one from:
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.ji
ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
<
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.a
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
.issuetabpanels:comment-tabpanel%23action_12473251
>
________________________________
From: kelvin goodson [mailto:kelvingoodson@gmail.com]
Sent: Fri 3/16/2007 9:14 AM
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Christian,
The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in
the
binary release.
Regards, Kelvin.
On 15/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
>
> What version of EMF and SDO api is needed for this release?
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 15. marts 2007 16:42
> To: tuscany-dev; Tuscany Users
> Subject: SDO Java M3 Release Candidate RC1
>
> I have posted an SDO Java M3 release candidate here:
>
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> pache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Sorry, there's not much documentation, just the JavaDoc. You need to get a
HelperContext by calling SDOUtil.createHelperContext() and then get your
XSDHelper from it.
If you want the new extensible namespaces behavior you need to pass "true"
to createHelperContext:
HelperContext hc = SDOUtil.createHelperContext(true);
Frank.
"Christian Landbo Frederiksen" <Ch...@ementor.dk>
03/22/2007 06:30 AM
Please respond to
tuscany-user@ws.apache.org
To
<tu...@ws.apache.org>
cc
Subject
RE: SDO Java M3 Release Candidate RC1
The testcase I used the last time does not function using SDO M3, but I
guess It is because I can't just use XSDHelper.INSTANCE. I remember Frank
mentioning something about helpercontexts. Have you got any documentation
as to hov this is done.
/Chr
ps. the test case is the one from:
https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473251
<
https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel%23action_12473251
>
________________________________
From: kelvin goodson [mailto:kelvingoodson@gmail.com]
Sent: Fri 3/16/2007 9:14 AM
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Christian,
The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in the
binary release.
Regards, Kelvin.
On 15/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
>
> What version of EMF and SDO api is needed for this release?
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 15. marts 2007 16:42
> To: tuscany-dev; Tuscany Users
> Subject: SDO Java M3 Release Candidate RC1
>
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> pache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
The testcase I used the last time does not function using SDO M3, but I guess It is because I can't just use XSDHelper.INSTANCE. I remember Frank mentioning something about helpercontexts. Have you got any documentation as to hov this is done.
/Chr
ps. the test case is the one from: https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473251 <https://webmail.topnordic.com/exchweb/bin/redir.asp?URL=https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel%23action_12473251>
________________________________
From: kelvin goodson [mailto:kelvingoodson@gmail.com]
Sent: Fri 3/16/2007 9:14 AM
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Christian,
The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in the
binary release.
Regards, Kelvin.
On 15/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
>
> What version of EMF and SDO api is needed for this release?
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 15. marts 2007 16:42
> To: tuscany-dev; Tuscany Users
> Subject: SDO Java M3 Release Candidate RC1
>
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> pache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
Christian,
The required jars for EMF 2.2.2 and the SDO 2.1 API are packaged in the
binary release.
Regards, Kelvin.
On 15/03/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
>
> What version of EMF and SDO api is needed for this release?
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 15. marts 2007 16:42
> To: tuscany-dev; Tuscany Users
> Subject: SDO Java M3 Release Candidate RC1
>
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
> pache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
RE: SDO Java M3 Release Candidate RC1
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
What version of EMF and SDO api is needed for this release?
-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com]
Sent: 15. marts 2007 16:42
To: tuscany-dev; Tuscany Users
Subject: SDO Java M3 Release Candidate RC1
I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.a
pache.org/%7Erobbinspg/M3-RC1/>
Please take a look at this and try it out, so that I can pick up any
errors
quickly and move towards a vote on a proper release in the short term.
Thanks, Kelvin.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
URL Correction,
It seems that the GMail interface has once again thwarted me. It seems that
the underlying URL in my post above is wrong. It should lead you to
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
Regards, Kelvin.
On 15/03/07, kelvin goodson <ke...@gmail.com> wrote:
>
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
> <http://people.apache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors quickly and move towards a vote on a proper release in the short
> term.
>
> Thanks, Kelvin.
>
Re: SDO Java M3 Release Candidate RC1
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It seems the correct link is
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/.
Thanks,
Raymond
----- Original Message -----
From: "kelvin goodson" <ke...@gmail.com>
To: "tuscany-dev" <tu...@ws.apache.org>; "Tuscany Users"
<tu...@ws.apache.org>
Sent: Thursday, March 15, 2007 8:42 AM
Subject: SDO Java M3 Release Candidate RC1
>I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/<http://people.apache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors
> quickly and move towards a vote on a proper release in the short term.
>
> Thanks, Kelvin.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Java M3 Release Candidate RC1
Posted by kelvin goodson <ke...@gmail.com>.
URL Correction,
It seems that the GMail interface has once again thwarted me. It seems that
the underlying URL in my post above is wrong. It should lead you to
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
Regards, Kelvin.
On 15/03/07, kelvin goodson <ke...@gmail.com> wrote:
>
> I have posted an SDO Java M3 release candidate here:
> http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
> <http://people.apache.org/%7Erobbinspg/M3-RC1/>
>
> Please take a look at this and try it out, so that I can pick up any
> errors quickly and move towards a vote on a proper release in the short
> term.
>
> Thanks, Kelvin.
>