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(a)redhat.com> wrote:
On Sep 24, 2013, at 7:27 PM, David M. Lloyd <david.lloyd(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev