[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
[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
[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
[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
[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
[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
[JBoss JIRA] (WFCORE-4139) Unclean disconnect of stopping slave HC from the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4139?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4139:
------------------------------------------
I understand now. The ProcessController has no shutdown hook, so calling Process.destroy on it is going to succeed very quickly. The HC process then detects the close of stdin and shuts down. So that is async to stopping the PC.
So maybe this is an Enhancement to make that better, or maybe just a Won't Fix because the chance of doing harm with a fix outweighs any benefit.
> Unclean disconnect of stopping slave HC from the domain
> -------------------------------------------------------
>
> Key: WFCORE-4139
> URL: https://issues.jboss.org/browse/WFCORE-4139
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
> Labels: domain-mode
>
> An interesting problem popped up when executing a new test I wrote.[1]
> The test invoked DomainLifecycleUtil.stop() to stop the slave HC. After it returned, it invoked an op on the master, one that would result in domain wide rollout. That failed with a failure indicating a problem sending the op to the slave.
> But the slave should have been disconnected from the master before DomainLifecycleUtil.stop() returned. It does a process.stop() on the PC, which should cleanly stop the PC, which cleanly stops the HC, which should cleanly disconnect from the master as part of stopping. But somehow that didn't all happen.
> [1] These specific details will soon be out of date; i.e. I'll change the test to work around this and eventually the test job will come out of TeamCity history. But anyway here they are:
> https://ci.wildfly.org/viewLog.html?buildId=123039&tab=buildResultsDiv&bu...
> {code}
> java.lang.AssertionError: {"host-failure-descriptions" => {"slave" => "Writes closed"}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:229)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:221)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.addRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:189)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.testSlaveBootWithMissingRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:167)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (WFCORE-4139) Unclean disconnect of stopping slave HC from the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4139?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4139:
-------------------------------------
Priority: Minor (was: Major)
> Unclean disconnect of stopping slave HC from the domain
> -------------------------------------------------------
>
> Key: WFCORE-4139
> URL: https://issues.jboss.org/browse/WFCORE-4139
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
> Labels: domain-mode
>
> An interesting problem popped up when executing a new test I wrote.[1]
> The test invoked DomainLifecycleUtil.stop() to stop the slave HC. After it returned, it invoked an op on the master, one that would result in domain wide rollout. That failed with a failure indicating a problem sending the op to the slave.
> But the slave should have been disconnected from the master before DomainLifecycleUtil.stop() returned. It does a process.stop() on the PC, which should cleanly stop the PC, which cleanly stops the HC, which should cleanly disconnect from the master as part of stopping. But somehow that didn't all happen.
> [1] These specific details will soon be out of date; i.e. I'll change the test to work around this and eventually the test job will come out of TeamCity history. But anyway here they are:
> https://ci.wildfly.org/viewLog.html?buildId=123039&tab=buildResultsDiv&bu...
> {code}
> java.lang.AssertionError: {"host-failure-descriptions" => {"slave" => "Writes closed"}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:229)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:221)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.addRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:189)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.testSlaveBootWithMissingRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:167)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years