Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Saving 1st model element to new repo crashes Eclipse(Class not found ResourcePlugin, not true though)
[CDO] Saving 1st model element to new repo crashes Eclipse [message #1731128] Tue, 03 May 2016 04:31 Go to next message
David Wynter is currently offline David WynterFriend
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 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
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 #1731419 is a reply to message #1731270] Thu, 05 May 2016 05:14 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi Eike,

I managed to upgrade to CDO 4.4.1 and that fixed the problem. Thx again.

It also now looks like I no longer have to add my ecore model to the empty database, it must do so when my client attaches to the cdo server. I am using DBStore.

Regards,

David

[Updated on: Thu, 05 May 2016 05:15]

Report message to a moderator

Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731429 is a reply to message #1731419] Thu, 05 May 2016 08:00 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 05.05.2016 um 07:14 schrieb David Wynter:
> Hi Eike,
>
> I managed to upgrade to CDO 4.4.1 and that fixed the problem. Thx again.
Good to hear that!

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 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
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 #1731524 is a reply to message #1731490] Fri, 06 May 2016 13:13 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi,

Yes the stack trace is shown in my original message. The issue we have occurs when we attempt to save changes to our model, they happen at random. Once that occurs whenever we try to read the repository we get the stack trace you see above.

It is hard to debug this because the stack trace is 30 calls deep from my code, that is a lot of CDO code between me and the issue. I appreciate your help.
Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1731900 is a reply to message #1731524] Tue, 10 May 2016 17:46 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I am now having issues with CDO 4.4.1. With version 4.2.1 I could add a package to the registry using the Workspace... option. That option is no longer there, there is only a Filesystem.... option, and it does not display my ecore file even when the ecore file is in the directory I have navigated to and the "Ecore models (*.ecore)" file extension is selected. Can you show me where the documentation is that describes how to prime a brand new empty database ready to be used with a particular ecore file in the registry? I know I have to prime the database with the registry entry, otherwise I can add elements but get an exception whenever I try to save that transaction.

I am on Linux Mint 17.3 64 bit.
index.php/fa/25866/0/
index.php/fa/25865/0/

[Updated on: Tue, 10 May 2016 17:57]

Report message to a moderator

Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1735152 is a reply to message #1731900] Wed, 15 June 2016 21:47 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I am still unable to connect to my repo using the CDO Explorer Perspective.

I see that while the package is registered the Type is set to '?' does this make a difference?
Re: [CDO] Saving 1st model element to new repo crashes Eclipse [message #1735164 is a reply to message #1735152] Thu, 16 June 2016 04:35 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 15.06.2016 um 23:47 schrieb David Wynter:
> I am still unable to connect to my repo using the CDO Explorer Perspective.
>
> I see that while the package is registered the Type is set to '?' does this make a difference?
That means that only a package descriptor is registered at that point in time and the concrete package type is not yet
known. As soon as you actually use that package the type becomes either NATIVE or LEGACY.

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 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
David Wynter wrote on Thu, 22 June 2017 11:20
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?


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:20
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?


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?


Previous Topic:[Transaction] An exception was (not) ignored during command execution
Next Topic:[CDO] Server Choices and Deployment Options
Goto Forum:
  


Current Time: Fri Mar 29 14:52:28 GMT 2024

Powered by FUDForum. Page generated in 0.02906 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top