| [CDO] Metamodels in CDO & exceptions [message #821555] |
Thu, 15 March 2012 14:13  |
|
Probably I am missing something about how to use MetaModels in CDO.
I launch and nice and fresh CDO Server. The CDO Server init the EPackege (using this 'trick' EPackage dummy = Mm1Package.eINSTANCE;). Then I connect through CDO UI and I register the metamodel from the workspace. Everything goes fine. Then I restart the server and when I open a view (having again registered the metamodel or not is the same) I get this error:
java.lang.NullPointerException
org.eclipse.net4j.signal.RemoteException: java.lang.NullPointerException
at org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:139)
at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:128)
at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:446)
at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:63)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at org.eclipse.emf.cdo.common.model.CDOClassifierRef.<init>(CDOClassifierRef.java:45)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.getObjectType(ObjectTypeTable.java:91)
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:73)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStoreAccessor.java:176)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStoreAccessor.java:193)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevision(DBStoreAccessor.java:213)
at org.eclipse.emf.cdo.internal.server.Repository.loadRevisions(Repository.java:445)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:365)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:276)
at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:259)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute(RevisionInfo.java:132)
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:133)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:96)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:296)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
... 5 more
Cheers,
Federico
website: http://www.federico-tomassetti.it
|
|
|
| Re: [CDO] Metamodels in CDO & exceptions [message #821603 is a reply to message #821555] |
Thu, 15 March 2012 15:33  |
|
Am 15.03.2012 15:13, schrieb Federico Tomassetti:
> Probably I am missing something about how to use MetaModels in CDO.
>
> I launch and nice and fresh CDO Server. The CDO Server init the EPackege (using this 'trick' EPackage dummy =
> Mm1Package.eINSTANCE;).
I don't understand what this trick is doing and what it's supposed to achieve. Can you elaborate?
> Then I connect through CDO UI and I register the metamodel from the workspace. Everything goes fine. Then I restart
> the server and when I open a view (having again registered the metamodel or not is the same) I get this error:
>
>
> java.lang.NullPointerException
> org.eclipse.net4j.signal.RemoteException: java.lang.NullPointerException
> at org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:139)
> at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:128)
> at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:446)
> at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:63)
> at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at org.eclipse.emf.cdo.common.model.CDOClassifierRef.<init>(CDOClassifierRef.java:45)
> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.getObjectType(ObjectTypeTable.java:91)
> 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:73)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStoreAccessor.java:176)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStoreAccessor.java:193)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevision(DBStoreAccessor.java:213)
> at org.eclipse.emf.cdo.internal.server.Repository.loadRevisions(Repository.java:445)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:365)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:276)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:259)
> at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute(RevisionInfo.java:132)
> 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:133)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:96)
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:296)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
> ... 5 more
Again, I don't understand exactly what you're doing. Is it possible that you send me an *executable* piece of code that
reproduces the issue?
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
|
|
|
| Re: [CDO] Metamodels in CDO & exceptions [message #821622 is a reply to message #821603] |
Thu, 15 March 2012 16:07 |
|
I am sorry that I was so obscure, I will try to explain better.
The 'trick' (bad choice of name) it is used just to force the initialization of the EPackage so that it is registered into the EPackage register. Using the class is supposed to assure that the class is loaded and consequently the static initialization is performed. In particular this line of my interface Mm1EPackage will be executed
Mm1Package eINSTANCE = mm1.impl.Mm1PackageImpl.init();
(each field of an interface is implicitly static and so it will be initialized when the class is loaded).
The method Mm1PackageImpl.init has this code:
public static Mm1Package init() {
if (isInited) return (Mm1Package)EPackage.Registry.INSTANCE.getEPackage(Mm1Package.eNS_URI);
...
}
The registration has to be done manually when EMF is used outside an OSGi container. This problem was already discussed (http://www.eclipse.org/forums/index.php/mv/msg/203918/651989/#msg_651989).
The problem is that this kind of behavior is not deterministic... (as reported also in the discussion and in a bug entry related to it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=366844).
In my case the exception was signaled repeatly, than I restarted Eclipse and it disappeared...
I would ask which is the best practice to manage meta-models with CDO operating standalone (no OSGi-container). Should I package them with the server and force the initialization?
On the client side, operating with the CDO UI should I register the meta-model from the workspace before opening any view/transaction? I do not understand which is the expected behaviour when I have a meta-model available only on the client side (not on the server side). I am sorry if I am not clear or my questions are really dumb, but I am some difficulties in understanding how CDO works.
website: http://www.federico-tomassetti.it
|
|
|
| Re: [CDO] Metamodels in CDO &amp; exceptions [message #821705 is a reply to message #821622] |
Thu, 15 March 2012 18:06 |
|
Am 15.03.2012 17:07, schrieb Federico Tomassetti:
> I am sorry that I was so obscure, I will try to explain better.
>
> The 'trick' (bad choice of name) it is used just to force the initialization of the EPackage so that it is registered
> into the EPackage register. Using the class is supposed to assure that the class is loaded and consequently the static
> initialization is performed. In particular this line of my interface Mm1EPackage will be executed
>
> Mm1Package eINSTANCE = mm1.impl.Mm1PackageImpl.init();
I see ;-)
Outside of OSGi I tend to use MyPackage.eINSTANCE.getClass() to force initialization/registration of the package.
>
>
> (each field of an interface is implicitly static and so it will be initialized when the class is loaded).
>
> The method Mm1PackageImpl.init has this code:
>
>
> public static Mm1Package init() {
> if (isInited) return (Mm1Package)EPackage.Registry.INSTANCE.getEPackage(Mm1Package.eNS_URI);
> ..
> }
>
>
> The registration has to be done manually when EMF is used outside an OSGi container. This problem was already
> discussed (http://www.eclipse.org/forums/index.php/mv/msg/203918/651989/#msg_651989).
> The problem is that this kind of behavior is not deterministic... (as reported also in the discussion and in a bug
> entry related to it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=366844).
>
> In my case the exception was signaled repeatly, than I restarted Eclipse and it disappeared...
>
> I would ask which is the best practice to manage meta-models with CDO operating standalone (no OSGi-container).
See above.
> Should I package them with the server and force the initialization?
The server usually operates purely reflectively, i.e., it doesn't require to deploy the generated models at all. This is
only necessary if you have server-side logic (OCL queries, constraints) that require it.
> On the client side, operating with the CDO UI
There you would have OSGi, eh?!
> should I register the meta-model from the workspace before opening any view/transaction?
Using the design-time models from the workspace is usually a bad idea, unless you ensure that all (even future) clients
can properly resolve workspace URIs.
> I do not understand which is the expected behaviour when I have a meta-model available only on the client side (not on
> the server side).
The expected behaviour would be that it just works :P
> I am sorry if I am not clear or my questions are really dumb, but I am some difficulties in understanding how CDO works.
Well, CDO is not rocket science, but also not moron simple. Usually CDO does not require to deal with the session's (or
repository's) package registry at all. I guess there are still some old tutorials on the web (and even some hundred
older test cases) that do it nevrtheless. But modern CDO versions, e.g., 4.0 or 4.1, do everything automatically for you.
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.02152 seconds
] 
Search
Help
Register
Login
Home
