| [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731128] |
Tue, 03 May 2016 04:31  |
 David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi,
I am setting up a new linux laptop to develop my CDO project on. It is based on Kepler SR2 and I updated CDO to 4.3.0 from here - http://download.eclipse.org/modeling/emf/cdo/updates/releases/4.3/
I start with running my CDO Server with an empty database. Using the CDO Explorer view I add my ecore file with "Package Registry... " Then I open a Transaction and create a new resource "resource1". Then I open in the CDO Editor and add a new model element. Once I Ctrl-S it crashed the CDOServer running.
Exception in thread "net4j-Thread-1" java.lang.NoClassDefFoundError: org/eclipse/core/resources/ResourcesPlugin
at org.eclipse.emf.ecore.plugin.EcorePlugin.getWorkspaceRoot(EcorePlugin.java:1081)
at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.<clinit>(ExtensibleURIConverterImpl.java:393)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getURIConverter(ResourceSetImpl.java:499)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:369)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:220)
at org.eclipse.emf.cdo.server.internal.db.MetaDataManager.getMetaInstance(MetaDataManager.java:113)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.getObjectType(ObjectTypeTable.java:90)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTypeMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingStrategy.readObjectType(HorizontalMappingStrategy.java:194)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStoreAccessor.java:205)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStoreAccessor.java:222)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevision(DBStoreAccessor.java:242)
at org.eclipse.emf.cdo.internal.server.Repository.loadRevisions(Repository.java:495)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:387)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:292)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:275)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute(RevisionInfo.java:140)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevisionsIndication.responding(LoadRevisionsIndication.java:169)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:134)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:98)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:298)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:67)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: org.eclipse.core.resources.ResourcesPlugin cannot be found by org.eclipse.emf.ecore_2.9.1.v20130827-0309
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 29 more
The org.eclipse.core.resources_3.8.101.v20130717-0806.jar plugin that contains this class is present and correct.
I attached the h2 db the repo at the point of failure. The user is "cdo" and pwd is "cdo34er", repo is "repo1" and the resource is "resource1"
Ideas?
[Updated on: Tue, 03 May 2016 04:44] Report message to a moderator |
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731131 is a reply to message #1731128] |
Tue, 03 May 2016 05:45  |
|
Hi David,
At this point CDO 4.3 is not maintained anymore. But generally it's not a good idea to use dynamic Ecore models as
packages in a CDO server. And assuming that the ResourcesPlugin does not make much sense on the server, a
platform:resource/ URI makes it even worse.
Can't you generate code from your Ecore model and commit that to your repo?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 03.05.2016 um 06:32 schrieb David Wynter:
> Hi,
>
> I am setting up a new linux laptop to develop my CDO project on. It is based on Kepler SR2 and I updated CDO to 4.3.0
> from here - http://download.eclipse.org/modeling/emf/cdo/updates/releases/4.3/
>
> I start with running my CDO Server with an empty database. Using the CDO Explorer view I add my ecore file with
> "Package Registry... " Then I open a Transaction and create a new resource "resource1". Then I open in the CDO Editor
> and add a new model element. Once I Ctrl-S it crashed the CDOServer running.
> Exception in thread "net4j-Thread-1" java.lang.NoClassDefFoundError: org/eclipse/core/resources/ResourcesPlugin
> at org.eclipse.emf.ecore.plugin.EcorePlugin.getWorkspaceRoot(EcorePlugin.java:1081)
> at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.<clinit>(ExtensibleURIConverterImpl.java:393)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getURIConverter(ResourceSetImpl.java:499)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:369)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:220)
> at org.eclipse.emf.cdo.server.internal.db.MetaDataManager.getMetaInstance(MetaDataManager.java:113)
> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.getObjectType(ObjectTypeTable.java:90)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTypeMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingStrategy.readObjectType(HorizontalMappingStrategy.java:194)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStoreAccessor.java:205)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStoreAccessor.java:222)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevision(DBStoreAccessor.java:242)
> at org.eclipse.emf.cdo.internal.server.Repository.loadRevisions(Repository.java:495)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:387)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:292)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:275)
> at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute(RevisionInfo.java:140)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevisionsIndication.responding(LoadRevisionsIndication.java:169)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:134)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:98)
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:298)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:67)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: org.eclipse.core.resources.ResourcesPlugin cannot be found by
> org.eclipse.emf.ecore_2.9.1.v20130827-0309
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
> at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 29 more
>
>
> The org.eclipse.core.resources_3.8.101.v20130717-0806.jar plugin that contains this class is present and correct.
>
> Ideas?
>
>
|
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731194 is a reply to message #1731131] |
Tue, 03 May 2016 12:31 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I am stuck with 4.3 for a while because moving a large RCP 3 app to e4 is too big an undertaking currently.
Out of interest I tried to add a model element from the legacy modle included in the registry, ejb. I got the same exception, thus it is nothing to do with my model.
I must misunderstand something. I have a genmodel ready for CDO, but I describe the preparation of the database above, which has nothing to do with the generated code. When I use CDO Explorer view to open a session I cannot see my model as associated with the empty db. So I use Package Registry... to attached it, it shows as state == new, type = dynamic and original = dynamic. The I open a Transaction on that session, then I create a new resource, then I open that resource in the CDO editor then I add a model element, then I save and it crashes. How are you supposed to prepare a empty database ready to use with your client? None of the tutorials I could find seem to describe how you prepare a empty database ready for your model?
[Updated on: Tue, 03 May 2016 23:42] Report message to a moderator |
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731270 is a reply to message #1731194] |
Wed, 04 May 2016 05:27 |
|
Am 03.05.2016 um 14:31 schrieb David Wynter:
> Hi Eike,
>
> I am stuck with 4.3 for a while because moving a large RCP 3 app to e4 is too big an undertaking currently.
CDO does not depend on e4, nor does it depend on any strict version of the Eclipse Platform. We only test against the
Eclipse version that's displayed next to a CDO download, but you should be able to run against a different version, too.
> I must misunderstand something. I have a genmodel ready for CDO, but I describe the preparation of the database above,
> which has nothing to do with the generated code. When I use CDO Explorer view to open a session I cannot see my model
> as associated with the empty db. So I use Package Registry... to attached it, it shows as state == new, type = dynamic
> and original = dynamic.
Can you be more specific w.r.t. the exact steps you take to register your package? If it results in a "dynamic" package,
you've probably done something wrong.
> The I open a Transaction on that session, then I create a new resource, then I open that resource in the CDO editor
> then I add a model element, then I save and it crashes. How are you supposed to prepare a empty database ready to use
> with your client?
Your generated model/package plugin should be deployed and activated in your client, ready to be used with CDO. Is that
not the case?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731479 is a reply to message #1731429] |
Fri, 06 May 2016 00:34 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Soon I will migrate onto the big issue for us. We have hundreds of hours of design work in CDO repos that corrupted. I'd really like to recover these. I was advised by another CDO user to always use the <property name="ensureReferentialIntegrity" value="true"/> setting as it prevented some corruptions.
They give errors such as:
Unhandled event loop exception
java.lang.IllegalStateException: Invalid synthetic type: -79
Which column in which table in the DBStore will I find these synthetic types defined? Is there anything I can do about it?
This is the method I am using to make the call that causes the exception:
/**
* Finds the resource map in the eCore resource.
*
* @return found resource map or null.
*/
private ResourceMap getResourceMap() {
ResourceMap resourceMap = null;
if (this.eResourceService.getEResource() != null) {
resourceMap = (ResourceMap) CollectionUtils.find(this.eResourceService.getEResource().getContents(),
new InstanceofPredicate(ResourceMap.class));
}
return resourceMap;
}
Here is the call stack:
Caused by: java.lang.IllegalStateException: Invalid synthetic type: -79
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:317)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:326)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:294)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:166)
at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:142)
at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:1)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequest.confirming(CDOClientRequest.java:97)
at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedInput(RequestWithConfirmation.java:125)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:369)
at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:105)
at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:53)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:275)
at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:466)
at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:89)
at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:75)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:557)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:590)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.loadRevisions(CDOClientProtocol.java:202)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:431)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:309)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:298)
at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertToEMF(CDOStoreImpl.java:650)
at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.get(CDOStoreImpl.java:170)
at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateGet(EStoreEObjectImpl.java:241)
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.apache.commons.collections.CollectionUtils.find(CollectionUtils.java:369)
at com.yambina.edm.commons.platform.internalservices.ResourceAssociationService.getResourceMap(ResourceAssociationService.java:396) [Updated on: Fri, 06 May 2016 00:40] Report message to a moderator |
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731490 is a reply to message #1731479] |
Fri, 06 May 2016 05:01 |
|
Am 06.05.2016 um 02:34 schrieb David Wynter:
> Hi Eike,
>
> Soon I will migrate onto the big issue for us. We have hundreds of hours of design work in CDO repos that corrupted.
> I'd really like to recover these. I was advised by another CDO user to always use the <property
> name="ensureReferentialIntegrity" value="true"/> setting as it prevented some corruptions.
Corruption is a hard word. Many applications happily avoid the cost of optional referential integrity checks during each
commit and instead prefer to handle stale references when they occur during read access.
> They give errors such as:
> Unhandled event loop exception
> java.lang.IllegalStateException: Invalid synthetic type: -79
Is there no stack trace?
>
> Which column in which table in the DBStore will I find these synthetic types defined? Is there anything I can do about
> it?
This is not related to the DB, but rather to identifying the internal type of a synthetic revision, i.e., a subclass of
org.eclipse.emf.cdo.spi.common.revision.SyntheticCDORevision. The exception indicates that there's either a protocol
version mismatch between your client and server, or a bug in the CDO protocol.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1766499 is a reply to message #1731131] |
Thu, 22 June 2017 09:20 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I was confused by something you said. As far as I know we do not use dynamic models. We generate code for the ecore file and use those generated classes. Was there something in the stack trace I posted that makes you think we use dynamic models?
On the point you made about a mismatch between the client and server protocol version.We use a targetplatform to define the version of CDO and Net4j so they are consistent across client and server. Does that mean we have a bug in the CDO protocol?
[Updated on: Thu, 22 June 2017 09:24] Report message to a moderator |
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1766560 is a reply to message #1766499] |
Fri, 23 June 2017 05:18 |
|
David Wynter wrote on Thu, 22 June 2017 11:20Hi Eike,
I was confused by something you said. As far as I know we do not use dynamic models. We generate code for the ecore file and use those generated classes. Was there something in the stack trace I posted that makes you think we use dynamic models?
I think you mentioned that the UI showed the package as "type = dynamic and original = dynamic".
David Wynter wrote on Thu, 22 June 2017 11:20On the point you made about a mismatch between the client and server protocol version.We use a targetplatform to define the version of CDO and Net4j so they are consistent across client and server. Does that mean we have a bug in the CDO protocol?
It could mean that. But if so, it must be in a very rarely used "area". For example related to a specific datatype or even a specific value of that type. It's all guessing until I can reproduce the problem. Can you provide an executable test case?
|
|
|
Powered by
FUDForum. Page generated in 0.02166 seconds
Search
Help
Register
Login
Home
