----- Original Message -----
From: "James Strachan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 01, 2001 3:56 PM
Subject: [MetaFactory] experiment


> I'd like to conduct a small experimental project in the sandbox if noone
> objects. If it proves useful cool, if it doesn't we can zap it.
>
> We use interfaces alot in Java and I like the idea of having some simple,
> lightweight component to allow runtime, loose binding of concrete types to
> interfaces.
>
> I'd like to investigate building a small, simple facade API over the
loading
> of objects from either
>
>     * JAR extension mechansim (/META-INF/services/foo.bar) like JAXP
>     * JNDI
>     * web.xml / ServletContext / init params
>     * Properties / ExtendedProperties files
>     * XML documents
>
> It may or may not be useful on other Jakarta projects too. Its not my
> intention to implement specific configuration mechanisms like the
Digester,
> rather just a way of loading a concrete factory class which might use
(say)
> the digester or JNDI directly.
>

cool.

I planned on doing a similar thing on a project I have called Babel. It is a
generic service framework (manage life cycle of it's services and basic
configuration and administration). I wrote several useful services for it,
like Configuration service that reads data from properties file (which might
be contained in jars and are refreshable), XML Mapper service  to transform
XML into Java objects (a facade around Castor XML), Logging service (a
facade around Log4j), JDBC Wrapper, JNDI Wrapper, .... I planned to do a
unified configuration service, which seems to be exactly what you describe :
- have a client API (CCI) to configuration,
- have an implementation API (SPI) so that different implementations can be
plugged in (like properties file, JNDI, XML files, JDBC, ...)

Your implementation of this unified configuration service is something that
could be useful for Avalon framework for example.

I have not looked at it but I seem to rememeber that there was a JSR
regadring Configuration that has been opened. Maybe it's worth having a look
at it to see if the goal is the same.

> My early thoughts are to use a Facade pattern along with a variation of
two
> patterns from IBM's San Francisco Desirgn Patterns book:-
>
>     * Class Replacement
>     * Special Class Factory
>
> The basic idea is there can be default implementations for specific
> interfaces which can be overridden for named instances if necessary or can
> be overridden for specifc 'categories' in a log4j sense or package or
class
> names.
> The idea being a little like log4j's categories and a little like Java's
> ResourceBundles where specific language & country combinations can
override
> default configurations. Only in the MetaFactory it would be caller class
> name (or package), the desired interface and an optional name which
decides
> which implementation to use. So this could be implemented as a fairly
> trivial layer above JAR extension mechanism or JNDI. (e.g. it could be
used
> as a bootstrap mechanism to find the JNDI context when in a JUnit test
> case).
>
> So code would be something along these lines...
>
> public Foo {
>
>     // look up my region of the MetaFactory
>     // like a log4j style Category
>     protected static final MetaFactory metaFactory =
> etaFactory.get( Foo.class );
>
>     public void doSomething() {
>
>         // create some default Map implementation
>         Map map = metaFactory.create( Map.class );
>
>         // create a named Map implementation
>         Map fooCache = metaFactory.create( Map.class, "fooCache" );
>         ...
>
>         // create some object pool
>         ObjectPoolFactory poolFactory = (ObjectPoolFactory)
>                 metaFactory.create( ObjectPoolFactory.class );
>
>         ObjectPool pool = poolFactory.createPool();
>         ...
>
>
>         // create some named database connection pool
>         ConnectionFactory connFactory = (ConnectionFactory)
>                 metaFactory.create( ConnectionFactory.class,
"customerDb" );
>     }
> }
>
> So from an API its one class though I would expect a small number of
> implementation classes too so that it is capable of bootstrapping itself
and
> talk to JNDI and JAR manifests.
>
> Does this seem an acceptable use of the sandbox? If so Craig, could I get
> sandbox karma please?
>
> James
>


Vincent.

Reply via email to