Geoff Howard <[EMAIL PROTECTED]> writes:
<snip/>
But this brings up another point - what to do if the wiring.xml and others is deleted? Presumably, all blocks are "uninstalled" in this state, but what does this do to persistence requirements.
Also, how to recreate the deploy step efficiently? For example:
You deploy a block with some dependencies and configuration. The block deploy process walks you through setting configs and resolving dependencies. You then have no record of these deployment choices except in wiring.xml which is not meant for human consumption. Perhaps it would be good to record these human-step deployment time configurations in a conf file which could be easily reprocessed to easily re-deploy all blocks to their last configuration.
The more I watch this discussion go by the more I feel like Cocoon is reinventing JBoss. The more I watch the Aspects discussion go by the more I feel like Cocoon is reinventing JBoss. Too bad JBoss isn't a container that we can just pick up for Cocoon and count on....
Maybe, but is there really anything (reusable) out there for such an amorphous thing as a block? It's not (just) classloading or component/service location because some of the things a block can expose is a file or more generic "behavior" which will in some cases be very specific to Cocoon. This assumption should of course be challenged - anyone see places we are unnecessarily reinventing the wheel?
BTW, On the same issue more or less: I don't think you ever responded to my question on what to do for a container for EJB samples supplied with Cocoon? (Still trying to get permission to contribute our code.)
Sorry, must have missed that. Can you remind me - were we talking about how to deal with the fact that an EJB example would rely on an EJB container which we don't provide?
Off the top of my head I'd say it's just like the SAP and other component(s) which rely on external dependencies we can't or don't ship. If the examples can be provided in a container-neutral way, that's the best option of course. Assuming that's not practical, I'd say start with what we have and over time perhaps we can accumulate container-specific versions. If we have to tailor to one at the start, JBOSS is probably the best as it's at least available to everyone.
Am I on the right discussion?
Geoff
