<div dir="ltr">I would go with 3) <br>given that this is EE related thing and other subsystems can also work/operate in non-EE scenarios.<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 24, 2013 at 4:12 PM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 09/24/2013 05:14 AM, Eduardo Martins wrote:<br>
> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...<br>
><br>
> 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:<br>
><br>
> <subsystem xmlns="urn:jboss:domain:datasources:2.0"><br>
> <datasources><br>
> <default-datasource jndi-name="java:jboss/datasources/ExampleDS" /><br>
> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true"><br>
> ...<br>
> </datasource><br>
> ...<br>
> </datasources><br>
> </subsystem><br>
><br>
> 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).<br>
><br>
> 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<br>
><br>
> 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<br>
<br>
</div></div>I don't know, I guess I'm running out of opinion on this.<br>
<br>
Here's a list of options:<br>
<br>
1) Enhance naming subsystem to be able to bind java:comp, java:module,<br>
java:app names, and put config in that subsystem (modify JMS and other<br>
subsystems with implicit bindings to do the same)<br>
2) Enhance datasources subsystem to include a default datasource<br>
attribute (== XML element) which, when present, will set up implicit<br>
bindings for java:comp (and make sure that the config looks/acts<br>
similarly between JMS, DS, and any other subsystem with implicit bindings)<br>
3) Decide it's all the EE subsystem and put implicit bindings in there<br>
<br>
Decision time: GO!<br>
<span class="HOEnZb"><font color="#888888">--<br>
- DML<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>