On 09/23/2013 10:31 AM, Jeff Mesnil wrote:
On 23 Sep 2013, at 17:14, Jaikiran Pai <jpai(a)redhat.com> wrote:
> On Monday 23 September 2013 08:34 PM, Jesper Pedersen wrote:
>> On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
>>> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>>>> I'm kind of caught on this requirement, since we already have a JPA
>>>> level default datasource setting (for JPA container deployment). I need
>>>> to know if we are going to add a default datasource
>>>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with
that.
>>> I think we should add support for java:comp/DefaultDataSource since it's
>>> required by spec. Furthermore, this isn't essentially just JPA thing
>>> since such and injected/lookedup datasource could even be used in a
>>> non-JPA application.
>> I think the best solution is to add an element in the :ee: subsystem
>> that points to a JNDI name defined in the :datasources: subsystem.
> I don't think we need any configuration in this case since the spec
> states that the product vendor just make available a pre-configured
> datasource (which we already do) under that JNDI name (right now we do
> in under a JBoss specific JNDI name). So I think it can be as simple as
> a linkref kind of thing within the code where we point
fwiw, the EE spec also mandates that a default JMS connection factory must be available
to deployments at "java:comp/DefaultJMSConnectionFactory".
I added in the messaging subsystem a DeploymentUnitProcessor[1] that create binding
configurations for our JMS ConnectionFactory defined in the profile at
"java:jboss/DefaultJMSConnectionFactory"
to make it available under the standard
"java:comp/DefaultJMSConnectionFactory"
It might have been better to do this in configuration as well. I think
in general we should avoid making automatic bindings that cannot be
disabled; and if they *can* be disabled it is better to do it in a
uniform way (i.e. use the naming subsystem) instead of having a zillion
disable-xyz config attributes.
--
- DML