3:59 p.m.
I have a portable extension not annotated in any way. It has a nested
class inside it named Producers. That class is annotated with @Singleton
(and nothing else). It has producer methods in it. They are being
discovered while a bean discovery mode of "annotated" is in effect. Is
this correct?
(CDI 2.0-PRD.)
Best,
Laird
4:18 p.m.
On Sun, Mar 19, 2017 at 1:59 PM Laird Nelson <ljnelson(a)gmail.com> wrote:
I have a portable extension not annotated in any way. It has a
nested
class inside it named Producers. That class is annotated with @Singleton
(and nothing else). It has producer methods in it. They are being
discovered while a bean discovery mode of "annotated" is in effect. Is
this correct?
(This also happens if I remove the @Singleton annotation. That is, if I
just have a private static (nested) class named Producers defining
@Produces-annotated methods in my portable extension class.)
Best,
Laird
2:26 a.m.
Hi Laird,
Weld version? Environment? Deployment structure?
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.
Martin
Dne 19.3.2017 v 22:18 Laird Nelson napsal(a):
On Sun, Mar 19, 2017 at 1:59 PM Laird Nelson <ljnelson(a)gmail.com
<mailto:ljnelson@gmail.com>> wrote:
I have a portable extension not annotated in any way. It has a
nested class inside it named Producers. That class is annotated
with @Singleton (and nothing else). It has producer methods in it.
They are being discovered while a bean discovery mode of "annotated"
is in effect. Is this correct?
(This also happens if I remove the @Singleton annotation. That is, if I
just have a private static (nested) class named Producers defining
@Produces-annotated methods in my portable extension class.)
Best,
Laird
_______________________________________________
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.
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
10:12 a.m.
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba <mkouba(a)redhat.com> wrote:
Weld version? Environment? Deployment structure?
3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
I think the Producers class should not be discovered. So it looks
like a
bug or misconfiguration.
Thank you; I'll file a bug once I have time to put together a test case.
Best,
Laird
12:21 p.m.
Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI,
or is this within a container (and I'm guessing some custom integration)? If
you're using SE, what does your SEContainerInitializer lines look like?
John
________________________________
From: cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org> on behalf of
Laird Nelson <ljnelson(a)gmail.com>
Sent: Monday, March 20, 2017 11:12 AM
To: Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba
<mkouba@redhat.com<mailto:mkouba@redhat.com>> wrote:
Weld version? Environment? Deployment structure?
3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.
Thank you; I'll file a bug once I have time to put together a test case.
Best,
Laird
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
12:24 p.m.
SE, and the initializer is brain-dead simple.
final SeContainerInitializer initializer =
SeContainerInitializer.newInstance();
assert initializer != null;
try (final SeContainer container = initializer.initialize()) {
assert container != null;
}
Best,
Laird
On Mon, Mar 20, 2017 at 10:21 AM John Ament <john.ament(a)spartasystems.com>
wrote:
Since you're mentioning a fledgling project and CDI 2.0, are you
using SE
mode of CDI, or is this within a container (and I'm guessing some custom
integration)? If you're using SE, what does your SEContainerInitializer
lines look like?
John
------------------------------
*From:* cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org>
on behalf of Laird Nelson <ljnelson(a)gmail.com>
*Sent:* Monday, March 20, 2017 11:12 AM
*To:* Martin Kouba; cdi-dev
*Subject:* Re: [cdi-dev] Bean discovery question
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba <mkouba(a)redhat.com> wrote:
Weld version? Environment? Deployment structure?
3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.
Thank you; I'll file a bug once I have time to put together a test case.
Best,
Laird
------------------------------
NOTICE: This e-mail message and any attachments may contain confidential,
proprietary, and/or privileged information which should be treated
accordingly. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this message, and destroy all
physical and electronic copies. Thank you.
12:42 p.m.
So I just tried locally with Weld 3.0 CR2
public class BeanDiscoverer implements Extension {
public void onBeans(@Observes ProcessBean<?> pb) {
}
@Singleton
public static class Producers {
}
public static void main(String...args) {
final SeContainer initialize = SeContainerInitializer.newInstance().initialize();
final Producers producers = initialize.select(Producers.class).get();
assert producers == null;
initialize.close();
}
}
And it correctly throws
Exception in thread "main"
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied
dependencies for type Producers with qualifiers
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110)
at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown hook because JVM
is shutting down. Using SimpleLogger
Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by shutdown hook
Even when I explicitly add the extension, same thing occurs
(.addExtensions(BeanDiscoverer.class)). Even when I explicitly add to
META-INF/services/Extension it fails.
This is what my beans.xml looks like:
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
bean-discovery-mode="annotated" version="2.0">
</beans>
Only when I change to all does it run fine... You can see the full example at
https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2confer...
so I'm curious to know if there's anything different between our setups.
John
________________________________
From: Laird Nelson <ljnelson(a)gmail.com>
Sent: Monday, March 20, 2017 1:24 PM
To: John Ament; Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
SE, and the initializer is brain-dead simple.
final SeContainerInitializer initializer = SeContainerInitializer.newInstance();
assert initializer != null;
try (final SeContainer container = initializer.initialize()) {
assert container != null;
}
Best,
Laird
On Mon, Mar 20, 2017 at 10:21 AM John Ament
<john.ament@spartasystems.com<mailto:john.ament@spartasystems.com>> wrote:
Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI,
or is this within a container (and I'm guessing some custom integration)? If
you're using SE, what does your SEContainerInitializer lines look like?
John
________________________________
From: cdi-dev-bounces@lists.jboss.org<mailto:cdi-dev-bounces@lists.jboss.org>
<cdi-dev-bounces@lists.jboss.org<mailto:cdi-dev-bounces@lists.jboss.org>> on
behalf of Laird Nelson <ljnelson@gmail.com<mailto:ljnelson@gmail.com>>
Sent: Monday, March 20, 2017 11:12 AM
To: Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba
<mkouba@redhat.com<mailto:mkouba@redhat.com>> wrote:
Weld version? Environment? Deployment structure?
3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.
Thank you; I'll file a bug once I have time to put together a test case.
Best,
Laird
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
12:50 p.m.
Very odd. OK. Here's my META-INF/beans.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
version="2.0"
bean-discovery-mode="annotated">
</beans>
…and here is a cut down, won't-compile gist of my extension class:
public class MavenExtension implements Extension {
public MavenExtension() {
super();
}
private final void beforeBeanDiscovery(@Observes final
BeforeBeanDiscovery event) {
if (event != null) {
//
// Types effectively bound by DefaultServiceLocator
//
event.addAnnotatedType(DefaultArtifactResolver.class,
"maven").add(SingletonLiteral.INSTANCE);
// and so on
}
private static final class Producers {
@Produces
@Singleton
private static final ModelInterpolator produceModelInterpolator(final
UrlNormalizer normalizer, final PathTranslator pathTranslator) {
return new
StringSearchModelInterpolator().setPathTranslator(pathTranslator).setUrlNormalizer(normalizer);
}
}
}
Also if it matters my main loop does nothing. In other words, the test
starts the container and closes it—which boots the extension of course,
whereupon I notice that my Producers class gets picked up. I would have
expected that I would have to programmatically add my Producers class for
its producer methods to be "seen", but I don't have to. That seems odd to
me.
(Frankly, what I *really* want is for those producer methods, all of which
are static, to just be members of my extension class, but they are not seen
in this case.)
Best,
Laird
On Mon, Mar 20, 2017 at 10:42 AM John Ament <john.ament(a)spartasystems.com>
wrote:
So I just tried locally with Weld 3.0 CR2
public class BeanDiscoverer implements Extension {
public void onBeans(@Observes ProcessBean<?> pb) {
}
@Singleton
public static class Producers {
}
public static void main(String...args) {
final SeContainer initialize =
SeContainerInitializer.newInstance().initialize();
final Producers producers =
initialize.select(Producers.class).get();
assert producers == null;
initialize.close();
}
}
And it correctly throws
Exception in thread "main"
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334:
Unsatisfied dependencies for type Producers with qualifiers
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110)
at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown
hook because JVM is shutting down. Using SimpleLogger
Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by
shutdown hook
Even when I explicitly add the extension, same thing occurs
(.addExtensions(BeanDiscoverer.class)).
Even when I explicitly add to META-INF/services/Extension it fails.
This is what my beans.xml looks like:
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
bean-discovery-mode="annotated" version="2.0">
</beans>
Only when I change to all does it run fine... You can see the full
example at
https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2confer...
so
I'm curious to know if there's anything different between our setups.
John
------------------------------
*From:* Laird Nelson <ljnelson(a)gmail.com>
*Sent:* Monday, March 20, 2017 1:24 PM
*To:* John Ament; Martin Kouba; cdi-dev
*Subject:* Re: [cdi-dev] Bean discovery question
SE, and the initializer is brain-dead simple.
final SeContainerInitializer initializer =
SeContainerInitializer.newInstance();
assert initializer != null;
try (final SeContainer container = initializer.initialize()) {
assert container != null;
}
Best,
Laird
On Mon, Mar 20, 2017 at 10:21 AM John Ament <john.ament(a)spartasystems.com>
wrote:
Since you're mentioning a fledgling project and CDI 2.0, are you using SE
mode of CDI, or is this within a container (and I'm guessing some custom
integration)? If you're using SE, what does your SEContainerInitializer
lines look like?
John
------------------------------
*From:* cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org>
on behalf of Laird Nelson <ljnelson(a)gmail.com>
*Sent:* Monday, March 20, 2017 11:12 AM
*To:* Martin Kouba; cdi-dev
*Subject:* Re: [cdi-dev] Bean discovery question
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba <mkouba(a)redhat.com> wrote:
Weld version? Environment? Deployment structure?
3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.
Thank you; I'll file a bug once I have time to put together a test case.
Best,
Laird
------------------------------
NOTICE: This e-mail message and any attachments may contain confidential,
proprietary, and/or privileged information which should be treated
accordingly. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this message, and destroy all
physical and electronic copies. Thank you.
------------------------------
NOTICE: This e-mail message and any attachments may contain confidential,
proprietary, and/or privileged information which should be treated
accordingly. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this message, and destroy all
physical and electronic copies. Thank you.
12:56 p.m.
For me, that still doesn't discover. The only thing I can think of is that the JAR
that includes StringSearchModelInterpolator may have a beans.xml (does it?) Also, what
bean are you checking for, producers or ModelInterpolator ?
Also, I like your idea of explicitly allowing extensions to have producer methods. We
treat extensions as app scoped beans, so why not add that support? Do you want to create
a JIRA for that?
John
________________________________
From: Laird Nelson <ljnelson(a)gmail.com>
Sent: Monday, March 20, 2017 1:50 PM
To: John Ament; Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
Very odd. OK. Here's my META-INF/beans.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
version="2.0"
bean-discovery-mode="annotated">
</beans>
…and here is a cut down, won't-compile gist of my extension class:
public class MavenExtension implements Extension {
public MavenExtension() {
super();
}
private final void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery event) {
if (event != null) {
//
// Types effectively bound by DefaultServiceLocator
//
event.addAnnotatedType(DefaultArtifactResolver.class,
"maven").add(SingletonLiteral.INSTANCE);
// and so on
}
private static final class Producers {
@Produces
@Singleton
private static final ModelInterpolator produceModelInterpolator(final UrlNormalizer
normalizer, final PathTranslator pathTranslator) {
return new
StringSearchModelInterpolator().setPathTranslator(pathTranslator).setUrlNormalizer(normalizer);
}
}
}
Also if it matters my main loop does nothing. In other words, the test starts the
container and closes it—which boots the extension of course, whereupon I notice that my
Producers class gets picked up. I would have expected that I would have to
programmatically add my Producers class for its producer methods to be "seen",
but I don't have to. That seems odd to me.
(Frankly, what I really want is for those producer methods, all of which are static, to
just be members of my extension class, but they are not seen in this case.)
Best,
Laird
On Mon, Mar 20, 2017 at 10:42 AM John Ament
<john.ament@spartasystems.com<mailto:john.ament@spartasystems.com>> wrote:
So I just tried locally with Weld 3.0 CR2
public class BeanDiscoverer implements Extension {
public void onBeans(@Observes ProcessBean<?> pb) {
}
@Singleton
public static class Producers {
}
public static void main(String...args) {
final SeContainer initialize = SeContainerInitializer.newInstance().initialize();
final Producers producers = initialize.select(Producers.class).get();
assert producers == null;
initialize.close();
}
}
And it correctly throws
Exception in thread "main"
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied
dependencies for type Producers with qualifiers
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110)
at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown hook because JVM
is shutting down. Using SimpleLogger
Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by shutdown hook
Even when I explicitly add the extension, same thing occurs
(.addExtensions(BeanDiscoverer.class)). Even when I explicitly add to
META-INF/services/Extension it fails.
This is what my beans.xml looks like:
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
bean-discovery-mode="annotated" version="2.0">
</beans>
Only when I change to all does it run fine... You can see the full example at
https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2confer...
so I'm curious to know if there's anything different between our setups.
John
________________________________
From: Laird Nelson <ljnelson@gmail.com<mailto:ljnelson@gmail.com>>
Sent: Monday, March 20, 2017 1:24 PM
To: John Ament; Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
SE, and the initializer is brain-dead simple.
final SeContainerInitializer initializer = SeContainerInitializer.newInstance();
assert initializer != null;
try (final SeContainer container = initializer.initialize()) {
assert container != null;
}
Best,
Laird
On Mon, Mar 20, 2017 at 10:21 AM John Ament
<john.ament@spartasystems.com<mailto:john.ament@spartasystems.com>> wrote:
Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI,
or is this within a container (and I'm guessing some custom integration)? If
you're using SE, what does your SEContainerInitializer lines look like?
John
________________________________
From: cdi-dev-bounces@lists.jboss.org<mailto:cdi-dev-bounces@lists.jboss.org>
<cdi-dev-bounces@lists.jboss.org<mailto:cdi-dev-bounces@lists.jboss.org>> on
behalf of Laird Nelson <ljnelson@gmail.com<mailto:ljnelson@gmail.com>>
Sent: Monday, March 20, 2017 11:12 AM
To: Martin Kouba; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba
<mkouba@redhat.com<mailto:mkouba@redhat.com>> wrote:
Weld version? Environment? Deployment structure?
3.0.0-CR2 (CDI 2.0-PFD).
Fledgling project containing only the extension at the moment, so no beans.
I think the Producers class should not be discovered. So it looks like a
bug or misconfiguration.
Thank you; I'll file a bug once I have time to put together a test case.
Best,
Laird
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
2:47 p.m.
On Mon, Mar 20, 2017 at 10:56 AM John Ament <john.ament(a)spartasystems.com>
wrote:
For me, that still doesn't discover. The only thing I can think
of is
that the JAR that includes StringSearchModelInterpolator may have a
beans.xml (does it?)
No.
I spoke with John off-list; wanted to shed more light on my setup.
I pushed a shaky incomplete version of what I'm doing here:
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java...
The purpose of this frightening :-) extension is uninteresting for the
subject under discussion here. Briefly, it does just enough Plexus
annotation processing to be mildly dangerous and break things in cool ways,
and no more.
The test method is here:
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/test/java...
Note in particular the main method is not in this project. It is in this
one, which is a test-scoped dependency:
https://github.com/ljnelson/microbean-main/blob/master/src/main/java/org/...
That project's META-INF/beans.xml has bean discovery set to none (
https://github.com/ljnelson/microbean-main/blob/master/src/main/resources...),
since there are no beans in that bean archive (it houses only the main
class). John indicated that this was likely the source of the problem:
"Ok, knowing that this is the setup helps out dramatically. If I had to
guess, the case of having the beans.xml from the main set to none is what's
causing this. I remember Martin mentioned some issues with SE originally
when I pushing [*sic*] that by default we should do discovery. My guess is
that Weld is seeing the beans.xml from the root component [microbean-main]
and actually falling back to the CDI 1.0 discovery behavior."
This project's META-INF/beans.xml has bean discovery of "annotated" (
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/reso...),
though I confess that's mostly because I just wanted to use the default
behavior, not because I carefully considered whether that was something I
should use here or not. In any event, I don't anticipate there being any
classes in this project with bean-defining annotations on them, nor any
other classes that I would want discovered automatically.
Perhaps I have misunderstood bean discovery: I thought that the discovery
mode applied to the bean archive in question alone, not to an aggregate.
Best,
Laird
6:17 a.m.
Dne 20.3.2017 v 20:47 Laird Nelson napsal(a):
On Mon, Mar 20, 2017 at 10:56 AM John Ament
<john.ament(a)spartasystems.com <mailto:john.ament@spartasystems.com>> wrote:
For me, that still doesn't discover. The only thing I can think of
is that the JAR that includes StringSearchModelInterpolator may have
a beans.xml (does it?)
No.
I spoke with John off-list; wanted to shed more light on my setup.
I pushed a shaky incomplete version of what I'm doing
here:
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java...
The purpose of this frightening :-) extension is uninteresting for the
subject under discussion here. Briefly, it does just enough Plexus
annotation processing to be mildly dangerous and break things in cool
ways, and no more.
The test method is
here:
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/test/java...
Note in particular the main method is not in this project. It is in
this one, which is a test-scoped
dependency:
https://github.com/ljnelson/microbean-main/blob/master/src/main/java/org/...
That project's META-INF/beans.xml has bean discovery set to none
(https://github.com/ljnelson/microbean-main/blob/master/src/main/resources...),
since there are no beans in that bean archive (it houses only the main
class). John indicated that this was likely the source of the problem:
I don't think this is the problem. In Weld SE bean archive isolation is
enabled by default. Ie. for
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java...
the beans.xml is
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/reso...
"Ok, knowing that this is the setup helps out dramatically. If I had to
guess, the case of having the beans.xml from the main set to none is
what's causing this. I remember Martin mentioned some issues with SE
originally when I pushing [/sic/] that by default we should do
discovery. My guess is that Weld is seeing the beans.xml from the root
component [microbean-main] and actually falling back to the CDI 1.0
discovery behavior."
This project's META-INF/beans.xml has bean discovery of "annotated"
(https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/reso...),
though I confess that's mostly because I just wanted to use the default
behavior, not because I carefully considered whether that was something
I should use here or not. In any event, I don't anticipate there being
any classes in this project with bean-defining annotations on them, nor
any other classes that I would want discovered automatically.
Perhaps I have misunderstood bean discovery: I thought that the
discovery mode applied to the bean archive in question alone, not to an
aggregate.
What do you mean with "aggregate"? Bean discovery mode is applied to a
specific bean archive only.
Best,
Laird
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
10:51 a.m.
On Wed, Mar 22, 2017 at 4:17 AM Martin Kouba <mkouba(a)redhat.com> wrote:
> That project's META-INF/beans.xml has bean discovery set to
none
> (
https://github.com/ljnelson/microbean-main/blob/master/src/main/resources...
),
> since there are no beans in that bean archive (it houses only the main
> class). John indicated that this was likely the source of the problem:
I don't think this is the problem. In Weld SE bean archive isolation is
enabled by default. Ie. for
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java...
the beans.xml is
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/reso...
Good; that confirms what I expected.
> Perhaps I have misunderstood bean discovery: I thought that the
> discovery mode applied to the bean archive in question alone, not to an
> aggregate.
What do you mean with "aggregate"? Bean discovery mode is applied to a
specific bean archive only.
What I meant was: *if* I had misunderstood bean discovery, which I have
not, then perhaps something about that bean archive's "none" mode was
affecting other bean archives. But I did not misunderstand bean discovery,
so this is moot.
Best,
Laird
1:56 p.m.
I'm a bit confused. When you do disableDiscovery() does that leave discovery on for
other archives in the classpath?
________________________________
From: Laird Nelson <ljnelson(a)gmail.com>
Sent: Wednesday, March 22, 2017 11:51 AM
To: Martin Kouba; John Ament; cdi-dev
Subject: Re: [cdi-dev] Bean discovery question
On Wed, Mar 22, 2017 at 4:17 AM Martin Kouba
<mkouba@redhat.com<mailto:mkouba@redhat.com>> wrote:
That project's META-INF/beans.xml has bean discovery set to none
(https://github.com/ljnelson/microbean-main/blob/master/src/main/resources...),
since there are no beans in that bean archive (it houses only the main
class). John indicated that this was likely the source of the problem:
I don't think this is the problem. In Weld SE bean archive isolation is
enabled by default. Ie. for
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java...
the beans.xml is
https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/reso...
Good; that confirms what I expected.
Perhaps I have misunderstood bean discovery: I thought that the
discovery mode applied to the bean archive in question alone, not to an
aggregate.
What do you mean with "aggregate"? Bean discovery mode is applied to a
specific bean archive only.
What I meant was: if I had misunderstood bean discovery, which I have not, then perhaps
something about that bean archive's "none" mode was affecting other bean
archives. But I did not misunderstand bean discovery, so this is moot.
Best,
Laird
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
2:43 p.m.
On Wed, Mar 22, 2017 at 11:56 AM John Ament <john.ament(a)spartasystems.com>
wrote:
I'm a bit confused. When you do disableDiscovery() does that
leave
discovery on for other archives in the classpath?
(My read here (and experience) is yes: it disables the entire bean archive
discovery mechanism completely.)
Best,
Laird
3037
days inactive
3040
days old
13 comments
3 participants
participants (3)
-
John Ament -
Laird Nelson -
Martin Kouba