cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: JNet integration doubts
Date Thu, 03 Apr 2008 18:58:23 GMT
Reinhard Poetz pisze:
> Grzegorz Kossakowski wrote:
>> Hello,
>> I've played with JNet for a while trying to integrate it with SSF and run
>> into many troubles.
>> First of all, I'm not sure if I understand whole concept correctly. Do I
>> understand correctly that JNet provides SourceURLStreamHandlerFactory 
>> class
>> that acts just like a bridge supporting legacy Source implementations? 
>> Should
>> we consider URLStreamHandlerFactory and URLStreamHandler as general 
>> replacements for SourceFactory and Source interfaces?
>> If a long-term goal is to drop Source and SourceFactory interfaces 
>> what about
>> extension like ModifiableSource, MoveableSource, PostableSource? How 
>> can they
>> be supported by URLConnection and friends?
>> --- o0o ---
>> Another problem is with the implementation. There is a problem with
>> installing SourceURLStreamHandlerFactory because: a) it must be installed
>> before ServletFactoryBean is being used at Spring initialization phase 
>> b) it
>> must be installed after ApplicationContext is created because 
>> SourceFactories
>> are components that must be initialized by Spring container.
>> I have no clue how to solve this problem. Any ideas?
> Why do we have to replace the blockcontext: protocol at all?

Take a look at its current source code. There is no such a thing like "blockcontext:" protocol

implementation at the moment.

In my [RT] mail I explained how we could possibly to stop cheating pretending there is a 
blockcontext protocol and replace it with blockcontext expression that would better reflect

Another possibility (suggested by you) is to provide real implementation of blockcontext:
and use blockcontext protocol in base URLs for blocks. I cannot comment on this solution because
haven't enough free time to check all implications. Remember: you will put blockcontext into

ServletContext that is rather general interface. I don't say there is any problem, I'm only
saying I 
haven't checked if there is none.

I prefer (only for now, as a quick solution) first way because there is not much room for

discussion, brainstorming and general research which is quite opposite to URL-em-them-all
I really would like to fix SSF ASAP and let the discussion/research on URL go in parallel.

Grzegorz Kossakowski

View raw message