Skip to main content
Jump to: navigation, search

FAQ for CDO and Net4j

Revision as of 04:35, 19 December 2008 by (Talk | contribs) (Why does p2 complain about unsatisfied dependencies?)


Why does p2 complain about unsatisfied dependencies?

CDO and Net4j are optionally using some 3rd party bundles from 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:



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():

  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());
    // 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)

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


How can I use authentication?

If you're using any sort of negotiation you must usually ensure that the INegotiators of both client and server side properly match together. INegotiators are currently only supported by IConnectors. Since server-side connectors are created by an IAcceptor you need to configure the acceptor with the needed INegotiator so tat it can pass it down to new connectors. If you do so you need to add a matching negotiator to your client connector before connecting, too.

If you're pulling your client connector out of an IManagedContainer it will already be connected. So you need to register a post processor with the container to inject your negotiator into the connector *before* it is returned:

    container.addPostProcessor(new IElementProcessor()
      public Object process(IManagedContainer container, String productGroup, String factoryType, String description,
          Object element)
        if (element instanceof TCPClientConnector)
          TCPClientConnector connector = (TCPClientConnector)element;
          INegotiator negotiator = createNegotiator();
        return null;
      private INegotiator createNegotiator()
        ResponseNegotiator negotiator = new ResponseNegotiator();
        negotiator.setCredentialsProvider(new PasswordCredentialsProvider("login", "password"));
        // negotiator.setCredentialsProvider(new InteractiveCredentialsProvider());
        return negotiator;

Wikis: CDO | Net4j | EMF | Eclipse

Back to the top