[cdi-dev] Standrdization of option to disable CDI for all app modules in single file?
Romain Manni-Bucau
rmannibucau at gmail.com
Tue Mar 15 18:11:31 EDT 2016
tomee has something but makes applications not portable for a common
use case so having something at EE level would be great.
Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber
2016-03-15 23:06 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:
> But if its an app server specific thing, I would expect the app server to
> support it no?
> Wildfly has a config, glassfish had a config last I looked (was a long while
> ago).
>
> John
>
>
> On Tue, Mar 15, 2016 at 2:06 PM Mark Struberg <struberg at yahoo.de> wrote:
>>
>> In Apache OpenWebBeans we have a mode
>>
>> org.apache.webbeans.scanBeansXmlOnly
>>
>> See http://openwebbeans.apache.org/owbconfig.html
>>
>>
>> Maybe Weld could implement something similar?
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Tuesday, 15 March 2016, 18:20, Romain Manni-Bucau
>> <rmannibucau at gmail.com> wrote:
>>
>>
>> >
>> >
>> >Hi Ondrej,
>> >
>> >
>> >would it be possible to push it on ee list too? Scanning is not limited
>> > to CDI and at EE level EJB, Servlet etc... can get the exact same issue. A
>> > global scanning config would benefit the whole platform and CDI could just
>> > reuse it when not in EE.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau | Blog | Github | LinkedIn | Tomitriber
>> >
>> >2016-03-15 18:12 GMT+01:00 Ondrej Mihályi <ondrej.mihalyi at gmail.com>:
>> >
>> >Hi,
>> >>
>> >>
>> >>Some Java EE 6 apps still have issues with implicit scanning, even
>> though they don't use guava and sometimes it is not possible to put
>> beans.xml file into the problematic JARs. People are having issues with
>> this when migrating to Glassfish 4 or Payara from Glassfish 3.
>> >>
>> >>
>> >>With Payara server, we are thinking of
>> creating an option in server-specific app descriptor to disable CDI
>> completely either for whole application or just for specific modules.
>> >>
>> >> I think it would make sense to consider some standardization of this
>> >> approach in CDI 2, as I've seen issues with this on stackoverflow also with
>> >> other app servers. Or is it already planned?
>> >>
>> >>
>> >>Ondrej
>> >>
>> >>_______________________________________________
>> >>cdi-dev mailing list
>> >>cdi-dev at lists.jboss.org
>> >>https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>
>> >>Note that for all code provided on this list, the provider licenses the
>> >> code under the Apache License, Version 2
>> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> >> provided on this list, the provider waives all patent and other intellectual
>> >> property rights inherent in such information.
>> >>
>> >
>> >
>> >_______________________________________________
>> >cdi-dev mailing list
>> >cdi-dev at lists.jboss.org
>> >https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> >Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> > provided on this list, the provider waives all patent and other intellectual
>> > property rights inherent in such information.
>> >
>> >
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
More information about the cdi-dev
mailing list