Eclipse Community Forums: EMF » ResourceImpl.unload final

Help

Home

Home » Modeling » EMF » ResourceImpl.unload final

Show: Today's Messages :: Show Polls :: Message Navigator

ResourceImpl.unload final [message #417380]

Fri, 07 March 2008 09:17

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Ed (and others),
Another question, is there a specific reason why the ResourceImpl.unload method is final?
For Teneo it can be good to know that a resource is being unloaded so I keep an isUnLoading flag
somewhere. The reason is that apparently the eNotify call in ResourceImpl.unload sometimes (with me)
results in a reload of the resource (which I want to prevent).
I would like to override the unload method to do that but I can't and maybe there is a specific
reason for not allowing this.

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: ResourceImpl.unload final [message #417383 is a reply to message #417380]

Fri, 07 March 2008 10:14

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------050406090806010808030103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Martin,

I didn't want folks to mess with the semantics of what happens during
save, load, and unload.

| *public final **void *unload()
{
*if *(isLoaded)
{
unloadingContents = *new *BasicEList.FastCompare<EObject>(getContents());
Notification notification = setLoaded(*false*);
*try*
{
doUnload();
}
*finally*
{
unloadingContents = *null*;
*if *(notification != *null*)
{
eNotify(notification);
}
setTimeStamp(URIConverter.NULL_TIME_STAMP);
}
}
}|

So do to additional interesting things as part of unload, the doUnload
hook is provided. Making this method final allowed me to add the
unloadingContents without fear that someone might bypass that code. The
resource is cleared as the first step of unloading, so when I changed
the getURIFragment return "/-1" for an object not contained by the
resource, I broke the unloading behavior and needed access to the
contents of the resource at the time unloading started. When the field
unloadingContents != null, you'll know the resource is in the process of
unloading. It seems a little dangerous for a resource implementations
to arbitrarily decide to stop producing loaded notifications, so I
hesitate to describe how you'd achieve that without fully understanding
why you'd need that...

Martin Taal wrote:
> Hi Ed (and others),
> Another question, is there a specific reason why the
> ResourceImpl.unload method is final?
> For Teneo it can be good to know that a resource is being unloaded so
> I keep an isUnLoading flag somewhere. The reason is that apparently
> the eNotify call in ResourceImpl.unload sometimes (with me) results in
> a reload of the resource (which I want to prevent).
> I would like to override the unload method to do that but I can't and
> maybe there is a specific reason for not allowing this.
>
>

--------------050406090806010808030103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin, 
 
I didn't want folks to mess with the semantics of what happens during
save, load, and unload. 
<blockquote>
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">


<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code>  public final void unload() 
  { 
    if (isLoaded) 
    { 
        unloadingContents = new BasicEList.FastCompare<EObject> (getContents()); 
        Notification notification = setLo aded (false); 
        try 
        { 
           doUnload(); 
        } 
        finally 
        { 
           unloadingContents = null; 
           if (notification !=  null) 
           { 
             eNotify(notification); 
           } 
           setTimeStamp(URIConverter.NULL_TIME_STAMP); 
        } 
    } 
  }</code>
</td>
 </tr>
</tbody>
</table>
</div>

</blockquote>
So do to additional interesting things as part of unload, the doUnload
hook is provided.  Making this method final allowed me to add the
unloadingContents without fear that someone might bypass that code. 
The resource is cleared as the first step of unloading, so when I
changed the getURIFragment return "/-1" for an object not contained by
the resource, I broke the unloading behavior and needed access to the
contents of the resource at the time unloading started.  When the field
unloadingContents != null, you'll know the resource is in the process
of unloading.  It seems a little dangerous for a resource
implementations to arbitrarily decide to stop producing loaded
notifications, so I hesitate to describe how you'd achieve that without
fully understanding why you'd need that... 
 
 
Martin Taal wrote:
<blockquote cite="mid:fqr188$cu$1@build.eclipse.org" type="cite">Hi Ed
(and others),
 
Another question, is there a specific reason why the
ResourceImpl.unload method is final?
 
For Teneo it can be good to know that a resource is being unloaded so I
keep an isUnLoading flag somewhere. The reason is that apparently the
eNotify call in ResourceImpl.unload sometimes (with me) results in a
reload of the resource (which I want to prevent).
 
I would like to override the unload method to do that but I can't and
maybe there is a specific reason for not allowing this.
 
 
 
</blockquote>
 
</body>
</html>

--------------050406090806010808030103--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: ResourceImpl.unload final [message #417385 is a reply to message #417383]

Fri, 07 March 2008 10:27

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Ed,
What I encounter is that the eNotify call in unload results in a reload of my resource. In the
current implementation of the unload method the unloadingContents is nullified before the call to
eNotify therefore the resource can't detect that it is unloading. Is there a reason to do the
nullify before the call to eNotify or maybe is this event (unload results in getContents on the same
resource so therefore a reload) an illegal state?

Here is part of the stacktrace:
at org.eclipse.emf.teneo.resource.StoreResource.addToContent(St oreResource.java:315)
at org.eclipse.emf.teneo.resource.StoreResource.load(StoreResou rce.java:300)
at org.eclipse.emf.teneo.resource.StoreResource.getContents(Sto reResource.java:429)
at org.eclipse.emf.ecore.change.util.ChangeRecorder.notifyChang ed(ChangeRecorder.java:264)
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:200)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(Reso urceImpl.java:1501)

gr. Martin

Ed Merks wrote:
> Martin,
>
> I didn't want folks to mess with the semantics of what happens during
> save, load, and unload.
>
> | *public final **void *unload()
> {
> *if *(isLoaded)
> {
> unloadingContents = *new *BasicEList.FastCompare<EObject>(getContents());
> Notification notification = setLoaded(*false*);
> *try*
> {
> doUnload();
> }
> *finally*
> {
> unloadingContents = *null*;
> *if *(notification != *null*)
> {
> eNotify(notification);
> }
> setTimeStamp(URIConverter.NULL_TIME_STAMP);
> }
> }
> }|
>
> So do to additional interesting things as part of unload, the doUnload
> hook is provided. Making this method final allowed me to add the
> unloadingContents without fear that someone might bypass that code. The
> resource is cleared as the first step of unloading, so when I changed
> the getURIFragment return "/-1" for an object not contained by the
> resource, I broke the unloading behavior and needed access to the
> contents of the resource at the time unloading started. When the field
> unloadingContents != null, you'll know the resource is in the process of
> unloading. It seems a little dangerous for a resource implementations
> to arbitrarily decide to stop producing loaded notifications, so I
> hesitate to describe how you'd achieve that without fully understanding
> why you'd need that...
>
>
> Martin Taal wrote:
>> Hi Ed (and others),
>> Another question, is there a specific reason why the
>> ResourceImpl.unload method is final?
>> For Teneo it can be good to know that a resource is being unloaded so
>> I keep an isUnLoading flag somewhere. The reason is that apparently
>> the eNotify call in ResourceImpl.unload sometimes (with me) results in
>> a reload of the resource (which I want to prevent).
>> I would like to override the unload method to do that but I can't and
>> maybe there is a specific reason for not allowing this.
>>
>>
>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: ResourceImpl.unload final [message #417387 is a reply to message #417385]

Fri, 07 March 2008 10:56

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Martin,

Sorry to answer questions with questions, but generally the framework
assumes that getContents will not alter the visible state of a
resource. In particular, it doesn't expect that a getContents call will
cause the resource to be demand loaded as a side effect. I.e.,
getContents on a resource for which isLoaded is false, should return an
empty collection and loading should only happen as a consequence of an
explicit call to load. I can understand that a lazy loading
implementation might well want to do some on-demand population, but
perhaps it's better to do that by keeping a different flag than isLoaded
for that purpose, because it isn't really the same thing I.e., you
might design your load method so that it actually does nothing except
set a flag indicating that lazy loading is required the next time
getContents is called; or probably better to keep such state within the
ContentsEList implementation, since a client could be holding on to the
list itself without ever having called getContents again.

Martin Taal wrote:
> Hi Ed,
> What I encounter is that the eNotify call in unload results in a
> reload of my resource. In the current implementation of the unload
> method the unloadingContents is nullified before the call to eNotify
> therefore the resource can't detect that it is unloading. Is there a
> reason to do the nullify before the call to eNotify or maybe is this
> event (unload results in getContents on the same resource so therefore
> a reload) an illegal state?
>
> Here is part of the stacktrace:
> at
> org.eclipse.emf.teneo.resource.StoreResource.addToContent(St oreResource.java:315)
>
> at
> org.eclipse.emf.teneo.resource.StoreResource.load(StoreResou rce.java:300)
> at
> org.eclipse.emf.teneo.resource.StoreResource.getContents(Sto reResource.java:429)
>
> at
> org.eclipse.emf.ecore.change.util.ChangeRecorder.notifyChang ed(ChangeRecorder.java:264)
>
> at
> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:200)
>
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(Reso urceImpl.java:1501)
>
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> I didn't want folks to mess with the semantics of what happens during
>> save, load, and unload.
>>
>> | *public final **void *unload()
>> {
>> *if *(isLoaded)
>> {
>> unloadingContents = *new
>> *BasicEList.FastCompare<EObject>(getContents());
>> Notification notification = setLoaded(*false*);
>> *try*
>> {
>> doUnload();
>> }
>> *finally*
>> {
>> unloadingContents = *null*;
>> *if *(notification != *null*)
>> {
>> eNotify(notification);
>> }
>> setTimeStamp(URIConverter.NULL_TIME_STAMP);
>> }
>> }
>> }|
>>
>> So do to additional interesting things as part of unload, the
>> doUnload hook is provided. Making this method final allowed me to
>> add the unloadingContents without fear that someone might bypass that
>> code. The resource is cleared as the first step of unloading, so
>> when I changed the getURIFragment return "/-1" for an object not
>> contained by the resource, I broke the unloading behavior and needed
>> access to the contents of the resource at the time unloading
>> started. When the field unloadingContents != null, you'll know the
>> resource is in the process of unloading. It seems a little dangerous
>> for a resource implementations to arbitrarily decide to stop
>> producing loaded notifications, so I hesitate to describe how you'd
>> achieve that without fully understanding why you'd need that...
>>
>>
>> Martin Taal wrote:
>>> Hi Ed (and others),
>>> Another question, is there a specific reason why the
>>> ResourceImpl.unload method is final?
>>> For Teneo it can be good to know that a resource is being unloaded
>>> so I keep an isUnLoading flag somewhere. The reason is that
>>> apparently the eNotify call in ResourceImpl.unload sometimes (with
>>> me) results in a reload of the resource (which I want to prevent).
>>> I would like to override the unload method to do that but I can't
>>> and maybe there is a specific reason for not allowing this.
>>>
>>>
>>
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: ResourceImpl.unload final [message #417388 is a reply to message #417387]

Fri, 07 March 2008 11:10

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Ed,
No problem, I am looking at the teneo gmf integration (I am encountering some issues there) and my
feel is that the teneo hibernate resources behave differently than the xml resources regarding load
behavior and notifications. This causes issues in combination with emf transactions as the resource
content gets changed outside of write/read transactions.

The behavior you describe (do not load in getContents, only do explicit load) is afaics no problem
as this is what users of EMF should expect anyway.

gr. Martin

Ed Merks wrote:
> Martin,
>
> Sorry to answer questions with questions, but generally the framework
> assumes that getContents will not alter the visible state of a
> resource. In particular, it doesn't expect that a getContents call will
> cause the resource to be demand loaded as a side effect. I.e.,
> getContents on a resource for which isLoaded is false, should return an
> empty collection and loading should only happen as a consequence of an
> explicit call to load. I can understand that a lazy loading
> implementation might well want to do some on-demand population, but
> perhaps it's better to do that by keeping a different flag than isLoaded
> for that purpose, because it isn't really the same thing I.e., you
> might design your load method so that it actually does nothing except
> set a flag indicating that lazy loading is required the next time
> getContents is called; or probably better to keep such state within the
> ContentsEList implementation, since a client could be holding on to the
> list itself without ever having called getContents again.
>
>
> Martin Taal wrote:
>> Hi Ed,
>> What I encounter is that the eNotify call in unload results in a
>> reload of my resource. In the current implementation of the unload
>> method the unloadingContents is nullified before the call to eNotify
>> therefore the resource can't detect that it is unloading. Is there a
>> reason to do the nullify before the call to eNotify or maybe is this
>> event (unload results in getContents on the same resource so therefore
>> a reload) an illegal state?
>>
>> Here is part of the stacktrace:
>> at
>> org.eclipse.emf.teneo.resource.StoreResource.addToContent(St oreResource.java:315)
>>
>> at
>> org.eclipse.emf.teneo.resource.StoreResource.load(StoreResou rce.java:300)
>> at
>> org.eclipse.emf.teneo.resource.StoreResource.getContents(Sto reResource.java:429)
>>
>> at
>> org.eclipse.emf.ecore.change.util.ChangeRecorder.notifyChang ed(ChangeRecorder.java:264)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:200)
>>
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(Reso urceImpl.java:1501)
>>
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> I didn't want folks to mess with the semantics of what happens during
>>> save, load, and unload.
>>>
>>> | *public final **void *unload()
>>> {
>>> *if *(isLoaded)
>>> {
>>> unloadingContents = *new
>>> *BasicEList.FastCompare<EObject>(getContents());
>>> Notification notification = setLoaded(*false*);
>>> *try*
>>> {
>>> doUnload();
>>> }
>>> *finally*
>>> {
>>> unloadingContents = *null*;
>>> *if *(notification != *null*)
>>> {
>>> eNotify(notification);
>>> }
>>> setTimeStamp(URIConverter.NULL_TIME_STAMP);
>>> }
>>> }
>>> }|
>>>
>>> So do to additional interesting things as part of unload, the
>>> doUnload hook is provided. Making this method final allowed me to
>>> add the unloadingContents without fear that someone might bypass that
>>> code. The resource is cleared as the first step of unloading, so
>>> when I changed the getURIFragment return "/-1" for an object not
>>> contained by the resource, I broke the unloading behavior and needed
>>> access to the contents of the resource at the time unloading
>>> started. When the field unloadingContents != null, you'll know the
>>> resource is in the process of unloading. It seems a little dangerous
>>> for a resource implementations to arbitrarily decide to stop
>>> producing loaded notifications, so I hesitate to describe how you'd
>>> achieve that without fully understanding why you'd need that...
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi Ed (and others),
>>>> Another question, is there a specific reason why the
>>>> ResourceImpl.unload method is final?
>>>> For Teneo it can be good to know that a resource is being unloaded
>>>> so I keep an isUnLoading flag somewhere. The reason is that
>>>> apparently the eNotify call in ResourceImpl.unload sometimes (with
>>>> me) results in a reload of the resource (which I want to prevent).
>>>> I would like to override the unload method to do that but I can't
>>>> and maybe there is a specific reason for not allowing this.
>>>>
>>>>
>>>
>>
>>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: ResourceImpl.unload final [message #417401 is a reply to message #417388]

Fri, 07 March 2008 21:40

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Ed,
I noticed that a save in my hibernate resource results in notifications being sent out. This happens
because hibernate sets information in the eobjects during a save (for example a generated id from
the db). Is there an easy way to disable all notifications for all eobjects in a resource?
Then I can use this during the save action.

gr. Martin

Martin Taal wrote:
> Hi Ed,
> No problem, I am looking at the teneo gmf integration (I am encountering
> some issues there) and my feel is that the teneo hibernate resources
> behave differently than the xml resources regarding load behavior and
> notifications. This causes issues in combination with emf transactions
> as the resource content gets changed outside of write/read transactions.
>
> The behavior you describe (do not load in getContents, only do explicit
> load) is afaics no problem as this is what users of EMF should expect
> anyway.
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> Sorry to answer questions with questions, but generally the framework
>> assumes that getContents will not alter the visible state of a
>> resource. In particular, it doesn't expect that a getContents call
>> will cause the resource to be demand loaded as a side effect. I.e.,
>> getContents on a resource for which isLoaded is false, should return
>> an empty collection and loading should only happen as a consequence of
>> an explicit call to load. I can understand that a lazy loading
>> implementation might well want to do some on-demand population, but
>> perhaps it's better to do that by keeping a different flag than
>> isLoaded for that purpose, because it isn't really the same thing
>> I.e., you might design your load method so that it actually does
>> nothing except set a flag indicating that lazy loading is required the
>> next time getContents is called; or probably better to keep such state
>> within the ContentsEList implementation, since a client could be
>> holding on to the list itself without ever having called getContents
>> again.
>>
>>
>> Martin Taal wrote:
>>> Hi Ed,
>>> What I encounter is that the eNotify call in unload results in a
>>> reload of my resource. In the current implementation of the unload
>>> method the unloadingContents is nullified before the call to eNotify
>>> therefore the resource can't detect that it is unloading. Is there a
>>> reason to do the nullify before the call to eNotify or maybe is this
>>> event (unload results in getContents on the same resource so
>>> therefore a reload) an illegal state?
>>>
>>> Here is part of the stacktrace:
>>> at
>>> org.eclipse.emf.teneo.resource.StoreResource.addToContent(St oreResource.java:315)
>>>
>>> at
>>> org.eclipse.emf.teneo.resource.StoreResource.load(StoreResou rce.java:300)
>>>
>>> at
>>> org.eclipse.emf.teneo.resource.StoreResource.getContents(Sto reResource.java:429)
>>>
>>> at
>>> org.eclipse.emf.ecore.change.util.ChangeRecorder.notifyChang ed(ChangeRecorder.java:264)
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:200)
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(Reso urceImpl.java:1501)
>>>
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>> Martin,
>>>>
>>>> I didn't want folks to mess with the semantics of what happens
>>>> during save, load, and unload.
>>>>
>>>> | *public final **void *unload()
>>>> {
>>>> *if *(isLoaded)
>>>> {
>>>> unloadingContents = *new
>>>> *BasicEList.FastCompare<EObject>(getContents());
>>>> Notification notification = setLoaded(*false*);
>>>> *try*
>>>> {
>>>> doUnload();
>>>> }
>>>> *finally*
>>>> {
>>>> unloadingContents = *null*;
>>>> *if *(notification != *null*)
>>>> {
>>>> eNotify(notification);
>>>> }
>>>> setTimeStamp(URIConverter.NULL_TIME_STAMP);
>>>> }
>>>> }
>>>> }|
>>>>
>>>> So do to additional interesting things as part of unload, the
>>>> doUnload hook is provided. Making this method final allowed me to
>>>> add the unloadingContents without fear that someone might bypass
>>>> that code. The resource is cleared as the first step of unloading,
>>>> so when I changed the getURIFragment return "/-1" for an object not
>>>> contained by the resource, I broke the unloading behavior and needed
>>>> access to the contents of the resource at the time unloading
>>>> started. When the field unloadingContents != null, you'll know the
>>>> resource is in the process of unloading. It seems a little
>>>> dangerous for a resource implementations to arbitrarily decide to
>>>> stop producing loaded notifications, so I hesitate to describe how
>>>> you'd achieve that without fully understanding why you'd need that...
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>> Hi Ed (and others),
>>>>> Another question, is there a specific reason why the
>>>>> ResourceImpl.unload method is final?
>>>>> For Teneo it can be good to know that a resource is being unloaded
>>>>> so I keep an isUnLoading flag somewhere. The reason is that
>>>>> apparently the eNotify call in ResourceImpl.unload sometimes (with
>>>>> me) results in a reload of the resource (which I want to prevent).
>>>>> I would like to override the unload method to do that but I can't
>>>>> and maybe there is a specific reason for not allowing this.
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: ResourceImpl.unload final [message #417402 is a reply to message #417401]

Fri, 07 March 2008 21:50

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Martin,

Here's how XMLHandler re-enables notification:

if (disableNotify)
{
for (Iterator<?> i =
EcoreUtil.getAllContents(xmlResource.getContents(), false); i.hasNext(); )
{
EObject eObject = (EObject)i.next();
eObject.eSetDeliver(true);
}
}

It would likely be better to surround the hibernate callbacks with code
to turn off notification, but likely you don't have that level of control.

Martin Taal wrote:
> Hi Ed,
> I noticed that a save in my hibernate resource results in
> notifications being sent out. This happens because hibernate sets
> information in the eobjects during a save (for example a generated id
> from the db). Is there an easy way to disable all notifications for
> all eobjects in a resource?
> Then I can use this during the save action.
>
> gr. Martin
>
> Martin Taal wrote:
>> Hi Ed,
>> No problem, I am looking at the teneo gmf integration (I am
>> encountering some issues there) and my feel is that the teneo
>> hibernate resources behave differently than the xml resources
>> regarding load behavior and notifications. This causes issues in
>> combination with emf transactions as the resource content gets
>> changed outside of write/read transactions.
>>
>> The behavior you describe (do not load in getContents, only do
>> explicit load) is afaics no problem as this is what users of EMF
>> should expect anyway.
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Sorry to answer questions with questions, but generally the
>>> framework assumes that getContents will not alter the visible state
>>> of a resource. In particular, it doesn't expect that a getContents
>>> call will cause the resource to be demand loaded as a side effect.
>>> I.e., getContents on a resource for which isLoaded is false, should
>>> return an empty collection and loading should only happen as a
>>> consequence of an explicit call to load. I can understand that a
>>> lazy loading implementation might well want to do some on-demand
>>> population, but perhaps it's better to do that by keeping a
>>> different flag than isLoaded for that purpose, because it isn't
>>> really the same thing I.e., you might design your load method so
>>> that it actually does nothing except set a flag indicating that lazy
>>> loading is required the next time getContents is called; or probably
>>> better to keep such state within the ContentsEList implementation,
>>> since a client could be holding on to the list itself without ever
>>> having called getContents again.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi Ed,
>>>> What I encounter is that the eNotify call in unload results in a
>>>> reload of my resource. In the current implementation of the unload
>>>> method the unloadingContents is nullified before the call to
>>>> eNotify therefore the resource can't detect that it is unloading.
>>>> Is there a reason to do the nullify before the call to eNotify or
>>>> maybe is this event (unload results in getContents on the same
>>>> resource so therefore a reload) an illegal state?
>>>>
>>>> Here is part of the stacktrace:
>>>> at
>>>> org.eclipse.emf.teneo.resource.StoreResource.addToContent(St oreResource.java:315)
>>>>
>>>> at
>>>> org.eclipse.emf.teneo.resource.StoreResource.load(StoreResou rce.java:300)
>>>>
>>>> at
>>>> org.eclipse.emf.teneo.resource.StoreResource.getContents(Sto reResource.java:429)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.change.util.ChangeRecorder.notifyChang ed(ChangeRecorder.java:264)
>>>>
>>>> at
>>>> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.n otifyChanged(TransactionChangeRecorder.java:200)
>>>>
>>>> at
>>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(Reso urceImpl.java:1501)
>>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Ed Merks wrote:
>>>>> Martin,
>>>>>
>>>>> I didn't want folks to mess with the semantics of what happens
>>>>> during save, load, and unload.
>>>>>
>>>>> | *public final **void *unload()
>>>>> {
>>>>> *if *(isLoaded)
>>>>> {
>>>>> unloadingContents = *new
>>>>> *BasicEList.FastCompare<EObject>(getContents());
>>>>> Notification notification = setLoaded(*false*);
>>>>> *try*
>>>>> {
>>>>> doUnload();
>>>>> }
>>>>> *finally*
>>>>> {
>>>>> unloadingContents = *null*;
>>>>> *if *(notification != *null*)
>>>>> {
>>>>> eNotify(notification);
>>>>> }
>>>>> setTimeStamp(URIConverter.NULL_TIME_STAMP);
>>>>> }
>>>>> }
>>>>> }|
>>>>>
>>>>> So do to additional interesting things as part of unload, the
>>>>> doUnload hook is provided. Making this method final allowed me to
>>>>> add the unloadingContents without fear that someone might bypass
>>>>> that code. The resource is cleared as the first step of
>>>>> unloading, so when I changed the getURIFragment return "/-1" for
>>>>> an object not contained by the resource, I broke the unloading
>>>>> behavior and needed access to the contents of the resource at the
>>>>> time unloading started. When the field unloadingContents != null,
>>>>> you'll know the resource is in the process of unloading. It seems
>>>>> a little dangerous for a resource implementations to arbitrarily
>>>>> decide to stop producing loaded notifications, so I hesitate to
>>>>> describe how you'd achieve that without fully understanding why
>>>>> you'd need that...
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Hi Ed (and others),
>>>>>> Another question, is there a specific reason why the
>>>>>> ResourceImpl.unload method is final?
>>>>>> For Teneo it can be good to know that a resource is being
>>>>>> unloaded so I keep an isUnLoading flag somewhere. The reason is
>>>>>> that apparently the eNotify call in ResourceImpl.unload sometimes
>>>>>> (with me) results in a reload of the resource (which I want to
>>>>>> prevent).
>>>>>> I would like to override the unload method to do that but I can't
>>>>>> and maybe there is a specific reason for not allowing this.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	Extend EAttribute
Next Topic:	How to reference a class in a subpackage

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 12:03:28 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter