Hi Paul,
On 10/31/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> 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.
>
The correct type for the map is Map<String, Object>
> 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.
> 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?
>
> 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.
>
Ok.
> 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.
>
Do i need to change any class or is this user code?
Frank.
--
Frank D. Martínez M.
Asimov Technologies Ltda.
Blog: http://www.ibstaff.net/fmartinez/