On Aug 9, 2010, at 12:52 PM, Jarek Gawor wrote: > It is. But I think OpenEJB is a bit different since it can be deployed > in different environments, e.g. Tomcat. If we go #2 it would require a > bit more configuration from the user to get OpenEJB running. It > wouldn't be as easy as it is now. > In Geronimo we control everything so #2 works fine for us.
Right, #1 would be more consistent on how OpenEJB tackles this kind of thing. On a similar note, we don't require a Java Agent either. Any serious usage of course should involve a javaagent if OpenJPA is the provider, but we don't require it to kick the tires. The mantra as always; be as invisible as possible. -David > On Mon, Aug 9, 2010 at 3:43 PM, David Jencks <[email protected]> wrote: >> I'd prefer #2. Isn't this what we do in geronimo? >> >> thanks >> david jencks >> >> On Aug 9, 2010, at 11:52 AM, Jarek Gawor wrote: >> >>> Hi, >>> >>> I can't really find a reference to it in the EJB 3.1 spec, but I'm >>> pretty sure EJB 3.1 needs to support the @Resource annotation from the >>> Common Annotations 1.1 spec. One of the new things in 1.1 spec is the >>> 'lookup' attribute on the Resource annotation. OpenEJB will need to >>> recognize & support that attribute. Here's one problem: Java 6 >>> provides Common Annotation 1.0 classes. So in order to support >>> @Resource.lookup attribute we will need to 1) use reflection to get >>> the 'lookup' attribute value OR 2) configure the compiler, surefire, >>> etc. maven plugins to execute with appropriate java.endorsed.dirs >>> settings so that right version of Common Annotation is used. >>> >>> I'm wondering which solution is a preferred solution. #1 seems much >>> easier. Also, if we go with #2 then deploying OpenEJB in e.g. Tomcat >>> might be a bit more difficult since the JVM will also need to be >>> configured to use the right annotation spec. >>> >>> Thoughts? >>> >>> Jarek >> >> >
