March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11817) CDI @Resource(lookup=...) processing does not start corresponding binding service

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11817?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-11817: ------------------------------------- [~manovotn] A simple modification to this test will reproduce the problem: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi... Adding a CDI annotation anywhere within: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi... will cause CDI to resolve the @Resource annotations instead of the ee subsystem. This causes the test to fail with an NPE. For reference, the deployment processor for @Resource annotations in the ee subsystem is here: https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss... specifically, the resolution for @Resource(lookup="...") is handled by: https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss... The binding service to which I was referring (as used by LookupInjectionSource) is here: https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/j... > CDI @Resource(lookup=...) processing does not start corresponding binding service > --------------------------------------------------------------------------------- > > Key: WFLY-11817 > URL: https://issues.jboss.org/browse/WFLY-11817 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Matej Novotny > Priority: Major > > If the corresponding binding service (the service responsible for creating the jndi binding) is not ACTIVE (e.g. clustering binding services are always PASSIVE) or, due to a race condition, has not yet started completely, a null value will be returned. > The ee subsystem processes @Resource(lookup=...) correctly by establishing a dependency on the corresponding binder service. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11819) max-allowed-connected-nodes element in jboss-ejb-client.xml not used

by Jörg Bäsner (Jira)

Jörg Bäsner created WFLY-11819: ---------------------------------- Summary: max-allowed-connected-nodes element in jboss-ejb-client.xml not used Key: WFLY-11819 URL: https://issues.jboss.org/browse/WFLY-11819 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 16.0.0.Final Environment: In a cluster with used {{remote-outbound-connections}} for remote EJB invocations and a {{clusters}} definition containing the {{max-allowed-connected-nodes}}, like: {code} <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2"> ... <clusters> <cluster name="ejb" ... max-allowed-connected-nodes="1"> </cluster> </clusters> </client-context> </jboss-ejb-client> {code} Reporter: Jörg Bäsner Assignee: Jörg Bäsner An application uses {{remote-outbound-connections}} for remote EJB invocations and the {{jboss-ejb-client.xml}} contains a {{clusters}} definition containing the {{max-allowed-connected-nodes}}, like below: {code} <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2"> ... <clusters> <cluster name="ejb" ... max-allowed-connected-nodes="20"> </cluster> </clusters> </client-context> </jboss-ejb-client> {code} In the actually used {{EJBClientContext}} this value doesn't get assigned and the hard coded default value of _10_ is being used. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11818) wildfly-16.0.0.Final: "From address" is no more used as default from in email

by Wolfgang Mayer (Jira)

