Revision as of 05:35, 19 December 2008

General

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:

• 3rd party bundles needed in HEAD
• 3rd party bundles needed in R1_0_maintenance

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

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();
          connector.getConfig().setNegotiator(negotiator);
 
        }
        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