Carsten Ziegeler wrote:
Okay, it seems that noone else has done these things already. At least I
haven't found/seen any other examples.
Ok, although it still seems weird to me nobody else came up with the same idea
(as well as a solution).
As a starting point I would like to extend the Cocoon Spring
configurator (CSC) with the below described logic. The CSC does already
half of the required stuff (property and overwrite handling), so I think
it makes sense to add the missing piece.
As I already said, the CSC is hosted at Cocoon because this is the place
where it all started. We can move it to whereever we think it needs to
be *and* we can replace the search directory path "cocoon/something"
with something more general.
I hope everyone is fine with this for now?
Np for now.
Ok, currently the CSC reads properties from
META-INF/cocoon/properties and META-INF/cocoon/properties/{runningMode}
The CSC reads spring bean definitions from
META-INF/cocoon/spring/*.xml and META-INF/cocoon/spring/{runningMode}*.xml
It also reads overwrite definitions from
META-INF/cocoon/spring/*.properties and
META-INF/cocoon/spring/{runningMode}*.properties
I propose to add the following:
We define a rule based language - we can either use existing rules
implementations or create our own (xml) based one.
The basic idea is to start with named rules that can test properties and
include bean definitions.
I would start with a simple xml based config file for these rules. The
CSC reads the rules from
META-INF/cocoon/spring/*.xrules and
META-INF/cocoon/spring/{runningMode}*.xrules
As the rules have a name (unique identifier) it's possible to overwrite
them inside the running mode specific configuration files.
The rules itself have include directives that can include spring bean
files from any available path (classpath etc.)
WDYT?
To be honest, I'm a bit confused about what you are proposing.
Without a concrete example and explanation what this rule language is/looks
like and is supposed to do my gut reaction is this might be overkill for what
we need.
I definitely think we need as simple as possible solution using conventions and
a language commonly known.
That's why I tried to come up with a jstl/el type of example as its a standard
and widly known language and the runtime evaluation should be easily embeddable.
Defining or even dynamically loading our own custom language seems a bit too
far fetched.
But maybe I simply misunderstood your proposal and is it actually very simple,
so it would be great if you could provide an example.
Regards, Ate
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
