[JBoss JIRA] (DROOLS-5229) DMNValidate mojo fails XMLSchema validation with included models
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5229?page=com.atlassian.jira.plug... ]
Mario Fusco reassigned DROOLS-5229:
-----------------------------------
Assignee: Matteo Mortari (was: Mario Fusco)
> DMNValidate mojo fails XMLSchema validation with included models
> ----------------------------------------------------------------
>
> Key: DROOLS-5229
> URL: https://issues.redhat.com/browse/DROOLS-5229
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.34.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: ValidateDMN Mojo Failure.png, xml_validation_error.zip
>
>
> The attached DMN decision project was built using Business Central 7.34.0.Final. In this project, the dmn model `Math Functions.dmn` invokes business knowledge model `Quotient` from dmn model `Divide.dmn`. Invoking the ValidateDMN mojo (enabled by default) from the kie-maven-plugin fails XML Validation. One can get past this error by disabling DMNValidation with the following configuration in the pom (though disabling DMNValidation for an XML Schema validation also prevents finding FEEL parser errors):
> ```
> <build>
> <plugins>
> <plugin>
> <groupId>org.kie</groupId>
> <artifactId>kie-maven-plugin</artifactId>
> <version>7.34.0.Final</version>
> <extensions>true</extensions>
> <!-- Can get past xml validation error by disabling the ValidateDMN Mojo -->
> <configuration>
> <validateDMN>disabled</validateDMN>
> </configuration>
> </plugin>
> </plugins>
> </build>
> ```
> When one combines the two dmn models into a single model, the XML Validation succeeds (this example is not supplied, but is trivial to re-build).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-1415?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFLY-1415 at 4/8/20 1:29 PM:
----------------------------------------------------------------
[~lvydra]. I think this is still valid. I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask.
I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs:
1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads. I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFCORE?selectedItem=com.atlassian.jira...), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA.
2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general. Full WildFly component leads are at (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.j...)
3) The kernel parsers in WF Core. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces. Any work would be tracked via a WFCORE.
4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc.
This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done.
was (Author: brian.stansberry):
[~lvydra]. I think this is still valid. I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask.
I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs:
1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads. I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.j...), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA.
2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general.
3) The kernel parsers. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces.
4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc.
This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done.
> Move away from expensive enum switch
> ------------------------------------
>
> Key: WFLY-1415
> URL: https://issues.redhat.com/browse/WFLY-1415
> Project: WildFly
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Labels: janitor
>
> We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-1415?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-1415:
----------------------------------------
[~lvydra]. I think this is still valid. I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask.
I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs:
1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads. I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.j...), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA.
2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general.
3) The kernel parsers. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces.
4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc.
This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done.
> Move away from expensive enum switch
> ------------------------------------
>
> Key: WFLY-1415
> URL: https://issues.redhat.com/browse/WFLY-1415
> Project: WildFly
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Labels: janitor
>
> We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-5229) DMNValidate mojo fails XMLSchema validation with included models
by Tracy Hires (Jira)
Tracy Hires created DROOLS-5229:
-----------------------------------
Summary: DMNValidate mojo fails XMLSchema validation with included models
Key: DROOLS-5229
URL: https://issues.redhat.com/browse/DROOLS-5229
Project: Drools
Issue Type: Bug
Affects Versions: 7.34.0.Final
Reporter: Tracy Hires
Assignee: Mario Fusco
Attachments: ValidateDMN Mojo Failure.png, xml_validation_error.zip
The attached DMN decision project was built using Business Central 7.34.0.Final. In this project, the dmn model `Math Functions.dmn` invokes business knowledge model `Quotient` from dmn model `Divide.dmn`. Invoking the ValidateDMN mojo (enabled by default) from the kie-maven-plugin fails XML Validation. One can get past this error by disabling DMNValidation with the following configuration in the pom (though disabling DMNValidation for an XML Schema validation also prevents finding FEEL parser errors):
```
<build>
<plugins>
<plugin>
<groupId>org.kie</groupId>
<artifactId>kie-maven-plugin</artifactId>
<version>7.34.0.Final</version>
<extensions>true</extensions>
<!-- Can get past xml validation error by disabling the ValidateDMN Mojo -->
<configuration>
<validateDMN>disabled</validateDMN>
</configuration>
</plugin>
</plugins>
</build>
```
When one combines the two dmn models into a single model, the XML Validation succeeds (this example is not supplied, but is trivial to re-build).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-4910) Log WARN if JBoss Logging Handler gets removed
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4910?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-4910:
----------------------------------
Issue Type: Enhancement (was: Bug)
> Log WARN if JBoss Logging Handler gets removed
> -----------------------------------------------
>
> Key: WFCORE-4910
> URL: https://issues.redhat.com/browse/WFCORE-4910
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Reporter: Bartosz Baranowski
> Assignee: James Perkins
> Priority: Major
>
> Spring Boot when add-logging-api-dependencies=false and jul-to-slf4j.jar is packaged in the app, that it will remove all handlers from the root logger, which includes JBoss Logging's Handler resulting in logging to stop.
> {code}
> 20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.slf4j.bridge.SLF4JBridgeHandler.removeHandlersForRootLogger(SLF4JBridgeHandler.java:-1)
> 20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.removeJdkLoggingBridgeHandler(Slf4JLoggingSystem.java:78)
> 20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.configureJdkLoggingBridgeHandler(Slf4JLoggingSystem.java:61)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.beforeInitialize(Slf4JLoggingSystem.java:41)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.beforeInitialize(Log4J2LoggingSystem.java:136)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.LoggingApplicationListener.onApplicationStartingEvent(LoggingApplicationListener.java:231)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:210)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:122)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.context.event.EventPublishingRunListener.starting(EventPublishingRunListener.java:69)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.SpringApplicationRunListeners.starting(SpringApplicationRunListeners.java:48)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.SpringApplication.run(SpringApplication.java:292)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.run(SpringBootServletInitializer.java:156)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.createRootApplicationContext(SpringBootServletInitializer.java:136)
> 20:37:01,191 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.onStartup(SpringBootServletInitializer.java:91)
> 20:37:01,191 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:169)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-4910) Log WARN if JBoss Logging Handler gets removed
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4910?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-4910:
----------------------------------
Description:
Spring Boot when add-logging-api-dependencies=false and jul-to-slf4j.jar is packaged in the app, that it will remove all handlers from the root logger, which includes JBoss Logging's Handler resulting in logging to stop.
{code}
20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.slf4j.bridge.SLF4JBridgeHandler.removeHandlersForRootLogger(SLF4JBridgeHandler.java:-1)
20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.removeJdkLoggingBridgeHandler(Slf4JLoggingSystem.java:78)
20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.configureJdkLoggingBridgeHandler(Slf4JLoggingSystem.java:61)
20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.beforeInitialize(Slf4JLoggingSystem.java:41)
20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.beforeInitialize(Log4J2LoggingSystem.java:136)
20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.LoggingApplicationListener.onApplicationStartingEvent(LoggingApplicationListener.java:231)
20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:210)
20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:122)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.context.event.EventPublishingRunListener.starting(EventPublishingRunListener.java:69)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.SpringApplicationRunListeners.starting(SpringApplicationRunListeners.java:48)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.SpringApplication.run(SpringApplication.java:292)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.run(SpringBootServletInitializer.java:156)
20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.createRootApplicationContext(SpringBootServletInitializer.java:136)
20:37:01,191 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.onStartup(SpringBootServletInitializer.java:91)
20:37:01,191 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:169)
{code}
> Log WARN if JBoss Logging Handler gets removed
> -----------------------------------------------
>
> Key: WFCORE-4910
> URL: https://issues.redhat.com/browse/WFCORE-4910
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Bartosz Baranowski
> Assignee: James Perkins
> Priority: Major
>
> Spring Boot when add-logging-api-dependencies=false and jul-to-slf4j.jar is packaged in the app, that it will remove all handlers from the root logger, which includes JBoss Logging's Handler resulting in logging to stop.
> {code}
> 20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.slf4j.bridge.SLF4JBridgeHandler.removeHandlersForRootLogger(SLF4JBridgeHandler.java:-1)
> 20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.removeJdkLoggingBridgeHandler(Slf4JLoggingSystem.java:78)
> 20:37:01,188 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.configureJdkLoggingBridgeHandler(Slf4JLoggingSystem.java:61)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.Slf4JLoggingSystem.beforeInitialize(Slf4JLoggingSystem.java:41)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.beforeInitialize(Log4J2LoggingSystem.java:136)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.LoggingApplicationListener.onApplicationStartingEvent(LoggingApplicationListener.java:231)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:210)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
> 20:37:01,189 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:122)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.context.event.EventPublishingRunListener.starting(EventPublishingRunListener.java:69)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.SpringApplicationRunListeners.starting(SpringApplicationRunListeners.java:48)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.SpringApplication.run(SpringApplication.java:292)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.run(SpringBootServletInitializer.java:156)
> 20:37:01,190 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.createRootApplicationContext(SpringBootServletInitializer.java:136)
> 20:37:01,191 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.boot.web.support.SpringBootServletInitializer.onStartup(SpringBootServletInitializer.java:91)
> 20:37:01,191 INFO [stdout] (ServerService Thread Pool -- 79) org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:169)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBJCA-1408) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown
by Ilia Vassilev (Jira)
Ilia Vassilev created JBJCA-1408:
------------------------------------
Summary: Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown
Key: JBJCA-1408
URL: https://issues.redhat.com/browse/JBJCA-1408
Project: IronJacamar
Issue Type: Bug
Reporter: Ilia Vassilev
Assignee: Flavia Rainone
By upgrading IJ to 1.4.21. Final https://issues.redhat.com/browse/WFLY-1324
There is a constant error in server shutdown
{code:xml}
12:12:44,713 ERROR [stderr] (ConnectionValidator) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException
12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:151)
12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1261)
12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:457)
12:12:44,715 ERROR [stderr] (ConnectionValidator) at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator$ConnectionValidatorRunner.run(ConnectionValidator.java:317)
12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-4908) The write-attribute operation does not work on a hosts JVM resource
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4908?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4908:
-------------------------------------
Component/s: CLI
[~jdenise] I put the CLI component on this as I think the odds are high that any problem is in the CLI. I'd be surprised if anything on the server side is manipulating the 'name' attribute of the operation ModelNode once it hits the server.
> The write-attribute operation does not work on a hosts JVM resource
> -------------------------------------------------------------------
>
> Key: WFCORE-4908
> URL: https://issues.redhat.com/browse/WFCORE-4908
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Management
> Reporter: James Perkins
> Assignee: Jeff Mesnil
> Priority: Major
> Labels: domain-mode
>
> Under a hosts server config, {{/host=master/server-config=server-one/}}, there is a {{jvm}} resource. On this resource the {{write-attribute}} operation does not work expected.
> {code}
> [domain@embedded /] /host=master/server-config=server-one/jvm=default:add
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@embedded /] /host=master/server-config=server-one/jvm=default:write-attribute(name=jvm-options["-Xlog:gc*:file=${jboss.domain.servers.dir}/server-two/log/gc.log"])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@embedded /] /host=master/server-config=server-one/jvm=default:read-resource
> {
> "outcome" => "success",
> "result" => {
> "agent-lib" => undefined,
> "agent-path" => undefined,
> "debug-enabled" => undefined,
> "debug-options" => undefined,
> "env-classpath-ignored" => undefined,
> "environment-variables" => undefined,
> "heap-size" => undefined,
> "java-agent" => undefined,
> "java-home" => undefined,
> "jvm-options" => undefined,
> "launch-command" => undefined,
> "max-heap-size" => undefined,
> "max-permgen-size" => undefined,
> "permgen-size" => undefined,
> "stack-size" => undefined,
> "type" => undefined
> }
> }
> {code}
> As you can see from the above command does not update the {{jvm-options}}. However if you use the {{add-jvm-option}} operation that does work. It seems the {{write-attribute}} operation should also work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Elizabeth Clayton (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Elizabeth Clayton commented on DROOLS-4746:
-------------------------------------------
[~karreiro][~danielezonca] [~tirelli] I posted a draft wireframe: https://marvelapp.com/7208d3a
This uses either the right click contextual menu, or the toolbar button, to access a right panel/dock when the user may add input values. I can look into additional methods as an iteration, just wanted to get your feedback on this first pass. Thanks!
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: decision-logic-2-2.png, decision-logic-3-2.png
>
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> *Acceptance criteria*
> Users are able to:
> * Execute a single node boxed expression by providing node inputs (within the DMN editor.)
> * Explore the DMN model and provide inputs necessary to run a scenario test.
> * Obtain results (Expected) within the DMN editor once the test is run.
> Notes:
> * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> * Out of scope: Saving or exporting the "quick test."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months