From: Jean-Baptiste Quenot <[EMAIL PROTECTED]>
Date: Mon, 3 Apr 2006 17:29:51 +0200

* [EMAIL PROTECTED]:

> How can I map some servlets next to the Cocoon stuff in the same
> context?

You can't.

That's strange, since I am :-)

I put the servlets' jar file in WEB-INF/lib in the Cocoon war file, and use the following in web.xml:

        <servlet id="Servlet_1102677113306">
                <servlet-name>LoginServlet</servlet-name>
                <servlet-class>com.foobar.LoginServlet</servlet-class>
        </servlet>
        <servlet id="Servlet_1102677113307">
                <servlet-name>LogoutServlet</servlet-name>
                <servlet-class>com.foobar.LogoutServlet</servlet-class>
        </servlet>
        <servlet id="Servlet_1102677113310">
                <servlet-name>Cocoon</servlet-name>
                <display-name>Cocoon</display-name>
                <description>Cocoon</description>
                
<servlet-class>org.apache.cocoon.servlet.ParanoidCocoonServlet</servlet-class>
...
        </servlet>
        <servlet-mapping id="ServletMapping_1102677775479">
                <servlet-name>Cocoon</servlet-name>
                <url-pattern>/</url-pattern>
        </servlet-mapping>
        <servlet-mapping id="ServletMapping_1102677775480">
                <servlet-name>Cocoon</servlet-name>
                <url-pattern>*.jsp</url-pattern>
        </servlet-mapping>
        <servlet-mapping id="ServletMapping_1102677775482">
                <servlet-name>LoginServlet</servlet-name>
                <url-pattern>/LoginServlet</url-pattern>
        </servlet-mapping>
        <servlet-mapping id="ServletMapping_1102677775483">
                <servlet-name>LogoutServlet</servlet-name>
                <url-pattern>/LogoutServlet</url-pattern>
        </servlet-mapping>

Works just fine for me. It may depend on the container being used, though, and the servlet spec version it supports. The Servlet 2.3 spec says:

"The URL path mapping rules below are used in
order. The first successful match is used with no further matches attempted:
1. The container will try to find an exact match of the path of the request to the
path of the servlet. A successful match selects the servlet.
2. The container will recursively try to match the longest path-prefix: This is done by stepping down the path tree a directory at a time, using the ’/’ character as
a path separator. The longest match determines the servlet selected."
3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last ’.’ character. 4. If neither of the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a "default"
servlet is defined for the application, it will be used.
...
A string containing only the ’/’ character indicates the "default" servlet of the
application."

So any requests for /context/LoginServlet and /context/LogoutServlet should therefore be matched to their corresponding servlets under rule 1. Anything else goes to the Cocoon servlet due to rule 4. Even if the Cocoon servlet mapping used "/*", that should come under rule 2 so the login/logout servlets should still work. And if my servlets were mapped to a path rather than a single URL (/context/foobar/*) then they should still take precedence due to having a longer path prefix.

However, the spec does warn that in previous versions these were only suggestions rather than a requirement, so older (or buggy) containers may not behave in the same way. And I haven't checked the 2.4 spec to see if that's any different. The above example is taken from code we have running in Websphere (in case you couldn't guess from all those extra "id" attributes) 5.0 and 5.1. IIRC we had some trouble getting it to work properly with Cocoon mapped to "/*" (some security-related container, I think). YMMV.


Andrew.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to