Re: [2.2] Configuration issues
Ralph Goers skrev:
Daniel Fagerstrom wrote:
No, I meant something different than the mechanism today, something
that works like the PropertyOverrideConfigurer in Spring. Say that you
have a configuration file like:
Then my idea was that you should be able to override the maxobjects
property by just providing a property:
store.maxobjects=2000
The mechanism of today is more like the PropertyPlaceholderConfigurer
in Spring and would require you to rewrite the configuration file like:
value="${store.use-cache-directory}"/>
and provide default property files for all properties.
Oh, OK. But we also support
class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter">
resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js
${javascript.reload-scripts}
${javascript.check-time}
Would this be replaced by
javascript.reload-scripts = true
It was just an example of a possible convention for using properties as
paths in configuration files, I haven't tried to find a complete mapping
yet.
But if we could find such a convention, it would save us the work to
rewrite hundreds of configurations. So it would probably be worthwhile.
/Daniel
Re: [2.2] Configuration issues
Peter Hunsberger skrev: On 5/17/06, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > 2. This works only as long as the user wants to use the same > implementation for a component. Switching to an own implementation with > an own configuration is not possible. > > Any idea on how to solve this? Here the IMO best and most natural solution is to have different blocks for different implementations. Say we have two different components that implements the XsltProcessor inteface, the Xalan and the Saxon implementation. Then if you have a Xalan block with its own embedded configuration and a Saxon block with its own embedded configuration. If you want to use the Xalan implementation you deploy the Xalan block and if you want the Saxon implementation you deply the Saxon block. Would this solution be able to deal with using both Saxon and Xalan or two different versions of Saxon at different points in the same pipeline? In our case we have 1 critical XSLT that currently only runs under Saxon 6 (I've tried repeatedly to get it to Saxon 8, but so far no go). Everything else exploits XSLT 2.0 and requires Saxon 8. We mix these XSLT in the same pipelines all the time... No, XSLT processors was a rather bad example as they not are interchangeable even if they implement the same interface. In OSGi service is registred with the interfaces that it implements and optionally with a map with properties. A service can be looked up based on its interfaces and optionally with an LDAP style filter on the property map. So in the above example, both implementations would be registered as XsltProcessors, then could also have properties describing vendor name and version. A component that can do with any XsltProcessor would just lookup the XSLT service based on the interface. While a component with special needs would use a filter that describe version range and/or vendor. I don't know if anything like this would be possible with Spring. /Daniel
Re: [2.2] Configuration issues
Daniel Fagerstrom wrote:
No, I meant something different than the mechanism today, something
that works like the PropertyOverrideConfigurer in Spring. Say that you
have a configuration file like:
Then my idea was that you should be able to override the maxobjects
property by just providing a property:
store.maxobjects=2000
The mechanism of today is more like the PropertyPlaceholderConfigurer
in Spring and would require you to rewrite the configuration file like:
value="${store.use-cache-directory}"/>
and provide default property files for all properties.
Oh, OK. But we also support
class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter">
resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js
${javascript.reload-scripts}
${javascript.check-time}
Would this be replaced by
javascript.reload-scripts = true
i.e., How does it know when to look for attributes versus the value of
child elements? Or would it just assume you won't have an attribute with
the same name as a child element?
I'm actually surprised that the syntax for your example isn't
store.parameter.maxobjects = 2000.
But I've never looked into this feature in Spring.
Ralph
Re: [2.2] Configuration issues
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Here the IMO best and most natural solution is to have different blocks for different implementations. Say we have two different components that implements the XsltProcessor inteface, the Xalan and the Saxon implementation. Then if you have a Xalan block with its own embedded configuration and a Saxon block with its own embedded configuration. If you want to use the Xalan implementation you deploy the Xalan block and if you want the Saxon implementation you deply the Saxon block. The result of this thinking is that you have typically smaller and more focused blocks, that contain components that are used togerther. WDYT? I'm not sure - on the one hand you're probably right. But this will lead to too many blocks. If you think this through, this will require that you make for each and every component an own block just to be able to use a different implementation. Might be, we maybe need some mechanism so that one can override a complete component configuration, not just its properties. OTH, we have lots of components that wouldn't need to be components at all or at least not be replaceable. Also some blocks are far to fat, the core contains more than 100 components, while I would guess that most users only use a handful components from core. In many cases having blocks that implements a set of interfaces that works together, and being able to change the block to another one that implements the same interfaces, is a convenient way to switch implementation. It also keep the application lean. /Daniel
Re: [2.2] Configuration issues
Ralph Goers skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of them are
stored in the jar and on deployment some of these files are extracted:
so in the end there are roles files in the jar, xconf and property files
on the WEB-INF folder.
A user should never touch/change these files - so only way to customize
the settings is through properties. This requires that each and every
user configurable value must be replaced with a property! Now while this
approach is fine it has at least two problems:
1. A huge number of properties which sooner or later will create a mess.
Requiring the user of the block to define every property is far to
inconvenient and error prone. A much better model is to have default
values in the configuration file in the block and make it possible for
the block user to optionally override the default value with own
properties. This is the way configuration is handled in OSGi with a
declarative service configuration file that gives the default and a
configuration service that can override the default. Spring has some
similar mechanism with the PropertyOverrideConfigurer
http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/beans/factory/config/PropertyOverrideConfigurer.html.
For the Avalon configurations we could find some convention for
translating configuration file element paths to property strings and
then write a implementation of the avalon Configuration that override
the configuration file based configuration with the property values.
And feed that overridable configuration to the component in the
BeanPostProcessor for the Avalon life cycle.
This is already the way it works in both 2.1 and 2.2. Cocoon provides
values for everything in property files within the block. The user can
then provide their own values which override them. I think Carsten is
simply worried because there are a lot of values you can specify.
No, I meant something different than the mechanism today, something that
works like the PropertyOverrideConfigurer in Spring. Say that you have a
configuration file like:
Then my idea was that you should be able to override the maxobjects
property by just providing a property:
store.maxobjects=2000
The mechanism of today is more like the PropertyPlaceholderConfigurer in
Spring and would require you to rewrite the configuration file like:
value="${store.use-cache-directory}"/>
and provide default property files for all properties.
/Daniel
Re: [2.2] Configuration issues
Carsten Ziegeler skrev: Reinhard Poetz wrote: How does OSGi solve this? Since OSGi4 declarative services are supported. Think of Spring dependency injection but considering interface/implementation relations. You can use the OSGi configuratonAdmin service to change an injected component or a component's properties. Ok, but this is then configuration at runtime and not at development time, right? The configuration admin is called when a service (component) is registered. Where are those values stored? According to the spec they are stored persistently. The actual storage mechanism is not standardized though. In Felix they talking about connecting the configuration admin to the storage API from the directory project so that configurations can be stored in e.g. an LDAP server. Reinhard and I have discussed initializing the configuration admin from an XML or property file. Additionally we have the possibility to redisgn e.g. forms and portal to use the OSGi whiteboard pattern[1]. Using it makes extending them very simple as it makes extensions very simple - you just have to provide a component that implements a particular interface and it is automatically added as reference to another component. I don't want to rewrite blocks in order to use OSGi and I think one of our main goals for using OSGi is that this does not affect the way how I develop blocks which means it is totally transparent. So imho we need an OSGi-free way which works at development time. The whiteboard pattern isn't about OSGi per se, but rather about how to organize extensible components in a plugin based architecture. The configuration model that is used for CForms is not suitable for a plugin architecture at all, as it assumes a single complete list of all components in one place. If you want to ad a component you need to edit the central configuration file. With the whiteboard pattern, each plugin register its services, e.g. validators and widgets, in a registry (the whiteboard). Then the user, e.g. the form framework search for the services it needs from the registry. This is much more flexible and extensible than the current architecture. /Daniel
Re: [2.2] Configuration issues
On 5/17/06, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > 2. This works only as long as the user wants to use the same > implementation for a component. Switching to an own implementation with > an own configuration is not possible. > > Any idea on how to solve this? Here the IMO best and most natural solution is to have different blocks for different implementations. Say we have two different components that implements the XsltProcessor inteface, the Xalan and the Saxon implementation. Then if you have a Xalan block with its own embedded configuration and a Saxon block with its own embedded configuration. If you want to use the Xalan implementation you deploy the Xalan block and if you want the Saxon implementation you deply the Saxon block. Would this solution be able to deal with using both Saxon and Xalan or two different versions of Saxon at different points in the same pipeline? In our case we have 1 critical XSLT that currently only runs under Saxon 6 (I've tried repeatedly to get it to Saxon 8, but so far no go). Everything else exploits XSLT 2.0 and requires Saxon 8. We mix these XSLT in the same pipelines all the time... -- Peter Hunsberger
Re: [2.2] Configuration issues
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a Xalan block with its own embedded
configuration and a Saxon block with its own embedded configuration. If
you want to use the Xalan implementation you deploy the Xalan block and
if you want the Saxon implementation you deply the Saxon block.
The result of this thinking is that you have typically smaller and more
focused blocks, that contain components that are used togerther.
WDYT?
I'm not sure - on the one hand you're probably right. But this will lead
to too many blocks. If you think this through, this will require that
you make for each and every component an own block just to be able to
use a different implementation.
What about having at least a configuration file for each and every component?
This way, it would be simple to provide some overriding mechanism, e.g. all
files in ./src/main/cocoon-xconf override files coming from a deployed block at
deployment.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Configuration issues
Daniel Fagerstrom wrote: > Here the IMO best and most natural solution is to have different blocks > for different implementations. Say we have two different components that > implements the XsltProcessor inteface, the Xalan and the Saxon > implementation. Then if you have a Xalan block with its own embedded > configuration and a Saxon block with its own embedded configuration. If > you want to use the Xalan implementation you deploy the Xalan block and > if you want the Saxon implementation you deply the Saxon block. > > The result of this thinking is that you have typically smaller and more > focused blocks, that contain components that are used togerther. > > WDYT? I'm not sure - on the one hand you're probably right. But this will lead to too many blocks. If you think this through, this will require that you make for each and every component an own block just to be able to use a different implementation. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Configuration issues
Ralph Goers wrote: > I think Carsten is worried about the Portal. The portal has a lot of > configurable elements in it. No actually I'm not worried about the portal - this will have a clean solution for 2.2; I'm just more worried about core, for example how can I configure my own store implementation without changing the core xconf? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Configuration issues
Daniel Fagerstrom wrote: Carsten Ziegeler skrev: I'm currently wondering what the best way to configure 2.2 from a user perspective is. We now have includes for xconfs and property replacements which is great. Now, each block comes with its own configuration files: all of them are stored in the jar and on deployment some of these files are extracted: so in the end there are roles files in the jar, xconf and property files on the WEB-INF folder. A user should never touch/change these files - so only way to customize the settings is through properties. This requires that each and every user configurable value must be replaced with a property! Now while this approach is fine it has at least two problems: 1. A huge number of properties which sooner or later will create a mess. Requiring the user of the block to define every property is far to inconvenient and error prone. A much better model is to have default values in the configuration file in the block and make it possible for the block user to optionally override the default value with own properties. This is the way configuration is handled in OSGi with a declarative service configuration file that gives the default and a configuration service that can override the default. Spring has some similar mechanism with the PropertyOverrideConfigurer http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/beans/factory/config/PropertyOverrideConfigurer.html. For the Avalon configurations we could find some convention for translating configuration file element paths to property strings and then write a implementation of the avalon Configuration that override the configuration file based configuration with the property values. And feed that overridable configuration to the component in the BeanPostProcessor for the Avalon life cycle. This is already the way it works in both 2.1 and 2.2. Cocoon provides values for everything in property files within the block. The user can then provide their own values which override them. I think Carsten is simply worried because there are a lot of values you can specify. 2. This works only as long as the user wants to use the same implementation for a component. Switching to an own implementation with an own configuration is not possible. Any idea on how to solve this? Here the IMO best and most natural solution is to have different blocks for different implementations. Say we have two different components that implements the XsltProcessor inteface, the Xalan and the Saxon implementation. Then if you have a Xalan block with its own embedded configuration and a Saxon block with its own embedded configuration. If you want to use the Xalan implementation you deploy the Xalan block and if you want the Saxon implementation you deply the Saxon block. The result of this thinking is that you have typically smaller and more focused blocks, that contain components that are used togerther. I think Carsten is worried about the Portal. The portal has a lot of configurable elements in it. WDYT? /Daniel
Re: [2.2] Configuration issues
Carsten Ziegeler skrev: I'm currently wondering what the best way to configure 2.2 from a user perspective is. We now have includes for xconfs and property replacements which is great. Now, each block comes with its own configuration files: all of them are stored in the jar and on deployment some of these files are extracted: so in the end there are roles files in the jar, xconf and property files on the WEB-INF folder. A user should never touch/change these files - so only way to customize the settings is through properties. This requires that each and every user configurable value must be replaced with a property! Now while this approach is fine it has at least two problems: 1. A huge number of properties which sooner or later will create a mess. Requiring the user of the block to define every property is far to inconvenient and error prone. A much better model is to have default values in the configuration file in the block and make it possible for the block user to optionally override the default value with own properties. This is the way configuration is handled in OSGi with a declarative service configuration file that gives the default and a configuration service that can override the default. Spring has some similar mechanism with the PropertyOverrideConfigurer http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/beans/factory/config/PropertyOverrideConfigurer.html. For the Avalon configurations we could find some convention for translating configuration file element paths to property strings and then write a implementation of the avalon Configuration that override the configuration file based configuration with the property values. And feed that overridable configuration to the component in the BeanPostProcessor for the Avalon life cycle. 2. This works only as long as the user wants to use the same implementation for a component. Switching to an own implementation with an own configuration is not possible. Any idea on how to solve this? Here the IMO best and most natural solution is to have different blocks for different implementations. Say we have two different components that implements the XsltProcessor inteface, the Xalan and the Saxon implementation. Then if you have a Xalan block with its own embedded configuration and a Saxon block with its own embedded configuration. If you want to use the Xalan implementation you deploy the Xalan block and if you want the Saxon implementation you deply the Saxon block. The result of this thinking is that you have typically smaller and more focused blocks, that contain components that are used togerther. WDYT? /Daniel
Re: [2.2] Configuration issues
On 5/16/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: ...As this will take some time I propose to do a a first beta release very soon (last week of May) without configuration... +1, there's plenty of stuff to digest anyway. -Bertrand
Re: [2.2] Configuration issues
Reinhard Poetz wrote: We should take some time to design the configuration and give room for discussions *before* somebody is implementing something. As this will take some time I propose to do a a first beta release very soon (last week of May) without configuration. +1. Although this beta will be missing a lot it will provide a good basis to start encouraging feedback, and hopefully spur on some new activity. Ralph
Re: [2.2] Configuration issues
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
You *can* use the mechanisms I explained but you *don't have to*. If you want to
benefit from from *particular* advantages that OSGi brings, you have to do
something.
Ok, so we need another way :) I'll think about this in the next days. I
think without a proper solution 2.2 will be even worse than 2.1.x where
we have the nice patch tool.
We should take some time to design the configuration and give room for
discussions *before* somebody is implementing something.
As this will take some time I propose to do a a first beta release very soon
(last week of May) without configuration.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Configuration issues
Reinhard Poetz wrote: > > You *can* use the mechanisms I explained but you *don't have to*. If you want > to > benefit from from *particular* advantages that OSGi brings, you have to do > something. > Ok, so we need another way :) I'll think about this in the next days. I think without a proper solution 2.2 will be even worse than 2.1.x where we have the nice patch tool. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Configuration issues
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
How does OSGi solve this?
Since OSGi4 declarative services are supported. Think of Spring dependency
injection but considering interface/implementation relations. You can use the
OSGi configuratonAdmin service to change an injected component or a component's
properties.
Ok, but this is then configuration at runtime and not at development
time, right? Where are those values stored?
I will let you know as soon as I have time to work on this again (postponed it
in favor of the 2.2beta1 release)
Additionally we have the possibility to redisgn e.g. forms and portal to use the
OSGi whiteboard pattern[1]. Using it makes extending them very simple as it
makes extensions very simple - you just have to provide a component that
implements a particular interface and it is automatically added as reference to
another component.
I don't want to rewrite blocks in order to use OSGi and I think one of
our main goals for using OSGi is that this does not affect the way how I
develop blocks which means it is totally transparent. So imho we need an
OSGi-free way which works at development time.
You *can* use the mechanisms I explained but you *don't have to*. If you want to
benefit from from *particular* advantages that OSGi brings, you have to do
something.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Configuration issues
Reinhard Poetz wrote: >> How does OSGi solve this? > > Since OSGi4 declarative services are supported. Think of Spring dependency > injection but considering interface/implementation relations. You can use the > OSGi configuratonAdmin service to change an injected component or a > component's > properties. Ok, but this is then configuration at runtime and not at development time, right? Where are those values stored? > > Additionally we have the possibility to redisgn e.g. forms and portal to use > the > OSGi whiteboard pattern[1]. Using it makes extending them very simple as it > makes extensions very simple - you just have to provide a component that > implements a particular interface and it is automatically added as reference > to > another component. > I don't want to rewrite blocks in order to use OSGi and I think one of our main goals for using OSGi is that this does not affect the way how I develop blocks which means it is totally transparent. So imho we need an OSGi-free way which works at development time. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Configuration issues
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Do you want to solve this for our first release? If we add the "beta" postfix,
adding some solution in the future isn't a problem. If you agree, I would like
to postpone the discussion for the time after first beta release.
I personally would like to have this in the first beta release, so we
can see if this is the right solution and eventually change this in the
next beta :)
I would like to have a first beta release in May. If we're fast enough, I don't
have a problem. I just wanted to say that finding a solution isn't a must.
@ your question: You probably don't like my answer but OSGi already solves this
kind of problem for us. Considering this I would only go for a very simple
solution so that user _can_ provide their own configuration files which are used
_instead_ of a block's configuration. For the usual needs (forms, template,
mail, apples, pdf block) this should be enough. Don't know about the portal
which is probably the use case you're thinking of.
The portal is no problem as you have your own config file anyway. I'm
more thinking of core or some blocks were you just add your own
components or override some, like adding your own validator to cforms
(which is no problem) or overriding the default email validator with
your own one (which is a problem).
How does OSGi solve this?
Since OSGi4 declarative services are supported. Think of Spring dependency
injection but considering interface/implementation relations. You can use the
OSGi configuratonAdmin service to change an injected component or a component's
properties.
Additionally we have the possibility to redisgn e.g. forms and portal to use the
OSGi whiteboard pattern[1]. Using it makes extending them very simple as it
makes extensions very simple - you just have to provide a component that
implements a particular interface and it is automatically added as reference to
another component.
[1] http://www.osgi.org/documents/osgi_technology/whiteboard.pdf
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Configuration issues
Reinhard Poetz wrote: > Carsten Ziegeler wrote: >> I'm currently wondering what the best way to configure 2.2 from a user >> perspective is. We now have includes for xconfs and property >> replacements which is great. >> Now, each block comes with its own configuration files: all of them are >> stored in the jar and on deployment some of these files are extracted: >> so in the end there are roles files in the jar, xconf and property files >> on the WEB-INF folder. >> A user should never touch/change these files - so only way to customize >> the settings is through properties. This requires that each and every >> user configurable value must be replaced with a property! Now while this >> approach is fine it has at least two problems: >> 1. A huge number of properties which sooner or later will create a mess. >> 2. This works only as long as the user wants to use the same >> implementation for a component. Switching to an own implementation with >> an own configuration is not possible. >> >> Any idea on how to solve this? > > > Do you want to solve this for our first release? If we add the "beta" > postfix, > adding some solution in the future isn't a problem. If you agree, I would > like > to postpone the discussion for the time after first beta release. I personally would like to have this in the first beta release, so we can see if this is the right solution and eventually change this in the next beta :) > > @ your question: You probably don't like my answer but OSGi already solves > this > kind of problem for us. Considering this I would only go for a very simple > solution so that user _can_ provide their own configuration files which are > used > _instead_ of a block's configuration. For the usual needs (forms, template, > mail, apples, pdf block) this should be enough. Don't know about the portal > which is probably the use case you're thinking of. The portal is no problem as you have your own config file anyway. I'm more thinking of core or some blocks were you just add your own components or override some, like adding your own validator to cforms (which is no problem) or overriding the default email validator with your own one (which is a problem). How does OSGi solve this? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Configuration issues
Carsten Ziegeler wrote:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of them are
stored in the jar and on deployment some of these files are extracted:
so in the end there are roles files in the jar, xconf and property files
on the WEB-INF folder.
A user should never touch/change these files - so only way to customize
the settings is through properties. This requires that each and every
user configurable value must be replaced with a property! Now while this
approach is fine it has at least two problems:
1. A huge number of properties which sooner or later will create a mess.
2. This works only as long as the user wants to use the same
implementation for a component. Switching to an own implementation with
an own configuration is not possible.
Any idea on how to solve this?
Do you want to solve this for our first release? If we add the "beta" postfix,
adding some solution in the future isn't a problem. If you agree, I would like
to postpone the discussion for the time after first beta release.
@ your question: You probably don't like my answer but OSGi already solves this
kind of problem for us. Considering this I would only go for a very simple
solution so that user _can_ provide their own configuration files which are used
_instead_ of a block's configuration. For the usual needs (forms, template,
mail, apples, pdf block) this should be enough. Don't know about the portal
which is probably the use case you're thinking of.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[2.2] Configuration issues
I'm currently wondering what the best way to configure 2.2 from a user perspective is. We now have includes for xconfs and property replacements which is great. Now, each block comes with its own configuration files: all of them are stored in the jar and on deployment some of these files are extracted: so in the end there are roles files in the jar, xconf and property files on the WEB-INF folder. A user should never touch/change these files - so only way to customize the settings is through properties. This requires that each and every user configurable value must be replaced with a property! Now while this approach is fine it has at least two problems: 1. A huge number of properties which sooner or later will create a mess. 2. This works only as long as the user wants to use the same implementation for a component. Switching to an own implementation with an own configuration is not possible. Any idea on how to solve this? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
