[wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...
Eduardo Martins
emartins at redhat.com
Tue Sep 24 14:03:16 EDT 2013
+1
There are two other concerns I have with 3):
1) EE binds are done at java:comp or java:module, depending on module/component. Generic blind binding in every instance of a namespace may not be an option for the EE default bindings.
2) Overridden of defaults through jboss app and jboss component xml descriptors, something I have planned for EE Concurrency default binds, may be much more complex to achieve.
I still like the feature, but think it will not help that much for handling EE default bindings.
--E
On Sep 24, 2013, at 4:00 PM, 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
More information about the wildfly-dev
mailing list