[JBoss JIRA] (WFLY-6636) WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6636?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6636:
-----------------------------------------------
Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1338093|https://bugzilla.redhat.com/show_bug.cgi?id=1338093] from NEW to ASSIGNED
> WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6636
> URL: https://issues.jboss.org/browse/WFLY-6636
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Tomas Hofman
> Attachments: test.ear
>
>
> If a sub deployment uses another sub deployment's module-alias as a dependency, it will deploy successfully, but if hot deployed, it will fail with the error below. Attached reproducer.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <sub-deployment name="ejb1.jar">
> <module-alias name="deployment.ejb1"/>
> </sub-deployment>
> <sub-deployment name="ejb2.jar">
> <dependencies>
> <!-- works
> <module name="deployment.test.ear.ejb1.jar" slot="main"/>
> -->
> <!-- fails with WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default on redeploy / hot deploy -->
> <module name="deployment.ejb1" slot="main"/>
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> {code}
> 10:43:42,140 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."test.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 10:43:42,144 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> "}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6402:
-----------------------------------------------
Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1310908|https://bugzilla.redhat.com/show_bug.cgi?id=1310908] from ON_QA to POST
> EJBs accessible too early (spec violation)
> ------------------------------------------
>
> Key: WFLY-6402
> URL: https://issues.jboss.org/browse/WFLY-6402
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency
> Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
> "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1598:
----------------------------------------
Summary: Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
Key: WFCORE-1598
URL: https://issues.jboss.org/browse/WFCORE-1598
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Alpha2
In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request.
For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1203) OptaPlanner on KIE Server running on Wildfly 9.0.2 throwing IllegalArgumentException on startup
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1203?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1203:
------------------------------------------
PR send for master: https://github.com/droolsjbpm/droolsjbpm-integration/pull/496
> OptaPlanner on KIE Server running on Wildfly 9.0.2 throwing IllegalArgumentException on startup
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1203
> URL: https://issues.jboss.org/browse/DROOLS-1203
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Environment: Wildfly 9.0.2
> Reporter: Jonathan Holmström
> Assignee: Geoffrey De Smet
> Fix For: 7.0.0.Beta1
>
>
> The following exception is thrown at startup. The server still starts successfully.
> [31m04:08:44,729 ERROR [org.kie.server.services.impl.KieServerImpl] (ServerService Thread Pool -- 65) Error when initializing server extension of type OptaPlanner KIE Server extension: java.lang.IllegalArgumentException
> at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1307)
> at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1195)
> at org.kie.server.services.optaplanner.OptaplannerKieServerExtension.init(OptaplannerKieServerExtension.java:75)
> at org.kie.server.services.impl.KieServerImpl.<init>(KieServerImpl.java:108)
> at org.kie.server.services.impl.KieServerLocator.<clinit>(KieServerLocator.java:20)
> at org.kie.server.services.Bootstrap.contextInitialized(Bootstrap.java:50)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1206) KIE Execution Server documentation shows faulty time unit for KieScanner interval.
by Jonathan Holmström (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1206?page=com.atlassian.jira.plugi... ]
Jonathan Holmström commented on DROOLS-1206:
--------------------------------------------
This is listed as fixed for BRMS but seems to remain a problem in Drools
> KIE Execution Server documentation shows faulty time unit for KieScanner interval.
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-1206
> URL: https://issues.jboss.org/browse/DROOLS-1206
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Reporter: Jonathan Holmström
> Assignee: Mark Proctor
>
> In Rule Deployments -> Container -> Version Configuration
> The input interval is interpreted as milliseconds, not seconds. The documentation indicates that this should be seconds.
> From: https://docs.jboss.org/drools/release/6.4.0.Final/drools-docs/html/ch22.html
> Quote:
> Automatic Update: If you want a deployed Container to always have the latest version of your deployment without manually editing it, you will need to set the Version property to the value of LATEST and start a Scanner. This will ensure that the deployed provision always contains the latest version. The Scanner can be started just once on demand by clicking the Scan Now button or you can start it in the background with scans happening at a specified interval (in seconds).You can also set this value to LATEST when you are first creating this deployment. The Resolved Release Id in this case will show you the actual, latest version number.
> Relevant section:
> "scans happening at a specified interval (in seconds)"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1208) Listed deployed packages are duplicated when creating a new Container in Workbench.
by Jonathan Holmström (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1208?page=com.atlassian.jira.plugi... ]
Jonathan Holmström updated DROOLS-1208:
---------------------------------------
Steps to Reproduce:
- Open or Reopen the workbench UI (should show "Please wait Loading application...")
- Navigate to Rule Deployments -> +Add Container
- The list will contain duplicates of every package. Selecting the duplicate entry (the second one) will result in an error.
was:
- Open or Reopen the workbench UI (should show "Please wait Loading application...")
- Navigate to Rule Deployments -> +Add Container
- The list will contain duplicates of every package. Clicking the duplicate entry (the second one) will result in an error.
> Listed deployed packages are duplicated when creating a new Container in Workbench.
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1208
> URL: https://issues.jboss.org/browse/DROOLS-1208
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Reporter: Jonathan Holmström
> Assignee: Mark Proctor
>
> This only seems to occur on the first container create window you open after starting the workbench UI. Closing and reopening the window removes the duplication.
> When the packages are duplicated, clicking the second entry for each package will result in:
> 11:17:40,985 ERROR [org.guvnor.m2repo.backend.server.GuvnorM2Repository] (default task-64) error in opening zip file
> And will not fill in any package fields. The first entry works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1208) Listed deployed packages are duplicated when creating a new Container in Workbench.
by Jonathan Holmström (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1208?page=com.atlassian.jira.plugi... ]
Jonathan Holmström updated DROOLS-1208:
---------------------------------------
Description:
This only seems to occur on the first container create window you open after starting the workbench UI. Closing and reopening the window removes the duplication.
When the packages are duplicated, selecting the second entry for each package will result in:
11:17:40,985 ERROR [org.guvnor.m2repo.backend.server.GuvnorM2Repository] (default task-64) error in opening zip file
And will not fill in any package fields. The first entry works as expected.
was:
This only seems to occur on the first container create window you open after starting the workbench UI. Closing and reopening the window removes the duplication.
When the packages are duplicated, clicking the second entry for each package will result in:
11:17:40,985 ERROR [org.guvnor.m2repo.backend.server.GuvnorM2Repository] (default task-64) error in opening zip file
And will not fill in any package fields. The first entry works as expected.
> Listed deployed packages are duplicated when creating a new Container in Workbench.
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1208
> URL: https://issues.jboss.org/browse/DROOLS-1208
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Reporter: Jonathan Holmström
> Assignee: Mark Proctor
>
> This only seems to occur on the first container create window you open after starting the workbench UI. Closing and reopening the window removes the duplication.
> When the packages are duplicated, selecting the second entry for each package will result in:
> 11:17:40,985 ERROR [org.guvnor.m2repo.backend.server.GuvnorM2Repository] (default task-64) error in opening zip file
> And will not fill in any package fields. The first entry works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years