[cdi-dev] Standrdization of option to disable CDI for all appmodules in single file?

Ondrej Mihályi ondrej.mihalyi at gmail.com
Tue Mar 15 18:13:55 EDT 2016


My point is that it is not standardized.

Another point is, that almost no app server provides an option to declare this inside the app archive (WAR). You need to set it through app server configuration, which is often error prone, if not unacceptable in certain scenarios.

S pozdravom,
Ondrej Mihályi 

----- Pôvodná správa -----
Od: "John D. Ament" <john.d.ament at gmail.com>
Odoslané: ‎15.‎3.‎2016 23:06
Komu: "Mark Struberg" <struberg at yahoo.de>; "Romain Manni-Bucau" <rmannibucau at gmail.com>; "Ondrej Mihályi" <ondrej.mihalyi at gmail.com>
Kópia: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
Predmet: Re: [cdi-dev] Standrdization of option to disable CDI for all appmodules in single file?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/3a9f3625/attachment.html 


More information about the cdi-dev mailing list