[wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

[Jeff Mesnil]

On 23 Sep 2013, at 17:38, "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> On 09/23/2013 10:31 AM, Jeff Mesnil wrote:
>> 
>> On 23 Sep 2013, at 17:14, Jaikiran Pai <jpai at 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.

I'm not sure to have understood you correctly but I'm not able to add a java:comp entry in the naming subsystem:

[standalone at localhost:9990 /] /subsystem=naming/binding="java:comp/DefaultJMSConnectionFactory":add(binding-type=lookup, lookup=java:jboss/DefaultJMSConnectionFactory)
{
    "outcome" => "failed",
    "failure-description" => "JBAS011864: Invaliding binding name java:comp/DefaultJMSConnectionFactory, name must start with one of [java:global, java:jboss, java:/]",
    "rolled-back" => true
}

That's why I added the DeploymentUnitProcessor to the messaging subsystem, to be able to add this lookup to the deployed component namespace.

But if there is a simpler/cleaner way to do it, I can change this.

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/