Ugo Cei wrote:
Sylvain Wallez wrote:
- Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the environment provide one and bind it to a JNDI namespace.
Mmmhh... defining the JNDI datasources is container-specific, and therefore makes the applications not self-contained. Furthermore, subsitemaps (and blocks in the future) can come with their own datasources used locally. I'm not sure this is compatible with the global declaration induced by JNDI.
Subsitemaps can define local datasources? Really? I tried to, in the past, but could never make this work. Now I'm not interested anymore, since I always use Hibernate and not XSP.
<map:components>
<datasources>
<jdbc name="local-ds">
<url>jdbc:blah</url>
</jdbc>
</datasources>
</map:components>Anyway, this request was inspired by this principle: "If you're running in a J2EE environment, use it's features, don't reimplement them" and by the desire to drop everything that is not strictly necessary.
I must admit that this desire might not be common to everyone and the current situation has the advantage of being immediately usable by novices without knowing how to properly configure a J2EE container.
Exactly. And this goes back to what I said yesterday: many Cocoon users aren't very skilled in J2EE techniques and having a self-contained application is easier for them.
So, I'll drop this for the moment. We already have lot of other things to do.
Yep :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
