August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-462) DirContext suppliing service to be used in LDAP realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-462?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-462: --------------------------- Description: There will be DirContext suppling service, which will be referenced by realm: * output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext() Problematic place: DirectEvidenceVerifier * context can be copied using (Context)ctx.lookup("") * was: There will be DirContext suppling service, which will be referenced by realm: * output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext() > DirContext suppliing service to be used in LDAP realm > ----------------------------------------------------- > > Key: ELY-462 > URL: https://issues.jboss.org/browse/ELY-462 > Project: WildFly Elytron > Issue Type: Task > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There will be DirContext suppling service, which will be referenced by realm: > * output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext() > Problematic place: DirectEvidenceVerifier > * context can be copied using (Context)ctx.lookup("") > * -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6909) Upgrade to RESTEasy 3.0.19.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-6909: ------------------------------------- Summary: Upgrade to RESTEasy 3.0.19.Final Key: WFLY-6909 URL: https://issues.jboss.org/browse/WFLY-6909 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 10.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1682: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1720 > Missleading tab completion for edit-batch-line command > ------------------------------------------------------ > > Key: WFCORE-1682 > URL: https://issues.jboss.org/browse/WFCORE-1682 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Petr Kremensky > Assignee: Jean-Francois Denise > > Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works. > *command usage* > {noformat} > [standalone@localhost:9990 /] batch > [standalone@localhost:9990 / #] :read-resource > [standalone@localhost:9990 / #] list-batch > #1 /:read-resource > [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type) > #1 :read-attribute(name=launch-type) > [standalone@localhost:9990 / #] list-batch > #1 :read-attribute(name=launch-type) > {noformat} > *actual* > {noformat} > [standalone@localhost:9990 / #] edit-batch-line <TAB> > [standalone@localhost:9990 / #] edit-batch-line --<TAB> > --help --line-number > [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type) > Failed to parse line number '--line-number=1': For input string: "--line-number=1" > {noformat} > {{--line-number}} shouldn't be offered by tab completion for the command. > Misleading tab completion ends up with syntax error. > *expected* > {noformat} > [standalone@localhost:9990 / #] edit-batch-line <TAB> > --help > {noformat} > The issue is a regression against EAP 7.0.0 release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1687) WFLYCTL0357 warning upon undeploying any deployment

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1687?page=com.atlassian.jira.plugi... ] Martin Simka moved JBEAP-5507 to WFCORE-1687: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1687 (was: JBEAP-5507) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Server (was: Domain Management) Affects Version/s: (was: 7.1.0.DR1) > WFLYCTL0357 warning upon undeploying any deployment > --------------------------------------------------- > > Key: WFCORE-1687 > URL: https://issues.jboss.org/browse/WFCORE-1687 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Martin Simka > Assignee: Brian Stansberry > > EAP produces following warning upon undeployment: > {code}WARN [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address []{code} > The warning is produced for both managed and unmanaged deployments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1687) WFLYCTL0357 warning upon undeploying any deployment

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1687?page=com.atlassian.jira.plugi... ] Martin Simka updated WFCORE-1687: --------------------------------- Affects Version/s: 3.0.0.Alpha4 > WFLYCTL0357 warning upon undeploying any deployment > --------------------------------------------------- > > Key: WFCORE-1687 > URL: https://issues.jboss.org/browse/WFCORE-1687 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha4 > Reporter: Martin Simka > Assignee: Brian Stansberry > > EAP produces following warning upon undeployment: > {code}WARN [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address []{code} > The warning is produced for both managed and unmanaged deployments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1244) TimedRuleExectionOption typing mistake

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1244: -------------------------------------- Summary: TimedRuleExectionOption typing mistake Key: DROOLS-1244 URL: https://issues.jboss.org/browse/DROOLS-1244 Project: Drools Issue Type: Enhancement Affects Versions: 7.0.0.Beta1 Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor TimedRuleExectionOption typo in class definition and documentation. Impacts: * code changes * System property / configuration * to be properly documented (as a breaking change) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6908) Add checkstyle testing also to tests classes in wildfly

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFLY-6908: --------------------------------------- Summary: Add checkstyle testing also to tests classes in wildfly Key: WFLY-6908 URL: https://issues.jboss.org/browse/WFLY-6908 Project: WildFly Issue Type: Enhancement Components: Test Suite Affects Versions: 10.1.0.CR1 Reporter: Rostislav Svoboda Assignee: Tomaz Cerar Add checkstyle testing also to tests classes in Wildfly codebase. Please create automated job(s) on http://ci.wildfly.org/ so we see trends in the results. TeamCity should be able to work with Checkstyle reports using XML Report processing build feature - resources: https://confluence.jetbrains.com/display/TCD10/XML+Report+Processing and http://kalssworld.blogspot.cz/2013/03/integrating-code-quality-reports-to... With the checkstyle it would be great to see results per module in testsuite and maybe even per package to see the most problematic parts. NOTE: Please add some info about and how to run checkstyle + reports into https://github.com/wildfly/wildfly/blob/master/README.md or another place you find more suitable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-358) Enable checkstyle for clustering integration testsuite

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-358?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar reassigned WFLY-358: -------------------------------- Assignee: Tomaz Cerar (was: Radoslav Husar) > Enable checkstyle for clustering integration testsuite > ------------------------------------------------------ > > Key: WFLY-358 > URL: https://issues.jboss.org/browse/WFLY-358 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Test Suite > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Priority: Minor > > Ideally this will make live easier by less rebasing due to formatting differences and easier PR reviews. Lets see how it goes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2094) Add convenience method Rsp.readIn

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-2094?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-2094: ------------------------------ Description: In Infinispan, during a staggered get we prepare several {{Rsp}} s in {{RspList}} and then for each {{Rsp}} we send one message. As the {{RspList}} can be accessed by multiple threads but we don't want to synchronize the access, we just get the {{Rsp}} and fill it from the (other) received {{Rsp}}. However the fill requires several ifs: {code} if (rsp.hasException()) { futureRsp.setException(rsp.getException()); } else if (rsp.wasSuspected()) { futureRsp.setSuspected(); } else if (rsp.wasUnreachable()) { futureRsp.setUnreachable(); } else { futureRsp.setValue(rsp.getValue()); } {code} Let's add a convenience method that will just read in the flags and value. was: In Infinispan, during a staggered get we prepare several {{Rsp}}s in {{RspList}} and then for each {{Rsp}} we send one message. As the {{RspList}} can be accessed by multiple threads but we don't want to synchronize the access, we just get the {{Rsp}} and fill it from the (other) received {{Rsp}}. However the fill requires several ifs: {code} if (rsp.hasException()) { futureRsp.setException(rsp.getException()); } else if (rsp.wasSuspected()) { futureRsp.setSuspected(); } else if (rsp.wasUnreachable()) { futureRsp.setUnreachable(); } else { futureRsp.setValue(rsp.getValue()); } {code} Let's add a convenience method that will just read in the flags and value. > Add convenience method Rsp.readIn > --------------------------------- > > Key: JGRP-2094 > URL: https://issues.jboss.org/browse/JGRP-2094 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.10, 4.0 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > In Infinispan, during a staggered get we prepare several {{Rsp}} s in {{RspList}} and then for each {{Rsp}} we send one message. As the {{RspList}} can be accessed by multiple threads but we don't want to synchronize the access, we just get the {{Rsp}} and fill it from the (other) received {{Rsp}}. However the fill requires several ifs: > {code} > if (rsp.hasException()) { > futureRsp.setException(rsp.getException()); > } else if (rsp.wasSuspected()) { > futureRsp.setSuspected(); > } else if (rsp.wasUnreachable()) { > futureRsp.setUnreachable(); > } else { > futureRsp.setValue(rsp.getValue()); > } > {code} > Let's add a convenience method that will just read in the flags and value. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2094) Add convenience method Rsp.readIn

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-2094?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-2094: ------------------------------ Affects Version/s: 4.0 > Add convenience method Rsp.readIn > --------------------------------- > > Key: JGRP-2094 > URL: https://issues.jboss.org/browse/JGRP-2094 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.10, 4.0 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > In Infinispan, during a staggered get we prepare several {{Rsp}}s in {{RspList}} and then for each {{Rsp}} we send one message. As the {{RspList}} can be accessed by multiple threads but we don't want to synchronize the access, we just get the {{Rsp}} and fill it from the (other) received {{Rsp}}. However the fill requires several ifs: > {code} > if (rsp.hasException()) { > futureRsp.setException(rsp.getException()); > } else if (rsp.wasSuspected()) { > futureRsp.setSuspected(); > } else if (rsp.wasUnreachable()) { > futureRsp.setUnreachable(); > } else { > futureRsp.setValue(rsp.getValue()); > } > {code} > Let's add a convenience method that will just read in the flags and value. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 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 August 2016