OsateResourceUtil bug? - Githubissues

mnam commented 12 years ago

Quick question in the OSATE code.

Is the OsateResourceUtil suppose to be fully working?

When I use a defaultTraversalAllDeclarativeModels() on one of my switches

it eventually calls the visitWorkspaceDeclarativeModels() in AbstractSimpleTraversal and the problem is that

When it does

final EList resources = OsateResourceUtil.getResourceSet().getResources();

it gets a zero list always.

Am I suppose to do something in the OSATE environment to load up OsateResourceUtil?

Only code that uses this is the architecture ModelStatisticsAnalysis plug in and you can see that

it also shows 0 for component type declarations, 0 component implementation declarations, and so on

for any model because of this problem.

Thanks. Sincerely, Min Young Nam

philip-alldredge commented 12 years ago

Min Young, I think I have encountered a similar issue. This seems like a bug to me.

In my plugin I am currently using a workaround. Try calling Aadl2Activator.getInstance(); before using defaultTraversalAllDeclarativeModels(). This seems to perform some initialization that isn't done under some circumstances.

mnam commented 12 years ago

Thanks for the comment but I'm afraid this doesn't work for me. Tried calling Aadl2Activator.getInstance() at the start of my plug-in and in some other places but OsateResourceUtil.getResourceSet().getResources() still gives a zero size list.

But good to know that it can work in some way. I don't think my build is wrong since even from the master snap-shot the Analysis -> Architecture -> Model statistics plug-in shows zero for any declaritive types.

philip-alldredge commented 12 years ago

My issue concerned using another method in OsateResourceUtil. I have not used getResourceSet so your initial thoughts about it not working may be correct.

reteprelief commented 12 years ago

Hi Min Young, Philip,

this is something I need to correct in short order. In OSATE 1.5 all resoruces in a workspace were always loaded. Therefore, if you wanted to process all declarative models the traversal could just find all of them in the resource set. You would traverse declarative models that may be unrelated.

In Osate V2 we have the issue that XText does lazy loading of resources, thus, we cannot assume that they declarative models are all loaded. However, we can take advantage of AADL V2 with clause to find all the declarative packages that actually are part of a given model.

What kind of processing are you trying to do on the model? In most cases my analysis plug-ins traverse the instance model and the trversal methods should work ok for that.

mnam commented 12 years ago

Hi Peter,

I use the defaultTraversalAllDeclarativeModels() to go through the workspace and find all process types that are declared and create a window with a list of available processes. From the window, I could just drag a process to a processor to add an application to a model. Connections are created through steps in a wizard. So I need to be able to traverse through the workspace.

This lazy loading is indeed causing me other problems. I normally would like to save any model changes into the declaritive model as well and not just the instance model. I'll usually get the ComponentClassifier of a ComponentInstance to do this and the Resource of ComponentClassifier is usually not loaded. At first I thought EcoreUtil.resolveAll() would always solve this. But, it causes some resolving errors for some elements (I'm thinking it is not loaded and thus randomly appears)

Also I had this case. I would comment out some lines in a type definition in AADL. Even clean the work space and rebuild. Run my tool. Do something that would update the type definition in resource. Then unparse it to aadl. What I would see is the aadl file is the added changes that I made but also the commented lines UNCOMMENTED. It looks like the commented model was not loaded yet even if I do a rebuild.

Is there a way of forcing the load of single resources before I update them and reparse it? I'm currently trying to figure this out.

reteprelief commented 12 years ago

Thanks for that feedback. It helps me determine how to best address these issues.

Peter

-----Original Message----- From: mnam [mailto:reply@reply.github.com] Sent: Friday, February 24, 2012 10:40 AM To: Peter Feiler Subject: Re: [osate2-core] OsateResourceUtil bug? (#42)

Hi Peter,

I use the defaultTraversalAllDeclarativeModels() to go through the workspace and find all process types that are declared and create a window with a list of available processes. From the window, I could just drag a process to a processor to add an application to a model. Connections are created through steps in a wizard. So I need to be able to traverse through the workspace.

This lazy loading is indeed causing me other problems. I normally would like to save any model changes into the declaritive model as well and not just the instance model. I'll usually get the ComponentClassifier of a ComponentInstance to do this and the Resource of ComponentClassifier is usually not loaded. At first I thought EcoreUtil.resolveAll() would always solve this. But, it causes some resolving errors for some elements (I'm thinking it is not loaded and thus randomly appears)

