[jboss-jira] [JBoss JIRA] (AS7-6215) Ability to declare a dependency on a service name

[Stuart Douglas (JIRA)]

    [ https://issues.jboss.org/browse/AS7-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744210#comment-12744210 ] 

Stuart Douglas commented on AS7-6215:
-------------------------------------

Is this datasource actually being injected, or just looked up manually? If it is injected then this should not be a problem. 

So there are several parts to this issue, I am going to list them here:

1) Dependencies on an injected resource:

For everything except an EJB this should work as expected. For EJB's however the @DependsOn annotation has to be explicitly specified. This is because otherwise EJB's cannot inject references to each other without causing circular dependencies. Injecting an EJB in this manner actually creates a dependency on the EJB view, which has a different lifecycle to the actual EJB component instance. 

As DependsOn only works with EJB's at the moment we have no way for other components such as servlets to express a dependency on an EJB.

2) Using the JNDI name method combined with @DependsOn mentioned above:

This does not actually really by us anything. To get a dependency on a JNDI all that is really required is a class level @Resource annotation. This still won't help with EJB's, as the underlying EJB's have a different lifecycle to the JNDI bindings. 

3) Using the @DependsOn with a service name based approach mentioned above:

This would allow EJB's to depend on other EJB's, although for the most part this is already allowed via @DependsOn. All this would really buy is the ability to depend on EJB's that are outside the current deployment, and would also allow you to workaround any missing dependency server bugs. 


As far as I can see data sources EJB should not be a problem, as they already have dependencies setup, so it is really just EJB's that have this problem. 

Thinking about it I think we should just do the following:

- For non-EJB components using @EJB injection setup a dependency on the underlying EJB by default, as there is no risk of circular dependencies (as an EJB can't inject a servlet). We will probably only be able to do this for the ejb name version of the lookup, rather than the JNDI name one. 

EJB's can continue to use @DependsOn as per normal to express dependencies. 

- Extend the EJB name syntax to allow lookup of EJB's outside the current deployment. For example using @EJB or @DependsOn you can currently do:

../myModule#MyEjb

I think this should be expanded to allow:

../../myApplication/myModule#myEjb

To me this seems like the best way to resolve the issue, as I don't think the existing proposals address the underlying issue. 

Incidentally it is currently possible to setup indirect dependencies between components by using @Resource in the dependent component, and then binding a value in the @PostConstruct of the dependee component, although this will only work if you bind a non-simple type. 











                
> Ability to declare a dependency on a service name
> -------------------------------------------------
>
>                 Key: AS7-6215
>                 URL: https://issues.jboss.org/browse/AS7-6215
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.1.3.Final (EAP)
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: Open To Community
>
>
> We have several use cases where we need dependencies between different deployments.
> Such as
> Singleton in ear1 which injects an ejb from ear2 using @EJB.  At shutdown we need the Singleton to call a method to clean up on the ejb, however the ejb is sometimes shutdown before the Singleton.  Using @DependsOn would allow the Singleton to depend on the EJB if the EJB is in the same ear as the Singleton, however it is not.
> There are other use cases where resources are injected and we need the resources to still be deployed at shutdown so we can clean up the resources before they are undeployed.
> Having a service name to depend on would be useful and if the name was configurable such that it does not based on the exact name of the deployment, it would be useful as using maven changes the deployment names when we rebuild and we do not want to have to change the code each time we rebuild.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira