Thanks for the clarification, Stefano.
You are very welcome.
I have another question, though.
Sure.
Does your response assume that the embedding application is likely to be something quite heavy (like Cocoon)?
Absolutely not. Avalon-framework is about 57kb of jar. Admittedly bigger than a servlet, but much smaller than any normal library an XML-aware program has to depend on (like xerces or xalan, for example).
The Avalon Container that Cocoon uses today is ECM and Fortress will probably obsolete that. The whole thing will probably never be more than another 100kb.
As far as perception of complexity, your servlet code will look like this (based on Avalon 4.1)
AvalonContainer avalon = new AvalonContainer(someConfigurationFile); XIndice xindice = (XIndice) avalon.getComponent(XIndice.ROLE);
and at that point you use xindice as you would normally do but avalon will take care of 'configure it' and assemblying it.
Or is an embeddable container like Fortress appropriate for use with a lightweight, servlet-based application or service?
Since many people like you share this concern, the Avalon Project is making all possible efforts to provide avalon implementations that are suitable for many different needs, ranging from full-blown standalone servers (like james or, hopefully in the future, tomcat) to small lightweight services that need COP (Component Oriented Programming) paradigms.
What I'm concerned about is too much weight and complexity just to embed the Xindice database.
if xindice goes down the Avalon path, I'll personally volunteer to write an example servlet that will embed xindice thru avalon, believe me, it's piece of cake (the code above shows it).
NOTE: I'm not saying that programming following Avalon paradigms is piece of cake, I'm saying that after others have gone thru the work of adopting avalon patterns, *using* avalon for your component-driven programming is very easy since Avalon takes control of all that glue-stuff that you normally had to do yourself.
So I'd venture to say that it's *easier* to embed something based on avalon, than it is normally. Because avalon enforces some common design on *all* components, so when you learn it once, you'll start using it all over the place :)
If the overhead is too high, Xindice won't be useful as a persistence mechanism for web services, for example.
I totally understand and believe me, the goal is to make things *easier* for Xindice users (and developers, but that's on a longer run) not harder.
Otherwise we'll be shooting ourselves in the foot and I don't like that. To be honest with you, I care more about this project coming back to healthy community-based development, than its adoption of avalon.
If both can happen together, great. But if there is no consensus on this list (also from users) I won't push any further than this.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> --------------------------------------------------------------------
