cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: GSoC: Cocoon & JMX
Date Sun, 07 May 2006 23:11:35 GMT
Philipp Schmidt skrev:
> Hi,
> First off sorry for my poor english.

Seem good enough to me.

> Second off if this email is 
> valuable for public discussion I repost it to the dev@cocoon list. I 
> wasn't sure.

We try to keep most discussions public, and an important part of GSoC at 
Apache is to learn the "Apache way". So I answer at cocoon-dev.

> Looks like I choose the most complicated project from cocoon list in the 
> GSoC 2006. That's why I have some questions and I hope one of you could 
> answer them since you are the experts of OGSi and the trunk. :)

Hopefully it is one of the more interesting projects as well :)

> So here are my top 10 questions in random order:
> 1 - The "cocoon-core" represents the core of Cocoon with all the basic 
> functionality like sitemaps, flowscript, etc. Right?


> 2 - The "cocoon-blocks-fw" is needed in order to mount all the other 
> blocks like forms etc. Right?


> 3 - There's no way at the moment to mount a "block" (like forms) and run 
> an example.

Actually it is. cocoon-webapp is working as an OSGi block(at least 
partly), and it gets all needed components through the Spring bridge. To 
test it you need to set the start level of cocoon-webapp higher (5 e.g.) 
than the rest of the bundles. This is needed to make sure that all the 
needed components from cocoon-core are registered before cocoon-webapp 
tries to access them.

To make it work you also need change

<map:transform src="welcome.xslt">
  <map:parameter name="contextPath" value="{request:contextPath}"/>

to have the explicit contextPath value "/cocoon-webapp".

The reason for this is that the standard HttpService is supposed to use 
Servlet 2.1 which doesn't contain getContextPath() in the request 
object. And the Equinox implementation of HttpService strictly follow 
the standard. Now, using Servlet 2.1 is obviously not enough for Cocoon, 
so the conclusion is that we need another HttpService. The Felix 
HttpService is less strict and use Servlet 2.4 (it is based on Jetty). I 
have tried to use the Felix HttpService instead of the Equinox one but 
this far without success. It seem to start as it should but in some way 
it seem to affect the behavior of the cocoon-core bundle so that it 
doesn't start as it should, no idea what is going wrong yet.

There is some work left to do on the Spring bridge though, aliases are 
not handled yet, non thread safe components are not handled either and I 
would expect that the pooled components doesn't work completely.

> 4 - How will the "blocks" be realised? As far as I understood it they 
> will be OGSi bundles like the "cocoon-core" and "cocoon-blocks-fw" are atm.

You understand correctly the blocks will be realized as bundles. 
cocoon-core is a good example of a block that contributes components (as 
OSGi services) to the rest of the blocks, and cocoon-webapp shows how a 
block can use components (services) from other blocks and contribute 
sitemap (Servlet) functionality.

You can find a description about how the blocks-fw work in

> 5 - What do you think would be the best way to integration JMX into 
> Cocoon? (I know it's my duty to figure this out, but I would highly 
> appreciate some advice for the start). After looking at [1] and if 4. is 
> true on way could be another OGSi service with JMX functionality. 
> Possible would also be an extension of the "cocoon-core" which would 
> lack all the fun of switching JMX off and make the core even heavier :)

I don't know much about JMX, so hopefully others can give you some 
advice on this.

> 6 - Since JMX only makes sense if you have an graphical interface I 
> depend on the functionality like the forms framework etc.

Maybe you can use some already written JMX console, so that you don't 
have to solve all the problems in the beginning.

> How much work is it to make 3. working?

Hard to say, everything that is needed is implemented, but as indicated 
above, some functionality might be lacking or buggy. And the debugging 
isn't particularly easy going.

What is needed for the forms block is to provide a Manifest file, which 
is fairly easy to do using the PDE in Eclipse. One also need to provide 
a configuration file for the declarative services that sets up a local 
OSGi/Spring bridge that use the necessary components from core and 
expose the form components, cocoon-core and cocoon-webapp can be used as 

> 7 - If you could name 10 things I should read, look at (except [1]) what 
> should that be? Any links, papers, code that's uber important?

The link above with references is a good starting point for the blocks fw.

Learning about the OSGi declarative services (DS) is also a good idea. 
It is fairly new so I'm afraid that the specification is the main source DS is 
based on the service binder, that has more 
documentation that can be helpful, especially the tutorial

There is some old material on the wiki which not is updated,

Code wise cocoon-blocks-fw-impl together with cocoon-blocks-fw-demo[12] 
is important. Also take a look at META-INF/components.xml and some of 
the classes refered to in in them in cocoon-core and cocoon-webapp.

And of course ask on the list, not everything is documented or that easy 
to follow in the code.

> 8 - How does the discovery of "bundles" in OGSi work? The question is 
> when I only compile the core, how do I add the forms block to it. I 
> couldn't find information concerning this.

OSGi doesn't discover any bundles, what bundles that are started when 
you start an OSGi framework is typically described in a configuration 
file in an implementation dependent way. For Equinox you find 
documentation here When 
the framework is started, bundles can be installed dynamically through 
the BundleContext.

More specifically when you run the code within Eclipse you should 
convert the block to a plugin, then it will be available in the GUI for 
Start... -> Equinox OSGi Framework. You can probably use the c-eclipse 
Maven plugin, but I don't know the details about how.

> 9 - Basic functionality of the JMX Cocoon Management Console should be 
> start a block, stop a block, show log file. Since Cocoon uses Spring and 
> Avalon reconfiguration (like cocoon.xconf etc.) is impossible at the 
> moment, as far as I understood it. Right?

It shouldn't be impossible AFAIK, but there is certainly work left to 
make the blocks reconfigurable.

> 10 - Could you please read: 
> and give me some feedback. Thanks a lot.

An important part that you didn't mention is to configure the blocks 
using JMX to control the configuration service in OSGi. Besides that you 
need a design document and an approach.


View raw message