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 Pötz <re...@apache.org> on 2008/07/30 13:29:03 UTC
Webdav and link-rewrite
I had a brief look at the link-rewrite block and think now that the
migration of the LinkrewriterTransformer will be difficult because of
its configuration can't be easily converted to Spring.
Since the main use case for the LinkrewritingTransformer is rewriting
servlet: links, I think that the best compromise is that Lukas
implements a specialized ServletLinkRewritingTransformer that could be
put into the servlet-service-fw-components block. This will satisfy our
main goal of getting rid of the linkrewrite dependency in the
servlet-service-fw-components block.
In the case that one needs the more advanced use cases, the already
existing transformer can be used by adding the link-rewrite block.
Or are there any better suggestions?
- o -
Apart from the link-rewrite block he will also migrate the webdav block.
Any thoughts or recommendations on this? The plan is that all Avalon
components are migrated to Spring and that Jackrabbit is used as webdav
server.
I remember Jasha and Jereon have started to work on this in Rome last
year. Any comments from you?
--
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 reinhard@apache.org
________________________________________________________________________
RE: Webdav and link-rewrite
Posted by Ard Schrijvers <a....@onehippo.com>.
>
> > Apart from the link-rewrite block he will also migrate the
> > webdav block.
> > Any thoughts or recommendations on this? The plan is that all
> > Avalon components are migrated to Spring and that Jackrabbit
> > is used as webdav server.
> >
> > I remember Jasha and Jereon have started to work on this in
> > Rome last year. Any comments from you?
>
> Jeroen has looked further at the WebDAV block after the Rome
> GT. The problem was the imcompatibility between HttpClient 2
> (used in Slide) and HttpClient 3 (used in the WebDAV block).
> Jeroen still has an open Jira issue for this [1], but he's
> enjoying a well deserved holiday now.
>
> Ard, do you know how far the WebDAV implementation in Jackrabbit is?
Jackrabbit does not supply a webdav client, only a server without the
DASL possibility AFAIK
-Ard
>
> [1] https://issues.apache.org/jira/browse/COCOON-2153
>
> Jasha Joachimsthal
>
> www.onehippo.com
> Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam
> +31(0)20-5224466
> San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma
> CA 94952-3329 +1 (707) 773-4646
>
>
RE: Webdav and link-rewrite
Posted by Jasha Joachimsthal <j....@onehippo.com>.
> -----Original Message-----
> From: Reinhard Pötz [mailto:reinhard@apache.org]
> Sent: woensdag 30 juli 2008 13:29
> To: dev@cocoon.apache.org
> Subject: Webdav and link-rewrite
>
> Apart from the link-rewrite block he will also migrate the
> webdav block.
> Any thoughts or recommendations on this? The plan is that all
> Avalon components are migrated to Spring and that Jackrabbit
> is used as webdav server.
>
> I remember Jasha and Jereon have started to work on this in
> Rome last year. Any comments from you?
Jeroen has looked further at the WebDAV block after the Rome GT. The problem was the imcompatibility between HttpClient 2 (used in Slide) and HttpClient 3 (used in the WebDAV block). Jeroen still has an open Jira issue for this [1], but he's enjoying a well deserved holiday now.
Ard, do you know how far the WebDAV implementation in Jackrabbit is?
[1] https://issues.apache.org/jira/browse/COCOON-2153
Jasha Joachimsthal
www.onehippo.com
Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
Re: Webdav and link-rewrite
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 6, 2008, at 5:17 AM, Reinhard Pötz wrote:
> Reinhard Pötz wrote:
>> I agree with you that we shouldn't support such stuff but what
>> features do we want to see in a new LinkRewriteTransformer? (...
>> hence my suggestion that we start with a
>> ServletLinkRewriteTransformer because we know that we need it.)
>
> Any comments, otherwise I still believe that we only need a
> ServletLinkRewriteTransformer and will advise Lukas to go towards
> this direction.
I'd suggest to start with ServletLinkRewriteTransformer. When/if needs
for other features become clear, it should be possible to implement
full version by extending from the basic ServletLinkRewriteTransformer
version.
Vadim
Re: Webdav and link-rewrite
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Grzegorz Kossakowski wrote:
>> Reinhard Pötz pisze:
>>> Grzegorz Kossakowski wrote:
>>>> Reinhard Pötz pisze:
>>>>>
>>>>> I had a brief look at the link-rewrite block and think now that the
>>>>> migration of the LinkrewriterTransformer will be difficult because
>>>>> of its configuration can't be easily converted to Spring.
>>>>
>>>> What kind of obstacles you can see here?
>>>
>>> What's your suggestion for a configuration like this:
>>>
>>> <map:transformer name="linkrewriter"
>>> src="org.apache.cocoon.transformation.LinkRewriterTransformer">
>>> <input-module name="book-raw">
>>> <file src="cocoon://samples/linkrewriter/bookdemo/linkmap"
>>> reloadable="true" />
>>> </input-module>
>>> <input-module name="book">
>>> <input-module name="book-raw">
>>> <file src="{src}" reloadable="true" />
>>> </input-module>
>>> <prefix>//*[@label='</prefix>
>>> <suffix>']/@href</suffix>
>>> </input-module>
>>> </map:transformer>
>>
>> I have no suggestion but only to remove support for such stuff. These
>> days, when you define components as Spring beans you don't need to
>> support configuration passed from one component to another. At least I
>> don't see any need for supporting that kind of configuration.
>>
>> If we remove this, then of course we'll have to release 2.0 of link
>> rewriter block but I have no problem with it.
>
> I agree with you that we shouldn't support such stuff but what features
> do we want to see in a new LinkRewriteTransformer? (... hence my
> suggestion that we start with a ServletLinkRewriteTransformer because we
> know that we need it.)
Any comments, otherwise I still believe that we only need a
ServletLinkRewriteTransformer and will advise Lukas to go towards this
direction.
--
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 reinhard@apache.org
________________________________________________________________________
Re: Webdav and link-rewrite
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Grzegorz Kossakowski wrote:
>>> Reinhard Pötz pisze:
>>>>
>>>> I had a brief look at the link-rewrite block and think now that the
>>>> migration of the LinkrewriterTransformer will be difficult because
>>>> of its configuration can't be easily converted to Spring.
>>>
>>> What kind of obstacles you can see here?
>>
>> What's your suggestion for a configuration like this:
>>
>> <map:transformer name="linkrewriter"
>> src="org.apache.cocoon.transformation.LinkRewriterTransformer">
>> <input-module name="book-raw">
>> <file src="cocoon://samples/linkrewriter/bookdemo/linkmap"
>> reloadable="true" />
>> </input-module>
>> <input-module name="book">
>> <input-module name="book-raw">
>> <file src="{src}" reloadable="true" />
>> </input-module>
>> <prefix>//*[@label='</prefix>
>> <suffix>']/@href</suffix>
>> </input-module>
>> </map:transformer>
>
> I have no suggestion but only to remove support for such stuff. These
> days, when you define components as Spring beans you don't need to
> support configuration passed from one component to another. At least I
> don't see any need for supporting that kind of configuration.
>
> If we remove this, then of course we'll have to release 2.0 of link
> rewriter block but I have no problem with it.
I agree with you that we shouldn't support such stuff but what features
do we want to see in a new LinkRewriteTransformer? (... hence my
suggestion that we start with a ServletLinkRewriteTransformer because we
know that we need it.)
--
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 reinhard@apache.org
________________________________________________________________________
Re: Webdav and link-rewrite
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
> Grzegorz Kossakowski wrote:
>> Reinhard Pötz pisze:
>>>
>>> I had a brief look at the link-rewrite block and think now that the
>>> migration of the LinkrewriterTransformer will be difficult because of
>>> its configuration can't be easily converted to Spring.
>>
>> What kind of obstacles you can see here?
>
> What's your suggestion for a configuration like this:
>
> <map:transformer name="linkrewriter"
> src="org.apache.cocoon.transformation.LinkRewriterTransformer">
> <input-module name="book-raw">
> <file src="cocoon://samples/linkrewriter/bookdemo/linkmap"
> reloadable="true" />
> </input-module>
> <input-module name="book">
> <input-module name="book-raw">
> <file src="{src}" reloadable="true" />
> </input-module>
> <prefix>//*[@label='</prefix>
> <suffix>']/@href</suffix>
> </input-module>
> </map:transformer>
I have no suggestion but only to remove support for such stuff. These days, when you define
components as Spring beans you don't need to support configuration passed from one component to
another. At least I don't see any need for supporting that kind of configuration.
If we remove this, then of course we'll have to release 2.0 of link rewriter block but I have no
problem with it.
WFYT?
> TBH, that's one of the most horrible pieces of configuration I've ever
> seen.
I'm only not sure if I agree with "the most" part of your sentence. ;-)
--
Grzegorz Kossakowski
Re: Webdav and link-rewrite
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>>
>> I had a brief look at the link-rewrite block and think now that the
>> migration of the LinkrewriterTransformer will be difficult because of
>> its configuration can't be easily converted to Spring.
>
> What kind of obstacles you can see here?
What's your suggestion for a configuration like this:
<map:transformer name="linkrewriter"
src="org.apache.cocoon.transformation.LinkRewriterTransformer">
<input-module name="book-raw">
<file src="cocoon://samples/linkrewriter/bookdemo/linkmap"
reloadable="true" />
</input-module>
<input-module name="book">
<input-module name="book-raw">
<file src="{src}" reloadable="true" />
</input-module>
<prefix>//*[@label='</prefix>
<suffix>']/@href</suffix>
</input-module>
</map:transformer>
TBH, that's one of the most horrible pieces of configuration I've ever seen.
--
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 reinhard@apache.org
________________________________________________________________________
Re: Webdav and link-rewrite
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
>
> I had a brief look at the link-rewrite block and think now that the
> migration of the LinkrewriterTransformer will be difficult because of
> its configuration can't be easily converted to Spring.
What kind of obstacles you can see here?
> Since the main use case for the LinkrewritingTransformer is rewriting
> servlet: links, I think that the best compromise is that Lukas
> implements a specialized ServletLinkRewritingTransformer that could be
> put into the servlet-service-fw-components block. This will satisfy our
> main goal of getting rid of the linkrewrite dependency in the
> servlet-service-fw-components block.
I have mixed feelings about this proposal. I really like to reuse components if it's possible. Two
components doing more or less the same doesn't sound good to me.
> In the case that one needs the more advanced use cases, the already
> existing transformer can be used by adding the link-rewrite block.
>
> Or are there any better suggestions?
Since Lukas is going to migrate link-rewrite block to Spring anyway (at least that's how I read your
e-mail) I fail to understand why we can't use migrated block?
--
Grzegorz Kossakowski