Skip to main content



      Home
Home » Modeling » UML2 » Problems in RedefinableTemplateSignature(NullPointerException handling associations of RedefinableTemplateSignature)
Problems in RedefinableTemplateSignature [message #900476] Tue, 07 August 2012 05:03 Go to next message
Eclipse UserFriend
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 423 times)
Re: Problems in RedefinableTemplateSignature [message #900484 is a reply to message #900476] Tue, 07 August 2012 05:21 Go to previous messageGo to next message
Eclipse UserFriend
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 #1227235 is a reply to message #900484] Fri, 03 January 2014 18:25 Go to previous messageGo to next message
Eclipse UserFriend
Was this ever reported as a bug? I can't find any bug report in Bugzilla, and I believe I am running into the same problem in the Kepler release.
Re: Problems in RedefinableTemplateSignature [message #1227394 is a reply to message #1227235] Sat, 04 January 2014 06:00 Go to previous messageGo to next message
Eclipse UserFriend
HI

I cannot reproduce the claimed exception on Juno, Kepler or Luna M4.

Please report a reproducible bug.

Regards

Ed Willink

On 03/01/2014 23:25, Ed Seidewitz wrote:
> Was this ever reported as a bug? I can't find any bug report in
> Bugzilla, and I believe I am running into the same problem in the
> Kepler release.
Re: Problems in RedefinableTemplateSignature [message #1227540 is a reply to message #1227394] Sat, 04 January 2014 16:08 Go to previous messageGo to next message
Eclipse UserFriend
Ed --

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=424895, which includes a Java program to reproduce the bug under Kepler. For the exception to occur, the RedefinableTemplateSignature must be owned by a Resource before it is then set as the ownedTemplateSignature of a Classifier. This happened to me during a QVT transformation, in which seemingly creating the RedefinableTemplateSignature in the output UML extent placed it into the output Resource content prior to the attempt to set it as an ownedTemplateSignature.

-- Ed
Re: Problems in RedefinableTemplateSignature [message #1227549 is a reply to message #1227540] Sat, 04 January 2014 16:44 Go to previous messageGo to next message
Eclipse UserFriend
Hi

UML 2.5 defines

RedefinableTemplateSignature .classifier[1] {composes}

so containment in a Resource is illegal UML-wise. The NPEs from EMF are
unfriendly but there are limits to the extent to which EMF can diagnose
every possible idiotic user behaviour. Perhaps the UML support
infrastructure could be better.

Since EMF doesn't really support [1] composition, perhaps the modeling
needs to distinguish [1] during validation but [0..1] during construction.

The outright bug is in QVTo iff the RTS was placed in the extent, but
from your words it sounds as if you may have done this yourself. In this
case QVTo could give a warning.

Can you provide a QVTo repro please.

Regards

Ed Willink


On 04/01/2014 21:08, Ed Seidewitz wrote:
> Ed --
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=424895, which
> includes a Java program to reproduce the bug under Kepler. For the
> exception to occur, the RedefinableTemplateSignature must be owned by
> a Resource before it is then set as the ownedTemplateSignature of a
> Classifier. This happened to me during a QVT transformation, in which
> seemingly creating the RedefinableTemplateSignature in the output UML
> extent placed it into the output Resource content prior to the attempt
> to set it as an ownedTemplateSignature.
>
> -- Ed
Re: Problems in RedefinableTemplateSignature [message #1227893 is a reply to message #1227549] Sun, 05 January 2014 18:34 Go to previous messageGo to next message
Eclipse UserFriend
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 18:37] by Moderator

Re: Problems in RedefinableTemplateSignature [message #1227980 is a reply to message #1227893] Mon, 06 January 2014 01:06 Go to previous messageGo to next message
Eclipse UserFriend
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
Re: Problems in RedefinableTemplateSignature [message #1227983 is a reply to message #1227980] Mon, 06 January 2014 01:17 Go to previous message
Eclipse UserFriend
Hi

When I run your transformation snippet, I see no problem, but since you
provided no test project, maybe I don't run it in the same way as you.

Perhaps http://wiki.eclipse.org/OCL/ForumNetiquette will help you
prepare a repro.

Regards

Ed Willink




On 06/01/2014 06:06, Ed Willink wrote:
>
> 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.
Previous Topic:UML help
Next Topic:Problem reading model with SysML 1.3 stereotypes applied
Goto Forum:
  


Current Time: Mon Jul 07 13:55:48 EDT 2025

Powered by FUDForum. Page generated in 0.09369 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top