|
|
| Re: [CDO] Problem with EMF content adapter [message #425685 is a reply to message #425679] |
Thu, 04 December 2008 16:16   |
 Christian Hauser
Messages: 189
Registered: July 2009 |
Senior Member |
|
|
Thanks Simon
You're right, my objects were GC'ed. Overriding setTarget in
EContentAdapter to add the elements to a list (using strong references)
fixed my problem that only existed on Windows, but not so on Linux.
Thank you for saving me time debugging any further.
As I have to stick to Eclipse 3.4.x (Ganymede) and EMF 2.4.x would it be
possible to use CDO 2.0.x? We're considering CDO, however, version 1.0.x
seems not too mature for what I've seen. Is CDO 1.0.4 used productively
on a larger system by anyone?
Please don't get me wrong, I really fancy what you guys developed with
CDO. However, we might have to wait for CDO 2.0.x and if this only works
with Galileo and EMF 2.5 we might have to wait until 2010 or even longer...
Christian
Simon McDuff wrote:
>
> Hi Christian,
>
> One reason could be the objects that are content are GC's.
>
> See this bugzilla :
>
> 250486: Objects are GC'ed out of a view even when adapters are attached
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250486
>
>
> Problem:
> Basically since the adapter do not have a strong reference to the
> target (except the last one I think in case of a ECOntentAdapter),
> objects could be GC's... so you won't have the notification.
>
>
> Solution:
> To fix that problem in CDO 1.0.4, you will need to keep a Strong
> reference to these objects. Maybe in your ECOntentAdapter.setTarget...
> you could add the element to a list...
>
>
> In the future:
> In 2.0.0, when the above bugs will be committed (it is under review at
> the moment) you will be able to fix that by doing :
>
> view.setAdapterReferencePolicy(CDOAdapterPolicy.ALL);
>
> We are thinking to put it at CDOAdapterPolicy.ALL by default so nobody
> will have a surprise!!!
>
> Let me know if you need more precision to solve the problem.
>
>
> Simon
>
>
>
> Christian Hauser wrote:
>> Hi
>>
>> I'm having problems with an EMF content adapter with CDO 1.0.4.
>>
>> Here's some code to demonstrate:
>>
>> // Create configuration
>> CDOSessionConfiguration configuration =
>> CDOUtil.createSessionConfiguration();
>> configuration.setConnector(connector);
>> configuration.setRepositoryName("repo1");
>>
>> // Open session
>> CDOSession session = configuration.openSession();
>> session.getPackageRegistry().putEPackage(ModelPackage.eINSTA NCE);
>>
>> // Add session listener
>> session.addListener(new IListener() {
>> @Override
>> public void notifyEvent(IEvent event) {
>> System.out.println(event.toString() + " (" +
>> event.getSource().toString() + ")");
>> }
>> });
>>
>> // Open transaction
>> CDOTransaction tx = session.openTransaction();
>> tx.setInvalidationNotificationsEnabled(true);
>>
>> // Get or create resource
>> CDOResource resource =
>> tx.getOrCreateResource("/personen/person1");
>> // Here I try to add a content adapter to my resource
>> resource.eAdapters().add(new EContentAdapter() {
>> public void notifyChanged(Notification notification) {
>> super.notifyChanged(notification);
>> Object notifier = notification.getNotifier();
>> if (notifier instanceof Person) {
>> Person p = (Person) notifier;
>> System.out.println("OK! Notification received!");
>> } else {
>> System.out.println("OK! Notification received!");
>> }
>> }
>> });
>> ...
>>
>> Now my problem is, that for an existing list of persons only the
>> first person and the last person within the list get the adapter
>> registered. Therefore my application only gets notified of changes
>> made to the first and last person within the list.
>>
>> My interpretation of resource.eAdapters().add(new EContentAdapter()
>> {...} was that *every* object within the resource will have the
>> adapter registered not only the first or last entry within a list.
>> Could someone please enlighten me on how this really works and how I
>> have to adapt my code?
>>
>> Thanks in advance for your help!
>> Christian
>>
>>
>>
>>
|
|
|
| Re: [CDO] Problem with EMF content adapter [message #425687 is a reply to message #425685] |
Thu, 04 December 2008 16:53 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I would like to add that we've developed one of our products
successfully using EMF 2.4 and a CDO integration build of the 2.0 stream
without any problem :)
Of course, I don't think I can encourage you to do this, since final 2.0
release will probably introduce dependencies with EMF 2.5 in it's
official release (Eike has raised some bugs in EMF that are very
important for CDO!), and API still might change until freezed (M6
03/16/2009). You can take a look at the project plan at
http://www.eclipse.org/projects/project-plan.php?planurl=htt p://www.eclipse.org/modeling/emf/cdo/project-info/plan.xml&a mp;component=CDO.
As you see, you won't have to wait until 2010 ;)
Regarding your initial problem with EContentAdapter, you might also be
interested in this:
Create a lazy self-attaching adapter for CDOObject
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247141
Cheers,
Víctor.
Christian Hauser escribió:
>
> Thanks Simon
>
> You're right, my objects were GC'ed. Overriding setTarget in
> EContentAdapter to add the elements to a list (using strong references)
> fixed my problem that only existed on Windows, but not so on Linux.
> Thank you for saving me time debugging any further.
>
> As I have to stick to Eclipse 3.4.x (Ganymede) and EMF 2.4.x would it be
> possible to use CDO 2.0.x? We're considering CDO, however, version 1.0.x
> seems not too mature for what I've seen. Is CDO 1.0.4 used productively
> on a larger system by anyone?
>
> Please don't get me wrong, I really fancy what you guys developed with
> CDO. However, we might have to wait for CDO 2.0.x and if this only works
> with Galileo and EMF 2.5 we might have to wait until 2010 or even longer...
>
> Christian
>
>
> Simon McDuff wrote:
>>
>> Hi Christian,
>>
>> One reason could be the objects that are content are GC's.
>>
>> See this bugzilla :
>>
>> 250486: Objects are GC'ed out of a view even when adapters are attached
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250486
>>
>>
>> Problem:
>> Basically since the adapter do not have a strong reference to the
>> target (except the last one I think in case of a ECOntentAdapter),
>> objects could be GC's... so you won't have the notification.
>>
>>
>> Solution:
>> To fix that problem in CDO 1.0.4, you will need to keep a Strong
>> reference to these objects. Maybe in your ECOntentAdapter.setTarget...
>> you could add the element to a list...
>>
>>
>> In the future:
>> In 2.0.0, when the above bugs will be committed (it is under review at
>> the moment) you will be able to fix that by doing :
>>
>> view.setAdapterReferencePolicy(CDOAdapterPolicy.ALL);
>>
>> We are thinking to put it at CDOAdapterPolicy.ALL by default so nobody
>> will have a surprise!!!
>>
>> Let me know if you need more precision to solve the problem.
>>
>>
>> Simon
>>
>>
>>
>> Christian Hauser wrote:
>>> Hi
>>>
>>> I'm having problems with an EMF content adapter with CDO 1.0.4.
>>>
>>> Here's some code to demonstrate:
>>>
>>> // Create configuration
>>> CDOSessionConfiguration configuration =
>>> CDOUtil.createSessionConfiguration();
>>> configuration.setConnector(connector);
>>> configuration.setRepositoryName("repo1");
>>>
>>> // Open session
>>> CDOSession session = configuration.openSession();
>>> session.getPackageRegistry().putEPackage(ModelPackage.eINSTA NCE);
>>>
>>> // Add session listener
>>> session.addListener(new IListener() {
>>> @Override
>>> public void notifyEvent(IEvent event) {
>>> System.out.println(event.toString() + " (" +
>>> event.getSource().toString() + ")");
>>> }
>>> });
>>>
>>> // Open transaction
>>> CDOTransaction tx = session.openTransaction();
>>> tx.setInvalidationNotificationsEnabled(true);
>>>
>>> // Get or create resource
>>> CDOResource resource =
>>> tx.getOrCreateResource("/personen/person1");
>>> // Here I try to add a content adapter to my resource
>>> resource.eAdapters().add(new EContentAdapter() {
>>> public void notifyChanged(Notification notification) {
>>> super.notifyChanged(notification);
>>> Object notifier = notification.getNotifier();
>>> if (notifier instanceof Person) {
>>> Person p = (Person) notifier;
>>> System.out.println("OK! Notification received!");
>>> } else {
>>> System.out.println("OK! Notification received!");
>>> }
>>> }
>>> });
>>> ...
>>>
>>> Now my problem is, that for an existing list of persons only the
>>> first person and the last person within the list get the adapter
>>> registered. Therefore my application only gets notified of changes
>>> made to the first and last person within the list.
>>>
>>> My interpretation of resource.eAdapters().add(new EContentAdapter()
>>> {...} was that *every* object within the resource will have the
>>> adapter registered not only the first or last entry within a list.
>>> Could someone please enlighten me on how this really works and how I
>>> have to adapt my code?
>>>
>>> Thanks in advance for your help!
>>> Christian
>>>
>>>
>>>
>>>
|
|
|
| Re: [CDO] Problem with EMF content adapter [message #425688 is a reply to message #425685] |
Thu, 04 December 2008 17:37 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Christian Hauser wrote:
>
> Thanks Simon
You are welcome
>
> You're right, my objects were GC'ed. Overriding setTarget in
> EContentAdapter to add the elements to a list (using strong references)
> fixed my problem that only existed on Windows, but not so on Linux.
> Thank you for saving me time debugging any further.
>
> As I have to stick to Eclipse 3.4.x (Ganymede) and EMF 2.4.x would it be
> possible to use CDO 2.0.x? We're considering CDO, however, version 1.0.x
> seems not too mature for what I've seen. Is CDO 1.0.4 used productively
> on a larger system by anyone?
>
I know some people is using it in a productive way, personnally we are
still using 0.8.0 at work... and never upgrade it!! :-) (it uses a
home-made back-end). Since I'm in paternity leave... I'm not there to
upgrade it!! :-)
> Please don't get me wrong, I really fancy what you guys developed with
> CDO. However, we might have to wait for CDO 2.0.x and if this only works
> with Galileo and EMF 2.5 we might have to wait until 2010 or even longer...
>
I slightly agree with you. It really depends on which features you are
using. Some feature do not work properly... it depends also on the
back-end you are using!! To address that issue, we went from 148
testcases in 1.0.x to 363 testcases in 2.0.0. We are very confident on
what we have in HEAD. Our goal is really to deliver a product of high
quality!
Simon
> Christian
>
>
> Simon McDuff wrote:
>>
>> Hi Christian,
>>
>> One reason could be the objects that are content are GC's.
>>
>> See this bugzilla :
>>
>> 250486: Objects are GC'ed out of a view even when adapters are attached
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250486
>>
>>
>> Problem:
>> Basically since the adapter do not have a strong reference to the
>> target (except the last one I think in case of a ECOntentAdapter),
>> objects could be GC's... so you won't have the notification.
>>
>>
>> Solution:
>> To fix that problem in CDO 1.0.4, you will need to keep a Strong
>> reference to these objects. Maybe in your ECOntentAdapter.setTarget...
>> you could add the element to a list...
>>
>>
>> In the future:
>> In 2.0.0, when the above bugs will be committed (it is under review at
>> the moment) you will be able to fix that by doing :
>>
>> view.setAdapterReferencePolicy(CDOAdapterPolicy.ALL);
>>
>> We are thinking to put it at CDOAdapterPolicy.ALL by default so nobody
>> will have a surprise!!!
>>
>> Let me know if you need more precision to solve the problem.
>>
>>
>> Simon
>>
>>
>>
>> Christian Hauser wrote:
>>> Hi
>>>
>>> I'm having problems with an EMF content adapter with CDO 1.0.4.
>>>
>>> Here's some code to demonstrate:
>>>
>>> // Create configuration
>>> CDOSessionConfiguration configuration =
>>> CDOUtil.createSessionConfiguration();
>>> configuration.setConnector(connector);
>>> configuration.setRepositoryName("repo1");
>>>
>>> // Open session
>>> CDOSession session = configuration.openSession();
>>> session.getPackageRegistry().putEPackage(ModelPackage.eINSTA NCE);
>>>
>>> // Add session listener
>>> session.addListener(new IListener() {
>>> @Override
>>> public void notifyEvent(IEvent event) {
>>> System.out.println(event.toString() + " (" +
>>> event.getSource().toString() + ")");
>>> }
>>> });
>>>
>>> // Open transaction
>>> CDOTransaction tx = session.openTransaction();
>>> tx.setInvalidationNotificationsEnabled(true);
>>>
>>> // Get or create resource
>>> CDOResource resource =
>>> tx.getOrCreateResource("/personen/person1");
>>> // Here I try to add a content adapter to my resource
>>> resource.eAdapters().add(new EContentAdapter() {
>>> public void notifyChanged(Notification notification) {
>>> super.notifyChanged(notification);
>>> Object notifier = notification.getNotifier();
>>> if (notifier instanceof Person) {
>>> Person p = (Person) notifier;
>>> System.out.println("OK! Notification received!");
>>> } else {
>>> System.out.println("OK! Notification received!");
>>> }
>>> }
>>> });
>>> ...
>>>
>>> Now my problem is, that for an existing list of persons only the
>>> first person and the last person within the list get the adapter
>>> registered. Therefore my application only gets notified of changes
>>> made to the first and last person within the list.
>>>
>>> My interpretation of resource.eAdapters().add(new EContentAdapter()
>>> {...} was that *every* object within the resource will have the
>>> adapter registered not only the first or last entry within a list.
>>> Could someone please enlighten me on how this really works and how I
>>> have to adapt my code?
>>>
>>> Thanks in advance for your help!
>>> Christian
>>>
>>>
>>>
>>>
|
|
|
Powered by
FUDForum. Page generated in 0.03467 seconds
] 
Search
Help
Register
Login
Home
