July 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10752) NPE on deploy, when Email validation annotation present

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10752?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-10752: ------------------------------------ Component/s: Bean Validation > NPE on deploy, when Email validation annotation present > ------------------------------------------------------- > > Key: WFLY-10752 > URL: https://issues.jboss.org/browse/WFLY-10752 > Project: WildFly > Issue Type: Bug > Components: Bean Validation > Affects Versions: 13.0.0.Final > Environment: Arch linux, openjdk 8, Wildfly 13.0.0.Final > Reporter: d3coder d3coder > Assignee: Jason Greene > > I'm making simple app. In one of my DTO's i have field with `javax.validation.constraints.Email` annotation. When this annotation present, wildfly fails to deploy my app with this exception: > https://gist.github.com/XakepSDK/daa2531203b365ad1969e01b4466b8a1 > My DTO class: > https://gist.github.com/XakepSDK/a78245b262315437d2800be524018d2e > CrossField annotation: > https://gist.github.com/XakepSDK/fde1553339c18bc442820868f573a53a > CrossField validator: > https://gist.github.com/XakepSDK/391783e3b79f839a93a8f45c886b38e0 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3909) jboss-cli script does not delegate -D properties to java process

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3909?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3909: ------------------------------------------ This sounds like an RFE to me. It's not a bug that there are differences in how software we write functions. Note that standalone.sh does _not_ work by ensuring that all -D arg are passed as args to java. Most are passed as args to org.jboss.modules.Main, which in turn passes them through to org.jboss.as.server.Main, which in turn sets the system property. Same as the CLI CommandLineMain. This is done well after JVM launch and after quite a lot of system properties are read. IOW if you want to be sure your property is set before it's read, you need to edit standalone.conf. Using -D args to standalone.sh as a way to configure logging definitely doesn't work. Passing properties as args to standalone.sh is actually somewhat an anti-pattern that we support for historical reasons. Having the CLI script process all args and ensure that any -D is passed to java means a lot of script complication that would need to be maintained for all variations. And then, if the requirement is all scripts have the same functionality, that means we have to alter all the other scripts, including standalone.sh, to do the same thing. > jboss-cli script does not delegate -D properties to java process > ---------------------------------------------------------------- > > Key: WFCORE-3909 > URL: https://issues.jboss.org/browse/WFCORE-3909 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Affects Versions: 5.0.0.Final > Reporter: Erich Duda > Assignee: Marek Marusic > > *Scenario:* I want to change logging configuration of CLI using system properties. My expectation is that I just put the properties on command line as arguments. > {code} > ./jboss-cli.sh -Dlogging.configuration=... -Djboss.cli.log.level=TRACE -Djboss.cli.log.level=TRACE > {code} > However what I actually have to do is to put the properties into the {{JAVA_OPTS}} env variable. > {code} > JAVA_OPTS="-Dlogging.configuration=... -Djboss.cli.log.level=TRACE -Djboss.cli.log.level=TRACE" ./jboss-cli.sh > {code} > This is different behavior than I am used to standalone.sh script. IMO it is more natural to put the properties as arguments of the script. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10662) Upgrade JBeret from 1.3.0.Final to 1.3.1.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-10662?page=com.atlassian.jira.plugin... ] James Perkins commented on WFLY-10662: -------------------------------------- Diff https://github.com/jberet/jsr352/compare/1.3.0.Final...1.3.1.Final > Upgrade JBeret from 1.3.0.Final to 1.3.1.Final > ---------------------------------------------- > > Key: WFLY-10662 > URL: https://issues.jboss.org/browse/WFLY-10662 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Cheng Fang > Fix For: 14.0.0.CR1 > > > Upgrade JBeret to 1.3.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10662) Upgrade JBeret from 1.3.0.Final to 1.3.1.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-10662?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-10662: --------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/11240) > Upgrade JBeret from 1.3.0.Final to 1.3.1.Final > ---------------------------------------------- > > Key: WFLY-10662 > URL: https://issues.jboss.org/browse/WFLY-10662 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Cheng Fang > Fix For: 14.0.0.CR1 > > > Upgrade JBeret to 1.3.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10662) Upgrade JBeret from 1.3.0.Final to 1.3.1.Final

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-10662?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-10662: ----------------------------------- jberet 1.3.1 was released on 2018-07-30 out of [jberet/jsr352 1.3.x branch|https://github.com/jberet/jsr352/commits/1.3.x] https://issues.jboss.org/projects/JBERET/versions/12337765 > Upgrade JBeret from 1.3.0.Final to 1.3.1.Final > ---------------------------------------------- > > Key: WFLY-10662 > URL: https://issues.jboss.org/browse/WFLY-10662 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Cheng Fang > Fix For: 14.0.0.CR1 > > > Upgrade JBeret to 1.3.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3970) Reload Elytron ldap-key-store using JBoss CLI

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3970?page=com.atlassian.jira.plugi... ] Farah Juma commented on WFCORE-3970: ------------------------------------ Since an {{ldap-key-store}} already loads its entries in real-time, the focus of this task should actually be to add a management operation to allow an Elytron {{trust-manager}} to be re-initialized, similar to the {{key-manager}} {{init}} operation. I'm going to update the title of this issue to reflect this. > Reload Elytron ldap-key-store using JBoss CLI > --------------------------------------------- > > Key: WFCORE-3970 > URL: https://issues.jboss.org/browse/WFCORE-3970 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Justin Cook > > It is not possible to reload the certificates dynamically for Elytron's *ldap-key-store*. > If some changes have been made in the certificates present in LDAP directory then EAP needs to be restarted first in order to see those changes done in LDAP directory which is not ideal for production environments. > For simple file based keystores, *load* operation is available : > ------------------------- > [standalone@localhost:9990 /] /subsystem=elytron/key-store=twoWayKS:load() > ------------------------- > But this option is missing for *ldap-key-store* : > ------------------------- > [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=LKS1:load() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0031: No operation named 'load' exists at address [ > (\"subsystem\" => \"elytron\"), > (\"ldap-key-store\" => \"LKS1\") > ]", > "rolled-back" => true > } > ------------------------- > There should be such option available to reload the content of ldap-key-store without restarting the EAP server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3970) Add a management operation to allow an Elytron trust-manager to be re-initialized

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3970?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-3970: ------------------------------- Summary: Add a management operation to allow an Elytron trust-manager to be re-initialized (was: Reload Elytron ldap-key-store using JBoss CLI) > Add a management operation to allow an Elytron trust-manager to be re-initialized > --------------------------------------------------------------------------------- > > Key: WFCORE-3970 > URL: https://issues.jboss.org/browse/WFCORE-3970 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Justin Cook > > It is not possible to reload the certificates dynamically for Elytron's *ldap-key-store*. > If some changes have been made in the certificates present in LDAP directory then EAP needs to be restarted first in order to see those changes done in LDAP directory which is not ideal for production environments. > For simple file based keystores, *load* operation is available : > ------------------------- > [standalone@localhost:9990 /] /subsystem=elytron/key-store=twoWayKS:load() > ------------------------- > But this option is missing for *ldap-key-store* : > ------------------------- > [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=LKS1:load() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0031: No operation named 'load' exists at address [ > (\"subsystem\" => \"elytron\"), > (\"ldap-key-store\" => \"LKS1\") > ]", > "rolled-back" => true > } > ------------------------- > There should be such option available to reload the content of ldap-key-store without restarting the EAP server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10009) Introduce a maximum-timeout management model attribute

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-10009?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-10009: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11440 > Introduce a maximum-timeout management model attribute > ------------------------------------------------------ > > Key: WFLY-10009 > URL: https://issues.jboss.org/browse/WFLY-10009 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > some resources may fail with a timeout value of Integer.MAX_VALUE for various reasons, so a lower "maximum" (such as one year) might be better. The purpose of the suggestion of the maximum timeout attribute would be to make this value configurable (also in the event where someone programmatically sets a timeout which might be problematic), -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2805) Release notes for 7.9.0 Final are not linked correctly

by Daniele Zonca (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2805?page=com.atlassian.jira.plugi... ] Daniele Zonca updated DROOLS-2805: ---------------------------------- Sprint: 2018 Week 30-32 > Release notes for 7.9.0 Final are not linked correctly > ------------------------------------------------------ > > Key: DROOLS-2805 > URL: https://issues.jboss.org/browse/DROOLS-2805 > Project: Drools > Issue Type: Bug > Components: docs > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Labels: ScenarioSimulationTeam > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2805) Release notes for 7.9.0 Final are not linked correctly

by Daniele Zonca (JIRA)

Daniele Zonca created DROOLS-2805: ------------------------------------- Summary: Release notes for 7.9.0 Final are not linked correctly Key: DROOLS-2805 URL: https://issues.jboss.org/browse/DROOLS-2805 Project: Drools Issue Type: Bug Components: docs Reporter: Daniele Zonca Assignee: Daniele Zonca -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 July 2018