Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? The extension point system can be of great value: a plugin declares an extension point (e.g. the core can declare a source-factory extension point), and plugins can provide contributions to this extension point (e.g. the JCR block will contribute a jcr: source factory). The source resolver can then know all protocols that are provided by plugins somewhere in the system. For this specific usecase, the URL service of OSGi could also be of interest. But in general extension points could be useful. AFAIU the plugin management stuff (download, update, etc) is specific, even if built on top of OSGi. Version management also. Ok. One one hand it is good to leverage on whats in Eclipse. OTH it seem to introduce quite a lot of bulk, even the platform download from Eclipse is some tens of MBs. Maybe one can use a much smaller part of Eclipse. To me it seem atractive to being able to chose between several implementations of OSGi and that e.g. the framework implementation from Knopplerfish starts at 200KB. /Daniel
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, Here the main problem is that JXTG and flow have some differences in behaviour, see http://marc2.theaimsgroup.com/?t=11164826501r=1w=2 and http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=11182531907w=2 for description and possible solutions. We need to decide: should we keep trhe direct access of request params as properties of cocoon.request and session/context attributes as properties of cocoon.[session|context] or not. Should we support the direct usage of org.*, javax.* and com.* whithout needing the Packages. prefix in flow? On that point, I proposed to write a new implementation of the flowscript implementation. This is certainly not a total rewrite, but a refactoring of the existing code to have an overally consistent object model, and also introduce a flow object that would separate the flow-specific operations out of the cocoon object that should be the common base for the object model, and therefore be identical in all places (flow, templates, form event listeners, etc). Would be nice! Having thought a little bit more about it I think that we, for the moment, just should make JXTG compatible with flow and independent of it. I take care of that if not anyone else feel like doing it. Then we can discuss refactorings, deprecation of confusing behaviour etc. But we need to support the behaviour of JXTG from 2.1 in 2.2 even if we hopefully can deprecate some stuff. snip/ As discussed in the relases thread I don't think it is realistic to stop adding features, we need a way to let rock stable core functionality coexist with new features. Otherwise the defacto no release policy will continue. Agree. That this rock solid core state that I'm currently not sure about, as many changes have occured there. I'm certainly not saying that the core in trunk is rock solid rigth now. What I'm saying is that when we have managed to get the core rock solid again, we should keep it that way in trunk. Marking something that is stable as unstable seem to be self fullfilling. People might become less carefull in the hope that it can be fixed later and most user testing and feedback dissapears. /Daniel
RE: [RT] Micro kernel based Cocoon
-Original Message- From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Sent: Dienstag, 24. Mai 2005 13:40 To: dev@cocoon.apache.org Subject: Re: [RT] Micro kernel based Cocoon Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? The extension point system can be of great value: a plugin declares an extension point (e.g. the core can declare a source-factory extension point), and plugins can provide contributions to this extension point (e.g. the JCR block will contribute a jcr: source factory). The source resolver can then know all protocols that are provided by plugins somewhere in the system. For this specific usecase, the URL service of OSGi could also be of interest. But in general extension points could be useful. AFAIU the plugin management stuff (download, update, etc) is specific, even if built on top of OSGi. Version management also. Ok. One one hand it is good to leverage on whats in Eclipse. OTH it seem to introduce quite a lot of bulk, even the platform download from Eclipse is some tens of MBs. Maybe one can use a much smaller part of Eclipse. To me it seem atractive to being able to chose between several implementations of OSGi and that e.g. the framework implementation from Knopplerfish starts at 200KB. /Daniel I'm afraid history is repeating itself. In my perception the Cocoon core dependency on Avalon/Excalibur was a major PITA even before the community breakdown. A separate community (although large overlap with Cocoon), separate release cycles, separate repository, separate agenda, ... Everytime I wanted to debug something I hit a wall with no way to get at the source code. Always a datestamped JAR with some private fixes, completely unreproducable. With Eclipse, Knopplerfish, Spring or other it might be the same and even worse because of the missing insider links. Instead of a micro kernel which is going to have again a large footprint to do anything useful I'd rather prefer a small kernel to do just what Cocoon needs. After all Cocoon is just a super-servlet which needs a bit of container services for managing component reuse and state information. We should not make it again the playground for container academics. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [RT] Micro kernel based Cocoon
Nathaniel Alfred wrote: Instead of a micro kernel which is going to have again a large footprint to do anything useful I'd rather prefer a small kernel to do just what Cocoon needs. After all Cocoon is just a super-servlet which needs a bit of container services for managing component reuse and state information. We should not make it again the playground for container academics. While I agree with parts of your post I simply can't agree with After all Cocoon is just a super-servlet which needs a bit of container services for managing component reuse and state information.. While the current Cocoon may simply be a super-servlet (although I see it as far more than that) with real-blocks it will need much more than a bit of container services. IMO that is why we have been struggling so long to get them out - we simply don't have the complete kernel to make them work. We have modified the core in 2.2 to (mostly) get rid of Avalon, but the functionality needed for real block deployment doesn't exist yet. And it certainly isn't trivial to implement. I agree that Cocoon shouldn't be a playground for container academics, but leveraging technologies that do what we need, are proven to work, and have a stable community supporting them are far from that. Frankly, I find writing our own stuff to do this more of a playground then leveraging stuff that already works. However, I will temper my optimism with the caveat that we do have to be extremely careful of some of the concerns that have been mentioned; i.e. accessing the source and jars must not require a full Eclipse download and strong community support must be there. Ralph
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain Wallez wrote: On that point, I proposed to write a new implementation of the flowscript implementation. This is certainly not a total rewrite, but a refactoring of the existing code to have an overally consistent object model, and also introduce a flow object that would separate the flow-specific operations out of the cocoon object that should be the common base for the object model, and therefore be identical in all places (flow, templates, form event listeners, etc). Would be nice! Having thought a little bit more about it I think that we, for the moment, just should make JXTG compatible with flow and independent of it. I take care of that if not anyone else feel like doing it. Then we can discuss refactorings, deprecation of confusing behaviour etc. But we need to support the behaviour of JXTG from 2.1 in 2.2 even if we hopefully can deprecate some stuff. Agree. IIRC, we also talked to have a new CTemplate generator, which could actually be the next-generation JXTG, working consistently with the refactored flow engine. Both being new components could concentrate on overall consistency without caring about backwards compatibility, whereas the existing classes whould have to ensure this compatibility. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: On that point, I proposed to write a new implementation of the flowscript implementation. This is certainly not a total rewrite, but a refactoring of the existing code to have an overally consistent object model, and also introduce a flow object that would separate the flow-specific operations out of the cocoon object that should be the common base for the object model, and therefore be identical in all places (flow, templates, form event listeners, etc). Would be nice! Having thought a little bit more about it I think that we, for the moment, just should make JXTG compatible with flow and independent of it. I take care of that if not anyone else feel like doing it. Then we can discuss refactorings, deprecation of confusing behaviour etc. But we need to support the behaviour of JXTG from 2.1 in 2.2 even if we hopefully can deprecate some stuff. Agree. IIRC, we also talked to have a new CTemplate generator, which could actually be the next-generation JXTG, working consistently with the refactored flow engine. Both being new components could concentrate on overall consistency without caring about backwards compatibility, whereas the existing classes whould have to ensure this compatibility. Exactly! We had some discussion about what CForms should contain in http://marc.theaimsgroup.com/?t=11094230054r=1w=2. It should IMO also contain the converters that we discussed half a year ago http://marc.theaimsgroup.com/?t=10994198833r=1w=2. /Daniel
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Sylvain Wallez wrote: Uh? What are these features? Would you mind sharing this with us? Sure; I already mentioned this months ago and even asked on this list for help; but noone was interested :( Actually, I was and am interested. I just can't get my boss to let me spend any time on it. Anyways, I'm thinking of adding a JMX interface, so you can monitor your Cocoon instance using JMX. I'm not sure which values you can monitor, but I'm thinking about monitoring the container (pool sizes etc.) and some configuration values for the first version. The second part - which is much more difficult - would be to allow to change some values during runtime. But this cause a lot of problems and I wanted to write an RT in the next days about it. Why is updating more difficult. We have MBeans that do both. Creating an operation that updates isn't that hard. The hard part is figuring out what you want to manage. Carsten Ralph
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote:
Actually, OSGi is a key point in the performance improvements in the
upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were
still written on the previous kernel API, and the more plugins move to
the OSGi API, the more startup time increases and memory used decreases,
by allowing on-demand loading of plugins.
See also:
-
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M7-200505131415/eclipse-news-all-M7.html
(second item)
- http://www.eclipse.org/eclipse/development/performance/index.html (the
performance bloopers page is a very interesting read)
the performance boost is incredible! Eclipse is up and running within about 5
seconds! That's great!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Micro kernel based Cocoon
Ralph Goers wrote: Why is updating more difficult. We have MBeans that do both. Creating an operation that updates isn't that hard. The hard part is figuring out what you want to manage. And what happens after you updated a value. Changing pool sizes or something like that is easy. But what about changing some core settings like the working directory (this is just an example, I don't say/know if that makes sense)? Several components use the working directory, so either you have to reinstantiate them or notify them or something like that. But neither option is really nice. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Ralph Goers wrote: Why is updating more difficult. We have MBeans that do both. Creating an operation that updates isn't that hard. The hard part is figuring out what you want to manage. And what happens after you updated a value. Changing pool sizes or something like that is easy. But what about changing some core settings like the working directory (this is just an example, I don't say/know if that makes sense)? Several components use the working directory, so either you have to reinstantiate them or notify them or something like that. But neither option is really nice. Carsten Sorry. I got the wrong impression from your earlier message. I thought you were implying that writing the MBeans to change things was somehow harder. Yes, some operations will be harder to perform than others. And in some cases an operation might be deemed too difficult to do, at least at first. However, I wouldn't go looking for operations to perform just because you can. I would start by identifying the operations you would find valuable and then prioritize them by need and difficulty to implement. Would your hypotheical of changing the working directory even make that list? Ralph
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: All current blocks, the core and libraries that are used by several bundles are packaged as bundles. These are deployed in a OSGi kernel. During development the Cocoon bundles can be deployed within the OSGi kernel of Eclipse together with various Cocoon develpment plugins (bundles). And during deployment the Cocoon bundles are deployed in a standalone kernel that either is started from within an servlet or at top level and contains a http server. The OSGi kernel is like an OS kernel. It takes care about starting and stoping bundles and to resolve dependencies between bundles and gives them a parent classloader containing their dependencies. The above means that we can get a much higher level of isolation beween different parts of core and between blocks. As the bundles don't need to expose all classes to everyone anymore. This is something that we allready need quite badly IMO, and a must if we wish to make it possible for external communities to develp Cocoon blocks. Ok, so far so good - now, what do I have to do if I'm developing my own application and want to use let's say the cron block: I want to add my own scheduled task? Currently I have to know a little bit about Avalon: using the service manager to lookup the component. Or to put it in other words, I have to know what the service locator concept is. And that's all. How does this look like with OSGi? And in this context, if I'm developing an own application, does this have to be an OSGi bundle as well? Read the subsections The main sitemap and The Cocoon service in the first post in this thread http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=111659636932761w=2. The application need to be a bundle, but that only means that there need to be a manifest file in it. Also the dependency information that we now handle in a rather implicit compile time way in blocks.properties, will need to be declared within the sitemap bundle. Everything else will be as before, you use the service manager for lookup as always. /Daniel
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, Here the main problem is that JXTG and flow have some differences in behaviour, see http://marc2.theaimsgroup.com/?t=11164826501r=1w=2 and http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=11182531907w=2 for description and possible solutions. We need to decide: should we keep trhe direct access of request params as properties of cocoon.request and session/context attributes as properties of cocoon.[session|context] or not. Should we support the direct usage of org.*, javax.* and com.* whithout needing the Packages. prefix in flow? Is there anythimg more? sitemap listeners, VPCs, I'm waiting for community involvement. If we follow Vadim's suggestion http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111331073205551w=2, nothing in core need to depend on vpc code and the vpc code could be moc´ved to an own (unstable) block. third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. As discussed in the relases thread I don't think it is realistic to stop adding features, we need a way to let rock stable core functionality coexist with new features. Otherwise the defacto no release policy will continue. /Daniel
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? /Daniel
Re: [RT] Micro kernel based Cocoon
Ralph Goers wrote: However, I wouldn't go looking for operations to perform just because you can. I would start by identifying the operations you would find valuable and then prioritize them by need and difficulty to implement. Would your hypotheical of changing the working directory even make that list? I honestly don't know :) - I tend to not include it. I started separating the available settings into not changeable and dynamic ones (see the interfaces BaseSettings and DynamicSettings in the core package). But that was just an initial random selection. Perhaps we end up with only a few dynamic settings. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Ok, so far so good - now, what do I have to do if I'm developing my own
application and want to use let's say the cron block: I want to add my
own scheduled task? Currently I have to know a little bit about Avalon:
using the service manager to lookup the component. Or to put it in other
words, I have to know what the service locator concept is. And that's
all. How does this look like with OSGi?
And in this context, if I'm developing an own application, does this
have to be an OSGi bundle as well?
Read the subsections The main sitemap and The Cocoon service in the
first post in this thread
http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=111659636932761w=2.
The application need to be a bundle, but that only means that there need
to be a manifest file in it. Also the dependency information that we now
handle in a rather implicit compile time way in blocks.properties, will
need to be declared within the sitemap bundle. Everything else will be
as before, you use the service manager for lookup as always.
I had a look at OSGi manifest files and I think we can generate out of our block
descriptors (block.xml) with the result that somebody who is writing a Cocoon
block doesn't even has to know that Cocoon is based on OSGi.
BTW, for all German speakers who have access to German magazins: Currently OSGi
seems to be a hot topic: In the current issues of Eclipse Magazin (05/03) and
Java Spektrum (05/02) there are articles about OSGi. The Eclipse Magazin
describes OSGi in Eclipse (of course) and the Java Spektrum article shows how to
use Oscar.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Vadim Gritsenko wrote: [...mostly off topic...] You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Well, is it really? So which point do you want to argue, that it won't be easier integration, or isn't an advantage? The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. Actually, OSGi is a key point in the performance improvements in the upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were still written on the previous kernel API, and the more plugins move to the OSGi API, the more startup time increases I could care less of startup time: I'm one of those who starts up IDE once in a month (after patching M$ windows ;-)). and memory used decreases, by allowing on-demand loading of plugins. On-demand loading means more sluggish UI, right? Once you click on something, you have to wait till it loads :-) Vadim
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, Here the main problem is that JXTG and flow have some differences in behaviour, see http://marc2.theaimsgroup.com/?t=11164826501r=1w=2 and http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=11182531907w=2 for description and possible solutions. We need to decide: should we keep trhe direct access of request params as properties of cocoon.request and session/context attributes as properties of cocoon.[session|context] or not. Should we support the direct usage of org.*, javax.* and com.* whithout needing the Packages. prefix in flow? On that point, I proposed to write a new implementation of the flowscript implementation. This is certainly not a total rewrite, but a refactoring of the existing code to have an overally consistent object model, and also introduce a flow object that would separate the flow-specific operations out of the cocoon object that should be the common base for the object model, and therefore be identical in all places (flow, templates, form event listeners, etc). Is there anythimg more? sitemap listeners, VPCs, I'm waiting for community involvement. If we follow Vadim's suggestion http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111331073205551w=2, nothing in core need to depend on vpc code and the vpc code could be moc´ved to an own (unstable) block. Sounds good. third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. As discussed in the relases thread I don't think it is realistic to stop adding features, we need a way to let rock stable core functionality coexist with new features. Otherwise the defacto no release policy will continue. Agree. That this rock solid core state that I'm currently not sure about, as many changes have occured there. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? The extension point system can be of great value: a plugin declares an extension point (e.g. the core can declare a source-factory extension point), and plugins can provide contributions to this extension point (e.g. the JCR block will contribute a jcr: source factory). The source resolver can then know all protocols that are provided by plugins somewhere in the system. AFAIU the plugin management stuff (download, update, etc) is specific, even if built on top of OSGi. Version management also. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.2 (was: [RT] Micro kernel based Cocoon)
On 5/23/05, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Le 23 mai 05, à 07:13, Reinhard Poetz a écrit : ...Let's release Cocoon 2.2 alpha1 as soon as possible. When the contracts are stable we use the beta postfix. This will increase the number of people who use and test the release and finally we can release Cocoon 2.2.0 final... Releasing 2.2 soon would allow us to stop keeping the 2.1 branch in sync, which is a pain IMHO. But are there enough visible incentives in 2.2 for people to make the switch? Do we have cool, exciting samples of the new features? I'm not sure, and if we haven't, people might just keep on using 2.1, and the risk is having too much pressure to maintain 2.1 instead of being able to move on. We tend to trail at least one release behind so that we can determine if any major bugs show up in a new release and what it means for us to migrate. On occasion that means we skip a release if something is broken that we depend on (rare) or if we get too far behind. More frequent release of Cocoon would just mean we skip more release... We do tend to use new features of Cocoon when we have a project underway that results in new code on our side. For instance, with our next major release of our code (currently in development, with 2 other releases in the testing pipeline in the mean time) we should finally have everything switched over to flow (no more actions for flow control). It wouldn't make a huge difference to us if a final 2.2.0 was released. If the reports where that it was somewhat stable, then sooner or later we'd get around to testing it and determining the impact on our application. Once we'd could evaluate that we'd fit the migration into our schedule. (If it's a big change, that might mean 6 months to a year before it hits production.) Personally, I'd say JFDI; build a 2.2 alpha, only put new features in 2.2 and plan on keeping on doing bug fixes on the 2.1 branch through at least a 2.1.9. -- Peter Hunsberger
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, sitemap listeners, VPCs, third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. I'm +1 for milestone release - 2.2m1 - especially since we have a history of those. Not sure it has to indicate end of new feature additions. Vadim
Re: [RT] Micro kernel based Cocoon
Vadim Gritsenko wrote: Sylvain Wallez wrote: Vadim Gritsenko wrote: [...mostly off topic...] You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Well, is it really? So which point do you want to argue, that it won't be easier integration, or isn't an advantage? Don't know. I just would like to know what advantages it can bring us, considering that not everybody will deploy Cocoon on Geronimo. The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. Actually, OSGi is a key point in the performance improvements in the upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were still written on the previous kernel API, and the more plugins move to the OSGi API, the more startup time increases I could care less of startup time: I'm one of those who starts up IDE once in a month (after patching M$ windows ;-)). Windoze running for one month? Wow, this is a magic patch :-) and memory used decreases, by allowing on-demand loading of plugins. On-demand loading means more sluggish UI, right? Once you click on something, you have to wait till it loads :-) Good point :-) But it also means things you don't need will never be loaded. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
Reinhard Poetz wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: IMO, OSGi seem to be the best choice for kernel for Cocoon's block architecture and there is (if I haven't missed something important) a low risk, incremental and evolutionary way to get there. Hmm, I'm currently not sure if we really need such an infrastructure for our own blocks; it seems like a big burden and might make things more complicated than they could be. Don't know. I still have the problem that I can't see what real world problems will be solved - breaking up the monolitic Cocoon - getting over the Java jar hell - making development of Cocoon extensions outside of the Cocoon project much easier (why there are hardly any Cocoon based projects out, except Daisy, Lenya, Forrest and two or three others) - ever tried to run your own project and let's say Forrest and maybe Lenya in one webapp application? Maybe possible but I wouldn't want to manage this configuration (and good luck with the next upgrade of one of them) Exactly! I'm engaged in this because it IMO will give us a much needed *simplification* of using and develping Cocoon. with this and what the drawbacks are. you're right, complexity is the price to pay. But maybe clearing contracts makes things more comprehensible in the future ... We have a lot of complexity today because of the lack of isolation mechanisms in Cocoon. It is monolithic and has so complicated internal contracts so that only a few people dare to touch it. Classloader isolation and declaration of dependencies and what is exposed, give us one mechanism for attacking this complexity. Sure, it sounds cool... Ok, anyways, I will not block any approach, I'm just trying to express my current feelings about it. But I really thing whatever we do, this should *not* be done in the current trunk. We should move 2.2 out the door as soon as possible and target real blocks for a later release. So, try out OSGi if you want, but please not in the trunk. The plan I suggest makes it possible to start develop it *whithin* trunk wtithout affecting current Cocoon. I'm very strongly against any more branching. IMO they have mainly been harmfull for us, this far. Why can't this be done in trunk as long as the old monolitic approach still works? AFAIU there will only be another Cocoon servlet that initializes the OSGi layer. If we come to the point that we have to introduce incompatibilites we can still decide to move out the OSGi version into its own branch. But I'm sure we will do our best to avoid any backward incompatibilites. IMHO development should happen in /trunk/src/osgi and build.properties contain a flag whether this or the stable version is built. We can do it that way. /Daniel
Re: [RT] Micro kernel based Cocoon
Reinhard Poetz wrote: - breaking up the monolitic Cocoon - getting over the Java jar hell - making development of Cocoon extensions outside of the Cocoon project much easier (why there are hardly any Cocoon based projects out, except Daisy, Lenya, Forrest and two or three others) - ever tried to run your own project and let's say Forrest and maybe Lenya in one webapp application? Maybe possible but I wouldn't want to manage this configuration (and good luck with the next upgrade of one of them) Ok, ok, I totally agree that we have to work on these points, no question. For most of the points above we could provide an improved build system, e.g. use Maven, and use the new functionalities we already have in 2.2 and that's it. But that's not my point. Cocoon has a very high learning curve, so we have to flatten this learning curve. Users never really understood Avalon; but interestingly everyone understands Spring - which is the same concepts of Avalon but done differently (I know, I simplify here a little bit, please, all Spring lovers forgive me for now!). Adding a complex block system on top of Cocoon doesn't make things easier. I have the fear that everything gets more complex and complicated and instead of flattening the learning curve, we increase it - and that's just because of beeing cool. - Don't get me wrong, I don't know if this will be the case, it just my feeling right now. During the GT last year we started a different route: flattening the learning curve by separating the core container (avalon based) from the things users should use. So in fact we encourage people to use something else with 2.2, like Spring or Hivemind or whatever. So the users don't have to learn Avalon anymore - again, a simplified view, but that's possible with 2.2 today. If we can make the block system - whatever it is - totally transparent in the same way, and users don't need to know about, great - but if we now exchange Avalon with let's say OSGi then this is in my view a big mistake. But again, if I'm the only one with these feelings, I can simply shut up and watch the show :( Why can't this be done in trunk as long as the old monolitic approach still works? AFAIU there will only be another Cocoon servlet that initializes the OSGi layer. If we come to the point that we have to introduce incompatibilites we can still decide to move out the OSGi version into its own branch. But I'm sure we will do our best to avoid any backward incompatibilites. IMHO development should happen in /trunk/src/osgi and build.properties contain a flag whether this or the stable version is built. If we now start with trunk, we will never get 2.2 out *without* this blocks concept working and that would delay everything imho. And AFAIU it's out of discussion that the OSGi layer will be part of Cocoon 2.2 - although it would be helpful to define what Cocoon 2.2 will be in order to get it out - in the past all my efforts to reach a common understanding were not very successful :-( You're not the only one. We have the hackathon at the ApacheCon or we can now start a thread about this topic and see (again) what other people think. In my opinion, 2.2 is more or less feature complete; there are *many* things to cleanup and I'm currently playing with adding administration and monitoring. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: SNIP/ But again, if I'm the only one with these feelings, I can simply shut up and watch the show :( Just to clarify: of course, this doesn't mean that I would not help or contribute. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Reinhard Poetz wrote: - breaking up the monolitic Cocoon - getting over the Java jar hell - making development of Cocoon extensions outside of the Cocoon project much easier (why there are hardly any Cocoon based projects out, except Daisy, Lenya, Forrest and two or three others) - ever tried to run your own project and let's say Forrest and maybe Lenya in one webapp application? Maybe possible but I wouldn't want to manage this configuration (and good luck with the next upgrade of one of them) Ok, ok, I totally agree that we have to work on these points, no question. For most of the points above we could provide an improved build system, e.g. use Maven, and use the new functionalities we already have in 2.2 and that's it. But that's not my point. Cocoon has a very high learning curve, so we have to flatten this learning curve. Users never really understood Avalon; but interestingly everyone understands Spring - which is the same concepts of Avalon but done differently (I know, I simplify here a little bit, please, all Spring lovers forgive me for now!). I have another opinion on this. Users never understood Avalong because of it's crappy/not existing documentation. .xconf file format is quite complex and documented nowhere. You start to get the picture after you know there is a .roles file somewhere. Most users do not even know one exists. Moreover now that Avalon is gone you have no documentation available, google search points to javadoc long time removed. You'll have luck if you are determined enough and find excalibur sources. On the contrary Spring has everything in one place. The documentation is broad and straightforward. I tried to find any starters for eclipse's OSGi implementation. Not a single useful page. If we are to make users read OSGi specification, then seek for help in external projects that are hardly documented we get the same problem in a fancy new outfit. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] Micro kernel based Cocoon
Leszek Gawron wrote: snip/ I tried to find any starters for eclipse's OSGi implementation. Not a single useful page. If we are to make users read OSGi specification, then seek for help in external projects that are hardly documented we get the same problem in a fancy new outfit. OSGi is a standard, so you don't need to depend on Eclipse's rather scattered OSGi docu. You can read overviews and download the standard from http://www.osgi.org/osgi_technology/index.asp?section=2. You can find online tutorials and API docu at http://www.knopflerfish.org/, http://oscar.objectweb.org/ and certainly other places. You can meet OSGi developers at http://www.osgicongress.com/. You can by comersial implementations, hopefully with docu from a number of companies: http://www.osgi.org/products/certification.asp?section=3. You can get traning: http://www.osgi.org/osgi_technology/osgi_training.asp?section=2. And there are a fair number of Eclipse plugin developers and embeded system developers who have experience with the framework. It's rather far away from Avalon docu status. /Daniel
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Reinhard Poetz wrote: - breaking up the monolitic Cocoon - getting over the Java jar hell - making development of Cocoon extensions outside of the Cocoon project much easier (why there are hardly any Cocoon based projects out, except Daisy, Lenya, Forrest and two or three others) - ever tried to run your own project and let's say Forrest and maybe Lenya in one webapp application? Maybe possible but I wouldn't want to manage this configuration (and good luck with the next upgrade of one of them) Ok, ok, I totally agree that we have to work on these points, no question. For most of the points above we could provide an improved build system, e.g. use Maven, and use the new functionalities we already have in 2.2 and that's it. But that's not my point. Cocoon has a very high learning curve, so we have to flatten this learning curve. That is my number one priority. About everything I propose aims towards this, if it actually will help is of course another question ;) Users never really understood Avalon; but interestingly everyone understands Spring - which is the same concepts of Avalon but done differently (I know, I simplify here a little bit, please, all Spring lovers forgive me for now!). Adding a complex block system on top of Cocoon doesn't make things easier. IMO it will. AFAIU the plugin concept in Eclipse is considered straight forward for most people. The blocks will be very similar to plugins. I have the fear that everything gets more complex and complicated and instead of flattening the learning curve, we increase it - and that's just because of beeing cool. - Don't get me wrong, I don't know if this will be the case, it just my feeling right now. IMO it will be the other way around. And be sure that its not based on just beeing cool. It solves very real and concrete problems. During the GT last year we started a different route: flattening the learning curve by separating the core container (avalon based) from the things users should use. So in fact we encourage people to use something else with 2.2, like Spring or Hivemind or whatever. So the users don't have to learn Avalon anymore - again, a simplified view, but that's possible with 2.2 today. If we can make the block system - whatever it is - totally transparent in the same way, and users don't need to know about, great - but if we now exchange Avalon with let's say OSGi then this is in my view a big mistake. Its not an exchange of Avalon with OSGi. In the firsts steps in the plan I propose OSGi is completely orthogonal to OSGi. It solves modularization, classloader and dependency concerns that our current container doesn't adress at all. In a later step we might or might not want to use OSGi services that overlaps with Avalon ones. But that is a later question that we can base on the experiences we have gained at that time. But again, if I'm the only one with these feelings, I can simply shut up and watch the show :( I think that everyone should raise their issues so that we don't misses any important consequences. So please continue to make your voice heard ;) Why can't this be done in trunk as long as the old monolitic approach still works? AFAIU there will only be another Cocoon servlet that initializes the OSGi layer. If we come to the point that we have to introduce incompatibilites we can still decide to move out the OSGi version into its own branch. But I'm sure we will do our best to avoid any backward incompatibilites. IMHO development should happen in /trunk/src/osgi and build.properties contain a flag whether this or the stable version is built. If we now start with trunk, we will never get 2.2 out *without* this blocks concept working and that would delay everything imho. I propose to add some build tasks that add fields to the manifest files. And to add some OSGi wrapper code outside the current Cocoon. There will, in the first steps, be no dependencies from the current Cocoon on OSGi. IMO this is unrelated to and will not affect any 2.2 release schedules. And AFAIU it's out of discussion that the OSGi layer will be part of Cocoon 2.2 - although it would be helpful to define what Cocoon 2.2 will be in order to get it out - in the past all my efforts to reach a common understanding were not very successful :-( You're not the only one. We have the hackathon at the ApacheCon or we can now start a thread about this topic and see (again) what other people think. In my opinion, 2.2 is more or less feature complete; there are *many* things to cleanup and I'm currently playing with adding administration and monitoring. If you feel that it is feature complete you can release an alpha right away. Cleenup can be done afterwards. If you can author a list on what you think needs cleanup, it would help. /Daniel
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: IMO it will. AFAIU the plugin concept in Eclipse is considered straight forward for most people. The blocks will be very similar to plugins. Ok, but even if it's simple, you have to learn it :) Its not an exchange of Avalon with OSGi. I know, I didn't mean a technical exchange but a barrier exchange. I think that everyone should raise their issues so that we don't misses any important consequences. So please continue to make your voice heard ;) I'm currently still missing the *big picture*. What are blocks, how does Cocoon look like with them. Can I develop something without blocks? What do I have to learn? And so on. This might be because I didn't have so much time for Cocoon in the last weeks, don't know. If you feel that it is feature complete you can release an alpha right away. Cleenup can be done afterwards. If you can author a list on what you think needs cleanup, it would help. :) I'll see what I can do about it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
IMO it will. AFAIU the plugin concept in Eclipse is considered straight
forward for most people. The blocks will be very similar to plugins.
Ok, but even if it's simple, you have to learn it :)
Its not an exchange of Avalon with OSGi.
I know, I didn't mean a technical exchange but a barrier exchange.
I think that everyone should raise their issues so that we don't misses
any important consequences. So please continue to make your voice heard ;)
I'm currently still missing the *big picture*. What are blocks, how does
Cocoon look like with them. Can I develop something without blocks? What
do I have to learn? And so on. This might be because I didn't have so
much time for Cocoon in the last weeks, don't know.
We had some very long threads about these questions. One of the conclusions of
them was that we have discussed enough *for now* and should come up with a
prototyp. Then we have something real that can be discussed in every detail again.
After the three days Blockathon I really want to see a *prototyp
implementation*. I don't say that everything has to work but we should have the
important contracts defined and more important, a *common understanding* on what
we want to reach.
If you feel that it is feature complete you can release an alpha right
away. Cleenup can be done afterwards. If you can author a list on what
you think needs cleanup, it would help.
:)
I'll see what I can do about it.
AFAIU only some work on cForms is missing (flowscript API and repeater binding)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: snip/ I'm currently still missing the *big picture*. What are blocks, how does Cocoon look like with them. Can I develop something without blocks? What do I have to learn? And so on. This might be because I didn't have so much time for Cocoon in the last weeks, don't know. It would require quite a lot of work to give a fair overview of what we have discussed about this in the last three or so years. You find some info in http://wiki.apache.org/cocoon/Blocks. And for the relation to OSGi I suggest that you reread my first post in this thread together with some of the references. I can give a short overview on how I currently view what Cocoon would look like if we go the OSGi bundle way. All current blocks, the core and libraries that are used by several bundles are packaged as bundles. These are deployed in a OSGi kernel. During development the Cocoon bundles can be deployed within the OSGi kernel of Eclipse together with various Cocoon develpment plugins (bundles). And during deployment the Cocoon bundles are deployed in a standalone kernel that either is started from within an servlet or at top level and contains a http server. The OSGi kernel is like an OS kernel. It takes care about starting and stoping bundles and to resolve dependencies between bundles and gives them a parent classloader containing their dependencies. The above means that we can get a much higher level of isolation beween different parts of core and between blocks. As the bundles don't need to expose all classes to everyone anymore. This is something that we allready need quite badly IMO, and a must if we wish to make it possible for external communities to develp Cocoon blocks. Having this means that a user can download a minimal Cocoon disto with some core bundles and a bundle (block) management utility. This can then be used for download and deploy the rest of the bundles that the user need. I also think that the current core should be splited in a number of bundles. I would like to have a Cocoon core bundle that contains the tree processor, the component manager and core interfaces. The Cocoon core will define what Cocoon is. It will have an own release cycle like an OS kernel. And the stable release should be rock stable. The servlet and CLI environments should be own bundles. The flowscripts could be an own bundle. Most of the components in current core could be transfered to own bundles. By breaking up todays monolitic core we are able to deprecate things that we don't believe in anymore and move to an own bundles that still will make the functionality available for those depending on it, whithout making core bloated. --- o0o --- Above this we have the sitemap aspect of blocks. Its more at the application level and doesn't have much to do with our current blocks. It is more for creating reusable application frameworks. It will be usefull for projects like Forrest, Lenya, Daisy, Linotype and probably for Portal. It gives you a possiblity to create bundles that not only exposes components and can contain own components, but also make sitemap functionality available through the block protocol. /Daniel
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: All current blocks, the core and libraries that are used by several bundles are packaged as bundles. These are deployed in a OSGi kernel. During development the Cocoon bundles can be deployed within the OSGi kernel of Eclipse together with various Cocoon develpment plugins (bundles). And during deployment the Cocoon bundles are deployed in a standalone kernel that either is started from within an servlet or at top level and contains a http server. The OSGi kernel is like an OS kernel. It takes care about starting and stoping bundles and to resolve dependencies between bundles and gives them a parent classloader containing their dependencies. The above means that we can get a much higher level of isolation beween different parts of core and between blocks. As the bundles don't need to expose all classes to everyone anymore. This is something that we allready need quite badly IMO, and a must if we wish to make it possible for external communities to develp Cocoon blocks. Ok, so far so good - now, what do I have to do if I'm developing my own application and want to use let's say the cron block: I want to add my own scheduled task? Currently I have to know a little bit about Avalon: using the service manager to lookup the component. Or to put it in other words, I have to know what the service locator concept is. And that's all. How does this look like with OSGi? And in this context, if I'm developing an own application, does this have to be an OSGi bundle as well? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: In my opinion, 2.2 is more or less feature complete; there are *many* things to cleanup Definitely. and I'm currently playing with adding administration and monitoring. Uh? What are these features? Would you mind sharing this with us? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, sitemap listeners, VPCs, third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Users never really understood Avalon; but interestingly everyone understands Spring - which is the same concepts of Avalon but done differently (I know, I simplify here a little bit, please, all Spring lovers forgive me for now!). Adding a complex block system on top of Cocoon doesn't make things easier. IMO it will. AFAIU the plugin concept in Eclipse is considered straight forward for most people. The blocks will be very similar to plugins. And there are several dozen books about this subject :-) We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. snip/ If we now start with trunk, we will never get 2.2 out *without* this blocks concept working and that would delay everything imho. I propose to add some build tasks that add fields to the manifest files. And to add some OSGi wrapper code outside the current Cocoon. There will, in the first steps, be no dependencies from the current Cocoon on OSGi. IMO this is unrelated to and will not affect any 2.2 release schedules. Agree. This can at start be a special build script that packages existing sources differently, with of course some OSGi glue. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Releasing 2.2 (was: [RT] Micro kernel based Cocoon)
Le 23 mai 05, à 07:13, Reinhard Poetz a écrit : ...Let's release Cocoon 2.2 alpha1 as soon as possible. When the contracts are stable we use the beta postfix. This will increase the number of people who use and test the release and finally we can release Cocoon 2.2.0 final... Releasing 2.2 soon would allow us to stop keeping the 2.1 branch in sync, which is a pain IMHO. But are there enough visible incentives in 2.2 for people to make the switch? Do we have cool, exciting samples of the new features? I'm not sure, and if we haven't, people might just keep on using 2.1, and the risk is having too much pressure to maintain 2.1 instead of being able to move on. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Uh? What are these features? Would you mind sharing this with us? Sure; I already mentioned this months ago and even asked on this list for help; but noone was interested :( Anyways, I'm thinking of adding a JMX interface, so you can monitor your Cocoon instance using JMX. I'm not sure which values you can monitor, but I'm thinking about monitoring the container (pool sizes etc.) and some configuration values for the first version. The second part - which is much more difficult - would be to allow to change some values during runtime. But this cause a lot of problems and I wanted to write an RT in the next days about it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Micro kernel use cases? (was: [RT] Micro kernel based Cocoon)
Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit : ...It would require quite a lot of work to give a fair overview of what we have discussed about this in the last three or so years. You find some info in http://wiki.apache.org/cocoon/Blocks... Would it be possible to come up with a (small) set of blocks-oriented use cases to re-sync our collective vision of what a micro-kernel Cocoon would bring? I'm thinking of use cases like start the Cocoon kernel, load a block at startup, locate and download a block after startup, debug my block during development, use a block service from my own code, etc. I don't know if the granularity is right, but having a set of use-cases (not more than about two A4-pages?) might make it easier to agree on concrete ideas. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Micro kernel based Cocoon
Le 23 mai 05, à 07:32, Carsten Ziegeler a écrit : ..I'm thinking of adding a JMX interface, so you can monitor your Cocoon instance using JMX... ...The second part - which is much more difficult - would be to allow to change some values during runtime... Hmm...maybe this second part makes a good use-case for a micro-kernel based Cocoon? ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Micro kernel based Cocoon
Le 20 mai 05, à 15:38, Daniel Fagerstrom a écrit : Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go... After reading some of the knopflerfish and osgi.org material I agree that an OSGI kernel looks really good for our purposes. Standing on the shoulders of *other* giants might be a good idea for these relatively complex things, provided the external tools are backed by a solid (and ASF-compatible) community. I haven't looked much at http://oscar.objectweb.org/ yet, but from a community point of view it might be a good idea to build more bridges to the ObjectWeb community - they seem to have some great stuff there. ...Following the above architecture, or some better ;) we can start experimenting with classloader isolation, deplyment from remote repositories and so on without introducing any back incompabilities or having to do any major rewritings... To me this is a killer advantage of your proposal. Big +1, or rather +0 as I won't have much cycles to contribute. But following the idea at least until it can be compared (also in performance) with the current code sounds really good. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go. Yeah! Kewl :-) OSGi The OSGi service platform is a standarized, component oriented, computing environment for networked services. It handled bundles, which from a deplyment perspective can be any jar with some extra meta info in the manifest. Each bundle declare its dependencies on other bundles and what packages it exposes. The framework takes care about classloader isolation and there are also support for hot deployment, (which require more work in writing the bundles). There is lifecycle support for dynamical: installation, start, stop, update and uninstallation of bundles. There is a service layer with registration and lookup of services. A number of APIs for standard services has also be defined [1] e.g. log, configuration, user admin and http services. OSGi specification is currently at its 3rd release. It is used as kernel for Eclipse (since 3.0), each plugin is a bundle. It is used for embeded applications e.g. BMWs 5 series, mobile phones etc. FYI, BMWs 7 series have 20 Mb of embedded Java. Yes, megabytes! There are 12 compliant implementations and at least 3 with friendly licenses: the Eclipse kernel [4] (release 3+), Knoplerfish [5] (release 3), Oscar [6] (release 3-). There is also a bundle repository [7]. And another bundle repository here: http://www.knopflerfish.org/repo/index.html The Eclipse OSGi contain some extra functionallity that probably will be part of OSGi release 4. Knoplerfish is more lightweight and has a minimal framework distribution at only 200kB. Alternatives So what would be the alternatives to using OSGi? We have Pier's kernel, Metro [8] and Geronimos GBeans [9]. For Pier's kernel is solves AFACS a subset of what OSGi does and IMO we shouldn't base something as important as the Cocoon kernel on a one man show if we can avoid it. Using Metro will just not happen due to community reasons. So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. We allready have people in the community (Sylvain, maybe other Eclipse developers?) with previous experience in using it. Every Eclipse plugin developer more or less needs to understand how this system works. So this makes a fair number of people :-) Getting it done === As about any component framework ever concieved, allready has been proposed to solve the real blocks problem but we still doesn't have them, I would like to be a little bit more specific about how we could actually get there with OSGi. My main design criteria (except for solving the problem ;) ) is that we should have an incremental, evolutionary aporach. No next generation, no new SVN branches, no major rewrites. The rest will by nececity be more technical. Cocoon bundles -- The first step is to make Cocoon OSGi compliant by packaging the core and the blocks as (passive library) bundles. It just means that we add some meta info to the manifest files of the jars for core and blocks. Most of the info is allready available in the gump.xml and can be automatically added to the mainfests by the build system. For each block and core we need to decide what it exposes, which initially could be everything, and its dependecy on other block and libraries. It would also be and advantage to package all the jars that are used by more than one block as a bundle. This step doesn't affect Cocoon as we know it at all. We just make it possible to load core and blocks into the OSGi environment (or Eclipse). OTH nothing will happen when we use OSGi this far. The main sitemap It should be as simple as possible for a user to add a webapp, so I think that a basic webapp bundle should be as simple as a directory with a sitemap in it and a WEB-INF with the basic configuration files. In the bundle scenario we don't need to put the core and block jars in WEB-INF as these are managed within the OSGi framework. What is needed is some meta info that says that the bundle contains the main sitemap, so that the (soon to be described) Cocoon service can search for the bundle and a list of what blocks (bundles) it depends on so that the Cocoon service can dynamically load all its dependencies. The Cocoon service -- The Cocoon service is the first bundle that is active, in the sense that it implements BundleActivator and is started by the frameworks
Re: [RT] Micro kernel based Cocoon
Thor Heinrichs-Wolpert wrote: Daniel: Check out RIO, which is a QoS oriented system based upon Jini. It has either completed its relicensing or will have completed its relicensing to use the Apache 2.0 license. This is the infrastructure used in Sun's RFID initiative and in their Formula1 Race Car monitoring system. I can poorly describe RIO as a framework for service beans, their dependencies and the QoS the components expect. Does it provide somthing similar to bundles and the classloader functionality in OSGi? It seem much earlier in development and spread than OSGi, can you explain what advantages it would have for us. /Daniel
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Daniel Fagerstrom wrote: snip/ The Cocoon servlet bundle - At last we need to have a Cocoon servlet bundle it looks up the Cocoon service and a HTTP service [10] (both Tomcat and Jetty implementations are available), embeds the Cocoon service in the Cocoon servlet and register it in the HTTP service. That is all. For some uses it would probably be good to be able to package everything including the OSGi framework as a WAR that can be deplyoyed into a Servlet container. I haven't thought about how to acomplish that. A CLI bundle would also be useful. Requiring the availability of an HTTP service would be too restrictive, because most J2EE servers don't expose such a service. So we must still have a CocoonServlet that will start the micro-kernel. Agree. Any ideas about how to achieve that? Are there standaridized ways for create and start an OSGi micro kernel and for communicating with its services? /Daniel
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain Wallez wrote: Daniel Fagerstrom wrote: snip/ The Cocoon servlet bundle - At last we need to have a Cocoon servlet bundle it looks up the Cocoon service and a HTTP service [10] (both Tomcat and Jetty implementations are available), embeds the Cocoon service in the Cocoon servlet and register it in the HTTP service. That is all. For some uses it would probably be good to be able to package everything including the OSGi framework as a WAR that can be deplyoyed into a Servlet container. I haven't thought about how to acomplish that. A CLI bundle would also be useful. Requiring the availability of an HTTP service would be too restrictive, because most J2EE servers don't expose such a service. So we must still have a CocoonServlet that will start the micro-kernel. Agree. Any ideas about how to achieve that? Replace CocoonServlet.createCocoon by CocoonServlet.createCocoonKernel :-) That method would instanciate the kernel and get the main Cocoon service. Are there standaridized ways for create and start an OSGi micro kernel and for communicating with its services? Not that I'm aware of, but it is acceptable for the bootstrap code to be dependent on the OSGi implementation used (a factory can be used too). Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Well, is it really? Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. Actually, OSGi is a key point in the performance improvements in the upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were still written on the previous kernel API, and the more plugins move to the OSGi API, the more startup time increases and memory used decreases, by allowing on-demand loading of plugins. See also: - http://download.eclipse.org/eclipse/downloads/drops/S-3.1M7-200505131415/eclipse-news-all-M7.html (second item) - http://www.eclipse.org/eclipse/development/performance/index.html (the performance bloopers page is a very interesting read) Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Micro kernel based Cocoon
On Vie, 20 de Mayo de 2005, 8:38, Daniel Fagerstrom dijo: Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go. OSGi The OSGi service platform is a standarized, component oriented, computing environment for networked services. It handled bundles, which from a deplyment perspective can be any jar with some extra meta info in the manifest. Each bundle declare its dependencies on other bundles and what packages it exposes. The framework takes care about classloader isolation and there are also support for hot deployment, (which require more work in writing the bundles). There is lifecycle support for dynamical: installation, start, stop, update and uninstallation of bundles. Cocooon configuration at run time! This sounds great! snip/ Getting it done === No next generation, no new SVN branches, no major rewrites. Big +1! snip/ --- o0o --- IMO, OSGi seem to be the best choice for kernel for Cocoon's block architecture and there is (if I haven't missed something important) a low risk, incremental and evolutionary way to get there. WDYT? +1! Thanks for the RT! Best Regards, Antonio Gallardo
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: IMO, OSGi seem to be the best choice for kernel for Cocoon's block architecture and there is (if I haven't missed something important) a low risk, incremental and evolutionary way to get there. Hmm, I'm currently not sure if we really need such an infrastructure for our own blocks; it seems like a big burden and might make things more complicated than they could be. Don't know. I still have the problem that I can't see what real world problems will be solved with this and what the drawbacks are. Sure, it sounds cool... Ok, anyways, I will not block any approach, I'm just trying to express my current feelings about it. But I really thing whatever we do, this should *not* be done in the current trunk. We should move 2.2 out the door as soon as possible and target real blocks for a later release. So, try out OSGi if you want, but please not in the trunk. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
IMO, OSGi seem to be the best choice for kernel for Cocoon's block
architecture and there is (if I haven't missed something important) a
low risk, incremental and evolutionary way to get there.
Hmm, I'm currently not sure if we really need such an infrastructure for
our own blocks; it seems like a big burden and might make things more
complicated than they could be. Don't know.
I still have the problem that I can't see what real world problems will
be solved
- breaking up the monolitic Cocoon
- getting over the Java jar hell
- making development of Cocoon extensions outside of the
Cocoon project much easier (why there are hardly any Cocoon based
projects out, except Daisy, Lenya, Forrest and two or three others)
- ever tried to run your own project and let's say Forrest
and maybe Lenya in one webapp application? Maybe possible but
I wouldn't want to manage this configuration (and good luck
with the next upgrade of one of them)
with this and what the drawbacks are.
you're right, complexity is the price to pay. But maybe clearing contracts makes
things more comprehensible in the future ...
Sure, it sounds cool...
Ok, anyways, I will not block any approach, I'm just trying to express
my current feelings about it. But I really thing whatever we do, this
should *not* be done in the current trunk. We should move 2.2 out the
door as soon as possible and target real blocks for a later release.
So, try out OSGi if you want, but please not in the trunk.
Why can't this be done in trunk as long as the old monolitic approach still
works? AFAIU there will only be another Cocoon servlet that initializes the OSGi
layer. If we come to the point that we have to introduce incompatibilites we can
still decide to move out the OSGi version into its own branch. But I'm sure we
will do our best to avoid any backward incompatibilites. IMHO development should
happen in /trunk/src/osgi and build.properties contain a flag whether this or
the stable version is built.
And AFAIU it's out of discussion that the OSGi layer will be part of Cocoon 2.2
- although it would be helpful to define what Cocoon 2.2 will be in order to get
it out - in the past all my efforts to reach a common understanding were not
very successful :-(
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
The Cocoon servlet bundle
-
At last we need to have a Cocoon servlet bundle it looks up the Cocoon
service and a HTTP service [10] (both Tomcat and Jetty implementations
are available), embeds the Cocoon service in the Cocoon servlet and
register it in the HTTP service. That is all.
For some uses it would probably be good to be able to package
everything including the OSGi framework as a WAR that can be deplyoyed
into a Servlet container. I haven't thought about how to acomplish that.
A CLI bundle would also be useful.
Requiring the availability of an HTTP service would be too restrictive,
because most J2EE servers don't expose such a service. So we must still
have a CocoonServlet that will start the micro-kernel. Of course this
doesn't preclude having a servlet bundle using the HTTP service.
Yes, that's a very important point. Cocoon mustn't require any modficuations on
the servlet or J2EE container.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[RT] Micro kernel based Cocoon
Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go. OSGi The OSGi service platform is a standarized, component oriented, computing environment for networked services. It handled bundles, which from a deplyment perspective can be any jar with some extra meta info in the manifest. Each bundle declare its dependencies on other bundles and what packages it exposes. The framework takes care about classloader isolation and there are also support for hot deployment, (which require more work in writing the bundles). There is lifecycle support for dynamical: installation, start, stop, update and uninstallation of bundles. There is a service layer with registration and lookup of services. A number of APIs for standard services has also be defined [1] e.g. log, configuration, user admin and http services. OSGi specification is currently at its 3rd release. It is used as kernel for Eclipse (since 3.0), each plugin is a bundle. It is used for embeded applications e.g. BMWs 5 series, mobile phones etc. There are 12 compliant implementations and at least 3 with friendly licenses: the Eclipse kernel [4] (release 3+), Knoplerfish [5] (release 3), Oscar [6] (release 3-). There is also a bundle repository [7]. The Eclipse OSGi contain some extra functionallity that probably will be part of OSGi release 4. Knoplerfish is more lightweight and has a minimal framework distribution at only 200kB. Alternatives So what would be the alternatives to using OSGi? We have Pier's kernel, Metro [8] and Geronimos GBeans [9]. For Pier's kernel is solves AFACS a subset of what OSGi does and IMO we shouldn't base something as important as the Cocoon kernel on a one man show if we can avoid it. Using Metro will just not happen due to community reasons. So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. We allready have people in the community (Sylvain, maybe other Eclipse developers?) with previous experience in using it. Getting it done === As about any component framework ever concieved, allready has been proposed to solve the real blocks problem but we still doesn't have them, I would like to be a little bit more specific about how we could actually get there with OSGi. My main design criteria (except for solving the problem ;) ) is that we should have an incremental, evolutionary aporach. No next generation, no new SVN branches, no major rewrites. The rest will by nececity be more technical. Cocoon bundles -- The first step is to make Cocoon OSGi compliant by packaging the core and the blocks as (passive library) bundles. It just means that we add some meta info to the manifest files of the jars for core and blocks. Most of the info is allready available in the gump.xml and can be automatically added to the mainfests by the build system. For each block and core we need to decide what it exposes, which initially could be everything, and its dependecy on other block and libraries. It would also be and advantage to package all the jars that are used by more than one block as a bundle. This step doesn't affect Cocoon as we know it at all. We just make it possible to load core and blocks into the OSGi environment (or Eclipse). OTH nothing will happen when we use OSGi this far. The main sitemap It should be as simple as possible for a user to add a webapp, so I think that a basic webapp bundle should be as simple as a directory with a sitemap in it and a WEB-INF with the basic configuration files. In the bundle scenario we don't need to put the core and block jars in WEB-INF as these are managed within the OSGi framework. What is needed is some meta info that says that the bundle contains the main sitemap, so that the (soon to be described) Cocoon service can search for the bundle and a list of what blocks (bundles) it depends on so that the Cocoon service can dynamically load all its dependencies. The Cocoon service -- The Cocoon service is the first bundle that is active, in the sense that it implements BundleActivator and is started by the frameworks lifecycle management. The Cocoon service publish an implemention of o.a.c.Processor as a service. It does this by looking up the main sitemap bundle above, dynamically installing all the blocks that the main sitemap bundles declare that it depends on and create an o.a.c.Cocoon based on this bundle and that uses the classloader that contains all
Re: [RT] Micro kernel based Cocoon
An interesting read. Where does the servlet container sit within this picture? Do you need to have an OSGi servlet? Eclipse could by the sound of it load these bundles, but wouldn't be able to run them due to a lack of servlet container. Regards, Upayavira Daniel Fagerstrom wrote: Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go. OSGi The OSGi service platform is a standarized, component oriented, computing environment for networked services. It handled bundles, which from a deplyment perspective can be any jar with some extra meta info in the manifest. Each bundle declare its dependencies on other bundles and what packages it exposes. The framework takes care about classloader isolation and there are also support for hot deployment, (which require more work in writing the bundles). There is lifecycle support for dynamical: installation, start, stop, update and uninstallation of bundles. There is a service layer with registration and lookup of services. A number of APIs for standard services has also be defined [1] e.g. log, configuration, user admin and http services. OSGi specification is currently at its 3rd release. It is used as kernel for Eclipse (since 3.0), each plugin is a bundle. It is used for embeded applications e.g. BMWs 5 series, mobile phones etc. There are 12 compliant implementations and at least 3 with friendly licenses: the Eclipse kernel [4] (release 3+), Knoplerfish [5] (release 3), Oscar [6] (release 3-). There is also a bundle repository [7]. The Eclipse OSGi contain some extra functionallity that probably will be part of OSGi release 4. Knoplerfish is more lightweight and has a minimal framework distribution at only 200kB. Alternatives So what would be the alternatives to using OSGi? We have Pier's kernel, Metro [8] and Geronimos GBeans [9]. For Pier's kernel is solves AFACS a subset of what OSGi does and IMO we shouldn't base something as important as the Cocoon kernel on a one man show if we can avoid it. Using Metro will just not happen due to community reasons. So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. We allready have people in the community (Sylvain, maybe other Eclipse developers?) with previous experience in using it. Getting it done === As about any component framework ever concieved, allready has been proposed to solve the real blocks problem but we still doesn't have them, I would like to be a little bit more specific about how we could actually get there with OSGi. My main design criteria (except for solving the problem ;) ) is that we should have an incremental, evolutionary aporach. No next generation, no new SVN branches, no major rewrites. The rest will by nececity be more technical. Cocoon bundles -- The first step is to make Cocoon OSGi compliant by packaging the core and the blocks as (passive library) bundles. It just means that we add some meta info to the manifest files of the jars for core and blocks. Most of the info is allready available in the gump.xml and can be automatically added to the mainfests by the build system. For each block and core we need to decide what it exposes, which initially could be everything, and its dependecy on other block and libraries. It would also be and advantage to package all the jars that are used by more than one block as a bundle. This step doesn't affect Cocoon as we know it at all. We just make it possible to load core and blocks into the OSGi environment (or Eclipse). OTH nothing will happen when we use OSGi this far. The main sitemap It should be as simple as possible for a user to add a webapp, so I think that a basic webapp bundle should be as simple as a directory with a sitemap in it and a WEB-INF with the basic configuration files. In the bundle scenario we don't need to put the core and block jars in WEB-INF as these are managed within the OSGi framework. What is needed is some meta info that says that the bundle contains the main sitemap, so that the (soon to be described) Cocoon service can search for the bundle and a list of what blocks (bundles) it depends on so that the Cocoon service can dynamically load all its dependencies. The Cocoon service -- The Cocoon service is the first bundle that is active, in the sense that it implements BundleActivator and is started by the frameworks lifecycle management. The Cocoon service publish an implemention
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go. Alternatives So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. Vadim
Re: [RT] Micro kernel based Cocoon
Upayavira wrote: An interesting read. Where does the servlet container sit within this picture? Simplest way is to use an implementation of the HTTP service [1], there is a Jetty version http://oscar-osgi.sourceforge.net/repo/http/, a version with (AFAICS) an own servlet conatiner http://www.knopflerfish.org/releases/1.3.3/jars/index.html for the Tomcat plugin in Eclipse I don't know if it implements OSGis HTTP service or not. Don't know how you use it from a stand alone service container. Do you need to have an OSGi servlet? Its the simplest way. Eclipse could by the sound of it load these bundles, but wouldn't be able to run them due to a lack of servlet container. Don't know what servlet contract Eclipse use, but as it is a OSGi container any implementation of the OSGi HTTP service should be possible to use. Regards, Upayavira Daniel Fagerstrom wrote: snip/ The Cocoon servlet bundle - At last we need to have a Cocoon servlet bundle it looks up the Cocoon service and a HTTP service [10] (both Tomcat and Jetty implementations are available), embeds the Cocoon service in the Cocoon servlet and register it in the HTTP service. That is all. For some uses it would probably be good to be able to package everything including the OSGi framework as a WAR that can be deplyoyed into a Servlet container. I haven't thought about how to acomplish that. snip/ [10] http://www.knopflerfish.org/releases/1.3.3/javadoc/org/osgi/service/http/package-summary.html Hopefully some of our Eclipse experts can give a better answer. /Daniel
Re: [RT] Micro kernel based Cocoon
Daniel: Check out RIO, which is a QoS oriented system based upon Jini. It has either completed its relicensing or will have completed its relicensing to use the Apache 2.0 license. This is the infrastructure used in Sun's RFID initiative and in their Formula1 Race Car monitoring system. I can poorly describe RIO as a framework for service beans, their dependencies and the QoS the components expect. Cheers, Thor HW On 20-May-05, at 6:38 AM, Daniel Fagerstrom wrote: Sylvain proposed [1] to base blocks on the OSGi service platform [2] [3]. After having studied it in more detail I'm completely convinced that it is the way to go. OSGi The OSGi service platform is a standarized, component oriented, computing environment for networked services. It handled bundles, which from a deplyment perspective can be any jar with some extra meta info in the manifest. Each bundle declare its dependencies on other bundles and what packages it exposes. The framework takes care about classloader isolation and there are also support for hot deployment, (which require more work in writing the bundles). There is lifecycle support for dynamical: installation, start, stop, update and uninstallation of bundles. There is a service layer with registration and lookup of services. A number of APIs for standard services has also be defined [1] e.g. log, configuration, user admin and http services. OSGi specification is currently at its 3rd release. It is used as kernel for Eclipse (since 3.0), each plugin is a bundle. It is used for embeded applications e.g. BMWs 5 series, mobile phones etc. There are 12 compliant implementations and at least 3 with friendly licenses: the Eclipse kernel [4] (release 3+), Knoplerfish [5] (release 3), Oscar [6] (release 3-). There is also a bundle repository [7]. The Eclipse OSGi contain some extra functionallity that probably will be part of OSGi release 4. Knoplerfish is more lightweight and has a minimal framework distribution at only 200kB. Alternatives So what would be the alternatives to using OSGi? We have Pier's kernel, Metro [8] and Geronimos GBeans [9]. For Pier's kernel is solves AFACS a subset of what OSGi does and IMO we shouldn't base something as important as the Cocoon kernel on a one man show if we can avoid it. Using Metro will just not happen due to community reasons. So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. We allready have people in the community (Sylvain, maybe other Eclipse developers?) with previous experience in using it. Getting it done === As about any component framework ever concieved, allready has been proposed to solve the real blocks problem but we still doesn't have them, I would like to be a little bit more specific about how we could actually get there with OSGi. My main design criteria (except for solving the problem ;) ) is that we should have an incremental, evolutionary aporach. No next generation, no new SVN branches, no major rewrites. The rest will by nececity be more technical. Cocoon bundles -- The first step is to make Cocoon OSGi compliant by packaging the core and the blocks as (passive library) bundles. It just means that we add some meta info to the manifest files of the jars for core and blocks. Most of the info is allready available in the gump.xml and can be automatically added to the mainfests by the build system. For each block and core we need to decide what it exposes, which initially could be everything, and its dependecy on other block and libraries. It would also be and advantage to package all the jars that are used by more than one block as a bundle. This step doesn't affect Cocoon as we know it at all. We just make it possible to load core and blocks into the OSGi environment (or Eclipse). OTH nothing will happen when we use OSGi this far. The main sitemap It should be as simple as possible for a user to add a webapp, so I think that a basic webapp bundle should be as simple as a directory with a sitemap in it and a WEB-INF with the basic configuration files. In the bundle scenario we don't need to put the core and block jars in WEB-INF as these are managed within the OSGi framework. What is needed is some meta info that says that the bundle contains the main sitemap, so that the (soon to be described) Cocoon service can search for the bundle and a list of what blocks (bundles) it depends on so that the Cocoon service can dynamically load all its
Re: [RT] Micro kernel based Cocoon
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: Sylvain proposed [1] to base blocks on the OSGi service platform [2][3]. After having studied it in more detail I'm completely convinced that it is the way to go. Alternatives So GBeans seem like the only serious alternative. I don't know enough about GBeans to be able to evaluate it. But its much earlier in its development, it is not a standard and there is only one implementation, so it should IMO have a considerable technical advantage to OSGi to be used instead. You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Might be, I don't have enough knowledge (or interest for, at least yet ;) ) about Geronimo to be able to evaluate it. An evaluation of what Geronimo would give us would certainly be interesting. Care to flesh out in what way an integration with Geronimo would be an significant advantage? Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. I haven't tested it yet, so I don't know. But considering that OSGi is used on mobile phones and within consumer electronics and have been around for 5 years I would be supprised if it was slow. Here http://eul.shacknet.nu/www/index.html you can read (about) a blog that is hosted under OSGi on a WLAN access point :) /Daniel
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Vadim Gritsenko wrote: You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Might be, I don't have enough knowledge (or interest for, at least yet ;) ) about Geronimo to be able to evaluate it. An evaluation of what Geronimo would give us would certainly be interesting. Care to flesh out in what way an integration with Geronimo would be an significant advantage? It means it is easier to sneak in Cocoon into places where Geronimo is employed :-) Also I would assume that the fact that Eclipse is based on OSGi will mean that it would be much easier to write various Cocoon tools if we base Cocoon on OSGi. The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. I haven't tested it yet, so I don't know. But considering that OSGi is used on mobile phones and within consumer electronics and have been around for 5 years I would be supprised if it was slow. Ok, that's good news :-) So even if it is slow, it is at least small! :-P Here http://eul.shacknet.nu/www/index.html you can read (about) a blog that is hosted under OSGi on a WLAN access point :) :-) PS I liked your plan, though. Large disruptions are not what we need, and your proposed approach does not have them, which is great. Vadim
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: OSGi specification is currently at its 3rd release. It is used as kernel for Eclipse (since 3.0), each plugin is a bundle. It is used for embeded applications e.g. BMWs 5 series, mobile phones etc. There are 12 compliant implementations and at least 3 with friendly licenses: the Eclipse kernel [4] (release 3+), Knoplerfish [5] (release 3), Oscar [6] (release 3-). There is also a bundle repository [7]. The Eclipse OSGi contain some extra functionallity that probably will be part of OSGi release 4. Knoplerfish is more lightweight and has a minimal framework distribution at only 200kB. After looking at the website I have to wonder why I've never run across this before. I could have used this a year and a half ago. My 2 cents. While the overview that the website provides looks great I can't really comment on the details until I get a chance to review the spec or API docs. However, should we go this route I have to make clear what I consider the number one essential requirement: the implementation must come from a stable community. In that regard I certainly wouldn't hesitate to leverage something that is part of Eclipse. If another implementation is preferable for technical reasons it would have to be shown that a) it has a sufficient user and developer community to survive, or b) it can somehow be moved to Apache and be maintained by us (not necessarily preferrable or a solution - Avalon was at Apache). Ralph
