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

[Brian Stansberry]

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