cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] applying SoC on cocoon itself
Date Mon, 18 Oct 2004 17:20:03 GMT
Pier made me realize that there are 3 different issues on the table 
regarding real blocks:

  1) classloading isolation
  2) pojoification
  3) service isolation

and, interestingly enough, they are orthogonal.

Tani was born to prototype 1.
Butterfly was born to prototype 2.

But what I really care is 3!!! and Pier made me realize that you don't 
need to have neither 1 nor 2 to achieve 3!!!

The key is *very* subdle and, in fact, was hard for me to realize before.

Let me show you with an example:

  <map:transformer name="blah" class="org.apache.blah.Blah"/>


  <map:transform type="blah" src="blah.src"/>

This design is 5 years old and does *THIS* really mean? it means that 
the sitemap will lookup a "component" identified by a "class" cast it to 
the functional group (in this case, a transformer), reference it with 
its local name and used with further parameters (the src="").

Now, look at this

  <map:transform name="blah/*" uri=""/>
    <map:param name="src" value="{1}.src"/>


  <map:transform type="blah/{1}">

what does *this* mean?

  1) the sitemap requires a service
  2) the service is located
  3) the service is used

Note that:

  1) no concept of class or interface or role is used.
  2) the two syntaxes are "functionally equivalent", but *ONLY* at a 
local level

                                   - o -

In short: what I wanted to achieve with real blocks was service isolation.

   Block A requires Service 1 that is described by Block Interface Z and 
exposed by Block B.

Virtual Pipeline components were the first examples of "non java" 
services. (well, ultimately everything ends up being a java class, but 
from a semantic point of view doesn't have to be).

Do we need classloader isolation for the above? NO!!!

So here is my proposal for Cocoon 2.2

  1) fully incremental transition (that's why I welcome Carsten's ECM++ 

  2) addition of the uri="" attribute to the sitemap component 
descriptors to indicate the "new URI-based lookup behavior", if the 
class="" attribute is used, then it's completely back compatible

  3) implementation of a single-classloader service lookup manager built 
in the sitemap, using the above syntax (the uri="" attribute in the 
component section will trigger the deprecation of the src="" attribute 
in the pipeline section")

  4) implementation of service-based real blocks

The advantages are:

  - fully reversible approach (no back incompatibility, no need to 
rewriting existing code)
  - implementation of polymorphic application level functional units 
(real blocks) as collection of services.
  - started the de-avalonization of the sitemap semantics
  - initiated a smooth migration path toward a service-based 
interpretation of the pipelines that would ease the introduction of 
virtual components

So, what do we lose by not having classloading independence?

  1) hot rewriting (the ability to change an existing service 
implementation at runtime)
  2) class versioning (the ability to have two versions of the same 
exact class running in the same workspace)

I have been blinded by the elegance of 2) for so long that I thought 
that it was somehow a requirement, but the need in real life is yet to 
be demonstrated.

So, as I have indicated, I indent to start working on this transition 
*WITHOUT* interfering with the intra-block or inter-block component 
lookup mechanism, since they are orthogonal.



View raw message