Re: S2 REST plugin URL mapping convention
Hmm... I found this two different behaviors in the S2 documentation itself. POST - create , PUT - update: http://struts.apache.org/2.x/docs/rest-plugin.html PUT - create, POST - update: http://cwiki.apache.org/S2PLUGINS/restful-crud-for-html-methods.html which one to choose? confused! Thanks, ManiKanta G Twitter/manikantag http://www.twitter.com/manikantag
Re: [s2] rest plugin and rss output with Rome
Bill Stilwell wrote: I'd like to solicit feedback on the best way to support .rss/.atom requests when using the rest plugin. Have you considered writing a custom content type handler? Content type handlers are chosen based on URL extension. Check the Custom ContentTypeHandlers section: http://struts.apache.org/2.x/docs/rest-plugin.html Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [s2] rest plugin and rss output with Rome
Yup, but as mentioned in the original email I'm not sure where to construct the SyndFeed object. Doing it in the content handler doesn't really make sense, as there's no generic way to map objects to an RSS/Atom feed. My basic idea is that the ContentTypeHandler would expect to be passed a SyndFeed object as the model to write to the output stream. The bit I'm having trouble figuring out is how the action would know that the model should be a SyndFeed object - is there a standard way to detect what extension was used when calling the action? (I could parse it from request.getRequestURI(), but that seems a bit ugly). Bill On Wed, Jan 28, 2009 at 6:08 PM, Dave Newton newton.d...@yahoo.com wrote: Have you considered writing a custom content type handler? Content type handlers are chosen based on URL extension. Check the Custom ContentTypeHandlers section: http://struts.apache.org/2.x/docs/rest-plugin.html -- Bill Stilwell - http://www.marginalia.org/ bill.stilw...@gmail.com - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [s2] rest plugin and rss output with Rome
Bill Stilwell wrote: The bit I'm having trouble figuring out is how the action would know that the model should be a SyndFeed object - is there a standard way to detect what extension was used when calling the action? (I could parse it from request.getRequestURI(), but that seems a bit ugly). The action doesn't need to know; that's the point. The framework serializes the action based on the content type handler (CTH) registered to the URL extension. For example, the json extension uses a JSON serializer which will serialize the entire action, or if it implemented ModelDriven just the model. The action code doesn't care that it will be serialized as JSON, it just goes about its business. In your case you'd construct the SyndFeed object in the content type handler. Actions are intended to create known data to hand off to the view layer--you shouldn't need to convert *any* old objects to your desired output, you just need to convert the object(s) your action creates/retrieves/etc. It's possible the existing XML CTH would be enough, if you create the appropriate beans. The existing non-RESTful XSLT result type might even be enough if you just write the XSLT to take whatever objects you create and mudge them into the desired format. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [s2] rest plugin and rss output with Rome
On Wed, Jan 28, 2009 at 6:45 PM, Dave Newton newton.d...@yahoo.com wrote: The action doesn't need to know; that's the point. The framework serializes the action based on the content type handler (CTH) registered to the URL extension. For example, the json extension uses a JSON serializer which will serialize the entire action, or if it implemented ModelDriven just the model. The action code doesn't care that it will be serialized as JSON, it just goes about its business. In your case you'd construct the SyndFeed object in the content type handler. Actions are intended to create known data to hand off to the view layer--you shouldn't need to convert *any* old objects to your desired output, you just need to convert the object(s) your action creates/retrieves/etc. I understand the general idea, but I guess where the problem lies for me is that RSS/Atom isn't intended for generic object serialization, but rather constructed very much around content with a title, description, URL, etc. To me, this implies that there needs to be code to map whatever the particular model is to the needs of the RSS feed. Your suggested approach would lead, I think, to either multiple content handlers (each understanding how to construct a feed from a particular model) or an interface approach where it's understood that the Model will implement a particular Feed interface so that a generic CTH can create a feed from different models. The interface approach makes the most sense to me, but I think there are still issues around doing this generically (for example, in my particular usage scenario, it's not reasonable that the model objects know what URL they can be addressed at). Thanks for the input - I'm mostly really loving working with the new rest/convention plugins, but there's stuff in the corners I'm still wrapping my head around. Bill -- Bill Stilwell - http://www.marginalia.org/ bill.stilw...@gmail.com - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [s2] rest plugin and rss output with Rome
Bill Stilwell wrote: To me, this implies that there needs to be code to map whatever the particular model is to the needs of the RSS feed. Well yeah. I think maybe I'm just completely misunderstanding what your system looks like. The systems I've worked on tend to have a pretty orthogonal type hierarchy that makes doing things like this trivial--it's been only a rare occasion when I've had to convert a slew of completely different types into one format. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [s2] rest plugin and rss output with Rome
On 29/01/2009, at 2:48 PM, Dave Newton wrote: Bill Stilwell wrote: To me, this implies that there needs to be code to map whatever the particular model is to the needs of the RSS feed. Well yeah. I think maybe I'm just completely misunderstanding what your system looks like. The systems I've worked on tend to have a pretty orthogonal type hierarchy that makes doing things like this trivial-- it's been only a rare occasion when I've had to convert a slew of completely different types into one format. Dave Hi Bill, Two other options: - (preferred) define a binding (annotations/xml) that can map the properties of your model(s) to a SyncFeed instance. The ContentTypeHandler performs the mapping and returns a SyncFeed. I'd be surprised if a binding implementation doesn't exist already. - If the resource is always a SyncFeed, then don't try to pretend it's not. eg. Have your action mapper direct the request to a different controller to create the alternative model. regards, Jeromy Evans - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [S2] REST Plugin + Validation
Thanks for the response Jeromy. I am actually already using that setting actually - I have two sets of different validations - one on the create method and one on the update method. However the problem is that when validation fails - I need an input result which is specific for each method. I hope that clarifies the problem. -- View this message in context: http://www.nabble.com/-S2--REST-Plugin-%2B-Validation-tp19230629p19268377.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] REST Plugin + Validation
alvins wrote: Thanks for the response Jeromy. I am actually already using that setting actually - I have two sets of different validations - one on the create method and one on the update method. However the problem is that when validation fails - I need an input result which is specific for each method. I hope that clarifies the problem. Ah, sorry, I understand now. I don't actually know how to solve that. Perhaps changing to a custom workflow interceptor to allow results other than input depending on the method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] REST Plugin + Validation
Hmm I might just have to do that. I am guessing alot of people will run into this issue with the REST plugin - might be an idea to get some annotation into conventions or rest plugin (not sure where it would go) to allow for method specific result for validation failure? How do these things get proposed - Jira? Jeromy Evans - Blue Sky Minds wrote: Ah, sorry, I understand now. I don't actually know how to solve that. Perhaps changing to a custom workflow interceptor to allow results other than input depending on the method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-S2--REST-Plugin-%2B-Validation-tp19230629p19268803.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] REST Plugin + Validation
alvins wrote: Hmm I might just have to do that. I am guessing alot of people will run into this issue with the REST plugin - might be an idea to get some annotation into conventions or rest plugin (not sure where it would go) to allow for method specific result for validation failure? How do these things get proposed - Jira? Yeah, raising a feature request in Jira. It could be adopted by convention/codebehind/rest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] REST Plugin + Validation
--- On Tue, 9/2/08, alvins wrote: However the problem is that when validation fails - I need an input result which is specific for each method. As Jeremy said you'll probably have to do something with a custom workflow; probably the easiest solution. I had a similar problem eons ago with wildcard mappings and that was what I ended up doing. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] REST Plugin + Validation
alvins wrote: Hi guys, I have been wrestling with the REST plugin for the last couple of days and have posted some notes in another thread. I have hit a problem which I need a little help with. Basically in my REST controller I have a create and update method as per the REST guidelines. I need separate validations for each of these which I do via annotating the methods respectively. A problem arises as I need to separate INPUT results in the case of validation failure 0 one for the create and one for the update but of course this is not doable. I posted a similar response to this list a a few minutes ago. Here's a paraphrase for your specific question: The default configuration for the validation interceptor is not suitable for this. The parameter validateAnnotatedMethodOnly needs to be sets to true so the annotations only apply for the specific method instead of the entire class. What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref Hope that helps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2} REST plugin Security
Thanks Jeromy, Yep, we did get the standard JEE security working in WAS. (Fat-fingered typing in the web.xml was the culprit). I'll have a look at the Sping option if we find the container stuff a bit lacking. Thanks again for your feedback. Mike 2008/7/29 Jeromy Evans [EMAIL PROTECTED]: If you don't have complex URL patterns, I'd continue down the JEE path. It should work. Although I haven't tried it with websphere it's a fundamental requirement of the container. I'd temporarily switch to HTTP BASIC instead of LDAP to try isolate the problem. Yes, creating a custom Security Interceptor is another approach. It's pretty simple to throw your own interceptor into the stack that checks the Principal or Session and forces a redirect/error if appropriate. It's a low effort approach but you take on some more risk of introducing vulnerabilities. An better approach is to use a third party filter. Acegi/Spring Security is the most popular and probably the most flexible as it's closely bound to your (Spring) Object Factory. There are other open source filters available too that may suite you. Hope that helps, Jeromy Evans Mike Watson wrote: I should probably add that I'm just trying to authenticate via LDAP at this stage. Authorization will be implemented later. 2008/7/28 Mike Watson [EMAIL PROTECTED]: Hi Folks, What's the most straightforward way to secure my REST URLs? I'd assumed that I'd be able to use the standard JEE approach and secure based on URL patterns but this doesn't seem to work (on Websphere anyway) and I'm assuming it's to do with the fact everything I'm doing is happening in filters rather than working with 'real' resources. (I don't get any errors, I just get to see resources I shouldn't when I'm not authenticated). Is there some sort of Security Interceptor I should enable or should this work the way I initially assumed? Has anybody else (Jeromy?) done this? Cheers Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.5/1569 - Release Date: 23/07/2008 1:31 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2} REST plugin Security
If you don't have complex URL patterns, I'd continue down the JEE path. It should work. Although I haven't tried it with websphere it's a fundamental requirement of the container. I'd temporarily switch to HTTP BASIC instead of LDAP to try isolate the problem. Yes, creating a custom Security Interceptor is another approach. It's pretty simple to throw your own interceptor into the stack that checks the Principal or Session and forces a redirect/error if appropriate. It's a low effort approach but you take on some more risk of introducing vulnerabilities. An better approach is to use a third party filter. Acegi/Spring Security is the most popular and probably the most flexible as it's closely bound to your (Spring) Object Factory. There are other open source filters available too that may suite you. Hope that helps, Jeromy Evans Mike Watson wrote: I should probably add that I'm just trying to authenticate via LDAP at this stage. Authorization will be implemented later. 2008/7/28 Mike Watson [EMAIL PROTECTED]: Hi Folks, What's the most straightforward way to secure my REST URLs? I'd assumed that I'd be able to use the standard JEE approach and secure based on URL patterns but this doesn't seem to work (on Websphere anyway) and I'm assuming it's to do with the fact everything I'm doing is happening in filters rather than working with 'real' resources. (I don't get any errors, I just get to see resources I shouldn't when I'm not authenticated). Is there some sort of Security Interceptor I should enable or should this work the way I initially assumed? Has anybody else (Jeromy?) done this? Cheers Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.5/1569 - Release Date: 23/07/2008 1:31 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2} REST plugin Security
I should probably add that I'm just trying to authenticate via LDAP at this stage. Authorization will be implemented later. 2008/7/28 Mike Watson [EMAIL PROTECTED]: Hi Folks, What's the most straightforward way to secure my REST URLs? I'd assumed that I'd be able to use the standard JEE approach and secure based on URL patterns but this doesn't seem to work (on Websphere anyway) and I'm assuming it's to do with the fact everything I'm doing is happening in filters rather than working with 'real' resources. (I don't get any errors, I just get to see resources I shouldn't when I'm not authenticated). Is there some sort of Security Interceptor I should enable or should this work the way I initially assumed? Has anybody else (Jeromy?) done this? Cheers Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 REST plugin
What I actually return is a DefaultHttpHeaders with a 404 set.
getImage() returns an empty (not null) inputstream since there's no
content for the body.
I'll do some debugging when I get time and see where it's failing. It
certainly seems to be StreamResult that has the issue.
Thanks
Mike
2008/7/24 Jeromy Evans [EMAIL PROTECTED]:
Mike Watson wrote:
Hi folks,
As mentioned in previous posts I'm using the REST plugin to serve
images and everything seems to work fine when the content exists.
However if I return an empty inputstream to StreamResult with a 404
response code I get the exception below.
Stepping through the code the getBufferSize() method on my controller
is definitely called and returns a legitimate value...
Does this only occur when you return a null or 0 buffer size?
My guess is that it's a bug in the StreamResult or the result handler. It
probably evaluates ${bufferSize} and deduces that the property doesn't
exist (because it's null/0) and uses it as a literal string value instead.
That's just a guess.
Is it really valid to return a zero length stream result? I would instead
return a http status result with 404 / NullResult for the error case (ie.
just headers, no content).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 REST plugin
Mike Watson wrote: What I actually return is a DefaultHttpHeaders with a 404 set. getImage() returns an empty (not null) inputstream since there's no content for the body. You may need to return a different result type for the error case (HttpHeaderResult or NullResult) so it only attempts to set the headers though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 REST plugin
Thanks mate. I'll give that a try tomorrow. 2008/7/24 Jeromy Evans [EMAIL PROTECTED]: Mike Watson wrote: What I actually return is a DefaultHttpHeaders with a 404 set. getImage() returns an empty (not null) inputstream since there's no content for the body. You may need to return a different result type for the error case (HttpHeaderResult or NullResult) so it only attempts to set the headers though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 REST plugin
Mike Watson wrote:
Hi folks,
As mentioned in previous posts I'm using the REST plugin to serve
images and everything seems to work fine when the content exists.
However if I return an empty inputstream to StreamResult with a 404
response code I get the exception below.
Stepping through the code the getBufferSize() method on my controller
is definitely called and returns a legitimate value...
Does this only occur when you return a null or 0 buffer size?
My guess is that it's a bug in the StreamResult or the result handler.
It probably evaluates ${bufferSize} and deduces that the property
doesn't exist (because it's null/0) and uses it as a literal string
value instead. That's just a guess.
Is it really valid to return a zero length stream result? I would
instead return a http status result with 404 / NullResult for the error
case (ie. just headers, no content).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
