Frank Martínez wrote:
>>> What do you think?
>>>
>> Yes it is better and less disruptive to specialize ResourceConfig. Your
>> commits to the jersey-rtresourceconfig are a great start.
>>
>>
>> An alternative to a ResourceConfig.init method is a constructor that
>> takes a Map<String, String> parameter. This is a bit more general for
>> intialization properties and there is no required extra init step
>> associated with all specializations of ResourceConfig.
>>
>
> The correct type for the map is Map<String, Object>
>
Ah! i did not think of connecting the initialization properties of the
constructor to be included with the other properties, nice catch.
>> If a container has a reference to a concreate class that implements
>> ResourceConfig it can instantiate accordingly and pass in the Map
>> instance (if required), or if there is no reference it can instantiate
>> directly a pre-configured one, namely ASMResourceConfig.
>>
>
> Done. Commited.
>
>> Once we have this in place we can remove the pre-compile step to
>> generate an implementation of ResourceConfig. The main reason why this
>> pre-compile step is necessary is to get the list of root resources. So
>> we will never be dealing with an existing ResourceConfig implementation
>> with servlet unless a developer wants to override default behaviour.
>>
>
> I dont know how to remove the -pre-compile target safely.
>
I can sort out this bit. I don't want to remove it completely until the
abstract resource model API and impl is ready so that we still have
WADL generation support for the interim period. But I can remove the
resource config APT and generation code and do some clean up.
>> For servlet we can then specify features/properties of configuration in
>> the init-params of servlet and those are passed to the ResourceConfig
>> impl instantiated. Thus for default behaviour no init-parameters are
>> required. Overall this is great improvement on what we currently require.
>>
>
> For servlet I scan into WEB-INF/lib, and WEB-INF/classes by default. Do you
> want to give to the users the ability to change via init params in the web.xml?
>
I am not sure. I am thinking from the perspective that a user might not
want to scan some or all of the jars in WEB-INF/lib for performance (or
security?) reasons.
>> In fact the former is so useful the container factory should have a method:
>>
>> public static <A> A createContainer(Class<A> type, String... paths)
>>
>> for taking in an array of paths and utilzing ASMResourceConfig under the
>> covers to search for resource classes.
>>
>
> Do i need to change any class or is this user code?
>
See the class:
com.sun.ws.rest.api.container.ContainerFactory
I justed checked the available properties returned from
System.getProperties() (ironically using the EntityProvider example in
Jersey to print them out :-) )
So we can get the value of the property "java.class.path" to get the
list of paths.
Which means we could add the following additional methods to
ContainerFactory:
// Creates a ASMResourceConfig obtaining the
// paths from the System property "java.class.path"
public static <A> A createContainer(Class<A> type)
// Creates a ASMResourceConfig obtaining the
// paths passed in as a parameter
public static <A> A createContainer(Class<A> type, String... paths)
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109