cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <>
Subject Re: [Fwd: Cocoon and Felix]
Date Sat, 25 Feb 2006 13:50:20 GMT
I just committed initial support in Felix for exploded bundle 
directories as well as referenced bundle JAR files.

Regarding some of the other issues mentioned below by Daniel, I cannot 
think of any major things that would prevent Felix from being used in a 
servlet container. I know other people have used Oscar in such scenarios 
and Felix should be better at it than Oscar. Felix is still growing, 

There is one area that could be an issue, which is if you want both 
Felix and the servlet container to set the URL stream handler factory. 
If you don't need the stream handler factory in Felix, it can be turned 
off. If they both need it, then currently Felix would have some 
difficulty here, but I have a JIRA issue for implementing a hack like 
the one done in Equinox to allow for such a thing, it is just not a 
major priority right now. The Felix URL handler is already pretty 
sophisticated, since it can deal with the situation where multiple 
framework instances exist in the same JVM and all want to use the URL 
handler service.

Regarding Declarative Services needing an implementation dependent hook, 
the issue is that it needs access to the BundleContext of the bundles 
that it manages. We could not come to agreement on how to provide a 
standard way to give it such access, since providing access to 
BundleContext is considered security sensitive. There are ways around 
this, such as having managed bundles use an activator from DS, but we 
couldn't agree on this either. :-)

If Cocoon really goes in the OSGi direction, my hope is that our two 
communities discuss issues and requirements so that we stay in sync with 
each other. I am willing to offer OSGi advice and opinion about 
approaches etc. for Cocoon if you need any.

-> richard

p.s. Perhaps you could cc me with your response, since I am not a 
subscriber to the Cocoon mailing list.

Daniel Fagerstrom wrote:
Richard S. Hall wrote:
 > Upayavira wrote:
 >> Thanks for this Daniel - Richard copied in so he sees your reply.
 >> Regards, Upayavira
 >> Daniel Fagerstrom wrote:
 >>>> We need the possibility to embed the OSGi
 >>>> framework in a servlet container

 >> The above link does not really give me a clear picture of what is
 >> needed. Would it be possible to describe more precisely what the
 >> requirement is?
The requirement is to be able to deploy the OSGi framework and the
needed Cocoon bundles and other bundles within a standard servlet
container as e.g. a war. Upayavira and others can hopefully fill in with
more details. This point is not high priority for me personally, I think
it is a better idea to use an OSGi framework with an HttpService,
standalone. But for others, the possibility to deploy Cocoon within a
servlet container is important.

 >>>> And we need a framework that work together with some declarative
 >>>> services implementation (IIUC the coupling between declarative
 >>>> services
 >>>> and the framework is not standardized).
 >> From my understanding, the Equinox DS impl has a pretty clean
 >> interface between it and the framework, so it might not be difficult
 >> to get it and Felix to play together. We could also investigate the
 >> KF impl. Also, we have people in the Felix community that are
 >> interested in implementing DS, so hopefully we can have our own impl
 >> before too long.
I was quite surprised when I read the standard draft and learned that
the DS require a non standardized framework hook, why is that?
 >>>> As a first step I think it is more important to get Cocoon working
 >>>> under
 >>>> OSGi at all than supporting our local OSGi provider ;) As soon as we
 >>>> have got to that point I am all for making Cocoon work with all
 >>>> OSGi R4
 >>>> compliant frameworks, and maybe having Felix as default choice.
 >> Well, some of the features you are talking about tie you to a
 >> particular OSGi R4 implementation, so if you depend on these features
 >> then you will not work on all R4 frameworks. It is highly unlikely
 >> that Felix (nor any other framework) will implement every Eclipse-ism.
I understand that. Our intension is of course to keep dependencies on
specific frameworks isolated and pluggable.

The requirements to be able to use unpacked bundles is a must for any
project that is interested in rapid development, so it isn't something
Cocoon specific. If you package your webapp, with html pages, java
scripts etc in a bundle, it would of course be a huge step back for web
development to require that the bundle would need to be zipped for each
small html editing.

The ability to run an OSGi framework within a web container will
hopefully not affect the Cocoon code at all. Cocoon will use an
HttpService, and when deployed standalone the HttpService will be an
ordinary one and when deployed as a war, we will instead use an
HttpService that just is a proxy to the embedding container.

So my hope is that, the only Cocoon requirement that will be visible in
our code is that we will depend on DS. Then, rapid development abilities
and web container deployabllity will more be an issue for the user and
will affect the users choice of OSGi framework and services provider.


View raw message