July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-151) Avoid Trigger collisions - Sprint-65

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-151?page=com.atlassian.jira.pl... ] Matt Mahoney updated HAWKULARQE-151: ------------------------------------ Description: Avoid Trigger collisions when Hawkular is linked to multiple MIQ installations Ref Sprint Review: https://www.youtube.com/watch?v=nXLLLv_QyP0&feature=em-subs_digest was: Avoid Trigger collisions when MIQ is linked to multiple MIQ's Ref Sprint Review: https://www.youtube.com/watch?v=nXLLLv_QyP0&feature=em-subs_digest > Avoid Trigger collisions - Sprint-65 > ------------------------------------ > > Key: HAWKULARQE-151 > URL: https://issues.jboss.org/browse/HAWKULARQE-151 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Avoid Trigger collisions when Hawkular is linked to multiple MIQ installations > Ref Sprint Review: https://www.youtube.com/watch?v=nXLLLv_QyP0&feature=em-subs_digest -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1683) ExcelParse can re-write files

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1683?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1683: -------------------------------- Sprint: 2017 Week 30-31 > ExcelParse can re-write files > ----------------------------- > > Key: DROOLS-1683 > URL: https://issues.jboss.org/browse/DROOLS-1683 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.0.0.Final > Reporter: James Livingston > Assignee: Mario Fusco > > ExcelParser.open(File) uses the single argument WorkbookFactory.create() call, which opens the file in read-write mode, so when parseWorkbook() calls close on it, it will save the workbook to disk. > Usually the resulting file is the same, however it may be binary-different but equivalent(causing git conflicts). Being read-only does not cause an error since the exceptions are swallowed silently. > It should use the three argument form of WorkbookFactory.create() and pass the read-only flag -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8456) Protocols added to a fork of some channel won't show in JMX MBeans

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8456?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-8456: ------------------------------------ I would suggest moving the mbean registration logic from ChannelBuilder to the ChannelFactory implementations themselves. This eliminates the need for special handling for externally created channels. Something like: {code:java} public MyChannelFactory implements ChannelFactoy, ChannelListener { @Override public Channel createChannel(String id) { Channel channel = // create channel JmxConfigurator.registerChannel(channel, ...); channel.addListener(this); return channel; } @Override public void channelClosed(Channel channel) { JmxConfigurator.unregisterChannel(channel, ...); channel.removeListener(this); } } {code} > Protocols added to a fork of some channel won't show in JMX MBeans > ------------------------------------------------------------------ > > Key: WFLY-8456 > URL: https://issues.jboss.org/browse/WFLY-8456 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > > When defining a fork of some channel and adding a protocol to the protocol stack of that fork channel, the newly added protocol won't show up in JMX MBeans. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-161) AsyncHandler is always creating a stacktrace dump

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-161?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-161: ------------------------------------ Assignee: James Perkins > AsyncHandler is always creating a stacktrace dump > ------------------------------------------------- > > Key: LOGMGR-161 > URL: https://issues.jboss.org/browse/LOGMGR-161 > Project: JBoss Log Manager > Issue Type: Enhancement > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Koen Janssens > Assignee: James Perkins > > I have noticed that when introducing an AsyncHandler for logging, all log statement are copied before being put on the queue and as part of that copy a complete stack dump is done. > This might be useful if the stack info is used by a downstream formatter (eg for line number identification), but even if the line numbers are not used anywhere, this still happens. > I think this behavior should be at least optional. > Source Location: org.jboss.logmanager.ExtLogRecord#copyAll -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3073: ------------------------------------- Summary: Handle TERM gracefully (was: Handle TERM cleanly) > Handle TERM gracefully > ---------------------- > > Key: WFCORE-3073 > URL: https://issues.jboss.org/browse/WFCORE-3073 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Parees > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. > While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). > Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3124) Handle TERM gracefully

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3124: ---------------------------------------- Summary: Handle TERM gracefully Key: WFCORE-3124 URL: https://issues.jboss.org/browse/WFCORE-3124 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Ben Parees Assignee: Brian Stansberry Fix For: 4.0.0.Alpha1 The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1649) Avoid using Class.forName in static factory methods

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1649?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1649: ----------------------------------- Assignee: Mario Fusco (was: Matteo Mortari) > Avoid using Class.forName in static factory methods > --------------------------------------------------- > > Key: DROOLS-1649 > URL: https://issues.jboss.org/browse/DROOLS-1649 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > > All factory calls should go through the ServiceRegistryImpl instead of using Class.forName -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9151) CLIENT_CERT without users certificates database

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9151?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9151: ---------------------------------------- Shouldn't this be in WFCORE? > CLIENT_CERT without users certificates database > ----------------------------------------------- > > Key: WFLY-9151 > URL: https://issues.jboss.org/browse/WFLY-9151 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 12.0.0.Alpha1 > > > CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them. > Analysis document: > https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9153) Upgrade Artemis 1.5.5.jbossorg-006

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9153?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-12425 to WFLY-9153: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9153 (was: JBEAP-12425) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) > Upgrade Artemis 1.5.5.jbossorg-006 > ---------------------------------- > > Key: WFLY-9153 > URL: https://issues.jboss.org/browse/WFLY-9153 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1312) Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1312?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on ELY-1312: --------------------------------------- We could even take this slightly further and allow these options to apply to other mechanisms - e.g. FORM authentication could use an alternative SCOPE, e.g. specify SSL Scope and without an SSLSession FORM authentication is not possible. This could mean if your connection is clear mechanisms such as Digest or SCRAM are possible but until an SSLSession is established FORM authentication is not possible. It could potentially become a simple form of SSO where a common SSLSession is used across multiple applications. > Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism > ----------------------------------------------------------------------------- > > Key: ELY-1312 > URL: https://issues.jboss.org/browse/ELY-1312 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Environment: # > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > Currently the SpnegoAuthenticationMechanism caches against the connection scope and uses the cached GssContext to recreate the identity. > We should consider the following: - > # Using the same cached identity mechanism as is used by FORM authentication. > # Adding configuration to specify which scope to cache against. > # Add an option to disable caching entirely, this would need to take into account cases where continuation is required as that would become unsupported. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 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 July 2017