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 [EMAIL PROTECTED] 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?
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
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114237414521595&w=2.
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
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
http://www.osgi.org/osgi_technology/download_specs.asp?section=2. DS is
based on the service binder
http://gravity.sourceforge.net/servicebinder/, that has more
documentation that can be helpful, especially the tutorial
http://oscar-osgi.sourceforge.net/tutorial/
There is some old material on the wiki which not is updated
http://wiki.apache.org/cocoon/osgi, http://wiki.apache.org/cocoon/Blocks.
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 http://www.eclipse.org/equinox/quickstart.html. 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: http://wiki.apache.org/cocoon/OGSiJMXConsole
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.
/Daniel
