RE: [BUG] NPE in VariableResolver
Thanks!
Carsten
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 9:36 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release and the input
module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
The broken variable is {baselink:}. My code couldn't handle
nothing after the colon. I've committed a fix (along with
some files I didn't mean to commit - I rolled them back).
Having said that, I can't work out what the example should
have been doing. But at least it shouldn't break now.
Regards, Upayavira
RE: [BUG] NPE in VariableResolver
Seems like a good change to me.
Carsten
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jorg Heymans
Sent: Thursday, May 06, 2004 11:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Coincidentally, i was just clicking through the HEAD samples
to see if there were any broken links i could (easily) fix. (see also
http://issues.apache.org/bugzilla/show_bug.cgi?id=28810)
The baselink module sitemap should be patched to something
more appropriate like inlined patch below. There are two
variables available (looking at the source) in this module,
SitemapBaseLink and RequestBaseLink. They both take a URL and
return a relative path. I don't know if this module is used a
lot, but at least with the patch the sample is showing the
module's functionality again.
Index: src/webapp/samples/modules/sitemap.xmap
===
RCS file:
/home/cvspublic/cocoon-2.1/src/webapp/samples/modules/sitemap.xmap,v
retrieving revision 1.9
diff -u -r1.9 sitemap.xmap
--- src/webapp/samples/modules/sitemap.xmap 10 Mar 2004 13:36:09
- 1.9
+++ src/webapp/samples/modules/sitemap.xmap 6 May 2004
21:05:40 -
@@ -101,14 +101,16 @@
map:match pattern=content/baselink.xml
map:generate type=jx src=properties.xml
- map:parameter name=(anything) value={baselink:}/
+ map:parameter name=sitemapAsBase
value={baselink:SitemapBaseLink}/
+ map:parameter name=requestAsBase
value={baselink:RequestBaseLink}/
/map:generate
map:transform src=properties2html.xsl
map:parameter name=title value=BaseLink Input
Module (BaseLinkModule)/
map:parameter name=description value=Returns
a relative path (../,
-../../, etc) linking to the base of the current request
URI. In
-this demonstration, the request URI is {0} (an internal
request not
+../../, etc) linking to either the base of the current
request URI or the base
+of the sitemap.
+In this demonstration, the request URI is {0}
(an internal
request not
equivalent to what the user sees)/
/map:transform
map:serialize /
HTH
Jorg
Upayavira wrote:
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release and the input
module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
The broken variable is {baselink:}. My code couldn't handle nothing
after the colon. I've committed a fix (along with some
files I didn't
mean to commit - I rolled them back).
Having said that, I can't work out what the example should
have been
doing. But at least it shouldn't break now.
Regards, Upayavira
Re: [BUG] NPE in VariableResolver
Carsten Ziegeler wrote:
Seems like a good change to me.
Yup. I wondered what the sample was supposed to do when I looked at it -
it seemed pretty useless as it was.
I've committed your change Jorg, thanks for that.
Upayavira
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jorg Heymans
Sent: Thursday, May 06, 2004 11:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Coincidentally, i was just clicking through the HEAD samples
to see if there were any broken links i could (easily) fix. (see also
http://issues.apache.org/bugzilla/show_bug.cgi?id=28810)
The baselink module sitemap should be patched to something
more appropriate like inlined patch below. There are two
variables available (looking at the source) in this module,
SitemapBaseLink and RequestBaseLink. They both take a URL and
return a relative path. I don't know if this module is used a
lot, but at least with the patch the sample is showing the
module's functionality again.
Index: src/webapp/samples/modules/sitemap.xmap
===
RCS file:
/home/cvspublic/cocoon-2.1/src/webapp/samples/modules/sitemap.xmap,v
retrieving revision 1.9
diff -u -r1.9 sitemap.xmap
--- src/webapp/samples/modules/sitemap.xmap 10 Mar 2004 13:36:09
- 1.9
+++ src/webapp/samples/modules/sitemap.xmap 6 May 2004
21:05:40 -
@@ -101,14 +101,16 @@
map:match pattern=content/baselink.xml
map:generate type=jx src=properties.xml
- map:parameter name=(anything) value={baselink:}/
+ map:parameter name=sitemapAsBase
value={baselink:SitemapBaseLink}/
+ map:parameter name=requestAsBase
value={baselink:RequestBaseLink}/
/map:generate
map:transform src=properties2html.xsl
map:parameter name=title value=BaseLink Input
Module (BaseLinkModule)/
map:parameter name=description value=Returns
a relative path (../,
-../../, etc) linking to the base of the current request
URI. In
-this demonstration, the request URI is {0} (an internal
request not
+../../, etc) linking to either the base of the current
request URI or the base
+of the sitemap.
+In this demonstration, the request URI is {0}
(an internal
request not
equivalent to what the user sees)/
/map:transform
map:serialize /
HTH
Jorg
Upayavira wrote:
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release and the input
module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
The broken variable is {baselink:}. My code couldn't handle nothing
after the colon. I've committed a fix (along with some
files I didn't
mean to commit - I rolled them back).
Having said that, I can't work out what the example should
have been
doing. But at least it shouldn't break now.
Regards, Upayavira
Re: [BUG] NPE in VariableResolver
Coincidentally, i was just clicking through the HEAD samples to see if
there were any broken links i could (easily) fix. (see also
http://issues.apache.org/bugzilla/show_bug.cgi?id=28810)
The baselink module sitemap should be patched to something more
appropriate like inlined patch below. There are two variables available
(looking at the source) in this module, SitemapBaseLink and
RequestBaseLink. They both take a URL and return a relative path. I
don't know if this module is used a lot, but at least with the patch the
sample is showing the module's functionality again.
Index: src/webapp/samples/modules/sitemap.xmap
===
RCS file:
/home/cvspublic/cocoon-2.1/src/webapp/samples/modules/sitemap.xmap,v
retrieving revision 1.9
diff -u -r1.9 sitemap.xmap
--- src/webapp/samples/modules/sitemap.xmap 10 Mar 2004 13:36:09
- 1.9
+++ src/webapp/samples/modules/sitemap.xmap 6 May 2004 21:05:40 -
@@ -101,14 +101,16 @@
map:match pattern=content/baselink.xml
map:generate type=jx src=properties.xml
- map:parameter name=(anything) value={baselink:}/
+ map:parameter name=sitemapAsBase
value={baselink:SitemapBaseLink}/
+ map:parameter name=requestAsBase
value={baselink:RequestBaseLink}/
/map:generate
map:transform src=properties2html.xsl
map:parameter name=title value=BaseLink Input Module
(BaseLinkModule)/
map:parameter name=description value=Returns a relative
path (../,
-../../, etc) linking to the base of the current request
URI. In
-this demonstration, the request URI is {0} (an internal
request not
+../../, etc) linking to either the base of the current
request URI or the base
+of the sitemap.
+In this demonstration, the request URI is {0} (an internal
request not
equivalent to what the user sees)/
/map:transform
map:serialize /
HTH
Jorg
Upayavira wrote:
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release
and the input module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
The broken variable is {baselink:}. My code couldn't handle nothing
after the colon. I've committed a fix (along with some files I didn't
mean to commit - I rolled them back).
Having said that, I can't work out what the example should have been
doing. But at least it shouldn't break now.
Regards, Upayavira
