You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2009/08/06 06:22:35 UTC
Re: [Tapestry IOC] Interfaces could be more complete -
MethodAdviceReceiver and Invocation
It might be possible to advise the interface. When advising, you may
be layering advice upon a proxy to the service, in which case the
service interface is the best that is known.
The latter case applies to advising a service that has a different
scope than the default, singleton.
On Wed, Aug 5, 2009 at 1:59 PM, Sebastian
Hennebrueder<us...@laliluna.de> wrote:
> Hello,
>
> I am using an advice to add a method based security. While implementing it,
> I were missing access to the advised classes.
>
> The MethodAdviceReceiver interface has no notion about the advised class. As
> a consequence, I can only check the interface not the implementation for
> the annotation @Procteded
>
> See my sample to get an idea, why I would like to read the advised class.
>
> @Match("*Service")
> public static void adviseNonNull(MethodAdviceReceiver receiver) {
> final Logger logger = LoggerFactory.getLogger(AppModule.class);
>
> SecurityServiceImpl service = new SecurityServiceImpl();
>
> for (Method m : receiver.getInterface().getMethods()) {
> Protected annotation = m.getAnnotation(Protected.class);
> if (annotation != null && annotation.rights() != null) {
> MethodSecurityAdvice advice = new
> MethodSecurityAdvice(service, annotation.rights());
> receiver.adviseMethod(m, advice);
> logger.debug("Protecting method {} with rights {}",
> m.getName(), annotation.rights());
> }
> }
> }
>
> The same information is missing in the advise itself. The interface
> Invocation provides no access to the delegate. As a consequence, I cannot
> log which service class blocked the access.
> Once again the code
>
> public void advise(Invocation invocation) {
> ApplicationUser user = securityService.getUser();
>
> boolean hasRight = false;
> if (user != null) {
> for (String right : rights) {
> if (user.hasRight(right)) {
> hasRight = true;
> break;
> }
> }
> }
> if (hasRight)
> invocation.proceed();
> else
> throw new NotAuthorizedException("You are not allowed
> to access " + invocation.getMethodName());
>
> }
>
>
> --
> Best Regards / Viele Grüße
>
> Sebastian Hennebrueder
> -----
> Software Developer and Trainer for Hibernate / Java Persistence
> http://www.laliluna.de
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry IOC] Interfaces could be more complete -
MethodAdviceReceiver and Invocation
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 06 Aug 2009 04:32:04 -0300, Sebastian Hennebrueder
<us...@laliluna.de> escreveu:
> Hmm,
> in that case a getDelegate method could return null or the Proxy or ask
> the proxy for getDelegate.
+1 to that. Annotation-driven decoration/advising is severely impaired
without getting access to the service implemention class and method
annotations.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry IOC] Interfaces could be more complete - MethodAdviceReceiver
and Invocation
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
Hmm,
in that case a getDelegate method could return null or the Proxy or ask
the proxy for getDelegate.
Howard Lewis Ship schrieb:
> It might be possible to advise the interface. When advising, you may
> be layering advice upon a proxy to the service, in which case the
> service interface is the best that is known.
>
> The latter case applies to advising a service that has a different
> scope than the default, singleton.
>
> On Wed, Aug 5, 2009 at 1:59 PM, Sebastian
> Hennebrueder<us...@laliluna.de> wrote:
>> Hello,
>>
>> I am using an advice to add a method based security. While implementing it,
>> I were missing access to the advised classes.
>>
>> The MethodAdviceReceiver interface has no notion about the advised class. As
>> a consequence, I can only check the interface not the implementation for
>> the annotation @Procteded
>>
>> See my sample to get an idea, why I would like to read the advised class.
>>
>> @Match("*Service")
>> public static void adviseNonNull(MethodAdviceReceiver receiver) {
>> final Logger logger = LoggerFactory.getLogger(AppModule.class);
>>
>> SecurityServiceImpl service = new SecurityServiceImpl();
>>
>> for (Method m : receiver.getInterface().getMethods()) {
>> Protected annotation = m.getAnnotation(Protected.class);
>> if (annotation != null && annotation.rights() != null) {
>> MethodSecurityAdvice advice = new
>> MethodSecurityAdvice(service, annotation.rights());
>> receiver.adviseMethod(m, advice);
>> logger.debug("Protecting method {} with rights {}",
>> m.getName(), annotation.rights());
>> }
>> }
>> }
>>
>> The same information is missing in the advise itself. The interface
>> Invocation provides no access to the delegate. As a consequence, I cannot
>> log which service class blocked the access.
>> Once again the code
>>
>> public void advise(Invocation invocation) {
>> ApplicationUser user = securityService.getUser();
>>
>> boolean hasRight = false;
>> if (user != null) {
>> for (String right : rights) {
>> if (user.hasRight(right)) {
>> hasRight = true;
>> break;
>> }
>> }
>> }
>> if (hasRight)
>> invocation.proceed();
>> else
>> throw new NotAuthorizedException("You are not allowed
>> to access " + invocation.getMethodName());
>>
>> }
>>
>>
>> --
>> Best Regards / Viele Grüße
>>
>> Sebastian Hennebrueder
>> -----
>> Software Developer and Trainer for Hibernate / Java Persistence
>> http://www.laliluna.de
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org