Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO] Problem with single Ecore, multiple packages
| [CDO] Problem with single Ecore, multiple packages [message #120722] |
Wed, 30 April 2008 15:30  |
 Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Hi Eike,
I've come across a problem when dealing with an Ecore file containing
multiple packages.
Ecore file:
Package1:
ClassA [has an attribute of type ClassD]
ClassB
Package2:
ClassC
ClassD
In my client, I register both packages (A & B) with my session's package
registry. I then create an object of type ClassA, but I don't set
(leave it as null) its attribute of type ClassD.
When CDO reaches the server side at commit time, I only see Package1
being transfered over and since ClassA references Package2 through an
attribute of ClassD, I get an exception:
Unable to resolve classref: CDOClassRef(Package2, ...)
at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
at
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
If I take the same code and create an object of type ClassC (or any
object from Package2) and add this object to my resource, Package2 will
get transfered over and my test will work. So in order to see your
package on the server side, you need to:
1. Register it
2. Create at least one object from that package
Problem is that object of type ClassA references Package2. So when
deciding which package need to be transfered, CDO will have to do a deep
scan of the object instead of only using its containingPackage (this is
how I assume CDO works, correct me if I'm wrong).
Any thoughts?
Eric
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #120735 is a reply to message #120722] |
Wed, 30 April 2008 16:28  |
|
Hi Eric,
I recently changed the code to better handle nested packages. Are you
using the latest CVS sources? It should work with them...
Cheers
/Eike
Eric wrote:
> Hi Eike,
> I've come across a problem when dealing with an Ecore file containing
> multiple packages.
> Ecore file:
> Package1:
> ClassA [has an attribute of type ClassD]
> ClassB
> Package2:
> ClassC
> ClassD
> In my client, I register both packages (A & B) with my session's package
> registry. I then create an object of type ClassA, but I don't set
> (leave it as null) its attribute of type ClassD.
> When CDO reaches the server side at commit time, I only see Package1
> being transfered over and since ClassA references Package2 through an
> attribute of ClassD, I get an exception:
> Unable to resolve classref: CDOClassRef(Package2, ...)
> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
> at
>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
> If I take the same code and create an object of type ClassC (or any
> object from Package2) and add this object to my resource, Package2 will
> get transfered over and my test will work. So in order to see your
> package on the server side, you need to:
> 1. Register it
> 2. Create at least one object from that package
> Problem is that object of type ClassA references Package2. So when
> deciding which package need to be transfered, CDO will have to do a deep
> scan of the object instead of only using its containingPackage (this is
> how I assume CDO works, correct me if I'm wrong).
> Any thoughts?
> Eric
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #120754 is a reply to message #120735] |
Wed, 30 April 2008 19:00 |
Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Hi Eike,
I've tried with the latest code and I have the same result. But I
know why it doesn't work. The problem is the common parent package for
Package1 & Package2 doesn't exist because it is not generated by the
genmodel. I have modified my Ecore file:
PackageRoot
ClassRoot
Package1
ClassA, ClassB
Package2
ClassC, ClassD
So now I have a common root package and it is created by my genmodel
since I have one class (ClassRoot) under this package. Because of this
new package, your code in CDOTransactionImpl.analyzeNewPackages() will
crawl to the top level package (PackageRoot), put it in the newpackages
collection and send it to the server. Now the server is aware of
PackageRoot and its children packages (Package1 & Package2).
The problem with the actual code is that it won't pick up any parent
packages that are not generated by genmodel. I don't know if there is
an option to generate code for empty packages (packages not holding
classes directly)... Another problem that could arise is basically the
situation I explained in my previous message:
Two root packages cross-referencing each other. If you don't persist an
object for each of those 2 packages, only 1 package will be flagged as
'new' and only this one will be transfered to the server.
Do you understand what I'm trying to explain here?
Eric
Eike Stepper wrote:
> Hi Eric,
>
> I recently changed the code to better handle nested packages. Are you
> using the latest CVS sources? It should work with them...
>
> Cheers
> /Eike
>
>
> Eric wrote:
>
>> Hi Eike,
>
>> I've come across a problem when dealing with an Ecore file
>> containing multiple packages.
>
>> Ecore file:
>> Package1:
>> ClassA [has an attribute of type ClassD]
>> ClassB
>> Package2:
>> ClassC
>> ClassD
>
>> In my client, I register both packages (A & B) with my session's
>> package registry. I then create an object of type ClassA, but I don't
>> set (leave it as null) its attribute of type ClassD.
>
>> When CDO reaches the server side at commit time, I only see Package1
>> being transfered over and since ClassA references Package2 through an
>> attribute of ClassD, I get an exception:
>
>> Unable to resolve classref: CDOClassRef(Package2, ...)
>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>> at
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>
>> If I take the same code and create an object of type ClassC (or any
>> object from Package2) and add this object to my resource, Package2
>> will get transfered over and my test will work. So in order to see
>> your package on the server side, you need to:
>> 1. Register it
>> 2. Create at least one object from that package
>
>> Problem is that object of type ClassA references Package2. So when
>> deciding which package need to be transfered, CDO will have to do a
>> deep scan of the object instead of only using its containingPackage
>> (this is how I assume CDO works, correct me if I'm wrong).
>
>> Any thoughts?
>> Eric
>
>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #120757 is a reply to message #120754] |
Wed, 30 April 2008 19:15 |
Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Eike,
I've tried adding multiple root packages to an Ecore file and you
can't. So the last part of my previous message doesn't apply directly.
You can't have 2 root packages cross-referencing each other. The only
case where this bug will happen is whenever your root package object is
not generated by genmodel.
Eric
Eric wrote:
> Hi Eike,
>
> I've tried with the latest code and I have the same result. But I
> know why it doesn't work. The problem is the common parent package for
> Package1 & Package2 doesn't exist because it is not generated by the
> genmodel. I have modified my Ecore file:
> PackageRoot
> ClassRoot
> Package1
> ClassA, ClassB
> Package2
> ClassC, ClassD
>
> So now I have a common root package and it is created by my genmodel
> since I have one class (ClassRoot) under this package. Because of this
> new package, your code in CDOTransactionImpl.analyzeNewPackages() will
> crawl to the top level package (PackageRoot), put it in the newpackages
> collection and send it to the server. Now the server is aware of
> PackageRoot and its children packages (Package1 & Package2).
>
> The problem with the actual code is that it won't pick up any parent
> packages that are not generated by genmodel. I don't know if there is
> an option to generate code for empty packages (packages not holding
> classes directly)... Another problem that could arise is basically the
> situation I explained in my previous message:
> Two root packages cross-referencing each other. If you don't persist an
> object for each of those 2 packages, only 1 package will be flagged as
> 'new' and only this one will be transfered to the server.
>
> Do you understand what I'm trying to explain here?
>
> Eric
>
> Eike Stepper wrote:
>> Hi Eric,
>>
>> I recently changed the code to better handle nested packages. Are you
>> using the latest CVS sources? It should work with them...
>>
>> Cheers
>> /Eike
>>
>>
>> Eric wrote:
>>
>>> Hi Eike,
>>
>>> I've come across a problem when dealing with an Ecore file
>>> containing multiple packages.
>>
>>> Ecore file:
>>> Package1:
>>> ClassA [has an attribute of type ClassD]
>>> ClassB
>>> Package2:
>>> ClassC
>>> ClassD
>>
>>> In my client, I register both packages (A & B) with my session's
>>> package registry. I then create an object of type ClassA, but I
>>> don't set (leave it as null) its attribute of type ClassD.
>>
>>> When CDO reaches the server side at commit time, I only see Package1
>>> being transfered over and since ClassA references Package2 through an
>>> attribute of ClassD, I get an exception:
>>
>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>> at
>> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>
>>> If I take the same code and create an object of type ClassC (or any
>>> object from Package2) and add this object to my resource, Package2
>>> will get transfered over and my test will work. So in order to see
>>> your package on the server side, you need to:
>>> 1. Register it
>>> 2. Create at least one object from that package
>>
>>> Problem is that object of type ClassA references Package2. So when
>>> deciding which package need to be transfered, CDO will have to do a
>>> deep scan of the object instead of only using its containingPackage
>>> (this is how I assume CDO works, correct me if I'm wrong).
>>
>>> Any thoughts?
>>> Eric
>>
>>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121639 is a reply to message #120757] |
Thu, 01 May 2008 13:27 |
|
Eric wrote:
> Eike,
> I've tried adding multiple root packages to an Ecore file and you
> can't. So the last part of my previous message doesn't apply directly.
> You can't have 2 root packages cross-referencing each other.
That's what I thought ;-)
> The only
> case where this bug will happen is whenever your root package object is
> not generated by genmodel.
Why should one want that? What would happen if you ask the subPackages for
their ESuperPackage? I would consider this a inconsistent but I really
never thought about this before. What do others think? Ed, are you
listening (can't cc you through the web UI)?
Cheers
/Eike
> Eric
> Eric wrote:
>> Hi Eike,
>>
>> I've tried with the latest code and I have the same result. But I
>> know why it doesn't work. The problem is the common parent package for
>> Package1 & Package2 doesn't exist because it is not generated by the
>> genmodel. I have modified my Ecore file:
>> PackageRoot
>> ClassRoot
>> Package1
>> ClassA, ClassB
>> Package2
>> ClassC, ClassD
>>
>> So now I have a common root package and it is created by my genmodel
>> since I have one class (ClassRoot) under this package. Because of this
>> new package, your code in CDOTransactionImpl.analyzeNewPackages() will
>> crawl to the top level package (PackageRoot), put it in the newpackages
>> collection and send it to the server. Now the server is aware of
>> PackageRoot and its children packages (Package1 & Package2).
>>
>> The problem with the actual code is that it won't pick up any parent
>> packages that are not generated by genmodel. I don't know if there is
>> an option to generate code for empty packages (packages not holding
>> classes directly)... Another problem that could arise is basically the
>> situation I explained in my previous message:
>> Two root packages cross-referencing each other. If you don't persist an
>> object for each of those 2 packages, only 1 package will be flagged as
>> 'new' and only this one will be transfered to the server.
>>
>> Do you understand what I'm trying to explain here?
>>
>> Eric
>>
>> Eike Stepper wrote:
>>> Hi Eric,
>>>
>>> I recently changed the code to better handle nested packages. Are you
>>> using the latest CVS sources? It should work with them...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eric wrote:
>>>
>>>> Hi Eike,
>>>
>>>> I've come across a problem when dealing with an Ecore file
>>>> containing multiple packages.
>>>
>>>> Ecore file:
>>>> Package1:
>>>> ClassA [has an attribute of type ClassD]
>>>> ClassB
>>>> Package2:
>>>> ClassC
>>>> ClassD
>>>
>>>> In my client, I register both packages (A & B) with my session's
>>>> package registry. I then create an object of type ClassA, but I
>>>> don't set (leave it as null) its attribute of type ClassD.
>>>
>>>> When CDO reaches the server side at commit time, I only see Package1
>>>> being transfered over and since ClassA references Package2 through an
>>>> attribute of ClassD, I get an exception:
>>>
>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>> at
>>>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>>
>>>
>>>> If I take the same code and create an object of type ClassC (or any
>>>> object from Package2) and add this object to my resource, Package2
>>>> will get transfered over and my test will work. So in order to see
>>>> your package on the server side, you need to:
>>>> 1. Register it
>>>> 2. Create at least one object from that package
>>>
>>>> Problem is that object of type ClassA references Package2. So when
>>>> deciding which package need to be transfered, CDO will have to do a
>>>> deep scan of the object instead of only using its containingPackage
>>>> (this is how I assume CDO works, correct me if I'm wrong).
>>>
>>>> Any thoughts?
>>>> Eric
>>>
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121653 is a reply to message #121639] |
Thu, 01 May 2008 13:59 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------010608080303000109020300
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Comments below.
Eike Stepper wrote:
> Eric wrote:
>
>> Eike,
>
>> I've tried adding multiple root packages to an Ecore file and you
>> can't. So the last part of my previous message doesn't apply
>> directly. You can't have 2 root packages cross-referencing each
>> other.
>
> That's what I thought ;-)
The editor doesn't support multiple roots in a .ecore resource and
likely some of the tools won't be expecting that either. You can have
two packages cross referencing each other, but you'll need to generate
them with a single GenModel.
>
>> The only case where this bug will happen is whenever your root
>> package object is not generated by genmodel.
>
> Why should one want that? What would happen if you ask the subPackages
> for their ESuperPackage? I would consider this a inconsistent but I
> really never thought about this before. What do others think? Ed, are
> you listening (can't cc you through the web UI)?
You should use Thunderbird; it will improve your newsgroup experience a
thousand fold. Not sure if 142856
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any bearings
on the situation? What's the question? :-P (I wish there was no such
thing as subpackages.)
>
> Cheers
> /Eike
>
>
>
>> Eric
>
>
>> Eric wrote:
>>> Hi Eike,
>>>
>>> I've tried with the latest code and I have the same result. But I
>>> know why it doesn't work. The problem is the common parent package
>>> for Package1 & Package2 doesn't exist because it is not generated by
>>> the genmodel. I have modified my Ecore file:
>>> PackageRoot
>>> ClassRoot
>>> Package1
>>> ClassA, ClassB
>>> Package2
>>> ClassC, ClassD
>>>
>>> So now I have a common root package and it is created by my genmodel
>>> since I have one class (ClassRoot) under this package. Because of
>>> this new package, your code in
>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top level
>>> package (PackageRoot), put it in the newpackages collection and send
>>> it to the server. Now the server is aware of PackageRoot and its
>>> children packages (Package1 & Package2).
>>>
>>> The problem with the actual code is that it won't pick up any parent
>>> packages that are not generated by genmodel. I don't know if there
>>> is an option to generate code for empty packages (packages not
>>> holding classes directly)... Another problem that could arise is
>>> basically the situation I explained in my previous message:
>>> Two root packages cross-referencing each other. If you don't
>>> persist an object for each of those 2 packages, only 1 package will
>>> be flagged as 'new' and only this one will be transfered to the server.
>>>
>>> Do you understand what I'm trying to explain here?
>>>
>>> Eric
>>>
>>> Eike Stepper wrote:
>>>> Hi Eric,
>>>>
>>>> I recently changed the code to better handle nested packages. Are
>>>> you using the latest CVS sources? It should work with them...
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Eric wrote:
>>>>
>>>>> Hi Eike,
>>>>
>>>>> I've come across a problem when dealing with an Ecore file
>>>>> containing multiple packages.
>>>>
>>>>> Ecore file:
>>>>> Package1:
>>>>> ClassA [has an attribute of type ClassD]
>>>>> ClassB
>>>>> Package2:
>>>>> ClassC
>>>>> ClassD
>>>>
>>>>> In my client, I register both packages (A & B) with my session's
>>>>> package registry. I then create an object of type ClassA, but I
>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>
>>>>> When CDO reaches the server side at commit time, I only see
>>>>> Package1 being transfered over and since ClassA references
>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>
>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>> at
>>>>
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>>>>
>>>>
>>>>> If I take the same code and create an object of type ClassC (or
>>>>> any object from Package2) and add this object to my resource,
>>>>> Package2 will get transfered over and my test will work. So in
>>>>> order to see your package on the server side, you need to:
>>>>> 1. Register it
>>>>> 2. Create at least one object from that package
>>>>
>>>>> Problem is that object of type ClassA references Package2. So
>>>>> when deciding which package need to be transfered, CDO will have
>>>>> to do a deep scan of the object instead of only using its
>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>> I'm wrong).
>>>>
>>>>> Any thoughts?
>>>>> Eric
>>>>
>>>>
>
>
--------------010608080303000109020300
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote
cite="mid:8a996694bf5626b7def3fe7a63f4ce6d$1@www.eclipse.org"
type="cite">Eric wrote:
<br>
<br>
<blockquote type="cite">Eike,
<br>
</blockquote>
<br>
<blockquote type="cite">
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121666 is a reply to message #121653] |
Thu, 01 May 2008 14:30 |
Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Ed, I had a look at the Bugzilla entry and it seems to be related to our
problem. We have a workaround (we now have at least one type under the
root package), but is this bug planned to be fixed eventually?
Thanks,
Eric
Ed Merks wrote:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>> Eric wrote:
>>
>>> Eike,
>>
>>> I've tried adding multiple root packages to an Ecore file and you
>>> can't. So the last part of my previous message doesn't apply
>>> directly. You can't have 2 root packages cross-referencing each
>>> other.
>>
>> That's what I thought ;-)
> The editor doesn't support multiple roots in a .ecore resource and
> likely some of the tools won't be expecting that either. You can have
> two packages cross referencing each other, but you'll need to generate
> them with a single GenModel.
>>
>>> The only case where this bug will happen is whenever your root
>>> package object is not generated by genmodel.
>>
>> Why should one want that? What would happen if you ask the subPackages
>> for their ESuperPackage? I would consider this a inconsistent but I
>> really never thought about this before. What do others think? Ed, are
>> you listening (can't cc you through the web UI)?
> You should use Thunderbird; it will improve your newsgroup experience a
> thousand fold. Not sure if 142856
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any bearings
> on the situation? What's the question? :-P (I wish there was no such
> thing as subpackages.)
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Eric
>>
>>
>>> Eric wrote:
>>>> Hi Eike,
>>>>
>>>> I've tried with the latest code and I have the same result. But I
>>>> know why it doesn't work. The problem is the common parent package
>>>> for Package1 & Package2 doesn't exist because it is not generated by
>>>> the genmodel. I have modified my Ecore file:
>>>> PackageRoot
>>>> ClassRoot
>>>> Package1
>>>> ClassA, ClassB
>>>> Package2
>>>> ClassC, ClassD
>>>>
>>>> So now I have a common root package and it is created by my genmodel
>>>> since I have one class (ClassRoot) under this package. Because of
>>>> this new package, your code in
>>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top level
>>>> package (PackageRoot), put it in the newpackages collection and send
>>>> it to the server. Now the server is aware of PackageRoot and its
>>>> children packages (Package1 & Package2).
>>>>
>>>> The problem with the actual code is that it won't pick up any parent
>>>> packages that are not generated by genmodel. I don't know if there
>>>> is an option to generate code for empty packages (packages not
>>>> holding classes directly)... Another problem that could arise is
>>>> basically the situation I explained in my previous message:
>>>> Two root packages cross-referencing each other. If you don't
>>>> persist an object for each of those 2 packages, only 1 package will
>>>> be flagged as 'new' and only this one will be transfered to the server.
>>>>
>>>> Do you understand what I'm trying to explain here?
>>>>
>>>> Eric
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I recently changed the code to better handle nested packages. Are
>>>>> you using the latest CVS sources? It should work with them...
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Eric wrote:
>>>>>
>>>>>> Hi Eike,
>>>>>
>>>>>> I've come across a problem when dealing with an Ecore file
>>>>>> containing multiple packages.
>>>>>
>>>>>> Ecore file:
>>>>>> Package1:
>>>>>> ClassA [has an attribute of type ClassD]
>>>>>> ClassB
>>>>>> Package2:
>>>>>> ClassC
>>>>>> ClassD
>>>>>
>>>>>> In my client, I register both packages (A & B) with my session's
>>>>>> package registry. I then create an object of type ClassA, but I
>>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>>
>>>>>> When CDO reaches the server side at commit time, I only see
>>>>>> Package1 being transfered over and since ClassA references
>>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>>
>>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>>> at
>>>>>
>> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>>>>
>>>>>
>>>>>> If I take the same code and create an object of type ClassC (or
>>>>>> any object from Package2) and add this object to my resource,
>>>>>> Package2 will get transfered over and my test will work. So in
>>>>>> order to see your package on the server side, you need to:
>>>>>> 1. Register it
>>>>>> 2. Create at least one object from that package
>>>>>
>>>>>> Problem is that object of type ClassA references Package2. So
>>>>>> when deciding which package need to be transfered, CDO will have
>>>>>> to do a deep scan of the object instead of only using its
>>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>>> I'm wrong).
>>>>>
>>>>>> Any thoughts?
>>>>>> Eric
>>>>>
>>>>>
>>
>>
>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121679 is a reply to message #121666] |
Thu, 01 May 2008 14:58 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eric,
We have an awful lot of feature requests accumulating. With a shrinking
team, it's difficult to know when we can get to any particular one of
these things... Given the workaround (add an EDataType) is quite
simple, that tends to make it seem less important in the grand scheme of
things...
Eric wrote:
> Ed, I had a look at the Bugzilla entry and it seems to be related to
> our problem. We have a workaround (we now have at least one type
> under the root package), but is this bug planned to be fixed eventually?
>
> Thanks,
> Eric
>
> Ed Merks wrote:
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>>> Eric wrote:
>>>
>>>> Eike,
>>>
>>>> I've tried adding multiple root packages to an Ecore file and
>>>> you can't. So the last part of my previous message doesn't apply
>>>> directly. You can't have 2 root packages cross-referencing each
>>>> other.
>>>
>>> That's what I thought ;-)
>> The editor doesn't support multiple roots in a .ecore resource and
>> likely some of the tools won't be expecting that either. You can
>> have two packages cross referencing each other, but you'll need to
>> generate them with a single GenModel.
>>>
>>>> The only case where this bug will happen is whenever your root
>>>> package object is not generated by genmodel.
>>>
>>> Why should one want that? What would happen if you ask the
>>> subPackages for their ESuperPackage? I would consider this a
>>> inconsistent but I really never thought about this before. What do
>>> others think? Ed, are you listening (can't cc you through the web UI)?
>> You should use Thunderbird; it will improve your newsgroup experience
>> a thousand fold. Not sure if 142856
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any
>> bearings on the situation? What's the question? :-P (I wish there
>> was no such thing as subpackages.)
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>>> Eric
>>>
>>>
>>>> Eric wrote:
>>>>> Hi Eike,
>>>>>
>>>>> I've tried with the latest code and I have the same result. But
>>>>> I know why it doesn't work. The problem is the common parent
>>>>> package for Package1 & Package2 doesn't exist because it is not
>>>>> generated by the genmodel. I have modified my Ecore file:
>>>>> PackageRoot
>>>>> ClassRoot
>>>>> Package1
>>>>> ClassA, ClassB
>>>>> Package2
>>>>> ClassC, ClassD
>>>>>
>>>>> So now I have a common root package and it is created by my
>>>>> genmodel since I have one class (ClassRoot) under this package.
>>>>> Because of this new package, your code in
>>>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top
>>>>> level package (PackageRoot), put it in the newpackages collection
>>>>> and send it to the server. Now the server is aware of PackageRoot
>>>>> and its children packages (Package1 & Package2).
>>>>>
>>>>> The problem with the actual code is that it won't pick up any
>>>>> parent packages that are not generated by genmodel. I don't know
>>>>> if there is an option to generate code for empty packages
>>>>> (packages not holding classes directly)... Another problem that
>>>>> could arise is basically the situation I explained in my previous
>>>>> message:
>>>>> Two root packages cross-referencing each other. If you don't
>>>>> persist an object for each of those 2 packages, only 1 package
>>>>> will be flagged as 'new' and only this one will be transfered to
>>>>> the server.
>>>>>
>>>>> Do you understand what I'm trying to explain here?
>>>>>
>>>>> Eric
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> I recently changed the code to better handle nested packages. Are
>>>>>> you using the latest CVS sources? It should work with them...
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Eric wrote:
>>>>>>
>>>>>>> Hi Eike,
>>>>>>
>>>>>>> I've come across a problem when dealing with an Ecore file
>>>>>>> containing multiple packages.
>>>>>>
>>>>>>> Ecore file:
>>>>>>> Package1:
>>>>>>> ClassA [has an attribute of type ClassD]
>>>>>>> ClassB
>>>>>>> Package2:
>>>>>>> ClassC
>>>>>>> ClassD
>>>>>>
>>>>>>> In my client, I register both packages (A & B) with my session's
>>>>>>> package registry. I then create an object of type ClassA, but I
>>>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>>>
>>>>>>> When CDO reaches the server side at commit time, I only see
>>>>>>> Package1 being transfered over and since ClassA references
>>>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>>>
>>>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>>>> at
>>>>>>
>>> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>>
>>>>>>
>>>>>>
>>>>>>> If I take the same code and create an object of type ClassC (or
>>>>>>> any object from Package2) and add this object to my resource,
>>>>>>> Package2 will get transfered over and my test will work. So in
>>>>>>> order to see your package on the server side, you need to:
>>>>>>> 1. Register it
>>>>>>> 2. Create at least one object from that package
>>>>>>
>>>>>>> Problem is that object of type ClassA references Package2. So
>>>>>>> when deciding which package need to be transfered, CDO will have
>>>>>>> to do a deep scan of the object instead of only using its
>>>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>>>> I'm wrong).
>>>>>>
>>>>>>> Any thoughts?
>>>>>>> Eric
>>>>>>
>>>>>>
>>>
>>>
>>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121694 is a reply to message #121653] |
Thu, 01 May 2008 14:58 |
|
Ed Merks wrote:
> Eike,
> Comments below.
> Eike Stepper wrote:
>> Eric wrote:
>>
>>> Eike,
>>
>>> I've tried adding multiple root packages to an Ecore file and you
>>> can't. So the last part of my previous message doesn't apply
>>> directly. You can't have 2 root packages cross-referencing each
>>> other.
>>
>> That's what I thought ;-)
> The editor doesn't support multiple roots in a .ecore resource and
> likely some of the tools won't be expecting that either. You can have
> two packages cross referencing each other, but you'll need to generate
> them with a single GenModel.
I feared that there's such thing ;-)
>>> The only case where this bug will happen is whenever your root
>>> package object is not generated by genmodel.
>>
>> Why should one want that? What would happen if you ask the subPackages
>> for their ESuperPackage? I would consider this a inconsistent but I
>> really never thought about this before. What do others think? Ed, are
>> you listening (can't cc you through the web UI)?
> You should use Thunderbird; it will improve your newsgroup experience a
> thousand fold.
Usually I do, but my customer is too restrictive with his firewall ;-(
> Not sure if 142856
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any bearings
> on the situation? What's the question? :-P (I wish there was no such
> thing as subpackages.)
Yes, that's what I always thought and I never used them myself!
And yes, the Bugzilla seems to address Eric's issue so I voted for it
(Eric!) ;-)
Enjoy
/Eike
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Eric
>>
>>
>>> Eric wrote:
>>>> Hi Eike,
>>>>
>>>> I've tried with the latest code and I have the same result. But I
>>>> know why it doesn't work. The problem is the common parent package
>>>> for Package1 & Package2 doesn't exist because it is not generated by
>>>> the genmodel. I have modified my Ecore file:
>>>> PackageRoot
>>>> ClassRoot
>>>> Package1
>>>> ClassA, ClassB
>>>> Package2
>>>> ClassC, ClassD
>>>>
>>>> So now I have a common root package and it is created by my genmodel
>>>> since I have one class (ClassRoot) under this package. Because of
>>>> this new package, your code in
>>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top level
>>>> package (PackageRoot), put it in the newpackages collection and send
>>>> it to the server. Now the server is aware of PackageRoot and its
>>>> children packages (Package1 & Package2).
>>>>
>>>> The problem with the actual code is that it won't pick up any parent
>>>> packages that are not generated by genmodel. I don't know if there
>>>> is an option to generate code for empty packages (packages not
>>>> holding classes directly)... Another problem that could arise is
>>>> basically the situation I explained in my previous message:
>>>> Two root packages cross-referencing each other. If you don't
>>>> persist an object for each of those 2 packages, only 1 package will
>>>> be flagged as 'new' and only this one will be transfered to the server.
>>>>
>>>> Do you understand what I'm trying to explain here?
>>>>
>>>> Eric
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I recently changed the code to better handle nested packages. Are
>>>>> you using the latest CVS sources? It should work with them...
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Eric wrote:
>>>>>
>>>>>> Hi Eike,
>>>>>
>>>>>> I've come across a problem when dealing with an Ecore file
>>>>>> containing multiple packages.
>>>>>
>>>>>> Ecore file:
>>>>>> Package1:
>>>>>> ClassA [has an attribute of type ClassD]
>>>>>> ClassB
>>>>>> Package2:
>>>>>> ClassC
>>>>>> ClassD
>>>>>
>>>>>> In my client, I register both packages (A & B) with my session's
>>>>>> package registry. I then create an object of type ClassA, but I
>>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>>
>>>>>> When CDO reaches the server side at commit time, I only see
>>>>>> Package1 being transfered over and since ClassA references
>>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>>
>>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>>> at
>>>>>
>>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>>>>
>>>>>
>>>>>> If I take the same code and create an object of type ClassC (or
>>>>>> any object from Package2) and add this object to my resource,
>>>>>> Package2 will get transfered over and my test will work. So in
>>>>>> order to see your package on the server side, you need to:
>>>>>> 1. Register it
>>>>>> 2. Create at least one object from that package
>>>>>
>>>>>> Problem is that object of type ClassA references Package2. So
>>>>>> when deciding which package need to be transfered, CDO will have
>>>>>> to do a deep scan of the object instead of only using its
>>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>>> I'm wrong).
>>>>>
>>>>>> Any thoughts?
>>>>>> Eric
>>>>>
>>>>>
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121896 is a reply to message #120735] |
Tue, 06 May 2008 10:18 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040805000202090709040803
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Eike,
I can reproduce the problem of Eric in similar but different setting.
If two packages are defined in different .ecore files, CDOClassRef can
not be resolved:
interface.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="interface"
nsURI="uuid://interface" nsPrefix="interface">
<eClassifiers xsi:type="ecore:EClass" name="IInterface"
abstract="true" interface="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="test"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
</ecore:EPackage>
reference.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="reference"
nsURI="uuid://reference" nsPrefix="reference">
<eClassifiers xsi:type="ecore:EClass" name="Reference">
<eStructuralFeatures xsi:type="ecore:EReference" name="ref"
eType="ecore:EClass interface.ecore#//IInterface"/>
</eClassifiers>
</ecore:EPackage>
common init code:
IManagedContainer container = IPluginContainer.INSTANCE;
acceptor = JVMUtil.getAcceptor(container, "default");
store = new HibernateStore(new TeneoHibernateMappingProvider());
Map<String, String> props = new HashMap<String, String>();
props.put(Props.PROP_OVERRIDE_UUID,
"f8188187-65de-4c8a-8e75-e0ce5949837a");
props.put(Props.PROP_SUPPORTING_AUDITS, "false");
props.put(Props.PROP_SUPPORTING_REVISION_DELTAS, "false");
props.put(Props.PROP_VERIFYING_REVISIONS, "false");
props.put(Props.PROP_CURRENT_LRU_CAPACITY, "10000");
props.put(Props.PROP_REVISED_LRU_CAPACITY, "10000");
props.put(PersistenceOptions.ID_FEATURE_AS_PRIMARY_KEY,
"false");
props.put("hibernate.connection.autocommit", "true");
props.put("hibernate.cache.provider_class",
"org.hibernate.cache.HashtableCacheProvider");
props.put("hibernate.connection.driver_class",
"com.mysql.jdbc.Driver");
props.put("hibernate.connection.url",
"jdbc:mysql://localhost:3306/" + DB_NAME);
props.put("hibernate.connection.username", DB_USER);
props.put("hibernate.connection.password", DB_PASS);
props.put("hibernate.dialect",
"org.hibernate.dialect.MySQLInnoDBDialect");
props.put("hibernate.hbm2ddl.auto", "update");
repository = CDOServerUtil.createRepository(repositoryName,
store,
props);
CDOServerUtil.addRepository(container, repository);
connector = JVMUtil.getConnector(container, "default");
*case 1 (manual package management):*
session = CDOUtil.openSession(connector, repositoryName,
true, false);
session.getPackageRegistry().putEPackage(InterfacePackage.eI NSTANCE);
session.getPackageRegistry().putEPackage(ReferencePackage.eI NSTANCE);
transaction = session.openTransaction();
resource = transaction.getOrCreateResource(RESOURCE_PATH);
resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
transaction.commit();
*case 2: (automatic package management):*
session = CDOUtil.openSession(connector, repositoryName,
true, true);
transaction = session.openTransaction();
resource = transaction.getOrCreateResource(RESOURCE_PATH);
resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
// note: the feature ref of the created reference is null!
transaction.commit();
Both cases result in java.lang.IllegalStateException: Unable to resolve
class ref: CDOClassRef(uuid://interface, 0)
Exception for both cases:
[ERROR] Unable to resolve class ref: CDOClassRef(uuid://interface, 0)
java.lang.IllegalStateException: Unable to resolve class ref:
CDOClassRef(uuid://interface, 0)
at
org.eclipse.emf.cdo.internal.protocol.model.CDOClassProxy.ge tCdoClass(CDOClassProxy.java:71)
at
org.eclipse.emf.cdo.internal.protocol.model.CDOFeatureImpl.g etReferenceType(CDOFeatureImpl.java:243)
at
org.eclipse.emf.cdo.server.internal.hibernate.tuplizer.CDOFe atureReferenceTypePropertyHandler.get(CDOFeatureReferenceTyp ePropertyHandler.java:58)
at
org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropert yValue(AbstractEntityTuplizer.java:277)
at
org.hibernate.persister.entity.AbstractEntityPersister.getPr opertyValue(AbstractEntityPersister.java:3586)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at
org.hibernate.event.def.AbstractSaveEventListener.cascadeBef oreSave(AbstractSaveEventListener.java:431)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:265)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
at
org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at
org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
at
org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at
org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :495)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernatePacka geHandler.writePackages(HibernatePackageHandler.java:136)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.writePackages(HibernateStoreWriter.java:157)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.commit(HibernateStoreWriter.java:56)
at
org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:179)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
Can it be that your code does not cover this case where a type in a
package is referred to in the meta-sense, but there is no reference
(yet) instance-wise?
Cheers,
Stefan
P.S. I'm working with HEAD of yesterday.
Eike Stepper schrieb:
> Hi Eric,
>
> I recently changed the code to better handle nested packages. Are you
> using the latest CVS sources? It should work with them...
>
> Cheers
> /Eike
>
>
> Eric wrote:
>
>> Hi Eike,
>
>> I've come across a problem when dealing with an Ecore file
>> containing multiple packages.
>
>> Ecore file:
>> Package1:
>> ClassA [has an attribute of type ClassD]
>> ClassB
>> Package2:
>> ClassC
>> ClassD
>
>> In my client, I register both packages (A & B) with my session's
>> package registry. I then create an object of type ClassA, but I
>> don't set (leave it as null) its attribute of type ClassD.
>
>> When CDO reaches the server side at commit time, I only see Package1
>> being transfered over and since ClassA references Package2 through an
>> attribute of ClassD, I get an exception:
>
>> Unable to resolve classref: CDOClassRef(Package2, ...)
>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>> at
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>
>> If I take the same code and create an object of type ClassC (or any
>> object from Package2) and add this object to my resource, Package2
>> will get transfered over and my test will work. So in order to see
>> your package on the server side, you need to:
>> 1. Register it
>> 2. Create at least one object from that package
>
>> Problem is that object of type ClassA references Package2. So when
>> deciding which package need to be transfered, CDO will have to do a
>> deep scan of the object instead of only using its containingPackage
>> (this is how I assume CDO works, correct me if I'm wrong).
>
>> Any thoughts?
>> Eric
>
>
--------------040805000202090709040803
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eike,<br>
<br>
I can reproduce the problem of Eric in similar but different setting.<br>
<br>
If two packages are defined in different .ecore files, CDOClassRef can
not be resolved:<br>
<br>
interface.ecore:<br>
<br>
<tt><?xml version="1.0" encoding="UTF-8"?><br>
<ecore:EPackage xmi:version="2.0"<br>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121948 is a reply to message #121896] |
Tue, 06 May 2008 11:39 |
|
Hi Stefan,
Hard to say at once where the root cause is. Theoretically one of three
areas:
1) Determination of the set of packages that need to be persisted for a
given class.
2) (De-)Serialization of the 1) set.
3) Usage of the Deserialized data in the Hibernate Store.
Personally I don't believe that it is related to 1).
It might well be 2) because that one is not easy (although I have test
cases to cover this).
For 3) we will have to ask Martin...
Can you please open a new bugzilla to track this issue?
Cheers
/Eike
Stefan Winkler wrote:
> Hi Eike,
> I can reproduce the problem of Eric in similar but different setting.
> If two packages are defined in different .ecore files, CDOClassRef can
> not be resolved:
> interface.ecore:
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="interface"
> nsURI="uuid://interface" nsPrefix="interface">
> <eClassifiers xsi:type="ecore:EClass" name="IInterface"
> abstract="true" interface="true">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="test"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> </ecore:EPackage>
> reference.ecore:
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="reference"
> nsURI="uuid://reference" nsPrefix="reference">
> <eClassifiers xsi:type="ecore:EClass" name="Reference">
> <eStructuralFeatures xsi:type="ecore:EReference" name="ref"
> eType="ecore:EClass interface.ecore#//IInterface"/>
> </eClassifiers>
> </ecore:EPackage>
> common init code:
> IManagedContainer container = IPluginContainer.INSTANCE;
> acceptor = JVMUtil.getAcceptor(container, "default");
> store = new HibernateStore(new TeneoHibernateMappingProvider());
> Map<String, String> props = new HashMap<String, String>();
> props.put(Props.PROP_OVERRIDE_UUID,
> "f8188187-65de-4c8a-8e75-e0ce5949837a");
> props.put(Props.PROP_SUPPORTING_AUDITS, "false");
> props.put(Props.PROP_SUPPORTING_REVISION_DELTAS, "false");
> props.put(Props.PROP_VERIFYING_REVISIONS, "false");
> props.put(Props.PROP_CURRENT_LRU_CAPACITY, "10000");
> props.put(Props.PROP_REVISED_LRU_CAPACITY, "10000");
> props.put(PersistenceOptions.ID_FEATURE_AS_PRIMARY_KEY,
> "false");
> props.put("hibernate.connection.autocommit", "true");
> props.put("hibernate.cache.provider_class",
> "org.hibernate.cache.HashtableCacheProvider");
> props.put("hibernate.connection.driver_class",
> "com.mysql.jdbc.Driver");
> props.put("hibernate.connection.url",
> "jdbc:mysql://localhost:3306/" + DB_NAME);
> props.put("hibernate.connection.username", DB_USER);
> props.put("hibernate.connection.password", DB_PASS);
> props.put("hibernate.dialect",
> "org.hibernate.dialect.MySQLInnoDBDialect");
> props.put("hibernate.hbm2ddl.auto", "update");
> repository = CDOServerUtil.createRepository(repositoryName,
> store,
> props);
> CDOServerUtil.addRepository(container, repository);
> connector = JVMUtil.getConnector(container, "default");
> *case 1 (manual package management):*
> session = CDOUtil.openSession(connector, repositoryName,
> true, false);
> session.getPackageRegistry().putEPackage(InterfacePackage.eI NSTANCE);
> session.getPackageRegistry().putEPackage(ReferencePackage.eI NSTANCE);
> transaction = session.openTransaction();
> resource = transaction.getOrCreateResource(RESOURCE_PATH);
> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
> transaction.commit();
> *case 2: (automatic package management):*
> session = CDOUtil.openSession(connector, repositoryName,
> true, true);
> transaction = session.openTransaction();
> resource = transaction.getOrCreateResource(RESOURCE_PATH);
> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
> // note: the feature ref of the created reference is null!
> transaction.commit();
> Both cases result in java.lang.IllegalStateException: Unable to resolve
> class ref: CDOClassRef(uuid://interface, 0)
> Exception for both cases:
> [ERROR] Unable to resolve class ref: CDOClassRef(uuid://interface, 0)
> java.lang.IllegalStateException: Unable to resolve class ref:
> CDOClassRef(uuid://interface, 0)
> at
>
org.eclipse.emf.cdo.internal.protocol.model.CDOClassProxy.ge tCdoClass(CDOClassProxy.java:71)
> at
>
org.eclipse.emf.cdo.internal.protocol.model.CDOFeatureImpl.g etReferenceType(CDOFeatureImpl.java:243)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.tuplizer.CDOFe atureReferenceTypePropertyHandler.get(CDOFeatureReferenceTyp ePropertyHandler.java:58)
> at
>
org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropert yValue(AbstractEntityTuplizer.java:277)
> at
>
org.hibernate.persister.entity.AbstractEntityPersister.getPr opertyValue(AbstractEntityPersister.java:3586)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.cascadeBef oreSave(AbstractSaveEventListener.java:431)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:265)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at
> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at
> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at
> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at
> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :495)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.HibernatePacka geHandler.writePackages(HibernatePackageHandler.java:136)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.writePackages(HibernateStoreWriter.java:157)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.commit(HibernateStoreWriter.java:56)
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:179)
> at
>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
> at
>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> Can it be that your code does not cover this case where a type in a
> package is referred to in the meta-sense, but there is no reference
> (yet) instance-wise?
> Cheers,
> Stefan
> P.S. I'm working with HEAD of yesterday.
> Eike Stepper schrieb:
>> Hi Eric,
>>
>> I recently changed the code to better handle nested packages. Are you
>> using the latest CVS sources? It should work with them...
>>
>> Cheers
>> /Eike
>>
>>
>> Eric wrote:
>>
>>> Hi Eike,
>>
>>> I've come across a problem when dealing with an Ecore file
>>> containing multiple packages.
>>
>>> Ecore file:
>>> Package1:
>>> ClassA [has an attribute of type ClassD]
>>> ClassB
>>> Package2:
>>> ClassC
>>> ClassD
>>
>>> In my client, I register both packages (A & B) with my session's
>>> package registry. I then create an object of type ClassA, but I
>>> don't set (leave it as null) its attribute of type ClassD.
>>
>>> When CDO reaches the server side at commit time, I only see Package1
>>> being transfered over and since ClassA references Package2 through an
>>> attribute of ClassD, I get an exception:
>>
>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>> at
>>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>
>>> If I take the same code and create an object of type ClassC (or any
>>> object from Package2) and add this object to my resource, Package2
>>> will get transfered over and my test will work. So in order to see
>>> your package on the server side, you need to:
>>> 1. Register it
>>> 2. Create at least one object from that package
>>
>>> Problem is that object of type ClassA references Package2. So when
>>> deciding which package need to be transfered, CDO will have to do a
>>> deep scan of the object instead of only using its containingPackage
>>> (this is how I assume CDO works, correct me if I'm wrong).
>>
>>> Any thoughts?
>>> Eric
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #121985 is a reply to message #121948] |
Tue, 06 May 2008 13:19 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050002020408050607040102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Eike,
filed Bug 230387 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=230387>
about this issue. Testcase included.
newPackages.length=1 and contains only package "reference" and not
"interface" as it should ...
Cheers,
Stefan
Eike Stepper schrieb:
> Hi Stefan,
>
> Hard to say at once where the root cause is. Theoretically one of
> three areas:
> 1) Determination of the set of packages that need to be persisted for
> a given class.
> 2) (De-)Serialization of the 1) set.
> 3) Usage of the Deserialized data in the Hibernate Store.
>
> Personally I don't believe that it is related to 1).
> It might well be 2) because that one is not easy (although I have test
> cases to cover this).
> For 3) we will have to ask Martin...
>
> Can you please open a new bugzilla to track this issue?
>
> Cheers
> /Eike
>
>
>
> Stefan Winkler wrote:
>
>> Hi Eike,
>
>> I can reproduce the problem of Eric in similar but different setting.
>
>> If two packages are defined in different .ecore files, CDOClassRef
>> can not be resolved:
>
>> interface.ecore:
>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="interface"
>> nsURI="uuid://interface" nsPrefix="interface">
>> <eClassifiers xsi:type="ecore:EClass" name="IInterface"
>> abstract="true" interface="true">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="test"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> </ecore:EPackage>
>
>
>> reference.ecore:
>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="reference"
>> nsURI="uuid://reference" nsPrefix="reference">
>> <eClassifiers xsi:type="ecore:EClass" name="Reference">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="ref"
>> eType="ecore:EClass interface.ecore#//IInterface"/>
>> </eClassifiers>
>> </ecore:EPackage>
>
>
>> common init code:
>
>> IManagedContainer container = IPluginContainer.INSTANCE;
>> acceptor = JVMUtil.getAcceptor(container, "default");
>
>> store = new HibernateStore(new
>> TeneoHibernateMappingProvider());
>
>> Map<String, String> props = new HashMap<String, String>();
>> props.put(Props.PROP_OVERRIDE_UUID,
>> "f8188187-65de-4c8a-8e75-e0ce5949837a");
>> props.put(Props.PROP_SUPPORTING_AUDITS, "false");
>> props.put(Props.PROP_SUPPORTING_REVISION_DELTAS, "false");
>> props.put(Props.PROP_VERIFYING_REVISIONS, "false");
>> props.put(Props.PROP_CURRENT_LRU_CAPACITY, "10000");
>> props.put(Props.PROP_REVISED_LRU_CAPACITY, "10000");
>> props.put(PersistenceOptions.ID_FEATURE_AS_PRIMARY_KEY,
>> "false");
>> props.put("hibernate.connection.autocommit", "true");
>> props.put("hibernate.cache.provider_class",
>> "org.hibernate.cache.HashtableCacheProvider");
>> props.put("hibernate.connection.driver_class",
>> "com.mysql.jdbc.Driver");
>> props.put("hibernate.connection.url",
>> "jdbc:mysql://localhost:3306/" + DB_NAME);
>> props.put("hibernate.connection.username", DB_USER);
>> props.put("hibernate.connection.password", DB_PASS);
>> props.put("hibernate.dialect",
>> "org.hibernate.dialect.MySQLInnoDBDialect");
>
>> props.put("hibernate.hbm2ddl.auto", "update");
>
>> repository =
>> CDOServerUtil.createRepository(repositoryName, store,
>> props);
>
>> CDOServerUtil.addRepository(container, repository);
>
>> connector = JVMUtil.getConnector(container, "default");
>
>> *case 1 (manual package management):*
>
>> session = CDOUtil.openSession(connector, repositoryName,
>> true, false);
>
>> session.getPackageRegistry().putEPackage(InterfacePackage.eI NSTANCE);
>
>> session.getPackageRegistry().putEPackage(ReferencePackage.eI NSTANCE);
>
>> transaction = session.openTransaction();
>
>> resource = transaction.getOrCreateResource(RESOURCE_PATH);
>
>
>> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
>>
>> transaction.commit();
>
>
>> *case 2: (automatic package management):*
>
>> session = CDOUtil.openSession(connector, repositoryName,
>> true, true);
>> transaction = session.openTransaction();
>
>> resource = transaction.getOrCreateResource(RESOURCE_PATH);
>
>
>> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
>>
>> // note: the feature ref of the created reference is null!
>> transaction.commit();
>
>> Both cases result in java.lang.IllegalStateException: Unable to
>> resolve class ref: CDOClassRef(uuid://interface, 0)
>
>> Exception for both cases:
>
>> [ERROR] Unable to resolve class ref: CDOClassRef(uuid://interface, 0)
>> java.lang.IllegalStateException: Unable to resolve class ref:
>> CDOClassRef(uuid://interface, 0)
>> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOClassProxy.ge tCdoClass(CDOClassProxy.java:71)
>
>> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOFeatureImpl.g etReferenceType(CDOFeatureImpl.java:243)
>
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.tuplizer.CDOFe atureReferenceTypePropertyHandler.get(CDOFeatureReferenceTyp ePropertyHandler.java:58)
>
>> at
> org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropert yValue(AbstractEntityTuplizer.java:277)
>
>> at
> org.hibernate.persister.entity.AbstractEntityPersister.getPr opertyValue(AbstractEntityPersister.java:3586)
>
>> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
>> at
> org.hibernate.event.def.AbstractSaveEventListener.cascadeBef oreSave(AbstractSaveEventListener.java:431)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:265)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
>> at
>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
>> at
>> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
>> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at
>> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
>> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
>> at
> org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
>> at
>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
>> at
>> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
>> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at
>> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
>> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
>> at
> org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
>> at
>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :495)
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.HibernatePacka geHandler.writePackages(HibernatePackageHandler.java:136)
>
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.writePackages(HibernateStoreWriter.java:157)
>
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.commit(HibernateStoreWriter.java:56)
>
>> at
>> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:179)
>>
>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
>> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
>
>> Can it be that your code does not cover this case where a type in a
>> package is referred to in the meta-sense, but there is no reference
>> (yet) instance-wise?
>
>> Cheers,
>> Stefan
>
>> P.S. I'm working with HEAD of yesterday.
>
>
>> Eike Stepper schrieb:
>>> Hi Eric,
>>>
>>> I recently changed the code to better handle nested packages. Are
>>> you using the latest CVS sources? It should work with them...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eric wrote:
>>>
>>>> Hi Eike,
>>>
>>>> I've come across a problem when dealing with an Ecore file
>>>> containing multiple packages.
>>>
>>>> Ecore file:
>>>> Package1:
>>>> ClassA [has an attribute of type ClassD]
>>>> ClassB
>>>> Package2:
>>>> ClassC
>>>> ClassD
>>>
>>>> In my client, I register both packages (A & B) with my session's
>>>> package registry. I then create an object of type ClassA, but I
>>>> don't set (leave it as null) its attribute of type ClassD.
>>>
>>>> When CDO reaches the server side at commit time, I only see
>>>> Package1 being transfered over and since ClassA references Package2
>>>> through an attribute of ClassD, I get an exception:
>>>
>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>> at
>>>
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>>>
>>>
>>>> If I take the same code and create an object of type ClassC (or any
>>>> object from Package2) and add this object to my resource, Package2
>>>> will get transfered over and my test will work. So in order to see
>>>> your package on the server side, you need to:
>>>> 1. Register it
>>>> 2. Create at least one object from that package
>>>
>>>> Problem is that object of type ClassA references Package2. So when
>>>> deciding which package need to be transfered, CDO will have to do a
>>>> deep scan of the object instead of only using its containingPackage
>>>> (this is how I assume CDO works, correct me if I'm wrong).
>>>
>>>> Any thoughts?
>>>> Eric
>>>
>>>
>
>
--------------050002020408050607040102
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eike,<br>
<br>
filed
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617964 is a reply to message #120722] |
Wed, 30 April 2008 16:28 |
|
Hi Eric,
I recently changed the code to better handle nested packages. Are you
using the latest CVS sources? It should work with them...
Cheers
/Eike
Eric wrote:
> Hi Eike,
> I've come across a problem when dealing with an Ecore file containing
> multiple packages.
> Ecore file:
> Package1:
> ClassA [has an attribute of type ClassD]
> ClassB
> Package2:
> ClassC
> ClassD
> In my client, I register both packages (A & B) with my session's package
> registry. I then create an object of type ClassA, but I don't set
> (leave it as null) its attribute of type ClassD.
> When CDO reaches the server side at commit time, I only see Package1
> being transfered over and since ClassA references Package2 through an
> attribute of ClassD, I get an exception:
> Unable to resolve classref: CDOClassRef(Package2, ...)
> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
> at
>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
> If I take the same code and create an object of type ClassC (or any
> object from Package2) and add this object to my resource, Package2 will
> get transfered over and my test will work. So in order to see your
> package on the server side, you need to:
> 1. Register it
> 2. Create at least one object from that package
> Problem is that object of type ClassA references Package2. So when
> deciding which package need to be transfered, CDO will have to do a deep
> scan of the object instead of only using its containingPackage (this is
> how I assume CDO works, correct me if I'm wrong).
> Any thoughts?
> Eric
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617968 is a reply to message #120735] |
Wed, 30 April 2008 19:00 |
Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Hi Eike,
I've tried with the latest code and I have the same result. But I
know why it doesn't work. The problem is the common parent package for
Package1 & Package2 doesn't exist because it is not generated by the
genmodel. I have modified my Ecore file:
PackageRoot
ClassRoot
Package1
ClassA, ClassB
Package2
ClassC, ClassD
So now I have a common root package and it is created by my genmodel
since I have one class (ClassRoot) under this package. Because of this
new package, your code in CDOTransactionImpl.analyzeNewPackages() will
crawl to the top level package (PackageRoot), put it in the newpackages
collection and send it to the server. Now the server is aware of
PackageRoot and its children packages (Package1 & Package2).
The problem with the actual code is that it won't pick up any parent
packages that are not generated by genmodel. I don't know if there is
an option to generate code for empty packages (packages not holding
classes directly)... Another problem that could arise is basically the
situation I explained in my previous message:
Two root packages cross-referencing each other. If you don't persist an
object for each of those 2 packages, only 1 package will be flagged as
'new' and only this one will be transfered to the server.
Do you understand what I'm trying to explain here?
Eric
Eike Stepper wrote:
> Hi Eric,
>
> I recently changed the code to better handle nested packages. Are you
> using the latest CVS sources? It should work with them...
>
> Cheers
> /Eike
>
>
> Eric wrote:
>
>> Hi Eike,
>
>> I've come across a problem when dealing with an Ecore file
>> containing multiple packages.
>
>> Ecore file:
>> Package1:
>> ClassA [has an attribute of type ClassD]
>> ClassB
>> Package2:
>> ClassC
>> ClassD
>
>> In my client, I register both packages (A & B) with my session's
>> package registry. I then create an object of type ClassA, but I don't
>> set (leave it as null) its attribute of type ClassD.
>
>> When CDO reaches the server side at commit time, I only see Package1
>> being transfered over and since ClassA references Package2 through an
>> attribute of ClassD, I get an exception:
>
>> Unable to resolve classref: CDOClassRef(Package2, ...)
>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>> at
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>
>> If I take the same code and create an object of type ClassC (or any
>> object from Package2) and add this object to my resource, Package2
>> will get transfered over and my test will work. So in order to see
>> your package on the server side, you need to:
>> 1. Register it
>> 2. Create at least one object from that package
>
>> Problem is that object of type ClassA references Package2. So when
>> deciding which package need to be transfered, CDO will have to do a
>> deep scan of the object instead of only using its containingPackage
>> (this is how I assume CDO works, correct me if I'm wrong).
>
>> Any thoughts?
>> Eric
>
>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617969 is a reply to message #120754] |
Wed, 30 April 2008 19:15 |
Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Eike,
I've tried adding multiple root packages to an Ecore file and you
can't. So the last part of my previous message doesn't apply directly.
You can't have 2 root packages cross-referencing each other. The only
case where this bug will happen is whenever your root package object is
not generated by genmodel.
Eric
Eric wrote:
> Hi Eike,
>
> I've tried with the latest code and I have the same result. But I
> know why it doesn't work. The problem is the common parent package for
> Package1 & Package2 doesn't exist because it is not generated by the
> genmodel. I have modified my Ecore file:
> PackageRoot
> ClassRoot
> Package1
> ClassA, ClassB
> Package2
> ClassC, ClassD
>
> So now I have a common root package and it is created by my genmodel
> since I have one class (ClassRoot) under this package. Because of this
> new package, your code in CDOTransactionImpl.analyzeNewPackages() will
> crawl to the top level package (PackageRoot), put it in the newpackages
> collection and send it to the server. Now the server is aware of
> PackageRoot and its children packages (Package1 & Package2).
>
> The problem with the actual code is that it won't pick up any parent
> packages that are not generated by genmodel. I don't know if there is
> an option to generate code for empty packages (packages not holding
> classes directly)... Another problem that could arise is basically the
> situation I explained in my previous message:
> Two root packages cross-referencing each other. If you don't persist an
> object for each of those 2 packages, only 1 package will be flagged as
> 'new' and only this one will be transfered to the server.
>
> Do you understand what I'm trying to explain here?
>
> Eric
>
> Eike Stepper wrote:
>> Hi Eric,
>>
>> I recently changed the code to better handle nested packages. Are you
>> using the latest CVS sources? It should work with them...
>>
>> Cheers
>> /Eike
>>
>>
>> Eric wrote:
>>
>>> Hi Eike,
>>
>>> I've come across a problem when dealing with an Ecore file
>>> containing multiple packages.
>>
>>> Ecore file:
>>> Package1:
>>> ClassA [has an attribute of type ClassD]
>>> ClassB
>>> Package2:
>>> ClassC
>>> ClassD
>>
>>> In my client, I register both packages (A & B) with my session's
>>> package registry. I then create an object of type ClassA, but I
>>> don't set (leave it as null) its attribute of type ClassD.
>>
>>> When CDO reaches the server side at commit time, I only see Package1
>>> being transfered over and since ClassA references Package2 through an
>>> attribute of ClassD, I get an exception:
>>
>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>> at
>> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>
>>> If I take the same code and create an object of type ClassC (or any
>>> object from Package2) and add this object to my resource, Package2
>>> will get transfered over and my test will work. So in order to see
>>> your package on the server side, you need to:
>>> 1. Register it
>>> 2. Create at least one object from that package
>>
>>> Problem is that object of type ClassA references Package2. So when
>>> deciding which package need to be transfered, CDO will have to do a
>>> deep scan of the object instead of only using its containingPackage
>>> (this is how I assume CDO works, correct me if I'm wrong).
>>
>>> Any thoughts?
>>> Eric
>>
>>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617976 is a reply to message #120757] |
Thu, 01 May 2008 13:27 |
|
Eric wrote:
> Eike,
> I've tried adding multiple root packages to an Ecore file and you
> can't. So the last part of my previous message doesn't apply directly.
> You can't have 2 root packages cross-referencing each other.
That's what I thought ;-)
> The only
> case where this bug will happen is whenever your root package object is
> not generated by genmodel.
Why should one want that? What would happen if you ask the subPackages for
their ESuperPackage? I would consider this a inconsistent but I really
never thought about this before. What do others think? Ed, are you
listening (can't cc you through the web UI)?
Cheers
/Eike
> Eric
> Eric wrote:
>> Hi Eike,
>>
>> I've tried with the latest code and I have the same result. But I
>> know why it doesn't work. The problem is the common parent package for
>> Package1 & Package2 doesn't exist because it is not generated by the
>> genmodel. I have modified my Ecore file:
>> PackageRoot
>> ClassRoot
>> Package1
>> ClassA, ClassB
>> Package2
>> ClassC, ClassD
>>
>> So now I have a common root package and it is created by my genmodel
>> since I have one class (ClassRoot) under this package. Because of this
>> new package, your code in CDOTransactionImpl.analyzeNewPackages() will
>> crawl to the top level package (PackageRoot), put it in the newpackages
>> collection and send it to the server. Now the server is aware of
>> PackageRoot and its children packages (Package1 & Package2).
>>
>> The problem with the actual code is that it won't pick up any parent
>> packages that are not generated by genmodel. I don't know if there is
>> an option to generate code for empty packages (packages not holding
>> classes directly)... Another problem that could arise is basically the
>> situation I explained in my previous message:
>> Two root packages cross-referencing each other. If you don't persist an
>> object for each of those 2 packages, only 1 package will be flagged as
>> 'new' and only this one will be transfered to the server.
>>
>> Do you understand what I'm trying to explain here?
>>
>> Eric
>>
>> Eike Stepper wrote:
>>> Hi Eric,
>>>
>>> I recently changed the code to better handle nested packages. Are you
>>> using the latest CVS sources? It should work with them...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eric wrote:
>>>
>>>> Hi Eike,
>>>
>>>> I've come across a problem when dealing with an Ecore file
>>>> containing multiple packages.
>>>
>>>> Ecore file:
>>>> Package1:
>>>> ClassA [has an attribute of type ClassD]
>>>> ClassB
>>>> Package2:
>>>> ClassC
>>>> ClassD
>>>
>>>> In my client, I register both packages (A & B) with my session's
>>>> package registry. I then create an object of type ClassA, but I
>>>> don't set (leave it as null) its attribute of type ClassD.
>>>
>>>> When CDO reaches the server side at commit time, I only see Package1
>>>> being transfered over and since ClassA references Package2 through an
>>>> attribute of ClassD, I get an exception:
>>>
>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>> at
>>>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>>
>>>
>>>> If I take the same code and create an object of type ClassC (or any
>>>> object from Package2) and add this object to my resource, Package2
>>>> will get transfered over and my test will work. So in order to see
>>>> your package on the server side, you need to:
>>>> 1. Register it
>>>> 2. Create at least one object from that package
>>>
>>>> Problem is that object of type ClassA references Package2. So when
>>>> deciding which package need to be transfered, CDO will have to do a
>>>> deep scan of the object instead of only using its containingPackage
>>>> (this is how I assume CDO works, correct me if I'm wrong).
>>>
>>>> Any thoughts?
>>>> Eric
>>>
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617977 is a reply to message #121639] |
Thu, 01 May 2008 13:59 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010608080303000109020300
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Comments below.
Eike Stepper wrote:
> Eric wrote:
>
>> Eike,
>
>> I've tried adding multiple root packages to an Ecore file and you
>> can't. So the last part of my previous message doesn't apply
>> directly. You can't have 2 root packages cross-referencing each
>> other.
>
> That's what I thought ;-)
The editor doesn't support multiple roots in a .ecore resource and
likely some of the tools won't be expecting that either. You can have
two packages cross referencing each other, but you'll need to generate
them with a single GenModel.
>
>> The only case where this bug will happen is whenever your root
>> package object is not generated by genmodel.
>
> Why should one want that? What would happen if you ask the subPackages
> for their ESuperPackage? I would consider this a inconsistent but I
> really never thought about this before. What do others think? Ed, are
> you listening (can't cc you through the web UI)?
You should use Thunderbird; it will improve your newsgroup experience a
thousand fold. Not sure if 142856
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any bearings
on the situation? What's the question? :-P (I wish there was no such
thing as subpackages.)
>
> Cheers
> /Eike
>
>
>
>> Eric
>
>
>> Eric wrote:
>>> Hi Eike,
>>>
>>> I've tried with the latest code and I have the same result. But I
>>> know why it doesn't work. The problem is the common parent package
>>> for Package1 & Package2 doesn't exist because it is not generated by
>>> the genmodel. I have modified my Ecore file:
>>> PackageRoot
>>> ClassRoot
>>> Package1
>>> ClassA, ClassB
>>> Package2
>>> ClassC, ClassD
>>>
>>> So now I have a common root package and it is created by my genmodel
>>> since I have one class (ClassRoot) under this package. Because of
>>> this new package, your code in
>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top level
>>> package (PackageRoot), put it in the newpackages collection and send
>>> it to the server. Now the server is aware of PackageRoot and its
>>> children packages (Package1 & Package2).
>>>
>>> The problem with the actual code is that it won't pick up any parent
>>> packages that are not generated by genmodel. I don't know if there
>>> is an option to generate code for empty packages (packages not
>>> holding classes directly)... Another problem that could arise is
>>> basically the situation I explained in my previous message:
>>> Two root packages cross-referencing each other. If you don't
>>> persist an object for each of those 2 packages, only 1 package will
>>> be flagged as 'new' and only this one will be transfered to the server.
>>>
>>> Do you understand what I'm trying to explain here?
>>>
>>> Eric
>>>
>>> Eike Stepper wrote:
>>>> Hi Eric,
>>>>
>>>> I recently changed the code to better handle nested packages. Are
>>>> you using the latest CVS sources? It should work with them...
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Eric wrote:
>>>>
>>>>> Hi Eike,
>>>>
>>>>> I've come across a problem when dealing with an Ecore file
>>>>> containing multiple packages.
>>>>
>>>>> Ecore file:
>>>>> Package1:
>>>>> ClassA [has an attribute of type ClassD]
>>>>> ClassB
>>>>> Package2:
>>>>> ClassC
>>>>> ClassD
>>>>
>>>>> In my client, I register both packages (A & B) with my session's
>>>>> package registry. I then create an object of type ClassA, but I
>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>
>>>>> When CDO reaches the server side at commit time, I only see
>>>>> Package1 being transfered over and since ClassA references
>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>
>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>> at
>>>>
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>>>>
>>>>
>>>>> If I take the same code and create an object of type ClassC (or
>>>>> any object from Package2) and add this object to my resource,
>>>>> Package2 will get transfered over and my test will work. So in
>>>>> order to see your package on the server side, you need to:
>>>>> 1. Register it
>>>>> 2. Create at least one object from that package
>>>>
>>>>> Problem is that object of type ClassA references Package2. So
>>>>> when deciding which package need to be transfered, CDO will have
>>>>> to do a deep scan of the object instead of only using its
>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>> I'm wrong).
>>>>
>>>>> Any thoughts?
>>>>> Eric
>>>>
>>>>
>
>
--------------010608080303000109020300
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Comments below.<br>
<br>
Eike Stepper wrote:
<blockquote
cite="mid:8a996694bf5626b7def3fe7a63f4ce6d$1@www.eclipse.org"
type="cite">Eric wrote:
<br>
<br>
<blockquote type="cite">Eike,
<br>
</blockquote>
<br>
<blockquote type="cite">
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617978 is a reply to message #121653] |
Thu, 01 May 2008 14:30 |
Eric
Messages: 40
Registered: July 2009 |
Member |
|
|
Ed, I had a look at the Bugzilla entry and it seems to be related to our
problem. We have a workaround (we now have at least one type under the
root package), but is this bug planned to be fixed eventually?
Thanks,
Eric
Ed Merks wrote:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>> Eric wrote:
>>
>>> Eike,
>>
>>> I've tried adding multiple root packages to an Ecore file and you
>>> can't. So the last part of my previous message doesn't apply
>>> directly. You can't have 2 root packages cross-referencing each
>>> other.
>>
>> That's what I thought ;-)
> The editor doesn't support multiple roots in a .ecore resource and
> likely some of the tools won't be expecting that either. You can have
> two packages cross referencing each other, but you'll need to generate
> them with a single GenModel.
>>
>>> The only case where this bug will happen is whenever your root
>>> package object is not generated by genmodel.
>>
>> Why should one want that? What would happen if you ask the subPackages
>> for their ESuperPackage? I would consider this a inconsistent but I
>> really never thought about this before. What do others think? Ed, are
>> you listening (can't cc you through the web UI)?
> You should use Thunderbird; it will improve your newsgroup experience a
> thousand fold. Not sure if 142856
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any bearings
> on the situation? What's the question? :-P (I wish there was no such
> thing as subpackages.)
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Eric
>>
>>
>>> Eric wrote:
>>>> Hi Eike,
>>>>
>>>> I've tried with the latest code and I have the same result. But I
>>>> know why it doesn't work. The problem is the common parent package
>>>> for Package1 & Package2 doesn't exist because it is not generated by
>>>> the genmodel. I have modified my Ecore file:
>>>> PackageRoot
>>>> ClassRoot
>>>> Package1
>>>> ClassA, ClassB
>>>> Package2
>>>> ClassC, ClassD
>>>>
>>>> So now I have a common root package and it is created by my genmodel
>>>> since I have one class (ClassRoot) under this package. Because of
>>>> this new package, your code in
>>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top level
>>>> package (PackageRoot), put it in the newpackages collection and send
>>>> it to the server. Now the server is aware of PackageRoot and its
>>>> children packages (Package1 & Package2).
>>>>
>>>> The problem with the actual code is that it won't pick up any parent
>>>> packages that are not generated by genmodel. I don't know if there
>>>> is an option to generate code for empty packages (packages not
>>>> holding classes directly)... Another problem that could arise is
>>>> basically the situation I explained in my previous message:
>>>> Two root packages cross-referencing each other. If you don't
>>>> persist an object for each of those 2 packages, only 1 package will
>>>> be flagged as 'new' and only this one will be transfered to the server.
>>>>
>>>> Do you understand what I'm trying to explain here?
>>>>
>>>> Eric
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I recently changed the code to better handle nested packages. Are
>>>>> you using the latest CVS sources? It should work with them...
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Eric wrote:
>>>>>
>>>>>> Hi Eike,
>>>>>
>>>>>> I've come across a problem when dealing with an Ecore file
>>>>>> containing multiple packages.
>>>>>
>>>>>> Ecore file:
>>>>>> Package1:
>>>>>> ClassA [has an attribute of type ClassD]
>>>>>> ClassB
>>>>>> Package2:
>>>>>> ClassC
>>>>>> ClassD
>>>>>
>>>>>> In my client, I register both packages (A & B) with my session's
>>>>>> package registry. I then create an object of type ClassA, but I
>>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>>
>>>>>> When CDO reaches the server side at commit time, I only see
>>>>>> Package1 being transfered over and since ClassA references
>>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>>
>>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>>> at
>>>>>
>> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>>>>
>>>>>
>>>>>> If I take the same code and create an object of type ClassC (or
>>>>>> any object from Package2) and add this object to my resource,
>>>>>> Package2 will get transfered over and my test will work. So in
>>>>>> order to see your package on the server side, you need to:
>>>>>> 1. Register it
>>>>>> 2. Create at least one object from that package
>>>>>
>>>>>> Problem is that object of type ClassA references Package2. So
>>>>>> when deciding which package need to be transfered, CDO will have
>>>>>> to do a deep scan of the object instead of only using its
>>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>>> I'm wrong).
>>>>>
>>>>>> Any thoughts?
>>>>>> Eric
>>>>>
>>>>>
>>
>>
>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617979 is a reply to message #121666] |
Thu, 01 May 2008 14:58 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Eric,
We have an awful lot of feature requests accumulating. With a shrinking
team, it's difficult to know when we can get to any particular one of
these things... Given the workaround (add an EDataType) is quite
simple, that tends to make it seem less important in the grand scheme of
things...
Eric wrote:
> Ed, I had a look at the Bugzilla entry and it seems to be related to
> our problem. We have a workaround (we now have at least one type
> under the root package), but is this bug planned to be fixed eventually?
>
> Thanks,
> Eric
>
> Ed Merks wrote:
>> Eike,
>>
>> Comments below.
>>
>> Eike Stepper wrote:
>>> Eric wrote:
>>>
>>>> Eike,
>>>
>>>> I've tried adding multiple root packages to an Ecore file and
>>>> you can't. So the last part of my previous message doesn't apply
>>>> directly. You can't have 2 root packages cross-referencing each
>>>> other.
>>>
>>> That's what I thought ;-)
>> The editor doesn't support multiple roots in a .ecore resource and
>> likely some of the tools won't be expecting that either. You can
>> have two packages cross referencing each other, but you'll need to
>> generate them with a single GenModel.
>>>
>>>> The only case where this bug will happen is whenever your root
>>>> package object is not generated by genmodel.
>>>
>>> Why should one want that? What would happen if you ask the
>>> subPackages for their ESuperPackage? I would consider this a
>>> inconsistent but I really never thought about this before. What do
>>> others think? Ed, are you listening (can't cc you through the web UI)?
>> You should use Thunderbird; it will improve your newsgroup experience
>> a thousand fold. Not sure if 142856
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any
>> bearings on the situation? What's the question? :-P (I wish there
>> was no such thing as subpackages.)
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>>> Eric
>>>
>>>
>>>> Eric wrote:
>>>>> Hi Eike,
>>>>>
>>>>> I've tried with the latest code and I have the same result. But
>>>>> I know why it doesn't work. The problem is the common parent
>>>>> package for Package1 & Package2 doesn't exist because it is not
>>>>> generated by the genmodel. I have modified my Ecore file:
>>>>> PackageRoot
>>>>> ClassRoot
>>>>> Package1
>>>>> ClassA, ClassB
>>>>> Package2
>>>>> ClassC, ClassD
>>>>>
>>>>> So now I have a common root package and it is created by my
>>>>> genmodel since I have one class (ClassRoot) under this package.
>>>>> Because of this new package, your code in
>>>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top
>>>>> level package (PackageRoot), put it in the newpackages collection
>>>>> and send it to the server. Now the server is aware of PackageRoot
>>>>> and its children packages (Package1 & Package2).
>>>>>
>>>>> The problem with the actual code is that it won't pick up any
>>>>> parent packages that are not generated by genmodel. I don't know
>>>>> if there is an option to generate code for empty packages
>>>>> (packages not holding classes directly)... Another problem that
>>>>> could arise is basically the situation I explained in my previous
>>>>> message:
>>>>> Two root packages cross-referencing each other. If you don't
>>>>> persist an object for each of those 2 packages, only 1 package
>>>>> will be flagged as 'new' and only this one will be transfered to
>>>>> the server.
>>>>>
>>>>> Do you understand what I'm trying to explain here?
>>>>>
>>>>> Eric
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> I recently changed the code to better handle nested packages. Are
>>>>>> you using the latest CVS sources? It should work with them...
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Eric wrote:
>>>>>>
>>>>>>> Hi Eike,
>>>>>>
>>>>>>> I've come across a problem when dealing with an Ecore file
>>>>>>> containing multiple packages.
>>>>>>
>>>>>>> Ecore file:
>>>>>>> Package1:
>>>>>>> ClassA [has an attribute of type ClassD]
>>>>>>> ClassB
>>>>>>> Package2:
>>>>>>> ClassC
>>>>>>> ClassD
>>>>>>
>>>>>>> In my client, I register both packages (A & B) with my session's
>>>>>>> package registry. I then create an object of type ClassA, but I
>>>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>>>
>>>>>>> When CDO reaches the server side at commit time, I only see
>>>>>>> Package1 being transfered over and since ClassA references
>>>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>>>
>>>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>>>> at
>>>>>>
>>> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>>
>>>>>>
>>>>>>
>>>>>>> If I take the same code and create an object of type ClassC (or
>>>>>>> any object from Package2) and add this object to my resource,
>>>>>>> Package2 will get transfered over and my test will work. So in
>>>>>>> order to see your package on the server side, you need to:
>>>>>>> 1. Register it
>>>>>>> 2. Create at least one object from that package
>>>>>>
>>>>>>> Problem is that object of type ClassA references Package2. So
>>>>>>> when deciding which package need to be transfered, CDO will have
>>>>>>> to do a deep scan of the object instead of only using its
>>>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>>>> I'm wrong).
>>>>>>
>>>>>>> Any thoughts?
>>>>>>> Eric
>>>>>>
>>>>>>
>>>
>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617980 is a reply to message #121653] |
Thu, 01 May 2008 14:58 |
|
Ed Merks wrote:
> Eike,
> Comments below.
> Eike Stepper wrote:
>> Eric wrote:
>>
>>> Eike,
>>
>>> I've tried adding multiple root packages to an Ecore file and you
>>> can't. So the last part of my previous message doesn't apply
>>> directly. You can't have 2 root packages cross-referencing each
>>> other.
>>
>> That's what I thought ;-)
> The editor doesn't support multiple roots in a .ecore resource and
> likely some of the tools won't be expecting that either. You can have
> two packages cross referencing each other, but you'll need to generate
> them with a single GenModel.
I feared that there's such thing ;-)
>>> The only case where this bug will happen is whenever your root
>>> package object is not generated by genmodel.
>>
>> Why should one want that? What would happen if you ask the subPackages
>> for their ESuperPackage? I would consider this a inconsistent but I
>> really never thought about this before. What do others think? Ed, are
>> you listening (can't cc you through the web UI)?
> You should use Thunderbird; it will improve your newsgroup experience a
> thousand fold.
Usually I do, but my customer is too restrictive with his firewall ;-(
> Not sure if 142856
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856> has any bearings
> on the situation? What's the question? :-P (I wish there was no such
> thing as subpackages.)
Yes, that's what I always thought and I never used them myself!
And yes, the Bugzilla seems to address Eric's issue so I voted for it
(Eric!) ;-)
Enjoy
/Eike
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Eric
>>
>>
>>> Eric wrote:
>>>> Hi Eike,
>>>>
>>>> I've tried with the latest code and I have the same result. But I
>>>> know why it doesn't work. The problem is the common parent package
>>>> for Package1 & Package2 doesn't exist because it is not generated by
>>>> the genmodel. I have modified my Ecore file:
>>>> PackageRoot
>>>> ClassRoot
>>>> Package1
>>>> ClassA, ClassB
>>>> Package2
>>>> ClassC, ClassD
>>>>
>>>> So now I have a common root package and it is created by my genmodel
>>>> since I have one class (ClassRoot) under this package. Because of
>>>> this new package, your code in
>>>> CDOTransactionImpl.analyzeNewPackages() will crawl to the top level
>>>> package (PackageRoot), put it in the newpackages collection and send
>>>> it to the server. Now the server is aware of PackageRoot and its
>>>> children packages (Package1 & Package2).
>>>>
>>>> The problem with the actual code is that it won't pick up any parent
>>>> packages that are not generated by genmodel. I don't know if there
>>>> is an option to generate code for empty packages (packages not
>>>> holding classes directly)... Another problem that could arise is
>>>> basically the situation I explained in my previous message:
>>>> Two root packages cross-referencing each other. If you don't
>>>> persist an object for each of those 2 packages, only 1 package will
>>>> be flagged as 'new' and only this one will be transfered to the server.
>>>>
>>>> Do you understand what I'm trying to explain here?
>>>>
>>>> Eric
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I recently changed the code to better handle nested packages. Are
>>>>> you using the latest CVS sources? It should work with them...
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Eric wrote:
>>>>>
>>>>>> Hi Eike,
>>>>>
>>>>>> I've come across a problem when dealing with an Ecore file
>>>>>> containing multiple packages.
>>>>>
>>>>>> Ecore file:
>>>>>> Package1:
>>>>>> ClassA [has an attribute of type ClassD]
>>>>>> ClassB
>>>>>> Package2:
>>>>>> ClassC
>>>>>> ClassD
>>>>>
>>>>>> In my client, I register both packages (A & B) with my session's
>>>>>> package registry. I then create an object of type ClassA, but I
>>>>>> don't set (leave it as null) its attribute of type ClassD.
>>>>>
>>>>>> When CDO reaches the server side at commit time, I only see
>>>>>> Package1 being transfered over and since ClassA references
>>>>>> Package2 through an attribute of ClassD, I get an exception:
>>>>>
>>>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>>>> at
>>>>>
>>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>>>>
>>>>>
>>>>>> If I take the same code and create an object of type ClassC (or
>>>>>> any object from Package2) and add this object to my resource,
>>>>>> Package2 will get transfered over and my test will work. So in
>>>>>> order to see your package on the server side, you need to:
>>>>>> 1. Register it
>>>>>> 2. Create at least one object from that package
>>>>>
>>>>>> Problem is that object of type ClassA references Package2. So
>>>>>> when deciding which package need to be transfered, CDO will have
>>>>>> to do a deep scan of the object instead of only using its
>>>>>> containingPackage (this is how I assume CDO works, correct me if
>>>>>> I'm wrong).
>>>>>
>>>>>> Any thoughts?
>>>>>> Eric
>>>>>
>>>>>
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617995 is a reply to message #120735] |
Tue, 06 May 2008 10:18 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040805000202090709040803
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Eike,
I can reproduce the problem of Eric in similar but different setting.
If two packages are defined in different .ecore files, CDOClassRef can
not be resolved:
interface.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="interface"
nsURI="uuid://interface" nsPrefix="interface">
<eClassifiers xsi:type="ecore:EClass" name="IInterface"
abstract="true" interface="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="test"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
</ecore:EPackage>
reference.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="reference"
nsURI="uuid://reference" nsPrefix="reference">
<eClassifiers xsi:type="ecore:EClass" name="Reference">
<eStructuralFeatures xsi:type="ecore:EReference" name="ref"
eType="ecore:EClass interface.ecore#//IInterface"/>
</eClassifiers>
</ecore:EPackage>
common init code:
IManagedContainer container = IPluginContainer.INSTANCE;
acceptor = JVMUtil.getAcceptor(container, "default");
store = new HibernateStore(new TeneoHibernateMappingProvider());
Map<String, String> props = new HashMap<String, String>();
props.put(Props.PROP_OVERRIDE_UUID,
"f8188187-65de-4c8a-8e75-e0ce5949837a");
props.put(Props.PROP_SUPPORTING_AUDITS, "false");
props.put(Props.PROP_SUPPORTING_REVISION_DELTAS, "false");
props.put(Props.PROP_VERIFYING_REVISIONS, "false");
props.put(Props.PROP_CURRENT_LRU_CAPACITY, "10000");
props.put(Props.PROP_REVISED_LRU_CAPACITY, "10000");
props.put(PersistenceOptions.ID_FEATURE_AS_PRIMARY_KEY,
"false");
props.put("hibernate.connection.autocommit", "true");
props.put("hibernate.cache.provider_class",
"org.hibernate.cache.HashtableCacheProvider");
props.put("hibernate.connection.driver_class",
"com.mysql.jdbc.Driver");
props.put("hibernate.connection.url",
"jdbc:mysql://localhost:3306/" + DB_NAME);
props.put("hibernate.connection.username", DB_USER);
props.put("hibernate.connection.password", DB_PASS);
props.put("hibernate.dialect",
"org.hibernate.dialect.MySQLInnoDBDialect");
props.put("hibernate.hbm2ddl.auto", "update");
repository = CDOServerUtil.createRepository(repositoryName,
store,
props);
CDOServerUtil.addRepository(container, repository);
connector = JVMUtil.getConnector(container, "default");
*case 1 (manual package management):*
session = CDOUtil.openSession(connector, repositoryName,
true, false);
session.getPackageRegistry().putEPackage(InterfacePackage.eI NSTANCE);
session.getPackageRegistry().putEPackage(ReferencePackage.eI NSTANCE);
transaction = session.openTransaction();
resource = transaction.getOrCreateResource(RESOURCE_PATH);
resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
transaction.commit();
*case 2: (automatic package management):*
session = CDOUtil.openSession(connector, repositoryName,
true, true);
transaction = session.openTransaction();
resource = transaction.getOrCreateResource(RESOURCE_PATH);
resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
// note: the feature ref of the created reference is null!
transaction.commit();
Both cases result in java.lang.IllegalStateException: Unable to resolve
class ref: CDOClassRef(uuid://interface, 0)
Exception for both cases:
[ERROR] Unable to resolve class ref: CDOClassRef(uuid://interface, 0)
java.lang.IllegalStateException: Unable to resolve class ref:
CDOClassRef(uuid://interface, 0)
at
org.eclipse.emf.cdo.internal.protocol.model.CDOClassProxy.ge tCdoClass(CDOClassProxy.java:71)
at
org.eclipse.emf.cdo.internal.protocol.model.CDOFeatureImpl.g etReferenceType(CDOFeatureImpl.java:243)
at
org.eclipse.emf.cdo.server.internal.hibernate.tuplizer.CDOFe atureReferenceTypePropertyHandler.get(CDOFeatureReferenceTyp ePropertyHandler.java:58)
at
org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropert yValue(AbstractEntityTuplizer.java:277)
at
org.hibernate.persister.entity.AbstractEntityPersister.getPr opertyValue(AbstractEntityPersister.java:3586)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at
org.hibernate.event.def.AbstractSaveEventListener.cascadeBef oreSave(AbstractSaveEventListener.java:431)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:265)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
at
org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at
org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
at
org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at
org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
at
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :495)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernatePacka geHandler.writePackages(HibernatePackageHandler.java:136)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.writePackages(HibernateStoreWriter.java:157)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.commit(HibernateStoreWriter.java:56)
at
org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:179)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
Can it be that your code does not cover this case where a type in a
package is referred to in the meta-sense, but there is no reference
(yet) instance-wise?
Cheers,
Stefan
P.S. I'm working with HEAD of yesterday.
Eike Stepper schrieb:
> Hi Eric,
>
> I recently changed the code to better handle nested packages. Are you
> using the latest CVS sources? It should work with them...
>
> Cheers
> /Eike
>
>
> Eric wrote:
>
>> Hi Eike,
>
>> I've come across a problem when dealing with an Ecore file
>> containing multiple packages.
>
>> Ecore file:
>> Package1:
>> ClassA [has an attribute of type ClassD]
>> ClassB
>> Package2:
>> ClassC
>> ClassD
>
>> In my client, I register both packages (A & B) with my session's
>> package registry. I then create an object of type ClassA, but I
>> don't set (leave it as null) its attribute of type ClassD.
>
>> When CDO reaches the server side at commit time, I only see Package1
>> being transfered over and since ClassA references Package2 through an
>> attribute of ClassD, I get an exception:
>
>> Unable to resolve classref: CDOClassRef(Package2, ...)
>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>> at
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>
>> If I take the same code and create an object of type ClassC (or any
>> object from Package2) and add this object to my resource, Package2
>> will get transfered over and my test will work. So in order to see
>> your package on the server side, you need to:
>> 1. Register it
>> 2. Create at least one object from that package
>
>> Problem is that object of type ClassA references Package2. So when
>> deciding which package need to be transfered, CDO will have to do a
>> deep scan of the object instead of only using its containingPackage
>> (this is how I assume CDO works, correct me if I'm wrong).
>
>> Any thoughts?
>> Eric
>
>
--------------040805000202090709040803
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eike,<br>
<br>
I can reproduce the problem of Eric in similar but different setting.<br>
<br>
If two packages are defined in different .ecore files, CDOClassRef can
not be resolved:<br>
<br>
interface.ecore:<br>
<br>
<tt><?xml version="1.0" encoding="UTF-8"?><br>
<ecore:EPackage xmi:version="2.0"<br>
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #617999 is a reply to message #121896] |
Tue, 06 May 2008 11:39 |
|
Hi Stefan,
Hard to say at once where the root cause is. Theoretically one of three
areas:
1) Determination of the set of packages that need to be persisted for a
given class.
2) (De-)Serialization of the 1) set.
3) Usage of the Deserialized data in the Hibernate Store.
Personally I don't believe that it is related to 1).
It might well be 2) because that one is not easy (although I have test
cases to cover this).
For 3) we will have to ask Martin...
Can you please open a new bugzilla to track this issue?
Cheers
/Eike
Stefan Winkler wrote:
> Hi Eike,
> I can reproduce the problem of Eric in similar but different setting.
> If two packages are defined in different .ecore files, CDOClassRef can
> not be resolved:
> interface.ecore:
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="interface"
> nsURI="uuid://interface" nsPrefix="interface">
> <eClassifiers xsi:type="ecore:EClass" name="IInterface"
> abstract="true" interface="true">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="test"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> </ecore:EPackage>
> reference.ecore:
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="reference"
> nsURI="uuid://reference" nsPrefix="reference">
> <eClassifiers xsi:type="ecore:EClass" name="Reference">
> <eStructuralFeatures xsi:type="ecore:EReference" name="ref"
> eType="ecore:EClass interface.ecore#//IInterface"/>
> </eClassifiers>
> </ecore:EPackage>
> common init code:
> IManagedContainer container = IPluginContainer.INSTANCE;
> acceptor = JVMUtil.getAcceptor(container, "default");
> store = new HibernateStore(new TeneoHibernateMappingProvider());
> Map<String, String> props = new HashMap<String, String>();
> props.put(Props.PROP_OVERRIDE_UUID,
> "f8188187-65de-4c8a-8e75-e0ce5949837a");
> props.put(Props.PROP_SUPPORTING_AUDITS, "false");
> props.put(Props.PROP_SUPPORTING_REVISION_DELTAS, "false");
> props.put(Props.PROP_VERIFYING_REVISIONS, "false");
> props.put(Props.PROP_CURRENT_LRU_CAPACITY, "10000");
> props.put(Props.PROP_REVISED_LRU_CAPACITY, "10000");
> props.put(PersistenceOptions.ID_FEATURE_AS_PRIMARY_KEY,
> "false");
> props.put("hibernate.connection.autocommit", "true");
> props.put("hibernate.cache.provider_class",
> "org.hibernate.cache.HashtableCacheProvider");
> props.put("hibernate.connection.driver_class",
> "com.mysql.jdbc.Driver");
> props.put("hibernate.connection.url",
> "jdbc:mysql://localhost:3306/" + DB_NAME);
> props.put("hibernate.connection.username", DB_USER);
> props.put("hibernate.connection.password", DB_PASS);
> props.put("hibernate.dialect",
> "org.hibernate.dialect.MySQLInnoDBDialect");
> props.put("hibernate.hbm2ddl.auto", "update");
> repository = CDOServerUtil.createRepository(repositoryName,
> store,
> props);
> CDOServerUtil.addRepository(container, repository);
> connector = JVMUtil.getConnector(container, "default");
> *case 1 (manual package management):*
> session = CDOUtil.openSession(connector, repositoryName,
> true, false);
> session.getPackageRegistry().putEPackage(InterfacePackage.eI NSTANCE);
> session.getPackageRegistry().putEPackage(ReferencePackage.eI NSTANCE);
> transaction = session.openTransaction();
> resource = transaction.getOrCreateResource(RESOURCE_PATH);
> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
> transaction.commit();
> *case 2: (automatic package management):*
> session = CDOUtil.openSession(connector, repositoryName,
> true, true);
> transaction = session.openTransaction();
> resource = transaction.getOrCreateResource(RESOURCE_PATH);
> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
> // note: the feature ref of the created reference is null!
> transaction.commit();
> Both cases result in java.lang.IllegalStateException: Unable to resolve
> class ref: CDOClassRef(uuid://interface, 0)
> Exception for both cases:
> [ERROR] Unable to resolve class ref: CDOClassRef(uuid://interface, 0)
> java.lang.IllegalStateException: Unable to resolve class ref:
> CDOClassRef(uuid://interface, 0)
> at
>
org.eclipse.emf.cdo.internal.protocol.model.CDOClassProxy.ge tCdoClass(CDOClassProxy.java:71)
> at
>
org.eclipse.emf.cdo.internal.protocol.model.CDOFeatureImpl.g etReferenceType(CDOFeatureImpl.java:243)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.tuplizer.CDOFe atureReferenceTypePropertyHandler.get(CDOFeatureReferenceTyp ePropertyHandler.java:58)
> at
>
org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropert yValue(AbstractEntityTuplizer.java:277)
> at
>
org.hibernate.persister.entity.AbstractEntityPersister.getPr opertyValue(AbstractEntityPersister.java:3586)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.cascadeBef oreSave(AbstractSaveEventListener.java:431)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:265)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at
> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at
> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at
> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at
> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
> at
>
org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
> at
>
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :495)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.HibernatePacka geHandler.writePackages(HibernatePackageHandler.java:136)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.writePackages(HibernateStoreWriter.java:157)
> at
>
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.commit(HibernateStoreWriter.java:56)
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:179)
> at
>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
> at
>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> Can it be that your code does not cover this case where a type in a
> package is referred to in the meta-sense, but there is no reference
> (yet) instance-wise?
> Cheers,
> Stefan
> P.S. I'm working with HEAD of yesterday.
> Eike Stepper schrieb:
>> Hi Eric,
>>
>> I recently changed the code to better handle nested packages. Are you
>> using the latest CVS sources? It should work with them...
>>
>> Cheers
>> /Eike
>>
>>
>> Eric wrote:
>>
>>> Hi Eike,
>>
>>> I've come across a problem when dealing with an Ecore file
>>> containing multiple packages.
>>
>>> Ecore file:
>>> Package1:
>>> ClassA [has an attribute of type ClassD]
>>> ClassB
>>> Package2:
>>> ClassC
>>> ClassD
>>
>>> In my client, I register both packages (A & B) with my session's
>>> package registry. I then create an object of type ClassA, but I
>>> don't set (leave it as null) its attribute of type ClassD.
>>
>>> When CDO reaches the server side at commit time, I only see Package1
>>> being transfered over and since ClassA references Package2 through an
>>> attribute of ClassD, I get an exception:
>>
>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>> at
>>
CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>>
>>
>>> If I take the same code and create an object of type ClassC (or any
>>> object from Package2) and add this object to my resource, Package2
>>> will get transfered over and my test will work. So in order to see
>>> your package on the server side, you need to:
>>> 1. Register it
>>> 2. Create at least one object from that package
>>
>>> Problem is that object of type ClassA references Package2. So when
>>> deciding which package need to be transfered, CDO will have to do a
>>> deep scan of the object instead of only using its containingPackage
>>> (this is how I assume CDO works, correct me if I'm wrong).
>>
>>> Any thoughts?
>>> Eric
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Problem with single Ecore, multiple packages [message #618002 is a reply to message #121948] |
Tue, 06 May 2008 13:19 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050002020408050607040102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Eike,
filed Bug 230387 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=230387>
about this issue. Testcase included.
newPackages.length=1 and contains only package "reference" and not
"interface" as it should ...
Cheers,
Stefan
Eike Stepper schrieb:
> Hi Stefan,
>
> Hard to say at once where the root cause is. Theoretically one of
> three areas:
> 1) Determination of the set of packages that need to be persisted for
> a given class.
> 2) (De-)Serialization of the 1) set.
> 3) Usage of the Deserialized data in the Hibernate Store.
>
> Personally I don't believe that it is related to 1).
> It might well be 2) because that one is not easy (although I have test
> cases to cover this).
> For 3) we will have to ask Martin...
>
> Can you please open a new bugzilla to track this issue?
>
> Cheers
> /Eike
>
>
>
> Stefan Winkler wrote:
>
>> Hi Eike,
>
>> I can reproduce the problem of Eric in similar but different setting.
>
>> If two packages are defined in different .ecore files, CDOClassRef
>> can not be resolved:
>
>> interface.ecore:
>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="interface"
>> nsURI="uuid://interface" nsPrefix="interface">
>> <eClassifiers xsi:type="ecore:EClass" name="IInterface"
>> abstract="true" interface="true">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="test"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> </ecore:EPackage>
>
>
>> reference.ecore:
>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="reference"
>> nsURI="uuid://reference" nsPrefix="reference">
>> <eClassifiers xsi:type="ecore:EClass" name="Reference">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="ref"
>> eType="ecore:EClass interface.ecore#//IInterface"/>
>> </eClassifiers>
>> </ecore:EPackage>
>
>
>> common init code:
>
>> IManagedContainer container = IPluginContainer.INSTANCE;
>> acceptor = JVMUtil.getAcceptor(container, "default");
>
>> store = new HibernateStore(new
>> TeneoHibernateMappingProvider());
>
>> Map<String, String> props = new HashMap<String, String>();
>> props.put(Props.PROP_OVERRIDE_UUID,
>> "f8188187-65de-4c8a-8e75-e0ce5949837a");
>> props.put(Props.PROP_SUPPORTING_AUDITS, "false");
>> props.put(Props.PROP_SUPPORTING_REVISION_DELTAS, "false");
>> props.put(Props.PROP_VERIFYING_REVISIONS, "false");
>> props.put(Props.PROP_CURRENT_LRU_CAPACITY, "10000");
>> props.put(Props.PROP_REVISED_LRU_CAPACITY, "10000");
>> props.put(PersistenceOptions.ID_FEATURE_AS_PRIMARY_KEY,
>> "false");
>> props.put("hibernate.connection.autocommit", "true");
>> props.put("hibernate.cache.provider_class",
>> "org.hibernate.cache.HashtableCacheProvider");
>> props.put("hibernate.connection.driver_class",
>> "com.mysql.jdbc.Driver");
>> props.put("hibernate.connection.url",
>> "jdbc:mysql://localhost:3306/" + DB_NAME);
>> props.put("hibernate.connection.username", DB_USER);
>> props.put("hibernate.connection.password", DB_PASS);
>> props.put("hibernate.dialect",
>> "org.hibernate.dialect.MySQLInnoDBDialect");
>
>> props.put("hibernate.hbm2ddl.auto", "update");
>
>> repository =
>> CDOServerUtil.createRepository(repositoryName, store,
>> props);
>
>> CDOServerUtil.addRepository(container, repository);
>
>> connector = JVMUtil.getConnector(container, "default");
>
>> *case 1 (manual package management):*
>
>> session = CDOUtil.openSession(connector, repositoryName,
>> true, false);
>
>> session.getPackageRegistry().putEPackage(InterfacePackage.eI NSTANCE);
>
>> session.getPackageRegistry().putEPackage(ReferencePackage.eI NSTANCE);
>
>> transaction = session.openTransaction();
>
>> resource = transaction.getOrCreateResource(RESOURCE_PATH);
>
>
>> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
>>
>> transaction.commit();
>
>
>> *case 2: (automatic package management):*
>
>> session = CDOUtil.openSession(connector, repositoryName,
>> true, true);
>> transaction = session.openTransaction();
>
>> resource = transaction.getOrCreateResource(RESOURCE_PATH);
>
>
>> resource.getContents().add(ReferenceFactory.eINSTANCE.create Reference());
>>
>> // note: the feature ref of the created reference is null!
>> transaction.commit();
>
>> Both cases result in java.lang.IllegalStateException: Unable to
>> resolve class ref: CDOClassRef(uuid://interface, 0)
>
>> Exception for both cases:
>
>> [ERROR] Unable to resolve class ref: CDOClassRef(uuid://interface, 0)
>> java.lang.IllegalStateException: Unable to resolve class ref:
>> CDOClassRef(uuid://interface, 0)
>> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOClassProxy.ge tCdoClass(CDOClassProxy.java:71)
>
>> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOFeatureImpl.g etReferenceType(CDOFeatureImpl.java:243)
>
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.tuplizer.CDOFe atureReferenceTypePropertyHandler.get(CDOFeatureReferenceTyp ePropertyHandler.java:58)
>
>> at
> org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropert yValue(AbstractEntityTuplizer.java:277)
>
>> at
> org.hibernate.persister.entity.AbstractEntityPersister.getPr opertyValue(AbstractEntityPersister.java:3586)
>
>> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
>> at
> org.hibernate.event.def.AbstractSaveEventListener.cascadeBef oreSave(AbstractSaveEventListener.java:431)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:265)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
>> at
>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
>> at
>> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
>> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at
>> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
>> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
>> at
> org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
>> at
>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
>> at
>> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
>> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at
>> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
>> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
>> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
>> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
>> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
>> at
> org.hibernate.event.def.AbstractSaveEventListener.cascadeAft erSave(AbstractSaveEventListener.java:456)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav eOrReplicate(AbstractSaveEventListener.java:334)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.performSav e(AbstractSaveEventListener.java:181)
>
>> at
> org.hibernate.event.def.AbstractSaveEventListener.saveWithGe neratedId(AbstractSaveEventListener.java:121)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.sav eWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener .java:187)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
>> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
>> at
>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :495)
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.HibernatePacka geHandler.writePackages(HibernatePackageHandler.java:136)
>
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.writePackages(HibernateStoreWriter.java:157)
>
>> at
> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Writer.commit(HibernateStoreWriter.java:56)
>
>> at
>> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:179)
>>
>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
>> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
>
>> Can it be that your code does not cover this case where a type in a
>> package is referred to in the meta-sense, but there is no reference
>> (yet) instance-wise?
>
>> Cheers,
>> Stefan
>
>> P.S. I'm working with HEAD of yesterday.
>
>
>> Eike Stepper schrieb:
>>> Hi Eric,
>>>
>>> I recently changed the code to better handle nested packages. Are
>>> you using the latest CVS sources? It should work with them...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eric wrote:
>>>
>>>> Hi Eike,
>>>
>>>> I've come across a problem when dealing with an Ecore file
>>>> containing multiple packages.
>>>
>>>> Ecore file:
>>>> Package1:
>>>> ClassA [has an attribute of type ClassD]
>>>> ClassB
>>>> Package2:
>>>> ClassC
>>>> ClassD
>>>
>>>> In my client, I register both packages (A & B) with my session's
>>>> package registry. I then create an object of type ClassA, but I
>>>> don't set (leave it as null) its attribute of type ClassD.
>>>
>>>> When CDO reaches the server side at commit time, I only see
>>>> Package1 being transfered over and since ClassA references Package2
>>>> through an attribute of ClassD, I get an exception:
>>>
>>>> Unable to resolve classref: CDOClassRef(Package2, ...)
>>>> at CDOClassProxy.getCdoClass(CDOClassProxy.java:71)
>>>> at CDOFeatureImpl.getReferenceType(CDOFeatureImpl.java:243)
>>>> at
>>>
> CDOFeatureReferenceTypePropertyHandler.get(CDOFeatureReferen ceTypePropertyHandler.java:63)
>
>>>
>>>
>>>> If I take the same code and create an object of type ClassC (or any
>>>> object from Package2) and add this object to my resource, Package2
>>>> will get transfered over and my test will work. So in order to see
>>>> your package on the server side, you need to:
>>>> 1. Register it
>>>> 2. Create at least one object from that package
>>>
>>>> Problem is that object of type ClassA references Package2. So when
>>>> deciding which package need to be transfered, CDO will have to do a
>>>> deep scan of the object instead of only using its containingPackage
>>>> (this is how I assume CDO works, correct me if I'm wrong).
>>>
>>>> Any thoughts?
>>>> Eric
>>>
>>>
>
>
--------------050002020408050607040102
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eike,<br>
<br>
filed
|
|
|
Goto Forum:
Current Time: Sat Nov 09 05:17:20 GMT 2024
Powered by FUDForum. Page generated in 0.05929 seconds |
] 
Search
Help
Register
Login
Home
