David,
While it'd be great to avoid any duplication when (and if) we expose
common services, let's not forget the OSGi requirements in packaging
various dependencies... OSGi doesn't allow to split classes from the
same package across 2 or more bundles, and it doesn't like any
duplications of classes either. We went through the hoops in GlassFish
to be able to duplicate javax.xml.rpc.handler classes in javax.ejb.jar
(so that everything compiles/runs correctly in a Web profile without
JAX-RPC being present) in such a way that only one copy of those classes
are loaded at runtime even when those classes exist as part of jaxrpc
implementation :(
-marina
David Blevins wrote:
> On Sep 30, 2011, at 9:16 PM, Marina Vatkina wrote:
>
>
>> Yes, let's discuss this after J1.
>>
>> Do we want to look at moving contexts that can be useful in other components to some common location? (I know, we are still trying to figure out where that common location will be and how it will be organized...)
>>
>
> I suppose it depends in if we want to bury the "javax.ejb" package.
>
> I have to admit, I'm a little bit looking forward to people's reactions when the see "@javax.ejb.Schedule" or "@javax.ejb.Asynchronous" on a Servlet. Sort of like, hey developer how badly do you want to hate "ejb" :) Bad enough that you aren't going to use it? Really hard to turn down good functionality that's just one little teeny tiny annotation away and you still get to call your component a Servlet.
>
> That said, if we wanted to go away from it, we can, it's just not as fun :)
>
>
>> (It's unfortunate that annotations do not support inheritance...).
>>
>
> Presenting something along these lines on Monday at JavaOne. The "EJB with Meta-Annotations" talk. An experimental idea that allows you to basically rewrap the standard annotations and have them still mean the same thing, just named and grouped as you like.
>
> So instead of using @java.ejb.AccessTimeout you can use something like this:
>
> import javax.ejb.AccessTimeout;
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
>
> @Metatype
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
>
> @AccessTimeout(-1)
> public @interface AwaitForever {
> }
>
> As well as make them simply easier to type:
>
> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
> @Metatype
> @Target({ElementType.METHOD, ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> public static @interface TxRequiresNew {
> }
>
>
> Or perhaps to make them a little more honest:
>
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> @Metatype
> @Target({ElementType.METHOD, ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> public static @interface LazilyIntitializedTransaction {
> }
>
>
> Users could essentially redesign 100% of our annotations to their liking. So rather than make a complete mess out of our own packages by duplicating things or splitting them oddly, we let user's do it.
>
> I proposed something along these lines in EJB 3.1 but it was a bit late to really consider.
>
>
> -David
>
>