Re: Webdav and link-rewrite
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
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//[EMAIL PROTECTED]'/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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Re: Webdav and link-rewrite
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
RE: Webdav and link-rewrite
-Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] 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
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//[EMAIL PROTECTED]'/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 [EMAIL PROTECTED]
Re: Webdav and link-rewrite
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//[EMAIL PROTECTED]'/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
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//[EMAIL PROTECTED]'/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 [EMAIL PROTECTED]
RE: 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? 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
