This looks very appealing to me.
On 3 Nov 2011, at 03:30, David Blevins wrote:
>
> On Nov 2, 2011, at 2:23 AM, Adam Bien wrote:
>
>> On that note: we should make the SessionContext @Inject and even the EntityManager (in case there is only a single PU with default) injectable with @Inject.
>> I solve this right now with @Produces - but it could be already provided with the platform.
>>
>> Is it interesting enough to file a JIRA-issue?
>
> There's certainly something to think about at the platform level making more things injectable via @Inject.
>
> The bottom line is things like @PersistenceContext are already a mix of "inject and qualify" with a side of "bind this to jndi".
>
> I'm curious what it would look like if we came up with standard qualifiers. Qualifiers can have parameters, so it could work out.
>
> Theoretically a vendor could add EntityManagers and such to the bean manager loaded up with the standard qualifiers and let the CDI system work out the resolving.
>
> @Unit("movies")
> @Extended
> @Inject
> private EntityManager entityManager
>
> Possibly even drop the @Unit in favor of @Named.
>
> We'd definitely need some concept of standard qualifiers in order to do it for anything that can be a multiple.
>
> The concept of more standard qualifiers is certainly really compelling.
>
>
> -David
>
>> On 30.09.2011, at 10:28, Antonio Goncalves wrote:
>>
>>> I like the idea of having one service one interface. David, when you say "All these would be injectable via @Resource" they could also be injected with @Inject (Principal and UserTransaction already are).
>>>
>>> On Thu, Sep 29, 2011 at 00:33, David Blevins <david.blevins_at_gmail.com> wrote:
>>>
>>> On Sep 28, 2011, at 12:55 AM, Antonio Goncalves wrote:
>>>
>>>> What asynch servlets also have is a timeout (asyncSupported = true, asyncTimeout = 3000). It could also be interesting to have a timeout attribute on @Asynchronous, what do you think ?
>>>
>>> See @javax.ejb.AccessTimeout. It's basically a wrapped version of the TimeUnit/long pair used in the java.util.concurrent APIs. Works for handling all multi-threaded access including @Asynchronous invocations.
>>>
>>> The part that I wonder about is what we might do with the relationship between the Future and javax.ejb.SessionContext. The cancel logic is tied together.
>>>
>>> Still preparing for JavaOne and don't have time for a concrete proposal, but off the top of my head it seems like we might want to start breaking up SessionContext into sub interfaces that are service specific to the related services. We've historically used the SessionContext (or EJBContext) as the way for beans to "talk to the container". We can still follow that pattern (and even keep compatibility) we probably just need to start slicing out methods into more specific interfaces.
>>>
>>> Specifically, perhaps a javax.ejb.AsynchronousContext interface to contain the 'boolean wasCancelCalled();' method and be the container compliment to the javax.ejb.Asynchronous support and container controlled Future object that might be the result of an @Asynchronous call. This could be injected into any object leveraging @Asynchronous support.
>>> We then make javax.ejb.
>>>
>>> package javax.ejb;
>>> public interface AsynchronousContext {
>>> boolean wasCancelCalled();
>>> }
>>>
>>> We then make SessionContext implement that interface:
>>>
>>> public interface SessionContext extends EJBContext, AsynchronousContext {
>>> EJBLocalObject getEJBLocalObject() throws IllegalStateException;
>>>
>>> EJBObject getEJBObject() throws IllegalStateException;
>>>
>>> MessageContext getMessageContext() throws IllegalStateException;
>>>
>>> <T> T getBusinessObject(Class<T> businessInterface);
>>>
>>> Class getInvokedBusinessInterface();
>>> }
>>>
>>> We could follow this pattern as we split up other parts. I can easily imagine the following:
>>>
>>> public interface SessionContext extends javax.ejb.EJBContext, AsynchronousContext {
>>>
>>> EJBLocalObject getEJBLocalObject() throws IllegalStateException;
>>> EJBObject getEJBObject() throws IllegalStateException;
>>>
>>> /**
>>> * These two methods could be interesting to any object using proxies
>>> * They allow the bean to call itself and get container services (interceptors, security, transaction)
>>> * Both are candidates for splitting
>>> */
>>> <T> T getBusinessObject(Class<T> businessInterface);
>>> Class getInvokedBusinessInterface();
>>>
>>> /**
>>> * Already a context object that can just be injected
>>> * No need to split out this method
>>> */
>>> MessageContext getMessageContext() throws IllegalStateException;
>>> }
>>>
>>> public interface AsynchronousContext {
>>> boolean wasCancelCalled();
>>> }
>>>
>>> public interface EJBContext extends SecurityContext, TransactionContext, NamingContext, InterceptorContext {
>>>
>>> EJBHome getEJBHome();
>>> EJBLocalHome getEJBLocalHome();
>>>
>>> /**
>>> * @deprecated
>>> */
>>> Properties getEnvironment();
>>> Identity getCallerIdentity();
>>> boolean isCallerInRole(Identity role);
>>>
>>> /**
>>> * Already a "context" object that can just be injected
>>> * No need to split out this method
>>> */
>>> TimerService getTimerService() throws IllegalStateException;
>>> }
>>>
>>> public interface SecurityContext {
>>> Principal getCallerPrincipal();
>>> boolean isCallerInRole(String roleName);
>>> }
>>>
>>> public interface TransactionContext {
>>> UserTransaction getUserTransaction() throws IllegalStateException;
>>> void setRollbackOnly() throws IllegalStateException;
>>> boolean getRollbackOnly() throws IllegalStateException;
>>> }
>>>
>>> public interface NamingContext {
>>> Object lookup(String name);
>>> }
>>>
>>> public interface InterceptorContext {
>>> Map<String, Object> getContextData();
>>> }
>>>
>>> All these would be injectable via @Resource and have standard names directly under "java:comp/", such as java:comp/AsynchronousContext
>>>
>>>
>>> -David
>>>
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site | Twitter | Blog | LinkedIn | Paris JUG
>>
>>
>