My guice-bind servlet is not called

824 views
Skip to first unread message

Ken

unread,
Jan 10, 2010, 2:22:22 AM1/10/10
to google-guice
I am playing with Guice 2.0 and WebSphere 6.1. My servlet is
configured in Guice module.

public class ServletConfigListener extends GuiceServletContextListener
{
@Override
protected Injector getInjector() {
return Guice.createInjector(new RpcServerModule());
}
}

public class RpcServerModule extends ServletModule {
@Override
protected void configureServlets() {
serve("*.rpc").with(RpcServiceImpl.class);
}
}

And I have configured GuiceFilter and above listener in my web.xml.
<filter>
<filter-name>guiceFilter</filter-name>
<filter-class>com.google.inject.servlet.GuiceFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>guiceFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>
gov.ontario.mnr.irs.ServletConfigListener
</listener-class>
</listener>

However my servlet RpcServiceImpl is never called. I traced Guice and
found out in class com.google.inject.servlet.ServletDefinition, method
service(), it tries to match the servlet path with my servlet pattern:
public boolean service(ServletRequest servletRequest,
ServletResponse servletResponse) throws IOException,
ServletException {
final boolean serve = shouldServe(((HttpServletRequest)
servletRequest).getServletPath());

But the servlet path always equals to "", then the pattern is not
matched. Should Guice use request URI instead of servlet path when try
to match servlet pattern?

I worked this around by putting following lines in web.xml:
<servlet>
<servlet-name>RpcServlet</servlet-name>
<display-name>Gwt-Rpc Servlet</display-name>
<servlet-class>com.my.RpcServiceImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>RpcServlet</servlet-name>
<url-pattern>*.rpc</url-pattern>
</servlet-mapping>

I don't believe this is a Guice bug, as if it is a bug, it should be
very easy to be detected. What did I do wrong? Any help is very
appreciated. Thank you.

Ken

unread,
Jan 14, 2010, 11:07:15 PM1/14/10
to google-guice
Am I the only one have this problem? I hope someone can share some
help.

Dhanji R. Prasanna

unread,
Jan 14, 2010, 11:16:43 PM1/14/10
to google...@googlegroups.com
I think the problem is with websphere, that you need a default servlet to get the GuiceFilter to fire.

Alen Vrecko knows more about this. But other servlet containers are generally well behaved and ship with a DefaultServlet that serves files statically (and typically a JSP servlet too).

Dhanji.

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To post to this group, send email to google...@googlegroups.com.
To unsubscribe from this group, send email to google-guice...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.




Alen Vrečko

unread,
Jan 15, 2010, 2:21:14 PM1/15/10
to google-guice
Hi, Guys.

I haven't worked much with WebSphere. It is a horrible piece of
software. I don't consider it a servlet spec compatible container (at
least not out of the box).

What I think is happening: When you request /foo/bar/baz.rpc the
server computes the target servlet, it doesn't match any declared
servlet therefore it defaults to default servlet after which the
filter chain is computed and invoked. Something along those lines if I
understand how servlet containers work.

I think the problem is that WS in the case of default servlet sets
Servlet Path to "" even if you requested "/foo/bar/baz.rpc".

Definitely take a look at
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rweb_custom_props.html.

More specifically look for

com.ibm.ws.webcontainer.enabledefaultservletrequestpathelements

In general on WS 6.1 I'd try setting

com.ibm.ws.webcontainer.enabledefaultservletrequestpathelements=true
com.ibm.ws.webcontainer.invokeFiltersCompatibility=true
prependSlashToResource=true

The guys I work with say you have to go with your "instinct" when
configuring WS. Hardly an engineering approach.

HTH.

Cheers,
Alen

On Jan 15, 5:16 am, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> I think the problem is with websphere, that you need a default servlet to
> get the GuiceFilter to fire.
>
> Alen Vrecko knows more about this. But other servlet containers are
> generally well behaved and ship with a DefaultServlet that serves files
> statically (and typically a JSP servlet too).
>
> Dhanji.
>

> > google-guice...@googlegroups.com<google-guice%2Bunsu...@googlegroups.com>

Dhanji R. Prasanna

unread,
Jan 15, 2010, 7:01:04 PM1/15/10
to google...@googlegroups.com
Use the force!

To unsubscribe from this group, send email to google-guice...@googlegroups.com.

Ken

unread,
Jan 17, 2010, 5:08:29 AM1/17/10
to google-guice
Hi, Alen

I installed WebSphere Fix Pack 27 which contains the fix. My WebSphere
is upgraded to 6.1.0.27. And I set the three custom properties.
However the problem is not fixed.

Is there any other thing I can try?

Thank you.
Ken


On Jan 15, 2:21 pm, Alen Vrečko <alen_vre...@yahoo.com> wrote:
> Hi, Guys.
>
> I haven't worked much with WebSphere. It is a horrible piece of
> software. I don't consider it a servlet spec compatible container (at
> least not out of the box).
>
> What I think is happening: When you request /foo/bar/baz.rpc the
> server computes the target servlet, it doesn't match any declared
> servlet therefore it defaults to default servlet after which the
> filter chain is computed and invoked. Something along those lines if I
> understand how servlet containers work.
>
> I think the problem is that WS in the case of default servlet sets
> Servlet Path to "" even if you requested "/foo/bar/baz.rpc".
>

> Definitely take a look athttp://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic....

Alen Vrečko

unread,
Jan 17, 2010, 11:09:20 AM1/17/10
to google-guice
Hi, Ken.

Looks like WS 6.1 still doesn't get the hint you want the full path
and not "".

There is this thing in the servlet spec:

Servlet Path: The path section that directly corresponds to the
mapping
which activated this request. This path starts with a ’/’ character
except in the
case where the request is matched with the ‘/*’ pattern, in which case
it is an
empty string.

Looks like from all the Servers only WS follows this in the case of
default servlet.

I'd try making a filter before the guice filter that returns pathinfo
instead of servletpath. Like

doFilter
chain.doFilter(new HttpServletRequestWrapper((HttpServletRequest) req)
{
@Override
public String getServletPath() {
return super.getPathInfo();
}
},resp);

this will be problematic if you have other servlets in web.xml.

Listen to your midi-chlorians!

Cheers
Alen

Ken

unread,
Jan 17, 2010, 4:43:51 PM1/17/10
to google-guice
Hi, Alen,

Seems like WebSphere is doing it right with Servlet path.

I figured out a workaround:
Add a File Servlet into web.xml and map it to all file extensions. As
these requests are not mapped to default Servlet any more, so the
Servlet path is not empty string. Please see below.

<servlet>
<servlet-name>FileServlet</servlet-name>
<servlet-class>
com.ibm.ws.webcontainer.servlet.SimpleFileServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.rpc</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.js</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.css</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.png</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.gif</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>FileServlet</servlet-name>
<url-pattern>*.jpg</url-pattern>
</servlet-mapping>

This works for me. Now all my servlets and filters are working fine.

Thanks.
Ken

Reply all
Reply to author
Forward
0 new messages