cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] Do we need URL/Source in SSF?
Date Mon, 31 Mar 2008 11:03:52 GMT
Grzegorz Kossakowski wrote:
> My conclusion is that SSF exploits semantics of Source/SourceFactory 
> interfaces for resolving *expressions*. My view on 
> "blockcontext:/myBlock/path" is that we deal with an expression that 
> should be resolved to real URL with real protocol implementation available.
> Having said all of this I would like to propose treating strings in 
> contextPath attribute as expressions and using 
> cocoon-expression-language-api module for resolving them. Then 
> cocoon-servlet-service-components could provide implementation of 
> blockcontext expression language that would use blockContext Map for 
> resolving expressions to real base URLs.
> This way we can get rid of dependency on CocoonSourceResolver and 
> Excalibur in one go. Moreover, it means that SSF won't mess with 
> URL/Source handling anymore which was my intention right from the 
> beginning. I think such functionality is far from SSF scope and should 
> be implemented elsewhere, probably as a Spring AOP's /around advice/ so 
> you could get more fine-grained control in which servlets you want to 
> have extended URL support.

Wouldn't this rule out the usage of the blockcontext: protocol outside of Cocoon 
Core (2.2) and everybody using the SSF would have to come up with his own solution?

                                     - o -

Let's take one step back so that we others (better) understand the problem that 
you want to solve.

When a block, which is a Java library (.jar), is being extracted, the 
information that the block exists is stored in a singleton. Then we can use the 
blockcontext: protocol to set the servlet's context path:

   <bean name="org.apache.cocoon.servletservice.demo1.servlet"
     <servlet:context mount-path="/test1"

When the servlet is being initialized, the blockcontext: URL is resolved using 
using the SourceResolver that returns the source object that points to the base 
directory of the extracted block.

Provided that we use JNet, I wonder why can't we set the blockcontext: URL as 
servlet context? Thanks to JNet, the URL should be resolveable then and there is 
no need for a SourceResolver.

What do I miss?

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message