I was revisiting this issue recently to try and get it working with 'mvn
jetty:run' and decided to have a look at how the struts2 codebehind
plugin works. I pretty much needs to do the same thing, scan for
classes implementing an interface or with a certain annotation. To do
this they use the ResolverUtil class from XWork2
(
http://svn.opensymphony.com/svn/xwork/trunk/src/java/com/opensymphony/xwork2/util/ResolverUtil.java).
The basic idea seems to be that you can use the
ClassLoader.getResources() method with a package name and it will give
you a list of resources in that package.
So there should be no need to specify where the class files and jars are.
Rich
Paul Sandoz wrote:
> Richard Wallace wrote:
>> Alright, I did a bit more digging. I hadn't noticed that check for
>> if it is a directory. The problem is that since I'm running jetty
>> with the maven-jetty-plugin jetty:run target (super useful for
>> debugging), the /WEB-INF/lib and /WEB-INF/classes directories don't
>> exist.
>
> It is odd that context.getRealPath("/WEB-INF/lib") is actually
> returning something non-null though, so in some sense they must exist
> "Jim, but not as we know it".
>
>
>> With the jetty:run target, the plugin doesn't assemble the war, it
>> runs everything in place and tells jetty what it should use for the
>> classpath.
>>
>
> OK. See the JavaDoc of:
>
> com.sun.ws.rest.spi.container.servlet.ServletContainer
>
> perhaps you could set the init-param:
>
> com.sun.ws.rest.config.property.ResourcePaths
>
> to point to the relevant locations? I guess it all depends on what
> base path for context.getRealPath() with Jetty for a non-standard
> deployment config.
>
> Another workaround is to create your own class that extends
> DynamicResourceConfig with an empty public constructor that configures
> things from the java.class.path system property (see the
> com.sun.ws.rest.api.container.ContainerFactory code). Then set up the
> web.xml to point to this class using the "webresourceclass" init-param.
>
>
>> This is what is causing the scanning code to die. The solution is to
>> use the jetty:run-war target instead. The bad thing about running
>> the plugin that way is that changes to things like jsps and templates
>> don't just automatically get used, the webapp has to be redeployed.
>> A pain but something I can live with.
>>
>> As you said, more error handling code would have made this much
>> easier to track down.
>>
>
> Tis done.
>
> Paul.
>