Eclipse Community Forums: EMF » [CDO] CDOStaleReferencePolicy & EMap

Help

Home

Home » Modeling » EMF » [CDO] CDOStaleReferencePolicy & EMap

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

[CDO] CDOStaleReferencePolicy & EMap [message #1856049]

Thu, 17 November 2022 05:45

Alain Picard

Messages: 266
Registered: July 2009

Senior Member

I am getting a ClassCastException:

java.lang.Class Cast Exception: class org.eclipse.emf.ecore.util.Basic Internal EList cannot be cast to class org.eclipse.emf.common.util.EMap (org.eclipse.emf.ecore.util.Basic Internal EList is in unnamed module of loader org.eclipse.osgi.internal.loader.Equinox Class Loader @644dfab9; org.eclipse.emf.common.util.EMap is in unnamed module of loader org.eclipse.osgi.internal.loader.Equinox Class Loader @7ef46d85)

        at com.sun.proxy.$Proxy154.getExternalIds(Unknown Source)
        at com.castortech.iris.ba.security.provider.access.ExternalElementAccessControllerImpl.isExternalElement(ExternalElementAccessControllerImpl.java:248)

Looking at CDOStaleReferencePolicy (ours and current, no real change), it appears that a isMany feature will be handled as a basicEList and never as an eMap.

Am I missing something here?

Cheers,
Alain

Report message to a moderator

Re: [CDO] CDOStaleReferencePolicy & EMap [message #1856057 is a reply to message #1856049]

Thu, 17 November 2022 17:01

Eike Stepper

Messages: 6688
Registered: July 2009

Senior Member

I assume that you're talking about CDOStaleReferencePolicy.PROXY and I don't think that are missing anything here. The whole purpose of this policy is to delay the problematic effect of stale references (i.e., references to objects that don't exist anymore) from the time of accessing the referencing object to the time of accessing the referenced object. I think one can not expect that a proxy object that is made up of nothing but the type information to always behave like the former real object. We've tried to make the proxy as tolerant as possible, but I'm sure that we've missed a few opportunities and I'm also sure that there are cases that simply can't be handled correctly and satisfiably.

In your specific case it appears to me that the following block of code, insterted right before the if (List.class.isAssignableFrom(returnType)) block, could help.:

  if (EMap.class.isAssignableFrom(returnType))
  {
    return new BasicEMap<>();
  }

Can you confirm this with your implementation of CDOStaleReferencePolicy.DynamicProxy?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] CDOStaleReferencePolicy & EMap [message #1856093 is a reply to message #1856057]

Mon, 21 November 2022 09:58

Alain Picard

Messages: 266
Registered: July 2009

Senior Member

Eike,

I added the block that you suggested and also to be sure:

            if (featureParam.isMany())
            {
              if (type.getInstanceClassName() == "java.util.Map$Entry") //$NON-NLS-1$
              {
                return new BasicEMap<Object, Object>();
              }

              return new BasicInternalEList<Object>(Object.class);
            }

As you said, stale references are meant to handle a narrow use case, so reproduction is not that easy to come by.

But in that vein, we've had for many years some scattered code to look for stale references, but that doesn't seem to be the right approach, as its like a game of whack a mole. Been looking at finding a more generic solution to filter those out, maybe as part of our own base EObject eGet, but I don't seem to have found the right solution to handle many references without forcing a full load from the iterator or else I feel that we might go to deep to address this. Your thoughts?

Cheers,
Alain

Report message to a moderator