12:12 p.m.
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.
<https://javaee-wg.slack.com/archives/cdi2_0-jsr-365/p1458060907000004>
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
12:19 p.m.
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 <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
|
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-03-15 18:12 GMT+01:00 Ondrej Mihályi <ondrej.mihalyi(a)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.
<https://javaee-wg.slack.com/archives/cdi2_0-jsr-365/p1458060907000004>
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(a)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.
1:06 p.m.
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(a)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(a)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(a)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(a)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.
5:06 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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.
5:11 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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.
5:13 p.m.
New subject: Standrdization of option to disable CDI for all appmodules in single file?
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(a)gmail.com>
Odoslané: 15.3.2016 23:06
Komu: "Mark Struberg" <struberg(a)yahoo.de>; "Romain Manni-Bucau"
<rmannibucau(a)gmail.com>; "Ondrej Mihályi"
<ondrej.mihalyi(a)gmail.com>
Kópia: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)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(a)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(a)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(a)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(a)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(a)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(a)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.
5:04 p.m.
Possted also on Java EE mailing list:
https://java.net/projects/javaee-spec/lists/users/archive/2016-03/message/12
2016-03-15 18:19 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com>:
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 <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-03-15 18:12 GMT+01:00 Ondrej Mihályi <ondrej.mihalyi(a)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.
> <https://javaee-wg.slack.com/archives/cdi2_0-jsr-365/p1458060907000004>
>
> 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(a)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.
>
3098
days inactive
3098
days old
6 comments
4 participants
participants (4)
-
John D. Ament -
Mark Struberg -
Ondrej Mihályi -
Romain Manni-Bucau