Hi Frank,
Frank Martínez wrote:
> Hi Paul,
>
> On 10/30/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> On the Resource Class Scanner: this is really cool stuff. I recommend
>> you write a different servlet adapter (to that of
>> com.sun.ws.rest.spi.container.servlet.ServletContainer) using the
>> scanner implementation ...
>>
>> Paul.
>>
>
> I think is better to write a subclass of
> com.sun.ws.rest.api.core.DefaultResourceConfig wich can be selected
> via an init parameter in the web.xml. By this way is easier for the
> user to select the desired implementation.
>
> Also is necessary to add an init(String[] paths) method to the
> ResourceConfig interface, by this way is easy to tell to the
> ResourceConfig implementation where to find the resources in a
> decoupled way.
>
> 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.
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.
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.
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.
This should also work for those wishing to use or extend
DefaultResourceConfig or ASMResourceConfig and passing in a reference to
the concrete class implementing ResourceConfig as is supported today.
Thus for the LW HTTP server we could then do:
String[] paths = ..
Map<String, String> props = new HashMap<String, String>();
props.put("paths", paths);
ResourceConfig rc = new ASMResourceConfig(props);
rc.etFeatures().put("myFeature", true);
HttpHandler handler = ContainerFactory.createContainer(
HttpHandler.class, rc);
Or:
HttpHandler handler = ContainerFactory.createContainer(
HttpHandler.class, "package.containing.rc");
Where the following class exists in the package "package.containing.rc":
class MyConfig extends ASMResourceConfig {
MyConfig(Map<String, String> props) {
super(props);
getFeatures().put("myFeature", true);
}
}
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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109