Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <47F528CF.4040101@tuffmail.com>
Date: Thu, 03 Apr 2008 20:58:23 +0200
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: JNet integration doubts
References: <47E509B2.7050003@tuffmail.com> <47F52534.5090101@apache.org>
In-Reply-To: <47F52534.5090101@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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 current 
implementation.

Another possibility (suggested by you) is to provide real implementation of blockcontext: protocol 
and use blockcontext protocol in base URLs for blocks. I cannot comment on this solution because I 
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 approach. 
I really would like to fix SSF ASAP and let the discussion/research on URL go in parallel.

-- 
Grzegorz Kossakowski