June 2015 - cdi-dev - Jboss List Archives

by Mark Struberg

Hi folks! CDI-1.1 and CDI-1.2 support has been added to OpenWebBeans for quite some time. But still it doesn’t show up on http://www.cdi-spec.org/download/ Could you please add http://openwebbeans.apache.org/download.html to the roaster? txs and LieGrue, strub

8 years, 10 months

2
1
0 / 0

Last line before EDR review of PR 250

by Antoine Sabot-Durand

Hi all, Last week and this week-end I rework on CDI-499 and PR 250. https://github.com/cdi-spec/cdi/pull/250 <https://github.com/cdi-spec/cdi/pull/250> Correct /addition are: - reverted fireAsync signature to add the type of the event in it - fireAsync triggers observers and async observers - @ObservesAsync doesn’t support transnational phase - Security context is propagated for async observer. Transaction context is not and CDI context are not except for application context which is shared. - Mention that container doesn’t guarantee thread safeties for payload in async observer - Exception in async observer must be caught by the container and added as suppressed exception (thanks José for this solution) : http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSupp... <http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSupp...> Please try to give me your feedback ASAP as I’d like to release EDR in the coming days. Remember, feature in EDR cane changed or removed during or after review, so if a point should launch a discussion we could bring change later. IF you din a big flaw in my proposal thanks to raise hand and try to propose a solution. Antoine

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-501: ------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: José Paumard > Fix For: 2.0-EDR1 > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

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.

8 years, 10 months

2
1
0 / 0

Cancelled: CDI weekly meeting

by Antoine Sabot-Durand

8 years, 10 months

1
0
0 / 0

Cancelled: CDI weekly meeting

by Antoine Sabot-Durand

8 years, 10 months

1
0
0 / 0

Face to Face meeting in Paris, please choose your date

by Antoine Sabot-Durand

Hi all, After discussion with Red Hat team. We chose Paris for the CDI Face to Face meeting. It was the second choice in our place survey, but this choice suits more our budget allow Red Hat to have a budget for EG members meal. This meeting will last 2 days (friday-saturday) in September or early October To choose the dat, I updated the Doodle here : http://doodle.com/ecvpshxceup8b278 <http://doodle.com/ecvpshxceup8b278> My modifications reset your former participation to this Doodle (if you did one) so people that already entered choices will have to it again (sorry). I’m so happly to meet you there! Antoine

8 years, 10 months

1
0
0 / 0

Face to Face meeting in Paris, please choose your date

by Antoine Sabot-Durand

Hi all, After discussion with Red Hat team. We chose Paris for the CDI Face to Face meeting. It was the second choice in our place survey, but this choice suits more our budget allow Red Hat to have a budget for EG members meal. This meeting will last 2 days (friday-saturday) in September or early October To choose the dat, I updated the Doodle here : http://doodle.com/ecvpshxceup8b278 <http://doodle.com/ecvpshxceup8b278> My modifications reset your former participation to this Doodle (if you did one) so people that already entered choices will have to it again (sorry). Hope to see you there, Antoine

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-535) cdi instance injection ordering

by Ochieng Marembo (JIRA)

Ochieng Marembo created CDI-535: ----------------------------------- Summary: cdi instance injection ordering Key: CDI-535 URL: https://issues.jboss.org/browse/CDI-535 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0 (discussion) Reporter: Ochieng Marembo Priority: Optional We should allow ordering of bean instance injection using the ```Instance<MyBeanInterface>``` when an instance injection is used. h3. Use case: Developer always define a kind of chain of processor beans, which may need to run in specific order. h3. Current scenario: Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: #1 {code} private Iterable<MyBeanInterface> myBeans; @Inject void injectBeans(@Any Instance<MyBeanInterface> myBeans) { //the create order does some kind of ordering on the beans. this.myBeans = createOrder(myBeans); } {code} #2 This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. {code} @Any @Inject private Instance<MyBeanInterface> myBeans; public void doSomething() { Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier)); } {code} h3. Our Proposal We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance<MyBeanInterface>{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} {code} public interface MyBeanInterface {} @MyQualifier @Priority(0) public class MyFirstBean implements MyBeanInterface{ } @MyQualifier @Priority(2) public class MySecondBean implements MyBeanInterface{ } @ApplicationScoped public class MyBeanProcessor { //We expect that this injected instances shall be in order based on the @Priority annotation @Any @Inject private Instance<MyBeanInterface> myBeans; } {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

Tomorrow's meeting agenda

by Antoine Sabot-Durand

Hi all, In tomorrow’s meeting I’d like to close EDR1 to release it ASAP. Main content I target to release is : - API split - Java SE bootstrap - Event ordering - Asynchronous events We’ll deal this content (I’m actually working to integrate the 3 last in the first). I’ll have question to validate with you like : - ApplicationContext in Java SE - Signature of fireAsync - Choice of separating Async event from sync event If you have other points please send me them to have a complete list by tomorrow meeting. And please remember that the target of an Early Draft is not to release a final part of the spec, it is to propose feature to have feedback. Features in the EDR may be removed or radically changed from the final spec. Even during the EDR review content may change as specified in the JCP : https://jcp.org/en/procedures/jcp2#3 <https://jcp.org/en/procedures/jcp2#3> Thanks for your input. Antoine

8 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2015