[weld-dev] Integrating with Weld Probe

[John D. Ament]

Hi

I was following the docs online (
https://docs.jboss.org/weld/reference/latest/en-US/html/devmode.html ) to
integrate Weld Probe into an SE application.

It looks like Probe takes care of serving static assets itself via the
filter.

Since this is an SE application, I programmatically register the
ProbeFilter (name="WeldProbeFilter",value= new String[]{"/weld-probe/*"},
uriPatterns=new String[]{"/weld-probe/*"},
dispatcherTypes=Constants.DISPATCHER_TYPES, // short cut for all
initParams=new WebInitParam[]{},
asyncSupported=true,
servletName=null,
filterClass=ProbeFilter.class)

I tried to start the application w/ -Dorg.jboss.weld.development=true and
noticed that it seemed to switch to bean-discovery-mode=all (without trim,
even though all of my JARs are with trim option).  I then tried to manually
enable the extension, but that resulted in

21:08:25.149 [main] WARN  org.jboss.weld.probe.Probe - PROBE-08:
=
 Weld Development Mode: ENABLED
 
 Disable this mode in production - it may have negative impact on
performance and/or represent a potential security risk
=
21:08:25.767 [ForkJoinPool.commonPool-worker-7] WARN
org.jboss.weld.Validator - WELD-001473: javax.enterprise.inject.spi.Bean
implementation org.apache.cxf.cdi.CdiBusBean@74cadd41 declared a normal
scope but does not implement
javax.enterprise.inject.spi.PassivationCapable. It won't be possible to
inject this bean into a bean with a passivating scope (@SessionScoped,
@ConversationScoped). This can be fixed by assigning the Bean
implementation a unique id by implementing the PassivationCapable interface.
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException:
PROBE-05: Probe is not properly initialized
at
org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:38)
at
org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:489)
at
org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:800)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:175)
at
ws.ament.hammock.bootstrap.weld3.Weld3Bootstrapper.start(Weld3Bootstrapper.java:58)
at ws.ament.hammock.Bootstrap.main(Bootstrap.java:41)
at
ws.ament.hammock.example.canonical.RestApplication.main(RestApplication.java:31)
Caused by: org.jboss.weld.exceptions.IllegalStateException: PROBE-05:
Probe is not properly initialized
at org.jboss.weld.probe.InvocationMonitor.init(InvocationMonitor.java:148)
at
org.jboss.weld.probe.InvocationMonitor.monitorCreation(InvocationMonitor.java:103)
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:498)
at
org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
at
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.invokeNext(WeldInvocationContextImpl.java:92)
at
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:124)
at
org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator$1.aroundConstruct(ConstructorInterceptionInstantiator.java:100)
at
org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallback(ConstructorInjectionPoint.java:109)
at
org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:95)
at
org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
at
org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
at
org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:62)
at
org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator.newInstance(ConstructorInterceptionInstantiator.java:66)
at
org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:186)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
at
org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
at
org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:140)
at 

Re: [weld-dev] Flat Deployment mode & beans.xml

[John D. Ament]

Yes, that test is basically why I'm asking the question.  Also, if I am
using implicit bean archives (per the CDI spec, the system flag) and have
flat deploymnet mode in Weld, what bean discovery should I be seeing?  The
result of the merged beans.xml?

John

On Mon, Jan 15, 2018 at 2:16 AM Matej Novotny <manov...@redhat.com> wrote:

> Actually, now that I think of it I was wrong.
> You may have a set of JARs in your deployment and you don't want to pick
> up beans from all JARs (it might even lead to ambiguous dep for example).
> Therefore, beans.xml, even empty one, would be required to mark an archive
> which is to be considered a bean archive.
>
> I also found this test which can be easily fiddled with to verify what I
> said above -
> https://github.com/weld/core/blob/master/environments/se/tests/src/test/java/org/jboss/weld/environment/se/test/discovery/isolation/IsolationDisabledTest.java
> E.g. if you change `bda1` to be a JavaArchive (no beans.xml added), it
> will fail with unsatisfied dep.
>
> Matej
>
> - Original Message -
> > From: "Matej Novotny" <manov...@redhat.com>
> > To: "John D. Ament" <john.d.am...@gmail.com>
> > Cc: "Weld" <weld-dev@lists.jboss.org>
> > Sent: Monday, January 15, 2018 8:04:15 AM
> > Subject: Re: [weld-dev] Flat Deployment mode & beans.xml
> >
> > Hi John,
> >
> > what you say makes sense, there shouldn't be need for multiple beans.xml.
> > Does it give you any errors?
> >
> > Matej
> >
> > - Original Message -
> > > From: "John D. Ament" <john.d.am...@gmail.com>
> > > To: "Weld" <weld-dev@lists.jboss.org>
> > > Sent: Saturday, January 13, 2018 4:17:35 PM
> > > Subject: [weld-dev] Flat Deployment mode & beans.xml
> > >
> > > Hi,
> > >
> > > If I'm using Weld SE in a flat deployment mode, is a beans.xml required
> > > still
> > > in all JARs? I would assume that with the beans.xml's being merged,
> any JAR
> > > that didn't have a beans.xml would inherit the "merged" one.
> > >
> > > John
> > >
> > > ___
> > > weld-dev mailing list
> > > weld-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/weld-dev
> > ___
> > weld-dev mailing list
> > weld-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] CDI JavaSE tck

