You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Thomas Dudziak <to...@first.fhg.de> on 2004/10/26 15:10:14 UTC
[RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Hi folks,
Armin and I were chatting the other day about making the whole
initialization and configuration of OJB more flexible and loose-coupled.
So I ventured into the 'depths' of IoC, more specifically PicoContainer
and Spring, to see whether they could help us there. As a result I came
up with the concept of an ObjectFactory (see the interface below) as
well as two implementations using PicoContainer and Spring's
BeanFactory, respectively.
In short, an ObjectFactory offers the following functions:
* configuration of the implementation classes for interfaces/abstract
classes (via setImplementationClass)
* dependencies to other factory-managed types that are stated in the
constructor of the component are automatically filled by the factory
* singleton instances can be defined (via setSingletonInstance)
* factories are hierarchical, the child factory directs a request to its
parent if it cannot answer it
* the factory configures newly created instances automatically using
standard bean properties of 'normal' java types (i.e. primitives, String
etc.)
Using such factories IMO would bring us the following benefits
* Loose coupling - a component (i.e. its facade object) only has to
state in its constructor that it wants e.g. a PersistenceBroker instance
and does not have to care where it gets it from (IoC)
* Via hierarchical factories and singleton instances it is easy to wire
1:n scenarios. I.e. for wiring one OJB instance with its n
PersistenceConfiguration instances, the OJB instance registers itself as
a singleton at its factory. When a PC instance is created somwehere
within the context of the OJB instance via
factory.getInstance(PersistenceConfiguration.class), it will want an OJB
instance (constructor arg) and will automatically receive the singleton
OJB instance.
* Automatic configuration (e.g. OJB.properties) using fully qualified
properties with the default values defined in the components itself.
E.g. it would be possible to specify both
org.apache.ojb.broker.PersistenceBroker.someProperty=someValue
org.apache.ojb.broker.DefaultPersistenceBrokerImpl.someOtherProperty=someOtherValue
The first property will be set at all PB instances regardless of the
impl type whereas the second one will only be used for PB instances of
this particular type. Using the special property
org.apache.ojb.broker.PersistenceBroker.class=someClass
the implementation class for PB can be configured.
This allows for hot-plugging of new components without having to
recompile OJB or even change source code in it simply by adding the
classes to the classpath and setting the properties in OJB.properties.
To be able to use this scheme all that is necessary would be that the
components adhere to these two rules:
* All components that a component is dependant upon, must be specified
in its constructor. Multiple constructors are possible (the factory will
choose the greediest one that it can supply instances to).
* All other properties (settings) have to be specified via simple bean
properties (get/set). The default value is thus specified in the component.
I'd like to know what you think about this ? Specifically, I'd like to
use the PicoContainer impl as the default one (which adds a 49k lib to
the runtime OJB requirements) and to provide the Spring impl as an
alternative (e.g. for Spring integration of OJB) which also adds a 250k
lib (spring-core) to the OJB-build requirements.
regards,
Tom
-------------------------------------------------------------------------------------
package org.apache.ojb.broker.conf;
import java.util.HashMap;
import java.util.Properties;
/**
* Defines a factory which is used to create and maintain configurable
components.
* The component objects are initialized via the IoC principle.
Factories are
* hierarchical where the children factories look at their parents if
they cannot
* handle a request themselves.
*
* @author Thomas Dudziak
*/
public interface ObjectFactory
{
/**
* Creates a child factory.
*
* @return The new child factory
*/
public ObjectFactory createChildFactory();
/**
* Sets the parent factory.
*
* @param parent The parent factory
*/
public void setParentFactory(ObjectFactory parent);
/**
* Returns the parent factory if any.
*
* @return The parent factory
*/
public ObjectFactory getParentFactory();
/**
* Returns the registered implementation class for the given type.
*
* @param type The type to register the implementation for
* @return The registered class
*/
public Class getImplementationClass(Class type);
/**
* Registers an implementation class for the given type (and only for it
* but not for super- or subtypes of it).
*
* @param type The type to register the implementation for
* @param implClass The implementation class to register
*/
public void setImplementationClass(Class type, Class implClass);
/**
* Registers the given object as the singleton instance for the
given type. Note that
* singleton instances are assumed to be already configured.
*
* @param clazz The class to register the object for
* @param obj The object
*/
public void setSingletonInstance(Class clazz, Object obj);
/**
* Return a new instance of the implementation for the given class.
* If a singleton instance is registered for this type, then this
instance
* is returned. The instance will be configured except if it is a
singleton
* instance.
*
* @param clazz The class
* @return The instance
* @exception ObjectCreationException If no implementation is
configured for this type
* @exception ObjectConfigurationException If the instance could not
be configured
*/
public Object getInstance(Class clazz) throws
ObjectCreationException, ObjectConfigurationException;
/**
* Returns all properties specifically defined for the specified type.
*
* @param clazz The type
* @return The properties or <code>null</code> if no properties are
defined for this type
*/
public HashMap getProperties(Class clazz);
/**
* Returns the given property.
*
* @param clazz The type that the property is set for
* @param name The property name
* @return The value or <code>null</code> if there is no such property
*/
public Object getProperty(Class clazz, String name);
/**
* Sets the given property.
*
* @param clazz The type to set the property for
* @param name The property name
* @param value The value; use <code>null</code> to unset the property
* @param force If <code>true</code> then an existing property will
be overriden, otherwise
* it will only be set if not yet defined
*/
public void setProperty(Class clazz, String name, Object value,
boolean force);
/**
* Sets the properties. The names of the properties are evaulated as
* fully qualified property names, e.g. package.Class.propertyName.
*
* @param props The properties
* @param force If <code>true</code> then an existing property will
be overriden, otherwise
* it will only be set if not yet defined
*/
public void setProperties(Properties props, boolean force) throws
FactoryInitializationException;
/**
* Configures the given object, i.e. sets all properties that are
defined
* for the types of the object beginning with the farthest base types.
*
* @param obj The object
*/
public void configure(Object obj) throws ObjectConfigurationException;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi all,
i'm very positive about ioc, but i do not know any of the containers in depth.
so if all provide the same features we should choose the smallest.
jakob
Thomas Mahler schrieb:
> Hi Tom,
>
> I always had IoC in mind when I wrote the original configuration stuff.
> So it should be easy to shift to any micro-container.
>
> I'm really positive about such a change. I'm simply not sure which
> product will be th ebest for our purpose.
> It should be
> - stable
> - minimum footprint
> - avoid a vendor lock in
> - easy to integrate of J2EE environments,
> etc.
>
> I had a short look at PicoContainer some time ago and it looked like a
> very clever piece of code...
> I can't comment ob Avalon, Spring BeanFactory etc.
>
> cheers,
> Thomas
>
> Thomas Dudziak wrote:
>
>> Hi folks,
>>
>> Armin and I were chatting the other day about making the whole
>> initialization and configuration of OJB more flexible and
>> loose-coupled. So I ventured into the 'depths' of IoC, more
>> specifically PicoContainer and Spring, to see whether they could help
>> us there. As a result I came up with the concept of an ObjectFactory
>> (see the interface below) as well as two implementations using
>> PicoContainer and Spring's BeanFactory, respectively.
>> In short, an ObjectFactory offers the following functions:
>>
>> * configuration of the implementation classes for interfaces/abstract
>> classes (via setImplementationClass)
>>
>> * dependencies to other factory-managed types that are stated in the
>> constructor of the component are automatically filled by the factory
>>
>> * singleton instances can be defined (via setSingletonInstance)
>>
>> * factories are hierarchical, the child factory directs a request to
>> its parent if it cannot answer it
>>
>> * the factory configures newly created instances automatically using
>> standard bean properties of 'normal' java types (i.e. primitives,
>> String etc.)
>>
>>
>>
>> Using such factories IMO would bring us the following benefits
>>
>>
>>
>> * Loose coupling - a component (i.e. its facade object) only has to
>> state in its constructor that it wants e.g. a PersistenceBroker
>> instance and does not have to care where it gets it from (IoC)
>>
>> * Via hierarchical factories and singleton instances it is easy to
>> wire 1:n scenarios. I.e. for wiring one OJB instance with its n
>> PersistenceConfiguration instances, the OJB instance registers itself
>> as a singleton at its factory. When a PC instance is created somwehere
>> within the context of the OJB instance via
>> factory.getInstance(PersistenceConfiguration.class), it will want an
>> OJB instance (constructor arg) and will automatically receive the
>> singleton OJB instance.
>>
>> * Automatic configuration (e.g. OJB.properties) using fully qualified
>> properties with the default values defined in the components itself.
>> E.g. it would be possible to specify both
>>
>> org.apache.ojb.broker.PersistenceBroker.someProperty=someValue
>> org.apache.ojb.broker.DefaultPersistenceBrokerImpl.someOtherProperty=someOtherValue
>>
>>
>> The first property will be set at all PB instances regardless of the
>> impl type whereas the second one will only be used for PB instances of
>> this particular type. Using the special property
>>
>> org.apache.ojb.broker.PersistenceBroker.class=someClass
>>
>> the implementation class for PB can be configured.
>> This allows for hot-plugging of new components without having to
>> recompile OJB or even change source code in it simply by adding the
>> classes to the classpath and setting the properties in OJB.properties.
>>
>>
>>
>> To be able to use this scheme all that is necessary would be that the
>> components adhere to these two rules:
>>
>>
>> * All components that a component is dependant upon, must be specified
>> in its constructor. Multiple constructors are possible (the factory
>> will choose the greediest one that it can supply instances to).
>>
>> * All other properties (settings) have to be specified via simple bean
>> properties (get/set). The default value is thus specified in the
>> component.
>>
>>
>>
>> I'd like to know what you think about this ? Specifically, I'd like to
>> use the PicoContainer impl as the default one (which adds a 49k lib to
>> the runtime OJB requirements) and to provide the Spring impl as an
>> alternative (e.g. for Spring integration of OJB) which also adds a
>> 250k lib (spring-core) to the OJB-build requirements.
>>
>> regards,
>> Tom
>>
>>
>>
>> -------------------------------------------------------------------------------------
>>
>>
>> package org.apache.ojb.broker.conf;
>>
>> import java.util.HashMap;
>> import java.util.Properties;
>>
>> /**
>> * Defines a factory which is used to create and maintain configurable
>> components.
>> * The component objects are initialized via the IoC principle.
>> Factories are
>> * hierarchical where the children factories look at their parents if
>> they cannot
>> * handle a request themselves.
>> *
>> * @author Thomas Dudziak
>> */
>> public interface ObjectFactory
>> {
>> /**
>> * Creates a child factory.
>> *
>> * @return The new child factory
>> */
>> public ObjectFactory createChildFactory();
>>
>> /**
>> * Sets the parent factory.
>> *
>> * @param parent The parent factory
>> */
>> public void setParentFactory(ObjectFactory parent);
>>
>> /**
>> * Returns the parent factory if any.
>> *
>> * @return The parent factory
>> */
>> public ObjectFactory getParentFactory();
>>
>> /**
>> * Returns the registered implementation class for the given type.
>> *
>> * @param type The type to register the implementation for
>> * @return The registered class
>> */
>> public Class getImplementationClass(Class type);
>>
>> /**
>> * Registers an implementation class for the given type (and only
>> for it
>> * but not for super- or subtypes of it).
>> *
>> * @param type The type to register the implementation for
>> * @param implClass The implementation class to register
>> */
>> public void setImplementationClass(Class type, Class implClass);
>>
>> /**
>> * Registers the given object as the singleton instance for the
>> given type. Note that
>> * singleton instances are assumed to be already configured.
>> *
>> * @param clazz The class to register the object for
>> * @param obj The object
>> */
>> public void setSingletonInstance(Class clazz, Object obj);
>>
>> /**
>> * Return a new instance of the implementation for the given class.
>> * If a singleton instance is registered for this type, then this
>> instance
>> * is returned. The instance will be configured except if it is a
>> singleton
>> * instance.
>> *
>> * @param clazz The class
>> * @return The instance
>> * @exception ObjectCreationException If no implementation is
>> configured for this type
>> * @exception ObjectConfigurationException If the instance could
>> not be configured
>> */
>> public Object getInstance(Class clazz) throws
>> ObjectCreationException, ObjectConfigurationException;
>>
>> /**
>> * Returns all properties specifically defined for the specified type.
>> *
>> * @param clazz The type
>> * @return The properties or <code>null</code> if no properties are
>> defined for this type
>> */
>> public HashMap getProperties(Class clazz);
>>
>> /**
>> * Returns the given property.
>> *
>> * @param clazz The type that the property is set for
>> * @param name The property name
>> * @return The value or <code>null</code> if there is no such property
>> */
>> public Object getProperty(Class clazz, String name);
>>
>> /**
>> * Sets the given property.
>> *
>> * @param clazz The type to set the property for
>> * @param name The property name
>> * @param value The value; use <code>null</code> to unset the property
>> * @param force If <code>true</code> then an existing property will
>> be overriden, otherwise
>> * it will only be set if not yet defined
>> */
>> public void setProperty(Class clazz, String name, Object value,
>> boolean force);
>>
>> /**
>> * Sets the properties. The names of the properties are evaulated as
>> * fully qualified property names, e.g. package.Class.propertyName.
>> *
>> * @param props The properties
>> * @param force If <code>true</code> then an existing property will
>> be overriden, otherwise
>> * it will only be set if not yet defined
>> */
>> public void setProperties(Properties props, boolean force) throws
>> FactoryInitializationException;
>>
>> /**
>> * Configures the given object, i.e. sets all properties that are
>> defined
>> * for the types of the object beginning with thefarthestbasetypes.
>> *
>> * @param obj The object
>> */
>> public void configure(Object obj) throws ObjectConfigurationException;
>> }
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Thomas Dudziak <to...@first.fhg.de>.
Brian McCallister wrote:
> I like pico a lot. It is more elegent than Spring, imho, but some
> things are less convenient.
Yep, noticed that as well ...
> Really, using either one should be pretty easy (ie, use both).
> Internally we can use whichever, but making it friendly for either
> should be very doable.
Using an interface removes the necessity to choose one. In fact I have
finished both the Pico and the Spring implementation (both using
Constructor Injection).
> On Tue, 26 Oct 2004 19:48:58 +0200, Thomas Mahler <th...@web.de> wrote:
>
>>I always had IoC in mind when I wrote the original configuration stuff.
>>So it should be easy to shift to any micro-container.
It is probably mostly a matter of moving the configuration stuff
(default values) into the components and make them 'IoC-friendlier',
i.e. create bean properties and adjust the constructors.
>>I'm really positive about such a change. I'm simply not sure which
>>product will be th ebest for our purpose.
>>It should be
>>- stable
>>- minimum footprint
>>- avoid a vendor lock in
>>- easy to integrate of J2EE environments,
>>etc.
Don't know about the stability of Pico or Spring but I think for our
purposes they both are quite stable. Vendor lockin should not be a
problem because ComponentContainer (formerly known as ObjectFactory)
implementations for our purposes are quite easily done (the Spring impl
is about 110 lines of code including comments).
AFAIK both Pico and Spring can be easily used within an EJB container
(the Geronimo guys seem to use Pico to some extent ?), and since the IoC
container does not load classes - this is usually done within the
context of OJB using the classloader configured for OJB - there should
be no problems in this regard.
Also, it should be quite doable to provide a JNDI implementation of the
ComponentContainer.
>>I had a short look at PicoContainer some time ago and it looked like a
>>very clever piece of code...
>>I can't comment ob Avalon, Spring BeanFactory etc.
A Spring variant is already in place (because I want to use OJB fully
integrated into Spring, this includes DataSources, hint hint). For OJB
standalone I'm in favor of Pico though, simply because of the smaller
footprint of the library (49k vs. 250k).
An Avalon impl should be easy too, same as with HiveMind. But I don't
think OJB itself should provide them as this would only increase the
amount of libraries necessary for building OJB.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Robert Sfeir <ro...@codepuccino.com>.
+1 on IoC for sure, recommend based on Spring but only for selfish
reasons as well as the popularity Spring is gaining.
R
> On Tue, 26 Oct 2004 19:48:58 +0200, Thomas Mahler <th...@web.de>
> wrote:
>> Hi Tom,
>>
>> I always had IoC in mind when I wrote the original configuration
>> stuff.
>> So it should be easy to shift to any micro-container.
>>
>> I'm really positive about such a change. I'm simply not sure which
>> product will be th ebest for our purpose.
>> It should be
>> - stable
>> - minimum footprint
>> - avoid a vendor lock in
>> - easy to integrate of J2EE environments,
>> etc.
>>
>> I had a short look at PicoContainer some time ago and it looked like a
>> very clever piece of code...
>> I can't comment ob Avalon, Spring BeanFactory etc.
>>
>> cheers,
>> Thomas
>>
>>
>>
>> Thomas Dudziak wrote:
>>
>>> Hi folks,
>>>
>>> Armin and I were chatting the other day about making the whole
>>> initialization and configuration of OJB more flexible and
>>> loose-coupled.
>>> So I ventured into the 'depths' of IoC, more specifically
>>> PicoContainer
>>> and Spring, to see whether they could help us there. As a result I
>>> came
>>> up with the concept of an ObjectFactory (see the interface below) as
>>> well as two implementations using PicoContainer and Spring's
>>> BeanFactory, respectively.
>>> In short, an ObjectFactory offers the following functions:
>>>
>>> * configuration of the implementation classes for interfaces/abstract
>>> classes (via setImplementationClass)
>>>
>>> * dependencies to other factory-managed types that are stated in the
>>> constructor of the component are automatically filled by the factory
>>>
>>> * singleton instances can be defined (via setSingletonInstance)
>>>
>>> * factories are hierarchical, the child factory directs a request to
>>> its
>>> parent if it cannot answer it
>>>
>>> * the factory configures newly created instances automatically using
>>> standard bean properties of 'normal' java types (i.e. primitives,
>>> String
>>> etc.)
>>>
>>>
>>>
>>> Using such factories IMO would bring us the following benefits
>>>
>>>
>>>
>>> * Loose coupling - a component (i.e. its facade object) only has to
>>> state in its constructor that it wants e.g. a PersistenceBroker
>>> instance
>>> and does not have to care where it gets it from (IoC)
>>>
>>> * Via hierarchical factories and singleton instances it is easy to
>>> wire
>>> 1:n scenarios. I.e. for wiring one OJB instance with its n
>>> PersistenceConfiguration instances, the OJB instance registers
>>> itself as
>>> a singleton at its factory. When a PC instance is created somwehere
>>> within the context of the OJB instance via
>>> factory.getInstance(PersistenceConfiguration.class), it will want an
>>> OJB
>>> instance (constructor arg) and will automatically receive the
>>> singleton
>>> OJB instance.
>>>
>>> * Automatic configuration (e.g. OJB.properties) using fully qualified
>>> properties with the default values defined in the components itself.
>>> E.g. it would be possible to specify both
>>>
>>> org.apache.ojb.broker.PersistenceBroker.someProperty=someValue
>>> org.apache.ojb.broker.DefaultPersistenceBrokerImpl.someOtherProperty=
>>> someOtherValue
>>>
>>>
>>> The first property will be set at all PB instances regardless of the
>>> impl type whereas the second one will only be used for PB instances
>>> of
>>> this particular type. Using the special property
>>>
>>> org.apache.ojb.broker.PersistenceBroker.class=someClass
>>>
>>> the implementation class for PB can be configured.
>>> This allows for hot-plugging of new components without having to
>>> recompile OJB or even change source code in it simply by adding the
>>> classes to the classpath and setting the properties in
>>> OJB.properties.
>>>
>>>
>>>
>>> To be able to use this scheme all that is necessary would be that the
>>> components adhere to these two rules:
>>>
>>>
>>> * All components that a component is dependant upon, must be
>>> specified
>>> in its constructor. Multiple constructors are possible (the factory
>>> will
>>> choose the greediest one that it can supply instances to).
>>>
>>> * All other properties (settings) have to be specified via simple
>>> bean
>>> properties (get/set). The default value is thus specified in the
>>> component.
>>>
>>>
>>>
>>> I'd like to know what you think about this ? Specifically, I'd like
>>> to
>>> use the PicoContainer impl as the default one (which adds a 49k lib
>>> to
>>> the runtime OJB requirements) and to provide the Spring impl as an
>>> alternative (e.g. for Spring integration of OJB) which also adds a
>>> 250k
>>> lib (spring-core) to the OJB-build requirements.
>>>
>>> regards,
>>> Tom
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ----------------
>>>
>>>
>>> package org.apache.ojb.broker.conf;
>>>
>>> import java.util.HashMap;
>>> import java.util.Properties;
>>>
>>> /**
>>> * Defines a factory which is used to create and maintain configurable
>>> components.
>>> * The component objects are initialized via the IoC principle.
>>> Factories
>>> are
>>> * hierarchical where the children factories look at their parents if
>>> they cannot
>>> * handle a request themselves.
>>> *
>>> * @author Thomas Dudziak
>>> */
>>> public interface ObjectFactory
>>> {
>>> /**
>>> * Creates a child factory.
>>> *
>>> * @return The new child factory
>>> */
>>> public ObjectFactory createChildFactory();
>>>
>>> /**
>>> * Sets the parent factory.
>>> *
>>> * @param parent The parent factory
>>> */
>>> public void setParentFactory(ObjectFactory parent);
>>>
>>> /**
>>> * Returns the parent factory if any.
>>> *
>>> * @return The parent factory
>>> */
>>> public ObjectFactory getParentFactory();
>>>
>>> /**
>>> * Returns the registered implementation class for the given type.
>>> *
>>> * @param type The type to register the implementation for
>>> * @return The registered class
>>> */
>>> public Class getImplementationClass(Class type);
>>>
>>> /**
>>> * Registers an implementation class for the given type (and only
>>> for it
>>> * but not for super- or subtypes of it).
>>> *
>>> * @param type The type to register the implementation for
>>> * @param implClass The implementation class to register
>>> */
>>> public void setImplementationClass(Class type, Class implClass);
>>>
>>> /**
>>> * Registers the given object as the singleton instance for the
>>> given
>>> type. Note that
>>> * singleton instances are assumed to be already configured.
>>> *
>>> * @param clazz The class to register the object for
>>> * @param obj The object
>>> */
>>> public void setSingletonInstance(Class clazz, Object obj);
>>>
>>> /**
>>> * Return a new instance of the implementation for the given
>>> class.
>>> * If a singleton instance is registered for this type, then this
>>> instance
>>> * is returned. The instance will be configured except if it is a
>>> singleton
>>> * instance.
>>> *
>>> * @param clazz The class
>>> * @return The instance
>>> * @exception ObjectCreationException If no implementation is
>>> configured for this type
>>> * @exception ObjectConfigurationException If the instance could
>>> not
>>> be configured
>>> */
>>> public Object getInstance(Class clazz) throws
>>> ObjectCreationException, ObjectConfigurationException;
>>>
>>> /**
>>> * Returns all properties specifically defined for the specified
>>> type.
>>> *
>>> * @param clazz The type
>>> * @return The properties or <code>null</code> if no properties
>>> are
>>> defined for this type
>>> */
>>> public HashMap getProperties(Class clazz);
>>>
>>> /**
>>> * Returns the given property.
>>> *
>>> * @param clazz The type that the property is set for
>>> * @param name The property name
>>> * @return The value or <code>null</code> if there is no such
>>> property
>>> */
>>> public Object getProperty(Class clazz, String name);
>>>
>>> /**
>>> * Sets the given property.
>>> *
>>> * @param clazz The type to set the property for
>>> * @param name The property name
>>> * @param value The value; use <code>null</code> to unset the
>>> property
>>> * @param force If <code>true</code> then an existing property
>>> will
>>> be overriden, otherwise
>>> * it will only be set if not yet defined
>>> */
>>> public void setProperty(Class clazz, String name, Object value,
>>> boolean force);
>>>
>>> /**
>>> * Sets the properties. The names of the properties are evaulated
>>> as
>>> * fully qualified property names, e.g.
>>> package.Class.propertyName.
>>> *
>>> * @param props The properties
>>> * @param force If <code>true</code> then an existing property
>>> will
>>> be overriden, otherwise
>>> * it will only be set if not yet defined
>>> */
>>> public void setProperties(Properties props, boolean force) throws
>>> FactoryInitializationException;
>>>
>>> /**
>>> * Configures the given object, i.e. sets all properties that are
>>> defined
>>> * for the types of the object beginning with
>>> thefarthestbasetypes.
>>> *
>>> * @param obj The object
>>> */
>>> public void configure(Object obj) throws
>>> ObjectConfigurationException;
>>> }
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Brian McCallister <bm...@gmail.com>.
I like pico a lot. It is more elegent than Spring, imho, but some
things are less convenient.
Really, using either one should be pretty easy (ie, use both).
Internally we can use whichever, but making it friendly for either
should be very doable.
+1 for constructor dependency injection either way!
-Brian
On Tue, 26 Oct 2004 19:48:58 +0200, Thomas Mahler <th...@web.de> wrote:
> Hi Tom,
>
> I always had IoC in mind when I wrote the original configuration stuff.
> So it should be easy to shift to any micro-container.
>
> I'm really positive about such a change. I'm simply not sure which
> product will be th ebest for our purpose.
> It should be
> - stable
> - minimum footprint
> - avoid a vendor lock in
> - easy to integrate of J2EE environments,
> etc.
>
> I had a short look at PicoContainer some time ago and it looked like a
> very clever piece of code...
> I can't comment ob Avalon, Spring BeanFactory etc.
>
> cheers,
> Thomas
>
>
>
> Thomas Dudziak wrote:
>
> > Hi folks,
> >
> > Armin and I were chatting the other day about making the whole
> > initialization and configuration of OJB more flexible and loose-coupled.
> > So I ventured into the 'depths' of IoC, more specifically PicoContainer
> > and Spring, to see whether they could help us there. As a result I came
> > up with the concept of an ObjectFactory (see the interface below) as
> > well as two implementations using PicoContainer and Spring's
> > BeanFactory, respectively.
> > In short, an ObjectFactory offers the following functions:
> >
> > * configuration of the implementation classes for interfaces/abstract
> > classes (via setImplementationClass)
> >
> > * dependencies to other factory-managed types that are stated in the
> > constructor of the component are automatically filled by the factory
> >
> > * singleton instances can be defined (via setSingletonInstance)
> >
> > * factories are hierarchical, the child factory directs a request to its
> > parent if it cannot answer it
> >
> > * the factory configures newly created instances automatically using
> > standard bean properties of 'normal' java types (i.e. primitives, String
> > etc.)
> >
> >
> >
> > Using such factories IMO would bring us the following benefits
> >
> >
> >
> > * Loose coupling - a component (i.e. its facade object) only has to
> > state in its constructor that it wants e.g. a PersistenceBroker instance
> > and does not have to care where it gets it from (IoC)
> >
> > * Via hierarchical factories and singleton instances it is easy to wire
> > 1:n scenarios. I.e. for wiring one OJB instance with its n
> > PersistenceConfiguration instances, the OJB instance registers itself as
> > a singleton at its factory. When a PC instance is created somwehere
> > within the context of the OJB instance via
> > factory.getInstance(PersistenceConfiguration.class), it will want an OJB
> > instance (constructor arg) and will automatically receive the singleton
> > OJB instance.
> >
> > * Automatic configuration (e.g. OJB.properties) using fully qualified
> > properties with the default values defined in the components itself.
> > E.g. it would be possible to specify both
> >
> > org.apache.ojb.broker.PersistenceBroker.someProperty=someValue
> > org.apache.ojb.broker.DefaultPersistenceBrokerImpl.someOtherProperty=someOtherValue
> >
> >
> > The first property will be set at all PB instances regardless of the
> > impl type whereas the second one will only be used for PB instances of
> > this particular type. Using the special property
> >
> > org.apache.ojb.broker.PersistenceBroker.class=someClass
> >
> > the implementation class for PB can be configured.
> > This allows for hot-plugging of new components without having to
> > recompile OJB or even change source code in it simply by adding the
> > classes to the classpath and setting the properties in OJB.properties.
> >
> >
> >
> > To be able to use this scheme all that is necessary would be that the
> > components adhere to these two rules:
> >
> >
> > * All components that a component is dependant upon, must be specified
> > in its constructor. Multiple constructors are possible (the factory will
> > choose the greediest one that it can supply instances to).
> >
> > * All other properties (settings) have to be specified via simple bean
> > properties (get/set). The default value is thus specified in the component.
> >
> >
> >
> > I'd like to know what you think about this ? Specifically, I'd like to
> > use the PicoContainer impl as the default one (which adds a 49k lib to
> > the runtime OJB requirements) and to provide the Spring impl as an
> > alternative (e.g. for Spring integration of OJB) which also adds a 250k
> > lib (spring-core) to the OJB-build requirements.
> >
> > regards,
> > Tom
> >
> >
> >
> > -------------------------------------------------------------------------------------
> >
> >
> > package org.apache.ojb.broker.conf;
> >
> > import java.util.HashMap;
> > import java.util.Properties;
> >
> > /**
> > * Defines a factory which is used to create and maintain configurable
> > components.
> > * The component objects are initialized via the IoC principle. Factories
> > are
> > * hierarchical where the children factories look at their parents if
> > they cannot
> > * handle a request themselves.
> > *
> > * @author Thomas Dudziak
> > */
> > public interface ObjectFactory
> > {
> > /**
> > * Creates a child factory.
> > *
> > * @return The new child factory
> > */
> > public ObjectFactory createChildFactory();
> >
> > /**
> > * Sets the parent factory.
> > *
> > * @param parent The parent factory
> > */
> > public void setParentFactory(ObjectFactory parent);
> >
> > /**
> > * Returns the parent factory if any.
> > *
> > * @return The parent factory
> > */
> > public ObjectFactory getParentFactory();
> >
> > /**
> > * Returns the registered implementation class for the given type.
> > *
> > * @param type The type to register the implementation for
> > * @return The registered class
> > */
> > public Class getImplementationClass(Class type);
> >
> > /**
> > * Registers an implementation class for the given type (and only for it
> > * but not for super- or subtypes of it).
> > *
> > * @param type The type to register the implementation for
> > * @param implClass The implementation class to register
> > */
> > public void setImplementationClass(Class type, Class implClass);
> >
> > /**
> > * Registers the given object as the singleton instance for the given
> > type. Note that
> > * singleton instances are assumed to be already configured.
> > *
> > * @param clazz The class to register the object for
> > * @param obj The object
> > */
> > public void setSingletonInstance(Class clazz, Object obj);
> >
> > /**
> > * Return a new instance of the implementation for the given class.
> > * If a singleton instance is registered for this type, then this
> > instance
> > * is returned. The instance will be configured except if it is a
> > singleton
> > * instance.
> > *
> > * @param clazz The class
> > * @return The instance
> > * @exception ObjectCreationException If no implementation is
> > configured for this type
> > * @exception ObjectConfigurationException If the instance could not
> > be configured
> > */
> > public Object getInstance(Class clazz) throws
> > ObjectCreationException, ObjectConfigurationException;
> >
> > /**
> > * Returns all properties specifically defined for the specified type.
> > *
> > * @param clazz The type
> > * @return The properties or <code>null</code> if no properties are
> > defined for this type
> > */
> > public HashMap getProperties(Class clazz);
> >
> > /**
> > * Returns the given property.
> > *
> > * @param clazz The type that the property is set for
> > * @param name The property name
> > * @return The value or <code>null</code> if there is no such property
> > */
> > public Object getProperty(Class clazz, String name);
> >
> > /**
> > * Sets the given property.
> > *
> > * @param clazz The type to set the property for
> > * @param name The property name
> > * @param value The value; use <code>null</code> to unset the property
> > * @param force If <code>true</code> then an existing property will
> > be overriden, otherwise
> > * it will only be set if not yet defined
> > */
> > public void setProperty(Class clazz, String name, Object value,
> > boolean force);
> >
> > /**
> > * Sets the properties. The names of the properties are evaulated as
> > * fully qualified property names, e.g. package.Class.propertyName.
> > *
> > * @param props The properties
> > * @param force If <code>true</code> then an existing property will
> > be overriden, otherwise
> > * it will only be set if not yet defined
> > */
> > public void setProperties(Properties props, boolean force) throws
> > FactoryInitializationException;
> >
> > /**
> > * Configures the given object, i.e. sets all properties that are
> > defined
> > * for the types of the object beginning with thefarthestbasetypes.
> > *
> > * @param obj The object
> > */
> > public void configure(Object obj) throws ObjectConfigurationException;
> > }
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-dev-help@db.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Thomas Mahler <th...@web.de>.
Hi Tom,
I always had IoC in mind when I wrote the original configuration stuff.
So it should be easy to shift to any micro-container.
I'm really positive about such a change. I'm simply not sure which
product will be th ebest for our purpose.
It should be
- stable
- minimum footprint
- avoid a vendor lock in
- easy to integrate of J2EE environments,
etc.
I had a short look at PicoContainer some time ago and it looked like a
very clever piece of code...
I can't comment ob Avalon, Spring BeanFactory etc.
cheers,
Thomas
Thomas Dudziak wrote:
> Hi folks,
>
> Armin and I were chatting the other day about making the whole
> initialization and configuration of OJB more flexible and loose-coupled.
> So I ventured into the 'depths' of IoC, more specifically PicoContainer
> and Spring, to see whether they could help us there. As a result I came
> up with the concept of an ObjectFactory (see the interface below) as
> well as two implementations using PicoContainer and Spring's
> BeanFactory, respectively.
> In short, an ObjectFactory offers the following functions:
>
> * configuration of the implementation classes for interfaces/abstract
> classes (via setImplementationClass)
>
> * dependencies to other factory-managed types that are stated in the
> constructor of the component are automatically filled by the factory
>
> * singleton instances can be defined (via setSingletonInstance)
>
> * factories are hierarchical, the child factory directs a request to its
> parent if it cannot answer it
>
> * the factory configures newly created instances automatically using
> standard bean properties of 'normal' java types (i.e. primitives, String
> etc.)
>
>
>
> Using such factories IMO would bring us the following benefits
>
>
>
> * Loose coupling - a component (i.e. its facade object) only has to
> state in its constructor that it wants e.g. a PersistenceBroker instance
> and does not have to care where it gets it from (IoC)
>
> * Via hierarchical factories and singleton instances it is easy to wire
> 1:n scenarios. I.e. for wiring one OJB instance with its n
> PersistenceConfiguration instances, the OJB instance registers itself as
> a singleton at its factory. When a PC instance is created somwehere
> within the context of the OJB instance via
> factory.getInstance(PersistenceConfiguration.class), it will want an OJB
> instance (constructor arg) and will automatically receive the singleton
> OJB instance.
>
> * Automatic configuration (e.g. OJB.properties) using fully qualified
> properties with the default values defined in the components itself.
> E.g. it would be possible to specify both
>
> org.apache.ojb.broker.PersistenceBroker.someProperty=someValue
> org.apache.ojb.broker.DefaultPersistenceBrokerImpl.someOtherProperty=someOtherValue
>
>
> The first property will be set at all PB instances regardless of the
> impl type whereas the second one will only be used for PB instances of
> this particular type. Using the special property
>
> org.apache.ojb.broker.PersistenceBroker.class=someClass
>
> the implementation class for PB can be configured.
> This allows for hot-plugging of new components without having to
> recompile OJB or even change source code in it simply by adding the
> classes to the classpath and setting the properties in OJB.properties.
>
>
>
> To be able to use this scheme all that is necessary would be that the
> components adhere to these two rules:
>
>
> * All components that a component is dependant upon, must be specified
> in its constructor. Multiple constructors are possible (the factory will
> choose the greediest one that it can supply instances to).
>
> * All other properties (settings) have to be specified via simple bean
> properties (get/set). The default value is thus specified in the component.
>
>
>
> I'd like to know what you think about this ? Specifically, I'd like to
> use the PicoContainer impl as the default one (which adds a 49k lib to
> the runtime OJB requirements) and to provide the Spring impl as an
> alternative (e.g. for Spring integration of OJB) which also adds a 250k
> lib (spring-core) to the OJB-build requirements.
>
> regards,
> Tom
>
>
>
> -------------------------------------------------------------------------------------
>
>
> package org.apache.ojb.broker.conf;
>
> import java.util.HashMap;
> import java.util.Properties;
>
> /**
> * Defines a factory which is used to create and maintain configurable
> components.
> * The component objects are initialized via the IoC principle. Factories
> are
> * hierarchical where the children factories look at their parents if
> they cannot
> * handle a request themselves.
> *
> * @author Thomas Dudziak
> */
> public interface ObjectFactory
> {
> /**
> * Creates a child factory.
> *
> * @return The new child factory
> */
> public ObjectFactory createChildFactory();
>
> /**
> * Sets the parent factory.
> *
> * @param parent The parent factory
> */
> public void setParentFactory(ObjectFactory parent);
>
> /**
> * Returns the parent factory if any.
> *
> * @return The parent factory
> */
> public ObjectFactory getParentFactory();
>
> /**
> * Returns the registered implementation class for the given type.
> *
> * @param type The type to register the implementation for
> * @return The registered class
> */
> public Class getImplementationClass(Class type);
>
> /**
> * Registers an implementation class for the given type (and only for it
> * but not for super- or subtypes of it).
> *
> * @param type The type to register the implementation for
> * @param implClass The implementation class to register
> */
> public void setImplementationClass(Class type, Class implClass);
>
> /**
> * Registers the given object as the singleton instance for the given
> type. Note that
> * singleton instances are assumed to be already configured.
> *
> * @param clazz The class to register the object for
> * @param obj The object
> */
> public void setSingletonInstance(Class clazz, Object obj);
>
> /**
> * Return a new instance of the implementation for the given class.
> * If a singleton instance is registered for this type, then this
> instance
> * is returned. The instance will be configured except if it is a
> singleton
> * instance.
> *
> * @param clazz The class
> * @return The instance
> * @exception ObjectCreationException If no implementation is
> configured for this type
> * @exception ObjectConfigurationException If the instance could not
> be configured
> */
> public Object getInstance(Class clazz) throws
> ObjectCreationException, ObjectConfigurationException;
>
> /**
> * Returns all properties specifically defined for the specified type.
> *
> * @param clazz The type
> * @return The properties or <code>null</code> if no properties are
> defined for this type
> */
> public HashMap getProperties(Class clazz);
>
> /**
> * Returns the given property.
> *
> * @param clazz The type that the property is set for
> * @param name The property name
> * @return The value or <code>null</code> if there is no such property
> */
> public Object getProperty(Class clazz, String name);
>
> /**
> * Sets the given property.
> *
> * @param clazz The type to set the property for
> * @param name The property name
> * @param value The value; use <code>null</code> to unset the property
> * @param force If <code>true</code> then an existing property will
> be overriden, otherwise
> * it will only be set if not yet defined
> */
> public void setProperty(Class clazz, String name, Object value,
> boolean force);
>
> /**
> * Sets the properties. The names of the properties are evaulated as
> * fully qualified property names, e.g. package.Class.propertyName.
> *
> * @param props The properties
> * @param force If <code>true</code> then an existing property will
> be overriden, otherwise
> * it will only be set if not yet defined
> */
> public void setProperties(Properties props, boolean force) throws
> FactoryInitializationException;
>
> /**
> * Configures the given object, i.e. sets all properties that are
> defined
> * for the types of the object beginning with thefarthestbasetypes.
> *
> * @param obj The object
> */
> public void configure(Object obj) throws ObjectConfigurationException;
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Thomas Dudziak <to...@first.fhg.de>.
Leandro Rodrigo Saad Cruz wrote:
>>Right, didn't have the time yet to look at it in detail, but my first
>>impression was that an easier way to accomplish this is to have the
>>factory-class handled by the ComponentContainer too. This way, you can
>>have singleton instances (the factory-method is not required to be
>>static). Then there would be no need to add the useObjectFactory
>>attribute and you won't have to wire this factory into OJB. A simple
>>call to container.getInstance(classDesc.getFactoryClass()) - or better a
>>variant of this method that creates a singleton if not yet defined -
>>would suffice, wdyt ?
>>
>>
>
>The problem is that we don't know into which container environment the
>persistent objects created by OJB should be used (pico, avalon, spring,
>etc) so.. as long as we can handle an *outside* instance of a
>ObjectFactory to the RowReader, we can plug ojb into any framework that
>needs that !
>
>So.. the ComponentContainer acts a object registry handling the
>ObjectFactory to the RowReader as needed, but, the ComponentContainer
>should be able to handle instances of ObjectFactor instantiated outside
>OJB !
>
>
Hmm, I don't see the problem here ? Say, you specify a class
SpringIntegration as the factory class of a certain class descriptor A
and the method createA as the factory method. If now OJB wants to create
an object of type A, it fetches an instance of SpringIntegration (which
might or might not be a singleton) from the ComponentContainer and
invokes createA. The ComponentContainer itself can create the
SpringIntegration instance or it might have been created outside of OJB
and then set via
OJB.getComponentContainer().setSingletonInstance(SpringIntegration.class,
integrationInstance) or something similar. In this case it does not
matter whether the ComponentContainer itself uses Pico or Spring or
whatever since the SpringIntegration is free to do whatever it takes to
create the A instance.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Tue, 2004-10-26 at 16:51 +0200, Thomas Dudziak wrote:
> No problem, the name is not chiseled in stone :-) How about
> ComponentContainer or something to avoid confusion with object-handling
> altogether ?
Sure !
> Right, didn't have the time yet to look at it in detail, but my first
> impression was that an easier way to accomplish this is to have the
> factory-class handled by the ComponentContainer too. This way, you can
> have singleton instances (the factory-method is not required to be
> static). Then there would be no need to add the useObjectFactory
> attribute and you won't have to wire this factory into OJB. A simple
> call to container.getInstance(classDesc.getFactoryClass()) - or better a
> variant of this method that creates a singleton if not yet defined -
> would suffice, wdyt ?
The problem is that we don't know into which container environment the
persistent objects created by OJB should be used (pico, avalon, spring,
etc) so.. as long as we can handle an *outside* instance of a
ObjectFactory to the RowReader, we can plug ojb into any framework that
needs that !
So.. the ComponentContainer acts a object registry handling the
ObjectFactory to the RowReader as needed, but, the ComponentContainer
should be able to handle instances of ObjectFactor instantiated outside
OJB !
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Thomas Dudziak <to...@first.fhg.de>.
Leandro Rodrigo Saad Cruz wrote:
>On Tue, 2004-10-26 at 15:10 +0200, Thomas Dudziak wrote:
>
>
>>Hi folks,
>>
>>Armin and I were chatting the other day about making the whole
>>initialization and configuration of OJB more flexible and loose-coupled.
>>So I ventured into the 'depths' of IoC, more specifically PicoContainer
>>and Spring, to see whether they could help us there. As a result I came
>>up with the concept of an ObjectFactory (see the interface below) as
>>well as two implementations using PicoContainer and Spring's
>>BeanFactory, respectively.
>>
>>
>
>Nice. but could we call it ObjectContainer, or something like that ?!
>
>
No problem, the name is not chiseled in stone :-) How about
ComponentContainer or something to avoid confusion with object-handling
altogether ?
>I'm asking this because I'm working on a ObjectFactory class that should
>be used to create instances of objects on RowReader, instead of using
>the ClassHelper. I'm just writing some tests to commit.
>It's use is optional, just add an attribute to your repository.xml.
>I'm working on this because we don't have a nice solution to integrate
>persistent objects into a container managed environment.
>The initialization-method is just not good enough !
>
>
Right, didn't have the time yet to look at it in detail, but my first
impression was that an easier way to accomplish this is to have the
factory-class handled by the ComponentContainer too. This way, you can
have singleton instances (the factory-method is not required to be
static). Then there would be no need to add the useObjectFactory
attribute and you won't have to wire this factory into OJB. A simple
call to container.getInstance(classDesc.getFactoryClass()) - or better a
variant of this method that creates a singleton if not yet defined -
would suffice, wdyt ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Tue, 2004-10-26 at 15:10 +0200, Thomas Dudziak wrote:
> Hi folks,
>
> Armin and I were chatting the other day about making the whole
> initialization and configuration of OJB more flexible and loose-coupled.
> So I ventured into the 'depths' of IoC, more specifically PicoContainer
> and Spring, to see whether they could help us there. As a result I came
> up with the concept of an ObjectFactory (see the interface below) as
> well as two implementations using PicoContainer and Spring's
> BeanFactory, respectively.
Nice. but could we call it ObjectContainer, or something like that ?!
I'm asking this because I'm working on a ObjectFactory class that should
be used to create instances of objects on RowReader, instead of using
the ClassHelper. I'm just writing some tests to commit.
It's use is optional, just add an attribute to your repository.xml.
I'm working on this because we don't have a nice solution to integrate
persistent objects into a container managed environment.
The initialization-method is just not good enough !
...
> Using such factories IMO would bring us the following benefits
...
> I'd like to know what you think about this ? Specifically, I'd like to
> use the PicoContainer impl as the default one (which adds a 49k lib to
> the runtime OJB requirements) and to provide the Spring impl as an
> alternative (e.g. for Spring integration of OJB) which also adds a 250k
> lib (spring-core) to the OJB-build requirements.
I think this is great. OJB lacks a formal dependency injection
mechanism.
I talked with Thomas Mahler about this a long time ago.
On that time.. I was trying to use the avalon framework (which I think
is the best one) for the job.
But I don't know if all developers agree on that.
Anyway. I'm confident that this is the right direction !
++1
>
> regards,
> Tom
>
>
>
> -------------------------------------------------------------------------------------
>
> package org.apache.ojb.broker.conf;
>
> import java.util.HashMap;
> import java.util.Properties;
>
> /**
> * Defines a factory which is used to create and maintain configurable
> components.
> * The component objects are initialized via the IoC principle.
> Factories are
> * hierarchical where the children factories look at their parents if
> they cannot
> * handle a request themselves.
> *
> * @author Thomas Dudziak
> */
> public interface ObjectFactory
> {
> /**
> * Creates a child factory.
> *
> * @return The new child factory
> */
> public ObjectFactory createChildFactory();
>
> /**
> * Sets the parent factory.
> *
> * @param parent The parent factory
> */
> public void setParentFactory(ObjectFactory parent);
>
> /**
> * Returns the parent factory if any.
> *
> * @return The parent factory
> */
> public ObjectFactory getParentFactory();
>
> /**
> * Returns the registered implementation class for the given type.
> *
> * @param type The type to register the implementation for
> * @return The registered class
> */
> public Class getImplementationClass(Class type);
>
> /**
> * Registers an implementation class for the given type (and only for it
> * but not for super- or subtypes of it).
> *
> * @param type The type to register the implementation for
> * @param implClass The implementation class to register
> */
> public void setImplementationClass(Class type, Class implClass);
>
> /**
> * Registers the given object as the singleton instance for the
> given type. Note that
> * singleton instances are assumed to be already configured.
> *
> * @param clazz The class to register the object for
> * @param obj The object
> */
> public void setSingletonInstance(Class clazz, Object obj);
>
> /**
> * Return a new instance of the implementation for the given class.
> * If a singleton instance is registered for this type, then this
> instance
> * is returned. The instance will be configured except if it is a
> singleton
> * instance.
> *
> * @param clazz The class
> * @return The instance
> * @exception ObjectCreationException If no implementation is
> configured for this type
> * @exception ObjectConfigurationException If the instance could not
> be configured
> */
> public Object getInstance(Class clazz) throws
> ObjectCreationException, ObjectConfigurationException;
>
> /**
> * Returns all properties specifically defined for the specified type.
> *
> * @param clazz The type
> * @return The properties or <code>null</code> if no properties are
> defined for this type
> */
> public HashMap getProperties(Class clazz);
>
> /**
> * Returns the given property.
> *
> * @param clazz The type that the property is set for
> * @param name The property name
> * @return The value or <code>null</code> if there is no such property
> */
> public Object getProperty(Class clazz, String name);
>
> /**
> * Sets the given property.
> *
> * @param clazz The type to set the property for
> * @param name The property name
> * @param value The value; use <code>null</code> to unset the property
> * @param force If <code>true</code> then an existing property will
> be overriden, otherwise
> * it will only be set if not yet defined
> */
> public void setProperty(Class clazz, String name, Object value,
> boolean force);
>
> /**
> * Sets the properties. The names of the properties are evaulated as
> * fully qualified property names, e.g. package.Class.propertyName.
> *
> * @param props The properties
> * @param force If <code>true</code> then an existing property will
> be overriden, otherwise
> * it will only be set if not yet defined
> */
> public void setProperties(Properties props, boolean force) throws
> FactoryInitializationException;
>
> /**
> * Configures the given object, i.e. sets all properties that are
> defined
> * for the types of the object beginning with the farthest base types.
> *
> * @param obj The object
> */
> public void configure(Object obj) throws ObjectConfigurationException;
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org