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

[Eduardo Martins]

Forget these 2 concerns, there is a way to easily get around both. Personally I think I we could go with 1) or 3) since that allows a single logic to be applied to all. 1) has the advantage of not needing any change in subsystem configs (just the impl in naming changes), while 3) has the advantage of not opening the door to wild hacks. 

Time for a final decision?

--E
 
On Sep 24, 2013, at 8:13 PM, Eduardo Martins <emartins at redhat.com> wrote:

> 
> On Sep 24, 2013, at 7:27 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
>> On 09/24/2013 01:03 PM, Eduardo Martins wrote:
>>> +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.
>> 
>> I believe this statement to be patently false.  The only case this might 
>> be true is WARs - but in a WAR, java:comp is just an alias for 
>> java:module so the same logic will always work in either case.  Now it 
>> may in fact be possible to create a conflicting binding, but that's a 
>> different problem.
> 
> 
> I wonder what in my statement is false :-) 
> Anyway, such conflict is why I said the generic blind bind may not be an option, since for components where java:comp is not the same as java:module we should not bind at java:module too. Obviously one could ask what would be the chance of we ever need to care about it...
> 
>> 
>>> 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.
>> 
>> Let's just take one step at a time OK? :-)
> 
> I think we should cover all features we plan to have related with this change, otherwise we may end up changing configs in multiple subsystems, which bring new schemas, transformers, test code etc.
> 
> --E
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev