[JBoss JIRA] (WFLY-6269) connector-service resource does not define a module for the classes to load
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6269?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-6269 at 3/1/16 4:12 AM:
-----------------------------------------------------------
There is a global solution that would work in all cases: add an optional module dependency to org.apache.activemq.artemis module (eg named "org.apache.activemq.artemis.addons").
Since it is an optional module, it does not require to exist. If users wants to specify specific classes in Artemis, they could create this module and add the classes to it so that Artemis could load them.
This also make sure that the user does not have to edit org.apache.activemq.artemis own module definition (which prevents patching to work).
Ideally, all the resources that requires to load classes should define both a class name and a module. In practice, this is important for the transformers of the divert and bridge resources and the connector-services. This is less important for the connector/acceptor (the implementations are so complex, I've never see anybody specifying something other than Artemis own implementations) and connection-load-balancing-policy-class-name.
Changing these resource definitions is more involving (it requires new management versions, XSD, transformers, etc.) and would be better addressed in WFLY 11.x.
The global solution of adding an optional module can be done in WFLY 10.x timeframe and will not prevent refining the resources later on.
was (Author: jmesnil):
There is a global solution that would work in all cases: add an optional module dependency to org.apache.activemq.artemis module (eg named "org.apache.activemq.artemis.addons").
Since it is an optional module, it does not require to exist. If users wants to specify specific classes in Artemis, they could create this module and add the classes to it so that Artemis could load them.
This also make sure that the user does not have to edit org.apache.activemq.artemis own module definition (which prevents patching to work).
Ideally, all the resources that requires to load classes should define both a class name and a module. In practice, this is important for the transformers of the divert and bridge resources. This is less important for the connector/acceptor (the implementations are so complex, I've never see anybody specifying something other than Artemis own implementations) and connection-load-balancing-policy-class-name.
Changing these resource definitions is more involving (it requires new management versions, XSD, transformers, etc.) and would be better addressed in WFLY 11.x.
The global solution of adding an optional module can be done in WFLY 10.x timeframe and will not prevent refining the resources later on.
> connector-service resource does not define a module for the classes to load
> ---------------------------------------------------------------------------
>
> Key: WFLY-6269
> URL: https://issues.jboss.org/browse/WFLY-6269
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The connector-service resource has only a factory-class attribute and does not specify from which module the class should be loaded.
> {noformat}
> <connector-service name="b"
> factory-class="bar.foo">
> <param name="foo"
> value="${connector.value:bar}"/>
> <param name="bar"
> value="2"/>
> </connector-service>
> {noformat}
> This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
> A module attribute should be added so that the class could be loaded from any module.
> The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6269) connector-service resource does not define a module for the classes to load
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6269?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6269:
-----------------------------------
There is a global solution that would work in all cases: add an optional module dependency to org.apache.activemq.artemis module (eg named "org.apache.activemq.artemis.addons").
Since it is an optional module, it does not require to exist. If users wants to specify specific classes in Artemis, they could create this module and add the classes to it so that Artemis could load them.
This also make sure that the user does not have to edit org.apache.activemq.artemis own module definition (which prevents patching to work).
Ideally, all the resources that requires to load classes should define both a class name and a module. In practice, this is important for the transformers of the divert and bridge resources. This is less important for the connector/acceptor (the implementations are so complex, I've never see anybody specifying something other than Artemis own implementations) and connection-load-balancing-policy-class-name.
Changing these resource definitions is more involving (it requires new management versions, XSD, transformers, etc.) and would be better addressed in WFLY 11.x.
The global solution of adding an optional module can be done in WFLY 10.x timeframe and will not prevent refining the resources later on.
> connector-service resource does not define a module for the classes to load
> ---------------------------------------------------------------------------
>
> Key: WFLY-6269
> URL: https://issues.jboss.org/browse/WFLY-6269
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The connector-service resource has only a factory-class attribute and does not specify from which module the class should be loaded.
> {noformat}
> <connector-service name="b"
> factory-class="bar.foo">
> <param name="foo"
> value="${connector.value:bar}"/>
> <param name="bar"
> value="2"/>
> </connector-service>
> {noformat}
> This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
> A module attribute should be added so that the class could be loaded from any module.
> The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1074) Kie-spring read resources on EAP not working
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1074?page=com.atlassian.jira.plugi... ]
Petr Široký updated DROOLS-1074:
--------------------------------
Component/s: integration
> Kie-spring read resources on EAP not working
> --------------------------------------------
>
> Key: DROOLS-1074
> URL: https://issues.jboss.org/browse/DROOLS-1074
> Project: Drools
> Issue Type: Bug
> Components: integration
> 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)
10 years, 1 month
[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2022 at 3/1/16 1:46 AM:
--------------------------------------------------------
I ran all schemas listed above through IntelliJ IDEA's XML validator, and they all passed with 0 errors. I don't have access to Oxygen as I don't want to register. Any other tool I could use for validation?
was (Author: belaban):
I ran all schemas listed above through IntelliJ IDEA's XML validator, and they all passed with 0 errors. I don't have access to Oxygen as I don't ant to register. Any other tool I could use for validation?
> 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
> Fix For: 4.0
>
>
> 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)
10 years, 1 month
[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2022:
--------------------------------
I ran all schemas listed above through IntelliJ IDEA's XML validator, and they all passed with 0 errors. I don't have access to Oxygen as I don't ant to register. Any other tool I could use for validation?
> 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
> Fix For: 4.0
>
>
> 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)
10 years, 1 month
[JBoss JIRA] (WFLY-6300) Batch extension fails module deployment if JobOperator provider not found
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6300?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov resolved WFLY-6300.
----------------------------------
Resolution: Won't Fix
Workaround found.
> 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: James Perkins
>
> 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)
10 years, 2 months
[JBoss JIRA] (WFLY-6300) Batch extension fails module deployment if JobOperator provider not found
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6300?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-6300:
--------------------------------------
[~jamezp], nevermind, found a way to exclude the batch through deployment unit attachment. Thanks for your help!
> 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: James Perkins
>
> 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)
10 years, 2 months
[JBoss JIRA] (WFLY-6293) <ejb-name> tag in <interceptor-binding> should support regular expression usages
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6293?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6293:
--------------------------------------
After thinking about this a bit more their are two complications that I can see:
1) There does not seem to be any requirement that bean names be alphanumeric, so it is possible that applications may have bean names that contain special characters
2) Should these interceptors be considered class level interceptors or default interceptors? I think they should probably be considered class level interceptors
WRT 1) I think we probably need some kind of setting to enable/disable this (possibly overriding spec-descriptor-property-replacement, or adding another similar command).
> <ejb-name> tag in <interceptor-binding> should support regular expression usages
> --------------------------------------------------------------------------------
>
> Key: WFLY-6293
> URL: https://issues.jboss.org/browse/WFLY-6293
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Stuart Douglas
>
> From the ejb specification the only possibility is to use the full EJB name or the wildcard "*".
> * If the application is too large with many hundreds or thousand ejbs then it is complex to define the interceptor individually for number of beans having a common name pattern.
> The <ejb-name> element in <interceptor-binding> should support regular expression usages. Like following via "ejb-jar.xml" or using "jboss-ejb3.xml":
> {code}
> <interceptor-binding>
> <ejb-name>Intercepted*Bean</ejb-name>
> <interceptor-class>interceptors.InterceptorOne</interceptor-class>
> </interceptor-binding>
> <interceptor-binding>
> <ejb-name>[AB]*Bean</ejb-name>
> <interceptor-class>interceptors.InterceptorOne</interceptor-class>
> </interceptor-binding>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months