JAVA-1: Proposed direction for resolution

[Simon Nash <oasis@cjnash.com>]

In our last telecon discussion of JAVA-1, we talked about the vendor
customization mechanism to override the default SCA lookup for a
vendor-specific factory.

We agreed that the requirements are as follows:
  a) It is not acceptable for SCA to impose a hard-wired algorithm
     for finding a vendor-specific factory.  The default mechanism
     provided by SCA needs to be customizable/overridable by vendors.
  b) It is not a requirement to enable a client to use more than one
     vendor-specific factory at the same time.
  c) It is a requirement to enable a client to use the factory for
     vendor A while running either standalone or within a vendor B
     SCA domain.
  d) It is acceptable to require a client to know which vendor
     factory is needed for the domain or domains it wishes to access.
  e) It is a requirement to clearly separate SCA-provided code and
     vendor-provided code into different packages, with standardized
     SPIs provided by SCA for use by vendors.

The current proposal
   http://lists.oasis-open.org/archives/sca-j/200903/msg00227.html
satisfies a), b), d) and e) but does not satisfy c).  This is because
the use of the defaultFactory injection point by vendor B (when
running in a vendor B environment) prevents the client from finding
vendor A's factory.  Removing the defaultFactory injection point
solves this problem, but this means requirement a) is not satisfied.

This problem can be solved by a minor change to the current proposal.
The change is to retain the injection point but use it to inject a
vendor-specific factory finder rather than a vendor-specific factory.
With this change, requirements a), b), c), d) and e) are all satisfied.

Here's the code needed for this, with comments describing the changes
from the current proposal:

- - - - - - - - - - - - - - - - - -

// This is a new SPI representing a factory finder.  The reference
// implementation provided by SCA implements this interface, and vendors
// can create alternative implementations of this interface that use
// different class loading or lookup mechanisms.

package org.oasisopen.sca.client;

public interface SCAClientFactoryFinder {

     SCAClientFactory find(Properties properties,
                           ClassLoader classLoader);
}

- - - - - - - - - - - - - - - - - -

// This is SCA's reference implementation of the SCAClientFactoryFinder SPI.
// The only difference from the SCAClientFactoryFinder class in the current
// proposal is that the find() method is no longer static.  Instead, it
// implements the find() method of the SCAClientFactoryFinder interface,
// just as a vendor-provided factory finder would.

package org.oasisopen.sca.client.impl;

public class SCAClientFactoryFinderImpl implements SCAClientFactoryFinder {

     private static final String SCA_CLIENT_FACTORY_PROVIDER_KEY =
             SCAClientFactory.class.getName();

     private static final String SCA_CLIENT_FACTORY_PROVIDER_META_INF_SERVICE
             = "META-INF/services/" + SCA_CLIENT_FACTORY_PROVIDER_KEY;

     public SCAClientFactoryFinderImpl() {
     }

     public SCAClientFactory find(Properties properties,
                                  ClassLoader classLoader) {
         if (classLoader == null) {
             classLoader = getThreadContextClassLoader();
         }
         final String factoryImplClassName =
             discoverProviderFactoryImplClass(properties, classLoader);
         final Class<? extends SCAClientFactory> factoryImplClass
             = loadProviderFactoryClass(factoryImplClassName, classLoader);
         final SCAClientFactory factory =
             instantiateSCAClientFactoryClass(factoryImplClass);
         return factory;
     }

     // the remaining code is unchanged from the SCAClientFactoryFinder
     // reference implmentation in the current proposal
     ....
}

- - - - - - - - - - - - - - - - - -

// This modification of the SCAClientFactory abstract class uses the new
// SCAClientFactoryFinder SPI to invoke the factory finder.  If a vendor
// has injected a factory finder into the defaultFactoryFinder field, the
// vendor's factory finder is used.  If nothing is injected into this
// field, the SCA-provided factory finder reference implementation is used.

package org.oasisopen.sca.client;

import java.util.Properties;

import org.oasisopen.sca.client.impl.SCAClientFactoryFinderImpl;

public abstract class SCAClientFactory {

     protected static SCAClientFactoryFinder defaultFactoryFinder;

     public static SCAClient newInstance() {
         return newInstance(null, null);
     }

     public static SCAClient newInstance(Properties properties) {
         return newInstance(properties, null);
     }

     public static SCAClient newInstance(ClassLoader classLoader) {
         return newInstance(null, classLoader);
     }

     public static SCAClient newInstance(Properties properties,
                                         ClassLoader classLoader) {
         final SCAClientFactoryFinder finder =
             defaultFactoryFinder != null ? defaultFactoryFinder :
             new SCAClientFactoryFinderImpl();
         final SCAClientFactory factory
             = finder.find(properties, classLoader);
         return factory.createSCAClient();
     }

     protected abstract SCAClient createSCAClient();
}

- - - - - - - - - - - - - - - - - -

The client interface is unchanged from the current proposal.  If a
vendor wants to customize the factory finder, the vendor must create
a factory finder class that implements the find() method of the
SCAClientFactoryFinder interface, and inject an instance of this class
into the defaultFactoryFinder field of the SCAClientFactory abstract class.
The find() method of the vendor's factory finder class must return a
vendor-implemented subclass of the SCAClientFactory abstract class.

   Simon