Home » Modeling » EMF » adding operations to java objects via XSD model annotation
|
| Re: adding operations to java objects via XSD model annotation [message #419294 is a reply to message #419293] |
Sat, 17 May 2008 01:22   |
 Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Jason,
Comments below.
jason henriksen wrote:
> Hi Ed,
>
> I think I've found a bug, but I wanted to ask before I logged it. I'm
> using EMF 2.3.0 as of the 20070530 build. (I know it really old, but
> without a visible problem I can't upgrade it. If this is fixed I'll
> have an excuse to upgrade to the latest 2.3.x!)
>
> The trouble is specifying an exception on an operation:
>
> <xsd:complexType name="Soldier">
>
> <xsd:annotation>
> <xsd:appinfo ecore:key="operations"
> source="http://www.eclipse.org/emf/2002/Ecore">
>
> <!-- add a complex action to use a helper object -->
> <!-- Provides a starter rank and a new serial number -->
> <operation
> exceptions="com.ibm.example.soldier:Exception"
Did you define a simple type that corresponds to Exception? The types
listed here must resolve properly just as when you use them in
<xsd:element name="xxx" type="com.ibm.example.soldier:Exception"/>
> name="enlistSoldier">
> <body>
> if(this.getSerial()!=null){
> throw new Exception("This object is already initialized");
> }
> <%com.vsp.example.SoldierHelper%>.initialize(t his);
> </body>
> </operation>
>
> I would expect the generated java method to have a throws clause, but
> it does not. When I look at the ecore that was generated from this
> XSD I get this:
>
> <eOperations name="enlistSoldier">
> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
> <details key="body" value="...the code..."/>
> </eAnnotations>
> </eOperations>
>
> However if I fix the code and generate a new EMF model from that fixed
> code I get this:
>
> <eOperations name="enlistSoldier" eExceptions="#//Exception">
> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
> <details key="body" value="...the code..."/>
> </eAnnotations>
> </eOperations>
>
> If I export this new ecore to XSD I get the same XSD that I started
> with, hence my suspicion that this is a bug in the XSD -> Ecore
> conversion. (BTW, I am specifying the simpleType for the Exception
> and marking it with ecore:instanceType.
If you take the same type reference and use it in an element or
attribute declaration, does it resolve correctly?
> I lifted that from the exported XSD model too and that part seems to
> be working ok)
If you can send me a complete example, I'll have a look.
>
> Is this bug fixed later in the 2.3 builds? If not, could it be?
2.4 is nearly GA, so I can certainly fix it there if there's a
problem... I'll have a look as soon as I have your example...
>
> Thanks much!
>
> Jason Henriksen
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: adding operations to java objects via XSD model annotation [message #419339 is a reply to message #419294] |
Mon, 19 May 2008 16:22 |
Jason Henriksen
Messages: 231
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000203020605090403060006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Ed,
I don't know why I didn't just attach the whole file to begin with.
I'm fairly sure all of the exception declaration is handled correctly
because I copied it out of the XSD exported from an ecore that I'd
generated from Java.
Unfortunately, there's no way my client would let me upgrade to the
latest GA release. If this is a bug and you decide not to fix it in 2.3
could you send me a patch to that I can fix the 2.3 code? We're running
2.3.0 and I'm trying to convince the team to upgrade to 2.3.2 but we're
getting close to a production release. 2.4 would be right out.
Anyway, thanks for taking a look at my XSD,
Jason
Ed Merks wrote:
> Jason,
>
> Comments below.
>
> jason henriksen wrote:
>> Hi Ed,
>>
>> I think I've found a bug, but I wanted to ask before I logged it. I'm
>> using EMF 2.3.0 as of the 20070530 build. (I know it really old, but
>> without a visible problem I can't upgrade it. If this is fixed I'll
>> have an excuse to upgrade to the latest 2.3.x!)
>>
>> The trouble is specifying an exception on an operation:
>>
>> <xsd:complexType name="Soldier">
>>
>> <xsd:annotation>
>> <xsd:appinfo ecore:key="operations"
>> source="http://www.eclipse.org/emf/2002/Ecore">
>>
>> <!-- add a complex action to use a helper object -->
>> <!-- Provides a starter rank and a new serial number -->
>> <operation
>> exceptions="com.ibm.example.soldier:Exception"
> Did you define a simple type that corresponds to Exception? The types
> listed here must resolve properly just as when you use them in
> <xsd:element name="xxx" type="com.ibm.example.soldier:Exception"/>
>> name="enlistSoldier">
>> <body>
>> if(this.getSerial()!=null){
>> throw new Exception("This object is already initialized");
>> }
>> <%com.vsp.example.SoldierHelper%>.initialize(t his);
>> </body>
>> </operation>
>>
>> I would expect the generated java method to have a throws clause, but
>> it does not. When I look at the ecore that was generated from this
>> XSD I get this:
>>
>> <eOperations name="enlistSoldier">
>> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
>> <details key="body" value="...the code..."/>
>> </eAnnotations>
>> </eOperations>
>>
>> However if I fix the code and generate a new EMF model from that fixed
>> code I get this:
>>
>> <eOperations name="enlistSoldier" eExceptions="#//Exception">
>> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
>> <details key="body" value="...the code..."/>
>> </eAnnotations>
>> </eOperations>
>>
>> If I export this new ecore to XSD I get the same XSD that I started
>> with, hence my suspicion that this is a bug in the XSD -> Ecore
>> conversion. (BTW, I am specifying the simpleType for the Exception
>> and marking it with ecore:instanceType.
> If you take the same type reference and use it in an element or
> attribute declaration, does it resolve correctly?
>> I lifted that from the exported XSD model too and that part seems to
>> be working ok)
> If you can send me a complete example, I'll have a look.
>>
>> Is this bug fixed later in the 2.3 builds? If not, could it be?
> 2.4 is nearly GA, so I can certainly fix it there if there's a
> problem... I'll have a look as soon as I have your example...
>>
>> Thanks much!
>>
>> Jason Henriksen
--------------000203020605090403060006
Content-Type: text/xml;
name="Soldier.xsd"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Soldier.xsd"
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHhzZDpz Y2hlbWEgCnht
bG5zOmNvbS5pYm0uZXhhbXBsZS5GYW1pbHk9Imh0dHA6Ly8vY29tL2libS9l eGFtcGxlL0Zh
bWlseS5lY29yZSIgCnhtbG5zOmVjb3JlPSJodHRwOi8vd3d3LmVjbGlwc2Uu b3JnL2VtZi8y
MDAyL0Vjb3JlIiAKeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAx L1hNTFNjaGVt
YSIgCmVjb3JlOm5zUHJlZml4PSJjb20uaWJtLmV4YW1wbGUuc29sZGllciIg CmVjb3JlOnBh
Y2thZ2U9ImNvbS5pYm0uZXhhbXBsZS5zb2xkaWVyIiAKdGFyZ2V0TmFtZXNw YWNlPSJodHRw
Oi8vL2NvbS9pYm0vZXhhbXBsZS9zb2xkaWVyLmVjb3JlIj4KDQogIDwhLS0g VGhpcyBpcyB2
ZXJ5IGltcG9ydGFudCEgIFlvdSdyZSBkZWZpbmVkIG1ldGhvZHMgY2Fubm90 IHRocm93IGFu
IGV4Y2VwdGlvbiB1bmxlc3MgeW91IGRlZmluZSB0aGlzIFhTRCB0eXBlISAt LT4gIA0KICA8
eHNkOnNpbXBsZVR5cGUgbmFtZT0iRXhjZXB0aW9uIg0KICAgIGVjb3JlOmlu c3RhbmNlQ2xh
c3M9ImphdmEubGFuZy5FeGNlcHRpb24iICAgDQogID4NCiAgICA8eHNkOnJl c3RyaWN0aW9u
IGJhc2U9InhzZDpzdHJpbmciLz4NCiAgPC94c2Q6c2ltcGxlVHlwZT4NCgo8 eHNkOmNvbXBs
ZXhUeXBlIG5hbWU9IlNvbGRpZXIiPg0KDQogIDx4c2Q6YW5ub3RhdGlvbj4N CiAgPHhzZDph
cHBpbmZvIGVjb3JlOmtleT0ib3BlcmF0aW9ucyIgc291cmNlPSJodHRwOi8v d3d3LmVjbGlw
c2Uub3JnL2VtZi8yMDAyL0Vjb3JlIj4NCiAgDQogIDwhLS0gYWRkIGEgYmFz aWMgYWN0aW9u
IHRvIGRldGVybWluZSB3aG8gb3V0cmFua3Mgd2hvIC0tPg0KICA8IS0tIEdp dmVuIGEgcmFu
ayBkb2VzIHRoaXMgcGVyc29uIG91dHJhbmsgdGhhdCBwZXJzb24gLS0+ICAN CiAgPG9wZXJh
dGlvbiANCiAgICBuYW1lPSJpc0hpZ2hlclJhbmtUaGFuIiANCiAgICB0eXBl PSJ4c2Q6Ym9v
bGVhbiINCiAgPg0KICAgIDxwYXJhbWV0ZXIgbmFtZT0iY29tcGFyZVRvUmFu ayIgdHlwZT0i
eHNkOnN0cmluZyIvPg0KICAgIDxib2R5Pg0KCSAgcmV0dXJuIHRoaXMuZ2V0 UmFuaygpLmNv
bXBhcmVUbyhjb21wYXJlVG9SYW5rKT09MTsNCiAgICA8L2JvZHk+DQogIDwv b3BlcmF0aW9u
Pg0KDQogIDwhLS0gYWRkIGEgY29tcGxleCBhY3Rpb24gdG8gdXNlIGEgaGVs cGVyIG9iamVj
dCAtLT4NCiAgPCEtLSBQcm92aWRlcyBhIHN0YXJ0ZXIgcmFuayBhbmQgYSBu ZXcgc2VyaWFs
IG51bWJlciAtLT4NCiAgPG9wZXJhdGlvbiBleGNlcHRpb25zPSJjb20uaWJt LmV4YW1wbGUu
c29sZGllcjpFeGNlcHRpb24iIG5hbWU9ImVubGlzdFNvbGRpZXIiPg0KICAg IDxib2R5Pg0K
ICAgICAgaWYodGhpcy5nZXRTZXJpYWwoKSE9bnVsbCl7DQogICAgICAgIHRo cm93IG5ldyBF
eGNlcHRpb24oIlRoaXMgb2JqZWN0IGlzIGFscmVhZHkgaW5pdGlhbGl6ZWQi KTsNCiAgICAg
IH0NCiAgICAgIC8vIG5vdGUgdGhhdCBpZiB5b3Ugd2FudCBhIGNsYXNzIGlt cG9ydGVkIHlv
dSBtdXN0IHdyYXAgaXQgd2l0aA0KICAgICAgLy8gW29wZW4gYW5nbGUgYnJh Y2tldF0lIGEu
Yi5jLkNsYXNzICVbY2xvc2UgYW5nbGUgYnJhY2tldF0gDQogICAgICAvLyBI b3dldmVyIFhT
RCBjYW4ndCB2YWxpZGF0ZSB0aGF0IHNvIHlvdSB1c2UgdGhlIChhbXAgbHQg c2VtaSkgYXMg
c2hvd24gaGVyZToNCiAgICAgICZsdDslY29tLnZzcC5leGFtcGxlLlNvbGRp ZXJIZWxwZXIl
Jmd0Oy5pbml0aWFsaXplKHRoaXMpOyAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgIDwvYm9keT4N CiAgPC9vcGVy
YXRpb24+DQoNCiAgICA8IS0tIGFkZCBhIGNvbXBsZXggYWN0aW9uIHVzZXIg YSAzcmQgcGFy
dHkgbGlicmFyIHRvIGNvbXBhcmUgdHdvIEVNRiBvYmplY3RzIC0tPg0KICAg IDwhLS0gY29t
cGFyZSB0aGlzIHRvIHRoYXQgLS0+DQoNCiAgICA8IS0tIGFkZCBhbiBPQ0wg dmFsaWRhdGlv
biAtLT4NCiAgICA8IS0tIHZhbGlkYXRlIHRoYXQgdGhlIGN1cnJlbnQgc2Vy aWFsIG51bWJl
ciBzdGFydHMgd2l0aCBhIGNhcGl0YWwgYW5kIGNvbnRhaW5zIG9ubHkgbGV0 dGVycyAtLT4N
Cg0KICAgIDwhLS0gYWRkIGEgbmFtZWQgcXVlcnk/IC0tPg0KICAgIDwhLS0g cmV0dXJucyB0
aGUgbnVtYmVyIG9mIHBlb3BsZSBpbiB0aGUgREIgd2l0aCB0aGUgc2FtZSBy YW5rIGFzIHRo
aXMgb2JqZWN0IC0tPg0KICA8L3hzZDphcHBpbmZvPjwveHNkOmFubm90YXRp b24+ICAgIA0K
ICAKICA8eHNkOnNlcXVlbmNlPgogIDwveHNkOnNlcXVlbmNlPg0KICAgIDwh LS0ganVzdCBo
YXZlIHNvbWUgZmllbGRzIHRvIHBsYXkgd2l0aCAtLT4KICAgIDx4c2Q6YXR0 cmlidXRlIG5h
bWU9Im5hbWUiIAkJdHlwZT0ieHNkOnN0cmluZyIvPg0KICAgIDx4c2Q6YXR0 cmlidXRlIG5h
bWU9InJhbmsiIAkJdHlwZT0ieHNkOnN0cmluZyIvPg0KICAgIDx4c2Q6YXR0 cmlidXRlIG5h
bWU9InNlcmlhbCIgCXR5cGU9InhzZDpzdHJpbmciLz4NCiAgPC94c2Q6Y29t cGxleFR5cGU+
Cg0KCjwveHNkOnNjaGVtYT4K
--------------000203020605090403060006--
|
|
|
| Re: adding operations to java objects via XSD model annotation [message #419343 is a reply to message #419339] |
Mon, 19 May 2008 21:45 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Jason,
Let's just assume it's a bug and open a bugzilla with the attached
file. I'll look at it first thing tomorrow. (Today's Victoria Day in
Canada.)
jason henriksen wrote:
>
> Hi Ed,
> I don't know why I didn't just attach the whole file to begin with.
>
> I'm fairly sure all of the exception declaration is handled correctly
> because I copied it out of the XSD exported from an ecore that I'd
> generated from Java.
>
> Unfortunately, there's no way my client would let me upgrade to the
> latest GA release. If this is a bug and you decide not to fix it in
> 2.3 could you send me a patch to that I can fix the 2.3 code? We're
> running 2.3.0 and I'm trying to convince the team to upgrade to 2.3.2
> but we're getting close to a production release. 2.4 would be right out.
>
> Anyway, thanks for taking a look at my XSD,
>
> Jason
>
>
>
>
> Ed Merks wrote:
>> Jason,
>>
>> Comments below.
>>
>> jason henriksen wrote:
>>> Hi Ed,
>>>
>>> I think I've found a bug, but I wanted to ask before I logged it.
>>> I'm using EMF 2.3.0 as of the 20070530 build. (I know it really
>>> old, but without a visible problem I can't upgrade it. If this is
>>> fixed I'll have an excuse to upgrade to the latest 2.3.x!)
>>>
>>> The trouble is specifying an exception on an operation:
>>>
>>> <xsd:complexType name="Soldier">
>>>
>>> <xsd:annotation>
>>> <xsd:appinfo ecore:key="operations"
>>> source="http://www.eclipse.org/emf/2002/Ecore">
>>>
>>> <!-- add a complex action to use a helper object -->
>>> <!-- Provides a starter rank and a new serial number -->
>>> <operation
>>> exceptions="com.ibm.example.soldier:Exception"
>> Did you define a simple type that corresponds to Exception? The
>> types listed here must resolve properly just as when you use them in
>> <xsd:element name="xxx" type="com.ibm.example.soldier:Exception"/>
>>> name="enlistSoldier">
>>> <body>
>>> if(this.getSerial()!=null){
>>> throw new Exception("This object is already initialized");
>>> }
>>> <%com.vsp.example.SoldierHelper%>.initialize(t his);
>>> </body>
>>> </operation>
>>>
>>> I would expect the generated java method to have a throws clause,
>>> but it does not. When I look at the ecore that was generated from
>>> this XSD I get this:
>>>
>>> <eOperations name="enlistSoldier">
>>> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
>>> <details key="body" value="...the code..."/>
>>> </eAnnotations>
>>> </eOperations>
>>>
>>> However if I fix the code and generate a new EMF model from that
>>> fixed code I get this:
>>>
>>> <eOperations name="enlistSoldier" eExceptions="#//Exception">
>>> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
>>> <details key="body" value="...the code..."/>
>>> </eAnnotations>
>>> </eOperations>
>>>
>>> If I export this new ecore to XSD I get the same XSD that I started
>>> with, hence my suspicion that this is a bug in the XSD -> Ecore
>>> conversion. (BTW, I am specifying the simpleType for the Exception
>>> and marking it with ecore:instanceType.
>> If you take the same type reference and use it in an element or
>> attribute declaration, does it resolve correctly?
>>> I lifted that from the exported XSD model too and that part seems to
>>> be working ok)
>> If you can send me a complete example, I'll have a look.
>>>
>>> Is this bug fixed later in the 2.3 builds? If not, could it be?
>> 2.4 is nearly GA, so I can certainly fix it there if there's a
>> problem... I'll have a look as soon as I have your example...
>>>
>>> Thanks much!
>>>
>>> Jason Henriksen
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: adding operations to java objects via XSD model annotation [message #419363 is a reply to message #419343] |
Tue, 20 May 2008 14:07 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Jason,
The XSDEcoreBuilder is expecting "exception" instead of "exceptions".
I'll change that in 2.4 to accept either. Eventually only the latter
will be accepted since the former was a mistake. Note that you didn't
declare
xmlns:com.ibm.example.soldier="http:///com/ibm/example/soldier.ecore"
so you'll need to add that to make this work. So it looks like using
"exception" in 2.3 should do the trick. Please open a bugzilla.
Ed Merks wrote:
> Jason,
>
> Let's just assume it's a bug and open a bugzilla with the attached
> file. I'll look at it first thing tomorrow. (Today's Victoria Day in
> Canada.)
>
>
> jason henriksen wrote:
>>
>> Hi Ed,
>> I don't know why I didn't just attach the whole file to begin with.
>>
>> I'm fairly sure all of the exception declaration is handled correctly
>> because I copied it out of the XSD exported from an ecore that I'd
>> generated from Java.
>>
>> Unfortunately, there's no way my client would let me upgrade to the
>> latest GA release. If this is a bug and you decide not to fix it in
>> 2.3 could you send me a patch to that I can fix the 2.3 code? We're
>> running 2.3.0 and I'm trying to convince the team to upgrade to 2.3.2
>> but we're getting close to a production release. 2.4 would be right
>> out.
>>
>> Anyway, thanks for taking a look at my XSD,
>>
>> Jason
>>
>>
>>
>>
>> Ed Merks wrote:
>>> Jason,
>>>
>>> Comments below.
>>>
>>> jason henriksen wrote:
>>>> Hi Ed,
>>>>
>>>> I think I've found a bug, but I wanted to ask before I logged it.
>>>> I'm using EMF 2.3.0 as of the 20070530 build. (I know it really
>>>> old, but without a visible problem I can't upgrade it. If this is
>>>> fixed I'll have an excuse to upgrade to the latest 2.3.x!)
>>>>
>>>> The trouble is specifying an exception on an operation:
>>>>
>>>> <xsd:complexType name="Soldier">
>>>>
>>>> <xsd:annotation>
>>>> <xsd:appinfo ecore:key="operations"
>>>> source="http://www.eclipse.org/emf/2002/Ecore">
>>>>
>>>> <!-- add a complex action to use a helper object -->
>>>> <!-- Provides a starter rank and a new serial number -->
>>>> <operation
>>>> exceptions="com.ibm.example.soldier:Exception"
>>> Did you define a simple type that corresponds to Exception? The
>>> types listed here must resolve properly just as when you use them in
>>> <xsd:element name="xxx" type="com.ibm.example.soldier:Exception"/>
>>>> name="enlistSoldier">
>>>> <body>
>>>> if(this.getSerial()!=null){
>>>> throw new Exception("This object is already initialized");
>>>> }
>>>> <%com.vsp.example.SoldierHelper%>.initialize(t his);
>>>> </body>
>>>> </operation>
>>>>
>>>> I would expect the generated java method to have a throws clause,
>>>> but it does not. When I look at the ecore that was generated from
>>>> this XSD I get this:
>>>>
>>>> <eOperations name="enlistSoldier">
>>>> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
>>>> <details key="body" value="...the code..."/>
>>>> </eAnnotations>
>>>> </eOperations>
>>>>
>>>> However if I fix the code and generate a new EMF model from that
>>>> fixed code I get this:
>>>>
>>>> <eOperations name="enlistSoldier" eExceptions="#//Exception">
>>>> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
>>>> <details key="body" value="...the code..."/>
>>>> </eAnnotations>
>>>> </eOperations>
>>>>
>>>> If I export this new ecore to XSD I get the same XSD that I started
>>>> with, hence my suspicion that this is a bug in the XSD -> Ecore
>>>> conversion. (BTW, I am specifying the simpleType for the Exception
>>>> and marking it with ecore:instanceType.
>>> If you take the same type reference and use it in an element or
>>> attribute declaration, does it resolve correctly?
>>>> I lifted that from the exported XSD model too and that part seems
>>>> to be working ok)
>>> If you can send me a complete example, I'll have a look.
>>>>
>>>> Is this bug fixed later in the 2.3 builds? If not, could it be?
>>> 2.4 is nearly GA, so I can certainly fix it there if there's a
>>> problem... I'll have a look as soon as I have your example...
>>>>
>>>> Thanks much!
>>>>
>>>> Jason Henriksen
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: adding operations to java objects via XSD model annotation [message #419364 is a reply to message #419363] |
Tue, 20 May 2008 14:47 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Jason,
I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=232985 so that I
could commit the fix for today's RC1 build.
Ed Merks wrote:
> Jason,
>
> The XSDEcoreBuilder is expecting "exception" instead of "exceptions".
> I'll change that in 2.4 to accept either. Eventually only the latter
> will be accepted since the former was a mistake. Note that you didn't
> declare
> xmlns:com.ibm.example.soldier="http:///com/ibm/example/soldier.ecore"
> so you'll need to add that to make this work. So it looks like using
> "exception" in 2.3 should do the trick. Please open a bugzilla.
>
>
> Ed Merks wrote:
>> Jason,
>>
>> Let's just assume it's a bug and open a bugzilla with the attached
>> file. I'll look at it first thing tomorrow. (Today's Victoria Day
>> in Canada.)
>>
>>
>> jason henriksen wrote:
>>>
>>> Hi Ed,
>>> I don't know why I didn't just attach the whole file to begin with.
>>>
>>> I'm fairly sure all of the exception declaration is handled
>>> correctly because I copied it out of the XSD exported from an ecore
>>> that I'd generated from Java.
>>>
>>> Unfortunately, there's no way my client would let me upgrade to the
>>> latest GA release. If this is a bug and you decide not to fix it in
>>> 2.3 could you send me a patch to that I can fix the 2.3 code? We're
>>> running 2.3.0 and I'm trying to convince the team to upgrade to
>>> 2.3.2 but we're getting close to a production release. 2.4 would be
>>> right out.
>>>
>>> Anyway, thanks for taking a look at my XSD,
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Jason,
>>>>
>>>> Comments below.
>>>>
>>>> jason henriksen wrote:
>>>>> Hi Ed,
>>>>>
>>>>> I think I've found a bug, but I wanted to ask before I logged it.
>>>>> I'm using EMF 2.3.0 as of the 20070530 build. (I know it really
>>>>> old, but without a visible problem I can't upgrade it. If this is
>>>>> fixed I'll have an excuse to upgrade to the latest 2.3.x!)
>>>>>
>>>>> The trouble is specifying an exception on an operation:
>>>>>
>>>>> <xsd:complexType name="Soldier">
>>>>>
>>>>> <xsd:annotation>
>>>>> <xsd:appinfo ecore:key="operations"
>>>>> source="http://www.eclipse.org/emf/2002/Ecore">
>>>>>
>>>>> <!-- add a complex action to use a helper object -->
>>>>> <!-- Provides a starter rank and a new serial number -->
>>>>> <operation
>>>>> exceptions="com.ibm.example.soldier:Exception"
>>>> Did you define a simple type that corresponds to Exception? The
>>>> types listed here must resolve properly just as when you use them
>>>> in <xsd:element name="xxx" type="com.ibm.example.soldier:Exception"/>
>>>>> name="enlistSoldier">
>>>>> <body>
>>>>> if(this.getSerial()!=null){
>>>>> throw new Exception("This object is already initialized");
>>>>> }
>>>>> <%com.vsp.example.SoldierHelper%>.initialize(t his);
>>>>> </body>
>>>>> </operation>
>>>>>
>>>>> I would expect the generated java method to have a throws clause,
>>>>> but it does not. When I look at the ecore that was generated from
>>>>> this XSD I get this:
>>>>>
>>>>> <eOperations name="enlistSoldier">
>>>>> <eAnnotations
>>>>> source="http://www.eclipse.org/emf/2002/GenModel">
>>>>> <details key="body" value="...the code..."/>
>>>>> </eAnnotations>
>>>>> </eOperations>
>>>>>
>>>>> However if I fix the code and generate a new EMF model from that
>>>>> fixed code I get this:
>>>>>
>>>>> <eOperations name="enlistSoldier" eExceptions="#//Exception">
>>>>> <eAnnotations
>>>>> source="http://www.eclipse.org/emf/2002/GenModel">
>>>>> <details key="body" value="...the code..."/>
>>>>> </eAnnotations>
>>>>> </eOperations>
>>>>>
>>>>> If I export this new ecore to XSD I get the same XSD that I
>>>>> started with, hence my suspicion that this is a bug in the XSD ->
>>>>> Ecore conversion. (BTW, I am specifying the simpleType for the
>>>>> Exception and marking it with ecore:instanceType.
>>>> If you take the same type reference and use it in an element or
>>>> attribute declaration, does it resolve correctly?
>>>>> I lifted that from the exported XSD model too and that part seems
>>>>> to be working ok)
>>>> If you can send me a complete example, I'll have a look.
>>>>>
>>>>> Is this bug fixed later in the 2.3 builds? If not, could it be?
>>>> 2.4 is nearly GA, so I can certainly fix it there if there's a
>>>> problem... I'll have a look as soon as I have your example...
>>>>>
>>>>> Thanks much!
>>>>>
>>>>> Jason Henriksen
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Sep 18 20:55:16 GMT 2024
Powered by FUDForum. Page generated in 0.03697 seconds |
] 
Search
Help
Register
Login
Home
