You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Louis Voo <jl...@yahoo.com> on 2009/08/14 18:05:00 UTC
LoggingInterceptor
HI,
I tried the LoggingInterceptor, it print
2009-08-14 16:26:02,062 INFO com.opensymphony.xwork2.interceptor.LoggingInterceptor.info:31 - Starting execution stack for action /louis/excludeParam/excludeParam
Is it possible to print the actual class name like this?
2009-08-14 16:26:02,078 DEBUG louis.demo.action.ExcludeParamAction.input:57 - Begining input
2009-08-14 16:26:02,078 DEBUG louis.demo.action.ExcludeParamAction.input:58 - End input
Thanks
Louis
RE: LoggingInterceptor
Posted by Martin Gainty <mg...@hotmail.com>.
as previously mentioned
MethodInterceptor != LoggingInterceptor
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Tue, 18 Aug 2009 07:16:33 -0700
> From: mailtolouis2020-struts@yahoo.com
> Subject: Re: LoggingInterceptor
> To: user@struts.apache.org
>
> Thanks Wes, I'm looking into it now.
>
>
>
> ________________________________
> From: Wes Wannemacher <we...@wantii.com>
> To: Struts Users Mailing List <us...@struts.apache.org>
> Sent: Tuesday, August 18, 2009 2:28:15 PM
> Subject: Re: LoggingInterceptor
>
> If you're using AOP, you'll need to tell spring to proxy classes using
> CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
> the cglib jars to your project and add the following to your
> applicationContext.xml ->
>
> <aop:config proxy-target-class="true" />
>
> -Wes
>
> On Tue, Aug 18, 2009 at 6:14 AM, <ma...@yahoo.com> wrote:
> > Ya, I'm tring Spring AOP as well, and facing some problem.
> >
> > If I AOP action class, some action when I run, I got this error, but some is running fine:
> >
> > Struts has detected an unhandled exception:
> > # Messages: $Proxy18.input1()
> > File: java/lang/Class.java
> > Line number: 1,605
> > Stacktraces
> > java.lang.NoSuchMethodException: $Proxy18.input1()
> >
> > java.lang.Class.getMethod(Class.java:1605)
> > org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.getActionMethod(AnnotationValidationInterceptor.java:75)
> > org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:47)
> > com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> > com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
> > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> > com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> > com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> > com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> > com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > java.lang.reflect.Method.invoke(Method.java:597)
> > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
> > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
> > com.iss.sandbox.louis.common.utils.LogInterceptor.invoke(LogInterceptor.java:67)
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> > $Proxy17.intercept(Unknown Source)
> >
> >
> >
> > Not sure what happen, but if I AOP service & dao classes, thats fine, but it print the interface name instead of the actual implement class name.
> > Here is part of my spring conf:
> >
> >
> >
> > <bean
> > class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
> > <property name="beanNames">
> > <list>
> > <value>*Action*</value>
> > <value>*Service*</value>
> > <value>*DAO*</value>
> > </list>
> > </property>
> > <property name="interceptorNames">
> > <list>
> > <value>logInterceptor</value>
> > </list>
> > </property>
> > </bean>
> >
> > And the LogInterceptor.java:
> > public class LogInterceptor implements MethodInterceptor {
> >
> > private static Log logger = LogFactory.getLog(LogInterceptor.class);
> >
> > /*
> > * (non-Javadoc)
> > *
> > * @see
> > * org.aopalliance.intercept.MethodInterceptor#invoke(org.aopalliance.intercept
> > * .MethodInvocation)
> > */
> > @Override
> > public Object invoke(MethodInvocation methodInvocation) throws Throwable {
> > if (logger.isDebugEnabled()) {
> > logger.debug("Beginning method: "
> > + methodInvocation.getMethod().getClass() + "::"
> > + methodInvocation.getMethod().getName());
> > }
> > try {
> > Object returnValue = methodInvocation.proceed();
> > return returnValue;
> > } finally {
> > if (logger.isDebugEnabled()) {
> > logger.debug("Finish execute "
> > + methodInvocation.getMethod().getDeclaringClass()
> > + "::" + methodInvocation.getMethod().getName());
> > }
> > }
> > }
> >
> > }
> >
> >
> > Print out:
> >
> > 2009-08-18 11:11:00,296 DEBUG louis.common.utils.LogInterceptor.invoke:62 - Beginning method: class java.lang.reflect.Method::execute
> > 2009-08-18 11:11:00,312 DEBUG louis.common.utils.LogInterceptor.invoke:71 - Finish execute interface com.opensymphony.xwork2.Action::execute
> >
> >
> >
> >
> > ________________________________
> > From: Dave Newton <ne...@yahoo.com>
> > To: Struts Users Mailing List <us...@struts.apache.org>
> > Sent: Monday, August 17, 2009 6:01:30 PM
> > Subject: Re: LoggingInterceptor
> >
> > mailtolouis2020-struts@yahoo.com wrote:
> >> We use to have this log statement in most of the method begin and end
> >> in Struts1, now working with S2+Spring, both are provide logging
> >> interceptor, so I wonder this can help me to reduce coding in new
> >> project.
> >
> > No; the logging interceptor does exactly what it says it does.
> >
> > General declarative entry/exit logging should be handled via AOP, for example using Spring.
> >
> > Dave
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.windowslive.com/Desktop/PhotoGallery
Re: LoggingInterceptor
Posted by ma...@yahoo.com.
Thanks Wes, I'm looking into it now.
________________________________
From: Wes Wannemacher <we...@wantii.com>
To: Struts Users Mailing List <us...@struts.apache.org>
Sent: Tuesday, August 18, 2009 2:28:15 PM
Subject: Re: LoggingInterceptor
If you're using AOP, you'll need to tell spring to proxy classes using
CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
the cglib jars to your project and add the following to your
applicationContext.xml ->
<aop:config proxy-target-class="true" />
-Wes
On Tue, Aug 18, 2009 at 6:14 AM, <ma...@yahoo.com> wrote:
> Ya, I'm tring Spring AOP as well, and facing some problem.
>
> If I AOP action class, some action when I run, I got this error, but some is running fine:
>
> Struts has detected an unhandled exception:
> # Messages: $Proxy18.input1()
> File: java/lang/Class.java
> Line number: 1,605
> Stacktraces
> java.lang.NoSuchMethodException: $Proxy18.input1()
>
> java.lang.Class.getMethod(Class.java:1605)
> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.getActionMethod(AnnotationValidationInterceptor.java:75)
> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:47)
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
> com.iss.sandbox.louis.common.utils.LogInterceptor.invoke(LogInterceptor.java:67)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> $Proxy17.intercept(Unknown Source)
>
>
>
> Not sure what happen, but if I AOP service & dao classes, thats fine, but it print the interface name instead of the actual implement class name.
> Here is part of my spring conf:
>
>
>
> <bean
> class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
> <property name="beanNames">
> <list>
> <value>*Action*</value>
> <value>*Service*</value>
> <value>*DAO*</value>
> </list>
> </property>
> <property name="interceptorNames">
> <list>
> <value>logInterceptor</value>
> </list>
> </property>
> </bean>
>
> And the LogInterceptor.java:
> public class LogInterceptor implements MethodInterceptor {
>
> private static Log logger = LogFactory.getLog(LogInterceptor.class);
>
> /*
> * (non-Javadoc)
> *
> * @see
> * org.aopalliance.intercept.MethodInterceptor#invoke(org.aopalliance.intercept
> * .MethodInvocation)
> */
> @Override
> public Object invoke(MethodInvocation methodInvocation) throws Throwable {
> if (logger.isDebugEnabled()) {
> logger.debug("Beginning method: "
> + methodInvocation.getMethod().getClass() + "::"
> + methodInvocation.getMethod().getName());
> }
> try {
> Object returnValue = methodInvocation.proceed();
> return returnValue;
> } finally {
> if (logger.isDebugEnabled()) {
> logger.debug("Finish execute "
> + methodInvocation.getMethod().getDeclaringClass()
> + "::" + methodInvocation.getMethod().getName());
> }
> }
> }
>
> }
>
>
> Print out:
>
> 2009-08-18 11:11:00,296 DEBUG louis.common.utils.LogInterceptor.invoke:62 - Beginning method: class java.lang.reflect.Method::execute
> 2009-08-18 11:11:00,312 DEBUG louis.common.utils.LogInterceptor.invoke:71 - Finish execute interface com.opensymphony.xwork2.Action::execute
>
>
>
>
> ________________________________
> From: Dave Newton <ne...@yahoo.com>
> To: Struts Users Mailing List <us...@struts.apache.org>
> Sent: Monday, August 17, 2009 6:01:30 PM
> Subject: Re: LoggingInterceptor
>
> mailtolouis2020-struts@yahoo.com wrote:
>> We use to have this log statement in most of the method begin and end
>> in Struts1, now working with S2+Spring, both are provide logging
>> interceptor, so I wonder this can help me to reduce coding in new
>> project.
>
> No; the logging interceptor does exactly what it says it does.
>
> General declarative entry/exit logging should be handled via AOP, for example using Spring.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] Re: LoggingInterceptor
Posted by Dale Newfield <da...@newfield.org>.
Wes Wannemacher wrote:
> Dale, honestly, I was being lazy and giving him the "quick" solution
> to his problem.
Thanks for the more complete (mostly elided) exposition, then.
> Most people don't really look into what spring is doing behind the
> scenes
I'm so frustrated with the acegi -> spring security upgrade that I've
been unable to successfully complete after 2+ days of effort I'm almost
ready to punt the whole thing. I agree that technology is great when it
works...
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by ma...@yahoo.com.
Thanks Dale & Wes for some more education. I agree with Wes, there is no point for me to use inteface based proxy for this logging funtion, otherwise that will be increase coding and make thing complicated.
Perhaps, if you guys come across this kind of logging component for spring and which is open source, pls let me know, I'll be much appreciate it. Meanwhile, I'm googleing it....
ps: I think I still got some setting problem somewhere, cos after using <aop:config proxy-target-class="true" />, I still getting same error, will chk out from spring forum.
Louis
________________________________
From: Wes Wannemacher <we...@wantii.com>
To: Struts Users Mailing List <us...@struts.apache.org>
Sent: Tuesday, August 18, 2009 3:29:26 PM
Subject: Re: LoggingInterceptor
Dale, honestly, I was being lazy and giving him the "quick" solution
to his problem. The thing about that error is that it is pretty
obvious what needs to be done, if you're versed in the arts of proxy
class generation. Most people don't really look into what spring is
doing behind the scenes, they are just happy that they get the service
implementation they specify. In this case, spring recognizes that the
class needs intercepted via AOP so it proxies it, but as you
mentioned, since the spring default is to use JDK proxies, only
methods inherited from from an interface will be exposed
(limitation/feature [toemaytoe/toemahtoe] of jdk proxies).
IMO, choosing jdk over cglib or vice versa is pretty much a coin
toss... You could argue the technical merit and the value of the
requiring interfaces to be implemented. But, to me, it really comes
down to the fact that none of that really matters since you are simply
asking spring to choose one or the other. Maybe JDK proxies are a
better design choice, but you don't really have any say as to how
Spring designs/implements the proxies... The Spring code could be
really bad for all we know. So, I just treat it like a black box, if I
am trying to intercept action method invocations, I just let spring
use CGLIB because I am aware of the limitation/feature of JDK proxies.
Creating an interface that exposes the 'input1' method in his case
sort of defeats the purpose of using AOP... I mean, if you have to
change your code to use AOP, why not just change the code to execute
the logic you want?
-Wes
On Tue, Aug 18, 2009 at 10:00 AM, Dale Newfield<da...@newfield.org> wrote:
> Wes Wannemacher wrote:
>>
>> If you're using AOP, you'll need to tell spring to proxy classes using
>> CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
>> the cglib jars to your project and add the following to your
>> applicationContext.xml ->
>>
>> <aop:config proxy-target-class="true" />
>
> http://static.springsource.org/spring/docs/2.0.x/reference/aop-api.html#aop-pfb-proxy-types
>
> I understand if the OP has methods in the implementation that are not in the
> interface that the interface based proxy won't have those methods.
>
> I'm unclear, though, whether your advice is a general suggestion, or just to
> solve this specific problem (without the (IMHO) more advisable solution of
> adding input1() to the implemented interface). Without the OP's problems, I
> don't understand what the benefit of having the auto-generated proxies
> extend the class rather than implement the same interfaces would be. It
> seems that there are many more pitfalls (with private/protected, whether or
> not the proxy calls super() methods (before then calling them on the wrapped
> bean), etc.) with this solution, no?
>
> Sorry to ask spring questions on a struts list, but I'm just trying to
> understand the already proffered advice.
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: LoggingInterceptor
Posted by Martin Gainty <mg...@hotmail.com>.
i would substitute 'powerful' for 'bad'
the idea of advised methods is to allow AOP advised methods to be introduced to the class e.g. 'logging'
JDKProxy vs CGLIB debate:
JDKProxy implements functionality thru interfaces
CGLIB
The proxies are created by sub-classing the actual class. This
means wherever an instance of the class is used it is also possible to
use the CGLib proxy.
The class needs to provide a default
constructor, i.e. without any arguments. Otherwise you'll get an
IllegalArgumentException: "Superclass has no null constructors but no
arguments were given." This makes constructor injection impossible.
The proxying does not work with final methods since the proxy sub class can not override the class' implementation.
The
CGLib proxy is final, so proxying a proxy does not work. You will get
an IllegalArgumentException saying "Cannot subclass final class
$Proxy0". But this feature is usually not needed anyway. (This issue might be solved in the future.)
Since
two objects are created (the instance of the class and the proxy as
instance of a sub class) the constructor is called twice. In general
this should not matter. I consider changing the class' state based on
constructor calls a code smell anyway.
You have CGLib as additional dependency.
based on what i see it is difficult to characterise CGLIB proxy implementation as 'lazy'
http://insufficientinformation.blogspot.com/2007/12/spring-dynamic-proxies-vs-cglib-proxies.html
Does this not conform to your understanding?
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Tue, 18 Aug 2009 10:29:26 -0400
> Subject: Re: LoggingInterceptor
> From: wesw@wantii.com
> To: user@struts.apache.org
>
> Dale, honestly, I was being lazy and giving him the "quick" solution
> to his problem. The thing about that error is that it is pretty
> obvious what needs to be done, if you're versed in the arts of proxy
> class generation. Most people don't really look into what spring is
> doing behind the scenes, they are just happy that they get the service
> implementation they specify. In this case, spring recognizes that the
> class needs intercepted via AOP so it proxies it, but as you
> mentioned, since the spring default is to use JDK proxies, only
> methods inherited from from an interface will be exposed
> (limitation/feature [toemaytoe/toemahtoe] of jdk proxies).
>
> IMO, choosing jdk over cglib or vice versa is pretty much a coin
> toss... You could argue the technical merit and the value of the
> requiring interfaces to be implemented. But, to me, it really comes
> down to the fact that none of that really matters since you are simply
> asking spring to choose one or the other. Maybe JDK proxies are a
> better design choice, but you don't really have any say as to how
> Spring designs/implements the proxies... The Spring code could be
> really bad for all we know. So, I just treat it like a black box, if I
> am trying to intercept action method invocations, I just let spring
> use CGLIB because I am aware of the limitation/feature of JDK proxies.
> Creating an interface that exposes the 'input1' method in his case
> sort of defeats the purpose of using AOP... I mean, if you have to
> change your code to use AOP, why not just change the code to execute
> the logic you want?
>
> -Wes
>
> On Tue, Aug 18, 2009 at 10:00 AM, Dale Newfield<da...@newfield.org> wrote:
> > Wes Wannemacher wrote:
> >>
> >> If you're using AOP, you'll need to tell spring to proxy classes using
> >> CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
> >> the cglib jars to your project and add the following to your
> >> applicationContext.xml ->
> >>
> >> <aop:config proxy-target-class="true" />
> >
> > http://static.springsource.org/spring/docs/2.0.x/reference/aop-api.html#aop-pfb-proxy-types
> >
> > I understand if the OP has methods in the implementation that are not in the
> > interface that the interface based proxy won't have those methods.
> >
> > I'm unclear, though, whether your advice is a general suggestion, or just to
> > solve this specific problem (without the (IMHO) more advisable solution of
> > adding input1() to the implemented interface). Without the OP's problems, I
> > don't understand what the benefit of having the auto-generated proxies
> > extend the class rather than implement the same interfaces would be. It
> > seems that there are many more pitfalls (with private/protected, whether or
> > not the proxy calls super() methods (before then calling them on the wrapped
> > bean), etc.) with this solution, no?
> >
> > Sorry to ask spring questions on a struts list, but I'm just trying to
> > understand the already proffered advice.
> >
> > -Dale
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009
Re: LoggingInterceptor
Posted by Wes Wannemacher <we...@wantii.com>.
Dale, honestly, I was being lazy and giving him the "quick" solution
to his problem. The thing about that error is that it is pretty
obvious what needs to be done, if you're versed in the arts of proxy
class generation. Most people don't really look into what spring is
doing behind the scenes, they are just happy that they get the service
implementation they specify. In this case, spring recognizes that the
class needs intercepted via AOP so it proxies it, but as you
mentioned, since the spring default is to use JDK proxies, only
methods inherited from from an interface will be exposed
(limitation/feature [toemaytoe/toemahtoe] of jdk proxies).
IMO, choosing jdk over cglib or vice versa is pretty much a coin
toss... You could argue the technical merit and the value of the
requiring interfaces to be implemented. But, to me, it really comes
down to the fact that none of that really matters since you are simply
asking spring to choose one or the other. Maybe JDK proxies are a
better design choice, but you don't really have any say as to how
Spring designs/implements the proxies... The Spring code could be
really bad for all we know. So, I just treat it like a black box, if I
am trying to intercept action method invocations, I just let spring
use CGLIB because I am aware of the limitation/feature of JDK proxies.
Creating an interface that exposes the 'input1' method in his case
sort of defeats the purpose of using AOP... I mean, if you have to
change your code to use AOP, why not just change the code to execute
the logic you want?
-Wes
On Tue, Aug 18, 2009 at 10:00 AM, Dale Newfield<da...@newfield.org> wrote:
> Wes Wannemacher wrote:
>>
>> If you're using AOP, you'll need to tell spring to proxy classes using
>> CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
>> the cglib jars to your project and add the following to your
>> applicationContext.xml ->
>>
>> <aop:config proxy-target-class="true" />
>
> http://static.springsource.org/spring/docs/2.0.x/reference/aop-api.html#aop-pfb-proxy-types
>
> I understand if the OP has methods in the implementation that are not in the
> interface that the interface based proxy won't have those methods.
>
> I'm unclear, though, whether your advice is a general suggestion, or just to
> solve this specific problem (without the (IMHO) more advisable solution of
> adding input1() to the implemented interface). Without the OP's problems, I
> don't understand what the benefit of having the auto-generated proxies
> extend the class rather than implement the same interfaces would be. It
> seems that there are many more pitfalls (with private/protected, whether or
> not the proxy calls super() methods (before then calling them on the wrapped
> bean), etc.) with this solution, no?
>
> Sorry to ask spring questions on a struts list, but I'm just trying to
> understand the already proffered advice.
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by Dale Newfield <da...@newfield.org>.
Wes Wannemacher wrote:
> If you're using AOP, you'll need to tell spring to proxy classes using
> CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
> the cglib jars to your project and add the following to your
> applicationContext.xml ->
>
> <aop:config proxy-target-class="true" />
http://static.springsource.org/spring/docs/2.0.x/reference/aop-api.html#aop-pfb-proxy-types
I understand if the OP has methods in the implementation that are not in
the interface that the interface based proxy won't have those methods.
I'm unclear, though, whether your advice is a general suggestion, or
just to solve this specific problem (without the (IMHO) more advisable
solution of adding input1() to the implemented interface). Without the
OP's problems, I don't understand what the benefit of having the
auto-generated proxies extend the class rather than implement the same
interfaces would be. It seems that there are many more pitfalls (with
private/protected, whether or not the proxy calls super() methods
(before then calling them on the wrapped bean), etc.) with this
solution, no?
Sorry to ask spring questions on a struts list, but I'm just trying to
understand the already proffered advice.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by Wes Wannemacher <we...@wantii.com>.
If you're using AOP, you'll need to tell spring to proxy classes using
CGLIB rather than dynamic JDK proxies... To do so, you'll have to add
the cglib jars to your project and add the following to your
applicationContext.xml ->
<aop:config proxy-target-class="true" />
-Wes
On Tue, Aug 18, 2009 at 6:14 AM, <ma...@yahoo.com> wrote:
> Ya, I'm tring Spring AOP as well, and facing some problem.
>
> If I AOP action class, some action when I run, I got this error, but some is running fine:
>
> Struts has detected an unhandled exception:
> # Messages: $Proxy18.input1()
> File: java/lang/Class.java
> Line number: 1,605
> Stacktraces
> java.lang.NoSuchMethodException: $Proxy18.input1()
>
> java.lang.Class.getMethod(Class.java:1605)
> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.getActionMethod(AnnotationValidationInterceptor.java:75)
> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:47)
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
> com.iss.sandbox.louis.common.utils.LogInterceptor.invoke(LogInterceptor.java:67)
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> $Proxy17.intercept(Unknown Source)
>
>
>
> Not sure what happen, but if I AOP service & dao classes, thats fine, but it print the interface name instead of the actual implement class name.
> Here is part of my spring conf:
>
>
>
> <bean
> class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
> <property name="beanNames">
> <list>
> <value>*Action*</value>
> <value>*Service*</value>
> <value>*DAO*</value>
> </list>
> </property>
> <property name="interceptorNames">
> <list>
> <value>logInterceptor</value>
> </list>
> </property>
> </bean>
>
> And the LogInterceptor.java:
> public class LogInterceptor implements MethodInterceptor {
>
> private static Log logger = LogFactory.getLog(LogInterceptor.class);
>
> /*
> * (non-Javadoc)
> *
> * @see
> * org.aopalliance.intercept.MethodInterceptor#invoke(org.aopalliance.intercept
> * .MethodInvocation)
> */
> @Override
> public Object invoke(MethodInvocation methodInvocation) throws Throwable {
> if (logger.isDebugEnabled()) {
> logger.debug("Beginning method: "
> + methodInvocation.getMethod().getClass() + "::"
> + methodInvocation.getMethod().getName());
> }
> try {
> Object returnValue = methodInvocation.proceed();
> return returnValue;
> } finally {
> if (logger.isDebugEnabled()) {
> logger.debug("Finish execute "
> + methodInvocation.getMethod().getDeclaringClass()
> + "::" + methodInvocation.getMethod().getName());
> }
> }
> }
>
> }
>
>
> Print out:
>
> 2009-08-18 11:11:00,296 DEBUG louis.common.utils.LogInterceptor.invoke:62 - Beginning method: class java.lang.reflect.Method::execute
> 2009-08-18 11:11:00,312 DEBUG louis.common.utils.LogInterceptor.invoke:71 - Finish execute interface com.opensymphony.xwork2.Action::execute
>
>
>
>
> ________________________________
> From: Dave Newton <ne...@yahoo.com>
> To: Struts Users Mailing List <us...@struts.apache.org>
> Sent: Monday, August 17, 2009 6:01:30 PM
> Subject: Re: LoggingInterceptor
>
> mailtolouis2020-struts@yahoo.com wrote:
>> We use to have this log statement in most of the method begin and end
>> in Struts1, now working with S2+Spring, both are provide logging
>> interceptor, so I wonder this can help me to reduce coding in new
>> project.
>
> No; the logging interceptor does exactly what it says it does.
>
> General declarative entry/exit logging should be handled via AOP, for example using Spring.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by ma...@yahoo.com.
Ya, I'm tring Spring AOP as well, and facing some problem.
If I AOP action class, some action when I run, I got this error, but some is running fine:
Struts has detected an unhandled exception:
# Messages: $Proxy18.input1()
File: java/lang/Class.java
Line number: 1,605
Stacktraces
java.lang.NoSuchMethodException: $Proxy18.input1()
java.lang.Class.getMethod(Class.java:1605)
org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.getActionMethod(AnnotationValidationInterceptor.java:75)
org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:47)
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
com.iss.sandbox.louis.common.utils.LogInterceptor.invoke(LogInterceptor.java:67)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
$Proxy17.intercept(Unknown Source)
Not sure what happen, but if I AOP service & dao classes, thats fine, but it print the interface name instead of the actual implement class name.
Here is part of my spring conf:
<bean
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>*Action*</value>
<value>*Service*</value>
<value>*DAO*</value>
</list>
</property>
<property name="interceptorNames">
<list>
<value>logInterceptor</value>
</list>
</property>
</bean>
And the LogInterceptor.java:
public class LogInterceptor implements MethodInterceptor {
private static Log logger = LogFactory.getLog(LogInterceptor.class);
/*
* (non-Javadoc)
*
* @see
* org.aopalliance.intercept.MethodInterceptor#invoke(org.aopalliance.intercept
* .MethodInvocation)
*/
@Override
public Object invoke(MethodInvocation methodInvocation) throws Throwable {
if (logger.isDebugEnabled()) {
logger.debug("Beginning method: "
+ methodInvocation.getMethod().getClass() + "::"
+ methodInvocation.getMethod().getName());
}
try {
Object returnValue = methodInvocation.proceed();
return returnValue;
} finally {
if (logger.isDebugEnabled()) {
logger.debug("Finish execute "
+ methodInvocation.getMethod().getDeclaringClass()
+ "::" + methodInvocation.getMethod().getName());
}
}
}
}
Print out:
2009-08-18 11:11:00,296 DEBUG louis.common.utils.LogInterceptor.invoke:62 - Beginning method: class java.lang.reflect.Method::execute
2009-08-18 11:11:00,312 DEBUG louis.common.utils.LogInterceptor.invoke:71 - Finish execute interface com.opensymphony.xwork2.Action::execute
________________________________
From: Dave Newton <ne...@yahoo.com>
To: Struts Users Mailing List <us...@struts.apache.org>
Sent: Monday, August 17, 2009 6:01:30 PM
Subject: Re: LoggingInterceptor
mailtolouis2020-struts@yahoo.com wrote:
> We use to have this log statement in most of the method begin and end
> in Struts1, now working with S2+Spring, both are provide logging
> interceptor, so I wonder this can help me to reduce coding in new
> project.
No; the logging interceptor does exactly what it says it does.
General declarative entry/exit logging should be handled via AOP, for example using Spring.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by Dave Newton <ne...@yahoo.com>.
mailtolouis2020-struts@yahoo.com wrote:
> We use to have this log statement in most of the method begin and end
> in Struts1, now working with S2+Spring, both are provide logging
> interceptor, so I wonder this can help me to reduce coding in new
> project.
No; the logging interceptor does exactly what it says it does.
General declarative entry/exit logging should be handled via AOP, for
example using Spring.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by ma...@yahoo.com.
Hi Dave,
We use to have this log statement in most of the method begin and end in Struts1, now working with S2+Spring, both are provide logging interceptor, so I wonder this can help me to reduce coding in new project.
I tried that on S2 and Spring, both not giving the result I want, so thinking is there anyway to achieve it or not, if not then I won't waste time research on this topic, still got a lot to explore on S2.
Louis
________________________________
From: Dave Newton <ne...@yahoo.com>
To: Struts Users Mailing List <us...@struts.apache.org>
Sent: Monday, August 17, 2009 3:51:47 PM
Subject: Re: LoggingInterceptor
mailtolouis2020-struts@yahoo.com wrote:
> Yes, thats the log from my classes. I'm trying to achive similar kind
> of log, or at least print the exact class and method name, instead of
> the namespace and the alias name of the action.
>
> Is it possible to do that?
...
I'm confused.
If you have log statements inside your class that are printing the class and method name, what's the problem?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by Dave Newton <ne...@yahoo.com>.
mailtolouis2020-struts@yahoo.com wrote:
> Yes, thats the log from my classes. I'm trying to achive similar kind
> of log, or at least print the exact class and method name, instead of
> the namespace and the alias name of the action.
>
> Is it possible to do that?
...
I'm confused.
If you have log statements inside your class that are printing the class
and method name, what's the problem?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by ma...@yahoo.com.
Yes, thats the log from my classes. I'm trying to achive similar kind of log, or at least print the exact class and method name, instead of the namespace and the alias name of the action.
Is it possible to do that?
Louis
________________________________
From: Dave Newton <ne...@yahoo.com>
To: Struts Users Mailing List <us...@struts.apache.org>
Sent: Saturday, August 15, 2009 6:54:01 PM
Subject: Re: LoggingInterceptor
Louis Voo wrote:
> I tried the LoggingInterceptor, it print
>
> 2009-08-14 16:26:02,062 INFO com.opensymphony.xwork2.interceptor.LoggingInterceptor.info:31 - Starting execution stack for action /louis/excludeParam/excludeParam
>
> Is it possible to print the actual class name like this?
>
> 2009-08-14 16:26:02,078 DEBUG louis.demo.action.ExcludeParamAction.input:57 - Begining input
> 2009-08-14 16:26:02,078 DEBUG louis.demo.action.ExcludeParamAction.input:58 - End input
That would come from log statements in /your/ classes. The logging interceptor just wraps action execution in log statements.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: LoggingInterceptor
Posted by Dave Newton <ne...@yahoo.com>.
Louis Voo wrote:
> I tried the LoggingInterceptor, it print
>
> 2009-08-14 16:26:02,062 INFO com.opensymphony.xwork2.interceptor.LoggingInterceptor.info:31 - Starting execution stack for action /louis/excludeParam/excludeParam
>
> Is it possible to print the actual class name like this?
>
> 2009-08-14 16:26:02,078 DEBUG louis.demo.action.ExcludeParamAction.input:57 - Begining input
> 2009-08-14 16:26:02,078 DEBUG louis.demo.action.ExcludeParamAction.input:58 - End input
That would come from log statements in /your/ classes. The logging
interceptor just wraps action execution in log statements.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org