Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "FAQ for CDO and Net4j"

(How can I react to remote changes to my objects?)
(How can I enable tracing?)
Line 10: Line 10:
  
 
<source lang="java">
 
<source lang="java">
    OMPlatform.INSTANCE.addLogHandler(PrintLogHandler.CONSOLE);
+
OMPlatform.INSTANCE.addLogHandler(PrintLogHandler.CONSOLE);
    OMPlatform.INSTANCE.addTraceHandler(PrintTraceHandler.CONSOLE);
+
OMPlatform.INSTANCE.addTraceHandler(PrintTraceHandler.CONSOLE);
    OMPlatform.INSTANCE.setDebugging(true);
+
OMPlatform.INSTANCE.setDebugging(true);
 
</source>
 
</source>
  

Revision as of 12:41, 10 October 2008


General

How can I enable tracing?

If running as Eclipse launch config it's easy: just turn on tracing on the tracing page of the launch config (plus all net4j and cdo plugins in the list).

If running standalone:

OMPlatform.INSTANCE.addLogHandler(PrintLogHandler.CONSOLE);
OMPlatform.INSTANCE.addTraceHandler(PrintTraceHandler.CONSOLE);
OMPlatform.INSTANCE.setDebugging(true);


CDO

Why does CDO complain that my objects can't be cast to InternalCDOObject?

Looks as if you are not generating your model for CDO. Have you already read Preparing EMF Models for CDO?

How can I modify the behaviour of generated getters and setters?

If you want to modify the behaviour of generated getters and setters (or have already done so in existing models) you might want to try dynamic feature delegation (introduced in EMF 2.5). With this pattern, the reflective methods like eGet still call your generated method like getX() and then that calls the dymamic reflective method like eDynamicGet. It effectively produces the same behavior as "Refective" delegating but does so by delegating through your generated accessors allowing you to specialize those as you could when you used "None"...

What's the best way to convert an XMIResource to a CDOResource?

You just need to copy/move the root objects over to the CDOResource. There's a good example in ImportResourceAction.doRun():

  @Override
  protected void doRun() throws Exception
  {
    CDOTransaction transaction = getTransaction();
 
    // Source ResourceSet
    ResourceSet sourceSet = new ResourceSetImpl();
    Map<String, Object> map = sourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap();
    map.put("*", new XMIResourceFactoryImpl());
    sourceSet.setPackageRegistry(transaction.getSession().getPackageRegistry());
 
    // Source Resource
    Resource source = sourceSet.getResource(sourceURI, true);
    List<EObject> sourceContents = new ArrayList<EObject>(source.getContents());
 
    // Target Resource
    Resource target = transaction.createResource(targetPath);
    EList<EObject> targetContents = target.getContents();
 
    // Move contents over
    for (EObject root : sourceContents)
    {
      targetContents.add(root);
    }
  }

How can I react to remote changes to my objects?

CDO 2.0 has several mechansims to catch up with remote changes. They differ in the amount of change information being delivered and thus in the burden put on the network:

  • CDOSessionInvalidationEvent is the oldest and simplest form. The event is emitted to registered IListeners of a CDOSession *if* PassiveUpdate is enabled for the session. See CDOSessionInvalidationEvent.java
  • CDOInvalidationNotification is a *custom* EMF notification that is emitted to adapters of the EObjects in a CDOView *if* InvalidationNotification is enabled for the view. Since the notifications are constructed out of the information in a CDOSessionInvalidationEvent (i.e. CDOIDs) they don't carry detailed change deltas. All the Notification methods related to change deltas throw UOEs. See CDOInvalidationNotification.java
  • CDOChangeSubscriptionPolicy a is the newest form (only in 2.0) and the one that delivers the most detailed information about the actual change. The change information is delivered to object adapters. To compensate the bandwidth burden of the change info per object you must exactly specify for which objects it is provides. With one of the shipped policies or an own one you can do this per view. See CDOChangeSubscriptionPolicy.java


Net4j


Wikis: CDO | Net4j | EMF | Eclipse

Back to the top