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="http://apache.org/blah/Blah"/> <map:param name="src" value="{1}.src"/> </map:transform>
...
<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++ solution)
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.
Comments?
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
