Re: [Stripes-users] Question about stripes spring integration
Hi. can I know how to delete cache? On Mon, Nov 17, 2008 at 4:16 PM, Levi Hoogenberg <[EMAIL PROTECTED]>wrote: > Though there is a difference between Stripes' wiring and Spring's: if you > have the same dependency in a class and its superclass, Stripes will not > inject the superclass. (I'm talking about field injection here.) > > > On Mon, Nov 17, 2008 at 5:50 AM, Gregg Bolinger < > [EMAIL PROTECTED]> wrote: > >> The only thing Stripes is doing with the Spring support Interceptor is >> getting a bean from spring's application context. The wiring of the bean is >> still completely up to Spring so I don't see how this can be a Stripes >> issue. >> >> Gregg >> >> On Sun, Nov 16, 2008 at 1:39 PM, Alex Turner <[EMAIL PROTECTED]> wrote: >> >>> Hmmm - whats weird is that my other DAOs that are being injected are >>> fine. >>> >>> On Sun, Nov 16, 2008 at 2:26 PM, Alex Turner <[EMAIL PROTECTED]> wrote: >>> The spring integration seems to work great for simple cases, but I'm running into a case where my dependency is not injected. My main action bean is CreateTrifoldBrochureActionBean, and this is a subclass of ProductActionBean. ProductActionBean has spring inject beans in it, but they don't appear to be getting injected. When I check the injected object to see if it is null, it is :(. Is this known behaviour or am I doing something wrong? Alex >>> >>> >>> - >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> ___ >>> Stripes-users mailing list >>> Stripes-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/stripes-users >>> >>> >> >> - >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> ___ >> Stripes-users mailing list >> Stripes-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/stripes-users >> >> > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Web service API, Stripes
I've been poking around trying to figure out a good "harmonious" way to provide a set of "web service" URLs as part of an application. By "web service" I don't necessarily mean any particular approach (SOAP or whatever) at this point. What I would like is to have some mechanism that could make an incoming HTTP POST to a service URL end up looking more-or-less like a plain old action invocation (possibly with the payload in the form of a FileBean). So I'm thinking that one way to do this would be to use a filter that does something like what the multipart filter does. It'd have to interpret any sort of authentication header and then package up the payload as a parameter. Does that seem like a bad idea for some reason? I'm not terribly experienced with Stripes, and the web service APIs I'm familiar with are implemented as independent servlets. Seems to me that it's not unlikely that somebody's done something similar. -- Turtle, turtle, on the ground, Pink and shiny, turn around. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Web service API, Stripes
On 30-11-2008 at 10:12, Mike McNally wrote: > I've been poking around trying to figure out a good "harmonious" way > to provide a set of "web service" URLs as part of an application. By > "web service" I don't necessarily mean any particular approach (SOAP > or whatever) at this point. What I would like is to have some > mechanism that could make an incoming HTTP POST to a service URL end > up looking more-or-less like a plain old action invocation (possibly > with the payload in the form of a FileBean). > > So I'm thinking that one way to do this would be to use a filter that > does something like what the multipart filter does. It'd have to > interpret any sort of authentication header and then package up the > payload as a parameter. Does that seem like a bad idea for some > reason? I'm not terribly experienced with Stripes, and the web service > APIs I'm familiar with are implemented as independent servlets. It seems a bit convoluted: a Filter works explicitly on a HTTP request; not on a derviate like SOAP. It's probably easier to create a protocol handler specific to each protocol, and have that handle the call to an ActionBean. The tricky bit however, is that you'll have to redo this work for every new protocol, while keeping the assumptions that ActionBean writers may make intact, like the Stripes lifecycle (and everything that it does/doesn't do). Oscar -- ,-_ Oscar Westra van holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Progress is made by lazy men looking for easier ways to do things. =/ () -- Robert Heinlein - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Enum Type Converter - bug in DefaultTypeConverterFactory
Hi, Cosmin. The 1.5.1 release is almost ready, but as usual we are unable to
commit to a release date due to constraints on our own time. Sorry I can't
be more specific.
-Ben
On Fri, Nov 28, 2008 at 12:02 PM, Cosmin Marginean <[EMAIL PROTECTED]>wrote:
> OK, It seems there's a bug + fix for this in 1.5.1:
> http://www.stripesframework.org/jira/browse/STS-608
> Sorry for the noise :)
>
> I patched this myself in my project, but do you have any clues about
> when the new release (1.5.1 ?) will be out. I see a lot of patches there.
>
> Thanks,
> Cosmin
> > Hello everyone,
> >
> > Boy, this took some time to figure it out.
> > I wrote a custom converter for enums:
> >
> > public class EnumConverter implements TypeConverter {
> > public Enum convert(String s, Class aClass,
> > Collection validationErrors) {
> >...
> > }
> > public void setLocale(Locale locale) {
> > }
> > }
> >
> > I went back and forth for a while trying to understand why the hell is
> > it not loaded using Extension.Packages filter parameter.
> > I dug through the whole flow and finally ran into this in
> > /net.sourceforge.stripes.validation.DefaultTypeConverterFactory/:
> >
> > protected Class>
> > findTypeConverterClass(Class targetClass) {
> > //...some stuff
> > else if (targetClass.isEnum()) {
> > Class> converterClass =
> > findTypeConverterClass(*Enumeration*.class);
> > //...some other stuff
> > }
> >
> > I believe this should be:
> > Class> converterClass =
> > findTypeConverterClass(*Enum*.class);
> >
> > I gotta say I had a good laugh though :)
> >
> > Regards,
> > Cosmin Marginean
>
>
> Cosmin Marginean
>
> --
> cosminaru.ro
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Web service API, Stripes
> It seems a bit convoluted: a Filter works explicitly on a HTTP request; not > on a derviate like SOAP. It's probably easier to create a protocol handler > specific to each protocol, and have that handle the call to an ActionBean. I did not explain myself well. The filter might do nothing at all with the information in the request, though it might have to handle the authentication part. That aside, all it would do is package up the request content so that an ActionBean written to handle it would be coded to accept one (or more, I guess) FileBean parameters. The ActionBean would be responsible for interpreting and acting on the request content. For my application it is likely to be the case that only one protocol would ever exist, at least for the authentication. On another application (servlet-based) the authentication header is universal, while the "protocol" (file formats for uploads, request formats for downloads) may indeed vary. My feeling here is that the filter itself would only pay attention to the authentication header, and then package up the rest of the request's content as a single file parameter. (It's true that if the protocol/format had some file separator semantics that the filter would have to know that. I have in mind that the filter would use some URL pattern queues to make decisions about things like that.) Thanks for your response; it is definitely the case that I may be terribly wrong :) -- Turtle, turtle, on the ground, Pink and shiny, turn around. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Web service API, Stripes
On Nov 30, 2008, at 8:12 AM, Mike McNally wrote: > I've been poking around trying to figure out a good "harmonious" way > to provide a set of "web service" URLs as part of an application. By > "web service" I don't necessarily mean any particular approach (SOAP > or whatever) at this point. What I would like is to have some > mechanism that could make an incoming HTTP POST to a service URL end > up looking more-or-less like a plain old action invocation (possibly > with the payload in the form of a FileBean). > > So I'm thinking that one way to do this would be to use a filter that > does something like what the multipart filter does. It'd have to > interpret any sort of authentication header and then package up the > payload as a parameter. Does that seem like a bad idea for some > reason? I'm not terribly experienced with Stripes, and the web service > APIs I'm familiar with are implemented as independent servlets. I don't see why you need any special anything to do this. Stripes already responds appropriately to HTTP requests (well, POST and GET, and it doesn't distinguish between the two, but that seems to be OK with what you're talking about) and does what you want. That is it reads the request, binds the parameters (including FileBeans), and calls your action and the appropriate method. With Clean URLs you can bind specific urls to specific events within your ActionBean and Magic Happens from there. So, I guess the question is what exactly does Stripes not already do that you want to do? Well, I guess besides security, but that's orthogonal to action handling, and there are a couple of in place mechanisms to even handle that. Perhaps you can be more clear about what you're trying to do. The biggest gap in Stripes ad hoc web services at the moment is having no support for the HTTP verb and conflating the GET and POST verbs to do the same thing. Doesn't affect most people, just annoys RESTy whiners like me. Regards, Will Hartung - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Web service API, Stripes
Hmm well my understanding is that the file upload stuff expects multipart-MIME content type; in fact it explicitly does based on my recollection of the source. It's certainly possible, I guess, to create a web service protocol that expects multipart-MIME inputs but that makes life on the client end a little more of a pain (barring the existence of a common tool I'm not aware of, and you'd be surprised how unaware I can be :) What I'm imagining is a service that expects: [ Authentication Header ] [ Content ] The content would be XML, or a CSV file, or whatever, and it coupled with the URL determines what the API means. -- Turtle, turtle, on the ground, Pink and shiny, turn around. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Web service API, Stripes
On Nov 30, 2008, at 10:48 AM, Mike McNally wrote: > Hmm well my understanding is that the file upload stuff expects > multipart-MIME content type; in fact it explicitly does based on my > recollection of the source. It's certainly possible, I guess, to > create a web service protocol that expects multipart-MIME inputs but > that makes life on the client end a little more of a pain (barring the > existence of a common tool I'm not aware of, and you'd be surprised > how unaware I can be :) > > What I'm imagining is a service that expects: > > [ Authentication Header ] > [ Content ] > > The content would be XML, or a CSV file, or whatever, and it coupled > with the URL determines what the API means. So, let me clarify this, you want to upload files with a header, is that about the gist of it? And in this header is some authentication information? How does a classic, multipart/form-data format not work for this case? Or do you want the filter to introspect the payload to work out the authentication details? Regards, Will Hartung - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Web service API, Stripes
> So, let me clarify this, you want to upload files with a header, is > that about the gist of it? And in this header is some authentication > information? > > How does a classic, multipart/form-data format not work for this case? > > Or do you want the filter to introspect the payload to work out the > authentication details? Yup that's it. Multipart-MIME would indeed work, but it's marginally more difficult to create the inputs than a format that allows a canned header (kept at the client end of course) to be prepended to an XML or CSV or JSON or whatever blob of content. My experience with typical customer IT departments has led me to believe that even the most trivial of tasks can pose a monumental problem for some customers, so the simpler the better. That aside, as I've pondered this further today I think that it's not really a worthwhile approach, and this is possibly what Oscar was getting at: what I'm trying to avoid is duplication of functionality between services offered via a web UI and services offered through scriptable web-based APIs. My scheme here really wouldn't achieve that at all, without a much more elaborate preprocessing mechanism. Thus, thanks for indulging my out-loud thought process. I'll keep an eye out for anything I see that's similar; I've worked with APIs like this but I've not done much research. -- Turtle, turtle, on the ground, Pink and shiny, turn around. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
