Home » Modeling » EMF » [CDO] OCL query failing on a newly started CDO server...(...and not anymore when the corresponding element has been loaded once !)
| [CDO] OCL query failing on a newly started CDO server... [message #1362730] |
Sat, 17 May 2014 16:10  |
Eclipse User |
|
|
|
Hi all,
I have a problem with the following OCL query :
mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))
It fails with a "org.eclipse.ocl.SemanticException: Unknown type ([mm, pictograms, Diagram])", but only in a specific situation.
The query is run against a CDO repository. And it fails if it is run directly after the CDO server has been started.
Whereas it succeeds if whatever diagram stored in the repository has been loaded once by any CDO client in a "classical way" (that is, by accessing a diagram in a transaction.getResource(XXX) content), before my application issues the query.
I tried to solve my problem by registering the necessary packages with lines like the following one :
session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);
But it makes no difference and I found no other clue while browsing various topics.
Could somebody please tell me what's wrong ?
Kind regards,
Laurent
|
|
|
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1369187 is a reply to message #1362730] |
Tue, 20 May 2014 09:11  |
| Eclipse User |
|
|
|
Hi, Laurent,
In order for a server-side OCL query to parse, the server needs to know
the EPackages involved. This happens implicitly when committing
instances of those EPackages, of course, but I don't think that adding
it to the client-side session package registry affects the server in
any way.
If you need to execute this query (presumably getting an empty result)
before the repository contains any instances of your EPackage, you
could pre-register the package in your server's XML configuration:
<initialPackage nsURI="http://whatever/is/the/pictogram/package/nsuri"/>
HTH,
Christian
On 2014-05-17 20:10:04 +0000, Laurent Le Moux said:
> Hi all,
>
> I have a problem with the following OCL query :
>
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
>
>
> It fails with a "org.eclipse.ocl.SemanticException: Unknown type ([mm,
> pictograms, Diagram])", but only in a specific situation.
>
> The query is run against a CDO repository. And it fails if it is run
> directly after the CDO server has been started.
>
> Whereas it succeeds if whatever diagram stored in the repository has
> been loaded once by any CDO client in a "classical way" (that is, by
> accessing a diagram in a transaction.getResource(XXX) content), before
> my application issues the query.
>
> I tried to solve my problem by registering the necessary packages with
> lines like the following one :
>
> session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);
>
>
> But it makes no difference and I found no other clue while browsing
> various topics.
> Could somebody please tell me what's wrong ?
>
> Kind regards,
>
> Laurent
|
|
|
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1369645 is a reply to message #1369187] |
Tue, 20 May 2014 13:32 |
| Eclipse User |
|
|
|
Hi Christian,
Thanks for your answer. I tried to add your statement in my cdo-server.xml:
<initialPackage nsURI="http://eclipse.org/graphiti/mm"/>
<initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms"/>
<initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms/styles"/>
<initialPackage nsURI="http://eclipse.org/graphiti/mm/pictograms"/>
But the server then refuses to start with a 'JdbcSQLException: Unique index or primary key violation' message (see attached log).
Moreover, when I execute my query, the repository is not empty. So I would not get an empty result back.
But, as the server has just been restarted, it seems that the implicit EPackage loading you described does not take place.
So, I had a look to the CDO Explorer package registry and it appears the Graphiti packages are correctly loaded (see attached screenshot):
Whereas, when I add traces to list the registered packages in my application, only the first Graphiti package is registered !
Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://eclipse.org/graphiti/mm, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://lemoux.fr/modeling/framework/commons/metadata/commit, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://lemoux.fr/modeling/framework/commons/metadata/configuration, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://repositorystructure/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://service/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://user/1.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://www.eclipse.org/emf/2002/Ecore, State : PROXY, Type : LEGACY, Original : LEGACY
Id : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, State : PROXY, Type : NATIVE, Original : NATIVE
Id : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, State : PROXY, Type : NATIVE, Original : NATIVE
Id : http://www.eclipse.org/emf/CDO/expressions/4.3.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://www.eclipse.org/emf/CDO/security/4.1.0, State : PROXY, Type : LEGACY, Original : NATIVE
I then tried again to register the 3 missing packages (like in Eike's StandaloneContainerExample in the CDO Wiki snippets) :
// Register missing Graphiti packages
session.getPackageRegistry().putEPackage(AlgorithmsPackage.eINSTANCE);
session.getPackageRegistry().putEPackage(StylesPackage.eINSTANCE);
session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);
// List registered packages
for (CDOPackageUnit pu : session.getPackageRegistry().getPackageUnits()) {
System.out.print("Id : " + pu.getID());
System.out.print(", State : " + pu.getState());
System.out.print(", Type : " + pu.getType());
System.out.println(", Original : " + pu.getOriginalType());
}
But this time, I get a NPE when I try to list again my registered packages (not when invoking putEPackage but rather when calling getType !) :
Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://eclipse.org/graphiti/mm, State : LOADED
...
java.lang.NullPointerException
at org.eclipse.emf.cdo.common.model.CDOPackageTypeRegistry.lookup(CDOPackageTypeRegistry.java:105)
at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.getType(CDOPackageUnitImpl.java:114)
...
Any idea why the missing packages are not registered like for the CDO Explorer and why I fail to force this registration ?
Regards,
Laurent
|
|
|
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1369691 is a reply to message #1369645] |
Tue, 20 May 2014 13:58 |
| Eclipse User |
|
|
|
Hi, Laurent,
Sorry, I didn't understand that your use case is re-starting a server
that already has content. I identified with a problem I had once, in
which the CDO server instance was entirely new and had no packages
registered because it contained no data. :-/
If a server-side view can't find the EPackages for objects that are
present in the repository when parsing OCL, I'm afraid I won't be of
much help.
One question: are these packages that you're having difficulty with
nested EPackages? (sub-packages contained within another package)
AFAIK, that should work in CDO (there had been problems, but they
should be fixed long since), but I'm not sure.
Which version of CDO are you using?
cW
On 2014-05-20 17:32:48 +0000, Laurent Le Moux said:
> Hi Christian,
>
> Thanks for your answer. I tried to add your statement in my cdo-server.xml:
>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm"/>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms"/>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms/styles"/>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm/pictograms"/>
>
>
> But the server then refuses to start with a 'JdbcSQLException: Unique
> index or primary key violation' message (see attached log).
>
> Moreover, when I execute my query, the repository is not empty. So I
> would not get an empty result back.
> But, as the server has just been restarted, it seems that the implicit
> EPackage loading you described does not take place.
>
> So, I had a look to the CDO Explorer package registry and it appears
> the Graphiti packages are correctly loaded (see attached screenshot):
>
>
>
> Whereas, when I add traces to list the registered packages in my
> application, only the first Graphiti package is registered !
>
> Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://eclipse.org/graphiti/mm, State : PROXY, Type : LEGACY,
> Original : NATIVE
> Id : http://lemoux.fr/modeling/framework/commons/metadata/commit, State
> : PROXY, Type : LEGACY, Original : NATIVE
> Id :
> http://lemoux.fr/modeling/framework/commons/metadata/configuration,
> State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://repositorystructure/2.0, State : PROXY, Type : LEGACY,
> Original : NATIVE
> Id : http://service/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://user/1.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://www.eclipse.org/emf/2002/Ecore, State : PROXY, Type :
> LEGACY, Original : LEGACY
> Id : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, State : PROXY,
> Type : NATIVE, Original : NATIVE
> Id : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, State : PROXY, Type :
> NATIVE, Original : NATIVE
> Id : http://www.eclipse.org/emf/CDO/expressions/4.3.0, State : PROXY,
> Type : LEGACY, Original : NATIVE
> Id : http://www.eclipse.org/emf/CDO/security/4.1.0, State : PROXY, Type
> : LEGACY, Original : NATIVE
>
> I then tried again to register the 3 missing packages (like in Eike's
> StandaloneContainerExample in the CDO Wiki snippets) :
>
> // Register missing Graphiti packages
> session.getPackageRegistry().putEPackage(AlgorithmsPackage.eINSTANCE);
> session.getPackageRegistry().putEPackage(StylesPackage.eINSTANCE);
> session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);
>
> // List registered packages
> for (CDOPackageUnit pu : session.getPackageRegistry().getPackageUnits()) {
> System.out.print("Id : " + pu.getID());
> System.out.print(", State : " + pu.getState());
> System.out.print(", Type : " + pu.getType());
> System.out.println(", Original : " + pu.getOriginalType());
> }
>
> But this time, I get a NPE when I try to list again my registered
> packages (not when invoking putEPackage but rather when calling getType
> !) :
>
> Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://eclipse.org/graphiti/mm, State : LOADED
> ..
> java.lang.NullPointerException
> at
> org.eclipse.emf.cdo.common.model.CDOPackageTypeRegistry.lookup(CDOPackageTypeRegistry.java:105)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.getType(CDOPackageUnitImpl.java:114)
>
> ..
>
> Any idea why the missing packages are not registered like for the CDO
> Explorer and why I fail to force this registration ?
>
> Regards,
>
> Laurent
> <image><image>
|
|
| | |
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1376006 is a reply to message #1374576] |
Fri, 23 May 2014 04:07 |
| Eclipse User |
|
|
|
Hi, Laurent.
One way to work around you problem is to use EClass of you package as a context object for OCL query.
For example, this query will fail on cold (just restarted) CDO:
CDOQuery q = view.createQuery("ocl", "myPackage::MyClass.allInstances()");
System.out.println(q.getResult());
This, however, will work fine:
CDOQuery q = view.createQuery("ocl", "myPackage::MyClass.allInstances()", MyPackage.Literals.MY_CLASS);
System.out.println(q.getResult());
The correct fix, however, should probably include some fixes on OCL side. Root of a problem lies in
org.eclipse.ocl.ecore.EcoreEnvironment.findPackage(List<String>, Registry)
for (Object next : registry.values()) {
if (next instanceof EPackage) {
...
}
}
On the 'cold' CDO server, package registry contains so called PackageDescriptors, which is a lazy-loading proxy of a EPackage. Of only OCL could concider them and load on-demand...
|
|
|
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1376080 is a reply to message #1376006] |
Fri, 23 May 2014 04:45 |
| Eclipse User |
|
|
|
Hi
Hopefully for Mars we can migrate to the Pivot-based OCL that has an
extension allowing a quoted URI as the first qualifier.
'http://my.package'::MyClass.allInstances()
Regards
Ed Willink
On 23/05/2014 09:07, Leonid Ripeynih wrote:
> Hi, Laurent.
> One way to work around you problem is to use EClass of you package as
> a context object for OCL query.
> For example, this query will fail on cold (just restarted) CDO:
>
>
> CDOQuery q = view.createQuery("ocl",
> "myPackage::MyClass.allInstances()");
> System.out.println(q.getResult());
>
>
> This, however, will work fine:
>
>
> CDOQuery q = view.createQuery("ocl",
> "myPackage::MyClass.allInstances()", MyPackage.Literals.MY_CLASS);
> System.out.println(q.getResult());
>
>
> The correct fix, however, should probably include some fixes on OCL
> side. Root of a problem lies in
> org.eclipse.ocl.ecore.EcoreEnvironment.findPackage(List<String>,
> Registry)
> for (Object next : registry.values()) {
> if (next instanceof EPackage) {
> ...
> }
> }
>
>
> On the 'cold' CDO server, package registry contains so called
> PackageDescriptors, which is a lazy-loading proxy of a EPackage. Of
> only OCL could concider them and load on-demand...
>
>
>
|
|
|
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1383243 is a reply to message #1376080] |
Mon, 26 May 2014 05:18 |
| Eclipse User |
|
|
|
Hi Leonid & Ed,
Thank you both for your detailed answer. But I'm afraid I'm not yet out of it...
I tried the following :
// Dummy OCL query to ensure the Graphiti packages are loaded
String dummyGraphitiQuery = "mm::StyleContainer.allInstances()";
CDOQuery cqDummyGraphiti = transaction.createQuery("ocl", dummyGraphitiQuery, MmPackage.Literals.STYLE_CONTAINER);
cqDummyGraphiti.getResult();
// Look for all diagrams where the element appears
String diagramsQuery = "mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | "
+ "d.children.link.businessObjects->includes(self))";
CDOQuery cqDiagrams = transaction.createQuery("ocl", diagramsQuery, element.cdoID(), true);
final List<Diagram> diagrams = cqDiagrams.getResult(Diagram.class);
This works except in one situation where I now get the following exception :
org.eclipse.net4j.util.WrappedException: Problem executing OCL query: mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))
at org.eclipse.net4j.util.WrappedException.wrap(WrappedException.java:44)
at org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:153)
at org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:303)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: OCL query evaluated to 'invalid'. Run with '-Dorg.eclipse.ocl.debug=true' and visit the log for failure details.
at org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:132)
... 6 more
I actually have another query which purpose is - before I delete a 'service' element from my repository - to check that none of its 'operation' sub-elements is still referenced elsewhere in the repository by an 'application' element.
I'm also facing problems with this second query depending on whether it is executed on a cold server or not. The result - however - is different. Instead of getting an exception, I just get an empty 'application' list back when I shouldn't...
So, if I run this second query first on a cold server, it fails. And then, the first query also fails with the above exception.
I tried the same trick :
// Dummy OCL queries to ensure the Application, Service and Operation packages are loaded
String dummyApplicationQuery = "applicationv2::Application.allInstances()";
CDOQuery cqDummyApplication = transaction.createQuery("ocl", dummyApplicationQuery, Applicationv2Package.Literals.APPLICATION);
cqDummyApplication.getResult();
String dummyServiceQuery = "servicev2::Service.allInstances()";
CDOQuery cqDummyService = transaction.createQuery("ocl", dummyServiceQuery, Servicev2Package.Literals.SERVICE);
cqDummyService.getResult();
String dummyOperationQuery = "servicev2::Operation.allInstances()";
CDOQuery cqDummyOperation = transaction.createQuery("ocl", dummyOperationQuery, Servicev2Package.Literals.OPERATION);
cqDummyOperation.getResult();
// Use an OCL query to find any application invoking any deleted service operation
String appsQuery = "applicationv2::Application.allInstances()->select(a:applicationv2::Application|not a.invokes->intersection(self.defines)->isEmpty())";
CDOQuery cqApps = transaction.createQuery("ocl", appsQuery, ((Service)element).cdoID(), false);
List<Application> clientApps = cqApps.getResult(Application.class);
The three dummy queries are apparently returning the expected results (I checked each returned list size).
But I still get an unexpected empty result back and I still 'disturbs' the other query if run first...
Any idea why ?
Regards,
Laurent
|
|
|
| Re: [CDO] OCL query failing on a newly started CDO server... [message #1383397 is a reply to message #1383243] |
Mon, 26 May 2014 06:45 |
| Eclipse User |
|
|
|
Hi Laurent
It looks as if you have a genuine problem that I should look at. Maybe
it's OCL, maybe CDO.OCL may be bad user init.
Whatever, since I've only used CDO when investigating CDO/OCL queries,
please provide an easy to use repro with clear instructions on how to
reproduce your problem and attach it to a CDO Bugzilla.
I'm kind of busy with Luna RC releases at present so I cannot promise to
look at it till late next week at the earliest.
Regards
Ed Willink
On 26/05/2014 10:18, Laurent Le Moux wrote:
> Hi Leonid & Ed,
>
> Thank you both for your detailed answer. But I'm afraid I'm not yet
> out of it...
>
> I tried the following :
>
> // Dummy OCL query to ensure the Graphiti packages are loaded
> String dummyGraphitiQuery = "mm::StyleContainer.allInstances()";
> CDOQuery cqDummyGraphiti = transaction.createQuery("ocl",
> dummyGraphitiQuery, MmPackage.Literals.STYLE_CONTAINER);
> cqDummyGraphiti.getResult();
>
> // Look for all diagrams where the element appears
> String diagramsQuery =
> "mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | "
> + "d.children.link.businessObjects->includes(self))";
> CDOQuery cqDiagrams = transaction.createQuery("ocl", diagramsQuery,
> element.cdoID(), true);
> final List<Diagram> diagrams = cqDiagrams.getResult(Diagram.class);
>
> This works except in one situation where I now get the following
> exception :
>
> org.eclipse.net4j.util.WrappedException: Problem executing OCL query:
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
> at
> org.eclipse.net4j.util.WrappedException.wrap(WrappedException.java:44)
> at
> org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:153)
> at
> org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:303)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
> Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: OCL query evaluated to 'invalid'. Run
> with '-Dorg.eclipse.ocl.debug=true' and visit the log for failure
> details.
> at
> org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:132)
> ... 6 more
>
>
> I actually have another query which purpose is - before I delete a
> 'service' element from my repository - to check that none of its
> 'operation' sub-elements is still referenced elsewhere in the
> repository by an 'application' element.
>
> I'm also facing problems with this second query depending on whether
> it is executed on a cold server or not. The result - however - is
> different. Instead of getting an exception, I just get an empty
> 'application' list back when I shouldn't...
>
> So, if I run this second query first on a cold server, it fails. And
> then, the first query also fails with the above exception.
>
> I tried the same trick :
>
> // Dummy OCL queries to ensure the Application, Service and Operation
> packages are loaded
> String dummyApplicationQuery =
> "applicationv2::Application.allInstances()";
> CDOQuery cqDummyApplication = transaction.createQuery("ocl",
> dummyApplicationQuery, Applicationv2Package.Literals.APPLICATION);
> cqDummyApplication.getResult();
>
> String dummyServiceQuery = "servicev2::Service.allInstances()";
> CDOQuery cqDummyService = transaction.createQuery("ocl",
> dummyServiceQuery, Servicev2Package.Literals.SERVICE);
> cqDummyService.getResult();
>
> String dummyOperationQuery = "servicev2::Operation.allInstances()";
> CDOQuery cqDummyOperation = transaction.createQuery("ocl",
> dummyOperationQuery, Servicev2Package.Literals.OPERATION);
> cqDummyOperation.getResult();
>
> // Use an OCL query to find any application invoking any deleted
> service operation
> String appsQuery =
> "applicationv2::Application.allInstances()->select(a:applicationv2::Application|not
> a.invokes->intersection(self.defines)->isEmpty())";
> CDOQuery cqApps = transaction.createQuery("ocl", appsQuery,
> ((Service)element).cdoID(), false);
> List<Application> clientApps = cqApps.getResult(Application.class);
>
> The three dummy queries are apparently returning the expected results
> (I checked each returned list size).
>
> But I still get an unexpected empty result back and I still 'disturbs'
> the other query if run first...
>
> Any idea why ?
>
> Regards,
>
> Laurent
|
|
| |
Goto Forum:
Current Time: Mon Apr 28 19:28:19 EDT 2025
Powered by FUDForum. Page generated in 0.03894 seconds |
Home
