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

[Tomaž Cerar]

I would go with 3)
given that this is EE related thing and other subsystems can also
work/operate in non-EE scenarios.



On Tue, Sep 24, 2013 at 4:12 PM, David M. Lloyd <david.lloyd at redhat.com>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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130924/3420c55d/attachment.html