cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject [RT] Do we need URL/Source in SSF?
Date Fri, 28 Mar 2008 21:48:07 GMT
Hi guys,

The discussion initiated by rather *technical* question about JNet integration with SSF turned
into 
heated discussion on whether standard URL API is capable enough to replace Excalibur's 
Source/SourceFactory interfaces. Actually, it was Rainer Pruy who gave a nice summary[1] of

discussed aspects up to now.


Even though, it's real fun to see interesting solutions like one proposed by Sylvain[2] I'm
still 
rather interested in that particular COCOON-2176[3] problem at the moment as it blocks any
out of 
Cocoon world SSF usage.


                                              --- o0o ---


Right from the beginning of my playings with JNet and URL replacement for SourceResolver I
had 
constant feeling that something is stinky about the approach I taken. That's been reflected
in bunch 
of dirty hacks in first, prototype implementation of JNet integration.


I've taken a closer look at our current Source interface usage pattern. Obviously, started
with 
blockcontext source that I'm mostly interested in at the moment and seen something like this
in 
BlockContextSourceFactory:

             String blockContext = (String) blockContexts.get(blockName);
[...]

             // construct the path relative the block context
             String resolvedPath = blockContext + path;

[...]

             resolver = (SourceResolver) this.serviceManager.lookup(SourceResolver.ROLE);
             return resolver.resolveURI(resolvedPath);


Some comments explaining what's happening here. If you try to resolve blockcontext:/myBlock/path
it 
will obtain blockContext from Map of contexts. This map contains base URLs for corresponding
blocks. 
Current implementation allows file: and jar: protocols.

As you see, BlockContextSourceFactory returns Source implementations of protocols that have

_nothing_ to do with BlockContextSource. Let's have a look at how resolved source is used
(in 
ServletFactoryBean):


           source = resolver.resolveURI(contextPath);
           contextPath = source.getURI();

Where contextPath contains "blockcontext:/myBlock/path" at the beginning of processing. It's
clear 
now, that ServletFactoryBean is interested only in String representation of base URL (Source)
and 
nothing else.


Don't you think that is little bit weird that following instructions:

       contextPath = "blockcontext:/myBlock/path";
       source = resolver.resolveURI(contextPath);
       contextPath = source.getURI();

Will result with "file://.../myBlock/path" stored in contextPath instead of original 
"blockcontext:/myBlock/path"?
I think that contract of URL/SourceFactory should be to to act as identity transform when
above code 
is being executed. I mean, returned URL/Source instance should always be implementing the
protocol 
we asked for.

Do you agree?


                                              --- o0o ---


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.


WDYT?

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/77432
[2] http://article.gmane.org/gmane.text.xml.cocoon.devel/77352
[3] https://issues.apache.org/jira/browse/COCOON-2176

-- 
Grzegorz Kossakowski

Mime
View raw message