Neeme,
Thanks for your answer. The reason is was mentioning the excalibur CM xml
file is because I have a proliferation (is that english ? :-)) of system
configuration file for my application :
- roleConfig.xml + systemConfig.xml (the files for excalibur CM),
- our standard properties file for message definition (exception, audit
logs) + localization
- EJB deployment descriptors (ejb environment values)
- log4j configuration file
- our technical properties file where we define technical system
configuration properties (like the ip of machines, passwords, jndi factory
to use, ...)
Note that I am using Avalon+Excalibur in a J2EE environment which does not
help in this regards, ... :)
Thus, 2 ideas :
1/ in a non j2ee environment, I thought the idea of systemConfig.xml was to
define the full system configuration (i.e. technical data for all
components). Now, what about things like standard properties file for
message definitions ? I thought they could have also been put in
systemConfig.xml. But it would have needed xpath query to easily get access
to a given message, identified by its id (<message id="xxx">text</message>).
That was my first idea yesterday but since then I have changed my mind ...
For several reasons :
- performance : I'm not sure doing a xpath (
getString("[EMAIL PROTECTED]'id']") ) query is really performant, as the data in
cache will not be indexed on the id. A simple hashmap would be better
suited.
- As you highlighted, I now believe this was not the intent of these files
to contain this kind of data, so they should be put somewhere else
(properties files for example) and accessed through another component (see
my following post).
2/ In a j2ee world, I would like that both my ejbs and the avalon component
use the same unified configuration service to access system configuration
data. Thus, I have decided to write a configuration avalon component that
would be used by both. Same for logging. Actually, to make like simpler,
I'll write an AbstractLogConfigEnabled abstract class. Something like :
public abstract AbstractLogConfigEnabled implements Composable
{
private Logging loggerComponent;
private Config configComponent;
public void compose(ComponentManager cm)
{
// lookup the logging + config component and save their reference
// (they both are thread safe btw).
}
public Logging getLogging()
{
return loggerComponent;
}
public Config getConfig()
{
return configComponent;
}
}
WRT helping you, I woudl love that but I can promise I'm 500% swamped (with
paid day work + open source night job - Cactus, MockObjects, presentation
for events, book, family also ...;-) ).
Nevertheless, I'll be submitting several proposals for new components soon
... :)
Thanks
-Vincent
----- Original Message -----
From: "Neeme Praks" <[EMAIL PROTECTED]>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Cc: "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Wednesday, December 05, 2001 8:50 AM
Subject: RE: [excalibur] XmlBundle and co, status ?
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 04, 2001 3:57 PM
> >
> > I have just been quickly looking at the XmlBundle component and its
> > dependent components (mapper, ...). It looks really nice and I certainly
> > need something like this in my application.
>
> very nice :-)
>
> > Thus the questions :
> >
> > * What is the state of XmlBundle ? Is it working functionnally ? Are
there
> > features not implemented yet that I shouldn't use ? Any known bugs ?
>
> well, I have some pending commits to do, to finalize the BundleMatcher
> facility and write some different BundleLoader implementations
> (bundle-per-file vs. many-bundles-per-file).
> I'm not sure if it works right now, haven't tried yet in any "real"
> application.
>
> Also I want to take advantage of the new components that were/are migrated
> over from Cocoon (Source, XmlConsumer, etc).
>
> > * I'd like to use it in a production application. Anything I should know
:
> > performance wise or stability wise ? :)
>
> well, the implementation isn't finished yet, so it is not 100% stable
> implementation-wise :-)
>
> > * Is there a plan to use is for managing the Excalibur Component
> > Manager xml files ?
> > * Is there a plan to replace
org.apache.avalon.configuration.Configuration
> > by Bundle in the future (so that components can use Xpath like queries)
?
>
> No, Bundle support is there just for i18n purposes (at least at this
stage).
> How do you see that it could help the management of the Excalibur
Component
> Manager xml files or why would you want to run XPath queries on
> org.apache.avalon.configuration.Configuration? AFAIK, the configuration
> system is on purpose designed not to allow this kind of things (to keep it
> simple and avoid people shooting themselves in the foot).
>
> Maybe you would like to join in with all the Bundle stuff? Any help is
> always welcome (testing, docs, patches, etc.) :-)
> Would like to finally get the i18n stuff out of scratchpad, for the others
> to see and use...
>
> Rgds,
> Neeme
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
