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
