RE: [gmf-dev] [GMF - API CHANGE] Bugzilla 115700: DemuxingMListener noti

[Chris McGee <cbmcgee@xxxxxxxxxx>]

Hi Alex,

Could you post this inquiry to the GMF
newsgroup? I'll answer this question as best as I can in that forum.

Thanks,
Chris McGee
_________________________________
Chris McGee, BCS
Software Developer
Rational Software, IBM Software Group
770 Palladium Drive, Ottawa, ON, Canada 
tel: (613) 591-2918

"Alexander Shatalin" <Alexander.Shatalin@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx

30/11/2005 10:12 AM

Please respond to
"GMF Project developer discussions."

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject	RE: [gmf-dev] [GMF - API CHANGE] Bugzilla 115700: DemuxingMListener        notifies clients that resource is loaded even when the load        actually failed

Hi, Chris!
    I
have a question concerning new way to work with resources: Should I surround
ResourceUtil.loadResource() with try-catch block or can I just ask resource
for an errors? If you suppose that an exception could be thrown from the
.loadResource() code, why don't declare this exception explicitly in a
method signature?

______________
Alex Shatalin

 

---

From: gmf-dev-bounces@xxxxxxxxxxx
[mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris McGee
Sent: Saturday, November 26, 2005 1:40 AM
To: gmf-dev@xxxxxxxxxxx
Subject: [gmf-dev] [GMF - API CHANGE] Bugzilla 115700: DemuxingMListener
notifies clients that resource is loaded even when the load actually failed


Description:
In the past, clients have come to expect that if they call ResourceUtil.load()
or MEditingDomain.loadResource() the resource would be automatically unloaded
if there were errors during the load. Also, client MListeners did not expect
to receive any events during this atomic operation. 

There are drawbacks to this approach: 
1) If the client calls aResource.load() directly, then there is no automatic
unloading of the resource. It is the same if a client causes a proxy to
resolve. 

2) The exception that is provided on the ResourceUtil.load() or MEditingDomain.loadResource()
is only one of many possible exceptions that were produced during the load.
EMF chooses one of the exceptions to be actually thrown back to the MSL.
Sometimes this exception by itself is not sufficient to discover the root
of the problem. The other exceptions are available in the resource object's
getErrors() method. When a resource is unloaded then these errors are cleared
out. If the resource is automatically unloaded then the client could have
difficulty tracking down the true problem with the model file. 

As part of the defect fix, the old behaviour has been re-instated for all
MListeners in GMF M4.

Clients need to do the following to migrate their code before they adopt
GMF M5: 
1) All MListeners that will fail if they are given a resource with no contents
should check the resource's errors list first before continuing: 

public void handleResourceLoadedEvent(Notification notification, Resource
resource) { 
        if (!resource.getErrors().isEmpty()) { 
                return; 
        } 

        // proceed with listener actions 
} 

public void onEvent(List events) { 
        // Extract a resource loaded notification from
the list of events and the notifier resource for the event 
        
        if (!resource.getErrors().isEmpty()) { 
                return; 
        } 

        // proceed as normal 
} 

2) Callers to ResourceUtil.load(String path, ...) or MEditingDomain.loadResource(String
path,...) should change their code to something like the following: 

Resource res = anEditingDomain.findResource(path, ...); 
if (res == null) { 
        res = anEditingDomain.createResource(path,
...); 
} 

if (!res.isLoaded()) { 
        try { 
                anEditingDomain.loadResource(res);
        } catch (Exception e) { 
                res.getErrors();
// Examine the errors, maybe log them somehow or even show them to the
user? 
                res.unload(); //
We don't need the errors anymore, unload the resource to clean up. 
        } 
} 

3) Callers to ResourceUtil.unload(...) or MEdtingDomain.unload(...) should
call aResource.unload() instead. 


New API Availability: 
This afternoon in the GMF repository as part of M4.

Old API Removal: 
Beginning of M5 unless clients request more time.

Tracking:                  
      
Bugzilla 115700

Clients Taken Care of:         
The runtime EMF core plugin of GMF only.

Other Clients' Action: 
Perform the migration mentioned above as soon as the client adopts the
M4 driver and before they adopt M5.

_________________________________
Chris McGee, BCS
Software Developer
Rational Software, IBM Software Group
770 Palladium Drive, Ottawa, ON, Canada 
tel: (613) 591-2918_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev