[JBoss JIRA] (WFCORE-3322) Invalid socket-binding config in remoting connector resource does not lead to model integrity failure
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3322:
----------------------------------------
Summary: Invalid socket-binding config in remoting connector resource does not lead to model integrity failure
Key: WFCORE-3322
URL: https://issues.jboss.org/browse/WFCORE-3322
Project: WildFly Core
Issue Type: Bug
Components: Remoting
Reporter: Brian Stansberry
Assignee: Brian Stansberry
A remoting connector with a socket-binding attribute pointing to a non-existing s-b does not fail with a capability validation failure:
{code}
[standalone@localhost:9990 /] /subsystem=remoting/connector=remoting-connector:add(security-realm=ApplicationRealm,socket-binding=remoting)
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.network.socket-binding.remoting"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.remoting-connector is missing [org.wildfly.network.socket-binding.remoting]"]
},
"rolled-back" => true
}
{code}
As in all such cases of missing cap validation, that means it doesn't fail at all in admin-only:
{code}
[standalone@localhost:9990 /] reload --admin-only=true
[standalone@localhost:9990 /] /subsystem=remoting/connector=remoting-connector:add(security-realm=ApplicationRealm,socket-binding=remoting)
{"outcome" => "success"}
{code}
Problem is ConnectorAdd isn't passing its attributes into the superclass, which means the superclass' recording of capability requirements isn't done.
I'll check for other occurrences of this pattern in the subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9405) NPE when trying to recursively remove the EJB subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9405?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9405:
-----------------------------------
Workaround Description:
Put the server in admin-only mode before removing the subsystem.
{code}
[standalone@localhost:9990 /] reload --admin-only=true
[standalone@localhost:9990 /] /subsystem=ejb3:remove
{"outcome" => "success"}
{code}
Putting the server in admin-only before doing this kind of surgery is probably a good idea anyway.
was:
Put the server in admin-only mode before removing the subsystem.
{code}
[standalone@localhost:9990 /] reload --admin-only=true
[standalone@localhost:9990 /] /subsystem=ejb3:remove
{"outcome" => "success"}
{code}
> NPE when trying to recursively remove the EJB subsystem
> -------------------------------------------------------
>
> Key: WFLY-9405
> URL: https://issues.jboss.org/browse/WFLY-9405
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> This fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> with this in the server log:
> {code}
> 15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote"),
> ("channel-creation-options" => "MAX_OUTBOUND_MESSAGES")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894)
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39)
> at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> ...
> {code}
> I believe a post-boot add of this resource would fail as well.
> Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service".
> Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9405) NPE when trying to recursively remove the EJB subsystem
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9405:
--------------------------------------
Summary: NPE when trying to recursively remove the EJB subsystem
Key: WFLY-9405
URL: https://issues.jboss.org/browse/WFLY-9405
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
This fails:
{code}
[standalone@localhost:9990 /] /subsystem=ejb3:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
with this in the server log:
{code}
15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([
("subsystem" => "ejb3"),
("service" => "remote"),
("channel-creation-options" => "MAX_OUTBOUND_MESSAGES")
]): java.lang.NullPointerException
at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894)
at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884)
at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216)
at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39)
at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
...
{code}
I believe a post-boot add of this resource would fail as well.
Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service".
Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9404) [GSS](7.2.0) Unable to deploy clustered ejb in a mixed domain.
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-9404:
----------------------------------
Summary: [GSS](7.2.0) Unable to deploy clustered ejb in a mixed domain.
Key: WFLY-9404
URL: https://issues.jboss.org/browse/WFLY-9404
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 11.0.0.CR1
Reporter: Brad Maxwell
Assignee: Paul Ferraro
Attachments: Clusterejb-0.0.1.jar, domain_EAP7.xml, host_EAP7.xml, host_slave_EAP6.xml
Using a ha profile in a mixed domain( i.e EAP 7 as a domain controler and EAP 6.3 as a slave) it does not seem possible to deploy ejb successfully.
While deploying a simple @clustered ejb on EAP 6.3 server below exception was thrown. This issue is easily replicated.
{code:java}
19:12:11,886 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named CounterBean in deployment unit deployment "Clusterejb-0.0.1.jar" are as follows:
java:global/Clusterejb-0.0.1/CounterBean!com.test.Counter
java:app/Clusterejb-0.0.1/CounterBean!com.test.Counter
java:module/CounterBean!com.test.Counter
java:jboss/exported/Clusterejb-0.0.1/CounterBean!com.test.Counter
java:global/Clusterejb-0.0.1/CounterBean
java:app/Clusterejb-0.0.1/CounterBean
java:module/CounterBean
19:12:12,089 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "Clusterejb-0.0.1.jar" (runtime-name : "Clusterejb-0.0.1.jar")
19:12:12,090 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jboss.ejb.cache.cluster.simple (missing) dependents: [service jboss.ejb.cache.cluster]
19:12:12,093 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 2654ms - Started 185 of 293 services (14 services failed or missing dependencies, 117 services are lazy, passive or on-demand)
{code}
I have attached the configuration files for both EAP 7 and EAP 6.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9403) Unable to deploy clustered ejb in a mixed domain.
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-9403?page=com.atlassian.jira.plugin.... ]
Brad Maxwell moved JBEAP-13293 to WFLY-9403:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9403 (was: JBEAP-13293)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
EJB
(was: Clustering)
(was: EJB)
Affects Version/s: 11.0.0.CR1
(was: 7.0.7.GA)
> Unable to deploy clustered ejb in a mixed domain.
> -------------------------------------------------
>
> Key: WFLY-9403
> URL: https://issues.jboss.org/browse/WFLY-9403
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Brad Maxwell
> Assignee: Paul Ferraro
> Attachments: Clusterejb-0.0.1.jar, domain_EAP7.xml, host_EAP7.xml, host_slave_EAP6.xml
>
>
> Using a ha profile in a mixed domain( i.e EAP 7 as a domain controler and EAP 6.3 as a slave) it does not seem possible to deploy ejb successfully.
> While deploying a simple @clustered ejb on EAP 6.3 server below exception was thrown. This issue is easily replicated.
> {code:java}
> 19:12:11,886 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named CounterBean in deployment unit deployment "Clusterejb-0.0.1.jar" are as follows:
> java:global/Clusterejb-0.0.1/CounterBean!com.test.Counter
> java:app/Clusterejb-0.0.1/CounterBean!com.test.Counter
> java:module/CounterBean!com.test.Counter
> java:jboss/exported/Clusterejb-0.0.1/CounterBean!com.test.Counter
> java:global/Clusterejb-0.0.1/CounterBean
> java:app/Clusterejb-0.0.1/CounterBean
> java:module/CounterBean
> 19:12:12,089 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "Clusterejb-0.0.1.jar" (runtime-name : "Clusterejb-0.0.1.jar")
> 19:12:12,090 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.ejb.cache.cluster.simple (missing) dependents: [service jboss.ejb.cache.cluster]
> 19:12:12,093 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 2654ms - Started 185 of 293 services (14 services failed or missing dependencies, 117 services are lazy, passive or on-demand)
> {code}
> I have attached the configuration files for both EAP 7 and EAP 6.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2951:
---------------------------------------
Adding a logstash formatter would likely only be for convenience. Really it's just a {{json-formatter}} with the {{timestamp}} key replaced with {{@timestamp}} and a {{@version : 1}} key/value pair added to the output. This would be very easy to do with the {{json-formatter}} itself. In fact dropping the {{org.jboss.logmanager.formatters.LogstashFormatter}} is being considered.
> Add JSON formatter resources to the logging subsystem
> -----------------------------------------------------
>
> Key: WFCORE-2951
> URL: https://issues.jboss.org/browse/WFCORE-2951
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 4.0.0.Beta1
>
>
> The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-2951:
----------------------------------
Description: The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-. (was: The logging subsystem should include resources for a {{json-formatter}} and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires.)
> Add JSON formatter resources to the logging subsystem
> -----------------------------------------------------
>
> Key: WFCORE-2951
> URL: https://issues.jboss.org/browse/WFCORE-2951
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 4.0.0.Beta1
>
>
> The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-2951:
----------------------------------
Summary: Add JSON formatter resources to the logging subsystem (was: Add JSON and Logstash formatter resources to the logging subsystem)
> Add JSON formatter resources to the logging subsystem
> -----------------------------------------------------
>
> Key: WFCORE-2951
> URL: https://issues.jboss.org/browse/WFCORE-2951
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 4.0.0.Beta1
>
>
> The logging subsystem should include resources for a {{json-formatter}} and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month