]
Romain Manni-Bucau commented on CDI-409:
----------------------------------------
Hi
I think it is not a CDI issue but a EE issue. Basically CDI is just a client for these
resources which are not CDI beans and these resources mainly rely on JNDI to get an
@Alternative behavior. Mixing both is IMO not sane since it will lead to mix and create
cycles between specs which finally leads to weird behavior(s) at deployment or worse at
runtime.
A convention to declare a resource as cdi bean through a particular qualifier maybe sounds
more pragmatic to me, wdyt?
Having @Alternatives for resource definition
--------------------------------------------
Key: CDI-409
URL:
https://issues.jboss.org/browse/CDI-409
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: TBD
Reporter: Antonio Goncalves
Java EE 6 introduced @DataSourceDefinition and Java EE 7 introduced the same way of
defining other resources (JMS factory/destination, Mail factory, JCA connectors....).
It would be interesting to have @Alternatives working with these resource definitions.
For example you could have a default DS for development :
{code}
@DataSourceDefinition(
className = "org.apache.derby.jdbc.EmbeddedDataSource",
name = "java:global/jdbc/devDS",
user = "dev",
password = "dev",
databaseName = "dev",
properties = {"connectionAttributes=;create=true"}
)
public class DevResources {...}
{code}
And another DS that would be used, let say, in production as an alternative :
{code}
@Alternative
@DataSourceDefinition(
className = "org.apache.derby.jdbc.EmbeddedDataSource",
name = "java:global/jdbc/prodDS",
user = "prod",
password = "prod",
databaseName = "prod",
properties = {"connectionAttributes=;create=true"}
)
public class ProdResources {...}
{code}
--
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: