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

[David M. Lloyd]

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.

-- 
- DML