db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [RFC] Using IoC for initializing the OJB runtime (OJB 1.1)
Date Tue, 26 Oct 2004 20:11:58 GMT
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


Mime
View raw message