Grzegorz Kossakowski wrote:
<snip/>
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"
class="org.apache.cocoon.servletservice.demo1.DemoServlet">
<servlet:context mount-path="/test1"
context-path="blockcontext:/cocoon-servlet-service-sample/">
</servlet:context>
</bean>
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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
