[JBoss JIRA] (WFLY-6300) Batch extension fails module deployment if JobOperator provider not found
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created WFLY-6300:
------------------------------------
Summary: Batch extension fails module deployment if JobOperator provider not found
Key: WFLY-6300
URL: https://issues.jboss.org/browse/WFLY-6300
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 9.0.2.Final
Reporter: Arcadiy Ivanov
Assignee: David Lloyd
I'm a maintainer for JBOSGI, trying to bring the plugin up to 9.x and 10.x.
Unfortunately, WildFly batch extension assumes that ANY module being inspected will have a classloader capable of finding a JobOperator provider, and if it doesn't the module will not be deployed.
This assumption is, obviously, wrong.
Generally the error looks like this:
{noformat}
15:55:56,679 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0010: Deployed "arquillian-service" (runtime-name : "arquillian-service")
15:55:57,049 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /Users/arcivanov/Documents/src/jbosgi/jbosgi/wildfly/build/target/wildfly-9.0.2.Final/standalone/data/content/13/040c763e3f044cd7bbf3475a137bb620158bc1/content
15:55:57,055 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "simple-bundle" (runtime-name: "simple-bundle")
15:55:57,070 INFO [org.jboss.osgi.framework] (MSC service thread 1-7) JBOSGI011001: Bundle installed: simple-bundle:0.0.0
15:55:57,112 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.simple-bundle.batch.job-operator: org.jboss.msc.service.StartException in service jboss.deployment.unit.simple-bundle.batch.job-operator: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.batch.operations.BatchRuntimeException: The ServiceLoader was unable to find an implemenation for JobOperator. Check classpath for META-INF/services/javax.batch.operations.JobOperator file.
at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:73)
at org.wildfly.extension.batch.deployment.JobOperatorService.start(JobOperatorService.java:90)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
15:55:57,112 INFO [org.jboss.as.arquillian] (MSC service thread 1-8) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config.simple-bundle,unit=simple-bundle,tests=[org.jboss.test.osgi.build.SimpleBundleLifecycleTestCase]]
15:55:57,118 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: simple-bundle:0.0.0
15:55:57,120 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "simple-bundle")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.simple-bundle.batch.job-operator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.simple-bundle.batch.job-operator: Failed to start service
{noformat}
In more detail, the error looks like this:
The HostBundleClassLoader is asked by BatchRuntime to enumerate JobOperator services via ServiceLoader.load, returning no providers which triggers an exception.
{noformat}
2016-02-29 15:55:57,110 TRACE [org.wildfly.extension.batch] (MSC service thread 1-1) Processing deployment 'simple-bundle' for the batch deployment resources.
2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Finding class org.jboss.as.arquillian.service.ArquillianConfig from Module "deployment.arquillian-service:main" from Service Module Loader
2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Finding local class org.jboss.as.arquillian.service.ArquillianConfig from Module "deployment.arquillian-service:main" from Service Module Loader
2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00337: nextState for action getPolicyConfiguration: open
2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Loading class org.jboss.as.arquillian.service.ArquillianConfig locally from Module "deployment.arquillian-service:main" from Service Module Loader
2016-02-29 15:55:57,111 DEBUG [org.jboss.security] (MSC service thread 1-2) PBOX00307: Constructing JBossPolicyConfiguration with contextID simple-bundle
2016-02-29 15:55:57,111 TRACE [org.jboss.as.naming] (MSC service thread 1-5) Bound resource env into naming store org.jboss.as.naming.ServiceBasedNamingStore@63739568 (service name service jboss.naming.context.java.app.simple-bundle.env)
2016-02-29 15:55:57,111 TRACE [org.jboss.as.naming] (MSC service thread 1-7) Bound resource env into naming store org.jboss.as.naming.ServiceBasedNamingStore@63739568 (service name service jboss.naming.context.java.module.simple-bundle.simple-bundle.env)
2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00337: nextState for action getPolicyConfiguration: open
2016-02-29 15:55:57,111 DEBUG [org.jboss.as.security] (MSC service thread 1-2) Cannot create permissions with 'null' metaData for id=simple-bundle
2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Attempting to define class org.jboss.as.arquillian.service.ArquillianConfig in Module "deployment.arquillian-service:main" from Service Module Loader
2016-02-29 15:55:57,111 TRACE [org.jboss.osgi.framework] (MSC service thread 1-4) LockManager locked: (START) [simple-bundle:0.0.0, simple-bundle:0.0.0]
2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-6) Attempting to find all resources META-INF/services/javax.batch.operations.JobOperator in Module "deployment.simple-bundle:main" from Service Module Loader
2016-02-29 15:55:57,111 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-4) Starting bundle: simple-bundle:0.0.0
2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00314: commit, contextID: simple-bundle
2016-02-29 15:55:57,111 TRACE [org.jboss.osgi.framework] (MSC service thread 1-6) Class [META-INF/services/javax.batch.operations.JobOperator] does not match Dynamic-ImportPackage patterns
2016-02-29 15:55:57,112 TRACE [org.jboss.modules] (MSC service thread 1-8) Defined class org.jboss.as.arquillian.service.ArquillianConfig in Module "deployment.arquillian-service:main" from Service Module Loader
2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00337: nextState for action commit: inService
2016-02-29 15:55:57,112 TRACE [org.jboss.osgi.framework] (MSC service thread 1-4) changeState: simple-bundle:0.0.0 -> STARTING
2016-02-29 15:55:57,113 TRACE [org.jboss.osgi.deployment] (MSC service thread 1-4) Invoke: [org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state STARTING on simple-bundle
2016-02-29 15:55:57,112 INFO [org.jboss.as.arquillian] (MSC service thread 1-8) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config.simple-bundle,unit=simple-bundle,tests=[org.jboss.test.osgi.build.SimpleBundleLifecycleTestCase]]
2016-02-29 15:55:57,112 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.simple-bundle.batch.job-operator: org.jboss.msc.service.StartException in service jboss.deployment.unit.simple-bundle.batch.job-operator: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.batch.operations.BatchRuntimeException: The ServiceLoader was unable to find an implemenation for JobOperator. Check classpath for META-INF/services/javax.batch.operations.JobOperator file.
at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:73)
at org.wildfly.extension.batch.deployment.JobOperatorService.start(JobOperatorService.java:90)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
{noformat}
The questions, therefore, are:
# Any way for module to indicate it doesn't want to be inspected by WildFly Batch Extension?
# Should this behavior be fixed in principle?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (LOGMGR-124) Add marker support
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-124:
--------------------------------------
Correct. Really my objection to adding marker support could be that I don't fully understand it. To me it just looks like a filter, but again maybe I'm misunderstanding them.
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1397) Boot errors and unmanageable server if http-interface resource's http-upgrade-enabled attribute != true
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1397?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges reassigned WFCORE-1397:
--------------------------------------------
Assignee: Yeray Santana Borges
> Boot errors and unmanageable server if http-interface resource's http-upgrade-enabled attribute != true
> -------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1397
> URL: https://issues.jboss.org/browse/WFCORE-1397
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.CR1
> Reporter: Brian Stansberry
> Assignee: Yeray Santana Borges
> Priority: Critical
> Fix For: 2.1.0.CR2
>
>
> The https://github.com/wildfly/wildfly-core/pull/1360 work added a new XnioWorker service that the HTTP interface depends on, but for a standalone server it isn't installed unless http-upgrade-enabled == true. Otherwise you see this during boot:
> {code}
> 15:43:25,005 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.serverManagement.controller.management.http is missing [jboss.serverManagement.controller.management.worker]",
> "jboss.serverManagement.controller.management.http.shutdown is missing [jboss.remoting.management.channel.registry]"
> ]}
> 15:43:25,006 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jmx"),
> ("remoting-connector" => "jmx")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.jmx.remoting-connector-ref is missing [jboss.remoting.endpoint.management]"]}
> 15:43:25,031 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.management (missing) dependents: [service jboss.jmx.remoting-connector-ref]
> service jboss.remoting.management.channel.registry (missing) dependents: [service jboss.serverManagement.controller.management.http.shutdown]
> service jboss.serverManagement.controller.management.worker (missing) dependents: [service jboss.serverManagement.controller.management.http]
> 15:43:25,127 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0063: Http management interface is not enabled
> 15:43:25,128 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
> 15:43:25,128 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.0.0.GA (WildFly Core 2.0.12.Final-redhat-1) started (with errors) in 3493ms - Started 254 of 544 services (3 services failed or missing dependencies, 369 services are lazy, passive or on-demand)
> {code}
> The problem is org.jboss.as.server.operations.HttpManagementAddHandler doesn't install the service. The HC variant of HttpManagementAddHandler does.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-232) Unclean shutdown of deployment scanner
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-232?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-232:
-----------------------------------------
[~ozizka] If you see this with WildFly 10.0.0.Final or the latest EAP 7 ER, please file a new JRIA with details.
> Unclean shutdown of deployment scanner
> --------------------------------------
>
> Key: WFCORE-232
> URL: https://issues.jboss.org/browse/WFCORE-232
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Beta4
>
>
> I happened to see this in a testsuite log file:
> {code}
> 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
> at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
> at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669)
> at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.)
> Waiting for tasks to complete could be tricky, e.g. imagine this race:
> 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services.
> 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock.
> Deadlock.
> Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit.
> But ^^^ is just a quick look, so be cautious!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6299) PostgreSQL Non-XA DS - relation does not exist
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6299?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFCORE-1416 to WFLY-6299:
------------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-6299 (was: WFCORE-1416)
> PostgreSQL Non-XA DS - relation does not exist
> ----------------------------------------------
>
> Key: WFLY-6299
> URL: https://issues.jboss.org/browse/WFLY-6299
> Project: WildFly
> Issue Type: Bug
> Environment: WildFly 10.0.0.Final, PostgreSQL 9.4, PostgreSQL JDBC Driver 9.3 and 9.4
> Reporter: Anton Saburov
> Labels: datasource, postgresql
>
> I tried to check the same in WildFly 8.2.1 and 9.0.2 - everything is working
> WildFly 10 - I get error.
> Registered PostgreSQL JDBC driver as a module:
> module add --name=org.postgresql --resources=postgresql-9.3-1102-jdbc41.jar --resource-delimiter=, --dependencies=javax.api,javax.transaction.api
> Registered PostgreSQL JDBC driver:
> /subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql, driver-module-name=org.postgresql, driver-class-name=org.postgresql.Driver, driver-datasource-class-name=org.postgresql.ds.PGSimpleDataSource, driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
> Created Non-XA Datasource - MyDS and XA Datasource MyXADS
> When I try to use Non-XA DS - I got error: relation "<table>" does not exist
> When I try to use XA DS - all is OK.
> I checked list of schema by SQL script: "select distinct table_schema from information_schema.tables"
> For Non-XA I see only this:
> - information_schema
> - pg_default
> For XA I see this:
> - information_schema
> - pg_default
> - public
> Maybe I have to make some additional options for DS ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1074) Kie-spring read resources on EAP not working
by David virgil naranjo (JIRA)
David virgil naranjo created DROOLS-1074:
--------------------------------------------
Summary: Kie-spring read resources on EAP not working
Key: DROOLS-1074
URL: https://issues.jboss.org/browse/DROOLS-1074
Project: Drools
Issue Type: Bug
Affects Versions: 6.4.0.Beta2
Reporter: David virgil naranjo
Assignee: Petr Široký
had to touch little bit the Kie-Spring to get the resources correctly. This is the only class I had to touch:
https://gist.github.com/dvirgiln/0f65d184c2004127b1db#file-gistfile1-txt-...
getClass().getResource("/") is failing on EAP, it returns null
This code needs to get the path of the kie-spring.jar. This is the only way I found to get the containing jar path.
This code is working. Maybe you know another way.
ClassLoader cl = getClass().getClassLoader();
URL url = getClass().getProtectionDomain().getCodeSource().getLocation();
configFilePath = url.getPath();
if (configFilePath.endsWith("!/")) {
configFilePath = configFilePath.substring(0, configFilePath.length() - 2);
}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate
by Manuel Dominguez Sarmiento (JIRA)
Manuel Dominguez Sarmiento created JGRP-2022:
------------------------------------------------
Summary: XSD schemas do not properly validate
Key: JGRP-2022
URL: https://issues.jboss.org/browse/JGRP-2022
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.8
Reporter: Manuel Dominguez Sarmiento
Assignee: Bela Ban
Priority: Minor
Affected resources:
- jgroups.xsd
- relay.xsd
- fork-stacks.xsd
Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6295) Wrong header comments on integration-tests.sh script
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6295?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6295:
--------------------------------------
Component/s: Test Suite
(was: Documentation)
Assignee: Eduardo Silva (was: Jason Greene)
> Wrong header comments on integration-tests.sh script
> ----------------------------------------------------
>
> Key: WFLY-6295
> URL: https://issues.jboss.org/browse/WFLY-6295
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Eduardo Silva
> Assignee: Eduardo Silva
> Priority: Minor
>
> Wrong header comments on integration-tests.sh script, the header of integration-tests.sh script was copied of the build.sh script.
> ### ====================================================================== ###
> ## ##
> ## This is the main entry point for the build system. ##
> ## ##
> ## Users should execute this file rather than 'mvn' to ensure ##
> ## the correct version is being used with the correct configuration. ##
> ## ##
> ### ====================================================================== ###
> # $Id: build.sh 105735 2010-06-04 19:45:13Z pgier $
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months