cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: GSoC: Cocoon & JMX
Date Mon, 08 May 2006 07:45:13 GMT
Daniel Fagerstrom wrote:
> 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 :)

... and I guess it will require only little coding ;-)

>> 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?
> Yes.
>> 2 - The "cocoon-blocks-fw" is needed in order to mount all the other 
>> blocks like forms etc. Right?
> Yes.
>> 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}"/>
> </map:transform>
> 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.

I can't give you detailed technical answers for now but have a look at - osgijmx project. I (and the 
author) think that it can be reused for our purpose.

>> 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.

I don't think writing a JMX console is within the scope of this project (but I 
don't stop you). A tutorial how to use an existing one (e.g. JConsole which 
comes with Java 5 -->

for German speakers) would be good enough.

>> 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 
> examples.
>> 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.

maybe you can help us with writing down all your findings in the wiki or even 
better in our CMS.

>> 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. 

yes, that's important.

> Besides that you 
> need a design document and an approach.

yes, that's required if you want to get your proposal accepted. For a first 
submission its good enough. IIUC there is some time left to refine the proposal 
together with you over the next days.

Philipp, are you subscribed to dev@cocoon so that I don't need to CC you any longer?

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


Telefonate ohne weitere Kosten vom PC zum PC:

View raw message