[CDO] 4.2 and CDOElementProxy [message #968352] |
Fri, 02 November 2012 11:53 |
Christophe Bouhier Messages: 937 Registered: July 2009 |
Senior Member |
|
|
Hi,
When I process a Resource, I sometimes convert the content, with a little piece of code like this:
public static class CollectionForObjects<T> {
public List<T> collectionForObjects(List<EObject> objects) {
List<T> typedList = Lists.transform(objects,
new Function<EObject, T>() {
@SuppressWarnings("unchecked")
public T apply(EObject from) {
return (T) from;
}
});
return typedList;
}
}
This used to work fine in CDO 4.0, with 4.2 however I get this class cast exception below.
So a CDOElementProxy, can't be cast to an EObject, what could I do with it to get a collection of
target objects? What has changed? I mean, is there a bug describing this? +
Thanks/
java.lang.ClassCastException: org.eclipse.emf.cdo.internal.common.revision.CDOElementProxyImpl cannot be cast to org.eclipse.emf.ecore.EObject
at com.netxforge.netxstudio.common.model.ModelUtils$CollectionForObjects$1.apply(ModelUtils.java:1)
at com.google.common.collect.Lists$TransformingSequentialList$1.next(Lists.java:381)
at com.netxforge.netxstudio.common.model.ModelUtils.roleForUserWithName(ModelUtils.java:1959)
at com.netxforge.netxstudio.data.DataService.getCurrentRole(DataService.java:71)
at com.netxforge.netxstudio.ui.ApplicationWorkbenchAdvisor.resetWorkbenchIfRoleChanged(ApplicationWorkbenchAdvisor.java:69)
|
|
|
Re: [CDO] 4.2 and CDOElementProxy [message #968495 is a reply to message #968352] |
Fri, 02 November 2012 13:53 |
|
Am 02.11.2012 12:53, schrieb Christophe Bouhier:
> Hi,
> When I process a Resource, I sometimes convert the content, with a little piece of code like this:
> public static class CollectionForObjects<T> {
>
> public List<T> collectionForObjects(List<EObject> objects) {
>
> List<T> typedList = Lists.transform(objects,
> new Function<EObject, T>() {
>
> @SuppressWarnings("unchecked")
> public T apply(EObject from) {
> return (T) from;
> }
> });
>
> return typedList;
> }
>
> }
> This used to work fine in CDO 4.0, with 4.2 however I get this class cast exception below. So a CDOElementProxy, can't
> be cast to an EObject, what could I do with it to get a collection of target objects? What has changed? I mean, is
> there a bug describing this? +
Are you using partial collection loading explicietely, i.e., session.options().setCollectionLoadingPolicy(...) ?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Thanks/
>
> java.lang.ClassCastException: org.eclipse.emf.cdo.internal.common.revision.CDOElementProxyImpl cannot be cast to
> org.eclipse.emf.ecore.EObject
> at com.netxforge.netxstudio.common.model.ModelUtils$CollectionForObjects$1.apply(ModelUtils.java:1)
> at com.google.common.collect.Lists$TransformingSequentialList$1.next(Lists.java:381)
> at com.netxforge.netxstudio.common.model.ModelUtils.roleForUserWithName(ModelUtils.java:1959)
> at com.netxforge.netxstudio.data.DataService.getCurrentRole(DataService.java:71)
> at
> com.netxforge.netxstudio.ui.ApplicationWorkbenchAdvisor.resetWorkbenchIfRoleChanged(ApplicationWorkbenchAdvisor.java:69)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
|
|
|
|
Re: [CDO] 4.2 and CDOElementProxy [message #1014606 is a reply to message #1011477] |
Tue, 26 February 2013 06:25 |
|
Hi Andrew,
Sorry for the late reply. Busy time here.
I wonder if you or Christophe can reproduce this in our test bed, especially with our test models and without 3rd party
stuff such as Guava? A quick scan of our open bugzillas didn't bring up a related one. Please submit a new bugzilla and
replicate the infos given here. I'm currently fixing the CDOMergingConflictResolver for a customer, so please don't
expect that I work on this immediately.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 19.02.2013 17:01, schrieb Andrew Whelan:
> Hi,
> I'm wondering if this means that the downcasting of CDO Proxy objects to EObject is broken, period? I have recently
> experienced the exception that Christophe posted. Another manifestation of the issue might be in the following. If
> there is some proxying going on I just can't seem to make a copy of a CDOObject period now. The "from" object in the
> ECoreUtil.copy being performed below is a CDOObject. As I said I have had the result below and in another similar
> situation (using EcoreUtil.copy) I have had the exception Christophe posted rear its ugly head.
> java.lang.NullPointerException
> at org.eclipse.emf.ecore.util.DelegatingEcoreEList.resolveProxy(DelegatingEcoreEList.java:312)
> at org.eclipse.emf.ecore.util.DelegatingEcoreEList.resolve(DelegatingEcoreEList.java:273)
> at org.eclipse.emf.common.util.DelegatingEList.get(DelegatingEList.java:230)
> at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:703)
> at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:690)
> at org.eclipse.emf.ecore.util.EcoreUtil$Copier.copyReference(EcoreUtil.java:717)
> at org.eclipse.emf.ecore.util.EcoreUtil$Copier.copyReferences(EcoreUtil.java:641)
> at org.eclipse.emf.ecore.util.EcoreUtil.copy(EcoreUtil.java:356)
> at com.src.ewir.nighthawk.cdointerface.handlers.LoadFromDatabaseHandler.openEditor(LoadFromDatabaseHandler.java:279)
> at com.src.ewir.nighthawk.cdointerface.handlers.LoadFromDatabaseHandler.execute(LoadFromDatabaseHandler.java:139)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
> at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241)
> at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:829)
> at org.eclipse.ui.menus.CommandContributionItem.access$19(CommandContributionItem.java:815)
> at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:805)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
> at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at com.src.ewir.nighthawk.platform.ui.Application.start(Application.java:20)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
Re: [CDO] 4.2 and CDOElementProxy [message #1014723 is a reply to message #1014720] |
Tue, 26 February 2013 10:48 |
|
Am 26.02.2013 11:44, schrieb Christophe Bouhier:
> On 26-02-13 10:42, Eike Stepper wrote:
>> Am 26.02.2013 09:52, schrieb Christophe Bouhier:
>>> On 26-02-13 07:25, Eike Stepper wrote:
>>>> A quick scan of our open bugzillas
>>>
>>> Removing this line of code solved the issue for me:
>>>
>>> cdoSession.options().setCollectionLoadingPolicy(
>>> CDOUtil.createCollectionLoadingPolicy(0, 300));
>> Oh boy! Let me cite your second post in this thread: "No I am not
>> explicitly setting a collection loading policy."
>>
> I think I corrected that statement in the thread :P
Okay, okay. I apologize ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> ********
>
> Oh.... bummer. My initial search didn't reveal this line of code:
>
> cdoSession.options().setCollectionLoadingPolicy(
> CDOUtil.createCollectionLoadingPolicy(0, 300));
>
>
> So, yes I do set a loading policy.
> / Christophe
>
>
>>>
>>>
>>> What is wrong with this bug BTW? Why create another one?
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=394076
>> Probably nothing. I just scanned for "proxy" :P
>>
> Ok, working on a test case without Guava.
>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.04315 seconds