cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stevens" <at...@hotmail.com>
Subject Re: servlets & cocoon?
Date Mon, 03 Apr 2006 16:49:04 GMT
>From: Jean-Baptiste Quenot <jbq@apache.org>
>Date: Mon, 3 Apr 2006 17:29:51 +0200
>
>* Fernando.Matomira@thomson.com:
>
> > 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message