On Wednesday 10 August 2005 21:46, Upayavira wrote: > The question > is, what if a piece of configuration information is needed by OSGi _and_ > Cocoon, because our use-case is broader than that of OSGi. Should we use > the manifest.mf file and have our own systems consume that as well as > OSGi, or alernatively use the block.xml file, and have manifest.mf > generated from that.
AFAIU, extending the use of the Manifest is "Ok" from both Java's and OSGi's point of view. If manifest headers of "Cocoon-XYZ" format is used, I am pretty confident that there are no future "issues" with conflicting names. My own usage pattern is basically; Use a single manifest entry to point to a resource within the bundle which contains further information about what one is trying to do. But, in the case of "real blocks" I foresee that there are some overlap between the "classloading mechanism" needed from OSGi and "SiteMap resolutions" provided by Cocoon core, which would suggest that the "raw data" is in source form of Cocoon's chosen format, and relevant "compilers" creates the necessary division into one, two or more runtime parts required. (This is when you don't want to depend on Maven 1 ;o) ) On a related note, some thought is probably required to "draw the line in the sand" for what is Core API and pure implementation. Although startlevels can ensure starting orders and that missing classes in a bundle therefor can be supplied properly, I get the impression that this is "bad practice" and that each bundle should carry all the classes required for its full instantiation. OSGi will take care of which actual class instance that will be used. Export of the entire Cocoon codebase of today seems like a bad idea, yet there is no good line in the older parts what is api vs implementation. General rule; start small and expand with need. Also, I am in the process of creating a Log4J bundle for OSGi, and I am totally open to suggestions on the best way forward with this. The generic LogService is indeed very rudimentary, and can potentially be very slow (object creation when not needed), but I think there should be an integrated solution of both the OSGi LogService as well as some better API, such as SLF4J or Jakarta commons-logging, in the same implementation. I assume that the result will either be hosted at Apache Logging or the new Apache OSGi project. Just my few thoughts on the subject. Cheers Niclas
