You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2008/04/03 20:43:00 UTC
Re: JNet integration doubts
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?
--
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 reinhard@apache.org
_________________________________________________________________________
Re: JNet integration doubts
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Apr 3, 2008, at 2:58 PM, Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> 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
A:
> replace it with blockcontext expression that would better reflect
> current implementation.
B:
> 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.
I've read your RT and I agree with conclusion that approach taken
there - to convert String (blockcontext:) --> SourceResolver -->
Source --> and back into String (file:) - it definitely smells bad.
But, I don't think plugging dependency to expressions block (A above)
is the good idea. I'd rather prefer B: make blockcontext a regular
protocol, and treat context path parameter as regular source without
any special treatment. I'd expect any of supported source
implementations to work there, be it http, webdav, or xmldb, or even
blockcontext.
Vadim
Re: JNet integration doubts
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
>> 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.
Therefore I'm asking ...
> 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.
making the blockcontext protocol an expression is just another big hack IMO.
>
> 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.
Steven and I made the servlet protocol based on JNet work for Corona yesterday
(not committed yet). Then we had a quick look into the resolution of the
blockcontext protocol and we don't see any problem why it should not work.
> 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.
Making blockcontext: a real protocol seems to be the simplest and by far the
most elegant and most obvious solution. I will give this a try either today or
at the Hackathon and find out if it is really as simple as expected.
--
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 reinhard@apache.org
_________________________________________________________________________
Re: JNet integration doubts
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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