You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jos Snellings <jo...@upperware.biz> on 2012/05/10 13:05:05 UTC

mount named blocks inconvenience

Dear cocooners,

Problem:
1. In the definition of a named block, for:
    <servlet:context mount-path="/foo" context-path="blockcontext:/foo/"/>

This tells the cocoon servlet that a block "foo" is mounted on "foo" in the
webapp.

2. sitemap.xmap
  An empty matcher like in the cocoon sample:
 <map:match pattern="">
            <map:read src="welcome.html" mime-type="text/html"/>
  </map:match>

3. call
    localhost/mywebapp/foo

   or, the root of the block. (it is configured correctly, all the rest
works).

EVENT:  exception:

For named blocks
java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at
java.lang.String.charAt(String.java:687) at
org.apache.cocoon.sitemap.node.MatchNode.invoke(MatchNode.java:89)

Without having it investigated in extenso, it seems that when blocks are
named, so not mounted as 'root block', that there is a problem with
<excerpt>
String testValue = resolvedValue == null
                ? null : resolvedValue.toString();
        if (testValue == null) {
            testValue = invocation.getRequestURI();
            if (testValue.charAt(0) == '/') {
                testValue = testValue.substring(1);
            }
        }
</excerpt>
The value is null.

By the way,
localhost/mywebapp/foo/
nicely produces the expected welcome page.

Anyone knows this problem?


Kind regards,
Jos

-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
        -- Gilbert K. Chesterson

Re: mount named blocks inconvenience

Posted by Jos Snellings <jo...@upperware.biz>.
O yes, Francesco, that is in every way a good workaround.
Thanks,
Jos

On Fri, May 11, 2012 at 12:43 PM, Francesco Chicchiriccò <
ilgrosso@apache.org> wrote:

>  On 10/05/2012 13:05, Jos Snellings wrote:
>
> Dear cocooners,
>
> Problem:
> 1. In the definition of a named block, for:
>     <servlet:context mount-path="/foo" context-path="blockcontext:/foo/"/>
>
> This tells the cocoon servlet that a block "foo" is mounted on "foo" in
> the webapp.
>
> 2. sitemap.xmap
>   An empty matcher like in the cocoon sample:
>  <map:match pattern="">
>             <map:read src="welcome.html" mime-type="text/html"/>
>   </map:match>
>
> 3. call
>     localhost/mywebapp/foo
>
>    or, the root of the block. (it is configured correctly, all the rest
> works).
>
> EVENT:  exception:
>
> For named blocks
>  java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:687) at
> org.apache.cocoon.sitemap.node.MatchNode.invoke(MatchNode.java:89)
>
> Without having it investigated in extenso, it seems that when blocks are
> named, so not mounted as 'root block', that there is a problem with
> <excerpt>
> String testValue = resolvedValue == null
>                 ? null : resolvedValue.toString();
>         if (testValue == null) {
>             testValue = invocation.getRequestURI();
>             if (testValue.charAt(0) == '/') {
>                 testValue = testValue.substring(1);
>             }
>         }
> </excerpt>
> The value is null.
>
> By the way,
> localhost/mywebapp/foo/
> nicely produces the expected welcome page.
>
> Anyone knows this problem?
>
>
> I've seen this since my first experiments with Cocoon 2.0 (and I am sure
> that if you search archives you would also get some better reply than
> this...): basically,
>
> http://localhost/mywebapp/foo
>
> and
>
> http://localhost/mywebapp/foo/
>
> are two different HTTP resources; the root of matching for a given block
> (i.e. "<map:match pattern="">) will always get not more than "foo/".
>
> If you want to match http://localhost/mywebapp/foo, I think you'll have
> to mount something at root (say a 'bar' block)
>
>   <servlet:context mount-path="" context-path="blockcontext:/bar"/>
>
> then inside this bar block have
>
> <map:match pattern="foo">
> ...
>
>
> I hope all this is "formally" correct: if not, it's the way I've been
> following so far ;-)
> Regards.
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/
>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
        -- Gilbert K. Chesterson

Re: mount named blocks inconvenience

Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/05/2012 13:05, Jos Snellings wrote:
> Dear cocooners,
>
> Problem:
> 1. In the definition of a named block, for:
> <servlet:context mount-path="/foo" context-path="blockcontext:/foo/"/>
>
> This tells the cocoon servlet that a block "foo" is mounted on "foo" 
> in the webapp.
>
> 2. sitemap.xmap
>   An empty matcher like in the cocoon sample:
> <map:match pattern="">
> <map:read src="welcome.html" mime-type="text/html"/>
> </map:match>
>
> 3. call
>     localhost/mywebapp/foo
>
>    or, the root of the block. (it is configured correctly, all the 
> rest works).
>
> EVENT:  exception:
>
> For named blocks
> java.lang.StringIndexOutOfBoundsException: String index out of range: 
> 0 at java.lang.String.charAt(String.java:687) at 
> org.apache.cocoon.sitemap.node.MatchNode.invoke(MatchNode.java:89)
>
> Without having it investigated in extenso, it seems that when blocks 
> are named, so not mounted as 'root block', that there is a problem with
> <excerpt>
> String testValue = resolvedValue == null
>                 ? null : resolvedValue.toString();
>         if (testValue == null) {
>             testValue = invocation.getRequestURI();
>             if (testValue.charAt(0) == '/') {
>                 testValue = testValue.substring(1);
>             }
>         }
> </excerpt>
> The value is null.
>
> By the way,
> localhost/mywebapp/foo/
> nicely produces the expected welcome page.
>
> Anyone knows this problem?

I've seen this since my first experiments with Cocoon 2.0 (and I am sure 
that if you search archives you would also get some better reply than 
this...): basically,

http://localhost/mywebapp/foo

and

http://localhost/mywebapp/foo/

are two different HTTP resources; the root of matching for a given block 
(i.e. "<map:match pattern="">) will always get not more than "foo/".

If you want to match http://localhost/mywebapp/foo, I think you'll have 
to mount something at root (say a 'bar' block)

<servlet:context mount-path="" context-path="blockcontext:/bar"/>

then inside this bar block have

<map:match pattern="foo">
...


I hope all this is "formally" correct: if not, it's the way I've been 
following so far ;-)
Regards.

-- 
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/