On Aug 3, 2010, at 10:33 AM, James Strachan wrote:
> 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? :)
>
I will try and get in done this week, about to travel to Prague for 3
days to meet up with other Jersey team members so lots of
distractions :-) plus a deadline by the 6th of Aug for JavaOne presos
was imposed on us :-(
>
>> 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.
>
OK.
>
>> 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.
>
But there is really only one class loader for a Web app. I suppose it
is different if using OSGi or Camel?
>
>> 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.
>
Yes, the idea would be to replace all the specific META-INF/services
files in a jar with at most just one that defines the module. I dunno
how we can remove it all together. I suppose a manifest header might
also work but that is harder for developers to register.
Jersey could supply a default module for all the message body readers/
writers, composed into meaningful sets, but a developer could define
their own and compose from in the sets in addition to their own stuff,
say if they want to use Jackson and not get interference with JAXB (we
added a specific feature to a JSON support to avoid this conflict).
I like the idea of having providers scoped to a module.
This is definitely something i want to do for a Jersey 2.0 effort.
Paul.