What is the best way to pass cofiguration to CDI bean using Weld?
by Alex Sviridov
Hi all
Could anyone suggest solution for the following situation.
Lets suppose we have:
public interface SomeManager{}
@ApplicationScoped
public class SomeManagerImpl implements SomeManager{}
@ApplicationScoped
public class Application {} //application entry point
In Application I need to pass configuration to SomeManagerImpl, but I don't want to
add setConfiguration method to SomeManager interface. What is the best way
to do it in Weld? Maybe I use some CDI mechanisms, or add extra classes. Please, help.
Best regards, Alex Sviridov
6 years, 7 months
Integrating with Weld Probe
by 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-000008:
=====================================
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-000005: 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-000005:
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 org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
at
org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
Even though based on the docs that should be all that's needed. Is there
something else required to get Probe running in SE?
6 years, 8 months
https://issues.jboss.org/browse/WELD-1130
by Emily Jiang
This issue https://issues.jboss.org/browse/WELD-1130 has been around for a
while. Can some investigation be done? We are happy to assist with testing
a patch if needed.
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 Internal: 246278
Email: emijiang(a)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
6 years, 8 months
WIP fix for https://issues.jboss.org/browse/WELD-1130
by Benjamin Confino
Hello everyone
I have a work in progress fix for WELD-1130 which can be seen here:
https://github.com/benjamin-confino/core/commit/35d055cd9a841cfbdf2bcb2aa...
I have tested a prototype of this fix on Liberty and wanted to solicit
feedback from the community. In particular I would like advice on how to
write a test for this, I tried modifying a test inside NaiveClusterTest to
update a bean twice but it seems that the explicit session replication
bypasses WELD-1130.
Currently this test only handles the SessionScoped side of WELD-1130, but
I have no objection to expanding it to cover both parts if people agree
with this design and it can be extended to conversation scopes.
(suggestions for what to call the combined property would also be
appreciated)
Regards
Benjamin
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
6 years, 8 months
Potential bug with Typed not affecting if a ProducerMethod is proxiable.
by Benjamin Confino
Hello
I can see something that might be a bug in weld. I attempted to work
around https://issues.jboss.org/projects/WELD/issues/WELD-2466 by using
the@Typed annotation on a Producer Method to exclude the unproxiable Types
and thus avoid getting caught by the failing isBeanProxiable check.
However the annotation did not affect whether or not the ProducerMethod is
proxiable. This might be a second bug.
I have uploaded a recreate application which I have verified against
Wildfly 11.0.0 here: https://github.com/benjamin-confino/TypedProducerBug
To recreate you can download the pre-compiled binary from github, deploy
it to a version of Wildfly without the fix for WELD-2466, and visit the
url http://localhost:8080/WeldRecreateProducesExtendedAbstract/inheritance
this will trigger a call to getInjectableReference() which will fail
because the ProducerMethod for recreate.BeanProducer.produceBean() is not
proxiable.
If you debug into constructor for ProducerMethod at line 76 you will see
that the proxiable flag is set using method.getTypeClosures() ; which
returns all the associated types, rather than just those specified with
the Typed() paramater.
Is this the correct behaviour? Should a ProducerMethod be unproxiable even
with Typed limiting the bean types to proxiable types?
Regards
Benjamin
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
6 years, 8 months
Class#getGenericInterfaces() on a CDI proxy
by Marko Bekhta
Hi all!
While working on an issue [1] in Hibernate Validator, We've stumbled on,
what
seems to be, a bug in Weld. We have a generic interface:
@ValidateOnExecution(type = { ExecutableType.NON_GETTER_METHODS,
ExecutableType.GETTER_METHODS })
public interface Repeater<T> {
String repeat(@NotNull String in);
@NotNull
T reverse(T in);
@NotNull
String getHelloWorld();
}
and then it's impl:
@ValidateOnExecution
public class DefaultRepeater implements Repeater<String> {
@Override
public String repeat(String in) {
return in;
}
@Override
public String reverse(String in) {
return null;
}
@Override
public String getHelloWorld() {
return null;
}
}
In the internals of HV we need to make a call to
`Class#getGenericInterfaces()`.
In case of calling it on `DefaultRepeater` class we will get something
similar
to:
result = {Type[1]@4948}
0 = {ParameterizedTypeImpl@4863} "org.hibernate.validator.test.
cdi.internal.methodvalidation.Repeater<java.lang.String>"
But in case when validation run in CDI context we receive a proxy instead
(something like org.hibernate.validator.test.cdi.internal.methodvalidation.
DefaultRepeater$Proxy$_$$_WeldSubclass).
And if we call `Class#getGenericInterfaces()` on such proxy we'd get next
results:
result = {Class[6]@4880}
0 = {Class@3049} "interface org.hibernate.validator.test.
cdi.internal.methodvalidation.Repeater"
1 = {Class@327} "interface java.io.Serializable"
2 = {Class@4636} "interface org.jboss.weld.proxy.WeldConstruct"
3 = {Class@4638} "interface org.jboss.weld.interceptor.util.proxy.
TargetInstanceProxy"
4 = {Class@4637} "interface org.jboss.weld.interceptor.
proxy.LifecycleMixin"
5 = {Class@4639} "interface org.jboss.weld.bean.proxy.ProxyObject"
The only line of interest here is 0. As you can see it gives a raw,
non-generic
type, while `ParameterizedType` was expected (Repeater<java.lang.String>).
Is that expected/intended behavior of `Class#getGenericInterfaces()`
(returning raw types) for CDI proxies?
Have a nice day,
Marko
[1] https://github.com/hibernate/hibernate-validator/pull/931#
issuecomment-372619324
6 years, 8 months
How to inject in servlet CDI beans from war/lib?
by Alex Sviridov
Hi all.
Could anyone help me with the following problem. I have a war that contains one servlet.
In WEB-INF of the war I have beans.xml. Besides, inside this war, in lib folder I have
a jar archive. Jar archive has beans.xml in META-INF.
I use GlassFish 5 that uses Weld. When I want to inject in servlet CDI bean from jar,
container doesn't inject anything - field is null, and no errors I get. However, when
I inject in servlet EJB bean everything works fine.
How to fix it?
--
Best regards, Alex Sviridov
6 years, 8 months
