[JBoss JIRA] (JBEE-133) Expression Language 3.0 (JSR-341) APIs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on JBEE-133:
----------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1207583|https://bugzilla.redhat.com/show_bug.cgi?id=1207583] from NEW to MODIFIED
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
> Key: JBEE-133
> URL: https://issues.jboss.org/browse/JBEE-133
> Project: JBoss JavaEE Spec APIs
> Issue Type: Sub-task
> Components: jboss-javaee-specs
> Reporter: Shelly McGowan
> Assignee: Remy Maucherat
> Fix For: JavaEE 7 Spec APIs 1.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
- 1
- 0
[JBoss JIRA] (WFLY-4419) Dependency on a deployed CDI module - beans are not injected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4419?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4419.
----------------------------------
Fix Version/s: 9.0.0.Beta2
Resolution: Done
I tested against 9.0.0.Beta2, so it sounds like this has already been fixed.
> Dependency on a deployed CDI module - beans are not injected
> ------------------------------------------------------------
>
> Key: WFLY-4419
> URL: https://issues.jboss.org/browse/WFLY-4419
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Dirk Buchhorn
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta2
>
>
> I want to deploy two modules to wildfly 8.2.0 The module-a contains beans (and later CDI producer and other stuff) and module-b use this beans. Beans from module-a should be injected with CDI in module-b (There is a beans.xml in both modules.). All works fine if the module-a is direct referenced as dependency like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" meta-inf="import" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
>
> But the dependency to module-a should be without to know the deployed version, so I tried to set a module alias and (or) to re-export module-a under a different name like this.
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <module-alias name="deployment.module-a-alias" />
> </deployment>
> </jboss-deployment-structure>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <module name="deployment.module-a">
> <module-alias name="deployment.module-a-alias" />
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" export="true" meta-inf="export" />
> </dependencies>
> </module>
> </jboss-deployment-structure>
>
> But either the module alias or a re-export under a new module name worked. The reported exception is always:
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type XYZ with qualifiers @Default
>
> The module alias fit my requirements and I guess is should work with CDI but it dosn't.
> Two questions:
> - Why CDI don't work with module alias and module re-export?
> - How to deal with dependencies and module versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
- 1
- 0
[JBoss JIRA] (WFLY-4478) Server won't shutdown until batch threads are done executing
by James Perkins (JIRA)
James Perkins created WFLY-4478:
-----------------------------------
Summary: Server won't shutdown until batch threads are done executing
Key: WFLY-4478
URL: https://issues.jboss.org/browse/WFLY-4478
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: James Perkins
Assignee: James Perkins
When the server is shutdown, even with {{SIGINT}}, the batch jobs keep running and the JVM will not exit until the batch jobs are complete. Ideally threads spawned from the {{BatchEnvironment}} will be daemon threads. At the least the thread should be interrupted.
Another option would be for JBeret to have a way to stop all running jobs.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
- 1
- 0