Return-Path: 
 <dev-return-85451-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 54762 invoked from network); 15 Mar 2006 23:42:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 15 Mar 2006 23:42:29 -0000
Received: (qmail 16699 invoked by uid 500); 15 Mar 2006 23:42:21 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 16631 invoked by uid 500); 15 Mar 2006 23:42:21 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 16612 invoked by uid 99); 15 Mar 2006 23:42:21 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Mar 2006 15:42:21 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Received: from [217.12.11.95] (HELO smtp006.mail.ukl.yahoo.com) (217.12.11.95)
    by apache.org (qpsmtpd/0.29) with SMTP; Wed, 15 Mar 2006 15:42:19 -0800
Received: (qmail 69519 invoked from network); 15 Mar 2006 23:41:57 -0000
Received: from unknown (HELO ?192.168.1.30?) (reinhard?poetz@62.178.239.20
 with plain)
  by smtp006.mail.ukl.yahoo.com with SMTP; 15 Mar 2006 23:41:57 -0000
Message-ID: <4418A640.3050205@apache.org>
Date: Thu, 16 Mar 2006 00:41:52 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] OSGi based blocks
References: <44173F14.4030701@nada.kth.se>
In-Reply-To: <44173F14.4030701@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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