Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Konstantin,
On 4/22/2010 5:53 PM, Konstantin Kolinko wrote:
2010/4/23 Christopher Schultz ch...@christopherschultz.net:
I'd love to see the code that enforces this.
Search for applicationDispatcher.specViolation.request and
applicationDispatcher.specViolation.response or for SRV.8.2 in the
code.
In o.a.c.c.ApplicationDispatcher.doForward, there's this:
if (Globals.STRICT_SERVLET_COMPLIANCE) {
// Check SRV.8.2 / SRV.14.2.5.1 compliance
checkSameObjects(request, response);
}
and then
private void checkSameObjects(ServletRequest appRequest,
ServletResponse appResponse) throws ServletException {
ServletRequest originalRequest =
ApplicationFilterChain.getLastServicedRequest();
ServletResponse originalResponse =
ApplicationFilterChain.getLastServicedResponse();
NB: ApplicationFilterChain uses a ThreadLocal to store the last
serviced request.
// Some forwards, eg from valves will not set original values
if (originalRequest == null || originalResponse == null) {
return;
}
boolean same = false;
ServletRequest dispatchedRequest = appRequest;
//find the request that was passed into the service method
while (originalRequest instanceof ServletRequestWrapper
((ServletRequestWrapper)
originalRequest).getRequest()!=null ) {
originalRequest =
((ServletRequestWrapper) originalRequest).getRequest();
}
//compare with the dispatched request
while (!same) {
if (originalRequest.equals(dispatchedRequest)) {
same = true;
}
if (!same dispatchedRequest instanceof
ServletRequestWrapper) {
dispatchedRequest =
((ServletRequestWrapper)
dispatchedRequest).getRequest();
} else {
break;
}
}
if (!same) {
throw new ServletException(sm.getString(
applicationDispatcher.specViolation.request));
}
(The remainder of the code checks the response in a similar way).
That certainly looks like it should be balking at my Proxy-based
wrapper. I'll have to check a few things, because it looks like this
isn't working as expected.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvTNZcACgkQ9CaO5/Lv0PCCuQCeLcOQFVouu0Xj6svjckN302Kx
OR0Ani5LCMLhQmkfDMAYSIKajOsWffBD
=stbu
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
Christopher Schultz ch...@christopherschultz.net wrote in message
news:4bcf5f41.6060...@christopherschultz.net...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 4/21/2010 3:46 PM, André Warnier wrote:
Mark Thomas wrote:
On 21/04/2010 20:24, André Warnier wrote:
Mark Thomas wrote:
...
I'd just use JAD and decompile it.
Thanks. But although my intentions are not obnoxious nor illegal nor
anything of the kind, I would not want to even come under suspicion of
reverse-engineering. So is there something that just lists the
standard
calls/methods used in it ?
No. You can see the methods it exposes, but not the methods it uses.
Time to add some debug code to your wrapper to see what is being
called?
Mmmm. :-(
How do I do that, assuming I do not know in advance which methods it
calls ?
Do I need to define all the methods of HttpServletRequest in my wrapper,
just to make them trace their call ?
Or does there exist some more dummy-user-friendly methodology ?
It's pretty inaccessible for novice Java programmers, but you could use
the proxy API which is jsut about the coolest thing available in Java
IMO.
This is how you do the wrapping of the request:
import java.lang.reflect.Proxy;
import java.lang.reflect.InvocationHandler;
public class RequestMethodCallLogger
implements InvocationHandler, Filter
{
public void doFilter(...) {
HttpServletRequest wrappedRequest
= Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] { HttpServletRequest.class },
this);
chain.doFilter(wrappedRequest, response);
}
public Object invoke(Object proxy, Method method, Object[] args)
{
// Log to your favorite logger here
return method.invoke(proxy, args);
}
}
Basically, the Proxy class allows you to intercept the calls to
interface methods. The implementation of the invoke method is just a
pass-through to the real method after logging (an exercise left for
the reader).
This can be optimized a bit if you need to use it long-term, but the
above is about as compact as it gets.
If it does a forward or include done the line, this won't work with any
remotely recent version of Tomcat. These versions enforce the spec
requirement that the Request has to be a subclass of HttpServletWrapper
wrapping the original request, or the original request.
I'd still recommend the use of jad, honestly.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvPX0EACgkQ9CaO5/Lv0PCKVQCdG5SMXiySnsFEowVF7/44KM8s
b7kAoIAGSzxOIWmKt4+z6ATkqslTl5uW
=ykwF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On 21/04/2010 19:52, André Warnier wrote: Hi. A while ago, I wrote a servlet filter which has served me well since, to wrap a servlet for which I do not have nor can obtain the source code, and of which I only generally know what it does. Now it seems that with a new version of this servlet, the servlet itself crashes when wrapped by my filter, with a java.lang.StringIndexOutOfBoundsException. Where crash is defined as a condition which produces a stacktrace, or just an error message with the above explanation? p My servlet filter, under certain conditions, creates a HttpRequestWrapper derived object, which it passes to the servlet instead of the original HttpServletRequest object. I have a suspicion that the ultimate reason for the servlet crash, is that it now calls a method which I have not re-defined in my wrapper, which method the previous servlet version did not call (and that it is not very defensive about the result it expects to get, but nothing I can do about that). All this to ask the following : is there some generic java tool which allows to examine a compiled .class file, and determine which methods of HttpServletRequest it calls ? I do not need nor want to decompile the class, just to know what it calls. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: a servlet-related Java question
On Thu, Apr 22, 2010 at 2:37 AM, Bill Barker billwbar...@verizon.net wrote:
Christopher Schultz ch...@christopherschultz.net wrote in message
news:4bcf5f41.6060...@christopherschultz.net...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 4/21/2010 3:46 PM, André Warnier wrote:
Mark Thomas wrote:
On 21/04/2010 20:24, André Warnier wrote:
Mark Thomas wrote:
...
I'd just use JAD and decompile it.
Thanks. But although my intentions are not obnoxious nor illegal nor
anything of the kind, I would not want to even come under suspicion of
reverse-engineering. So is there something that just lists the
standard
calls/methods used in it ?
No. You can see the methods it exposes, but not the methods it uses.
Time to add some debug code to your wrapper to see what is being
called?
Mmmm. :-(
How do I do that, assuming I do not know in advance which methods it
calls ?
Do I need to define all the methods of HttpServletRequest in my wrapper,
just to make them trace their call ?
Or does there exist some more dummy-user-friendly methodology ?
It's pretty inaccessible for novice Java programmers, but you could use
the proxy API which is jsut about the coolest thing available in Java
IMO.
This is how you do the wrapping of the request:
import java.lang.reflect.Proxy;
import java.lang.reflect.InvocationHandler;
public class RequestMethodCallLogger
implements InvocationHandler, Filter
{
public void doFilter(...) {
HttpServletRequest wrappedRequest
= Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] { HttpServletRequest.class },
this);
chain.doFilter(wrappedRequest, response);
}
public Object invoke(Object proxy, Method method, Object[] args)
{
// Log to your favorite logger here
return method.invoke(proxy, args);
}
}
Basically, the Proxy class allows you to intercept the calls to
interface methods. The implementation of the invoke method is just a
pass-through to the real method after logging (an exercise left for
the reader).
This can be optimized a bit if you need to use it long-term, but the
above is about as compact as it gets.
If it does a forward or include done the line, this won't work with any
remotely recent version of Tomcat. These versions enforce the spec
requirement that the Request has to be a subclass of HttpServletWrapper
wrapping the original request, or the original request.
Good point - which really kills the proxy approach as a
general-purpose solution in this context...
I'd still recommend the use of jad, honestly.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvPX0EACgkQ9CaO5/Lv0PCKVQCdG5SMXiySnsFEowVF7/44KM8s
b7kAoIAGSzxOIWmKt4+z6ATkqslTl5uW
=ykwF
-END PGP SIGNATURE-
--
Kris Schneider
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill, On 4/22/2010 2:37 AM, Bill Barker wrote: It's pretty inaccessible for novice Java programmers, but you could use the proxy API which is [just] about the coolest thing available in Java IMO. If it does a forward or include done the line, this won't work with any remotely recent version of Tomcat. These versions enforce the spec requirement that the Request has to be a subclass of HttpServletWrapper wrapping the original request, or the original request. How does Tomcat enforce that? HttpServletRequestWrapper doesn't expose the underlying request. I must admit that I didn't try it. I should. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQpjMACgkQ9CaO5/Lv0PDioACfXvCsWsL6dPHDsegCEqCx0ISZ oF8Anj+PpzWrSWN9I6BWru0urmdLaWLg =qt08 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On Thu, Apr 22, 2010 at 3:40 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill, On 4/22/2010 2:37 AM, Bill Barker wrote: It's pretty inaccessible for novice Java programmers, but you could use the proxy API which is [just] about the coolest thing available in Java IMO. If it does a forward or include done the line, this won't work with any remotely recent version of Tomcat. These versions enforce the spec requirement that the Request has to be a subclass of HttpServletWrapper wrapping the original request, or the original request. How does Tomcat enforce that? HttpServletRequestWrapper doesn't expose the underlying request. ...but ServletRequestWrapper does I must admit that I didn't try it. I should. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQpjMACgkQ9CaO5/Lv0PDioACfXvCsWsL6dPHDsegCEqCx0ISZ oF8Anj+PpzWrSWN9I6BWru0urmdLaWLg =qt08 -END PGP SIGNATURE- -- Kris Schneider - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 4/22/2010 2:37 AM, Bill Barker wrote:
If [the request/filter] does a forward or include done the line, this
won't work with any remotely recent version of Tomcat. These
versions enforce the spec requirement that the Request has to be a
subclass of HttpServletWrapper wrapping the original request, or the
original request.
The following filter works as expected on Tomcat 6.0.26 (some changes
were required to make it actually work... my off-the-cuff implementation
was lacking a few details).
I can confirm that this filter operates properly across a forward()
call: I have a struts action handles by the Struts servlet that forwards
to a Velocity template handled by the Velocity servlet. All calls are
logged to stdout. (Wow, lots of calls to Request.getAttribute!)
import java.io.IOException;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class RequestMethodCallLogger
implements Filter
{
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws ServletException, IOException
{
if(request instanceof HttpServletRequest)
request = (ServletRequest)Proxy
.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] {
HttpServletRequest.class },
new Wrapper(request));
chain.doFilter(request, response);
}
public void init(FilterConfig config) { }
public void destroy() { }
static class Wrapper
implements InvocationHandler
{
private Object _target;
Wrapper(Object target)
{
_target = target;
}
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable
{
System.out.print(Intercepted: );
System.out.println(method);
return method.invoke(_target, args);
}
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvQsjUACgkQ9CaO5/Lv0PA65ACgiR4tiSji6MElZr9/Z0ibXdtX
WJQAnRoB/GZbrSwdfPjcf50IpHFmW4L9
=Stkm
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On Thu, Apr 22, 2010 at 4:31 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 4/22/2010 2:37 AM, Bill Barker wrote:
If [the request/filter] does a forward or include done the line, this
won't work with any remotely recent version of Tomcat. These
versions enforce the spec requirement that the Request has to be a
subclass of HttpServletWrapper wrapping the original request, or the
original request.
The following filter works as expected on Tomcat 6.0.26 (some changes
were required to make it actually work... my off-the-cuff implementation
was lacking a few details).
I can confirm that this filter operates properly across a forward()
call: I have a struts action handles by the Struts servlet that forwards
to a Velocity template handled by the Velocity servlet. All calls are
logged to stdout. (Wow, lots of calls to Request.getAttribute!)
For reference, here's the snippet from the Servlet 2.5 Spec:
SRV.8.2 Using a Request Dispatcher
To use a request dispatcher, a servlet calls either the include method
or forward method of the RequestDispatcher interface. The parameters
to these methods can be either the request and response arguments that
were passed in via the service method of the javax.servlet interface,
or instances of subclasses of the request and response wrapper classes
that were introduced for version 2.3 of the specification. In the
latter case, the wrapper instances must wrap the request or response
objects that the container passed into the service method.
But...the proxy is created prior to entering a servlet's service
method, so it may well appear to be the original request for the
purposes of creating and validating a dispatcher and its parameters...
import java.io.IOException;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class RequestMethodCallLogger
implements Filter
{
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws ServletException, IOException
{
if(request instanceof HttpServletRequest)
request = (ServletRequest)Proxy
.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] {
HttpServletRequest.class },
new Wrapper(request));
chain.doFilter(request, response);
}
public void init(FilterConfig config) { }
public void destroy() { }
static class Wrapper
implements InvocationHandler
{
private Object _target;
Wrapper(Object target)
{
_target = target;
}
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable
{
System.out.print(Intercepted: );
System.out.println(method);
return method.invoke(_target, args);
}
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvQsjUACgkQ9CaO5/Lv0PA65ACgiR4tiSji6MElZr9/Z0ibXdtX
WJQAnRoB/GZbrSwdfPjcf50IpHFmW4L9
=Stkm
-END PGP SIGNATURE-
--
Kris Schneider
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
2010/4/23 Kris Schneider kschnei...@gmail.com: On Thu, Apr 22, 2010 at 4:31 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- On 4/22/2010 2:37 AM, Bill Barker wrote: If [the request/filter] does a forward or include done the line, this won't work with any remotely recent version of Tomcat. These versions enforce the spec requirement that the Request has to be a subclass of HttpServletWrapper wrapping the original request, or the original request. SRV.8.2 is enforced when STRICT_SERVLET_COMPLIANCE property is set to true. http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html#Specification Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris, On 4/22/2010 4:48 PM, Kris Schneider wrote: On Thu, Apr 22, 2010 at 4:31 PM, Christopher Schultz ch...@christopherschultz.net wrote: The following filter works as expected on Tomcat 6.0.26 (some changes were required to make it actually work... my off-the-cuff implementation was lacking a few details). For reference, here's the snippet from the Servlet 2.5 Spec: SRV.8.2 Using a Request Dispatcher To use a request dispatcher, a servlet calls either the include method or forward method of the RequestDispatcher interface. The parameters to these methods can be either the request and response arguments that were passed in via the service method of the javax.servlet interface, or instances of subclasses of the request and response wrapper classes that were introduced for version 2.3 of the specification. In the latter case, the wrapper instances must wrap the request or response objects that the container passed into the service method. But...the proxy is created prior to entering a servlet's service method Yes, but there's nothing stopping me from placing the filter so that it only wraps FORWARD requests and violating the specification. I'll try that: I'm sure it'll still work. so it may well appear to be the original request for the purposes of creating and validating a dispatcher and its parameters... It probably doesn't matter: there's no real value in enforcing this particular requirement of the specification, so I'd be surprised if anyone has bothered to do so. Yup: adding dispatcherFORWARD/dispatcher to my filter still intercepts the calls without complaint. With a Servlet 2.3 DOCTYPE to boot. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQuwwACgkQ9CaO5/Lv0PAH+ACdHvyK0sJoaDQ1qIbnWA5eD9c8 sccAoL4TyPUWAcvzXTE06vha3QFYUK4s =EehI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/22/2010 4:53 PM, Konstantin Kolinko wrote: 2010/4/23 Kris Schneider kschnei...@gmail.com: On Thu, Apr 22, 2010 at 4:31 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- On 4/22/2010 2:37 AM, Bill Barker wrote: If [the request/filter] does a forward or include done the line, this won't work with any remotely recent version of Tomcat. These versions enforce the spec requirement that the Request has to be a subclass of HttpServletWrapper wrapping the original request, or the original request. SRV.8.2 is enforced when STRICT_SERVLET_COMPLIANCE property is set to true. http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html#Specification $ export CATALINA_OPTS=-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true $ ant tomcat-start Buildfile: build.xml check-local-properties: build-local-properties: init: check-tomcat-config: prepare-local-tomcat: tomcat-start: [echo] === [echo] Starting Tomcat [echo] === [echo] JAVA_HOME is /usr [echo] JAVA_OPTS is -Xmx64M [echo] CATALINA_HOME is /usr/local/apache-tomcat-6.0.26 [echo] CATALINA_BASE is /xxx [echo] CATALINA_OPTS is - -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true - -Djava.library.path=/usr/local/apache-tomcat-6.0.26/server/lib [echo] security-option is BUILD SUCCESSFUL Total time: 0 seconds $ Still runs. :p I double-checked that the system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE = true in the running VM. It is. I'd love to see the code that enforces this: it shouldn't be that hard to do, as Tomcat gets to specify the implementation of the original request and can unwrap any wrapped request to determine if it's legit. Kris and Bill are right: this shouldn't work, but it does. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQvIEACgkQ9CaO5/Lv0PCmBQCfYmmspo4D8/Dvh0G7/QrF5dI7 eQYAoKLfh7XbI6wphEMyxuikqDORthlk =l+5A -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
2010/4/23 Christopher Schultz ch...@christopherschultz.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/22/2010 4:53 PM, Konstantin Kolinko wrote: 2010/4/23 Kris Schneider kschnei...@gmail.com: On Thu, Apr 22, 2010 at 4:31 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- On 4/22/2010 2:37 AM, Bill Barker wrote: If [the request/filter] does a forward or include done the line, this won't work with any remotely recent version of Tomcat. These versions enforce the spec requirement that the Request has to be a subclass of HttpServletWrapper wrapping the original request, or the original request. SRV.8.2 is enforced when STRICT_SERVLET_COMPLIANCE property is set to true. http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html#Specification $ export CATALINA_OPTS=-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true I'd love to see the code that enforces this: Search for applicationDispatcher.specViolation.request and applicationDispatcher.specViolation.response or for SRV.8.2 in the code. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
a servlet-related Java question
Hi. A while ago, I wrote a servlet filter which has served me well since, to wrap a servlet for which I do not have nor can obtain the source code, and of which I only generally know what it does. Now it seems that with a new version of this servlet, the servlet itself crashes when wrapped by my filter, with a java.lang.StringIndexOutOfBoundsException. My servlet filter, under certain conditions, creates a HttpRequestWrapper derived object, which it passes to the servlet instead of the original HttpServletRequest object. I have a suspicion that the ultimate reason for the servlet crash, is that it now calls a method which I have not re-defined in my wrapper, which method the previous servlet version did not call (and that it is not very defensive about the result it expects to get, but nothing I can do about that). All this to ask the following : is there some generic java tool which allows to examine a compiled .class file, and determine which methods of HttpServletRequest it calls ? I do not need nor want to decompile the class, just to know what it calls. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On 21/04/2010 19:52, André Warnier wrote: Hi. A while ago, I wrote a servlet filter which has served me well since, to wrap a servlet for which I do not have nor can obtain the source code, and of which I only generally know what it does. Now it seems that with a new version of this servlet, the servlet itself crashes when wrapped by my filter, with a java.lang.StringIndexOutOfBoundsException. My servlet filter, under certain conditions, creates a HttpRequestWrapper derived object, which it passes to the servlet instead of the original HttpServletRequest object. I have a suspicion that the ultimate reason for the servlet crash, is that it now calls a method which I have not re-defined in my wrapper, which method the previous servlet version did not call (and that it is not very defensive about the result it expects to get, but nothing I can do about that). All this to ask the following : is there some generic java tool which allows to examine a compiled .class file, and determine which methods of HttpServletRequest it calls ? I do not need nor want to decompile the class, just to know what it calls. I'd just use JAD and decompile it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
Mark Thomas wrote: ... I'd just use JAD and decompile it. Thanks. But although my intentions are not obnoxious nor illegal nor anything of the kind, I would not want to even come under suspicion of reverse-engineering. So is there something that just lists the standard calls/methods used in it ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On 21/04/2010 20:24, André Warnier wrote: Mark Thomas wrote: ... I'd just use JAD and decompile it. Thanks. But although my intentions are not obnoxious nor illegal nor anything of the kind, I would not want to even come under suspicion of reverse-engineering. So is there something that just lists the standard calls/methods used in it ? No. You can see the methods it exposes, but not the methods it uses. Time to add some debug code to your wrapper to see what is being called? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 4/21/2010 3:24 PM, André Warnier wrote: Mark Thomas wrote: ... I'd just use JAD and decompile it. Thanks. But although my intentions are not obnoxious nor illegal nor anything of the kind, I would not want to even come under suspicion of reverse-engineering. So is there something that just lists the standard calls/methods used in it ? Jad can get your the (roughly) original Java source code for the whole class. You have to figure out what the variable names really should be (because they are lost during the compilation process and are replaced by things like String s1, s2, s3, etc.) but you can get a general idea of what the servlet is doing. If you just want to see a list of method calls from a particular method, you can use the standard Java tool javap with the -c switch which will disassemble the class (per method, which is nice) and you can just read the methods that get called. Presumably, you already know the stack trace of where the error is thrown, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvPU8cACgkQ9CaO5/Lv0PD+TgCgtSUqrj/Y04hnHFqaskN15M99 xh8An0LwFdNG3IT60no4lGpV+B0OKyXw =ojNv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
Mark Thomas wrote: On 21/04/2010 20:24, André Warnier wrote: Mark Thomas wrote: ... I'd just use JAD and decompile it. Thanks. But although my intentions are not obnoxious nor illegal nor anything of the kind, I would not want to even come under suspicion of reverse-engineering. So is there something that just lists the standard calls/methods used in it ? No. You can see the methods it exposes, but not the methods it uses. Time to add some debug code to your wrapper to see what is being called? Mmmm. :-( How do I do that, assuming I do not know in advance which methods it calls ? Do I need to define all the methods of HttpServletRequest in my wrapper, just to make them trace their call ? Or does there exist some more dummy-user-friendly methodology ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On 21/04/2010 20:46, André Warnier wrote: Mark Thomas wrote: On 21/04/2010 20:24, André Warnier wrote: Mark Thomas wrote: ... I'd just use JAD and decompile it. Thanks. But although my intentions are not obnoxious nor illegal nor anything of the kind, I would not want to even come under suspicion of reverse-engineering. So is there something that just lists the standard calls/methods used in it ? No. You can see the methods it exposes, but not the methods it uses. Time to add some debug code to your wrapper to see what is being called? Mmmm. :-( How do I do that, assuming I do not know in advance which methods it calls ? Do I need to define all the methods of HttpServletRequest in my wrapper, just to make them trace their call ? Yep. Or does there exist some more dummy-user-friendly methodology ? You could play games with reflection but with IDE code generation just writing the methods will be quicker. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 4/21/2010 3:46 PM, André Warnier wrote:
Mark Thomas wrote:
On 21/04/2010 20:24, André Warnier wrote:
Mark Thomas wrote:
...
I'd just use JAD and decompile it.
Thanks. But although my intentions are not obnoxious nor illegal nor
anything of the kind, I would not want to even come under suspicion of
reverse-engineering. So is there something that just lists the standard
calls/methods used in it ?
No. You can see the methods it exposes, but not the methods it uses.
Time to add some debug code to your wrapper to see what is being called?
Mmmm. :-(
How do I do that, assuming I do not know in advance which methods it
calls ?
Do I need to define all the methods of HttpServletRequest in my wrapper,
just to make them trace their call ?
Or does there exist some more dummy-user-friendly methodology ?
It's pretty inaccessible for novice Java programmers, but you could use
the proxy API which is jsut about the coolest thing available in Java IMO.
This is how you do the wrapping of the request:
import java.lang.reflect.Proxy;
import java.lang.reflect.InvocationHandler;
public class RequestMethodCallLogger
implements InvocationHandler, Filter
{
public void doFilter(...) {
HttpServletRequest wrappedRequest
= Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] { HttpServletRequest.class },
this);
chain.doFilter(wrappedRequest, response);
}
public Object invoke(Object proxy, Method method, Object[] args)
{
// Log to your favorite logger here
return method.invoke(proxy, args);
}
}
Basically, the Proxy class allows you to intercept the calls to
interface methods. The implementation of the invoke method is just a
pass-through to the real method after logging (an exercise left for
the reader).
This can be optimized a bit if you need to use it long-term, but the
above is about as compact as it gets.
I'd still recommend the use of jad, honestly.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvPX0EACgkQ9CaO5/Lv0PCKVQCdG5SMXiySnsFEowVF7/44KM8s
b7kAoIAGSzxOIWmKt4+z6ATkqslTl5uW
=ykwF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
On Wed, Apr 21, 2010 at 4:25 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 4/21/2010 3:46 PM, André Warnier wrote:
Mark Thomas wrote:
On 21/04/2010 20:24, André Warnier wrote:
Mark Thomas wrote:
...
I'd just use JAD and decompile it.
Thanks. But although my intentions are not obnoxious nor illegal nor
anything of the kind, I would not want to even come under suspicion of
reverse-engineering. So is there something that just lists the standard
calls/methods used in it ?
No. You can see the methods it exposes, but not the methods it uses.
Time to add some debug code to your wrapper to see what is being called?
Mmmm. :-(
How do I do that, assuming I do not know in advance which methods it
calls ?
Do I need to define all the methods of HttpServletRequest in my wrapper,
just to make them trace their call ?
Or does there exist some more dummy-user-friendly methodology ?
It's pretty inaccessible for novice Java programmers, but you could use
the proxy API which is jsut about the coolest thing available in Java IMO.
This is how you do the wrapping of the request:
Not to potentially muddy the waters, but I think your
InvocationHandler is invoking the method on the wrong object - it
shouldn't invoke it on the proxy but on the original request. So,
something like this:
public void doFilter(final ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
InvocationHandler handler = new InvocationHandler() {
public Object invoke(Object proxy, Method method, Object[]
args) throws Throwable {
// log some stuff
return method.invoke(request, args);
}
};
HttpServletRequest proxyRequest =
(HttpServletRequest)Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] { HttpServletRequest.class }, handler);
chain.doFilter(proxyRequest, response);
}
import java.lang.reflect.Proxy;
import java.lang.reflect.InvocationHandler;
public class RequestMethodCallLogger
implements InvocationHandler, Filter
{
public void doFilter(...) {
HttpServletRequest wrappedRequest
= Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(),
new Class[] { HttpServletRequest.class },
this);
chain.doFilter(wrappedRequest, response);
}
public Object invoke(Object proxy, Method method, Object[] args)
{
// Log to your favorite logger here
return method.invoke(proxy, args);
}
}
Basically, the Proxy class allows you to intercept the calls to
interface methods. The implementation of the invoke method is just a
pass-through to the real method after logging (an exercise left for
the reader).
This can be optimized a bit if you need to use it long-term, but the
above is about as compact as it gets.
I'd still recommend the use of jad, honestly.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvPX0EACgkQ9CaO5/Lv0PCKVQCdG5SMXiySnsFEowVF7/44KM8s
b7kAoIAGSzxOIWmKt4+z6ATkqslTl5uW
=ykwF
-END PGP SIGNATURE-
--
Kris Schneider
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a servlet-related Java question
Mark, Chris and Kris, thanks. You have all impressed the hell out of me. You have also lost me.. at a guess about 50 lines ago. But I get the idea, and it is nice to learn that such things exist. I also believe this may be helpful to someone else some day looking for a solution to a case much more complicated than mine. As for me, I think I will use the little grey cells and some additional circumstancial knowledge to try to figure out what the supplier /may/ have logically changed to that servlet, to restrict the number of methods to implement and log in my filter, to a reasonable try first list. If that fails, I'll have a go at your proxy method, which looks really cool. (Kind of reminds me of the Perl AUTOLOAD method, which does basically the same thing.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
