cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] The impact of using OSGi
Date Wed, 10 Aug 2005 18:21:18 GMT
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


Mime
View raw message