April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3730) Add support to DMN constraints on inputs (report input validation errors)

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-3730?page=com.atlassian.jira.plugi... ] Klara Kufova updated DROOLS-3730: --------------------------------- Description: See this example https://github.com/kiegroup/drools/compare/master...tarilabs:tarilabs-201... and try with a value out of the domain ranga [0..100]. when a Decision or any evaluation which depends on such InputData is triggered, an error message like the following is reported ```Error while evaluating node 'my decision' for dependency 'my input': the dependency value '999' is not allowed by the declared type (DMNType{ http://www.trisotech.com/definitions/_7ab67159-21c7-4985-91fc-f0d0174898db : tNumber0100 })``` NOTE: Verify also running the tests from the command line. was: See this example https://github.com/kiegroup/drools/compare/master...tarilabs:tarilabs-201... and try with a value out of the domain ranga [0..100]. when a Decision or any evaluation which depends on such InputData is triggered, an error message like the following is reported ```Error while evaluating node 'my decision' for dependency 'my input': the dependency value '999' is not allowed by the declared type (DMNType{ http://www.trisotech.com/definitions/_7ab67159-21c7-4985-91fc-f0d0174898db : tNumber0100 })``` > Add support to DMN constraints on inputs (report input validation errors) > ------------------------------------------------------------------------- > > Key: DROOLS-3730 > URL: https://issues.jboss.org/browse/DROOLS-3730 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > > See this example https://github.com/kiegroup/drools/compare/master...tarilabs:tarilabs-201... > and try with a value out of the domain ranga [0..100]. > when a Decision or any evaluation which depends on such InputData is triggered, an error message like the following is reported > ```Error while evaluating node 'my decision' for dependency 'my input': the dependency value '999' is not allowed by the declared type (DMNType{ http://www.trisotech.com/definitions/_7ab67159-21c7-4985-91fc-f0d0174898db : tNumber0100 })``` > NOTE: Verify also running the tests from the command line. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3730) Add support to DMN constraints on inputs (report input validation errors)

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-3730?page=com.atlassian.jira.plugi... ] Klara Kufova edited comment on DROOLS-3730 at 4/25/19 5:14 AM: --------------------------------------------------------------- NOTE FOR FUTURE KLARA: This is saying that constraints should be validated and errors should be generated when violating the constraints (which is not happening at the moment). Basically, it should fail but it doesn't. was (Author: kkufova): NOTE FOR FUTURE KLARA: I know this is misleading for you. This is saying that constraints should be validated and errors should be generated when violating the constraints (which is not happening at the moment). Basically, it should fail but it doesn't. > Add support to DMN constraints on inputs (report input validation errors) > ------------------------------------------------------------------------- > > Key: DROOLS-3730 > URL: https://issues.jboss.org/browse/DROOLS-3730 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > > See this example https://github.com/kiegroup/drools/compare/master...tarilabs:tarilabs-201... > and try with a value out of the domain ranga [0..100]. > when a Decision or any evaluation which depends on such InputData is triggered, an error message like the following is reported > ```Error while evaluating node 'my decision' for dependency 'my input': the dependency value '999' is not allowed by the declared type (DMNType{ http://www.trisotech.com/definitions/_7ab67159-21c7-4985-91fc-f0d0174898db : tNumber0100 })``` -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ] Jan Stourac commented on WFWIP-160: ----------------------------------- [~flavia.rainone], [~fjuma], any new information regarding to this one? Note that EAP7-1022 is currently planned for {{JBoss EAP 7.3.0.CD17}}. > Fix throughput and response time differences between TLS 1.2 and TLS 1.3 > ------------------------------------------------------------------------ > > Key: WFWIP-160 > URL: https://issues.jboss.org/browse/WFWIP-160 > Project: WildFly WIP > Issue Type: Task > Reporter: Farah Juma > Assignee: Flavia Rainone > Priority: Blocker > > Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2. > Steps to reproduce (taken from EAP7-1022): > 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]: > https://github.com/fjuma/wildfly-elytron/tree/ELY-1706 > https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step) > https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step) > 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi > 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...] > 4. Configure and start server with TLSv1.3 and JDK 11: > {code} > connect > /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS) > /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost") > /subsystem=elytron/key-store=tls13:store() > /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret}) > /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"]) > batch > /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) > /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13) > run-batch > reload > {code} > 5. Start jmeter with JDK 11 and downloaded test plan > {code} > export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13 > {code} > 6. Set server to use TLSv1.2 > {code} > /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"]) > reload > {code} > 7. Repeat same for TLSv1.2 > {code} > export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12 > {code} > 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Guillaume Smet (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Guillaume Smet edited comment on WFLY-11956 at 4/25/19 3:35 AM: ---------------------------------------------------------------- [~ron_sigal] My understanding is that it's not the getter validation that is triggered. The field and getter form a unique validated entity called a property in HV. When validating the bean in {{JaxrsInjectionTarget}}, you validate the bean itself and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean. I'm not sure I'm seeing an easy way to disable this behavior as doing it globally with a configuration knob seems a bit dangerous as it would also disable it for the domain objects. We could probably imagine an entry point specific to {{JaxrsInjectionTarget}} to avoid validating the getters too but I'm not sure how dirty it would be and we would also probably need to keep the HV metadata generated by this entry point separate. [~gunnar.morling] any thoughts on that? I'm surprised it only surfaces now tbh as it seems a potentially very common issue. was (Author: guillaume.smet): [~ron_sigal] My understanding is that it's not the getter validation that is triggered. The field and getter form a unique validated entity called a property in HV. When validating the constructor of a bean, you validate the bean itself as the return value of the constructor and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean. I'm not sure I'm seeing an easy way to disable this behavior as doing it globally with a configuration knob seems a bit dangerous as it would also disable it for the domain objects. We could probably imagine an entry point specific to CDI to avoid validating the getters too but I'm not sure how dirty it would be and we would also probably need to keep the HV metadata generated by this entry point separate. [~gunnar.morling] any thoughts on that? I'm surprised it only surfaces now tbh as it seems a potentially very common issue. > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Ronald Sigal > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11116) Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception)