Also I had this case. I would comment out some lines in a type definition in AADL. Even clean the work space and rebuild. Run my tool. Do something that would update the type definition in resource. Then unparse it to aadl. What I would see is the aadl file is the added changes that I made but also the commented lines UNCOMMENTED. It looks like the commented model was not loaded yet even if I do a rebuild.

Is there a way of forcing the load of single resources before I update them and reparse it? I'm currently trying to figure this out.

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/42#issuecomment-4158889

peterhfeiler commented 12 years ago

I have some methods now that work with the EMF index maintained by XText. They give you the set of packages or the set of classifiers in packages without loading the model. This is useful when you want to let the user select a classifier,e.g., to be used for construction - without loading the whole world into memory. They are Description objects that contain the name, qualified name, the EClass, and the URI to the actual object. The later is given to you as object if in memory or as proxy. I'll write something up about that on the Wiki.

A question to you: In your scenario, where you drag the process to the processor, are you dragging an instance of a process, i.e., work with the instance model, or are you dragging a process type or implementation and as a result create a subcomponent and/or instance object?

I am using the ModelStatistics example to make sure things work better.

I'll also look at the other issue you mentioned: changing and updating the model

mnam commented 12 years ago

I have both functionalities. When dragging some component that is already there, it is the instance model but I do update the type definitions, well at least try although some information is missing. When adding a new component that is not in the instance model, I would have it dragged from a table and it is initially a type or implementation. After updating the type definition, I reinstantiate the whole model to update the instance model just to be sure. Use to do a partial instantiation but just made it whole.

Great, I'll look in the ModelStatistics plugin as a samle code when it is up.

Not sure if I'm doing something wrong here but I had repeated instances where I would make change 1 and change 2 to the same resource. Both do a load and resolve before making any changes. Even checked that the property values were correctly changed for change 1 even after doing change 2. Now I would unparse twice, after change 1 and change 2. The resulting file had only change 1 in the end 90 percent of the time. Sometimes it had change 1 and change 2. Unparsing just once did solve it but I had to write code for storing all the resources that I change so that I wont unparse the same file twice. But why wouldn't change 2 be unparsed?

philip-alldredge commented 12 years ago

I have come across an occasion where I need to get access to the declarative models without going through the instance model. Since defaultTraversalAllDeclarativeModels() isn't working as expected, is there a method/work around for opening a .aadl as a declarative model(as opposed to just reading it as a text string)?

What I'm trying to do is to find all component implementations, check if they meet certain characteristics, modify them based on external files and then unparse back to aadl.

philip-alldredge commented 12 years ago

Nevermind, I figured it out. The answer is to use OsateResourceUtil.getResource() to open the .aadl file. I thought it only worked on xmi model files.

reteprelief commented 12 years ago

Min Young, Philip,

I fixed up the traversals that cover the whole workspace. Instead of traversing the resoruceset they now traverse the file system to find the models to be accessed. The changes have been pushed to the develop branch.

I also have put together some methods that give you the list of aadl packages, or a list of classifiers (or of a given classifier class, e.g., ProcessorType) by using the EMF index that Xtext maintains for global qualified names. This works without loading the respective models by giving you an IEObjectDescription for each. That object has the reference (or proxy) to the actual object as well as the EClass of the object.

Look at DoModelStatistics - it has a code illustration of how to use it (in comments).

Still looking at the issue with changes to the model getting updated correctly into text. I have some ideas of what goes wrong.

philip-alldredge commented 12 years ago

Peter, Thanks for the updates.

This may be a case of user error, but I just built the develop branch and I ran across an issue when using defaultTraversalAllDeclarativeModels(). caseComponentImplementation(...) is now called with valid SystemImplementation objects as expected. Unfortunately when I call getAllSubcomponents() on those objects, I get an empty list. Is there anything I need to do to load the complete object. I tried various interactions of resolve and resolveAll without any success.

