You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/11/11 01:40:28 UTC
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/test/data test1.roles test1.xconf
Heads up.
On Mon, 11 Nov 2002 11:10, donaldp@apache.org wrote:
> donaldp 2002/11/10 16:10:01
>
> Modified: fortress/src/java/org/apache/excalibur/fortress/container
> AbstractContainer.java DefaultContainer.java
> fortress/src/java/org/apache/excalibur/fortress/role
> AbstractRoleManager.java RoleManager.java
> fortress/src/test/org/apache/excalibur/fortress/test
> ContainerProfile.xconf
> fortress/src/test/org/apache/excalibur/fortress/test/data
> test1.roles test1.xconf
> Log:
> Remove handler/role attributes from within the .xconf file. These are
> derivable from the values stored in the roles file and thus there is no
> need to try and duplicate the same data across multiple places.
>
> Revision Changes Path
> 1.17 +28 -16
> jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/co
>ntainer/AbstractContainer.java
>
> Index: AbstractContainer.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/f
>ortress/container/AbstractContainer.java,v retrieving revision 1.16
> retrieving revision 1.17
> diff -u -r1.16 -r1.17
> --- AbstractContainer.java 10 Nov 2002 16:16:43 -0000 1.16
> +++ AbstractContainer.java 11 Nov 2002 00:10:01 -0000 1.17
> @@ -81,6 +81,7 @@
> import org.apache.excalibur.fortress.lookup.FortressServiceSelector;
> import org.apache.excalibur.fortress.role.ExcaliburRoleManager;
> import org.apache.excalibur.fortress.role.RoleManager;
> +import org.apache.excalibur.fortress.role.RoleEntry;
> import org.apache.excalibur.instrument.InstrumentManager;
> import org.apache.excalibur.instrument.Instrumentable;
> import org.apache.excalibur.mpool.ObjectFactory;
> @@ -241,14 +242,22 @@
> throw new IllegalArgumentException( message );
> }
>
> - String role = component.getAttribute( "role", null );
> - String klass = component.getAttribute( "class", null );
> + final String classname = component.getAttribute( "class", null
> ); boolean isLazy = isLazyComponentHandler( component );
> - ComponentHandler handler = getComponentHandler(
> - component.getAttribute( "handler", null ), klass, component,
> isLazy - );
>
> - if( null != role && null != klass && null != handler )
> + final RoleEntry roleEntry = m_roleManager.getRoleForClassname(
> classname ); + if( null == roleEntry )
> + {
> + final String message = "No role defined for " + classname;
> + throw new IllegalArgumentException( message );
> + }
> +
> + final ComponentHandler handler =
> + getComponentHandler( roleEntry, component, isLazy );
> +
> + final String role = roleEntry.getRole();
> +
> + if( null != role && null != classname && null != handler )
> {
> Map hintMap = (StaticBucketMap)m_mapper.get( role );
>
> @@ -319,20 +328,19 @@
> * Get a ComponentHandler with the standard
> * <code>HANDLER_CONSTRUCTOR</code> for the component class passed
> in. */
> - private ComponentHandler getComponentHandler( final String
> handlerClassName, - final
> String classname, + private ComponentHandler getComponentHandler( final
> RoleEntry roleEntry, final Configuration configuration, final boolean
> isLazy ) {
> ComponentHandler handler = null;
> + final String classname =
> roleEntry.getComponentClass().getName(); try
> {
> - final Class handlerClazz = m_classLoader.loadClass(
> handlerClassName ); final ObjectFactory factory =
> createObjectFactory( classname, configuration );
>
> final ComponentHandler targetHandler =
> - (ComponentHandler)handlerClazz.newInstance();
> +
> (ComponentHandler)roleEntry.getHandlerClass().newInstance();
>
> ContainerUtil.contextualize( targetHandler, m_context );
>
> @@ -359,16 +367,20 @@
> {
> if( getLogger().isDebugEnabled() )
> {
> - getLogger().debug( "Could not create the '" +
> handlerClassName + - "' handler for the
> '" + classname + - "' component.", e );
> + final String message =
> + "Could not create the handler for the '" +
> + classname + "' component.";
> + getLogger().debug( message, e );
> }
> + return null;
> }
>
> if( getLogger().isDebugEnabled() )
> {
> - getLogger().debug( "Component " + classname +
> - " uses handler " + handlerClassName );
> + final String message =
> + "Component " + classname +
> + " uses handler " +
> roleEntry.getHandlerClass().getName(); + getLogger().debug(
> message );
> }
>
> final ComponentHandlerEntry entry =
>
>
>
> 1.12 +1 -4
> jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/co
>ntainer/DefaultContainer.java
>
> Index: DefaultContainer.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/f
>ortress/container/DefaultContainer.java,v retrieving revision 1.11
> retrieving revision 1.12
> diff -u -r1.11 -r1.12
> --- DefaultContainer.java 10 Nov 2002 16:16:43 -0000 1.11
> +++ DefaultContainer.java 11 Nov 2002 00:10:01 -0000 1.12
> @@ -156,10 +156,7 @@
>
> //We set these before copying all other attributes so the class
> / handler can be overriden if needed if //the shorthand name is used
> - temp.setAttribute( "role", roleEntry.getRole() );
> temp.setAttribute( "class",
> roleEntry.getComponentClass().getName() ); - temp.setAttribute(
> "handler", roleEntry.getHandlerClass().getName() ); -
> temp.setValue( configItem.getValue( null ) );
>
> String[] attributes = configItem.getAttributeNames();
>
>
>
> 1.4 +25 -1
> jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/ro
>le/AbstractRoleManager.java
>
> Index: AbstractRoleManager.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/f
>ortress/role/AbstractRoleManager.java,v retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- AbstractRoleManager.java 10 Nov 2002 16:16:43 -0000 1.3
> +++ AbstractRoleManager.java 11 Nov 2002 00:10:01 -0000 1.4
> @@ -74,6 +74,11 @@
> private Map m_shorthands = new Hashtable();
>
> /**
> + * Map for classname to RoleEntry
> + */
> + private Map m_classnames = new Hashtable();
> +
> + /**
> * Parent <code>RoleManager</code> for nested resolution
> */
> private final RoleManager m_parent;
> @@ -164,11 +169,30 @@
>
> final RoleEntry entry = new RoleEntry( role, clazz, handlerKlass
> ); m_shorthands.put( shortName, entry );
> + m_classnames.put( className, entry );
> }
>
> protected Class guessHandlerFor( final Class clazz )
> {
> return PerThreadComponentHandler.class;
> + }
> +
> +
> + public RoleEntry getRoleForClassname( final String classname )
> + {
> + final RoleEntry roleEntry = (RoleEntry)m_classnames.get(
> classname ); + if( null != roleEntry )
> + {
> + return roleEntry;
> + }
> + else if( null != m_parent )
> + {
> + return m_parent.getRoleForClassname( classname );
> + }
> + else
> + {
> + return null;
> + }
> }
>
> public RoleEntry getRoleForShortName( final String shortname )
>
>
>
> 1.4 +3 -1
> jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/ro
>le/RoleManager.java
>
> Index: RoleManager.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/f
>ortress/role/RoleManager.java,v retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- RoleManager.java 10 Nov 2002 16:16:43 -0000 1.3
> +++ RoleManager.java 11 Nov 2002 00:10:01 -0000 1.4
> @@ -64,4 +64,6 @@
> String ROLE = RoleManager.class.getName();
>
> RoleEntry getRoleForShortName( String shortname );
> +
> + RoleEntry getRoleForClassname( String classname );
> }
>
>
>
> 1.8 +5 -24
> jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/te
>st/ContainerProfile.xconf
>
> Index: ContainerProfile.xconf
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/f
>ortress/test/ContainerProfile.xconf,v retrieving revision 1.7
> retrieving revision 1.8
> diff -u -r1.7 -r1.8
> --- ContainerProfile.xconf 24 Sep 2002 21:45:10 -0000 1.7
> +++ ContainerProfile.xconf 11 Nov 2002 00:10:01 -0000 1.8
> @@ -1,33 +1,14 @@
> <test>
> -<!--
> - <component id="test1"
> - class="org.apache.avalon.excalibur.datasource.JdbcDataSource"
> - role="org.apache.avalon.excalibur.datasource.DataSourceComponent"
>
> - handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler
>" - logger="test">
> - <pool-controller min="5" max="10">
> - <keep-alive>SELECT 1 FROM groups</keep-alive>
> - </pool-controller>
> - <driver>@test.jdbc.driver@</driver>
> - <dburl>@test.jdbc.url@</dburl>
> - <user>@test.jdbc.user@</user>
> - <password>@test.jdbc.password@</password>
> - </component>
> --->
> <component id="test2"
> class="org.apache.avalon.excalibur.monitor.ActiveMonitor"
> - role="org.apache.avalon.excalibur.monitor.Monitor"
>
> - handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler
>" - logger="test"
> - activation="startup">
> + logger="test"
> + activation="startup">
> <thread priority="10" frequency="1"/>
> </component>
> <component id="test3"
> - class="org.apache.avalon.excalibur.xml.JaxpParser"
> - role="org.apache.avalon.excalibur.xml.Parser"
>
> - handler="org.apache.excalibur.fortress.handler.PoolableComponentHandler"
> - logger="test"
> - activation="startup">
> + class="org.apache.avalon.excalibur.xml.JaxpParser"
> + logger="test"
> + activation="startup">
> <parameter name="validate" value="false"/>
> <parameter name="namespace-prefixes" value="false"/>
> <parameter name="reuse-parsers" value="true"/>
>
>
>
> 1.2 +3 -3
> jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/te
>st/data/test1.roles
>
> Index: test1.roles
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/f
>ortress/test/data/test1.roles,v retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- test1.roles 10 Nov 2002 12:39:04 -0000 1.1
> +++ test1.roles 11 Nov 2002 00:10:01 -0000 1.2
> @@ -7,17 +7,17 @@
> <role name="org.apache.excalibur.fortress.test.data.Role2">
> <component shorthand="component2"
> class="org.apache.excalibur.fortress.test.data.Component2"
> -
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/
>> +
> handler="org.apache.excalibur.fortress.handler.PoolableComponentHandler"/>
> </role>
> <role name="org.apache.excalibur.fortress.test.data.Role3">
> <component shorthand="component3"
> class="org.apache.excalibur.fortress.test.data.Component3"
> -
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/
>> +
> handler="org.apache.excalibur.fortress.handler.PerThreadComponentHandler"/>
> </role>
> <role name="org.apache.excalibur.fortress.test.data.Role4">
> <component shorthand="component4"
> class="org.apache.excalibur.fortress.test.data.Component4"
> -
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/
>> +
> handler="org.apache.excalibur.fortress.handler.FactoryComponentHandler"/>
> </role>
> </test>
>
>
>
>
> 1.3 +0 -8
> jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/te
>st/data/test1.xconf
>
> Index: test1.xconf
> ===================================================================
> RCS file:
> /home/cvs/jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/f
>ortress/test/data/test1.xconf,v retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- test1.xconf 10 Nov 2002 12:43:57 -0000 1.2
> +++ test1.xconf 11 Nov 2002 00:10:01 -0000 1.3
> @@ -1,27 +1,19 @@
> <test>
> <component id="component1"
> class="org.apache.excalibur.fortress.test.data.Component1"
> - role="org.apache.excalibur.fortress.test.data.Role1"
> -
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"
> logger="component1"
> activation="startup"/>
> <component id="component2"
> class="org.apache.excalibur.fortress.test.data.Component2"
> - role="org.apache.excalibur.fortress.test.data.Role2"
> -
> handler="org.apache.excalibur.fortress.handler.PoolableComponentHandler"
> logger="component2"
> pool-min="2"
> activation="startup"/>
> <component id="component3"
> class="org.apache.excalibur.fortress.test.data.Component3"
> - role="org.apache.excalibur.fortress.test.data.Role3"
> -
> handler="org.apache.excalibur.fortress.handler.PerThreadComponentHandler"
> logger="component3"
> activation="startup"/>
> <component id="component4"
> class="org.apache.excalibur.fortress.test.data.Component4"
> - role="org.apache.excalibur.fortress.test.data.Role4"
> -
> handler="org.apache.excalibur.fortress.handler.FactoryComponentHandler"
> logger="component4"
> activation="startup"/>
> </test>
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XFC / Fortress integration
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>Hi,
>
>On Thu, 14 Nov 2002 00:42, Marcus Crafter wrote:
>
>
>> This would be fine. You could bundle the required XFC classes with
>> Fortress and just set up the input/output modules to convert one
>> way ECM to Fortress. I don't see a problem there, and for Fortress
>> this would be nice.
>>
>>
>
>Kool ... volunteering to do it ? I would really like that capability prior to
>release :)
>
>
>
>> Random thought coming...
>>
>> On the long term and grand scale :) I had a few thoughts about
>> creating a common container 'model' that could be used across all
>> containers (if possible), that could support arbitrary backends.
>> The thought came to me while I was writing parts of XFC.
>>
>>
>...
>
>
>> If we could nail this, then any container that uses the 'model'
>> could use any other containers configurations, assuming there's a
>> backend written to support it.
>>
>> What do you think ? Am I dreaming :)
>>
>>
>
>It is a thought that has occured before and was going to part of the
>containerkit model prior to the blow up. However that is a model that is much
>harder to achieve than metadata definition and as of now we don't even have
>that model in common.
>
Pete:
What are the functional requirements you see as necessary over an above
the current excalibur/meta package?
>Essentially there is 4 types of different information that would need to be
>able to be modelled for such an evolution to take place. Essentially these
>are;
>
>1. component configuration
>2. component assembly
>3. component environment
>4. component aspects (for lack of a better term)
>
>Some would also separate out
>5. Logging
>
>(1) and (2) are relatively easy to model and are already in place. They just
>need to be brought together and homogenized. The other Peter is actually
>working towards that with (1) (whether he knows it or not ;]). (2) is simple.
>(5) is relatively simple - especially if we base it on existing work.
>
>(3) and (4) are much much harder to model. The main reason being that they are
>implicitly defined with respect to a parent container.
>
>
Generally yes - but this is also addressable through a declarive
approach - for example, the excalibur/meta package include not only the
low level type model, but also the declarative criteria on which the
environment can be expressed as container depedencies (as distinct from
component centric service dependecies), and descriptors that provide
containers an open mechanisms for the creation of resources required by
components to properly function.
>(3)/Environment stuff such as classloader stuff, policy stuff, thread stuff,
>URLContentHandlers, System.io/out redirection are all things that are
>provided in the parent container and are things that are a lot harder to
>standardize on. You can see parts of the picture in various different
>excalibur projects.
>* loader: classloader stuff
>* policy: policy stuff
>* ThreadContext: maintaining threadContext even when crossin boundaries
>* jprocess: attempt at bringing together ThreadProcess to isolate different
>parts of the environment
>
You should add to you list the excalibur/meta package as this directly
address aspects concerning environment establishment.
http://jakarta.apache.org/avalon/excalibur/meta/
>
>(4) also requires the notion of a parent container as the interceptors will
>need to aquire services from parent and possibly be workin in mixed
>"environments"
>
>Interesting idea but something that is not really within our grasp atm.
>
>
I have a differnet take on this. Based on looking at and playing with
Fortress and ECM stuff - I don't see any obsticles to the creation of a
meta model. In fact the recent work on excalibur/meta has been
undertaken specifically to enable this. The objective is to be able
(via XFC) to suck in ECM structured information and from that build
programatically the meta model enabling those components to run without
modification in other environments such as Merlin. This is also
consistent with the Fortress meta container approach. Within a
ECM/Merlin model in place we will have the complete story for Foress -
combined with support for Phoneix meta (because Phoneix meta is already
supported in the excalibur/meta package).
Cheers, Steve.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XFC / Fortress integration
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Thu, 14 Nov 2002 00:42, Marcus Crafter wrote:
> This would be fine. You could bundle the required XFC classes with
> Fortress and just set up the input/output modules to convert one
> way ECM to Fortress. I don't see a problem there, and for Fortress
> this would be nice.
Kool ... volunteering to do it ? I would really like that capability prior to
release :)
> Random thought coming...
>
> On the long term and grand scale :) I had a few thoughts about
> creating a common container 'model' that could be used across all
> containers (if possible), that could support arbitrary backends.
> The thought came to me while I was writing parts of XFC.
...
> If we could nail this, then any container that uses the 'model'
> could use any other containers configurations, assuming there's a
> backend written to support it.
>
> What do you think ? Am I dreaming :)
It is a thought that has occured before and was going to part of the
containerkit model prior to the blow up. However that is a model that is much
harder to achieve than metadata definition and as of now we don't even have
that model in common.
Essentially there is 4 types of different information that would need to be
able to be modelled for such an evolution to take place. Essentially these
are;
1. component configuration
2. component assembly
3. component environment
4. component aspects (for lack of a better term)
Some would also separate out
5. Logging
(1) and (2) are relatively easy to model and are already in place. They just
need to be brought together and homogenized. The other Peter is actually
working towards that with (1) (whether he knows it or not ;]). (2) is simple.
(5) is relatively simple - especially if we base it on existing work.
(3) and (4) are much much harder to model. The main reason being that they are
implicitly defined with respect to a parent container.
(3)/Environment stuff such as classloader stuff, policy stuff, thread stuff,
URLContentHandlers, System.io/out redirection are all things that are
provided in the parent container and are things that are a lot harder to
standardize on. You can see parts of the picture in various different
excalibur projects.
* loader: classloader stuff
* policy: policy stuff
* ThreadContext: maintaining threadContext even when crossin boundaries
* jprocess: attempt at bringing together ThreadProcess to isolate different
parts of the environment
(4) also requires the notion of a parent container as the interceptors will
need to aquire services from parent and possibly be workin in mixed
"environments"
Interesting idea but something that is not really within our grasp atm.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XFC / Fortress integration
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Peter,
On Wed, Nov 13, 2002 at 07:52:03AM +1100, Peter Donald wrote:
> On Tue, 12 Nov 2002 14:05, Berin Loritsch wrote:
> > It is easy to do. There is also the cross config package that
> > should bridge the gaps dynamically. It is Excalibur XFC. If
> > that solve the problem (i.e. can be used at runtime), then there
> > really isn't a need for YAC (yet another container).
>
> I agree - better to remove the need for the container. Marcus what do you
> think would be best? I had a look at the code and it looks to be more general
> than is really required in the container. It may be simpler to do the
> transformation in fortress directly. XFC would still be required to migrate
> applications properly but one way runtime transform could be done in
> fortress.
This would be fine. You could bundle the required XFC classes with
Fortress and just set up the input/output modules to convert one
way ECM to Fortress. I don't see a problem there, and for Fortress
this would be nice.
Random thought coming...
On the long term and grand scale :) I had a few thoughts about
creating a common container 'model' that could be used across all
containers (if possible), that could support arbitrary backends.
The thought came to me while I was writing parts of XFC.
Stephen and I talked about this when I was in Paris recently,
and was part of the reason why he moved the Merlin model package out
into meta.
The idea is based on the assumption that all containers essentially
manage their components internally in a similar way. There are
differences w.r.t how (ie. async. event based in Fortress, sync.
linear based in ECM, .xfiles approach in Merlin, etc), but once
components are loaded into their respective containers they're
basically managed in some similar way, ie. hashmap with some
accessor methods.
So, with this being the case, we could extract the best parts from all
our existing containers into a 'model' package that any container
could use. This would free container implementations of that
effort and allow them to focus on other things (eg. hierarchical
support, kernel management, classloader issues, threading, etc, etc).
It would also mean that we could write different backend's for this
'model' package, allowing it to support the current and any future
style of configuration files, and providing backwards
compatibility for older style config files in the newer containers.
Something like this:
Config Model Container impl. Client code
|------------------------|
ECM| | |-------| Merlin| |
Fortress| -> | | Model | -> Fortress| | -> component access
Merlin | |-------| etc |
|------------------------|
The model:
|------------------------|
| |-----| |-----| |-----||
| |Fort.| |Merl.| |ECM. || Backends support current/future containers
| |-----| |-----| |-----||
| |
| Model | Internal model of configured components
|------------------------|
API Container oriented API
If we could nail this, then any container that uses the 'model'
could use any other containers configurations, assuming there's a
backend written to support it.
What do you think ? Am I dreaming :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
XFC / Fortress integration
Posted by Peter Donald <pe...@apache.org>.
On Tue, 12 Nov 2002 14:05, Berin Loritsch wrote:
> > BTW one thing that someone has asked me to do (though I no
> > agree yet) is to
> > make a ECMContainer for Fortress. This container would
> > essentially provide an
> > interface identical to ECM (same config files and
> > autodiscover handlers). Any
> > comments on this? Good idea/bad idea/hard idea? It **looks**
> > like something
> > easy to do atm but ...
>
> It is easy to do. There is also the cross config package that
> should bridge the gaps dynamically. It is Excalibur XFC. If
> that solve the problem (i.e. can be used at runtime), then there
> really isn't a need for YAC (yet another container).
I agree - better to remove the need for the container. Marcus what do you
think would be best? I had a look at the code and it looks to be more general
than is really required in the container. It may be simpler to do the
transformation in fortress directly. XFC would still be required to migrate
applications properly but one way runtime transform could be done in
fortress.
Thoughts?
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/test/data test1.roles test1.xconf
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Mon, 11 Nov 2002 11:47, Peter Royal wrote:
> > Cocoon (arguably the largest public ECM consumer we have)
> allows users
> > to add custom components via its xconf file. With the current
> > structure, one can add a component of a new role without needing to
> > make a custom roles file. Yes, anyone adding any sizable amount of
> > components will create a roles file for them, simple users may not.
> >
> > This may not be an issue by the time Cocoon is ready for a new
> > embeddable container. Especially if we can package a
> component as a JAR
> > and have a special directory or such that is read and basically
> > creating the role automatically.. but that's for the future.
>
> okay.
>
> BTW one thing that someone has asked me to do (though I no
> agree yet) is to
> make a ECMContainer for Fortress. This container would
> essentially provide an
> interface identical to ECM (same config files and
> autodiscover handlers). Any
> comments on this? Good idea/bad idea/hard idea? It **looks**
> like something
> easy to do atm but ...
It is easy to do. There is also the cross config package that
should bridge the gaps dynamically. It is Excalibur XFC. If
that solve the problem (i.e. can be used at runtime), then there
really isn't a need for YAC (yet another container).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/test/data test1.roles test1.xconf
Posted by Peter Donald <pe...@apache.org>.
On Mon, 11 Nov 2002 11:47, Peter Royal wrote:
> Cocoon (arguably the largest public ECM consumer we have) allows users
> to add custom components via its xconf file. With the current
> structure, one can add a component of a new role without needing to
> make a custom roles file. Yes, anyone adding any sizable amount of
> components will create a roles file for them, simple users may not.
>
> This may not be an issue by the time Cocoon is ready for a new
> embeddable container. Especially if we can package a component as a JAR
> and have a special directory or such that is read and basically
> creating the role automatically.. but that's for the future.
okay.
BTW one thing that someone has asked me to do (though I no agree yet) is to
make a ECMContainer for Fortress. This container would essentially provide an
interface identical to ECM (same config files and autodiscover handlers). Any
comments on this? Good idea/bad idea/hard idea? It **looks** like something
easy to do atm but ...
--
Cheers,
Peter Donald
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/test/org/apache/excalibur/fortress/test/data test1.roles test1.xconf
Posted by Peter Royal <pr...@apache.org>.
On Sunday, November 10, 2002, at 07:40 PM, Peter Donald wrote:
> Heads up.
eek!
>> Log:
>> Remove handler/role attributes from within the .xconf file. These
>> are
>> derivable from the values stored in the roles file and thus there is
>> no
>> need to try and duplicate the same data across multiple places.
Yes, the data can be duplicated. But there is a current use which could
be outdated by the time it becomes an issue, but I'm making the case
just to be sure.
Cocoon (arguably the largest public ECM consumer we have) allows users
to add custom components via its xconf file. With the current
structure, one can add a component of a new role without needing to
make a custom roles file. Yes, anyone adding any sizable amount of
components will create a roles file for them, simple users may not.
This may not be an issue by the time Cocoon is ready for a new
embeddable container. Especially if we can package a component as a JAR
and have a special directory or such that is read and basically
creating the role automatically.. but that's for the future.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>