| Problems in RedefinableTemplateSignature [message #900476] |
Tue, 07 August 2012 09:03  |
 Miguel A. de Miguel
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
The metaclass RedefinableTemplateSignature has some problems in Juno implementations of UML2. The problem was in previous versions too, in our tools we didn't have too many problems because the exception was handled in EMF packages.
We have attached a simple example. Open the model with a uml2.uml.editor, select the RedefinableTemplateSignature element for the edition in property sheets and you'll the exception.
Classifier and RedefinableTemplateSignature has an association, that redefines the assocaition between TemplateableElement and TemplateSignature metaclasses.
We suppose that the problem is the type of "duplicated" EReference in UML.ecore ownedTemplateSignature in metaclass Classifier (the type is TemplateSignature, and this should be RedefinableTemplateSignature, as in uml metamodel and standard). When EMF try to get the opposite in this assication generates null pointer exception. And some tools such as GMF does not handle the exception. May be, the problem is in the generation of duplicate assotions, we haven't explored this.
Cheers,
Miguel
Attachment: template.uml
(Size: 0.53KB, Downloaded 99 times)
|
|
|
| Re: Problems in RedefinableTemplateSignature [message #900484 is a reply to message #900476] |
Tue, 07 August 2012 09:21  |
Ed Willink
Messages: 4903
Registered: July 2009 |
Senior Member |
|
|
Hi
This is clearly a bug with a good repro. Please raise a Bugzilla for it.
Regards
Ed Willink
On 07/08/2012 10:03, Miguel A. de Miguel wrote:
> The metaclass RedefinableTemplateSignature has some problems in Juno implementations of UML2. The problem was in previous versions too, in our tools we didn't have too many problems because the exception was handled in EMF packages.
>
> We have attached a simple example. Open the model with a uml2.uml.editor, select the RedefinableTemplateSignature element for the edition in property sheets and you'll the exception.
>
> Classifier and RedefinableTemplateSignature has an association, that redefines the assocaition between TemplateableElement and TemplateSignature metaclasses.
>
> We suppose that the problem is the type of "duplicated" EReference in UML.ecore ownedTemplateSignature in metaclass Classifier (the type is TemplateSignature, and this should be RedefinableTemplateSignature, as in uml metamodel and standard). When EMF try to get the opposite in this assication generates null pointer exception. And some tools such as GMF does not handle the exception. May be, the problem is in the generation of duplicate assotions, we haven't explored this.
>
> Cheers,
>
> Miguel
|
|
|
|
|
|
|
| Re: Problems in RedefinableTemplateSignature [message #1227893 is a reply to message #1227549] |
Sun, 05 January 2014 23:34 |
Ed Seidewitz
Messages: 7
Registered: July 2011 |
Junior Member |
|
|
Ed --
As far as I know there is no way to create an instance of a metaclass in QVTo outside of some extent. Let me know if you have an alternative -- currently I am using a blackbox unit as a workaround, but that obviously should not be necessary.
I would also suggest that, just as a matter of good Java style, the UML2 API shouldn't be throwing mysterious null point exceptions. In this case, the only way to create a RedefinableTemplateSignature is as unowned (there is no createOwnedTemplateSignature operation on TemplateableElement or Classifier), there is nothing to stop you from putting such an element into the content of a resource (as you can with any other element), and it is only when you then try to properly put it into the ownedTemplateSignature attribute of some classifier that the exception is thrown. To me, this not only seems unfriendly it is downright derogatory.
Would it really be so hard to check for the null and then do the right thing?
It doesn't seem to be letting me upload a QVT file for some reason, so here inline is a simple transformation that reproduces the bug in QVTo:
modeltype UML uses "http://www.eclipse.org/uml2/4.0.0/UML";
transformation RedefinableTemplateSignatureBug(inout uml : UML);
main() {
var s = object RedefinableTemplateSignature { };
var c = object Class {
ownedTemplateSignature := s
}
}
-- Ed
[Updated on: Sun, 05 January 2014 23:37] Report message to a moderator |
|
|
| Re: Problems in RedefinableTemplateSignature [message #1227980 is a reply to message #1227893] |
Mon, 06 January 2014 06:06 |
Ed Willink
Messages: 4903
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
For the most I fully agreee, but as I commented on the Bugzilla
The NPEs from EMF are unfriendly but there are limits to the extent to which EMF can diagnose every possible idiotic user behaviour.
EMF works in principle with well-formed models and meta-models. If every
run-time action is accompanied by validation, the performance
degradations can be severe. It's a trade-off.
However in the case of NPEs, I look forward to EMF adopting @NonNull and
@Nullable annotations so that many hidden bugs can be exposed. If you
feel strongly, promote my comment that
eContainmentFeature has many ways of returning null
into an EMF bug.
As it stands I am aware that the UML support has many extra
complexities, so I have left the bug open in the hope that one of the
UML experts can decide whether it is the UML or EMF infrastructure that
is deficient.
For QVTo there may be a significant bug that may ripple upwards; you
didn't attach the transformation project. (Argh!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=424910, your forum message
is longer than the newsgroup!). I'll investigate.
Regards
Ed Willink
On 05/01/2014 23:34, Ed Seidewitz wrote:
> Ed --
>
> As far as I know there is no way to create an instance of a metaclass
> in QVTo outside of some extent. I have attached a QVT transformation
> that reproduces the bug. Let me know if you have an alternative --
> currently I am using a blackbox unit as a workaround, but that
> obviously should not be necessary.
>
> I would also suggest that, just as a matter of good Java style, the
> UML2 API shouldn't be throwing mysterious null point exceptions. In
> this case, the only way to create a RedefinableTemplateSignature is as
> unowned (there is no createOwnedTemplateSignature operation on
> TemplateableElement or Classifier), there is nothing to stop you from
> putting such an element into the content of a resource (as you can
> with any other element), and it is only when you then try to properly
> put it into the ownedTemplateSignature attribute of some classifier
> that the exception is thrown. To me, this not only seems unfriendly it
> is downright derogatory.
>
> Would it really be so hard to check for the null and then do the right
> thing?
>
> -- Ed
|
|
|
|
Powered by
FUDForum. Page generated in 0.05146 seconds
Search
Help
Register
Login
Home
