[JBoss JIRA] (DROOLS-4162) Scenario Test: UX for background data
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-4162?page=com.atlassian.jira.plugi... ]
Tao Zhu commented on DROOLS-4162:
---------------------------------
[~danielezonca] Could you please share me a video demo about how the user "create 4 instances (one for each person) and specify the same values for each row", I want to know the user pain point clearly.
*The work progress I think is：*
1. Create the first person's instance.
2.Save this instance as background and list the background in right panel.
3.User could select the background to map it to the other person quickly.
What do you think about it?
> Scenario Test: UX for background data
> -------------------------------------
>
> Key: DROOLS-4162
> URL: https://issues.jboss.org/browse/DROOLS-4162
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: design1.png, design2.png, design3.png
>
>
> As user I want to be able to specify a set of data shared by all the scenarios inside a simulation. All the data will be not editable.
> Please refer to Cucumber background feature for details https://cucumber.io/docs/gherkin/reference/#background
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11864) Only one JSF Validator is invoked when defined via annotation @FacesValidator
by Chao Wang (Jira)
[ https://issues.jboss.org/browse/WFLY-11864?page=com.atlassian.jira.plugin... ]
Chao Wang commented on WFLY-11864:
----------------------------------
Both PR are merged, but it requires an upgrade in WFLY-11960
> Only one JSF Validator is invoked when defined via annotation @FacesValidator
> -----------------------------------------------------------------------------
>
> Key: WFLY-11864
> URL: https://issues.jboss.org/browse/WFLY-11864
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 16.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Labels: downstream_dependency
>
> Only one JSF Validator is invoked when defined via annotation @FacesValidator
> {code}
> @FacesValidator(value = "validator.CustomValidator1", managed = true)
> public class CustomValidator1 implements Validator<String> {
> ...
> }
> @FacesValidator(value = "validator.CustomValidator2", managed = true)
> public class CustomValidator2 implements Validator<String> {
> ...
> }
> {code}
> {code}
> <h:inputText id="input-value" value="#{customBean.inputValue}">
> <f:validator validatorId="validator.CustomValidator2" />
> <f:validator validatorId="validator.CustomValidator1" />
> </h:inputText>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-1225) Add options to specify the salience range of rules in a Decision Table Sheet
by Osamu Kuniyasu (Jira)
[ https://issues.jboss.org/browse/DROOLS-1225?page=com.atlassian.jira.plugi... ]
Osamu Kuniyasu commented on DROOLS-1225:
----------------------------------------
Unexpected DRL generation from a Decision Table Excel file was realized.
When we have multiple RuleTable(s) in one Excel Sheet (means one RuleSet),
Each RuleTable starts from salience={SequentialMaxPriority}.
With this, the order of rule firing is jumping between RuleTable(s) in same Excel Sheet.
Can we have rules' saliences counting down from the top to the bottom in same Excel Sheet even it has multiple RuleTable(s)?
> Add options to specify the salience range of rules in a Decision Table Sheet
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1225
> URL: https://issues.jboss.org/browse/DROOLS-1225
> Project: Drools
> Issue Type: Feature Request
> Components: decision tables
> Affects Versions: 6.4.0.Final
> Environment: any
> Reporter: Osamu Kuniyasu
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.0.0.Final
>
>
> When we set Sequential=true in RuleSet properties.
> The salience of the generated rules are started from 65518 and down one by one.
> When we mix several Decision Table Sheets and DRL rules in a Ruleflow-Group (Agenda-Group), We could not make these rules' salience order, because each Decision Table Sheet has fixed to start from 65518.
> A (limited) workaround is to have separated Ruleflow-Groups,
> But this way does not solve the situation to back to the higher priority rules as it's previous Ruleflow-Group.
> To solve The request is that add two options into RuleSet properties. like,
> SequentialMaxPriority 10000
> SequentialMinPriority 1000
> By this optional properties, we can control the range of the salience of rules in the Decision Table Sheet. and it is possible safely to mix multiple Decision Table Sheets in a Ruleflow-Group.
> The SequentialMaxPriority is used to set the start value of the salience instead of 65518.
> The SequentialMinPriority is used to check if this minimum salience value is not violated in the Decision Table Compiler. (if it's violated, compilation error occurs.)
> Best Regards,
> Osamu Kuniyasu
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-256?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-256:
---------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/263, https://github.com/jboss-logging/jboss-logmanager/pull/264, https://github.com/jboss-logging/jboss-logmanager/pull/265, https://github.com/jboss-logging/jboss-logmanager/pull/266, https://github.com/jboss-logging/jboss-logmanager/pull/267 (was: https://github.com/jboss-logging/jboss-logmanager/pull/264, https://github.com/jboss-logging/jboss-logmanager/pull/265, https://github.com/jboss-logging/jboss-logmanager/pull/266, https://github.com/jboss-logging/jboss-logmanager/pull/267)
> Failure to rotate logfile on Windows system because of already open file lock
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-256
> URL: https://issues.jboss.org/browse/LOGMGR-256
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.13.Final
> Reporter: Patrick Colbaut
> Assignee: James Perkins
> Priority: Major
> Fix For: 1.5.10.Final, 2.0.12.Final, 2.1.14.Final, 2.2.0.Final, 3.0.0.Final
>
>
> I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
> Of note: The server.log file is configured to be rotated on boot.
> {code:java}
> LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
> java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
> at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> at java.nio.file.Files.move(Files.java:1395)
> at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
> at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> 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.boot(ModelControllerImpl.java:521)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
> at org.jboss.as.server.ServerService.boot(ServerService.java:435)
> at org.jboss.as.server.ServerService.boot(ServerService.java:394)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.lang.Thread.run(Thread.java:748){code}
> A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
> Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
> This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
> To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
> As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
> {code:java}
> public void setFile(final File file) throws FileNotFoundException {
> synchronized (outputLock) {
> // Check for a rotate
> if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
> setFileInternal(null);
> suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
> }
> setFileInternal(file);
> }
> }
> {code}
> Manually adding the above mentioned call seems to allow everything to work as intended.
> And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-256?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-256:
---------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/264, https://github.com/jboss-logging/jboss-logmanager/pull/265, https://github.com/jboss-logging/jboss-logmanager/pull/266, https://github.com/jboss-logging/jboss-logmanager/pull/267
> Failure to rotate logfile on Windows system because of already open file lock
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-256
> URL: https://issues.jboss.org/browse/LOGMGR-256
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.13.Final
> Reporter: Patrick Colbaut
> Assignee: James Perkins
> Priority: Major
> Fix For: 1.5.10.Final, 2.0.12.Final, 2.1.14.Final, 2.2.0.Final, 3.0.0.Final
>
>
> I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
> Of note: The server.log file is configured to be rotated on boot.
> {code:java}
> LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
> java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
> at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> at java.nio.file.Files.move(Files.java:1395)
> at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
> at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> 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.boot(ModelControllerImpl.java:521)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
> at org.jboss.as.server.ServerService.boot(ServerService.java:435)
> at org.jboss.as.server.ServerService.boot(ServerService.java:394)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.lang.Thread.run(Thread.java:748){code}
> A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
> Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
> This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
> To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
> As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
> {code:java}
> public void setFile(final File file) throws FileNotFoundException {
> synchronized (outputLock) {
> // Check for a rotate
> if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
> setFileInternal(null);
> suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
> }
> setFileInternal(file);
> }
> }
> {code}
> Manually adding the above mentioned call seems to allow everything to work as intended.
> And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (LOGMGR-256) Failure to rotate logfile on Windows system because of already open file lock
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-256?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-256:
---------------------------------
Fix Version/s: 1.5.10.Final
2.0.12.Final
2.1.14.Final
2.2.0.Final
3.0.0.Final
> Failure to rotate logfile on Windows system because of already open file lock
> -----------------------------------------------------------------------------
>
> Key: LOGMGR-256
> URL: https://issues.jboss.org/browse/LOGMGR-256
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.13.Final
> Reporter: Patrick Colbaut
> Assignee: James Perkins
> Priority: Major
> Fix For: 1.5.10.Final, 2.0.12.Final, 2.1.14.Final, 2.2.0.Final, 3.0.0.Final
>
>
> I've run into a similar error to the one described in LOGMGR-154, using the jboss-logmanager 2.1.13.Final release on a system that's still running Windows 7.
> Of note: The server.log file is configured to be rotated on boot.
> {code:java}
> LogManager error of type GENERIC_FAILURE: Failed to move file C:\wildfly\standalone\log\server.log to C:\wildfly\standalone\log\server.log.1.
> java.nio.file.FileSystemException: C:\wildfly\standalone\log\server.log -> C:\wildfly\standalone\log\server.log.1: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
> at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
> at java.nio.file.Files.move(Files.java:1395)
> at org.jboss.logmanager.handlers.SuffixRotator.move(SuffixRotator.java:246)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:174)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:233)
> at org.jboss.logmanager.handlers.SuffixRotator.rotate(SuffixRotator.java:193)
> at org.jboss.logmanager.handlers.SizeRotatingFileHandler.setFile(SizeRotatingFileHandler.java:142)
> at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:189)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:299)
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:106)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> 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.boot(ModelControllerImpl.java:521)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
> at org.jboss.as.server.ServerService.boot(ServerService.java:435)
> at org.jboss.as.server.ServerService.boot(ServerService.java:394)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.lang.Thread.run(Thread.java:748){code}
> A similar error will also occur if a compression suffix is used, although it will be the Files.delete(File) instead the Files.move(File, File) call which will fail.
> Debugging shows that SizeRotatingFileHandler.setFileName(String) is called once immediately during server boot (initialization via logging.properties) and again a short time after (via the logging subsystem I'm guessing).
> This second call results in the error above, because the SizeRotatingFileHandler instance already holds a file lock via its outputStream field, but a rotation is still attempted, as the file should rotate on boot and already contains content at that point in time.
> To confirm whether this process internal file lock is responsible, I additionally checked for other processes that might own such a handle. The only listed one is the Java process running Wildfly.
> As far as I can tell, this kind of error case should be easily fixed by adding an additional setFileInternal(null) call to clean up the open lock before actually triggering the rotation, as seen in this snippet:
> {code:java}
> public void setFile(final File file) throws FileNotFoundException {
> synchronized (outputLock) {
> // Check for a rotate
> if (rotateOnBoot && maxBackupIndex > 0 && file != null && file.exists() && file.length() > 0L) {
> setFileInternal(null);
> suffixRotator.rotate(getErrorManager(), file.toPath(), maxBackupIndex);
> }
> setFileInternal(file);
> }
> }
> {code}
> Manually adding the above mentioned call seems to allow everything to work as intended.
> And while the fact that the second setting of the same file name triggers an additional log file rotation (as rotateOnBoot = true in the used configuration) slightly annoys me, that's probably a problem for a different followup bug.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months