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

[Jason Greene]

On Sep 25, 2013, at 8:50 AM, Jason Greene <jason.greene at redhat.com> wrote:

> I think the biggest risk is that those namespaces are reserved. For that reason, we ourselves would never include a configuration for anything non standard. We could restrict the possible bind locations though, or perhaps log a warning. Although that seems to make the feature seem like a hack.
> 
> The more I think about it the more I think option two is better; however, we don't have to use implicit bindings. We could just add the following optional element to the EE subsystem:
>  <default-bindings datasource="java:jboss/blah" jms-conenction-factory=""/>


s/two/three


> 
> On Sep 24, 2013, at 10:00 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
>> Ok, so that's a generic feature.  Seems like a scary generic capability 
>> to me, but I'm not as familiar as you guys are with how these namespaces 
>> work.
>> 
>> On 9/24/13 9:54 AM, David M. Lloyd wrote:
>>> I think it means the config will continue to work just as it does,
>>> except Jeff's error message won't happen anymore.  Bindings in
>>> non-global namespaces would materialize in every instance of that namespace.
>>> 
>>> On 09/24/2013 09:50 AM, Brian Stansberry wrote:
>>>> 3) is confusing. If it's naming binding stuff, putting it in naming or
>>>> in the relevant subsystem seems more intuitive.
>>>> 
>>>> What does 1) really mean in terms of config? Something generic? Or
>>>> something quite specific that results in the appropriate bindings?
>>>> Generic makes me nervous as it opens up a whole new broad feature with
>>>> many possible ways it could be broken.
>>>> 
>>>> I like 1) better than 2) if my concern above can be addressed.
>>>> 
>>>> On 9/24/13 9:12 AM, David M. Lloyd wrote:
>>>>> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
>>>>>> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>>>>>> 
>>>>>> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>>>>>> 
>>>>>> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>>>>>>          <datasources>
>>>>>>          		<default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>>>>>> 		<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>>>>>> 			...
>>>>>> 	        </datasource>
>>>>>>           	...
>>>>>>          </datasources>
>>>>>> </subsystem>
>>>>>> 
>>>>>> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>>>>>> 
>>>>>> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>>>>>> 
>>>>>> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>>>>> 
>>>>> I don't know, I guess I'm running out of opinion on this.
>>>>> 
>>>>> Here's a list of options:
>>>>> 
>>>>> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
>>>>> java:app names, and put config in that subsystem (modify JMS and other
>>>>> subsystems with implicit bindings to do the same)
>>>>> 2) Enhance datasources subsystem to include a default datasource
>>>>> attribute (== XML element) which, when present, will set up implicit
>>>>> bindings for java:comp (and make sure that the config looks/acts
>>>>> similarly between JMS, DS, and any other subsystem with implicit bindings)
>>>>> 3) Decide it's all the EE subsystem and put implicit bindings in there
>>>>> 
>>>>> Decision time: GO!
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat