On 3 August 2010 09:07, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
> Hi James,
>
> OK, i have a clearer understanding now. You want to introduce is a new type
> of component that is registered with Application/ResourceConfig (how it is
> registered via scanning or explicitly is not important). That component will
> declare that it is a sub resource of a super resource.
>
> The concern i have around hypermedia is the super-resource may not know
> about all the sub-resources such that it can create a representation with
> links/types to those sub-resources. I think this concern can be mitigated by
> a resource being able to inspect the model, which would any be better than
> using Java reflection on explicit sub-resource locators.
Great!
> I believe this feature is certainly possible to implement in addition to
> ensuring the abstract model is correctly up to date without too many
> modifications to existing code. It should also be possible to make it work
> for conventional sub-resources that have those new components attached as
> further sub-resources.
Great!
> For Aug/Sept i will be mostly tied up sorting out a new client API (moving
> the one in the experimental area to the stable area) and JavaOne so i don't
> have much time to work on this at the moment. The @ResourceRef stuff is
> easy, 1 to 2 hour job at most.
Any chance of sneaking in the @ResourceRef in the mean time then? :)
> Of late i have become more uncomfortable with the idea of plonking jars in
> place without some form of developer agreement or contract in place that
> describes relationships, because the former can lead to very confusing
> results and class path hell.
Maybe more introspection tools might help; e.g. a little tool to
display a nice diagram or tree of the resources. I guess this is just
transforming the WADL into visual representations so folks can see
what resources are at what URI template and which jar they come from
etc..
I've worked on a number of web apps using various JAXRS resources from
different packages and to be fair Jersey already does a pretty good
job of listing what resources its using from what packages etc.
> This is where i was suggesting some sort of
> routes file. But what i really meant was a module concept much like that of
> Guice. Imagine if your Camel app defined a JerseyModule and another app can
> use that module as a parent from which it can refer to the components of the
> parent module. I think you may be able to do all the same things you can
> today with annotations but things might be appropriately scoped e.g. for the
> case of a sub-resource declaring the parent resource if there is no concrete
> class of that name in the module or parent then it is a binding error.
Though the sub resources would be linked using the class loader to the
parent resource's class (or a ClassNotFoundException would occur). So
even though we're using annotations to do the linking, its a form of
typesafe module that works across class loader boundaries.
> I
> think this type of thing can also help with the inclusion of message body
> readers/writers e.g. a JAXBModule. JerseyModule is kind of like
> Application/ResourceConfig but with inheritance and builder like
> registration of stuff (that could include scanning for registration).
Agreed. We have a kinda module thing in the
META-INF/services/jersey-server-components file - in that you can
inspect the jars to see the packages which are jersey 'modules' of
sorts. But maybe a module system a-la Guice is simpler.
e.g. I always find those zillions of init-param with long
com.sun.jersey.whatnot names feel a bit smelly in a web.xml. It just
feels like those properties should be closer to the JAXRS stuff. For
example you need intimate knowledge of how each 'module' of jaxrs
resources work before you know how you can configure your global
web.xml with the ton of Jersey properties.
So maybe a little Jersey module class with simple bean properties
would be simpler. As an aside when using Scalate and Guice I tend to
use this helper Guice module to initialize Jersey (and the Scalate
templates) using guice-servlet - so Jersey itself is configured in the
IoC container (and I can hide all those long property strings)...
http://github.com/scalate/scalate/blob/master/scalate-guice/src/main/scala/org/fusesource/scalate/guice/ScalateModule.scala
So maybe we could introduce a simple JerseyModule class which
describes the properties & packages (or classes) of resources and
components; then allow it to be specified in a
META-INF/services/jersey-module file. Then its much easier to
introspect which modules are visible on the classloader and introspect
them in a more meaningful way - than just raw package scanning? It
could maybe open the door for different jersey configurations for
different modules. (e.g. tracing and implicit views on for some
modules but off for others or something like that). Maybe a module
could then explicitly depend on another module (to allow the new
sub-resources of other resources type feature?).
It would be nice if you just registered the Jersey filter in web.xml;
then Jersey found the available modules (or you list them explicitly
maybe) and those modules figured out what configurations to use for
Jersey - rather than a global configuration of Jersey in the web.xml -
when the modules probably know more about how Jersey needs to be
configured than the web.xml editor.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/