[JBoss JIRA] (WFCORE-4135) Add a new property to disable backups of configuration XML files. Also avoid writing to standalone_xml_history when --read-only-server-config=<config> is set.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4135?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4135:
------------------------------------------
The server successfully executing a management op and responding with reload-required, and then the user does the reload but the change doesn't end up in the runtime -- that would be a bug. If the server knows it won't be able to effect the change if reload is invoked, then it shouldn't report the initial op as a success.
This could be done by having the OperationContext reject calls to reloadRequired() and restartRequired(), instead marking itself as rollback only and throwing an OperationFailedRuntimeException. The OperationContext would need to know the process is configured this way though.
Thanks for the info about the use cases.
> Add a new property to disable backups of configuration XML files. Also avoid writing to standalone_xml_history when --read-only-server-config=<config> is set.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4135
> URL: https://issues.jboss.org/browse/WFCORE-4135
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Rafael Ruiz
>
> We need something like
> --disable-configuration-history
> to use when running in containers to avoid write to any directory ('standalone_xml_history').
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFLY-10912) CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-10912?page=com.atlassian.jira.plugin... ]
Masafumi Miura reassigned WFLY-10912:
-------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
> -----------------------------------------------------------------------------------
>
> Key: WFLY-10912
> URL: https://issues.jboss.org/browse/WFLY-10912
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 13.0.0.Final, 14.0.0.Beta2
> Reporter: Masafumi Miura
> Assignee: Paul Ferraro
>
> This issue is very similar to WFLY-10262/JBEAP-14641 but the condition causing the problem is a bit different.
> The issue happens when the client sends JSESSIONID Cookie in the request to the web application does NOT use HttpSession. JSESSIONID Set-Cookie response header should not be sent in this scenario, but WildFly/EAP 7 returns the response with JSESSIONID reusing the requested session id which does not exist in the session manager.
> The fix for WFLY-10262 / JBEAP-14641 added AttachmentKey SESSION_ID_SET to avoid invoking CodecSessionConfig#setSessionId() more than once. However, the fix does not help for this issue because CodecSessionConfig#setSessionId() is not invoked (= SESSION_ID_SET is null) before the problematic CodecSessionConfig#findSessionId() processing in this scenario.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (DROOLS-3000) Enhance data type restrictions UX (decision tables & DT dialog)
by Cristiano Nicolai (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ]
Cristiano Nicolai commented on DROOLS-3000:
-------------------------------------------
[~uxdlc] [~karreiro] there is a component on uberfire already, see: https://github.com/kiegroup/appformer/blob/master/uberfire-workbench/uber...
> Enhance data type restrictions UX (decision tables & DT dialog)
> ---------------------------------------------------------------
>
> Key: DROOLS-3000
> URL: https://issues.jboss.org/browse/DROOLS-3000
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, date-time.png, date.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFCORE-4140) Incorrect resource passed into ExtensionRegistry.remove by ExtensionAddHandler rollback handling
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-4140:
----------------------------------------
Summary: Incorrect resource passed into ExtensionRegistry.remove by ExtensionAddHandler rollback handling
Key: WFCORE-4140
URL: https://issues.jboss.org/browse/WFCORE-4140
Project: WildFly Core
Issue Type: Bug
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
ExtensionAddHandler rollback handling passes the extension resource to ExtensionRegistry.remove when the API wants the root resource. This results in this failure:
{code}
2018-09-27 17:21:19,300 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0190: Step handler org.jboss.as.controller.extension.ExtensionAddHandler@4bdb1e35 for operation add at address [("extension" => "org.jboss.as.test.extension")] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
at org.jboss.as.controller.extension.ExtensionRegistry.hasSubsystemsRegistered(ExtensionRegistry.java:372)
at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:342)
at org.jboss.as.controller.extension.ExtensionAddHandler$1.handleRollback(ExtensionAddHandler.java:97)
at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1561)
at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1533)
at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1515)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1472)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1455)
at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1319)
at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:876)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:756)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
{code}
Also, ExtensionResource should not return null from getChildren. Fixing that would eliminate the NPE but the rollback handling wouldn't work properly with the wrong object being passed in.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (LOGMGR-203) LogManager stops any logging output after changing "encoding" attribute to file-handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-203?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-203:
---------------------------------
Fix Version/s: 2.0.11.Final
> LogManager stops any logging output after changing "encoding" attribute to file-handler
> ---------------------------------------------------------------------------------------
>
> Key: LOGMGR-203
> URL: https://issues.jboss.org/browse/LOGMGR-203
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Reporter: Masafumi Miura
> Assignee: David Lloyd
> Fix For: 2.0.11.Final, 2.1.5.Final
>
>
> When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
> Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
> Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.io.IOException: Stream Closed
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:326)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
> at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
> at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-10339 at 9/27/18 6:24 PM:
--------------------------------------------------------------
[~jmesnil]
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}
I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.
AIUI, the complexity for provisioning is two-fold:
# The attribute that toggles whether a JGroups-supplied capability is required is not the same attribute that determines the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.
We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.
was (Author: pferraro):
[~jmesnil]
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}
I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.
AIUI, the complexity for provisioning is two-fold:
# The attribute that toggles whether a JGroups supplied capability is needed is not the same attribute that supplies the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.
We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: ehsavoie Hugonnet
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10339:
-------------------------------------
[~jmesnil]
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}
I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.
AIUI, the complexity for provisioning is two-fold:
# The attribute that toggles whether a JGroups supplied capability is needed is not the same attribute that supplies the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.
We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: ehsavoie Hugonnet
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFLY-11088) Deployment failure if existing HA deployment contains a common EJB class
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-11088:
-----------------------------------
Summary: Deployment failure if existing HA deployment contains a common EJB class
Key: WFLY-11088
URL: https://issues.jboss.org/browse/WFLY-11088
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 14.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, the command dispatcher ID uses the bean name. This needs to be qualified using the deployment name.
{noformat}Thrown in org.wildfly.clustering.server.dispatcher.MangedCommandDispatcherFactory.cre>ateCommandDispatcher(Object id, C context) line 98 "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".component.StatefullBean.START" => "java.lang.Ille galArgumentException: WFLYCLSV0017: A command dispatcher for StatefullBean already exists, but with a different command context slave1 | [Server:group1] Caused by: java.lang.IllegalArgumentException: WFLYCLSV0017: A command dispatcher for StatefullBean alrea dy exists, but with a different command context",
slave1 | [Server:group1] "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".component.StatefulBean2.START" => "java.lang.IllegalA rgumentException: WFLYCLSV0017: A command dispatcher for StatefulBean2 already exists, but with a different command context slave1 | [Server:group1] Caused by: java.lang.IllegalArgumentException: WFLYCLSV0017: A command dispatcher for StatefulBean2 already e xists, but with a different command context"
slave1 | [Server:group1] },
slave1 | [Server:group1] "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
slave1 | [Server:group1] "Services that were unable to start:" => [ slave1 | [Server:group1] "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".moduleDeploymentRuntimeInformationStart", slave1 | [Server:group1] "jboss.deployment.unit.\"app2.ear\".WeldEndInitService", slave1 | [Server:group1] "jboss.undertow.deployment.default-server.default-host./app2"
slave1 | [Server:group1] ], slave1 | [Server:group1] "Services that may be the cause:" => `
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months