Re: Can we use the decorator pattern in Actions?
2012/10/3 Miguel Almeida :
> I was speaking with Lukasz today about this, so I'm resurrecting this
> old thread.
>
> The underlying question in my (rather extensive) post is:
>
> How can you perform the following decorator pattern:
>
> public OriginalAction implements Preparable,
> SessionAware,OriginalActionInterface{
>
> public String someFunctionality(){
>
> }
> }
>
> Decorate like:
>
> public DecoratedAction implements Preparable, SessionAware,etc{
> private OriginalActionInterface originalAction; //inject
> OriginalAction here
> @Secured
> public String someFunctionality(){
> // do new stuff
> orignalAction.someFunctionality();
> }
> }
>
> Issues:
> 1) Your OriginalAction will probably rely on some objects injected by
> struts (eg: session will probably be used). However, because
> OriginalAction is now only decorating DecoratedAction...those objects
> won't be automatically populated by Struts.
>
>
> The only way I see it is to use Spring IoC to define these needed
> objects in OriginalAction. But it would be neat if that was performed by
> Struts.
>
> What are your thoughts on this?
>
>
> Miguel Almeida
>
>
> On Wed, 2012-05-16 at 11:22 +0100, Miguel Almeida wrote:
>
>> Imagine the scenario where you have security implemented at the action
>> method level with an annotation:
>>
>> @Secured("someRole") restricts that action to that role (and it is
>> checked with an interceptor).
>>
>> Discussing this on the TDD mailing list a while back, a decorator
>> approach was suggested
>>
>> To separate concerns and ease up testing, authorization is implemented
>> as a decorator (a-la GoF decorator pattern) adding authorization to the
>> underlying (decorated) MVC app.
>>
>> The technique to getting there (see pseudo code in [1])
>> 1. Extract an interface from your main class with all the public methods
>> 2. Implement a decorator which adds authorization rules to a decorated
>> underlying object. The decorator implements the authorization rules
>> using annotations
>> 3. in your tests, test the decorator providing a mock underlying
>> decorated object, asserting in each test that given a request with a
>> user that has certain roles the underlying method should or should not
>> be called.
>>
>>
>> As you see, tests would have a simple setup as you wouldn't be calling
>> "the real, possible complicated action code", but the fake decorated
>> one.
>> The problem arises when you have superclasses (and maybe also when you
>> implement interfaces). I exemplify with both.
>>
>> Imagine this:
>> RealAction extends CommonAction implements IAction(){
>> ...}
>>
>> CommonAction implements ServletRequestAware(){
>> ...
>> }
>>
>> AuthorizingDecorator implements IAction(){
>> //injected decorated IAction, see [1]
>> ...
>> }
>>
>> Now, on a regular RealAction implementation, the request object exists:
>> RealAction extends CommonAction, so the request is injected through its
>> ServletRequestAware.
>> If you're using the AuthorizingDecorator, however, the request will be
>> null: RealAction will be injected, so Struts won't kick in to populate
>> RealAction's request object.
>>
>>
>> My question is: how would you go on and solve this? Or is the decorator
>> approach impractical in Struts? I haven't even consider the necessity to
>> implement every getter/setter on the IAction, which would also make this
>> approach a bit cumbersome. The simplicity for testing, however, is
>> great!
>>
>> Cheers,
>>
>> Miguel Almeida
>>
>>
>> [1] The code might end up like this (semi-pseudo code)
>>
>> Tests:
>>
>> test_admin_can_call_method_a()
>>
>> {
>> // setup a fake request with admin role:
>> httpRequest = buildRequestWithRole("admin");
>>
>> // setup a mock app decorated with an authorzation decorator:
>> MockApp app = new MockApp();
>> AuthorizationDecorator authorizer = new
>> AuthorizationDecorator(app);
>>
>> // act - try calling method A in the decorator:
>> authorizer.MethodA(httpRequest);
>>
>> // assert - underlaying method a should have been called:
>> Assert(app.MethodA.WasCalled==true);
>>
>> }
>>
>> test_regularUser_cannot_call_method_a()
>> {
>>
>> // setup a fake request with regular user role:
>> httpRequest = buildRequestWithRole("regular user");
>>
>> // setup a mock app decorated with an authorzation decorator:
>> MockApp app = new MockApp();
>> AuthorizationDecorator authorizer = new
>> AuthorizationDecorator(app);
>>
>> // act - try calling method A in the decorator:
>> authorizer.MethodA(httpRequest);
>>
>> // assert - underlaying method a should not have been called:
>> Assert(app.MethodA.WasCalled==false);
>>
>> }
>>
>> In the SUT:
>>
>> interface IAction
>> {
>>
>> String MethodA()
>> String MethodB()
>> ...
>>
>> }
>>
>> // this is the real action implementing methodA, methodB etc
>> cla
Re: overriding framework components
2012/10/3 Davis, Chad : > Ok. I found it in the javadoc for TextProvider > > class="com.mycompany.struts2.MyTextProviderSupport" scope="default"/> > > > This works. Here you have the full list of extension points http://struts.apache.org/2.x/docs/plugins.html#Plugins-ExtensionPoints Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Can we use the decorator pattern in Actions?
If this is a recurring functionality (that is, you use it on several
actions), then implementing it as an interceptor makes perfect sense.
http://struts.apache.org/2.3.4.1/docs/writing-interceptors.html
Gabriel
2012/10/3 Miguel Almeida :
> I was speaking with Lukasz today about this, so I'm resurrecting this
> old thread.
>
> The underlying question in my (rather extensive) post is:
>
> How can you perform the following decorator pattern:
>
> public OriginalAction implements Preparable,
> SessionAware,OriginalActionInterface{
>
> public String someFunctionality(){
>
> }
> }
>
> Decorate like:
>
> public DecoratedAction implements Preparable, SessionAware,etc{
> private OriginalActionInterface originalAction; //inject
> OriginalAction here
> @Secured
> public String someFunctionality(){
> // do new stuff
> orignalAction.someFunctionality();
> }
> }
>
> Issues:
> 1) Your OriginalAction will probably rely on some objects injected by
> struts (eg: session will probably be used). However, because
> OriginalAction is now only decorating DecoratedAction...those objects
> won't be automatically populated by Struts.
>
>
> The only way I see it is to use Spring IoC to define these needed
> objects in OriginalAction. But it would be neat if that was performed by
> Struts.
>
> What are your thoughts on this?
>
>
> Miguel Almeida
>
>
> On Wed, 2012-05-16 at 11:22 +0100, Miguel Almeida wrote:
>
>> Imagine the scenario where you have security implemented at the action
>> method level with an annotation:
>>
>> @Secured("someRole") restricts that action to that role (and it is
>> checked with an interceptor).
>>
>> Discussing this on the TDD mailing list a while back, a decorator
>> approach was suggested
>>
>> To separate concerns and ease up testing, authorization is implemented
>> as a decorator (a-la GoF decorator pattern) adding authorization to the
>> underlying (decorated) MVC app.
>>
>> The technique to getting there (see pseudo code in [1])
>> 1. Extract an interface from your main class with all the public methods
>> 2. Implement a decorator which adds authorization rules to a decorated
>> underlying object. The decorator implements the authorization rules
>> using annotations
>> 3. in your tests, test the decorator providing a mock underlying
>> decorated object, asserting in each test that given a request with a
>> user that has certain roles the underlying method should or should not
>> be called.
>>
>>
>> As you see, tests would have a simple setup as you wouldn't be calling
>> "the real, possible complicated action code", but the fake decorated
>> one.
>> The problem arises when you have superclasses (and maybe also when you
>> implement interfaces). I exemplify with both.
>>
>> Imagine this:
>> RealAction extends CommonAction implements IAction(){
>> ...}
>>
>> CommonAction implements ServletRequestAware(){
>> ...
>> }
>>
>> AuthorizingDecorator implements IAction(){
>> //injected decorated IAction, see [1]
>> ...
>> }
>>
>> Now, on a regular RealAction implementation, the request object exists:
>> RealAction extends CommonAction, so the request is injected through its
>> ServletRequestAware.
>> If you're using the AuthorizingDecorator, however, the request will be
>> null: RealAction will be injected, so Struts won't kick in to populate
>> RealAction's request object.
>>
>>
>> My question is: how would you go on and solve this? Or is the decorator
>> approach impractical in Struts? I haven't even consider the necessity to
>> implement every getter/setter on the IAction, which would also make this
>> approach a bit cumbersome. The simplicity for testing, however, is
>> great!
>>
>> Cheers,
>>
>> Miguel Almeida
>>
>>
>> [1] The code might end up like this (semi-pseudo code)
>>
>> Tests:
>>
>> test_admin_can_call_method_a()
>>
>> {
>> // setup a fake request with admin role:
>> httpRequest = buildRequestWithRole("admin");
>>
>> // setup a mock app decorated with an authorzation decorator:
>> MockApp app = new MockApp();
>> AuthorizationDecorator authorizer = new
>> AuthorizationDecorator(app);
>>
>> // act - try calling method A in the decorator:
>> authorizer.MethodA(httpRequest);
>>
>> // assert - underlaying method a should have been called:
>> Assert(app.MethodA.WasCalled==true);
>>
>> }
>>
>> test_regularUser_cannot_call_method_a()
>> {
>>
>> // setup a fake request with regular user role:
>> httpRequest = buildRequestWithRole("regular user");
>>
>> // setup a mock app decorated with an authorzation decorator:
>> MockApp app = new MockApp();
>> AuthorizationDecorator authorizer = new
>> AuthorizationDecorator(app);
>>
>> // act - try calling method A in the decorator:
>> authorizer.MethodA(httpRequest);
>>
>> // assert - underlaying method a should not have been called:
>> Assert(app.MethodA.WasCalled==fals
Re: Struts2 authentication, validation, and roles
Hi: I took a look at the ServletPrincipalProxy class, and it just delegates to the current request object to resolve authorization queries. There is not much more to do, since it is how the servlet standard is defined (the HttpServletRequest interface is the only one to query). So implementing a _custom_ PrincipalProxy implies you get those roles from *another object*, which means you are deviating from the standard and then, from any other framework which may integrate security with S2. If what you really want is to avoid configure container managed security for your app one vendor at a time, then you may give a try to Spring Security. HTH, Gabriel 2012/10/2 Ken McWilliams : > Asking for the consideration of a struts2 feature enhancement. > > The roles interceptor depends on container based security, it is a bit > of a pain to set up and portability is complicated by needing to cover > more documentation steps (how to secure your application on Glassfish, > Weblogic, Tomcat...). This is container security and of course not > Struts2s issue but it would be nice it we could use the roles > interceptor by defining a > org.apache.struts2.interceptor.PrincipalProxy implementation and > specifying it with a struts2 constant: > > value="com.example.MyPrincipalProxyImpl"/> //default would be > org.apache.struts2.servlet.interceptor.ServletPrincipalProxy > > There is only a few place (that I know of) where the PrincipalProxy > interface aught to be used where currently the request is being used > (aught to be used if implementing this feature). That is in the > "servletConfig" interceptor when setting the PrincipalAware interface > of an action and in the roles interceptor. > > It is not too much work to implement our own interceptors to > facilitate role based access but I think this would be helpful to many > and does not seem to require a radical change to S2 internals, so I > thought I would bring this up in the user forum to see what others > think. > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: overriding framework components
Ok. I found it in the javadoc for TextProvider This works. > -Original Message- > From: Davis, Chad [mailto:chad.da...@emc.com] > Sent: Wednesday, October 03, 2012 12:47 PM > To: Struts Users Mailing List > Subject: RE: overriding framework components > > I guess I need to map a constant value to my bean, but where do I find that > constant name? > > > -Original Message- > > From: Davis, Chad [mailto:chad.da...@emc.com] > > Sent: Wednesday, October 03, 2012 10:55 AM > > To: user@struts.apache.org > > Subject: overriding framework components > > > > I want to override the framework's built in TextProvider with my own. > > I understand that I need to add mine as a bean in my strut.xml, but > > something about the precise mechanics is eluding me. > > > > For starters, this is from struts-default.xml > > > > > class="com.opensymphony.xwork2.TextProviderSupport" scope="default" > /> > > > class="com.opensymphony.xwork2.TextProviderSupport" scope="default" > /> > > > > And my struts.xml bean element: > > > > > name="myProvider " > > class="com.mycompany.struts2.MyTextProviderSupport" scope="default" > /> > > > > > > This doesn't appear to get my provider injected into the framework. > > What am I doing wrong? > > > > > > - > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: overriding framework components
I guess I need to map a constant value to my bean, but where do I find that constant name? > -Original Message- > From: Davis, Chad [mailto:chad.da...@emc.com] > Sent: Wednesday, October 03, 2012 10:55 AM > To: user@struts.apache.org > Subject: overriding framework components > > I want to override the framework's built in TextProvider with my own. I > understand that I need to add mine as a bean in my strut.xml, but something > about the precise mechanics is eluding me. > > For starters, this is from struts-default.xml > > class="com.opensymphony.xwork2.TextProviderSupport" scope="default" /> > class="com.opensymphony.xwork2.TextProviderSupport" scope="default" /> > > And my struts.xml bean element: > > name="myProvider " > class="com.mycompany.struts2.MyTextProviderSupport" scope="default" /> > > > This doesn't appear to get my provider injected into the framework. What > am I doing wrong? > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
overriding framework components
I want to override the framework's built in TextProvider with my own. I understand that I need to add mine as a bean in my strut.xml, but something about the precise mechanics is eluding me. For starters, this is from struts-default.xml And my struts.xml bean element: This doesn't appear to get my provider injected into the framework. What am I doing wrong? - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Can we use the decorator pattern in Actions?
I was speaking with Lukasz today about this, so I'm resurrecting this
old thread.
The underlying question in my (rather extensive) post is:
How can you perform the following decorator pattern:
public OriginalAction implements Preparable,
SessionAware,OriginalActionInterface{
public String someFunctionality(){
}
}
Decorate like:
public DecoratedAction implements Preparable, SessionAware,etc{
private OriginalActionInterface originalAction; //inject
OriginalAction here
@Secured
public String someFunctionality(){
// do new stuff
orignalAction.someFunctionality();
}
}
Issues:
1) Your OriginalAction will probably rely on some objects injected by
struts (eg: session will probably be used). However, because
OriginalAction is now only decorating DecoratedAction...those objects
won't be automatically populated by Struts.
The only way I see it is to use Spring IoC to define these needed
objects in OriginalAction. But it would be neat if that was performed by
Struts.
What are your thoughts on this?
Miguel Almeida
On Wed, 2012-05-16 at 11:22 +0100, Miguel Almeida wrote:
> Imagine the scenario where you have security implemented at the action
> method level with an annotation:
>
> @Secured("someRole") restricts that action to that role (and it is
> checked with an interceptor).
>
> Discussing this on the TDD mailing list a while back, a decorator
> approach was suggested
>
> To separate concerns and ease up testing, authorization is implemented
> as a decorator (a-la GoF decorator pattern) adding authorization to the
> underlying (decorated) MVC app.
>
> The technique to getting there (see pseudo code in [1])
> 1. Extract an interface from your main class with all the public methods
> 2. Implement a decorator which adds authorization rules to a decorated
> underlying object. The decorator implements the authorization rules
> using annotations
> 3. in your tests, test the decorator providing a mock underlying
> decorated object, asserting in each test that given a request with a
> user that has certain roles the underlying method should or should not
> be called.
>
>
> As you see, tests would have a simple setup as you wouldn't be calling
> "the real, possible complicated action code", but the fake decorated
> one.
> The problem arises when you have superclasses (and maybe also when you
> implement interfaces). I exemplify with both.
>
> Imagine this:
> RealAction extends CommonAction implements IAction(){
> ...}
>
> CommonAction implements ServletRequestAware(){
> ...
> }
>
> AuthorizingDecorator implements IAction(){
> //injected decorated IAction, see [1]
> ...
> }
>
> Now, on a regular RealAction implementation, the request object exists:
> RealAction extends CommonAction, so the request is injected through its
> ServletRequestAware.
> If you're using the AuthorizingDecorator, however, the request will be
> null: RealAction will be injected, so Struts won't kick in to populate
> RealAction's request object.
>
>
> My question is: how would you go on and solve this? Or is the decorator
> approach impractical in Struts? I haven't even consider the necessity to
> implement every getter/setter on the IAction, which would also make this
> approach a bit cumbersome. The simplicity for testing, however, is
> great!
>
> Cheers,
>
> Miguel Almeida
>
>
> [1] The code might end up like this (semi-pseudo code)
>
> Tests:
>
> test_admin_can_call_method_a()
>
> {
> // setup a fake request with admin role:
> httpRequest = buildRequestWithRole("admin");
>
> // setup a mock app decorated with an authorzation decorator:
> MockApp app = new MockApp();
> AuthorizationDecorator authorizer = new
> AuthorizationDecorator(app);
>
> // act - try calling method A in the decorator:
> authorizer.MethodA(httpRequest);
>
> // assert - underlaying method a should have been called:
> Assert(app.MethodA.WasCalled==true);
>
> }
>
> test_regularUser_cannot_call_method_a()
> {
>
> // setup a fake request with regular user role:
> httpRequest = buildRequestWithRole("regular user");
>
> // setup a mock app decorated with an authorzation decorator:
> MockApp app = new MockApp();
> AuthorizationDecorator authorizer = new
> AuthorizationDecorator(app);
>
> // act - try calling method A in the decorator:
> authorizer.MethodA(httpRequest);
>
> // assert - underlaying method a should not have been called:
> Assert(app.MethodA.WasCalled==false);
>
> }
>
> In the SUT:
>
> interface IAction
> {
>
> String MethodA()
> String MethodB()
> ...
>
> }
>
> // this is the real action implementing methodA, methodB etc
> class RealAction: IAction
> {
>
> String MethodA()
> String MethodB()
> ...
>
> }
>
> // this is responsible for
