Carsten Ziegeler wrote: > Reinhard Poetz wrote: >>>> Currently the deployer extracts the files from COB-INF and META-INF into >>>> the file system (into the web application). We talked about skipping >>>> this step and adding a mechanism to the core of Cocoon which allows to >>>> access the information from within the jar without extracting it. >>>> This should be doable by using the class loader and some detection >>>> mechanism and avoids the deployer plugin. And more important it means >>> Seems like cocoon solutions are always a step ahead my comprehension. Is >>> this really feasible? >> Why not? >> > Giacomo and I talked a little bit about this at the GT and to be honest, > we are not sure if it's 100% feasible, but it should! (I really love > such answers). > > We are able to find all jar files containing a COB-INF directory through > the class loader and we should be able to get a stream to this jar. > Then we can just go through the archive, find the files, and register > them somewere. > Actually we are looking for a volunteer to implement this asap :) (If noone has done it until the end of October I will herhaps have some time by then).
So, currently Cocoon is setup through Spring by using the namespace authoring stuff. We currently have a "cocoon:settings" element which will sets up the settings object of Cocoon and does some minor other stuff. We could hook up there and: a) search for all relevant jar files containing a COB-INF directory and all the other directories we usually extract during deployment. This can be done using the class loader which returns urls for each jar file. b) Once we have all relevant jar files we can scan them using the usual zip stuff (we got the url of the jar file in a) ) and get hold of all relevant files contained in the COB-INF directory (and other locations). c) We have to extend the various configuration implementations (for properties, for spring config files and for avalon files) to include the stuff from b) I think this is more or less the first step; we talk about some more details which I can't remember right now. Perhaps Reinhard or Daniel can fill in here. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
