[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Tao Zhu commented on DROOLS-4161:
---------------------------------
Thanks [~kkufova]
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFWIP-163) WildFlyServerStatus is not present in operator description
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-163?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-163:
--------------------------------------
Verifying the fix.
> WildFlyServerStatus is not present in operator description
> -----------------------------------------------------------
>
> Key: WFWIP-163
> URL: https://issues.jboss.org/browse/WFWIP-163
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: *openshift:* {{v3.11.82}}
> *operator image:* {{quay.io/wildfly/wildfly-operator:0.2.0}}
> *runtime image:* {{quay.io/wildfly/wildfly-centos7:17.0}}
> *application image:* {{pkremens/simple-jaxrs-wildfly}}
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: wildfly-operator.txt
>
>
> According to the [operator api documentation|https://github.com/wildfly/wildfly-operator/blob/master/doc...], the deployment pods status should be pard of operator description, but I failed to find such on OCP.
> Install the wildfly operator on OCP as described by [wildfly-operator - openshift|https://github.com/wildfly/wildfly-operator#openshift] section.
> *steps to reproduce*
> {noformat}
> $ cat << EOF > simple-jaxrs-wildfly.yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: simple-jaxrs-wildfly
> spec:
> applicationImage: "pkremens/simple-jaxrs-wildfly"
> size: 2
> EOF
> $ oc apply -f simple-jaxrs-wildfly.yaml
> $ oc expose service/simple-jaxrs-wildfly-loadbalancer
> # verify that application is accessible
> $ ROUTE=$(oc get route.route.openshift.io/simple-jaxrs-wildfly-loadbalancer --template='{{ .spec.host }}')
> $ curl $ROUTE/ping
> pong
> $ oc describe wildflyserver simple-jaxrs-wildfly
> Name: simple-jaxrs-wildfly
> Namespace: myproject
> Labels: <none>
> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"wildfly.org/v1alpha1","kind":"WildFlyServer","metadata":{"annotations":{},"name":"simple-jaxrs-wildfly","namespace":"myproject"},"spec":...
> API Version: wildfly.org/v1alpha1
> Kind: WildFlyServer
> Metadata:
> Creation Timestamp: 2019-07-02T13:11:58Z
> Generation: 1
> Resource Version: 4318
> Self Link: /apis/wildfly.org/v1alpha1/namespaces/myproject/wildflyservers/simple-jaxrs-wildfly
> UID: f8eb76bf-9cca-11e9-b8ee-52540043aed8
> Spec:
> Application Image: pkremens/simple-jaxrs-wildfly
> Size: 2
> Events: <none>
> {noformat}
> Operator status is not part of the object.
> For wildfly operator pod logs see [^wildfly-operator.txt] attachment.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4474) Missing path validation of a log file while update path
by Marek Kopecky (Jira)
[ https://issues.jboss.org/browse/WFCORE-4474?page=com.atlassian.jira.plugi... ]
Marek Kopecky commented on WFCORE-4474:
---------------------------------------
Ah, thank you. But back to the description of this jira. We have fresh server on Windows and we call three management commands:
{noformat}
[standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <:> at index 69: C:\\Users\\Administrator\\playground\\CD16\\jboss-eap-7.3\\st
andalone\\log\\C:/server.log",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\\server.log})
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
{"outcome" => "success"}
{noformat}
First command fails. Third command (same as first command) is successful.
> Missing path validation of a log file while update path
> --------------------------------------------------------
>
> Key: WFCORE-4474
> URL: https://issues.jboss.org/browse/WFCORE-4474
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 9.0.0.Beta4
> Reporter: Vratislav Marek
> Assignee: James Perkins
> Priority: Major
>
> After the first successful set of a valid path, you can set an invalid path.
> It is can be relative to that while "relative-to" parameter is overridden, the validator doesn't validate it.
> Discovered on Windows.
> A code block is divided, but it is holding sequence to reproduce.
> _This works as expected._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <
> :> at index 61: D:\\Tests\\clear\\wildfly-17.0.0.Beta1-SNAPSHOT\\standalone\\log\\C:/server.log",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\server.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <
> :> at index 61: D:\\Tests\\clear\\wildfly-17.0.0.Beta1-SNAPSHOT\\standalone\\log\\C:server.log",
> "rolled-back" => true
> }
> {code}
> _Still works as expected. But After this successful write-attribute command, it that changing._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\\server.log})
> {"outcome" => "success"}
> {code}
> *Now there is a problem, it that not works as expected. The validator accepts invalid path.*
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:server.log})
> {"outcome" => "success"}
> {code}
> _But not accept all invalid paths._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:*server.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <
> *> at index 2: C:*server.log",
> "rolled-back" => true
> }
> {code}
> _Verification if the unsuccessful update changes something. But not._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\\server.log})
> {"outcome" => "success"}
> {code}
> _Verification if is really set in the property value. Yes_
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:\\server.log"}
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:server.log"}
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:/server.log"}
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:server.log"}
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4301) drools example lack of explaination
by Shiming Liu (Jira)
Shiming Liu created DROOLS-4301:
-----------------------------------
Summary: drools example lack of explaination
Key: DROOLS-4301
URL: https://issues.jboss.org/browse/DROOLS-4301
Project: Drools
Issue Type: Enhancement
Components: docs
Affects Versions: 7.23.0.Final
Reporter: Shiming Liu
Assignee: Mario Fusco
hi, I am new to drools, we want to use it in our project, but I find there are not many examples to study, the official repo in github have some, it's great, but the problem is the drools example are lack of instructions, I don't know the meaning of them, so I can master them, please add more case introductions, thank you!
https://github.com/kiegroup/drools/tree/master/drools-examples/src/main/j...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12274) EJB Bean with mappedName is not binding
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFLY-12274?page=com.atlassian.jira.plugin... ]
Jaikiran Pai commented on WFLY-12274:
-------------------------------------
More of a FYI - Back when we started redesiging AS7 and the EJB3.x spec support for it, we had decided to _not_ support "mappedName" on these component declaring annotation (like the @Stateless annotation in this example). The javadoc of this attribute states that this value can be anything and not necessarily a JNDI name and may not be supported by application server vendors[1]. I don't have a reference to the discussion where we had decided this (it mostly was a IRC or such discussion from what I remember).
[1] https://docs.oracle.com/javaee/6/api/javax/ejb/Stateless.html#mappedName()
> EJB Bean with mappedName is not binding
> ---------------------------------------
>
> Key: WFLY-12274
> URL: https://issues.jboss.org/browse/WFLY-12274
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 16.0.0.Final, 17.0.0.Beta1, 17.0.1.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: mapped-name.jar
>
>
> EJB Bean with mappedName is not binding , the mappedName is vendor specific, it is not portable, however @EJB(mappedName=...) is expecting a global JNDI path, but @Stateless(mappedName=...) does not appear to be binding anything.
> {code}
> @Stateless(name="HelloBean", mappedName="MappedHelloBean")
> public class HelloBean implements Hello {
> ...
> {code}
> {code}
> @Startup
> @Singleton
> public class TestSingleton {
> @EJB(mappedName="MappedHelloBean")
> private Hello ejb;
> ...
> {code}
> So the @EJB causes the TestSingleton to fail.
> {code}
> 22:12:55,637 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 72) MSC000001: Failed to start service jboss.deployment.unit."mapped-name.jar".component.TestSingleton.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mapped-name.jar".component.TestSingleton.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> ...
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.jboss.examples.ejb.TestSingleton/ejb
> ...
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.jboss.examples.ejb.TestSingleton/ejb
> ...
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.jboss.examples.ejb.TestSingleton/ejb [Root exception is java.lang.RuntimeException: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean]
> ...
> Caused by: java.lang.RuntimeException: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean
> ...
> Caused by: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean
> ...
> {code}
> [1] https://docs.oracle.com/javaee/6/api/javax/ejb/EJB.html#mappedName()
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JBLOGGING-140) Avoid ClassCastException in Slf4jLoggerProvider
by Philippe Marschall (Jira)
[ https://issues.jboss.org/browse/JBLOGGING-140?page=com.atlassian.jira.plu... ]
Philippe Marschall updated JBLOGGING-140:
-----------------------------------------
Description:
We use jboss-logging with a custom SLF4J implementation that does not implement {{LocationAwareLogger}}. We have exception tracing on and see a {{ClassCastException}} in {{org.jboss.logging.Slf4jLoggerProvider#getLogger(String)}} for every logger we look up.
We did some preliminary microbenchmarks and can see no differences between unconditionally casting and catching {{Throwable}} vs an {{instanceof}}, both in cases where the check succeeds and where is fails. Having said the class hierarchies we tested are slightly different from actual SLF4J class hierarchies.
was:
We use jboss-logging with a custom SLF4J implementation that does not implement {{LocationAwareLogger}}. We have exception tracing on and see a {{ClassCastException}} in {{org.jboss.logging.Slf4jLoggerProvider#getLogger(String)}} for every logger we look up.
We did some preliminary microbenchmarks and can see no differences between unconditionally casting and catching {{Throwable}} vs an {{instanceof}}, both in cases where the check success. Having said the class hierarchies we tested are slightly different from actual SLF4J class hierarchies.
> Avoid ClassCastException in Slf4jLoggerProvider
> -----------------------------------------------
>
> Key: JBLOGGING-140
> URL: https://issues.jboss.org/browse/JBLOGGING-140
> Project: JBoss Logging
> Issue Type: Enhancement
> Reporter: Philippe Marschall
> Assignee: James Perkins
> Priority: Major
> Fix For: 3.4.1.Final
>
>
> We use jboss-logging with a custom SLF4J implementation that does not implement {{LocationAwareLogger}}. We have exception tracing on and see a {{ClassCastException}} in {{org.jboss.logging.Slf4jLoggerProvider#getLogger(String)}} for every logger we look up.
> We did some preliminary microbenchmarks and can see no differences between unconditionally casting and catching {{Throwable}} vs an {{instanceof}}, both in cases where the check succeeds and where is fails. Having said the class hierarchies we tested are slightly different from actual SLF4J class hierarchies.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4162) Scenario Test: UX for background data
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-4162?page=com.atlassian.jira.plugi... ]
Klara Kufova edited comment on DROOLS-4162 at 7/9/19 3:04 AM:
--------------------------------------------------------------
[~danielezonca], [~zhutaojiajia]
I think we should only allow to specify one background for the whole test scenario table (exactly for situations similar to the one depicted in Daniele's screenshot).
What I had in mind originally was something like this: above the test scenario table, there could be a button called *set background* (or similar). After clicking the button, a new test scenario table would appear above the original one. Here, you could set the background exactly the same way how the user works with the original table (_i.e._ using the right panel). There could be other buttons as well, such as *hide background*, *remove background* _etc._ However, I'm not sure if we're able to have more than one table in the canvas.
Alternatively, there could be a new tab called *Background* (Model, Background, Overview, Data Objects). After selecting the tab, the same page as the original one would appear, where it would be possible to set the background. There could also be some sort of a "feedback" in the original page (something like "a background is set").
Let me know if this is useful. You can also propose something completely different if you have better ideas how this could work!
was (Author: kkufova):
[~danielezonca], [~zhutaojiajia]
I think we should only allow to specify one background for the whole test scenario table (exactly for situations similar to the one depicted in Daniele's screenshot).
What I had in mind originally was something like this: above the test scenario table, there could be a button called *set background* (or similar). After clicking the button, a new test scenario table would appear above the original one. Here, you could set the background exactly the same way how the user works with the original table (_i.e._ using the right panel). There could be other buttons as well, such as *remove background* _etc._ However, I'm not sure if we're able to have more than one table in the canvas.
Alternatively, there could be a new tab called *Background* (Model, Background, Overview, Data Objects). After selecting the tab, the same page as the original one would appear, where it would be possible to set the background. There could also be some sort of a "feedback" in the original page (something like "a background is set").
Let me know if this is useful. You can also propose something completely different if you have better ideas how this could work!
> 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: Screenshot from 2019-07-08 14-12-18.png, 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