[jira] [Resolved] (MEECROWAVE-65) log isn't visible during shutdown

2017-09-11 Thread Mark Struberg (JIRA)
[ https://issues.apache.org/jira/browse/MEECROWAVE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MEECROWAVE-65. - Resolution: Fixed > log isn't visible during shutdown >

[jira] [Created] (MEECROWAVE-65) log isn't visible during shutdown

2017-09-11 Thread Mark Struberg (JIRA)
Mark Struberg created MEECROWAVE-65: --- Summary: log isn't visible during shutdown Key: MEECROWAVE-65 URL: https://issues.apache.org/jira/browse/MEECROWAVE-65 Project: Meecrowave Issue Type:

[jira] [Resolved] (MEECROWAVE-64) OWBTomcatWebScannerService blows up with a NPE if used in Unit Tests

2017-09-11 Thread Mark Struberg (JIRA)
[ https://issues.apache.org/jira/browse/MEECROWAVE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MEECROWAVE-64. - Resolution: Fixed > OWBTomcatWebScannerService blows up with a NPE if used in Unit

[jira] [Created] (MEECROWAVE-64) OWBTomcatWebScannerService blows up with a NPE if used in Unit Tests

2017-09-11 Thread Mark Struberg (JIRA)
Mark Struberg created MEECROWAVE-64: --- Summary: OWBTomcatWebScannerService blows up with a NPE if used in Unit Tests Key: MEECROWAVE-64 URL: https://issues.apache.org/jira/browse/MEECROWAVE-64

Re: [Meecrowave] next cxf

2017-09-11 Thread Mark Struberg
I gonna try it out, but yes, 3.2 is the way to go I'd say! LieGrue, strub > Am 11.09.2017 um 16:15 schrieb Romain Manni-Bucau : > > Hey guys > > We now can upgrade to 3.1.13 or 3.2. What our feeling here? > > Tempted to say 3.2 but do i miss sthg? .

[Meecrowave] next cxf

2017-09-11 Thread Romain Manni-Bucau
Hey guys We now can upgrade to 3.1.13 or 3.2. What our feeling here? Tempted to say 3.2 but do i miss sthg?

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread Mark Struberg
Well, the IP resolving is always done against getTypes(). But I think this is uninamously understood the same in all impls, isn't? The only discussion I remembered was around the getTypes() vs getBeanClass() for proxing. Thus my answers. Again: test would be cool, then we could help much

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread John D. Ament
Good catch. We need a getInjectionPoint().getType() check on https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injectionpoint/dynamic/DynamicInjectionPointTest.java#L99 On Mon, Sep 11, 2017 at 3:23 AM Romain Manni-Bucau

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread John D. Ament
So remember. The question here is about injection point, not the bean type. Some of the problems described are deployment problems. E.g. you try to inject using a type that's forbidden because of @Typed, then that should result in UnsatisfiedDependencies, at deployment time. On Mon, Sep 11,

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread John D. Ament
On Mon, Sep 11, 2017 at 3:05 AM Mark Struberg wrote: > Hmm, if you have a class > > public class Bla { > private @Inject Instance myInstance; > } > > then I'd asssume that the InjectionPoint.getType for myInstance would be > Instance and not Foo alone. > > Agreed,

AW: Odd behavior in InjectionPointProducer

2017-09-11 Thread Arne Limburg
Yes, that's interesting, you could get a proxy that directly extends Object. So you could invoke no method on that bean (except toString(), equals(...), hashCode(), ...) Does not seem to be usefull at all Von: Mark Struberg

AW: Odd behavior in InjectionPointProducer

2017-09-11 Thread Arne Limburg
Quick look into the spec http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#name_resolution @Named @Typed() seems to be valid and the bean should be found by EL. Von: Romain Manni-Bucau Gesendet: Montag, 11. September 2017 09:31:38 An:

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread Romain Manni-Bucau
Not sure it is 100% related but looks like a bean without types so not even sure @Named should be "matchable" since you dont match types at all (we often used @Typed = @Vetoed in CDI 1.0) Romain Manni-Bucau @rmannibucau | Blog

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread Mark Struberg
Btw, what I've seen quite a few times is the following: @Named @Typed() public class MyBla extends SomeComplicatedThing implements AFewInterfaces { ... } Means the @Typed got purely used to not have it picked up by type but only via EL. And in that case the proxy in Weld is most likely not

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread Romain Manni-Bucau
Surely the one to test: https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injectionpoint/dynamic/DynamicInjectionPointTest.java Romain Manni-Bucau @rmannibucau | Blog | Old

AW: Odd behavior in InjectionPointProducer

2017-09-11 Thread Arne Limburg
I'm with Mark here, InjectionPoint#getType() should return a ParameterizedType Instance So in the code below we simply should return parameterizedType I think. Would that pass the TCK? If yes, we definitely should file a TCK issue, there seems to be a test missing. Cheers, Arne

Re: Odd behavior in InjectionPointProducer

2017-09-11 Thread Mark Struberg
Hmm, if you have a class public class Bla { private @Inject Instance myInstance; } then I'd asssume that the InjectionPoint.getType for myInstance would be Instance and not Foo alone. > The problem is that Bean.getBeanClass() can never be null, by definition, > but also should not be used