You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2006/03/14 23:09:24 UTC
[RT] OSGi based blocks
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 URI
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 name="Servlet"
interface="javax.servlet.Servlet"
cardinality="0..n"
policy="dynamic"
bind="setServlet"
unbind="unsetServlet"/>
</scr:component>
which activates the class o.a.c.blocks.osgi.Activator [6] by calling its
"void activate(ComponentContext)" method if there is one. We can also
see that the declaration refers to other services. It will not be
activated until all its references are fulfilled. In this case it
require a log service and an HTTP service to be present, and will insert
these into the Activator instance by using its setLog and setHttpService
methods.
The servlet reference is more interesting, it is dynamic an it has
cardinality 0..n. This means that the activator can be connected to many
servlets and that they can come and go dynamically. Each time a servlet
service appears the setServlet method is called with it and each time
one disappear the unsetServlet method is called.
The name attribute for the references are used for allowing service
manager style lookup using the name, within the component. The service
manager can be get through the ComponentContext.
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.
--- o0o ---
This far we can see that by using what OSGi implementations already
contain and some minimal glue code [6], we get the possiblity to
dynamically register (and unregister) servlets within a webapp.
In the next step we will see how these servlets can share (dynamic)
components.
Component Management
====================
Actually we already have inter block component management from OSGi. A
bundle (block) can provide components by declaring them as services and
it can depend on other components, possibly from other bundles by
declaring them as references.
More specifically, for a servlet to depend on some components, we can
add a number of set (and unset if we want dynamism) methods to it, and
add the corresponding references in its declaration.
So, by just using OSGi, we get much of what the block architecture is
intended for: dynamic component handling, packaging of servlets
(sitemaps), sharing of components between blocks.
Component Manager Bridges
=========================
While DS is neat, it is not as flexible and powerful as Spring and we
still have our legacy of Avalon components to take care of.
To create a bridge between OSGi services and Spring or Avalon component
management we need two kind of adapters:
* An OSGi service to ServiceManager (or BeanFactory) adapter. This
adapter just implement ServiceManager (or BeanFactory) and lookup the
components OSGi services. It could be registered as an OSGi service it
self and refered to by other components that needs a ServiceManager. We
can even get dynamism by creating the adapter with DS and explicitly
list the services that it should be able to provide, as references.
* A Spring component manager to OSGi services adapter. This adapter
register all the components that is created by the Spring container as
services. By letting the Spring container have a OSGi service to
BeanFactory adapter as parent component manager, the Spring component
manager can use components from other blocks as well, while creating new
components.
We have already implemented this kind of bridge for ECM++ [7]. Now we
need to implement it for the new Spring based container.
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>
Here we can see that we provide a service with the identifier
"cocoon.blockServlet2" that is implemented by the mentioned BlockServlet
and implements Servlet, it is mounted on the path "/test2". So the
"whiteboard" part of the dispatcher described above, will take care of
installing this block servlet in the HttpService of the framework.
The servlet reference with the special name "blockServlet" (should find
a less confusing name) refer to the servlet that is embedded by the
BlockServlet. The embeded servlet could e.g. be a sitemap servlet, and
it could get the components it needs through the mechanism described in
the sections about component management above.
The "target" attribute in a reference can contain constraints on what
service that is refered to. The constraint
"(component.name=cocoon.servlet2)" means that we want the particular
servlet that is registered under the name "cocoon.servlet2". The
constraint lanuage is the same as is used in LDAP, and it is possible to
create rather complex constraints if needed.
We can also see that there is a reference to a block servlet with the
identifier "cocoon.blockServlet1", it will be made available through the
servlet context for "cocoon.servlet2" with the getNamedDispatcher
method using the name "block1".
All the properties (path and attr) are made available as init parameters
in the servlet context for "cocoon.servlet2".
As we can see, the above DS configuration of a block servlet take care
of most of what is configured in block.xml in the current block
architecture.
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).
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.
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.
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
References
==========
[1] OSGI R4 specification
http://www.osgi.org/osgi_technology/download_specs.asp?section=2
[2] Service binder http://gravity.sourceforge.net/servicebinder/
[3] Servlet container embedding
http://www.eclipse.org/equinox/incubator/server/embedding_in_a_servlet_container.php
[4] Whiteboard pattern
http://www.osgi.org/documents/osgi_technology/whiteboard.pdf
[5]
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/META-INF/components.xml
[6]
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/src/main/java/org/apache/cocoon/blocks/osgi/Activator.java
[7] The bridge was part of cocoon-core in package o.a.c.core.osgi,
Reinhard moved it to the whiteboard, but the code seem to have
disappeared on its way.
[8] Obsolete description of the sitemap blocks that contain an
explanation of how polymorphism is implemented
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2
[9]
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/src/main/java/org/apache/cocoon/blocks/osgi/TestServlet2.java
Re: [RT] OSGi based blocks
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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-dev&m=114087539715696&w=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).
Felix supports the same as Richard reports in the above mail (or
actually the three combinations that make sense, IIRC).
/Daniel
Re: [RT] OSGi based blocks
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [RT] OSGi based blocks
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Antonio Gallardo <ag...@agssa.net>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [RT] OSGi based blocks
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Upayavira <uv...@odoko.co.uk>.
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 name="Servlet"
> interface="javax.servlet.Servlet"
> cardinality="0..n"
> policy="dynamic"
> bind="setServlet"
> unbind="unsetServlet"/>
> </scr:component>
>
> which activates the class o.a.c.blocks.osgi.Activator [6] by calling its
> "void activate(ComponentContext)" method if there is one. We can also
> see that the declaration refers to other services. It will not be
> activated until all its references are fulfilled. In this case it
> require a log service and an HTTP service to be present, and will insert
> these into the Activator instance by using its setLog and setHttpService
> methods.
>
> The servlet reference is more interesting, it is dynamic an it has
> cardinality 0..n. This means that the activator can be connected to many
> servlets and that they can come and go dynamically. Each time a servlet
> service appears the setServlet method is called with it and each time
> one disappear the unsetServlet method is called.
>
> The name attribute for the references are used for allowing service
> manager style lookup using the name, within the component. The service
> manager can be get through the ComponentContext.
>
> 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.
>
> --- o0o ---
>
> This far we can see that by using what OSGi implementations already
> contain and some minimal glue code [6], we get the possiblity to
> dynamically register (and unregister) servlets within a webapp.
>
> In the next step we will see how these servlets can share (dynamic)
> components.
>
> Component Management
> ====================
>
> Actually we already have inter block component management from OSGi. A
> bundle (block) can provide components by declaring them as services and
> it can depend on other components, possibly from other bundles by
> declaring them as references.
>
> More specifically, for a servlet to depend on some components, we can
> add a number of set (and unset if we want dynamism) methods to it, and
> add the corresponding references in its declaration.
>
> So, by just using OSGi, we get much of what the block architecture is
> intended for: dynamic component handling, packaging of servlets
> (sitemaps), sharing of components between blocks.
>
> Component Manager Bridges
> =========================
>
> While DS is neat, it is not as flexible and powerful as Spring and we
> still have our legacy of Avalon components to take care of.
>
> To create a bridge between OSGi services and Spring or Avalon component
> management we need two kind of adapters:
>
> * An OSGi service to ServiceManager (or BeanFactory) adapter. This
> adapter just implement ServiceManager (or BeanFactory) and lookup the
> components OSGi services. It could be registered as an OSGi service it
> self and refered to by other components that needs a ServiceManager. We
> can even get dynamism by creating the adapter with DS and explicitly
> list the services that it should be able to provide, as references.
>
> * A Spring component manager to OSGi services adapter. This adapter
> register all the components that is created by the Spring container as
> services. By letting the Spring container have a OSGi service to
> BeanFactory adapter as parent component manager, the Spring component
> manager can use components from other blocks as well, while creating new
> components.
>
> We have already implemented this kind of bridge for ECM++ [7]. Now we
> need to implement it for the new Spring based container.
>
> 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>
>
> Here we can see that we provide a service with the identifier
> "cocoon.blockServlet2" that is implemented by the mentioned BlockServlet
> and implements Servlet, it is mounted on the path "/test2". So the
> "whiteboard" part of the dispatcher described above, will take care of
> installing this block servlet in the HttpService of the framework.
>
> The servlet reference with the special name "blockServlet" (should find
> a less confusing name) refer to the servlet that is embedded by the
> BlockServlet. The embeded servlet could e.g. be a sitemap servlet, and
> it could get the components it needs through the mechanism described in
> the sections about component management above.
>
> The "target" attribute in a reference can contain constraints on what
> service that is refered to. The constraint
> "(component.name=cocoon.servlet2)" means that we want the particular
> servlet that is registered under the name "cocoon.servlet2". The
> constraint lanuage is the same as is used in LDAP, and it is possible to
> create rather complex constraints if needed.
>
> We can also see that there is a reference to a block servlet with the
> identifier "cocoon.blockServlet1", it will be made available through the
> servlet context for "cocoon.servlet2" with the getNamedDispatcher
> method using the name "block1".
>
> All the properties (path and attr) are made available as init parameters
> in the servlet context for "cocoon.servlet2".
>
> As we can see, the above DS configuration of a block servlet take care
> of most of what is configured in block.xml in the current block
> architecture.
>
> 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).
>
> 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.
>
> 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.
>
> 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
>
>
> References
> ==========
>
> [1] OSGI R4 specification
> http://www.osgi.org/osgi_technology/download_specs.asp?section=2
> [2] Service binder http://gravity.sourceforge.net/servicebinder/
> [3] Servlet container embedding
> http://www.eclipse.org/equinox/incubator/server/embedding_in_a_servlet_container.php
>
> [4] Whiteboard pattern
> http://www.osgi.org/documents/osgi_technology/whiteboard.pdf
> [5]
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/META-INF/components.xml
>
> [6]
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/src/main/java/org/apache/cocoon/blocks/osgi/Activator.java
>
> [7] The bridge was part of cocoon-core in package o.a.c.core.osgi,
> Reinhard moved it to the whiteboard, but the code seem to have
> disappeared on its way.
> [8] Obsolete description of the sitemap blocks that contain an
> explanation of how polymorphism is implemented
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2
> [9]
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-osgi-impl/src/main/java/org/apache/cocoon/blocks/osgi/TestServlet2.java
>
>
Re: [RT] OSGi based blocks
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Re: [RT] OSGi based blocks
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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/
Re: [RT] OSGi based blocks
Posted by hepabolu <he...@gmail.com>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Reviving 2.1 development (was Re: [RT] OSGi based blocks)
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] OSGi based blocks
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] OSGi based blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [RT] OSGi based blocks
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [RT] OSGi based blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Revivingg 2.1 development (was Re: [RT] OSGi based blocks)
Posted by Peter Hunsberger <pe...@gmail.com>.
On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Revivingg 2.1 development (was Re: [RT] OSGi based blocks)
Posted by Upayavira <uv...@odoko.co.uk>.
Peter Hunsberger wrote:
> On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Posted by Peter Hunsberger <pe...@gmail.com>.
On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Re: [RT] OSGi based blocks
Posted by Upayavira <uv...@odoko.co.uk>.
Peter Hunsberger wrote:
> On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Posted by Peter Hunsberger <pe...@gmail.com>.
On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Posted by Upayavira <uv...@odoko.co.uk>.
Peter Hunsberger wrote:
> On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Posted by Peter Hunsberger <pe...@gmail.com>.
On 3/15/06, Upayavira <uv...@odoko.co.uk> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
>
>
>