by ziad saade (Jira)

[ https://issues.jboss.org/browse/WFLY-11116?page=com.atlassian.jira.plugin... ] ziad saade commented on WFLY-11116: ----------------------------------- Dear Paul Moreover on the above, I noticed from the console log of Wildfly that the operations are running in different threads: 1-Execute Method2() (*Task2*) (thread-1) 2-Execute Method3() (*Task2*) (thread-1) 3-Execute Stm1 (*Task2*) (thread-1) 4-Execute response.sendredirect("index.html"); (*Taks3*) (thread-2) Best Regards > Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception) > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11116 > URL: https://issues.jboss.org/browse/WFLY-11116 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.1.Final, 12.0.0.Final, 13.0.0.Final, 15.0.0.Final > Reporter: ziad saade > Assignee: Paul Ferraro > Priority: Critical > > I have two Servlets Book and BookPreview the attribute is set in Book Servlet as follow: > > Book.java > TestBean testBean=null; > if(session.getAttribute("testBean")!=null) > testBean = (TestBean)session.getAttribute("testBean"); > else{ > testBean=new TestBean(); > session.setAttribute("testBean",testBean); > } > testBean.setAmount("10"); > > response.sendRedirect("BookPreview"); > > > The session attribute can be retrieved and the page is loaded normally and the Amount value is displayed however when submitting the form (Post Action in BookPreview.java) Null Pointer exception is generated. > > BookPreview.java > > TestBean testBean = (TestBean)session.getAttribute("testBean"); > String amount = testBean.getAmount; //Null pointer exception when submitting the form > > <form method="Post" action="BookPreview"> > > </form> > > TestBean.java > > public class TestBean implements java.io.Serializable { > > private static final long serialVersionUID = 1L; > private String amount; > > public String getAmount() { > return amount; > } > > public void setAmount(String amount) { > this.amount = amount; > } > } > > Kindly advice how to fix the problem at the level of the server configuration. > PS: I am not getting the exception when deploying the same application under other J EE application servers (Tomcat....) > > Thanks and Best Regards -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9929) JDR does not close some files properly

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/WFLY-9929?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-9929: ----------------------------------------------- Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1702809|https://bugzilla.redhat.com/show_bug.cgi?id=1702809] from NEW to POST > JDR does not close some files properly > -------------------------------------- > > Key: WFLY-9929 > URL: https://issues.jboss.org/browse/WFLY-9929 > Project: WildFly > Issue Type: Bug > Components: JDR > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Major > Fix For: 12.0.0.Final > > > This is probably to blame for the failures in the windows test suite that look like: > Caused by: java.nio.file.FileSystemException: M:\buildAgent\work\9ccd5e119c4a65d0\testsuite\integration\basic\target\wildfly\standalone\configuration\standalone.xml: The process cannot access the file because it is being used by another process. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Ronald Sigal (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Ronald Sigal commented on WFLY-11956: ------------------------------------- Thanks, [~guillaume.smet]. Yes, I see what I had wrong about getters. Hmm. Hmm. Could we have a {code} <field-validation> <do-not-validate> <property class="ValidatedJaxRsInterface">helloGreeting</property> </do-not-validate> </field-validation> {code} in validation.xml that overrides the @Valid in {code} @GET @Valid @Produces(MediaType.APPLICATION_JSON) GreetingModel getHelloGreeting(); {code} Or, remember when we talked about fields and properties being the same? Maybe we could have something like {code} <property-validation> <default-validated-property-types> <property-type>FIELD</executable-type> <property-type>GETTER</executable-type> </default-validated-property-types> </property-validation> {code} where we could leave out GETTER. > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Ronald Sigal > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12014) Distributed session manager should not assume unmodifiable sets are immutable

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12014: ----------------------------------- Summary: Distributed session manager should not assume unmodifiable sets are immutable Key: WFLY-12014 URL: https://issues.jboss.org/browse/WFLY-12014 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro >From java.util.Set javadoc: "Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set." -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Guillaume Smet (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Guillaume Smet commented on WFLY-11956: --------------------------------------- [~ron_sigal] My understanding is that it's not the getter validation that is triggered. The field and getter form a unique validated entity called a property in HV. When validating the constructor of a bean, you validate the bean itself as the return value of the constructor and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean. I'm not sure I'm seeing an easy way to disable this behavior as doing it globally with a configuration knob seems a bit dangerous as it would also disable it for the domain objects. We could probably imagine an entry point specific to CDI to avoid validating the getters too but I'm not sure how dirty it would be and we would also probably need to keep the HV metadata generated by this entry point separate. [~gunnar.morling] any thoughts on that? I'm surprised it only surfaces now tbh as it seems a potentially very common issue. > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Ronald Sigal > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9976) EJB Client Interceptor not invoked for Local Interface

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-9976?page=com.atlassian.jira.plugin.... ] Cheng Fang updated WFLY-9976: ----------------------------- Fix Version/s: 18.0.0.Beta1 > EJB Client Interceptor not invoked for Local Interface > ------------------------------------------------------ > > Key: WFLY-9976 > URL: https://issues.jboss.org/browse/WFLY-9976 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 12.0.0.Final > Reporter: Bartosz Baranowski > Assignee: Cheng Fang > Priority: Major > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019