cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] OSGi based blocks
Date Thu, 16 Mar 2006 18:52:15 GMT
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

Mime
View raw message