[JBoss JIRA] (WFCORE-73) Add CLI command to display information about current connection.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-73?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-2510 to WFCORE-73:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-73 (was: WFLY-2510)
Issue Type: Feature Request (was: Enhancement)
Component/s: CLI
(was: CLI)
Fix Version/s: 1.0.0.Alpha6
(was: Awaiting Volunteers)
> Add CLI command to display information about current connection.
> ----------------------------------------------------------------
>
> Key: WFCORE-73
> URL: https://issues.jboss.org/browse/WFCORE-73
> Project: WildFly Core
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Claudio Miranda
> Labels: management_security,
> Fix For: 1.0.0.Alpha6
>
>
> Would be useful for a single command to display information about the current connection.
> Definitely information about SSL, certificates, authenticated user, address etc...
> Could also obtain other common info from server.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-3711:
-------------------------------------------
As mentioned earlier, the method RegistryCollector.registryRemoved() has its action commented out as removing a registry from the registry collector merely indicates that the node on which the RegistryCollector service is running has left the cluster,not that the cluster has zero members. We only want this method to be called when the last member leaves the cluster. This state of affairs should be true when the condition
{noformat}
registry.getEntries().keySet().size() == 1
{noformat}
is true during the call to registryRemoved. In other words, we know that the current node is leaving a cluster, and that the membership of the cluster being left is 1. So we are the last member. This, with this condition in place, the call to sendClusterRemoved can be reinstated and the cluster contexts cleaned up on the client.
> Topology updates of EJBClient ClusterContexts not being processed correctly after failover
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3711
> URL: https://issues.jboss.org/browse/WFLY-3711
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 9.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
> Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
> The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
> The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3253) CXF should not be installing BouncyCastle
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3253?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-3253:
----------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
Moving this to CR1, as Apache CXF 3.0.2 (containing the required changes) is not being released in time for Beta1.
> CXF should not be installing BouncyCastle
> -----------------------------------------
>
> Key: WFLY-3253
> URL: https://issues.jboss.org/browse/WFLY-3253
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Reporter: David Lloyd
> Assignee: Alessio Soldano
> Priority: Critical
> Fix For: 9.0.0.CR1
>
>
> CXF installs a BouncyCastle provider globally into the security providers list. This is causes performance and other problems when this provider gets chosen for whatever reason to be the system crypto provider for e.g. TLS.
> The list of globally installed security providers should be a user concern only. If CXF requires a specific provider for a specific purpose, it should be selecting that provider when constructing the crytpo API object, though generally this is to be discouraged.
> Ultimately we want to introduce a configuration in the app server that allows the list of security providers to be specified in some way, without interference from any frameworks that we happen to have installed.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3790) Upgrade to JBossWS 5.0.0.Beta1, Apache CXF 3.0.1, Apache WSS4J 2.0.1, Apache Santuario 2.0.1
by Alessio Soldano (JIRA)
Alessio Soldano created WFLY-3790:
-------------------------------------
Summary: Upgrade to JBossWS 5.0.0.Beta1, Apache CXF 3.0.1, Apache WSS4J 2.0.1, Apache Santuario 2.0.1
Key: WFLY-3790
URL: https://issues.jboss.org/browse/WFLY-3790
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Web Services
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: 9.0.0.Beta1
Upgrade the whole WS stack to JBossWS 5.x series:
* JBossWS-CXF 5.0.0.Beta1
* JBossWS-API 1.0.3.CR1
* JBossWS-SPI 3.0.0.Beta1
* JBossWS-Common 3.0.0.Beta1
* Apache CXF 3.0.1
* Apache WSS4J 2.0.1
* Apache Santuario 2.0.1
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3789) Vault cannot be initialized with external password provided by CLASS
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/WFLY-3789?page=com.atlassian.jira.plugin.... ]
Peter Skopek reassigned WFLY-3789:
----------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> Vault cannot be initialized with external password provided by CLASS
> ---------------------------------------------------------------------
>
> Key: WFLY-3789
> URL: https://issues.jboss.org/browse/WFLY-3789
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Filip Bogyai
> Assignee: Peter Skopek
>
> When vault is configured to use external password obtained from CLASS, e.g. :{code:xml} <vault-option name="KEYSTORE_PASSWORD" value="{CLASS}org.jboss.security.plugins.TmpFilePassword:${java.io.tmpdir}/tmp.password"/> {code}
> WildFly is unable to start, because of ClassNotFoundException:
> {code}
> 11:00:40,696 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("core-service" => "vault")]): java.lang.RuntimeException: WFLYSRV0076: Error initializing vault -- org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception:
> at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:88) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:657) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:498) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:299) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:294) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1072) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:375) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:297) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.server.ServerService.boot(ServerService.java:373) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.server.ServerService.boot(ServerService.java:348) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> Caused by: org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception:
> at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:99) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:86) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
> ... 12 more
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
> at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:97) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 13 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.security.Util.invokePasswordClass(Util.java:174) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
> at org.jboss.security.Util.loadPassword(Util.java:126) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:343) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
> ... 14 more
> {code}
> External passwords for vault were introduces by RFE: SECURITY-831
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3789) Vault cannot be initialized with external password provided by CLASS
by Filip Bogyai (JIRA)
Filip Bogyai created WFLY-3789:
----------------------------------
Summary: Vault cannot be initialized with external password provided by CLASS
Key: WFLY-3789
URL: https://issues.jboss.org/browse/WFLY-3789
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Reporter: Filip Bogyai
Assignee: Darran Lofthouse
When vault is configured to use external password obtained from CLASS, e.g. :{code:xml} <vault-option name="KEYSTORE_PASSWORD" value="{CLASS}org.jboss.security.plugins.TmpFilePassword:${java.io.tmpdir}/tmp.password"/> {code}
WildFly is unable to start, because of ClassNotFoundException:
{code}
11:00:40,696 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("core-service" => "vault")]): java.lang.RuntimeException: WFLYSRV0076: Error initializing vault -- org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception:
at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:88) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:657) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:498) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:299) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:294) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1072) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:375) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:297) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.server.ServerService.boot(ServerService.java:373) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.server.ServerService.boot(ServerService.java:348) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
Caused by: org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception:
at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:99) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:86) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4]
... 12 more
Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:97) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
... 13 more
Caused by: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
at org.jboss.security.Util.invokePasswordClass(Util.java:174) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
at org.jboss.security.Util.loadPassword(Util.java:126) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:343) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3]
... 14 more
{code}
External passwords for vault were introduces by RFE: SECURITY-831
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3784) JMX remoting-connector dependency error
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3784?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-3784.
------------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Rejected
Jira is for the management and scheduling of bugs and features, for assistance with your configuration please use the community forums.
If you are unfamiliar with the best place for different tasks I recommend starting at http://wildfly.org/
> JMX remoting-connector dependency error
> ---------------------------------------
>
> Key: WFLY-3784
> URL: https://issues.jboss.org/browse/WFLY-3784
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Rakesh Panati
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> My WildFly 8.1 configuration contains the below subsystem profile.
> <server xmlns="urn:jboss:domain:2.1">
> <extensions>
> ....
> <extension module="org.jboss.as.remoting"/>
> ....
> </extensions>
> ...........
> <profile>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> </profile>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </server>
> During startup, the JMX addition fails with the below error
> 2014-08-27 14:34:06,301 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "jmx"),
> ("remoting-connector" => "jmx")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.jmx.remoting-connector-ref is missing [jboss.remoting.endpoint.management]"]}
> 2014-08-27 14:34:06,329 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.management (missing) dependents: [service jboss.jmx.remoting-connector-ref]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3784) JMX remoting-connector dependency error
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3784?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3784:
--------------------------------------
Assignee: Darran Lofthouse (was: Jason Greene)
> JMX remoting-connector dependency error
> ---------------------------------------
>
> Key: WFLY-3784
> URL: https://issues.jboss.org/browse/WFLY-3784
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Rakesh Panati
> Assignee: Darran Lofthouse
>
> My WildFly 8.1 configuration contains the below subsystem profile.
> <server xmlns="urn:jboss:domain:2.1">
> <extensions>
> ....
> <extension module="org.jboss.as.remoting"/>
> ....
> </extensions>
> ...........
> <profile>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> </profile>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </server>
> During startup, the JMX addition fails with the below error
> 2014-08-27 14:34:06,301 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "jmx"),
> ("remoting-connector" => "jmx")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.jmx.remoting-connector-ref is missing [jboss.remoting.endpoint.management]"]}
> 2014-08-27 14:34:06,329 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.management (missing) dependents: [service jboss.jmx.remoting-connector-ref]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez closed WFLY-3724.
-------------------------------------------
Resolution: Rejected
> Batch jobs don't receive partition-specific parameters
> ------------------------------------------------------
>
> Key: WFLY-3724
> URL: https://issues.jboss.org/browse/WFLY-3724
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
> Reporter: Ari Silvan
> Assignee: Enrique González Martínez
>
> When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez commented on WFLY-3724:
-------------------------------------------------
I don't think this behavior can be considered a bug. Partition properties are available through xml substitution and they are in step scope.
Extracted from the JavaDoc
jsr 352 -> 10.9.7
JobOperator::getParameters(execID)
"Returns job parameters for a specified job instance. These are the key/value pairs specified when the instance was originally created by the start method."
That means the properties passed during creation: JobOperator::start(jobXMLName, jobParameters).
It does not mention anything about partition plan properties available to the job parameters or job properties (through the JobContext).
The specification states that:
jsr352 -> 10.9.4 PartitionPlan
PartitionPlan::getPartitionProperties()
"Gets array of Partition Properties objects for Partitions. These can be used in Job XML substitution using substitution expressions with the syntax: #{partitionPlan['propertyName']}
Each element of the Properties array returned can be used to resolving substitutions for a single partition. In the typical use case, each Properties element will have a similar set of property names, with a substitution potentially resolving to the corresponding value for each partition."
jsr 352 -> 8.8.1.4 partitionPlan Substitution Operator
"The partitionPlan substitution operator resolves to the value of the partition plan property with the specified target name from the PartitionPlan returned by the PartitionMapper
Partition plan properties are in scope only for the step to which the partition plan is defined. The partitionPlan operator is resolved separately for each partition before the partition execution begins. "
> Batch jobs don't receive partition-specific parameters
> ------------------------------------------------------
>
> Key: WFLY-3724
> URL: https://issues.jboss.org/browse/WFLY-3724
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
> Reporter: Ari Silvan
> Assignee: Enrique González Martínez
>
> When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months