Jump to: navigation, search

Difference between revisions of "FAQ for CDO and Net4j"

(How can I react to remote changes to my objects?)
(General)
Line 2: Line 2:
 
<br>
 
<br>
 
=General=
 
=General=
 +
 +
==Why does p2 complain about unsatisfied dependencies?==
 +
[[CDO]] and [[Net4j]] are '''optionally''' using some 3rd party bundles from [http://www.springsource.com/repository/app/
 +
SpringSource Enterprise Bundle Repository] at runtime. Unfortunately p2 does not support this optinality at install time.
 +
 +
Please download and install the needed 3rd party bundles '''before''' you use p2 to install CDO and Net4j. The following links
 +
provide you with an idea of the required bundles:
 +
 +
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf.cdo/develop/setup/setup-workspace.properties?root=Modeling_Project&view=co 3rd party bundles needed in HEAD]
 +
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf.cdo/develop/setup/setup-workspace.properties?view=log&root=Modeling_Project&pathrev=R1_0_maintenance 3rd party bundles needed in R1_0_maintenance]
  
 
==How can I enable '''tracing'''?==
 
==How can I enable '''tracing'''?==

Revision as of 07:50, 21 November 2008


General

Why does p2 complain about unsatisfied dependencies?

CDO and Net4j are optionally using some 3rd party bundles from [http://www.springsource.com/repository/app/ SpringSource Enterprise Bundle Repository] at runtime. Unfortunately p2 does not support this optinality at install time.

Please download and install the needed 3rd party bundles before you use p2 to install CDO and Net4j. The following links provide you with an idea of the required bundles:

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 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