Re: AOP interceptor: match only subclass methods
Thanks, that let me in the right direction. I ended up writing my own
class and method matchers that both accepted the same list of
subpackage names as the method matcher can't simply grab the package
names from the class matcher.
In case anyone else is trying to do class matching at runtime, i.e.
inside the interceptor itself, take note that classes touched by Guice
AOP will have $$EnhancerByGuice$$ added to the class name, can't do
a straight equals() comparison.
On Jun 13, 11:25 am, Alen Vrecko alen_vre...@yahoo.com wrote:
Notice the first Matcher takes a ? super Class and it decides if the
class is eligible for AOP. The second Matcher takes a ? super Method
and it decides if it should intercept the method or not.
Nothing is stopping you from inspecting the method e.g.
new AbstractMatcherMethod() {
public boolean matches(Method method) {
return method.getDeclaringClass().getPackage
() // decide if you like this method or not
}
}
Cheers
Alen
On Jun 13, 3:02 pm, tchan tks...@gmail.com wrote:
Hi;
Has anyone worked with the AOP interceptors in Guice much? I'm used
to using full blown AspectJ in my other projects and am having
difficulty reproducing some mix-in behaviour using plain AOP.
I want to introduce a tracer on instance methods in certain packages.
The catch is that I only want the logic applied to methods declared in
those packages. That is, skip methods defined in parent classes that
reside outside of the target packages.
So say class A resides in org.library and class B that extends A
resides in my.project. I want to only intercept methods defined in
my.project.B and not any inherited method from org.library.A.
Right now, I am using subpackageOf() as my class matcher and any() as
my method matcher in my bind interceptor declaration. This doesn't do
what I want, it will apply to all methods in the subpackage, even
inherited methods from classes outside the packages I state.
Does anyone have any ideas on how to do this with a custom method
matcher? And if it can't be done statically, what about during
runtime in the actual interceptor?
Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
google-guice group.
To post to this group, send email to google-guice@googlegroups.com
To unsubscribe from this group, send email to
google-guice+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~--~~~~--~~--~--~---
AOP interceptor: match only subclass methods
Hi; Has anyone worked with the AOP interceptors in Guice much? I'm used to using full blown AspectJ in my other projects and am having difficulty reproducing some mix-in behaviour using plain AOP. I want to introduce a tracer on instance methods in certain packages. The catch is that I only want the logic applied to methods declared in those packages. That is, skip methods defined in parent classes that reside outside of the target packages. So say class A resides in org.library and class B that extends A resides in my.project. I want to only intercept methods defined in my.project.B and not any inherited method from org.library.A. Right now, I am using subpackageOf() as my class matcher and any() as my method matcher in my bind interceptor declaration. This doesn't do what I want, it will apply to all methods in the subpackage, even inherited methods from classes outside the packages I state. Does anyone have any ideas on how to do this with a custom method matcher? And if it can't be done statically, what about during runtime in the actual interceptor? Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups google-guice group. To post to this group, send email to google-guice@googlegroups.com To unsubscribe from this group, send email to google-guice+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~--~~~~--~~--~--~---
Re: Guice 2 SNAPSHOT: migrating from web.xml to ServletModule/GuiceFilter
Well, as a workaround, I've resorted to using this when I need to do a
forward:
protected static ServletRequest getUnderlyingRequest
( HttpServletRequest request )
{
ServletRequest innerRequest = request;
while ( innerRequest instanceof HttpServletRequestWrapper )
{
innerRequest = ( ( HttpServletRequestWrapper )
innerRequest ).getRequest();
}
return innerRequest;
}
It's pure hack but I can live with it until it gets fixed in Guice.
And I believe the WEB-INF jsp trick is only valid for recent versions
of the spec, I only learned of this in the past couple of years myself
but it's great for keeping your jsps private.
On May 5, 8:09 am, Alen Vrecko alen_vre...@yahoo.com wrote:
Hey, thanks for the reply.
Hi. You to. I'll learn from this.
I am just using the snapshot build.
I don't think there is any difference with regards to servlets.
From my understanding, if I am using the dispatcher from
ServletRequest, forwards and includes will be relative to the servlet
path unless preceded by a slash. In that case, it's relative to
context root, i.e. WebContent. At least this is how it works in
Tomcat and WebSphere.
You're right. In the servlet spec I found this part a bit confusing it
only explicitly mentions the relative paths. Thanks for clarifying
this.
I tried using the RequestDispatcher from ServletContext without Guice
(straight web.xml mapping) on Tomcat and it looks like it actually
wants all paths to start with a slash, it too serves relative to
context root.
On the other hand this is explicitly mentioned in the spec.
RequestDispatcher for ServletContext must start with a slash. I
thought Context and Request dispatcher are exclusive one is absolute
the other relative. But the latter is only complementary. Great.
WEB-INF is special in that it can't be access directly from the client
side but you're allowed to access it internally via a request
dispatcher.
Right. I've always thought there is somebody with a shotgun protecting
WEB-INF. I was wrong;)
I experimented with getServletContext().getRequestDispatcher() with
the Guice servlet adapter and it too doesn't work with forwards but
it's fine with include.
So the request dispatcher doesn't seem to
make a difference and stepping through the debug showed it was the
same problem with the servlet path reported by the server request
wrapper.
Got it! Squash! Like there is a saying Premature Optimization is the
root of all evil or something like that.
What happens is that the Wrapper caches the paths but when you forward
the paths in the original request are changed but the wrapper returns
the old cached path!
Quick fix is just to get rid of the Memoizer in ServletDefinition
lines 203+. Hope that helps.
Will take a closer look at this wrapper soon and maybe make a patch or
something.
I don't think that's the case. When I tried /test in my browser, it
did make a request for /test on the servlet side, sans final slash.
Never mind. What was I thinking? Nothing! Today it works as expected.
Must been some Heisenbug in the browser or something.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
google-guice group.
To post to this group, send email to google-guice@googlegroups.com
To unsubscribe from this group, send email to
google-guice+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~--~~~~--~~--~--~---
Re: Guice 2 SNAPSHOT: migrating from web.xml to ServletModule/GuiceFilter
Hey, thanks for the reply. I gave it a quick go (trunk build) and it to works with jsp out of the box but it is not perfect(calling include works but calling forward crashes). I am just using the snapshot build. You're doing req.getRequestDispatcher( /WEB-INF/jsp/test.jsp). I could be wrong but you are doing the request way your request is actually for /servlet//WEB-INF/jsp/test.jsp beside I think that request for WEB-INF/* should return 404 in any case. WEB-INF is private property. From my understanding, if I am using the dispatcher from ServletRequest, forwards and includes will be relative to the servlet path unless preceded by a slash. In that case, it's relative to context root, i.e. WebContent. At least this is how it works in Tomcat and WebSphere. I tried using the RequestDispatcher from ServletContext without Guice (straight web.xml mapping) on Tomcat and it looks like it actually wants all paths to start with a slash, it too serves relative to context root. WEB-INF is special in that it can't be access directly from the client side but you're allowed to access it internally via a request dispatcher. You can try @Inject ServletContext ctx; and doing ctx.getRequestDispatcher(/jsp/test.jsp) or properly use request way. I experimented with getServletContext().getRequestDispatcher() with the Guice servlet adapter and it too doesn't work with forwards but it's fine with include. So the request dispatcher doesn't seem to make a difference and stepping through the debug showed it was the same problem with the servlet path reported by the server request wrapper. I noticed serve( /test ).with( TestServlet.class ); If you try /test in the browser it will return 404 since the browser actually requests /test/ notice the trailing /. Try serve( /test/ ).with( TestServlet.class ) I don't think that's the case. When I tried /test in my browser, it did make a request for /test on the servlet side, sans final slash. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups google-guice group. To post to this group, send email to google-guice@googlegroups.com To unsubscribe from this group, send email to google-guice+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~--~~~~--~~--~--~---
