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!
>
--
- DML