atom feed29 messages in net.java.dev.glassfish.usersRe: JAX-RS on Glassfish 3.1: @EJB inj...
FromSent OnAttachments
glas...@javadesktop.orgJun 15, 2010 6:13 am 
Paul SandozJun 15, 2010 6:32 am 
glas...@javadesktop.orgJun 15, 2010 6:44 am 
Paul SandozJun 15, 2010 7:02 am 
glas...@javadesktop.orgJun 15, 2010 7:12 am 
Paul SandozJun 15, 2010 7:31 am 
glas...@javadesktop.orgJun 15, 2010 8:12 am 
glas...@javadesktop.orgJun 15, 2010 2:02 pm 
glas...@javadesktop.orgJun 15, 2010 2:17 pm 
glas...@javadesktop.orgJun 15, 2010 2:37 pm 
Paul SandozJun 16, 2010 1:49 am 
Paul SandozJun 16, 2010 2:08 am 
glas...@javadesktop.orgJun 16, 2010 5:07 am 
glas...@javadesktop.orgJun 16, 2010 5:25 am 
Paul SandozJun 16, 2010 5:43 am 
Paul SandozJun 16, 2010 5:46 am 
glas...@javadesktop.orgJun 16, 2010 5:58 am 
glas...@javadesktop.orgJun 16, 2010 5:59 am 
Paul SandozJun 16, 2010 7:08 am 
glas...@javadesktop.orgJun 16, 2010 8:02 am 
Paul SandozJun 16, 2010 8:29 am 
glas...@javadesktop.orgJun 16, 2010 8:49 am 
Paul SandozJun 16, 2010 9:20 am 
glas...@javadesktop.orgJun 16, 2010 9:33 am 
Paul SandozJun 16, 2010 9:42 am 
glas...@javadesktop.orgJun 16, 2010 10:15 am 
Paul SandozJun 17, 2010 3:26 am 
glas...@javadesktop.orgJun 17, 2010 5:33 am 
Paul SandozJun 17, 2010 6:06 am 
Subject:Re: JAX-RS on Glassfish 3.1: @EJB injection?
From:Paul Sandoz (Paul@Sun.COM)
Date:Jun 16, 2010 9:42:00 am
List:net.java.dev.glassfish.users

On Jun 16, 2010, at 6:42 PM, glas@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.