| [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731128] |
Tue, 03 May 2016 00:31  |
Eclipse User |
|
|
|
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 00:44] by Moderator |
|
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731194 is a reply to message #1731131] |
Tue, 03 May 2016 08:31  |
| Eclipse User |
|
|
|
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 19:42] by Moderator |
|
|
| Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731270 is a reply to message #1731194] |
Wed, 04 May 2016 01:27 |
| Eclipse User |
|
|
|
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 #1766560 is a reply to message #1766499] |
Fri, 23 June 2017 01:18 |
| Eclipse User |
|
|
|
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.08068 seconds
Home