I looked at your example for getting classifiers and I was wondering if there is there a way to get an Aadl2LinkingService and getting all the classifiers without needing a model element or resource. In my case I am just trying to find all the classifiers and will edit them conditionally so I do not have a reference to a model element at this time.

reteprelief commented 12 years ago

I was able to fix getAadl2LinkingService and getPropertiesLinkingService to work without a parameter.

I added some sample code into DoModelStatistics and the caseComponentImplemetnation in the switch to test out the subcomponent list issue. Works in that code. pushed to develop branch

philip-alldredge commented 12 years ago

Thanks. The linking service example worked great. I had to pass in a new resource set in place of the one returned by obj.eResource().getResourceSet(). (Since I don't have resource set to pass in).

I did some investigation on the defaultTraversalAllDeclarativeModel issue I'm experiencing. For some classifiers, getAllSubcomponents() returns the correct value. On others it returns an empty list. The major difference I have noticed is that the classifiers that work are the ones that do not extend anything. The ones that do not work extend system implementations contained in another project.

The getAllSubcomponents method works correctly for these same System Implementations when retrieved using the linking service or the resource is loaded directly.

peterhfeiler commented 12 years ago

Can you send me some sample models to look into this?

Thanks

philip-alldredge commented 12 years ago

Peter, I have tried to find the simplest setup that reproduces the issue in my plugin. It requires having two packages. They can both be in the same project. Example below.

Debug.aadl:

package Debug
public
    system A
    end A;

system implementation A.impl
subcomponents 
    b1: system;
    end A.impl; 
end Debug;

Debug2.aadl:

package Debug2
public
    with Debug;

    system AExtended extends Debug::A
    end AExtended;

    system implementation AExtended.impl2 extends Debug::A.impl
    end AExtended.impl2;
end Debug2;

reteprelief commented 12 years ago

Ok. I see the error. Will be interesting to trace down. Lutz is using some UML queries in the Meta model to get the subcomponents for each implementation.

reteprelief commented 12 years ago

Resolved the issue. Had to do with misunderstanding how XText is managing resourcesets. I ended up creating more than one. This is fixed now. If you use the methods that return IEobjectDescriptions from the index allowing you to identifiy packages and classifiers without loading the models, they have moved the the ModelLoadingAdapter from Aadl2LinkingService.

philip-alldredge commented 12 years ago

Sorry for the delay. defaultTraversalAllDeclarativeModels() is now working as expected. Thanks for the quick fixes!

philip-alldredge commented 12 years ago

Looks like I've encountered another problem. Relevant portions of the stack trace are below.

at org.osate.aadl2.modelsupport.modeltraversal.TraverseWorkspace.getFiles(TraverseWorkspace.java:64)
at org.osate.aadl2.modelsupport.modeltraversal.TraverseWorkspace.getFiles(TraverseWorkspace.java:71)
at org.osate.aadl2.modelsupport.modeltraversal.TraverseWorkspace.getFiles(TraverseWorkspace.java:71)
at org.osate.aadl2.modelsupport.modeltraversal.TraverseWorkspace.getFiles(TraverseWorkspace.java:51)

Line 64 in my version of the source is "if (file.getFileExtension().equalsIgnoreCase(WorkspacePlugin.SOURCE_FILE_EXT)".

I believe getFileExtension() returns null if there is a file that does not have one. I haven't been able to find the file that is causing this in my workspace but that seems like the only possible cause.

Update: This issue started happening sometime after I added the model to a subversion repository. Subversion uses files without extensions in (normally)hidden folders. That may be the cause.

peterhfeiler commented 12 years ago

Found the problem. getFileExtension was returning null if no extension and an empty string if the file ends with "." (I had assumed it was always an empty string. I also added filtering out invisible folders, i.e., folders that start with "." Pushed to develop branch.

mnam commented 12 years ago

Hi Peter,

I found an issue and I believe that it is related with this topic again. Above, philip mentioned his problem with getAllSubcomponents() and I am experiencing this as well. I have multiple times done the same procedure and this always happens and I believe there is a simple fix that is in need.

My tool would try to add a instance of a selected process type to the model. In doing so, it would update instance file and the declaritive model where the process is added as a subcomponent. I'm using a simple model where all processes are in the top-level system implementation. After updating the declaritive model, which is the system implementation in (defined in A_Model.aadl), it would unparse and update the A_Model.aadl file. Up to now it looks like it is working. After doing this, for testing, I would delete the process subcomponent, that I just added, from the system implementation inside A_Model.aadl from OSATE by typing. I'll save it. I'll even do a clean of the work space. Delete the old instance model. Remake a new instance model and load the model into my tool. When I load the model, I don't see the process that I deleted from the instance model. But, when I use InstanceUtil.getComponentImplementation(systeminstance, 0, null).getAllSubcomponents() the system implementation that I get is an old one that includes the deleted process subcomponent. From now on, whatever change I make to the system implementation in the A_Model.aadl file, it is not applied to the system implementation that I get in code. Only way to make it work it right is to rebuild OSATE. I could clean, rebuild the workspace but the system implementation that I get would stay the same causing a mismatch in the system instance's content and the system implementation.

Looks like when I modify the system implementation by code and unparse it, I am breaking something or it was never suppose to be supported this way.

Thanks. Sincerely, Min Young

the A_Model.aadl file

reteprelief commented 12 years ago

Hi Min Young,

It looks like someone is holding on to the old instance model, which still points to the old system implementation. Can you check the resource set the original instance model and resource with the system implementation are in, and then do the same for the new instance model and system implementation resource?

Also, with the latest sources in the develop branch you will be able to just save the resource - I was able to get the Serializer of Xtext to work. You can try that instead of the unparse. To do the modification of the declarative model, they have a readonly and a modify transaction: http://koehnlein.blogspot.com/2010/06/semantic-model-access-in-xtext.html

See also the SerializeHandler in org.osate.xtext.aadl2.ui.handlers

Peter

-----Original Message----- From: mnam [mailto:reply@reply.github.com] Sent: Saturday, May 12, 2012 9:30 AM To: Peter Feiler Subject: Re: [osate2-core] OsateResourceUtil bug? (#42)

Hi Peter,

I found an issue and I believe that it is related with this topic again. Above, philip mentioned his problem with getAllSubcomponents() and I am experiencing this as well. I have multiple times done the same procedure and this always happens and I believe there is a simple fix that is in need.

My tool would try to add a instance of a selected process type to the model. In doing so, it would update instance file and the declaritive model where the process is added as a subcomponent. I'm using a simple model where all processes are in the top-level system implementation. After updating the declaritive model, which is the system implementation in (defined in A_Model.aadl), it would unparse and update the A_Model.aadl file. Up to now it looks like it is working. After doing this, for testing, I would delete the process subcomponent, that I just added, from the system implementation inside A_Model.aadl from OSATE by typing. I'll save it. I'll even do a clean of the work space. Delete the old instance model. Remake a new instance model and load the model into my tool. When I load the model, I don't see the process that I deleted from the instance model. But, when I use InstanceUtil.getComponentImplementation(systeminstance, 0, null).getAllSubcomponents() the system implementation that I get is an old one that includes the deleted process subcomponent. From now on, whatever change I make to the system implementation in the A_Model.aadl file, it is not applied to the system implementation that I get in code. Only way to make it work it right is to rebuild OSATE. I could clean, rebuild the workspace but the system implementation that I get would stay the same causing a mismatch in the system instance's content and the system implementation.

Looks like when I modify the system implementation by code and unparse it, I am breaking something or it was never suppose to be supported this way.

Thanks. Sincerely, Min Young

the A_Model.aadl file

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/42#issuecomment-5668470

mnam commented 12 years ago

Hi Peter,

At first I was suspicious that I may be holding onto the old instance model. But even if I check for the subcomponent from the system instance by systeminstance.getAllComponentInstances() right before I check its system implementation, I see that the delete process is not existing in the system instance but the system implementation has the subcomponent.

So, then what I checked is, as soon as my tool starts and get the system instance from doAaxlAction(IProgressMonitor monitor, Element obj) then final Element systeminstance = obj.getElementRoot();

and when I do systeminstance.getAllComponentInstances() I don't see the subcomponent component instance but InstanceUtil.getComponentImplementation(systeminstance, 0, null).getAllSubcomponents() this will show the deleted subcomponent.

So here, practically none of my code is gone through.

I'll try to use the serializer and see what happens.

Thanks!! Min Young

reteprelief commented 12 years ago

Min Young,

I found a place where Lutz uses a hashtable to access classifiers and prototype bindings more efficiently. That has table is not getting reset. I'll see if I can fix that.

Peter

-----Original Message----- From: mnam [mailto:reply@reply.github.com] Sent: Saturday, May 12, 2012 10:04 AM To: Peter Feiler Subject: Re: [osate2-core] OsateResourceUtil bug? (#42)

Hi Peter,

At first I was suspicious that I may be holding onto the old instance model. But even if I check for the subcomponent from the system instance by systeminstance.getAllComponentInstances() right before I check its system implementation, I see that the delete process is not existing in the system instance but the system implementation has the subcomponent.

So, then what I checked is, as soon as my tool starts and get the system instance from doAaxlAction(IProgressMonitor monitor, Element obj) then final Element systeminstance = obj.getElementRoot();

and when I do systeminstance.getAllComponentInstances() I don't see the subcomponent component instance but InstanceUtil.getComponentImplementation(systeminstance, 0, null).getAllSubcomponents() this will show the deleted subcomponent.

So here, practically none of my code is gone through.

I'll try to use the serializer and see what happens.

Thanks!! Min Young

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/42#issuecomment-5668699

reteprelief commented 12 years ago

Hi Min Young,

I fixed the hashtable problem. It was in the InstantiateHandler. It now creates an InstantiateModel object every time it creates an instance object.

You can find the fix in the develop branch.

Peter

-----Original Message----- From: mnam [mailto:reply@reply.github.com] Sent: Saturday, May 12, 2012 10:04 AM To: Peter Feiler Subject: Re: [osate2-core] OsateResourceUtil bug? (#42)

Hi Peter,

At first I was suspicious that I may be holding onto the old instance model. But even if I check for the subcomponent from the system instance by systeminstance.getAllComponentInstances() right before I check its system implementation, I see that the delete process is not existing in the system instance but the system implementation has the subcomponent.

So, then what I checked is, as soon as my tool starts and get the system instance from doAaxlAction(IProgressMonitor monitor, Element obj) then final Element systeminstance = obj.getElementRoot();

and when I do systeminstance.getAllComponentInstances() I don't see the subcomponent component instance but InstanceUtil.getComponentImplementation(systeminstance, 0, null).getAllSubcomponents() this will show the deleted subcomponent.

So here, practically none of my code is gone through.

I'll try to use the serializer and see what happens.

Thanks!! Min Young

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/42#issuecomment-5668699

mnam commented 12 years ago

Thanks for the quick fix Peter,

I'll see how it works.

Min Young

mnam commented 12 years ago

Hi Peter,

I'm afraid the change didn't fix this. I'm still seeing the old process as soon as I check after getting the system instance from doAaxlAction. Not in the system instance but only it its system implementation subcomponent list. This is even after I do a EList classifierlist = EMFIndexRetrieval.getAllClassifiersInWorkspace(); for (IEObjectDescription cleod : classifierlist){ Classifier cl = (Classifier) EcoreUtil.resolve(cleod.getEObjectOrProxy(), obj.eResource().getResourceSet()); }

right before checking inside doAaxlAction.

Did more testing and it is really weird. When I instantiate, I see that a system implementation without the process subcomponent is being set for the created system instance. When I read the system instance and the move to get the system implementation, it has the deleted process subcomponent while the system instance is correct as explained before.

Min Young

mnam commented 12 years ago

Oh also for the same instantiation file that would give me the deleted process subcomponent, If I close OSATE and rebuild and use the same instantiation file without rebuilding, it will no longer show the deleted process subcomponent.

Min Young

peterhfeiler commented 12 years ago

Hi Min Young,

Definitely odd. Are you still unparsing or just saving the file which uses the Xtext serializer? When unparsing the Xtext builder recompiles the file, which may affect the references from the instance model into the declarative model. But why would you get two different system implementations from the same instance object? The only thing I can think of is that one access is done inside a transaction on the model, while the other is done outside

with the transaction completion affecting the reference.

Peter

On 5/12/2012 12:42 PM, mnam wrote:

Oh also for the same instantiation file that would give me the deleted process subcomponent, If I close OSATE and rebuild and use the same instantiation file without rebuilding, it will no longer show the deleted process subcomponent.

Min Young

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/42#issuecomment-5669867

mnam commented 12 years ago

Hi Peter,

So I tried the serializer by just the simple save of the resource and it would generate the updated aadl file correctly. Then I did the same steps and I am seeing the same strange results. I'll investigate more.

Thanks. Min Young

mnam commented 12 years ago

Hi Peter,

I've found some surprising facts and believe this is bug in OSATE. My tool editing the model actually has nothing to do with it.

Only after doing the first instantiation, the system implementation is saved somewhere and is not
being updated any more. All resolve would load this old system implementation from then on. After the first instantiation, making any changes to the top-level system implementation will not affect what is given by the EcoreUtil.resolve. When saving the system implementation that is used for the system instance, it looks like although it would update the Resource, it is not updating whatever object that EcoreUtil.resolve is using.

The instantiation works fine because it uses the editor to directly read in the SystemImplementation. During instantiation, it would save the system implementation inside the system instance as 'systemImplementation". HOWEVER, when we open the system instance file with the Instance Model Editor by double clicking from the AADL Navigator, it would call the SystemInstanceImpl.setSystemImplementation and change the saved systemImplementation into a proxy. Then when we select the first element from the tree in the editor, it would call the getSystemImplementation() which would identify that systemImplementation is a proxy and do a resolve and set the systemImplementation into whatever object that it uses.

I only found this after putting print statements into the set and getSystemImplementation methods. When this behavior combined with the previous non-update issue, what we get is the mis-match of the systeminstance being correct but its system implementation not being changed.

You can check this behavior by using the following steps:

Create a top-level system implementation with say one subcomponent. Instantiated the system. (Need to do it once) Then deleted the system instance file. add another subcomponent to the system implementation. Instantiated the system. Run a plug-in with the system instance. In the doAaxlAction(IProgressMonitor monitor, Element obj) try

final Element root = obj.getElementRoot(); SystemImplementation systemImplementation = (SystemImplementation)InstanceUtil.getComponentImplementation((SystemInstance)root, 0, null); for (Iterator iterator = systemImplementation.getAllSubcomponents().iterator(); iterator.hasNext();) { Subcomponent type = (Subcomponent) iterator.next(); System.out.println("checking existing Subcomponent: " + type.getName()); }

You will see that the newly add subcomponent doesn't show up. In fact, any change to the system implementation from now on would not show up. It remains as the first instantiated system implementation because the EcoreUtil.resolve will keep on changing it back whenever I select it from the instance model editor.

Not sure if other declaritive models would have the same issue.

Min Young

peterhfeiler commented 12 years ago

Thanks for doing such a thorough investigation. That should give us enough clues.

Peter

Sent from my iPad

On May 13, 2012, at 6:34, mnam reply@reply.github.com wrote:

Hi Peter,

I've found some surprising facts and believe this is bug in OSATE. My tool editing the model actually has nothing to do with it.

Only after doing the first instantiation, the system implementation is saved somewhere and is not being updated any more. All resolve would load this old system implementation from then on. After the first instantiation, making any changes to the top-level system implementation will not affect what is given by the EcoreUtil.resolve. When saving the system implementation that is used for the system instance, it looks like although it would update the Resource, it is not updating whatever object that EcoreUtil.resolve is using.

The instantiation works fine because it uses the editor to directly read in the SystemImplementation. During instantiation, it would save the system implementation inside the system instance as 'systemImplementation". HOWEVER, when we open the system instance file with the Instance Model Editor by double clicking from the AADL Navigator, it would call the SystemInstanceImpl.setSystemImplementation and change the saved systemImplementation into a proxy. Then when we select the first element from the tree in the editor, it would call the getSystemImplementation() which would identify that systemImplementation is a proxy and do a resolve and set the systemImplementation into whatever object that it uses.

I only found this after putting print statements into the set and getSystemImplementation methods. When this behavior combined with the previous non-update issue, what we get is the mis-match of the systeminstance being correct but its system implementation not being changed.

You can check this behavior by using the following steps:

Create a top-level system implementation with say one subcomponent. Instantiated the system. (Need to do it once) Then deleted the system instance file. add another subcomponent to the system implementation. Instantiated the system. Run a plug-in with the system instance. In the doAaxlAction(IProgressMonitor monitor, Element obj) try

final Element root = obj.getElementRoot(); SystemImplementation systemImplementation = (SystemImplementation)InstanceUtil.getComponentImplementation((SystemInstance)root, 0, null); for (Iterator iterator = systemImplementation.getAllSubcomponents().iterator(); iterator.hasNext();) { Subcomponent type = (Subcomponent) iterator.next(); System.out.println("checking existing Subcomponent: " + type.getName()); }

You will see that the newly add subcomponent doesn't show up. In fact, any change to the system implementation from now on would not show up. It remains as the first instantiated system implementation because the EcoreUtil.resolve will keep on changing it back whenever I select it from the instance model editor.

Not sure if other declaritive models would have the same issue.

Min Young

Reply to this email directly or view it on GitHub: https://github.com/osate/osate2-core/issues/42#issuecomment-5675364

mnam commented 12 years ago

Hi Peter,

Were you able to figure this problem out?. I think this is happening for any Type that goes through EcoreUtil.resolve. Example of what I am seeing is. I would instantiate a model. Then manually add a port to the component type. Instantiate it once more. Then when my code goes to the Feature of the port and for example try to get the containing classifier, it gives me null. Of course if I restart OSATE it will go away because I'll get the correct ComponentType.

The instantatiation works but any call to component types that enables the EcoreUtil.resolve would give back an old ComponentType that was saved during the first instatiation. This is not just happening for the system type. General tools that only access the instantiation file will never see any problem.

Thanks. Sincerely, Min Young

reteprelief commented 12 years ago

Hi Min Young,

I finally traced the problem to its root. It was a bug in OsateResourceutil. The method returning an empty resource did not do its job correctly. As a result the old resource was left in the resource set and a new one with the same file name was added in. The EcoreUtil.resolve method then found the old one instead of the new one. The fix is in the develop branch. Can you check it on your examples? It works for me with the example you gave in the most recent responses from you.

Thanks

Peter

mnam commented 12 years ago

Hi Peter,

I've been testing and trying to see a pattern. I believe some things have changed but this situation of getting a past system implementation still exist.

At first nothing seem different to me. But, since you said that it seemed to work with my example, I followed it blindly and it really looked like it was working. I have three test cases. First case is when it looks to be working correctly and I believe that you may have followed this procedure. 1.1 Instantiate model. 1.2 Delete Instantiation file. 1.3 Remove the subcomponent from the system implementation 1.4 Instantiate model once more 1.5 Check the subcomponents of the system implementation and it showed the one has the subcomponent removed.

Now this second procedure shows that it is not working. 2.1 Instantiate model. 2.2 Try running a plug-in on it and check the system implementation which eventually causes a resolve occur for the system implementation. 2.3 Delete Instantiation file. 2.4 Remove the subcomponent from the system implementation 2.5 Instantiate model once more 2.6 Check the subcomponents of the system implementation and it showed the OLD one with the deleted subcomponent still inside.

Also from this test case it also showed that it didn't work. 3.1 Leave a instantiation file. Restart OSATE to start without any instantiation step. 3.2 Try running a plug-in on it and check the system implementation which eventually causes a resolve occur for the system implementation. 3.3 Delete Instantiation file. 3.4 Remove the subcomponent from the system implementation 3.5 Instantiate model once more 3.6 Check the subcomponents of the system implementation and it showed the OLD one with the deleted subcomponent still inside.

From these cases, I think that the system implementation or any resource is no longer wrongfully stored during instantiation, which is maybe what was fixed, but it is still stored when it is resolved for the first time.

Hope you see the same phenomenon. I've checked that I got all the update files.

Thanks!!! Min Young

reteprelief commented 12 years ago

Hi Min Young,

can you do another test on your side from the develop branch? The issue was that I had to refresh the resource set that contains the instance models with the model changes in the editor. It turns out the editor uses its own resourceset and EcoreUtil.resolve was resolving in the resource set of the instance model..

Thanks Peter

mnam commented 12 years ago

Thanks Peter,

It Works!!! That must have been it.

Sincerely, Min Young

mnam commented 12 years ago

Hi Peter,

I have a new issue that is related to this Resource loading and I can't figure out why this is happening. Whenever I want to save changes, my tool would unparse the resource to save any changes to classifiers. Then it reinstantiates the system instance and reload the model. I instantiate using the following code which is the same in the InstanceHandler.

final InternalErrorReporter internalErrorLogger = new LogInternalErrorReporter(OsateCorePlugin .getDefault().getBundle());

final InstantiateModel instantiateModel = new InstantiateModel(new NullProgressMonitor(), new AnalysisErrorReporterManager(internalErrorLogger,new MarkerAnalysisErrorReporter.Factory( AadlConstants.INSTANTIATION_OBJECT_MARKER)));

URI instanceURI = OsateResourceUtil.getInstanceModelURI(oldsysteminstance.getSystemImplementation());

Resource aadlResource = OsateResourceUtil.getEmptyAaxl2Resource(instanceURI); OsateResourceUtil.refreshResourceSet(aadlResource.getResourceSet());

final SystemInstance newsysteminstance = instantiateModel.createSystemInstance(system.getSystemImplementation(), aadlResource);

Then, just like reading in the model for a plug-in, I would use newsysteminstance.

I have a print statement in the SystemInstanceImpl.getSystemImplementation() that tells me whether the systemImplementation is a proxy and whether its resource systemImplementation.eResource() is null when this function is called.

This is what I'm doing and is happening. It can be repeated. I build the OSATE which has no system instance file. I instantiate the system implementation. Run my tool and read in the model. Save a contained property in the system implementation. Unparse the system implementation in the tool. Instantiate the system implementation from the tool. Reload the system instance.

Now I'll see a lot of prints that tells me the status of the system instance. The systemimplementation's resource is not null in the begining but suddenly the system implementation's resource systemImplementation.eResource() starts to be null while it says that it is not a proxy. systemImplementation).eIsProxy() If I try to do a resolve when this happens, it still remains null. I close my tool and select the system instance from the instance file and it tells me its resource is null. Without deleting the system instance file, I close OSATE and restart it and then the resolve works and gives me the resource using the existing instance file. The time when the resource becomes null just happens randomly at different times so I believe my tool is not initiating it.

Now another case, also repeatable. If I newly open OSATE with a existing instance file. no matter how many times I reinstantiate and load the system instance through my tool, the resource never becomes null and my tool would work fine. Strange. Because it works fine in this case, I don't think that I'm using a old object from previous instantiations.

Is it suppose to be possible to have non proxy who's resource is null? Is there any way I could resovle this when it happens. Am I suppose to do something before instantiation? Did I miss something? Is this another lazy loading problem that changes the resource later and breaks the link?

Any Ideas to check or try would be helpful. I've tried all sorts of stuffs including resolving all the classifiers after reinstantiation but the resource is never initially null. Just suddenly randomly becomes null probably from some background operation?

Thanks. Min Young I

reteprelief commented 12 years ago

Hi Min Young,

Can you try to save the changed system implementation by calling save on the resource instead of unparsing? When you unparsed, the file is overwritten. The resource set that has the file with the system implementation loaded may as a result reload the resource.

At that time you may already have a reference to the system implementation in a variable, the one that got unloaded. Since the resource is reloaded the old system implementation does not belong to a resource anymore, thus will not return a resource.

Or are you talking about reretrieving the reference from the instance model and the returned object is not a proxy object, but a system implementation object and it does not have a resource?

Peter

-----Original Message----- From: mnam [mailto:reply@reply.github.com] Sent: Thursday, June 14, 2012 4:34 AM To: Peter Feiler Subject: Re: [osate2-core] OsateResourceUtil bug? (#42)