Is this in regards to the service splitting or the meta-annotation concept?
For the service splitting I had imagined we'd not split packages and leave everything where it currently is. At least where the respective annotations live.
I.e.
public interface EJBContext extends javax.ejb.TransactionContext...
public interface SessionContext extends javax.ejb.AsynchronousContext ...
Giving us:
javax.ejb.TransactionManagement
javax.ejb.TransactionAttribute
javax.ejb.TransactionContext
javax.ejb.Asynchronous
javax.ejb.AsynchronousContext
-David
On Oct 5, 2011, at 5:19 PM, Marina Vatkina wrote:
> 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
>>
>>