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. 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
>