[JBoss JIRA] (LOGMGR-179) The configuration API should fail if a configuration being removed is attached to another configuration
by James Perkins (JIRA)
James Perkins created LOGMGR-179:
------------------------------------
Summary: The configuration API should fail if a configuration being removed is attached to another configuration
Key: LOGMGR-179
URL: https://issues.jboss.org/browse/LOGMGR-179
Project: JBoss Log Manager
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The configuration API will allow the removal of a configuration resource even if that resource is attached to a different configuration. For example you can remove a {{FormatterConfiguration}} even if that formatter is attached to a {{HandlerConfiguration}}. This should be validated and fail if prepared or committed via the {{LogContextConfiguration}} API.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9405) NPE when trying to remove an EJB subsystem channel-creation-options resource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9405?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9405:
-----------------------------------
Summary: NPE when trying to remove an EJB subsystem channel-creation-options resource (was: NPE when trying to recursively remove the EJB subsystem)
> NPE when trying to remove an EJB subsystem channel-creation-options resource
> ----------------------------------------------------------------------------
>
> 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, 7 months
[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 commented on WFLY-9405:
----------------------------------------
The description does a recursive removal of the entire ejb3 subsystem to cause this, but that's not necessary. A targeted op would do it too:
{code}
[standalone@embedded /] /subsystem=ejb3/service=remote/channel-creation-options=MAX_OUTBOUND_MESSAGES:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
For this to fail the server can't be running in --admin-only (hence the workaround I posted.)
> 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, 7 months
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3336:
----------------------------------
Steps to Reproduce:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
*Note:* The following reproducer only works on WildFly Full, but the issue itself is likely in WIldFly Core.
To reproduce with the attached {{logging-profile.zip}} do the follow:
# Build the project and deploy the EAR.
## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}}
# In a browser go to http://localhost:8080/test-war-one/rest/log
# Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages
# Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's
was:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
To reproduce with the attached {{logging-profile.zip}} do the follow:
# Build the project and deploy the EAR.
## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}}
# In a browser go to http://localhost:8080/test-war-one/rest/log
# Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages
# Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz, logging-profile.zip
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3336:
----------------------------------
Steps to Reproduce:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
To reproduce with the attached {{logging-profile.zip}} do the follow:
# Build the project and deploy the EAR.
## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}}
# In a browser go to http://localhost:8080/test-war-one/rest/log
# Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages
# Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's
was:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz, logging-profile.zip
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3336:
----------------------------------
Attachment: logging-profile.zip
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz, logging-profile.zip
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3336:
---------------------------------------
Since the library doing the logging is a shared in the EAR it looks like when first invoked it's seeing the log context from the first WAR in the EAR that uses it. This should see whichever log context belongs to the EAR not either of the WAR's. What this means is that any libraries in the EAR's {{lib}} directory should be using the EAR's log context. In the case of the attached example the shared library should be using the system log context since the EAR does not have a logging profile associated with it.
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-13387 to WFCORE-3336:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3336 (was: JBEAP-13387)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Logging
(was: Logging)
Affects Version/s: (was: 7.0.5.GA)
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ELY-1384) Fix the DER encoding of the subject key identifier extension
by Farah Juma (JIRA)
Farah Juma created ELY-1384:
-------------------------------
Summary: Fix the DER encoding of the subject key identifier extension
Key: ELY-1384
URL: https://issues.jboss.org/browse/ELY-1384
Project: WildFly Elytron
Issue Type: Bug
Components: X.500
Reporter: Farah Juma
Assignee: Farah Juma
It should be defined as follows as per [RFC 5280 Section 4.2.1.2 |https://tools.ietf.org/html/rfc5280#section-4.2.1.2]:
{code}
SubjectKeyIdentifier ::= KeyIdentifier
KeyIdentifier ::= OCTET STRING
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months