On Feb 26, 2009, at 5:57 PM, Paul Sandoz wrote:
> Hi James,
>
> Some points of note:
>
> 1) In the JAX-RS MR [1] it states:
>
> When using a Servlet 3 container, the Application subclass is
> optional. By default, all root resource classes
> and providers packaged in the web application MUST be included
> in the published JAX-RS application. An
> Application subclass MAY be included in a .war file to
> override the default behavior.
>
> 2) 1) is a bit similar to the default Jersey deployment (when not
> using Spring) where all classes in
> WEB-INF/classes and all classes in jars in WEB-INF/lib are
> scanned. However, class scanning is the least
> portable mechanism to scan when deploying on app servers. And
> for many jars in the WEB-INF/lib it is
> not that efficient, although i am surprised at how fast the ASM
> code can churn through class files.
>
> 3) In the early days Jersey had a similar mechanism to what you
> described. At pre-compile time a Java source
> file, that was a ResourceConfig implementation was generated
> from a Java SE 5 annotation processor that
> declared the root resource and provider classes. This was done
> using ant and it was a right PITA for
> developers to work with.
>
> But i think your solution has a lot of merit to it. Especially used
> in conjunction with maven as it is so simple to integrate such
> functionality. It is essentially an optimization step.
In addition an ease of use step for developer including things from
multiple sources so that they do not have to declare themselves.
Paul.
> The resource file could contain list of packages and/or fully
> qualified class names.
>
> Note that it would be really easy to reuse the class scanning
> support we already have on the compiled class to generate such
> resources file before the Java classes and resource file are
> packaged. I do not think we need to use the SE 5 annotation
> processing mechanism. In fact that post compile technique is what
> the WADL Ant generator task uses, you can point it at a bunch of
> jars and class files and it will generate WADL from that.
>
> Paul.
>
> [1] http://jcp.org/aboutJava/communityprocess/maintenance/jsr311/311ChangeLog.html
>
> On Feb 26, 2009, at 1:08 PM, James Strachan wrote:
>
>> At some point soon I'm going to experiment with building some modular
>> web applications based on Jersey; thats to say a core application
>> with
>> optional, pluggable extra resources.
>>
>> There's a kinda example in the Apache Camel project where I take the
>> normal Camel web application...
>> http://camel.apache.org/web-console.html
>>
>> and then add some extra endpoints (ActiveMQ)...
>> https://svn.apache.org/repos/asf/camel/trunk/components/camel-activemq-web/
>>
>> (Though no custom resource beans are added yet - just new content and
>> more jar dependencies for now). Maven's war plugin is pretty good at
>> taking an existing WAR and overlaying new JSP/files/jars into it to
>> make a new application.
>>
>> One of the first issues when doing such a thing is figuring out what
>> all the packages are that contain the various resource beans. While
>> you can manually do that by hand and provide a custom web.xml file -
>> it'd be nice to just automatically know, based on the jar
>> dependencies
>> of a WAR what resource beans are available.
>>
>> The brute force approach would be to just use "org" and "com" as the
>> package names - though this would lead to a lot of classpath scanning
>> on startup and slow things down.
>>
>> So here's a little idea for how this could work in a simple, fast,
>> automated way - I just wondered if others thought it was a good idea
>> or not first or if folks had similar ideas...
>>
>>
>> Imagine we have a maven-jaxrs-plugin (or a Java 5 annotation
>> processor) which when compilng your code with any resource beans
>> inside it, it generated a text file in
>> META-INF/services/jaxrs/resources which contained a list of all the
>> package names where resource beans are located. (A Java 5 annotation
>> processor is maybe a bit more reusable outside of maven). (We could
>> always make these files by hand for now :)
>>
>> Then Jersey (or any other provider) could then auto-locate the
>> resource beans by loading all of the files called
>> "META-INF/services/jaxrs/resources" on the classpath (one from each
>> jar containing the resource beans) and then the user wouldn't have to
>> know all the packages used inside the jars - it'd just do the right
>> thing.
>>
>> This seems a pretty simple solution to me - even when folks are
>> building just a single, self contained web application - it would
>> avoid the need for the user having to know the jersey configuration
>> option to set the package name. (i.e. by default it could just use
>> the
>> auto-discovery mechanism).
>>
>> I can see it being useful even without the maven plugin / annotation
>> processor - where folks just make them by hand.
>>
>> Thoughts?
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>