Re: [RT] OSGi based blocks
Bertrand Delacretaz wrote: Le 15 mars 06 à 13:31, Upayavira a écrit : ...So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption?.. Same feelings here - what you describe sounds way cool, but maybe Cocoon would then be just another application built on that framework? We've just been another application built on Avalon framework, right? I don't see a problem with that. :-) Best Regards, Antonio Gallardo.
Re: [RT] OSGi based blocks
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
snip/
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property name=attr value=bar/
scr:reference name=blockServlet
interface=javax.servlet.Servlet
target=(component.name=cocoon.servlet2)/
scr:reference name=skin
interface=myCompany.FancySkinServlet
target=(component.name=fancy-skin)/
/scr:component
The target could be overriden by the configuration service. Do we get
polymorphism this way based on the interface of references?
I think it should work, neat idea :)
Otherwise we have mainly discussed polymorphism at the web service
level. Where a blocks interface would describe what URI:s that the
block responds and what input and output the URI:s would be assumed to
produce. A formal contract could possibly be defined in terms of WSDL,
but the feeling when this was discussed long time ago, was that it was
better to have block contracts at the documentation level.
Following this I have not even thought about implementing any type
checking on the URL level.
So currently we have untyped polymorphism. A block can call any
block in any role as long as they are wired together.
Do you feel a need for stricter checking?
this makes the use of the deployer simpler as auto-wiring works for
all cases that don't want to change the default implementation
forget this statement, it was too late :-/
the advantage would only be type checking. Changing the type can be kept
optional. I will make the deployer doing a type check. If somebody wants to get
type safty in a more specific way than checking that the type is a servlet, he
would have to implement it as outlined above, otherwise no additional work has
to be done.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] OSGi based blocks
Daniel Fagerstrom wrote: Upayavira skrev: My own reflections on this is whether or not this is still Cocoon. It seems to me that you are creating a framework for managing web applications based upon servlets, OSGi and the URLConnections. This doesn't seem all that specific to Cocoon - it seems more general than that, and potentially more generally useful too. I have had similar reflections. From a technical stand point it could be developed in some other community as it doesn't depend on the rest of Cocoon. But as it is based on years of community work from Cocoon, I think it belongs to Cocoon. Also I think we have some agreement that we should make more parts of Cocoon reusable outside Cocoon and then the same will be the case for them as well. Cocoon's contribution would be its SitemapServlet, and other such elements. So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption? We should develop it to a point where it works for Cocoon first ;) I'm very interested in suggestions about how we could cooperate with the Felix community about this. As you suggest it could be interesting for some of them and feedback from the OSGi community would be very valuable. Okay. I'm glad we seem to be on the same page with this. It would seem sensible to continue development here in this community - get it working to a point when we can demonstrate it, then we can show it off to others and see who is interested, and where its future home lies. Maybe elsewhere, or maybe the meaning of 'Cocoon' changes. But for now it makes sense to stay precisely here. Regards, Upayavira
Re: [RT] OSGi based blocks
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
snip/
Inter Block Communication
=
The servlets (sitemaps) in the different blocks need to be able to
call each other. Also it simplifies reuse of blocks if one block can
extend another one (or rather that a servlets in one block can extend
a servlet in another one). This is achieved with the block protocol.
One way of thinking about the inter block communication is to consider
the servlet in the block to be embedded in an own container where the
the servlets of the other blocks are available through the servlet
context. This is the way I have implemented it, so other servlets can
be called through the getNamedDispatcher method of the servlet
context, with the block name as argument.
The implementation of calls to super blocks and polymorphism requires
the use of a call stack, see [8] for details.
Block properties are accessed as servlet config (and context) init
parameters.
In the OSGi implementation there is a BlockServlet that sets up the
the communication with other blocks and creates the context that the
servlet of the own block is executed within. A declaration of a
BlockServlet might look like:
scr:component name=cocoon.blockServlet2
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property name=attr value=bar/
scr:reference name=blockServlet
interface=javax.servlet.Servlet
target=(component.name=cocoon.servlet2)/
scr:reference name=block1
interface=javax.servlet.Servlet
target=(component.name=cocoon.blockServlet1)/
/scr:component
Do I understand correctly that every bundle can have such a component
declaration?
Yes, if you add a field like:
Service-Component: META-INF/components.xml
The DS will read the component declarations and handle the components.
See
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/META-INF/MANIFEST.MF
and
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/META-INF/components.xml
for a working example.
A second question: The bundle provides the interface
javax.servlet.Servlet. One of our goals is polymorphism. What's the plan
to achieve this? My idea was having a declaration like
scr:component name=fancy-skin
scr:implementation class=myCompany.FancySkinServlet/
scr:service
scr:provide interface=myCompany.Skin/
/scr:service
scr:property name=path value=/test3/
/scr:component
package myCompany;
public interface Skin extends javax.servlet.Servlet {
...
}
A block/bundle that requires my skin could have following declaration:
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property name=attr value=bar/
scr:reference name=blockServlet
interface=javax.servlet.Servlet
target=(component.name=cocoon.servlet2)/
scr:reference name=skin
interface=myCompany.FancySkinServlet
target=(component.name=fancy-skin)/
/scr:component
The target could be overriden by the configuration service. Do we get
polymorphism this way based on the interface of references?
I think it should work, neat idea :)
Otherwise we have mainly discussed polymorphism at the web service
level. Where a blocks interface would describe what URI:s that the block
responds and what input and output the URI:s would be assumed to
produce. A formal contract could possibly be defined in terms of WSDL,
but the feeling when this was discussed long time ago, was that it was
better to have block contracts at the documentation level.
Following this I have not even thought about implementing any type
checking on the URL level.
So currently we have untyped polymorphism. A block can call any block
in any role as long as they are wired together.
Do you feel a need for stricter checking?
On the component level, all polymorphism is of course handled within Java.
/Daniel
Re: [RT] OSGi based blocks
Daniel Fagerstrom wrote:
snip/
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property name=attr value=bar/
scr:reference name=blockServlet
interface=javax.servlet.Servlet
target=(component.name=cocoon.servlet2)/
scr:reference name=skin
interface=myCompany.FancySkinServlet
target=(component.name=fancy-skin)/
/scr:component
The target could be overriden by the configuration service. Do we get
polymorphism this way based on the interface of references?
I think it should work, neat idea :)
Otherwise we have mainly discussed polymorphism at the web service
level. Where a blocks interface would describe what URI:s that the block
responds and what input and output the URI:s would be assumed to
produce. A formal contract could possibly be defined in terms of WSDL,
but the feeling when this was discussed long time ago, was that it was
better to have block contracts at the documentation level.
Following this I have not even thought about implementing any type
checking on the URL level.
So currently we have untyped polymorphism. A block can call any block
in any role as long as they are wired together.
Do you feel a need for stricter checking?
this makes the use of the deployer simpler as auto-wiring works for all cases
that don't want to change the default implementation
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] OSGi based blocks
Daniel Fagerstrom wrote: I have worked on implementing the blocks framework in terms of OSGi for some time. Not everything is working yet, but I think it is time to start discussing the involved ideas. snip/ A Servlet Service - A bundle that provides a servlet, can register it as a service with a declaration like [5]: scr:component name=cocoon.servlet3 scr:implementation class=org.apache.cocoon.blocks.osgi.TestServlet/ scr:service scr:provide interface=javax.servlet.Servlet/ /scr:service scr:property name=path value=/test3/ /scr:component compared to the whiteboard adapter we can see some new things, here we provide a service to the framework and it can be refered to by the name cocoon.servlet3 (we should use a better naming scheme, I just adapted some examples from the specification while implementing the above). The declaration also contains a property: path=/test3, that is looked up by the whiteboard adapter and used for mounting the servlet at that URI context. I'm wondering about who's concern it is to define the path where a bundle is mounted. If it's in the bundle, it is totally self-contained, but that may lead to name clashes if two bundles have the same name built in. Isn't the path the responsibility of the hosting environment, i.e. defined by the people that assemble bundles to create an application (just like WARs actually)? snip/ The Block Protocol -- OSGi have an URL service that make it possible to dynamically add protocols that are available through java.net.URL, much like the Excalibur sources. I have reimplemented the block source as an URLConnection that is registered as a protocol and can be used like in [9] (still buggy code). What about the JVM-wide static URLStreamHandlerFactory problem? Did Equinox and/or Felix come up with a solution for this (didn't had time to catch up lately)? snip/ Deployment == I have not thought that much about deployment of OSGi based blocks, and assume Reinhard will have ideas about that. For packaging the OSGi framework together with needed service bundles and an init configuration it is best to see what the Felix and Eclipse/Equinox communities have come up with. Most OSGi implementations provide both telnet and http based consoles for installing, starting and stopping bundles. Deploy time configuration (wiring.xml) seem to have less well developed tool support. There is a configuration service that can be used for deploy time configuration. With the configuration service one can override the properties and target attributes for references that is given in the DS files in the bundles. The wiring.xml could be used for setting up the configuration service. A *very* important point IMO for the acceptance of all this by developers is to be able do deploy a directory. This to have fast roundtrips, without having to go through the compile/package/deploy cycle. WDYT? Looks good! Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [RT] OSGi based blocks
My own reflections on this is whether or not this is still Cocoon. It seems to me that you are creating a framework for managing web applications based upon servlets, OSGi and the URLConnections. This doesn't seem all that specific to Cocoon - it seems more general than that, and potentially more generally useful too. Cocoon's contribution would be its SitemapServlet, and other such elements. So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption? Regards, Upayavira Daniel Fagerstrom wrote: I have worked on implementing the blocks framework in terms of OSGi for some time. Not everything is working yet, but I think it is time to start discussing the involved ideas. As already discussed I have refactored the blocks fw to reuse as much as possible form the servlet APIs. While studying OSGi R4 and especially the new declarative services (DS), I have seen that much of what we want to accomplish with blocks already is solved in OSGi, although sometimes in a different way. I have experimented with implementing the blocks fw in terms of DS, and am quite happy with the results. The new architecture is less monolithic than the previous one and there is not much code at all, most of it is OSGi based design patterns. --- o0o --- So, now over to the actual design. As before we have a number of different parts (not everything implemented yet): * A dispatcher - where the blocks are mounted with their respective prefixes. * Inter block component management - a block can make its components available to other blocks, and use components from other blocks. * Component manager bridges- the components within a block can be setup by our ECM/Spring container or maybe by some other kind of container. * Inter block communication and polymorphism - a sitemap, and more generally a servlet, can call servlets in other blocks. And there is also inheritance so that one sitemap (or servlet) can extend another one. * Dynamic deployment and configuration - the blocks can be installed, updated, reconfigured and removed dynamically while the rest of the framework is executing. In the rest of the RT we will step through these parts and look at the design. But first a little bit about DS, that is used everywhere in the design and replaces block.xml among other things in the current design. Declarative Services The declarative services simplify service (component) handling in OSGi by making it possible to declare services and their dependencies in an XML file (before service management wasn't configuration file based in OSGi). The DS supports setter injection. Compared to Spring it is rather small and primitive. The cool thing about it is that it support dynamic dependencies. A dynamic dependency can have both a setter and an un-setter. The framework also takes care of stopping and starting non-dynamic components when their dependencies comes and goes. The DS can be used together with a configuration service that can override the default configurations in the DS XML file. The configuration service can take part of the responsibility that the wiring file and deployer takes in the current architecture. There is not much documentation for the DS yet, so the main references are the specification [1] and the documentation of the service binder [2] that was a predecessor of DS. The dispatcher == The role of the dispatcher is that the blocks (servlets) are mounted in it based together with their URI prefixes. The dispatcher then call the blocks based on the incoming URIs. This is already handled by the OSGi HTTP service which provides a service that a servlet can lookup and register it self in. A HTTP service implementation normally contains a HTTP server. But an alternative for embedding OSGi managed servlets in a servlet container is to use a HTTP service that acts as a bridge to the embedding servlet container [3]. It is also inconvenient to require the servlets to lookup the HTTP service. It is better to use the whiteboard pattern [4], and just register the servlets as services and have a component that reacts on the appearance and disappearance of servlet services, and register and unregister them in the HTTP service respectively. Using DS a declaration (which is referred to by the Service-Component property in the manifest file) for a whiteboard adapter can look like [5]: scr:component name=cocoon.activator scr:implementation class=org.apache.cocoon.blocks.osgi.Activator/ scr:reference name=LOG interface=org.osgi.service.log.LogService bind=setLog/ scr:reference name=HTTP interface=org.osgi.service.http.HttpService bind=setHttpService/ scr:reference
Re: [RT] OSGi based blocks
Le 15 mars 06 à 13:31, Upayavira a écrit : ...So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption?.. Same feelings here - what you describe sounds way cool, but maybe Cocoon would then be just another application built on that framework? -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] OSGi based blocks
Upayavira wrote:
My own reflections on this is whether or not this is still Cocoon.
It seems to me that you are creating a framework for managing web
applications based upon servlets, OSGi and the URLConnections. This
doesn't seem all that specific to Cocoon - it seems more general than
that, and potentially more generally useful too.
Cocoon's contribution would be its SitemapServlet, and other such elements.
So, my question: Is this still cocoon, or is it becoming something more
general than that (e.g. that could become a Felix sub-project) - thus
gaining a far wider adoption?
That's maybe right but don't let us do the mistake of externalizing things ATM.
We should develop it under our project for now and when we know more about all
the consequences we can still move it to another community or start to build a
new one so that other projects that don't need this Cocoon-thing can reuse it ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] OSGi based blocks
Sylvain Wallez wrote:
A bundle that provides a servlet, can register it as a service with a
declaration like [5]:
scr:component name=cocoon.servlet3
scr:implementation
class=org.apache.cocoon.blocks.osgi.TestServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test3/
/scr:component
compared to the whiteboard adapter we can see some new things, here we
provide a service to the framework and it can be refered to by the
name cocoon.servlet3 (we should use a better naming scheme, I just
adapted some examples from the specification while implementing the
above).
The declaration also contains a property: path=/test3, that is looked
up by the whiteboard adapter and used for mounting the servlet at that
URI context.
I'm wondering about who's concern it is to define the path where a
bundle is mounted. If it's in the bundle, it is totally self-contained,
but that may lead to name clashes if two bundles have the same name
built in. Isn't the path the responsibility of the hosting environment,
i.e. defined by the people that assemble bundles to create an
application (just like WARs actually)?
yes, you're right that this is another concern. IIUC all the values in the
service declaration can be considered as default values and be overriden by some
kind of configuration service. (... but I have to learn more about OSGi though
to verify this statement)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] OSGi based blocks
Le 15 mars 06 à 14:38, Reinhard Poetz a écrit : ...We should develop it under our project for now and when we know more about all the consequences we can still move it to another community or start to build a new one so that other projects that don't need this Cocoon-thing can reuse it ;-).. You're right...frameworks should come out of successful implementations ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] OSGi based blocks
Sylvain Wallez wrote:
A *very* important point IMO for the acceptance of all this by
developers is to be able do deploy a directory. This to have fast
roundtrips, without having to go through the compile/package/deploy cycle.
Felix has recently added the possiblity to add bundles which are unpacked. I
guess that Equinox already supports this. In order to get a redeployment we have
several options:
a) use an OSGi console and enter some commands
b) we can have some kind of watchdog that does the start/stop of bundles
c) maybe we can even plugin the ReloadingClassloader
I think option a) is not what you/we expect. Option b) should already feel like
our ReloadingClassloader. Option c) could be more difficult as we would need
some way to add the ReloadingClassloader into the OSGi classpath hierarchy.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] OSGi based blocks
Daniel Fagerstrom wrote: Conclusion == It should be noted that I haven't referred to any Cocoon specifics above. That is one of the neat things about the architecture. It is completely orthogonal to and independent of the rest of Cocoon and it could be used together with any servlet based web framework. I suppose this is part of the problem and where my concern lies. I have no idea what trunk is anymore and how I'm supposed to build an application with it and from what I can tell there are only a few people who really do. I have been simply waiting for a maven 2 build so that I could run a small script from my desktop and have it download and install the parts I need. While all this stuff is probably really cool I still don't see how it addresses what I'm looking for. I don't want to be negative because I really like the premise of OSGi, but it really isn't one of the problems I needed solved at the moment: a. No requirement for Cocoon users to download source b. Build and deployment tools to allow customers to only download the Cocoon parts they want and their dependencies. c. Build tool to allow customers to add their own customization. Now if you can put what you have done into instructions on how to do the above I'll shut up. Sorry for venting, but it is just that IIRC we all agreed at the getTogether that the priority was to try to get a maven 2 build done by the end of the year for a 2.2M1 release. For quite a while I have felt that only 2 or 3 committers actually have any idea what is going on in trunk and no one else can help because they don't really know what to do. However, I have seen patches that were applied to 2.1 also applied to trunk, but I find myself wondering if they were actually tested there. Please Daniel, don't take this personally as it isn't really directed at you. Part of it is directed at myself as I haven't had any significant amount of time to contribute to this work. I guess I'm just wondering if I'm the only one who is feeling this way? If so, I'll stop my whining. Ralph It is obviously not exactly as the block architecture that was designed a couple of years ago. But it is rather close and by reusing so much of OSGi we get a rather small implementation that can be interesting for other communities. Much of the surrounding infrastuture will be needed by other OSGi users, so much can be developed together with other communities. WDYT? /Daniel
Re: [RT] OSGi based blocks
Ralph Goers wrote: Please Daniel, don't take this personally as it isn't really directed at you. Part of it is directed at myself as I haven't had any significant amount of time to contribute to this work. I guess I'm just wondering if I'm the only one who is feeling this way? If so, I'll stop my whining. I'd like to look at why you don't have time to contribute. I believe it is because this 'Cocoon' that is under development is still in early stages and still quite 'abstract' in the problems it is trying to solve. That's not a bad thing necessarily, but the consequence is that it feels as if there's no space for people to innovate on smaller or more immediate issues because we're all waiting for this 'big thing'. If the OSGi blocks stuff is so orthogonal to Cocoon, why don't we: * break it off into a separate development path, no longer consider it 'trunk', * move 2.1.X into trunk * Start innovating on 2.1.x again * Wrap the OSGi blocks system around this new trunk as and when it is a bit better developed. Personally, the long waiting for this blocks system is having very unfortunate effects on our community. We need to change that. Take the development of blocks off the front stage, and let it happen quietly somewhere until there's something clear for us to see and play with, rather than preventing people from being able to innovate because they can't understand the status of trunk and don't have time/resources to invest in working it out and keeping up. That means that all that are left are those of us that have 'personal spare time'. The rest of us, who do all of our Cocoon work as a part of our livelihoods, can't find time to contribute to Cocoon because we can't justify it - it is just too hard to work out where to contribute. And 'just waiting' is dangerous, as each moment some of our valuable resource wanders away. Upayavira
Re: [RT] OSGi based blocks
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Personally, the long waiting for this blocks system is having very unfortunate effects on our community. We need to change that. Take the development of blocks off the front stage, and let it happen quietly somewhere until there's something clear for us to see and play with, rather than preventing people from being able to innovate because they can't understand the status of trunk and don't have time/resources to invest in working it out and keeping up. That means that all that are left are those of us that have 'personal spare time'. The rest of us, who do all of our Cocoon work as a part of our livelihoods, can't find time to contribute to Cocoon because we can't justify it - it is just too hard to work out where to contribute. And 'just waiting' is dangerous, as each moment some of our valuable resource wanders away. Do that, and nothing other than 2.1 will ever happen. Getting real blocks is a big thing. It looks like a lot of work, everyone has always known that. Now that there is a little bit of momentum in the blocks direction is no time to kill it. -- Peter Hunsberger
Re: [RT] OSGi based blocks
Upayavira wrote: Ralph Goers wrote: Please Daniel, don't take this personally as it isn't really directed at you. Part of it is directed at myself as I haven't had any significant amount of time to contribute to this work. I guess I'm just wondering if I'm the only one who is feeling this way? If so, I'll stop my whining. I'd like to look at why you don't have time to contribute. I believe it is because this 'Cocoon' that is under development is still in early stages and still quite 'abstract' in the problems it is trying to solve. That's not a bad thing necessarily, but the consequence is that it feels as if there's no space for people to innovate on smaller or more immediate issues because we're all waiting for this 'big thing'. If the OSGi blocks stuff is so orthogonal to Cocoon, why don't we: * break it off into a separate development path, no longer consider it 'trunk', * move 2.1.X into trunk * Start innovating on 2.1.x again * Wrap the OSGi blocks system around this new trunk as and when it is a bit better developed. Personally, the long waiting for this blocks system is having very unfortunate effects on our community. We need to change that. Take the development of blocks off the front stage, and let it happen quietly somewhere until there's something clear for us to see and play with, rather than preventing people from being able to innovate because they can't understand the status of trunk and don't have time/resources to invest in working it out and keeping up. That means that all that are left are those of us that have 'personal spare time'. The rest of us, who do all of our Cocoon work as a part of our livelihoods, can't find time to contribute to Cocoon because we can't justify it - it is just too hard to work out where to contribute. And 'just waiting' is dangerous, as each moment some of our valuable resource wanders away. I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] OSGi based blocks
Peter Hunsberger wrote: On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Personally, the long waiting for this blocks system is having very unfortunate effects on our community. We need to change that. Take the development of blocks off the front stage, and let it happen quietly somewhere until there's something clear for us to see and play with, rather than preventing people from being able to innovate because they can't understand the status of trunk and don't have time/resources to invest in working it out and keeping up. That means that all that are left are those of us that have 'personal spare time'. The rest of us, who do all of our Cocoon work as a part of our livelihoods, can't find time to contribute to Cocoon because we can't justify it - it is just too hard to work out where to contribute. And 'just waiting' is dangerous, as each moment some of our valuable resource wanders away. Do that, and nothing other than 2.1 will ever happen. Getting real blocks is a big thing. It looks like a lot of work, everyone has always known that. Now that there is a little bit of momentum in the blocks direction is no time to kill it. I never said 'kill it'. I said 'move it'. I very much value the blocks work, but at the same time I think it is stifling the rest of Cocoon. I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Upayavira
Re: [RT] OSGi based blocks
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit : ...I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on... How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? The current 2.2 would then stay as is, people could work on it until it stabilizes, and when it's time to release it we can always call it 3.0 or whatever to avoid confusion. And that 2.3 release would be a big improvement already, especially using Spring as its container. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] OSGi based blocks
Bertrand Delacretaz wrote: Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit : ...I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on... How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? The current 2.2 would then stay as is, people could work on it until it stabilizes, and when it's time to release it we can always call it 3.0 or whatever to avoid confusion. And that 2.3 release would be a big improvement already, especially using Spring as its container. Exactly the sort of thing I'm talking about. Both streams keep innovating. Regards, Upayavira
Re: [RT] OSGi based blocks
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: Do that, and nothing other than 2.1 will ever happen. Getting real blocks is a big thing. It looks like a lot of work, everyone has always known that. Now that there is a little bit of momentum in the blocks direction is no time to kill it. I never said 'kill it'. I said 'move it'. If you ask me, that the same thing: if it's ever going to happen lots of people have to focus on it and make it happen... I very much value the blocks work, but at the same time I think it is stifling the rest of Cocoon. I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Perhaps, but from what I understand nothing is really stopping you from working on anything else? -- Peter Hunsberger
Re: [RT] OSGi based blocks
Bertrand Delacretaz wrote: How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? The current 2.2 would then stay as is, people could work on it until it stabilizes, and when it's time to release it we can always call it 3.0 or whatever to avoid confusion. And that 2.3 release would be a big improvement already, especially using Spring as its container. Sounds like a good idea; so we finish 2.1.9, freeze the development completly there except for really important bug fixes, use 2.1.9 as the start for 2.3 and port the spring based container over there. That should be fairly easy. In fact we would make the current 2.2 core the new core for 2.3. This should only take a short time and we can then quickly release 2.3M1 - the only drawback I see is the build system which would in that case be of course still Ant. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] OSGi based blocks
* Bertrand Delacretaz: Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit : ...I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on... How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? Good idea. But I guess you are talking about release 2.2, not 2.3 as we never released 2.2 yet? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [RT] OSGi based blocks
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many other changes like the
Spring based container (which I also would like to have *today*).
So perhaps your suggestion, starting anew with 2.1.x as trunk is a good
way to move on...
How about backporting the Spring-based container and the new
configuration features to 2.1.x, and make that Cocoon 2.3, without
touching the current trunk?
The current 2.2 would then stay as is, people could work on it until it
stabilizes, and when it's time to release it we can always call it 3.0
or whatever to avoid confusion.
And that 2.3 release would be a big improvement already, especially
using Spring as its container.
Exactly the sort of thing I'm talking about. Both streams keep innovating.
I have no problem with a backport in general, but why exactly *now* when Daniel
writes a mail that he has solved all problems that required a lot of research
work and Daniel and I only need some more weeks of implementation work?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] OSGi based blocks
Peter Hunsberger wrote: On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: Do that, and nothing other than 2.1 will ever happen. Getting real blocks is a big thing. It looks like a lot of work, everyone has always known that. Now that there is a little bit of momentum in the blocks direction is no time to kill it. I never said 'kill it'. I said 'move it'. If you ask me, that the same thing: if it's ever going to happen lots of people have to focus on it and make it happen... I very much value the blocks work, but at the same time I think it is stifling the rest of Cocoon. I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Perhaps, but from what I understand nothing is really stopping you from working on anything else? 2.1 is a branch - so innovation shouldn't really happen there. Trunk I don't understand, and is too unstable (not a negative, just a fact[1]) for me to find time to understand it. So I don't see quite what I could work on. And I suspect the case is the same for others too. Upayavira [1] Some people have time and resources to give to working with that level of instability. Others need something relatively stable to work on incrementally within their work. I see no problem with either approach, I just want us to bring the latter back into play in our community.
Re: [RT] OSGi based blocks
Le 15 mars 06 à 16:25, Jean-Baptiste Quenot a écrit : * Bertrand Delacretaz: ...How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? Good idea. But I guess you are talking about release 2.2, not 2.3 as we never released 2.2 yet?.. No, I'm talking about 2.3 on purpose - we've been talking about 2.2 for a long time, and what we're talking about now is not the 2.2 that we envisioned in these discussions. People would find rather confusing information about 2.2 in our mail archives for example, if we released the above as 2.2. So naming the above thing 2.3 avoids confusion, the only question will be what happened to 2.2 to which we can reply it was never released but will come up later under another version number. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] OSGi based blocks
My feelings about the blocks and OSGi are vented here already: too few people know that is going on and what to do and although these features are big promises, at the moment they are just that: promises. Is it possible to get the best of both worlds and do something like this: - evolve 2.1.X to include (Carsten's idea) the new configuration features of 2.2 and Spring (and Maven 2 build?). This will be 2.2. - evolve the current 2.2 into 2.3 including the real blocks and the OSGi stuff. IMHO I think that focusing on real blocks should be first priority and every evolution into a cocoon-independent framework should be put on the back burner, otherwise the blocks will never become real. The first implementation can be crude and clumsy, but then it can benefit from all the accumulated knowledge here. From my POV this will close part of the huge gap that is currently between 2.1.X and 2.2 and that is probably the biggest problem now. Bye, Helma
Re: [RT] OSGi based blocks
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: snip/ I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Perhaps, but from what I understand nothing is really stopping you from working on anything else? 2.1 is a branch - so innovation shouldn't really happen there. Trunk I don't understand, and is too unstable (not a negative, just a fact[1]) for me to find time to understand it. So I don't see quite what I could work on. And I suspect the case is the same for others too. Upayavira [1] Some people have time and resources to give to working with that level of instability. Others need something relatively stable to work on incrementally within their work. I see no problem with either approach, I just want us to bring the latter back into play in our community. Sure, I understand. But that's really my point: Cocoon has always taken a bit of learning curve. The fact that trunk is now new, and unusual is a hump for many people, but if Cocoon is every going to really move forward then people should either be willing to wait, or climb the learning curve. Yes, you loose a little bit from the people that don't have the time or energy to climb the curve early in the process. However, IMO you loose even more if there are two main branches of Cocoon to focus on instead. -- Peter Hunsberger
Reviving 2.1 development (was Re: [RT] OSGi based blocks)
Reinhard Poetz wrote: Upayavira wrote: Bertrand Delacretaz wrote: Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit : ...I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on... How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? The current 2.2 would then stay as is, people could work on it until it stabilizes, and when it's time to release it we can always call it 3.0 or whatever to avoid confusion. And that 2.3 release would be a big improvement already, especially using Spring as its container. Exactly the sort of thing I'm talking about. Both streams keep innovating. I have no problem with a backport in general, but why exactly *now* when Daniel writes a mail that he has solved all problems that required a lot of research work and Daniel and I only need some more weeks of implementation work? Consider it nothing more than a build up of frustration. I will only fully believe it when you say now rather than some more weeks. I offer you both/all my greatest encouragement in what you are doing - I really do hope it is a few weeks - I find it very exciting. But at the same time, I want to see something move in the rest of Cocoon too. Regards, Upayavira
Re: [RT] OSGi based blocks
* hepabolu: - evolve 2.1.X to include (Carsten's idea) the new configuration features of 2.2 and Spring (and Maven 2 build?). Maven 2 build would be great, but there is a problem with deployment. AFAICT we will be able to have the Maven build ready once we have a simple way to choose blocks and deploy the application. I don't think it is the case yet. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Revivingg 2.1 development (was Re: [RT] OSGi based blocks)
Peter Hunsberger wrote: On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: snip/ I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Perhaps, but from what I understand nothing is really stopping you from working on anything else? 2.1 is a branch - so innovation shouldn't really happen there. Trunk I don't understand, and is too unstable (not a negative, just a fact[1]) for me to find time to understand it. So I don't see quite what I could work on. And I suspect the case is the same for others too. Upayavira [1] Some people have time and resources to give to working with that level of instability. Others need something relatively stable to work on incrementally within their work. I see no problem with either approach, I just want us to bring the latter back into play in our community. Sure, I understand. But that's really my point: Cocoon has always taken a bit of learning curve. The fact that trunk is now new, and unusual is a hump for many people, but if Cocoon is every going to really move forward then people should either be willing to wait, or climb the learning curve. I'm talking about people who have already climbed that learning curve. People who have jobs and time constraints and can't justify another climb until there is something concrete to offer their bosses. This is an energy resource we are loosing a lot of right now. Yes, you loose a little bit from the people that don't have the time or energy to climb the curve early in the process. However, IMO you loose even more if there are two main branches of Cocoon to focus on instead. Who _really_ is following the blocks thread anyway other than the core developers? I want someone else for the rest of us to follow. Regards, Upayavira P.S. Note new subject to move away from Daniel's original topic, which is itself good stuff.
Re: [RT] OSGi based blocks
Le 15 mars 06 à 16:28, Reinhard Poetz a écrit : ...I have no problem with a backport in general, but why exactly *now* when Daniel writes a mail that he has solved all problems that required a lot of research work and Daniel and I only need some more weeks of implementation work?... Weeks add to weeks - we planned to release 2.2M1 shortly after the GetTogether and it's not out yet, that's a *big* delay. Finding a reasonable way of getting an innovative release out is certainly a Good Thing - people who have enough time, competence and energy to work on the very innovative trunk stuff can continue to do so, and people who have less of these could also work on useful stuff. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] OSGi based blocks
Reinhard Poetz wrote: I have no problem with a backport in general, but why exactly *now* when Daniel writes a mail that he has solved all problems that required a lot of research work and Daniel and I only need some more weeks of implementation work? I guess the mail was just a trigger. Now, I trust and value Daniels and your efforts very very much. Really. And I guess with the real blocks in place it will be a big step forward for Cocoon - no doubt. On the other hand, I would like to have some features we already have in trunk, today. And I think it would be better to do smaller steps: the first one introducing a new core - which solves many of our day to day problems - and then the next step, the blocks stuff. I can only speak for myself: while I don't have enough time to help in the blocks stuff today, I know enough about the Cocoon core to add the features from trunk to 2.1.x again. And I think the current core from trunk should be pretty stable, at least as stable as the current 2.1.x :) So we could do a release with that stuff very quickly imho. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Revivingg 2.1 development (was Re: [RT] OSGi based blocks)
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Who _really_ is following the blocks thread anyway other than the core developers? I want someone else for the rest of us to follow. So, what else do you want that you can't do in 2.1 and are unwilling to do in 2.2? -- Peter Hunsberger
Re: [RT] OSGi based blocks
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
I have worked on implementing the blocks framework in terms of OSGi
for some time. Not everything is working yet, but I think it is time
to start discussing the involved ideas.
snip/
A Servlet Service
-
A bundle that provides a servlet, can register it as a service with a
declaration like [5]:
scr:component name=cocoon.servlet3
scr:implementation
class=org.apache.cocoon.blocks.osgi.TestServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test3/
/scr:component
compared to the whiteboard adapter we can see some new things, here we
provide a service to the framework and it can be refered to by the
name cocoon.servlet3 (we should use a better naming scheme, I just
adapted some examples from the specification while implementing the
above).
The declaration also contains a property: path=/test3, that is looked
up by the whiteboard adapter and used for mounting the servlet at that
URI context.
I'm wondering about who's concern it is to define the path where a
bundle is mounted. If it's in the bundle, it is totally self-contained,
but that may lead to name clashes if two bundles have the same name
built in. Isn't the path the responsibility of the hosting environment,
i.e. defined by the people that assemble bundles to create an
application (just like WARs actually)?
I completely agree that it is the deployer that should be responsible
for the choice of mount point. The value of properties (and reference
targets) in the DS configurations should just be considered default
values (and a convenience in the way that you can test a block without
configuring it further).
The deploy time configuration can be performed with a OSGi configuration
service (CS). In the CS you can register (persistently) a dictionary
with a service PID (persistent identity).
So for the example above you could register a dictionary {path:
/mytest} with the PID cocoon.sevlet3. Then when the DS creates the
service component, the values from the dictionary in the CS will
override the values from the DS configuration.
For factories, there are factory configurations. In the CS one can
register a set of PID - dictionary associations with a *factory* PID.
Then one product service will be created for each PID - directionary
association, when the factory is registred.
AFAICS the CS should be able to take care of most of the information in
wiring.xml. The question is how to use it, one idea would be to let the
deployer fill the CS with the content from a wiring.xml.
Another idea would be to use the meta service, that in R4 contains a
small schema language for describing a property schema. The Knopflerfish
implementation instead use a small subset of XML schema.
I haven't done any implementation experiments on this part. I'd like to
hear Reinhard's opinion about how to integrate it with the deployer first.
snip/
The Block Protocol
--
OSGi have an URL service that make it possible to dynamically add
protocols that are available through java.net.URL, much like the
Excalibur sources. I have reimplemented the block source as an
URLConnection that is registered as a protocol and can be used like in
[9] (still buggy code).
What about the JVM-wide static URLStreamHandlerFactory problem? Did
Equinox and/or Felix come up with a solution for this (didn't had time
to catch up lately)?
Equinox is supposed to have a solution for it and Richard S. Hall says
that it could be implemented in Felix if there is enough need for it
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114087539715696w=2.
snip/
Deployment
==
I have not thought that much about deployment of OSGi based blocks,
and assume Reinhard will have ideas about that.
For packaging the OSGi framework together with needed service bundles
and an init configuration it is best to see what the Felix and
Eclipse/Equinox communities have come up with.
Most OSGi implementations provide both telnet and http based consoles
for installing, starting and stopping bundles. Deploy time
configuration (wiring.xml) seem to have less well developed tool support.
There is a configuration service that can be used for deploy time
configuration. With the configuration service one can override the
properties and target attributes for references that is given in the
DS files in the bundles.
The wiring.xml could be used for setting up the configuration service.
A *very* important point IMO for the acceptance of all this by
developers is to be able do deploy a directory. This to have fast
roundtrips, without having to go through the compile/package/deploy cycle.
Equinox supports all four combinations of packed/exploded and
installed/referenced bundles (bundles are normally installed by
copying their content into an internal DB like structure, a referenced
bundle is used as is from without copying).
Re: [RT] OSGi based blocks
Upayavira skrev: My own reflections on this is whether or not this is still Cocoon. It seems to me that you are creating a framework for managing web applications based upon servlets, OSGi and the URLConnections. This doesn't seem all that specific to Cocoon - it seems more general than that, and potentially more generally useful too. I have had similar reflections. From a technical stand point it could be developed in some other community as it doesn't depend on the rest of Cocoon. But as it is based on years of community work from Cocoon, I think it belongs to Cocoon. Also I think we have some agreement that we should make more parts of Cocoon reusable outside Cocoon and then the same will be the case for them as well. Cocoon's contribution would be its SitemapServlet, and other such elements. So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption? We should develop it to a point where it works for Cocoon first ;) I'm very interested in suggestions about how we could cooperate with the Felix community about this. As you suggest it could be interesting for some of them and feedback from the OSGi community would be very valuable. /Daniel
Re: [RT] OSGi based blocks
Daniel Fagerstrom wrote:
snip/
Inter Block Communication
=
The servlets (sitemaps) in the different blocks need to be able to call
each other. Also it simplifies reuse of blocks if one block can extend
another one (or rather that a servlets in one block can extend a servlet
in another one). This is achieved with the block protocol.
One way of thinking about the inter block communication is to consider
the servlet in the block to be embedded in an own container where the
the servlets of the other blocks are available through the servlet
context. This is the way I have implemented it, so other servlets can be
called through the getNamedDispatcher method of the servlet context,
with the block name as argument.
The implementation of calls to super blocks and polymorphism requires
the use of a call stack, see [8] for details.
Block properties are accessed as servlet config (and context) init
parameters.
In the OSGi implementation there is a BlockServlet that sets up the the
communication with other blocks and creates the context that the servlet
of the own block is executed within. A declaration of a BlockServlet
might look like:
scr:component name=cocoon.blockServlet2
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property name=attr value=bar/
scr:reference name=blockServlet
interface=javax.servlet.Servlet
target=(component.name=cocoon.servlet2)/
scr:reference name=block1
interface=javax.servlet.Servlet
target=(component.name=cocoon.blockServlet1)/
/scr:component
Do I understand correctly that every bundle can have such a component
declaration?
A second question: The bundle provides the interface javax.servlet.Servlet. One
of our goals is polymorphism. What's the plan to achieve this? My idea was
having a declaration like
scr:component name=fancy-skin
scr:implementation class=myCompany.FancySkinServlet/
scr:service
scr:provide interface=myCompany.Skin/
/scr:service
scr:property name=path value=/test3/
/scr:component
package myCompany;
public interface Skin extends javax.servlet.Servlet {
...
}
A block/bundle that requires my skin could have following declaration:
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property name=attr value=bar/
scr:reference name=blockServlet
interface=javax.servlet.Servlet
target=(component.name=cocoon.servlet2)/
scr:reference name=skin
interface=myCompany.FancySkinServlet
target=(component.name=fancy-skin)/
/scr:component
The target could be overriden by the configuration service. Do we get
polymorphism this way based on the interface of references?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
