Eclipse Community Forums: EMF » Dangling EObjects (are in NO resource) during serialization

Help

Home

Home » Modeling » EMF » Dangling EObjects (are in NO resource) during serialization

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

Dangling EObjects (are in NO resource) during serialization [message #424476]

Mon, 27 October 2008 22:38

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

Hi,

During serialization, if an EObject (ObjA) has a reference to another
EObject (ObjB) and ObjB is not in any resource, then the default
XMLSaveImpl/XMLHelperImpl tries to treat ObjB as an object within the
same resource as ObjA. This actually creates an invalid reference.
Usually it creates just "/", and so it returns the first root object in
the resource, which is not the correct one, and probably not even of a
valid type for the feature. Then the when trying to then later read this
back in an InvalidValueException is thrown. Which can be a pain.

Shouldn't it instead be treated as a DanglingHRef so that we can use the
appropriate OPTIONS flag to handle this during serialization, just like
any other dangling reference?

By the way the reason it is not in any resource is that ObjB was simply
removed from the resource. There are times where it is not easy to catch
all the references to this object because they are one-way and there is
no back pointer to ObjA to find it. So it is easier to let the Options
handle it.

--
Thanks,
Rich Kulp

Report message to a moderator

Re: Dangling EObjects (are in NO resource) during serialization [message #424477 is a reply to message #424476]

Mon, 27 October 2008 22:44

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

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

Rich,

Comments below.

Rich Kulp wrote:
> Hi,
>
> During serialization, if an EObject (ObjA) has a reference to another
> EObject (ObjB) and ObjB is not in any resource, then the default
> XMLSaveImpl/XMLHelperImpl tries to treat ObjB as an object within the
> same resource as ObjA. This actually creates an invalid reference.
> Usually it creates just "/", and so it returns the first root object
> in the resource, which is not the correct one, and probably not even
> of a valid type for the feature. Then the when trying to then later
> read this back in an InvalidValueException is thrown. Which can be a
> pain.
>
> Shouldn't it instead be treated as a DanglingHRef so that we can use
> the appropriate OPTIONS flag to handle this during serialization, just
> like any other dangling reference?
It sounds like related to ResourceImpl producing /-1 rather than /

public String getURIFragment(EObject eObject)
{
String id = EcoreUtil.getID(eObject);
if (id != null)
{
return id;
}
else
{
InternalEObject internalEObject = (InternalEObject)eObject;
if (internalEObject.eDirectResource() == this ||
unloadingContents != null &&
unloadingContents.contains(internalEObject))
{
return "/" + getURIFragmentRootSegment(eObject);
}
else
{
List<String> uriFragmentPath = new ArrayList<String>();
boolean isContained = false;
for (InternalEObject container =
internalEObject.eInternalContainer(); container != null; container =
internalEObject.eInternalContainer())
{

uriFragmentPath.add(container.eURIFragmentSegment(internalEO bject.eContainingFeature(),
internalEObject));
internalEObject = container;
if (container.eDirectResource() == this ||
unloadingContents != null && unloadingContents.contains(container))
{
isContained = true;
break;
}
}

* if (!isContained)
{
return "/-1";
}*

Which is then handled as a dangling reference:

protected String getURIFragment(Resource containingResource,
EObject object)
{
if (roots != null && containingResource == resource &&
!EcoreUtil.isAncestor(roots, object))
{
URI uriResult = handleDanglingHREF(object);
return uriResult == null || !uriResult.hasFragment() ? null :
uriResult.fragment();
}
else
{
String result = containingResource.getURIFragment(object);
if (result.length() > 0 && result.charAt(0) != '/')
{
String query = getURIFragmentQuery(containingResource, object);
if (query != null)
{
result += "?" + query + "?";
}
}
*else if ("/-1".equals(result))*
{
if (object.eResource() != containingResource)
{
URI uriResult = handleDanglingHREF(object);
return uriResult == null || !uriResult.hasFragment() ?
null : uriResult.fragment();
}
}

>
> By the way the reason it is not in any resource is that ObjB was
> simply removed from the resource. There are times where it is not easy
> to catch all the references to this object because they are one-way
> and there is no back pointer to ObjA to find it. So it is easier to
> let the Options handle it.
Perhaps specialized ResourceImpls are part of the equation. I recall
this changing a few years ago...

--------------040200040708040909030604
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">
Rich, 
 
Comments below. 
 
Rich Kulp wrote:
<blockquote cite="mid:ge5fsa$adg$1@build.eclipse.org" type="cite">Hi,
 
 
During serialization, if an EObject (ObjA) has a reference to another
EObject (ObjB) and ObjB is not in any resource, then the default
XMLSaveImpl/XMLHelperImpl tries to treat ObjB as an object within the
same resource as ObjA. This actually creates an invalid reference.
Usually it creates just "/", and so it returns the first root object in
the resource, which is not the correct one, and probably not even of a
valid type for the feature. Then the when trying to then later read
this back in an InvalidValueException is thrown. Which can be a pain.
 
 
Shouldn't it instead be treated as a DanglingHRef so that we can use
the appropriate OPTIONS flag to handle this during serialization, just
like any other dangling reference?
 
</blockquote>
It sounds like related to ResourceImpl producing /-1 rather than / 
<blockquote>  public String getURIFragment(EObject eObject) 
  { 
    String id = EcoreUtil.getID(eObject); 
    if (id != null) 
    { 
      return id; 
    } 
    else 
    { 
      InternalEObject internalEObject = (InternalEObject)eObject; 
      if (internalEObject.eDirectResource() == this ||
unloadingContents != null &&
unloadingContents.contains(internalEObject)) 
      { 
         return "/" + getURIFragmentRootSegment(eObject); 
      } 
      else 
      { 
         List<String> uriFragmentPath = new
ArrayList<String>(); 
         boolean isContained = false; 
         for (InternalEObject container =
internalEObject.eInternalContainer(); container != null; container =
internalEObject.eInternalContainer()) 
         { 
          
uriFragmentPath.add(container.eURIFragmentSegment(internalEO bject.eContainingFeature(),
internalEObject)); 
           internalEObject = container; 
           if (container.eDirectResource() == this || unloadingContents
!= null && unloadingContents.contains(container)) 
           { 
             isContained = true; 
             break; 
           } 
         } 
 
          if (!isContained) 
         { 
           return "/-1"; 
         } 
</blockquote>
 
Which is then handled as a dangling reference: 
<blockquote>  protected String getURIFragment(Resource
containingResource, EObject object) 
  { 
    if (roots != null && containingResource ==
resource && !EcoreUtil.isAncestor(roots, object)) 
    { 
      URI uriResult = handleDanglingHREF(object); 
      return uriResult == null || !uriResult.hasFragment() ?
null : uriResult.fragment(); 
    } 
    else 
    { 
      String result =
containingResource.getURIFragment(object); 
      if (result.length() > 0 && result.charAt(0)
!= '/') 
      { 
          String query = getURIFragmentQuery(containingResource,
object); 
          if (query != null) 
          { 
            result += "?" + query + "?"; 
          } 
      } 
      else if ("/-1".equals(result)) 
      { 
          if (object.eResource() != containingResource) 
          { 
            URI uriResult = handleDanglingHREF(object); 
            return uriResult == null || !uriResult.hasFragment()
? null : uriResult.fragment(); 
          } 
      } 
</blockquote>
<blockquote cite="mid:ge5fsa$adg$1@build.eclipse.org" type="cite"> 
By the way the reason it is not in any resource is that ObjB was simply
removed from the resource. There are times where it is not easy to
catch all the references to this object because they are one-way and
there is no back pointer to ObjA to find it. So it is easier to let the
Options handle it.
 
</blockquote>
Perhaps specialized ResourceImpls are part of the equation.  I recall
this changing a few years ago... 
</body>
</html>

--------------040200040708040909030604--

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

Report message to a moderator

Re: Dangling EObjects (are in NO resource) during serialization [message #424491 is a reply to message #424477]

Tue, 28 October 2008 14:06

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

Hi Ed,

Was this fixed after 2.2.1? I'm still at 2.2.1 because I need to stay at
this level due to Websphere 6.1. As of 2.2.1 it can produce either "/"
or "/-1" and both are treated as OK and not as a dangling.

--
Thanks,
Rich Kulp

Report message to a moderator

Re: Dangling EObjects (are in NO resource) during serialization [message #424492 is a reply to message #424491]

Tue, 28 October 2008 14:25

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

Rich,

It's fixed by https://bugs.eclipse.org/bugs/show_bug.cgi?id=153577, but
that's in 2.3, not 2.2.x

Rich Kulp wrote:
> Hi Ed,
>
> Was this fixed after 2.2.1? I'm still at 2.2.1 because I need to stay
> at this level due to Websphere 6.1. As of 2.2.1 it can produce either
> "/" or "/-1" and both are treated as OK and not as a dangling.
>

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

Report message to a moderator

Previous Topic:	Non-uniqueness property not propagated to multivalued reference of type EObject
Next Topic:	[CDO] A locked CDOView has objects removed from its model

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 16:00:57 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter