On 3 August 2010 10:21, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
>
> 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 :-(
No worries :). But a style C would be a good workaround for now; so we
can at least use the same injection model with root and sub resources.
>>> 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?
Sorry; not enough coffee yet (and am about to delve into the horrid
OSGi world shortly). I meant across jar boundaries in a web-app
(though it would be class loader boundaries in OSGi).
>>> 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.
Cool.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/