Hi,
@FormParam stuff should work with the latest 1.1.5-ea-SNAPSHOT
artifacts on the maven repo (there are unit tests in place for this).
Does the @Inject annotation work for you?
For example in your resource method can you do:
@POST
public ... post(@Inject Sample s) {
assertNotNull(s.param1);
assertNotNull(s.param2);
...
}
I do not understand what you mean by:
> . But then, when I check at my provider class at above, I see that
> this
> provider is not there.
Paul.
On Nov 18, 2009, at 10:52 AM, Cemo Koc wrote:
>
> Hi Paul,
>
> I installed latest code from trunk as 1.1.5-ea-snapshot.
>
> I have such an implementation.
>
> public class Sample extends SimpleForm {
>
> @FormParam("param1")
> String param1;
>
> @FormParam("param2")
> String param2;
>
> @QueryParam("x")
> String param3;
> ///
> }
>
>
> @Provider
> public class FormBeanInjector implements
> InjectableProvider<FormBean, Type>
> {
>
> private final ResourceContext rc;
>
> public FormBeanInjector(@Context ResourceContext rc) {
> this.rc = rc;
> }
>
> public ComponentScope getScope() {
> return ComponentScope.PerRequest;
> }
>
> public Injectable getInjectable(ComponentContext ic, FormBean a,
> Type
> type) {
> if (type instanceof Class) {
> final Class c = (Class) type;
>
> return new Injectable() {
> public Object getValue() {
> return rc.getResource(c);
> }
> };
> }
> return null;
> }
> }
>
> However my resourceContext can not return FormParam setted FormBean
> object.
> I can see that QueryParam annotated variable can be setted but
> FormParam
> annotated variables can not be setted.
>
>
> When I checked at initiliaziting of my application, I could see that
> formParam bean provider is setted in injectableFactory in
> WebapplicationImpl
> . But then, when I check at my provider class at above, I see that
> this
> provider is not there.
>
>
> Thanks
>
>
>
> Paul Sandoz wrote:
>>
>> Hi,
>>
>> This is fixed in the trunk (jars on repo not yet available).
>>
>> You can now use the @Inject annotation to obtain a resource and that
>> resource can have @FormParam instances injected on to it.
>>
>> If @FormParam injection occurs when there is no request entity the
>> media type is anything other than "application/x-www-form-urlencoded"
>> an IllegalStateException will be thrown.
>>
>> If you need to inject a per-request resource onto a singleton
>> resource
>> you can do:
>>
>> @Singleton
>> public class SingletonResource {
>> private final Injectable<PerRequestResouce> ipr;
>>
>> public SingletonResource(@Inject Injectable<PerRequestResouce>
>> ipr) {
>> this.ipr = ipr;
>> }
>> }
>>
>> Paul.
>>
>> On Nov 13, 2009, at 10:55 AM, Cemo Koc wrote:
>>
>>>
>>> Despite of being newbie in restful area, I believe that such an
>>> implementation can be very beneficial for us. :) I am looking for
>>> your
>>> implementation.
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>> Paul Sandoz wrote:
>>>>
>>>>
>>>> Thinking out loud in the following....
>>>>
>>>> Having thought about this some more ideally what i would like to
>>>> achieve is:
>>>>
>>>> @GET
>>>> public XXX get(@Inject MyParamBean b) { ... } // I am referring to
>>>> Jersey's @Inject annotation.
>>>>
>>>> which would replace:
>>>>
>>>> @GET
>>>> public XXX get(@ResourceContext ResourceContext rc) { ...
>>>> MyParamBean b = rc.get(MyParamBean.class);
>>>> }
>>>>
>>>>
>>>> Then for forms ideally we could do the same like:
>>>>
>>>> @POST
>>>> @Consumes("application/x-www-form-urlencoded")
>>>> public XXX post(@Inject MyParamBean b) { ... }
>>>>
>>>>
>>>> The problem is there is a slight inconsistency in all this.
>>>> Consider
>>>> the following:
>>>>
>>>> public class Foo {
>>>> public Foo(@Inject MyParamBean b) { ... }
>>>>
>>>> @GET
>>>> public XXX get(@Inject MyParamBean b) { ... }
>>>>
>>>> @POST
>>>> @Consumes("application/x-www-form-urlencoded")
>>>> public XXX post(@Inject MyParamBean b);
>>>> }
>>>>
>>>> Currently we only know that form parameters are present when the
>>>> POST
>>>> method is called, but the reference to b in the constructor
>>>> parameter
>>>> should be the same as the parameter of the get or post (default
>>>> life-
>>>> cycle is per-request).
>>>>
>>>> I am wondering if i should really relax things in this respect
>>>> and go
>>>> back on some of the things i said. The way we could do this is to
>>>> buffer the request entity if it is of "application/x-www-form-
>>>> urlencoded" and also parse the entity to an instance of Form from
>>>> which @FormParam can operate. If there is no Form present we can
>>>> throw
>>>> an exception. Buffering would only occur if form parameters are
>>>> accessed outside of the resource method, or cannot be detected
>>>> from a
>>>> resource method. However, i still do not like the fact form
>>>> parameters
>>>> could be processed from outside of the resource method.
>>>>
>>>> Marc, if you got this far :-), what do you think?
>>>>
>>>> Paul.
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/FormParam-problem-in-InjectableProvider-and-Spring-tp3992897p3998312.html
>>> Sent from the Jersey mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/FormParam-problem-in-InjectableProvider-and-Spring-tp3992897p4024398.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>