[ https://issues.jboss.org/browse/WFLY-11818?page=com.atlassian.jira.plugin... ] Wolfgang Mayer commented on WFLY-11818: --------------------------------------- Tomaz I am not sure understanding your comment correctly. But I understand the JavaMail (TM) Specification did not change and in the JavaMail API doc it says: public abstract void setFrom(): Set the "From" attribute in this Message. The value of this attribute is obtained from the property "mail.user". If this property is absent, the system property "user.name" is used. Maybe had there been any change in how the "user.name" property is populated? > wildfly-16.0.0.Final: "From address" is no more used as default from in email > ----------------------------------------------------------------------------- > > Key: WFLY-11818 > URL: https://issues.jboss.org/browse/WFLY-11818 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 16.0.0.Final > Environment: mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00) > Maven home: /apps/apache-maven-3.6.0 > Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix" > Reporter: Wolfgang Mayer > Assignee: Tomaz Cerar > Priority: Major > > As mentioned in the Help (description) of 'Mail Session' configuration: > From: *From address that is used as default from, if not set when sending* > Apparently this is not the case anymore in wildfly-16.0.0.Final. > For example I made a test with quickstart-16.0/mail/. > When omitting the line > *message.setFrom(new InternetAddress(from));* > Sending mail fails with: > com.sun.mail.smtp.SMTPSendFailedException: 554-Transaction failed > 554 Unauthorized sender address. > I have the same issue when replacing the line above with > message.setFrom(new InternetAddress()); > I am pretty sure that this is working in wildfly-15 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-633) Separate the Resources on Kiali Test Mesh Operator

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-633?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-633: ------------------------------------------ Description: First version of Kiali Test Mesh Operator was based on one resource of installation type. It leads to an issue when complex mesh installed and want to have a separate bookinfo, you need to remove both. That is not ideal > Separate the Resources on Kiali Test Mesh Operator > -------------------------------------------------- > > Key: SWSQE-633 > URL: https://issues.jboss.org/browse/SWSQE-633 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Priority: Major > > First version of Kiali Test Mesh Operator was based on one resource of installation type. > It leads to an issue when complex mesh installed and want to have a separate bookinfo, you need to remove both. > That is not ideal -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3735) [DMN Designer] Expression constraint is not parsed to Range constraint

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3735?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3735: -------------------------------- Steps to Reproduce: # Create new dmn model # Select data types tab # Add new data type entry, set its type as *date* # Click on the constraints # Select expression and put: [date( "2016-07-29" )..date( "2016-07-30" )] # Save constraint, save model, close and reopen # Navigate to same data type entry, invoke constraint modal popup # Change constraint from expression to range, ranges is not parsed > [DMN Designer] Expression constraint is not parsed to Range constraint > ---------------------------------------------------------------------- > > Key: DROOLS-3735 > URL: https://issues.jboss.org/browse/DROOLS-3735 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.19.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2019-03-07 11-11-18.png, Screenshot from 2019-03-07 11-11-30.png > > > If the data type constraint is set as {{[date( "2016-07-29" )..date( "2016-07-30" )]}} [0], it is not recognized as an range in the [1]. > The problem is that our {{ParseService}} for parsing Range, doesn't check deeply, what is the type of {{StartNode}} [3]. And then the {{DateValueFormatter}} component fails to replace the leading {color:red}{{date(}}{color} [4]. > [0] > !Screenshot from 2019-03-07 11-11-18.png|thumbnail! > [1] > !Screenshot from 2019-03-07 11-11-30.png|thumbnail! > [3] > https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/k... > [4] > https://github.com/kiegroup/kie-wb-common/pull/2508/files#diff-e199e1e595... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3735) [DMN Designer] Expression constraint is not parsed to Range constraint

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3735?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3735: -------------------------------- Description: If the data type constraint is set as {{[date( "2016-07-29" )..date( "2016-07-30" )]}} [0], it is not recognized as an range in the [1]. The problem is that our {{ParseService}} for parsing Range, doesn't check deeply, what is the type of {{StartNode}} [3]. And then the {{DateValueFormatter}} component fails to replace the leading {color:red}{{date(}}{color} [4]. [0] !Screenshot from 2019-03-07 11-11-18.png|thumbnail! [1] !Screenshot from 2019-03-07 11-11-30.png|thumbnail! [3] https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/k... [4] https://github.com/kiegroup/kie-wb-common/pull/2508/files#diff-e199e1e595... was: If the data type constraint is set as {{[date( "2016-07-29" )..date( "2016-07-30" )]}} [0], it is not recognized as an range in the [1]. The problem is that our {{ParseService}} for parsing Range, doesn't check deeply, what is the type of {{StartNode}} [3]. And then the {{DateValueFormatter}} component fails to replace the leading {{date(}} [4]. [0] !Screenshot from 2019-03-07 11-11-18.png|thumbnail! [1] !Screenshot from 2019-03-07 11-11-30.png|thumbnail! [3] https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/k... [4] https://github.com/kiegroup/kie-wb-common/pull/2508/files#diff-e199e1e595... > [DMN Designer] Expression constraint is not parsed to Range constraint > ---------------------------------------------------------------------- > > Key: DROOLS-3735 > URL: https://issues.jboss.org/browse/DROOLS-3735 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.19.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2019-03-07 11-11-18.png, Screenshot from 2019-03-07 11-11-30.png > > > If the data type constraint is set as {{[date( "2016-07-29" )..date( "2016-07-30" )]}} [0], it is not recognized as an range in the [1]. > The problem is that our {{ParseService}} for parsing Range, doesn't check deeply, what is the type of {{StartNode}} [3]. And then the {{DateValueFormatter}} component fails to replace the leading {color:red}{{date(}}{color} [4]. > [0] > !Screenshot from 2019-03-07 11-11-18.png|thumbnail! > [1] > !Screenshot from 2019-03-07 11-11-30.png|thumbnail! > [3] > https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/k... > [4] > https://github.com/kiegroup/kie-wb-common/pull/2508/files#diff-e199e1e595... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3735) [DMN Designer] Expression constraint is not parsed to Range constraint

by Jozef Marko (Jira)

Jozef Marko created DROOLS-3735: ----------------------------------- Summary: [DMN Designer] Expression constraint is not parsed to Range constraint Key: DROOLS-3735 URL: https://issues.jboss.org/browse/DROOLS-3735 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.19.0.Final Reporter: Jozef Marko Assignee: Jozef Marko Attachments: Screenshot from 2019-03-07 11-11-18.png, Screenshot from 2019-03-07 11-11-30.png If the data type constraint is set as {{[date( "2016-07-29" )..date( "2016-07-30" )]}} [0], it is not recognized as an range in the [1]. The problem is that our {{ParseService}} for parsing Range, doesn't check deeply, what is the type of {{StartNode}} [3]. And then the {{DateValueFormatter}} component fails to replace the leading {{date(}} [4]. [0] !Screenshot from 2019-03-07 11-11-18.png|thumbnail! [1] !Screenshot from 2019-03-07 11-11-30.png|thumbnail! [3] https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/k... [4] https://github.com/kiegroup/kie-wb-common/pull/2508/files#diff-e199e1e595... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-618) Move Bookinfo to Kiali Test Mesh Operator

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-618?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-618: ------------------------------------------ Description: Moving Bookinfo to Kiali Test Mesh order to get the automatic injection of maistra (was: Moving Bookinfo to Kiali Test Meshin order to get the automatic injection of maistra) > Move Bookinfo to Kiali Test Mesh Operator > ----------------------------------------- > > Key: SWSQE-618 > URL: https://issues.jboss.org/browse/SWSQE-618 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > Moving Bookinfo to Kiali Test Mesh order to get the automatic injection of maistra -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-618) Move Bookinfo to Kiali Test Mesh Operator

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-618?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-618. ------------------------------------------- Resolution: Done > Move Bookinfo to Kiali Test Mesh Operator > ----------------------------------------- > > Key: SWSQE-618 > URL: https://issues.jboss.org/browse/SWSQE-618 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > Moving Bookinfo to Kiali Test Meshin order to get the automatic injection of maistra -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11818) wildfly-16.0.0.Final: "From address" is no more used as default from in email

by Tomaz Cerar (Jira)

[ https://issues.jboss.org/browse/WFLY-11818?page=com.atlassian.jira.plugin... ] Tomaz Cerar commented on WFLY-11818: ------------------------------------ Given that there ware no real changes in mail subsystem for a while https://github.com/wildfly/wildfly/commits/master/mail/src/main/java/org/... I suspect that problem must be caused by newer version of java mail dependency the code that does that config of the property is https://github.com/wildfly/wildfly/blob/master/mail/src/main/java/org/jbo... > wildfly-16.0.0.Final: "From address" is no more used as default from in email > ----------------------------------------------------------------------------- > > Key: WFLY-11818 > URL: https://issues.jboss.org/browse/WFLY-11818 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 16.0.0.Final > Environment: mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00) > Maven home: /apps/apache-maven-3.6.0 > Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix" > Reporter: Wolfgang Mayer > Assignee: Tomaz Cerar > Priority: Major > > As mentioned in the Help (description) of 'Mail Session' configuration: > From: *From address that is used as default from, if not set when sending* > Apparently this is not the case anymore in wildfly-16.0.0.Final. > For example I made a test with quickstart-16.0/mail/. > When omitting the line > *message.setFrom(new InternetAddress(from));* > Sending mail fails with: > com.sun.mail.smtp.SMTPSendFailedException: 554-Transaction failed > 554 Unauthorized sender address. > I have the same issue when replacing the line above with > message.setFrom(new InternetAddress()); > I am pretty sure that this is working in wildfly-15 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019