cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] Migrate from the aging ECM
Date Wed, 03 Sep 2003 13:30:59 GMT
Carsten Ziegeler wrote:

> 
> I think we should do this switch asap. *If* we can solve the commandmanager
> issue discussed in the other thread, I will make a 2.1.1 release this week.
> Immediately after that work can start on the migration.
> 
> Berin, you mention above in 3) that the configuration format changes
> slightly.
> Can you give a short explaination please?

In Cocoon/ECM we have the following constructs:

<regular-component>
   <stuff/>
</regular-component>

<database-selector>
   <jdbc name="foo"/>
   <j2ee name="bar"/>
   <informix name="baz"/>
</database-selector>


Notice that the regular component has no name/id, and the database-selector
is a "component" that defines a set of components with a name.

In Fortress, things are simplified a bit--esp. since the only time a Selector
is returned is when you append "Selector" to the role name--you don't need them
at all if you don't want.  The above in Fortress would be redone as:

<regular-component id="regular">
   <stuff/>
</regular-component>

<jdbc-datasource id="foo"/>
<j2ee-datasource id="bar"/>
<informix-datasource id="baz"/>

(the actual configuration name is set up in the meta data).

In ECM, the only way to get the "regular-component" is to do a direct lookup:

manager.lookup(RegularComponent.ROLE);

and the only way to get the particular database connection you want is to do
a lookup on the selector and then select the correct connection:

ServiceSelector selector =
    (ServiceSelector) manager.lookup(DataSourceComponent.ROLE + "Selector");
selector.select("foo");
selector.select("bar");
selector.select("baz");

In Fortress, you can do things the old ECM way, or you can incorporate the ID
to get whichever component you want and bypass the selector completely like
this:

manager.lookup(RegularComponent.ROLE + "/regular");
manager.lookup(DataSourceComponent.ROLE + "/foo");
manager.lookup(DataSourceComponent.ROLE + "/bar");
manager.lookup(DataSourceComponent.ROLE + "/baz");

Lastly, a component that just wants whatever the default implementation for a
component is only has to lookup the component it wants:

manager.lookup(RegularComponent.ROLE);
manager.lookup(DataSourceComponent.ROLE);

The default component is always the first one listed in the configuration file,
unless that behavior is overridden.  You can override the behavior by adding a
default="true" attribute to a component.  In the above example, the lookup for
a DataSourceComponent.ROLE would return the "foo" variation.  If the "bar"
variation was altered like this:

<j2ee-datasource id="bar" default="true"/>

then any call to lookup DataSourceComponent.ROLE would return that variation.

As you can see, we can get away from the whole selector concept and do direct
lookups--but Fortress will still work with the old way of doing things.  This
allows you to mix components that expect only one implementation of a component
type with components that require you to select the component.

It would simplify all the database actions, etc. that we have.

The way I propose working around it for the short term--to avoid the
configuration reformatting is to accept the old style configuration (things
with "selector" in the name would be treated as the old style selectors),
and if there is no "name" attribute, the name would match the short config name.

So <regular-component/> would have the id "regular-component".

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message