I don't want to overload HeaderDelegate.

I will create a new @Provider interface for this. Something like

public interface StringConverter<T>
{
T fromString(String val);
String toString(T val);
}

And then allow its use with @HeaderParam, @QueryParam, @PathParam,
@MatrixParam, and @FormParam injected objects.

Sound good?

Michael Brackx wrote:
> > That would be nice.
> > How could a HeaderDelegate be "activated" for a parameter?
> >
> > Michael
> >
> > On Fri, Oct 24, 2008 at 6:19 PM, Bill Burke <bburke@redhat.com> wrote:
>> >> There's is HeaderDelegate in the specification. I could make sure that is
>> >> used for all String parameters.
>> >>
>> >> Michael Brackx wrote:
>>> >>> Hi,
>>> >>>
>>> >>> It would be nice to have some sort of custom parameter unmarshalling.
>>> >>> Currently parameter types can be String, primitive, or a class that
>>> >>> has a String constructor or static valueOf(String) method.
>>> >>> Some use cases:
>>> >>> - injecting interfaces
>>> >>> - injecting Enums (they already have a static valueOf(String) method)
>>> >>> - injecting thirdparty classes
>>> >>> - injecting factory created objects
>>> >>>
>>> >>> example:
>>> >>>
>>> >>> @GET
>>> >>> @Path("/book/

{isbn}

")
>>> >>> public String getBook(@PathParm(value = "isbn", provider =
>>> >>> ISBNFactory.class) ISBN id)

{ >>> >>> ... >>> >>> }

>>> >>>
>>> >>> @Provider
>>> >>> public class ISBNFactory {
>>> >>> @ProviderMethod
>>> >>> public ISBN create(String value)

{ >>> >>> return new ISBNImpl(value); >>> >>> }

>>> >>> }
>>> >>>
>>> >>> The @ProviderMethod could be left out if there is only one matching
>>> >>> method.
>>> >>> Or a new interface could be used, to be more in line with ExceptionMapper.
>>> >>>
>>> >>> I realize the spec is final, but someday the will be a 1.1 or 2.0
>>> >>> Any comments?
>>> >>>
>>> >>> Michael Brackx