cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [RT] OSGi based blocks
Date Fri, 17 Mar 2006 09:45:50 GMT
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
> 
> <snip/>
> 
>>>    <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?
> 
> 
> this makes the use of the deployer simpler as "auto-wiring" works for 
> all cases that don't want to change the default implementation
> 

forget this statement, it was too late :-/

the advantage would only be type checking. Changing the type can be kept 
optional. I will make the deployer doing a type check. If somebody wants to get 
type safty in a more specific way than checking that the type is a servlet, he 
would have to implement it as outlined above, otherwise no additional work has 
to be done.

-- 
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

Mime
View raw message