On Jun 16, 2010, at 6:42 PM, glassfish_at_javadesktop.org wrote:
>>> I am not sure what all the bugs are. I will say
>> that I followed the
>>> publishing guidelines in the JAX-RS specification
>> to the letter.
>>> The only "gray area" that I know of involves
>> packaging resource
>>> classes in the lib directory, which appears to be
>> permitted by the
>>> specifications, but does not work here.
>>>
>>
>> This is indeed a gray area but since you can do this:
>>
>> @ApplicationPath("/frobnication")
>> public class Application extends
>> javax.ws.rs.core.Application {
>> public Set<Class<?>> getClasses() {
>> return Collections.<Class<?
>> ingleton(FrobnicatorResource.class);
>> }
>> would expect it to work.
>
> Yes. The problem is that this is for a big application where, by
> design, we don't know what all the modules are for a given .ear file
> until deployment time. So we're going to rely on scanning, as I
> believe the specification implies we can.
Yes.
> (If you return an empty set from both getClasses() and
> getSingletons() the classpath (there's the gray area) is scanned, as
> you know--the issue here is: is the classpath limited to the war
> file's lib and classes directories, or, instead, should it
> incorporate the ear/lib directory as well? As we've already
> discussed we both suspected that ear/lib should work; it doesn't.)
>
>>> Will you, Paul, file the requisite bugs?
>>
>> Blimey where to start... this is gonna take some time
>> for me as it
>> will require precise reproducible test cases, and
>> time is a scarce
>> resource for me...
>
> I didn't mean to push work on you; I just meant that you seem to
> already have a faint suspicion of where the problems lie. It's not
> a big deal; I can submit bugs and you can correct/edit them where
> I've made mistakes.
Thanks! please CC me on logged bugs that is a better way for me to
contribute. Tomorrow i can try and summarize things.
> I am currently planning on filing them against the webservices
> component, although I don't see your name on the CC list so that may
> not be the right component.
I am the JAX-RS/Jersey person :-) i dived in because JAX-RS/Jersey was
involved. But i think these issues we are encountering are related to
GlassFish and not to JAX-RS/Jersey.
>
>> BTW I suspect it may be much easier if you avoid
>> using an ear. With
>> EJB 3.1 it is not always necessary to use an ear.
>
> Need the .ear file because of a resource adapter among other reasons.
>
OK.
Paul.