[John D. Ament]

On Mon, Oct 16, 2017 at 2:07 PM Martin Kouba  wrote:

> Hi Emily,
>
> tests from TestGroups.SE should NOT be run in a Java EE environment.
> Note that CDI Bootstrap API should not even work in a Java EE container
> (SeContainerInitializer.newInstance() should throw IllegalStateException).
>

Isn't there a TCK test for that?


>
> Martin
>
> Dne 16.10.2017 v 14:33 Emily Jiang napsal(a):
> > Hi Matej/Martin,
> >
> > I am looking at the CDI 2.0 tck on JavaSE. I saw they are under the
> > groups of "SE". Should the tcks be exercised by JavaEE runtime, e.g.
> > wildfly, glassfish, Liberty etc? Which profile did you package the
> > JavaSE tck?
> >
> >
> > Many thanks,
> > Emily
> > ===
> > Emily Jiang
> > WebSphere Application Server, CDI & MicroProfile Development Lead
> >
> > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> > Phone:  +44 (0)1962 816278 <+44%201962%20816278>  Internal: 246278
> >
> > Email: emiji...@uk.ibm.com
> > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> > ___
> > weld-dev mailing list
> > weld-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Do Custom implementations of Bean need to provide injection points?

[John D. Ament]

Martin,

Knowing that I don't have any reference to an injection point, what would
you recommend I pass in as a dummy injection point?

John

On Fri, Aug 4, 2017 at 8:07 AM Martin Kouba <mko...@redhat.com> wrote:

> Hm, I think BeanManager.getReference() should not be used here, see also
> 6.5.3. Contextual reference for a bean [1]:
>
> "The container must ensure that every injection point of type
> InjectionPoint and qualifier @Default of any dependent object
> instantiated during this process receives a null value if it is not
> being injected into any injection point."
>
> However, in Weld you could use
> BeanManager.getInjectableReference(InjectionPoint, CreationalContext)
> and provide some dummy IP. See for example
>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/custom/BarBean.java#L50
> .
>
> FYI there is a TCK test that verifies the InjectionPoint is null if
> using getReference() outside custom bean's create:
>
> org.jboss.cdi.tck.tests.lookup.injectionpoint.InjectionPointTest#testNullInjectionPointInjectedIntoNonInjectedObject()
>
> Martin
>
> [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#contextual_reference
>
> Dne 4.8.2017 v 13:05 Martin Kouba napsal(a):
> > Hi John,
> >
> > Bean.getInjectionPoints() is only used during validation - returned
> > injection points are validated at initialization time, so for a custom
> > bean it makes sense to return an empty set as there are no real
> > injection points.
> >
> > WRT lookup - what exactly do you try to accomplish? Do you try to obtain
> > InjectionPoint metadata from inside a custom dependent bean's create()
> > method? This should be possible although not clearly specified. I think
> > we have a test with BeanManager.getInjectableReference(InjectionPoint,
> > CreationalContext) but I will need to double check.
> >
> > I will also look at the geronimo-config repo.
> >
> > Martin
> >
> > Dne 4.8.2017 v 11:42 John D. Ament napsal(a):
> >> Hi
> >>
> >> As the subject says.  I have a library that registers a custom
> >> implementation of Bean, which has a method
> >>
> >>  @Override
> >>  public Set getInjectionPoints() {
> >>  return Collections.emptySet();
> >>  }
> >>
> >> When testing this on Weld3, I have code that looks up the injection
> >> point, to find the annotations present.  However, the following
> >> injection point lookup fails:
> >>
> >>  private static InjectionPoint findInjectionPoint(final
> >> BeanManager bm, final CreationalContext ctx) {
> >>  return InjectionPoint.class.cast(
> >> bm.getReference(bm.resolve(bm.getBeans(InjectionPoint.class)),
> >> InjectionPoint.class, ctx));
> >>  }
> >>
> >> so based on a CreationalContext I'm looking for InjectionPoint.  Maybe
> >> there's a different way that this is supposed to work?  If you're
> >> interested in giving it a shot, take a look at
> >> https://github.com/apache/geronimo-config and run the Weld3 profile to
> >> replicate the issue.
> >>
> >> John
> >>
> >>
> >> ___
> >> weld-dev mailing list
> >> weld-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>
> >
>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Do Custom implementations of Bean need to provide injection points?

[John D. Ament]

Hi

As the subject says.  I have a library that registers a custom
implementation of Bean, which has a method

@Override
public Set getInjectionPoints() {
return Collections.emptySet();
}

When testing this on Weld3, I have code that looks up the injection point,
to find the annotations present.  However, the following injection point
lookup fails:

private static InjectionPoint findInjectionPoint(final BeanManager bm,
final CreationalContext ctx) {
return InjectionPoint.class.cast(

bm.getReference(bm.resolve(bm.getBeans(InjectionPoint.class)),
InjectionPoint.class, ctx));
}

so based on a CreationalContext I'm looking for InjectionPoint.  Maybe
there's a different way that this is supposed to work?  If you're
interested in giving it a shot, take a look at
https://github.com/apache/geronimo-config and run the Weld3 profile to
replicate the issue.

John
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0 Beta 1 & Arquillian Embedded Container

[John D. Ament]

Hi,

It seems that Arquillian Embedded Container Weld (2.0 Beta3) is not
compatible with Weld 3 Beta 1.  Is this a known issue, or do we need to
bump to Weld container 3.0.x to add CDI 2.0 support?

java.lang.NoClassDefFoundError: org/jboss/weld/literal/InitializedLiteral
at
org.jboss.arquillian.container.weld.embedded.mock.TestContainer.startContainer(TestContainer.java:244)
at
org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:115)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


