Getting injection point from Bean#create
by arjan tijms
Hi,
In a producer method it's trivial to get access to an InjectionPoint
instance representing the point where the value produced by the
producer will be injected.
When registering a Bean manually from an extension using
AfterBeanDiscovery#addBean, this is not immediately obvious.
After some fumbling with the CDI APIs I came up with the following
code that seems to work on both Weld and OWB (didn't test CanDI yet).
It uses a small "dummy" class, which is used to grab an InjectionPoint off:
In a Bean:
public Object create(CreationalContext<Object> creationalContext) {
InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
creationalContext
);
With InjectionPointGenerator being the following class:
public class InjectionPointGenerator {
@Inject
private InjectionPoint injectionPoint;
}
And resolve being the following method:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
As mentioned, while this seems to work, I wonder if it's the best approach.
Kind regards,
Arjan
8 years, 10 months
Deploy failing due to WELD-000071: Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider must be @Dependent
by Dev
It seems it is failing as i am using an external jar file in which
javax.Inject is used.
When my war is deployed with this jar file it fails.
I tried to exclude the packages in jar file by declaring them in
WEB-INF/beans.xml i.e.
<?xml version="1.0" encoding="UTF-8"?>
<beans bean-discovery-mode="all" version="1.1"
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_1_1.xsd">
<scan>
<exclude name="com.xyz.*"/>
<exclude name="com.shipment.**"/>
</scan>
</beans>
CDI version is 1.2
Server is WILDFLY 8.2.0
Error that i am getting :
###############
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071:
Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider
must be @Dependent
at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:198)
at
org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
at
org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_25]
... 3 more
23:23:19,370 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address:
([("deployment" => "CaseManagementSystem.war")]) - failure description:
{"JBAS014671: Failed services" =>
{"jboss.deployment.unit.\"CaseManagementSystem.war\".WeldStartService" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"CaseManagementSystem.war\".WeldStartService: Failed
to start service
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071:
Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider
must be @Dependent"}}
23:23:19,437 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31)
JBAS018559: Deployed "CaseManagementSystem.war" (runtime-name :
"CaseManagementSystem.war")
23:23:19,466 INFO [org.jboss.as.controller] (Controller Boot Thread)
JBAS014774: Service status report
JBAS014777: Services which failed to start: service
jboss.deployment.unit."CaseManagementSystem.war".WeldStartService:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."CaseManagementSystem.war".WeldStartService: Failed to
start service
23:23:19,822 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service
thread 1-3) JBAS010418: Stopped Driver service with driver-name =
CaseManagementSystem.war_com.mysql.jdbc.Driver_5_1
23:23:19,832 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 6)
JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service
'CaseManagementSystem.war#hsn18cms'
23:23:19,842 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 17)
JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service
'CaseManagementSystem.war#hsn18cmsaspect'
23:23:19,842 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service
thread 1-4) JBAS010418: Stopped Driver service with driver-name =
CaseManagementSystem.war_org.h2.Driver_1_4
23:23:19,852 INFO [org.jboss.weld.deployer] (MSC service thread 1-7)
JBAS016009: Stopping weld service for deployment CaseManagementSystem.war
23:23:19,972 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 17)
JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service
'CaseManagementSystem.war#hsn18cmsaspect'
23:23:19,972 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 6)
JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service
'CaseManagementSystem.war#hsn18cms'
23:23:21,872 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8)
JBAS015877: Stopped deployment CaseManagementSystem.war (runtime-name:
CaseManagementSystem.war) in 2076ms
23:23:21,872 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http
management interface listening on http://127.0.0.1:9990/management
23:23:21,872 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin
console listening on http://127.0.0.1:9990
23:23:21,872 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874:
WildFly 8.2.0.Final "Tweek" started in 134751ms - Started 241 of 290
services (95 services are lazy, passive or on-demand)
23:23:22,152 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2)
JBAS018558: Undeployed "CaseManagementSystem.war" (runtime-name:
"CaseManagementSystem.war")
23:23:22,162 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2)
JBAS014774: Service status report
######################
Kindly help and let me know how i can exclude the jar files in CDI.
Thanks,
Dev
--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Deploy-failing-...
Sent from the CDI Development mailing list mailing list archive at Nabble.com.
9 years, 6 months
Fwd: bean archives
by Emily Jiang
I agree with Mark. I am confused about section 5 and section 12. Weld-2
leaves the work of specifying the bean archive to the integrator. I am
wondering how the new version of app server using Weld-2 can pass the CDI
1.1/1.2 CTS at all if the integrator creates its bean archives based on
section 12.
I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?), is based
on section 5. Can someone confirm? The spec needs to be updated to remove
the conflict between section 5 and section 12.
---------- Forwarded message ----------
From: Emily Jiang <emijiang6(a)googlemail.com>
Date: Sat, May 2, 2015 at 10:21 PM
Subject: Re: [cdi-dev] bean archives
To: Mark Struberg <struberg(a)yahoo.de>
I agree with Mark. I am confused about section 5 and section 12. Weld-2
leaves the work of specifying the bean archive to the integrator. I am
wondering how the new version of app server using Weld-2 can pass the CDI
1.1/1.2 CTS at all if the integrator creates its bean archives based on
section 12.
I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?), is based
on section 5. Can someone confirm? The spec needs to be updated to remove
the conflict between section 5 and section 12.
On Sat, May 2, 2015 at 3:47 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
> Actually the rules are still not clear. Section 5 and 12 contradict each
> other. The EE6 RI, JBossAS6 and TomEE and WAS did behave like in section 5
> (1 BDA per ee-module) whereas Weld-2 behaves like in section 12.
>
> LieGrue,
> strub
>
>
>
> On Saturday, 2 May 2015, 10:13, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
>
>
> Hi Emily,
>
> The rules) apply to each jar (archive). There is no merging, thus an app
> can contain three types of archives :
> Non bean archives,
> Implicit bean archives,
> Explicit bean archives.
>
> Antoine Sabot-Durand
>
>
> Le 1 mai 2015 à 23:03, Emily Jiang <emijiang6(a)googlemail.com> a écrit :
>
>
> I have a question on bean archives.
>
> For the jars under web-inf\lib, are they individual bean archives or they
> should be merged with web-inf\classes files and use the beans.xml under
> web-inf\ to form one bean archive?
>
>
> If they are merged together to form one bean archive, what will happen if
> they have their own beans.xml under Meta-inf dir?
>
> Below is the what spec says, but it does not mention the jar under
> web-inf\lib. The spec should make this situation clear.
>
> In the CDI1.2 spec:
> When determining which archives are bean archives, the container must
> consider:
> • Library jars, EJB jars or application client jars
> • The WEB-INF/classes directory of a war
> • Directories in the JVM classpath
> The container is not required to support application client jar bean
> archives.
> A Java EE container is required by the Java EE specification to support
> Java EE modules. Other
> containers may or may not provide support for war, EJB jar or rar bean
> archives.
> The beans.xml file must be named:
> • META-INF/beans.xml , or,
> • in a war, WEB-INF/beans.xml or WEB-INF/classes/META-INF/beans.xml.
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang(a)apache.org
>
> _______________________________________________
> 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.
>
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
[JBoss JIRA] (CDI-532) Support multiple container in Java SE
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-532:
----------------------------------------
Summary: Support multiple container in Java SE
Key: CDI-532
URL: https://issues.jboss.org/browse/CDI-532
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Java SE Integration
Affects Versions: 1.2.Final
Reporter: Antoine Sabot-Durand
We should propose a solution to support multiple container in Java SE.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Antoine Sabot-Durand updated CDI-4:
-----------------------------------
Fix Version/s: 2.0-EDR1
(was: 2.0 (discussion))
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR1
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (CDI-521) Create a Prioritized Interface for SPI element that have a priority
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-521?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-521:
-------------------------------------
Fix Version/s: 2.0-EDR1
(was: 2.0 (discussion))
> Create a Prioritized Interface for SPI element that have a priority
> --------------------------------------------------------------------
>
> Key: CDI-521
> URL: https://issues.jboss.org/browse/CDI-521
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0-EDR1
>
>
> With the addition of ordering in Observer (CDI-4), we have a collection of element in SPI that could benefit having a {{getPriority()}} method:
> * {{ObserverMethod}}
> * {{Bean}} to be able to read alternative priority and give priority for {{Decorator}} and {{Interceptor}}
> Any other place?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
CDI-26 feedback
by Jozef Hartinger
Hi all,
I'd like to raise several concerns with the CDI-26 resolution that I
either forgot to raise before or were lost in the process.
1) Bean discovery in SE
I was under the impression that the task to define bean discovery for SE
was postponed post EDR1 yet the PR for CDI-26 that has been merged
defines bean discovery in SE explicitly
https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67...
I am concerned about the way it is defined currently as it requires that
the CDI implementation eagerly loads/scans each and every class found on
the classpath during initialization. Due to performance implications of
this I am convinced that this is not the desired behavior. It may be
useful to support this for some use-cases with e.g. a special container
mode but I doubt this should be the default behavior for CDI in SE.
Let's not forget to fix this.
2) CDIProvider.isInitialized()
First of all, good job on removing the constraints, preventing multiple
parallel container support, from the API. One missing piece seems to be
CDIProvider.isInitialized(). The JavaDoc says: " Determines whether or
not this CDIProvider has been initialized or not"
My understanding is that it is supposed to indicate whether a CDI object
is in initialized state yet or whether it has been shut down. If my
understanding is correct then this method should probably be moved to
the CDI class instead. Due to the possible 1-to-n mapping between CDI
and CDIProvider it's not correct to have this method on CDIProvider
Jozef
9 years, 7 months
Stopping priority event handling?
by Michael Remijan
If this question has already been discussed, I apologize. I want to know if there was any talk about stopping event processing for @Priority events? The use case I'm thinking of is 1st verifying user data then 2nd performing whatever action the user wanted. I thought the UI layer (desktop application) can published an event where observers use the @Priority annotation so you get the correct ordering of verification then performing the user's action. If verification fails, event process should stop. Is there a way to do this or has something like this been discussed?
9 years, 7 months
