You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2007/08/26 16:42:12 UTC
OSGi integration (again)
As some of you might have seen in the SVN logs, I have started to work
on making Cocoon work under OSGi again [1].
This will, for the moment, not affect the trunk more than that I might
refactor or reorganize some stuff based on needs for the OSGi integration.
The main reasons for working on OSGi integration is that OSGi makes it
possible to push the modularization of Cocoon a bit further.
* Blocks can be dynamically installed, started, stopped and updated
while the rest of the webapp continue to run. Take a look at Peter
Kriens demo from last year to see how cool this is [2].
* Each block (bundle) has its own classloader and import and export Java
packages from other bundles based on OSGi specific info in the
metainf.mf. In this way the "classloader hell" is handled. Several
versions of the same jar can be used in the same application.
* Each block has its own Spring context and publish and use services
(beans) from other blocks based on a special Spring-OSGi configuration [3].
For background on OSGi [4], [5] and [6] might be good. And the
specification [7] is fairly readable for being a specification.
The work on getting there mainly conisists of: bundelizing the Cocoon
jars and all needed jars, make beans OSGi services and creating
infrastucture for building, configuring and running Cocoon in OSGi.
Bundelizing
===========
To make a jar working in OSGi it must be converted to a bundle. Which
means that its Manifest.mf must be extended with some OSGi specific,
info about what packages it exports and imports and some other things.
Felix contains an excelent Maven plugin that makes this work rather easy
[8].
Also the Felix, Spring-OSGi, Eclipse Equinox and OPS4J has already
bundelized many popular Java libraries.
Services
========
The Spring-OSGi project [9] creates OSGi-Spring integration. There is a
custom name space with constructions for publishing beans as OSGi
services and for using OSGi services as Spring bean references. The idea
is that each bundle (block) has its own Sprin application context, and
that it can publish beans and use beans from other bundles through
OSGi:s service architecture.
There is a Spring OSGi extender bundle that automatically detects
bundles with a Spring configurations in the META-INF/spring directory
and takes care about its services.
Infrastructure
==============
Although the Cocoon OSGi integration should work in any OSGi
implementation I use Felix during development.
I have set up a Maven assembly that creates a directory structure with
all needed jars and configuration files. So that one just can start the
Felix OSGi framework with parts of Cocoon inside (see the README [10]).
For logging I use OPS4J Pax Logging [11], which makes all major logging
frameworks available in an OSGi friendly way.
I use an HTTP service from Eclipse Equinox as the Felix one doesn't
support Servlet 2.4 only 2.3. An activator [14], [15] has the same role
as the DispatcherServlet in the ordinary context. But it is dynamic so
it will detect and use servlet services that comes and goes.
The servlet protocol is available as a "real" Java protocol and is
available with java.net.URL, using the OSGi URL service.
Status
======
This far some basic examples that use the servlet service fw works. See
the README [10] for how to build and test the stuff.
I'll continue with bundelizing the Cocoon core.
There are a number of open problems:
* How to handle configuration
* Spring-OSGi doesn't support prototype scope that well
* How handle the massive "import" of services that is needed for a sitemap?
We had some partial answers to the above question last time we worked on
Cocoon OSGi integration. Hopefully they can be adapted to the Spring
OSGi context.
An overview of earlier work can be found in [12] and in my presentation
[13].
/Daniel
[1] http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/
[2] http://www.aqute.biz/Blog/20070703
[3] http://www.springframework.org/osgi/specification
[4] http://www.aqute.biz/OSGi/Tutorial
[5] http://felix.apache.org/site/presentations.data/osgi-berlin-20070321.pdf
[6] http://www.osgi.org/osgi_technology/index.asp?section=2
[7] http://www2.osgi.org/Download/Release4V401
[8] http://felix.apache.org/site/maven-bundle-plugin-bnd.html
[9] http://www.springframework.org/osgi/
[10] http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/README.txt
[11] http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging
[12] http://marc.info/?l=xml-cocoon-dev&m=114237414521595&w=2
[13] http://www.cocoongt.org/archive/2005/Slides-and-recordings.html
[14]
http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-servlet-service/cocoon-servlet-service-impl-osgi/src/main/java/org/apache/cocoon/servletservice/osgi/Activator.java
[15]
http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-servlet-service/cocoon-servlet-service-impl-osgi/src/main/resources/META-INF/spring/servlet-listener.xml
Re: OSGi integration (again)
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi Grzegorz,
> Any pointers to "Sling scripts"? Quick look at Sling's home page didn't reveal anything.
You can deploy ecma, jsp, groovy and other scripting flavours into
Sling to process requests. Have a look this tutorial [1].
[1] http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html
BR,
Juanjo.
Re: OSGi integration (again)
Posted by Andreas Hartmann <an...@apache.org>.
Grzegorz Kossakowski schrieb:
> Juan José Vázquez Delgado pisze:
>> I´ve written a proof of concept with a Sling Servlet using the Cocoon
>> pipeline api to get the response. This proof was ok but I´m thinking
>> about a more natural Cocoon/Sling integration. IMHO, a pipeline, even
>> a sitemap, would be as a script in Sling.
>
> Any pointers to "Sling scripts"? Quick look at Sling's home page didn't reveal anything.
Here's a bit of information:
http://incubator.apache.org/sling/site/servlet-resolution.html#ServletResolution-ScriptsareServlets
http://cwiki.apache.org/SLING/scripting-variables.html
Maybe this helps :)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: OSGi integration (again)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 29, 2009 at 12:57 PM, Grzegorz Kossakowski
<gr...@tuffmail.com> wrote:
> Juan José Vázquez Delgado pisze:
>> ...I´m thinking
>> about a more natural Cocoon/Sling integration. IMHO, a pipeline, even
>> a sitemap, would be as a script in Sling.
>
> Any pointers to "Sling scripts"? Quick look at Sling's home page didn't reveal anything.
http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html
shows the basics of how Sling processes a request by finding a script
in the JCR repository.
Totally agree with Juanjo that "cocoon scripts" could be used to
define Ccoon pipelines to process Sling requests.
-Bertrand
Re: OSGi integration (again)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Juan José Vázquez Delgado pisze:
>
> I´ve written a proof of concept with a Sling Servlet using the Cocoon
> pipeline api to get the response. This proof was ok but I´m thinking
> about a more natural Cocoon/Sling integration. IMHO, a pipeline, even
> a sitemap, would be as a script in Sling.
Any pointers to "Sling scripts"? Quick look at Sling's home page didn't reveal anything.
--
Grzegorz Kossakowski
Re: OSGi integration (again)
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> Wow, great - what do you think about committing this into the Sling
> whiteboard? So we can use this as a prototype and base for further
> discussions.
Sure, Carsten, My purpose is committing the proof of concept in
sandbox this weekend.
On the other hand, I´m embedding the cocoon-pipeline jar into the
bundle right now. IMHO, it would be ok having OSGizied cocoon jars to
deploy into Sling.
BR,
Juanjo.
Re: OSGi integration (again)
Posted by Andreas Hartmann <an...@apache.org>.
Carsten Ziegeler schrieb:
> Juan José Vázquez Delgado wrote:
>>>> I could imagine a future version of Lenya to use Sling for the
>>>> repository management. I wouldn't like to give up Cocoon's pipelining
>>>> and XML processing capabilities, though.
>>> Me neither :)
>>>
>>>> I'm not sure in which way Sling and Cocoon would cooperate from a
>>>> request processing point of view (I imagine that Sling resources can
>>>> include the output of Cocoon pipelines, which process data generated by
>>>> other resources), but I guess having the option to deploy Cocoon
>>>> blocks/modules as OSGi bundles would be a good starting point.
>>> For our products I've written a simple pipeline api (and impl) which
>>> post processes the output from Sling. My intention is to do exactly this
>>> with C3.
>> I´ve written a proof of concept with a Sling Servlet using the Cocoon
>> pipeline api to get the response. This proof was ok but I´m thinking
>> about a more natural Cocoon/Sling integration. IMHO, a pipeline, even
>> a sitemap, would be as a script in Sling.
>>
> Wow, great - what do you think about committing this into the Sling
> whiteboard? So we can use this as a prototype and base for further
> discussions.
I would also be very interested in seeing the code and joining the
discussion.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: OSGi integration (again)
Posted by Carsten Ziegeler <cz...@apache.org>.
Juan José Vázquez Delgado wrote:
> Hi,
>
>>> I could imagine a future version of Lenya to use Sling for the
>>> repository management. I wouldn't like to give up Cocoon's pipelining
>>> and XML processing capabilities, though.
>> Me neither :)
>>
>>> I'm not sure in which way Sling and Cocoon would cooperate from a
>>> request processing point of view (I imagine that Sling resources can
>>> include the output of Cocoon pipelines, which process data generated by
>>> other resources), but I guess having the option to deploy Cocoon
>>> blocks/modules as OSGi bundles would be a good starting point.
>> For our products I've written a simple pipeline api (and impl) which
>> post processes the output from Sling. My intention is to do exactly this
>> with C3.
>
> I´ve written a proof of concept with a Sling Servlet using the Cocoon
> pipeline api to get the response. This proof was ok but I´m thinking
> about a more natural Cocoon/Sling integration. IMHO, a pipeline, even
> a sitemap, would be as a script in Sling.
>
Wow, great - what do you think about committing this into the Sling
whiteboard? So we can use this as a prototype and base for further
discussions.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: OSGi integration (again)
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,
>> I could imagine a future version of Lenya to use Sling for the
>> repository management. I wouldn't like to give up Cocoon's pipelining
>> and XML processing capabilities, though.
> Me neither :)
>
>> I'm not sure in which way Sling and Cocoon would cooperate from a
>> request processing point of view (I imagine that Sling resources can
>> include the output of Cocoon pipelines, which process data generated by
>> other resources), but I guess having the option to deploy Cocoon
>> blocks/modules as OSGi bundles would be a good starting point.
> For our products I've written a simple pipeline api (and impl) which
> post processes the output from Sling. My intention is to do exactly this
> with C3.
I´ve written a proof of concept with a Sling Servlet using the Cocoon
pipeline api to get the response. This proof was ok but I´m thinking
about a more natural Cocoon/Sling integration. IMHO, a pipeline, even
a sitemap, would be as a script in Sling.
BR,
Juanjo.
Re: OSGi integration (again)
Posted by Carsten Ziegeler <cz...@apache.org>.
Andreas Hartmann wrote:
> BTW, to illustrate my intentions:
>
> I could imagine a future version of Lenya to use Sling for the
> repository management. I wouldn't like to give up Cocoon's pipelining
> and XML processing capabilities, though.
Me neither :)
> I'm not sure in which way Sling and Cocoon would cooperate from a
> request processing point of view (I imagine that Sling resources can
> include the output of Cocoon pipelines, which process data generated by
> other resources), but I guess having the option to deploy Cocoon
> blocks/modules as OSGi bundles would be a good starting point.
For our products I've written a simple pipeline api (and impl) which
post processes the output from Sling. My intention is to do exactly this
with C3.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: OSGi integration (again)
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Carsten Ziegeler schrieb:
>> Andreas Hartmann wrote:
>>> Hi Daniel,
>>>
>>> Daniel Fagerstrom schrieb:
>>>> As some of you might have seen in the SVN logs, I have started to work
>>>> on making Cocoon work under OSGi again [1].
>
>>> are you still working on this? I'd be interested in deploying Cocoon in
>>> an OSGi environment.
>
> […]
>
>> I can't speak about C2, but my intension is to enable C3 for OSGi
>> (whatever that means in the end).
>
> This is great news! I'll keep an eye on the commits, I hope I will find
> the time to do some testing as soon as any code is available.
BTW, to illustrate my intentions:
I could imagine a future version of Lenya to use Sling for the
repository management. I wouldn't like to give up Cocoon's pipelining
and XML processing capabilities, though.
I'm not sure in which way Sling and Cocoon would cooperate from a
request processing point of view (I imagine that Sling resources can
include the output of Cocoon pipelines, which process data generated by
other resources), but I guess having the option to deploy Cocoon
blocks/modules as OSGi bundles would be a good starting point.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: OSGi integration (again)
Posted by Andreas Hartmann <an...@apache.org>.
Carsten Ziegeler schrieb:
> Andreas Hartmann wrote:
>> Hi Daniel,
>>
>> Daniel Fagerstrom schrieb:
>>> As some of you might have seen in the SVN logs, I have started to work
>>> on making Cocoon work under OSGi again [1].
>> are you still working on this? I'd be interested in deploying Cocoon in
>> an OSGi environment.
[…]
> I can't speak about C2, but my intension is to enable C3 for OSGi
> (whatever that means in the end).
This is great news! I'll keep an eye on the commits, I hope I will find
the time to do some testing as soon as any code is available.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: OSGi integration (again)
Posted by Carsten Ziegeler <cz...@apache.org>.
Andreas Hartmann wrote:
> Hi Daniel,
>
> Daniel Fagerstrom schrieb:
>> As some of you might have seen in the SVN logs, I have started to work
>> on making Cocoon work under OSGi again [1].
>
> are you still working on this? I'd be interested in deploying Cocoon in
> an OSGi environment.
>
> I just checked out the osgi directory from the whiteboard. After
> updating the version of the Cocoon artifact I'm running into several
> build issues.
>
> The POM files under commons contain the following parent declaration:
>
> <parent>
> <groupId>org.apache.felix.commons</groupId>
> <artifactId>build</artifactId>
> <version>0.9.0-incubator-SNAPSHOT</version>
> </parent>
>
> Is this still up to date? I couldn't find anything about a "build"
> artifact in the Felix commons sub-project.
>
This is definitly not up to date :(
I can't speak about C2, but my intension is to enable C3 for OSGi
(whatever that means in the end).
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: OSGi integration (again)
Posted by Andreas Hartmann <an...@apache.org>.
Hi Daniel,
Daniel Fagerstrom schrieb:
> As some of you might have seen in the SVN logs, I have started to work
> on making Cocoon work under OSGi again [1].
are you still working on this? I'd be interested in deploying Cocoon in
an OSGi environment.
I just checked out the osgi directory from the whiteboard. After
updating the version of the Cocoon artifact I'm running into several
build issues.
The POM files under commons contain the following parent declaration:
<parent>
<groupId>org.apache.felix.commons</groupId>
<artifactId>build</artifactId>
<version>0.9.0-incubator-SNAPSHOT</version>
</parent>
Is this still up to date? I couldn't find anything about a "build"
artifact in the Felix commons sub-project.
TIA!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01