John
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Does WELD-2260 Need to be fixed for StartMain?

[John D. Ament]

Hi,

So I ran into an issue after manually patching to work around WELD-2260.
It didn't work for use cases where StartMain is used to boostrap Weld.  I'm
just not sure if its actually needed.  E.g. the fixes for WELD-2260 may be
good enough that this isn't an issue.

https://github.com/weld/core/pull/1535

Let me know what you think.

John
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld & Groovy

[John D. Ament]

Hi

So based on the last issue I saw, I just want to run this by you guys.

I'm starting to run tests with Weld 3.  I saw the following, which made me
think of the groovy issue

Caused by: java.lang.AbstractMethodError:
org.apache.cxf.Bus$1366014918$Proxy$_$$_WeldClientProxy.getProperty(Ljava/lang/String;)Ljava/lang/Object;
at org.apache.cxf.common.util.ClassHelper.getRealClass(ClassHelper.java:81)


I just want to confirm that this is fixed on master, and its just because
Weld is a little out of date.

-Dweld.version=3.0.0.Alpha17 -Dcdi-api.version=2.0-EDR2

John
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] How to avoid this warning message?

[John D. Ament]

Yep, it was the inheritance.  Any idea why though?

https://git1-us-west.apache.org/repos/asf?p=deltaspike.git;a=blobdiff;f=deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/AbstractEntityRepository.java;h=529c474d8a84837ccfb2fb6693ec651f65ff8b3e;hp=933c136abf58efde4bba7dc5cf8944d711d92d40;hb=bb9abfcc;hpb=6d4fbd8e6a50555ed70c06b4a10669e7e6f403d1

John

On Sun, Aug 14, 2016 at 7:03 PM John D. Ament <john.d.am...@gmail.com>
wrote:

>
> https://lists.apache.org/thread.html/8edcc676c2dbede50f7e75cc56c4d78d260357df527347a1ff155402@%3Cusers.deltaspike.apache.org%3E
>  for
> some reference
>
> Somewhere between 1.6 and 1.7 this started popping up on DS.  Even though
> these methods are defined in the class hierarchy, they are transitively
> inherited.  Is DS not picking them up because AbstractEntityRepository
> doesn't directly implement the other interfaces?
>
> John
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] How to avoid this warning message?

[John D. Ament]

https://lists.apache.org/thread.html/8edcc676c2dbede50f7e75cc56c4d78d260357df527347a1ff155402@%3Cusers.deltaspike.apache.org%3E
for
some reference

Somewhere between 1.6 and 1.7 this started popping up on DS.  Even though
these methods are defined in the class hierarchy, they are transitively
inherited.  Is DS not picking them up because AbstractEntityRepository
doesn't directly implement the other interfaces?

John
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev