March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1455) Undertow 1.3.20.Final

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-1455: -------------------------------------- Summary: Undertow 1.3.20.Final Key: WFCORE-1455 URL: https://issues.jboss.org/browse/WFCORE-1455 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1025) NPE removing a rule that contains a subnetwork

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1025?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1025: ------------------------------------------------- Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1298579|https://bugzilla.redhat.com/show_bug.cgi?id=1298579] from MODIFIED to ON_QA > NPE removing a rule that contains a subnetwork > ---------------------------------------------- > > Key: DROOLS-1025 > URL: https://issues.jboss.org/browse/DROOLS-1025 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > > Removing a rule containing a subnetwork causes the following NPE: > {code} > java.lang.NullPointerException > at org.drools.core.phreak.AddRemoveRule.deletePeerLeftTuple(AddRemoveRule.java:777) > at org.drools.core.phreak.AddRemoveRule.followPeer(AddRemoveRule.java:749) > at org.drools.core.phreak.AddRemoveRule.processLeftTuples(AddRemoveRule.java:713) > at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:281) > at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:153) > at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173) > at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626) > at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1089) Reentrant working memory actions aren't flushed immediately even when eager evaluation is forced

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1089?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1089: ------------------------------------------------- Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1316860|https://bugzilla.redhat.com/show_bug.cgi?id=1316860] from MODIFIED to ON_QA > Reentrant working memory actions aren't flushed immediately even when eager evaluation is forced > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-1089 > URL: https://issues.jboss.org/browse/DROOLS-1089 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.CR2, 7.0.0.Final > > > jBPM requires Drools working memory actions to be immediately flushed and then uses Drools force eager activation option. However even when this option is enabled working memory actions that aren't created in a reentrant way (during a rule firing) are enqueued instead of being flushed as expected by jBPM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6439) Undertow access_log prefix/suffix default values discrepancy

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6439?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-3988 to WFLY-6439: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6439 (was: JBEAP-3988) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Target Release: (was: 7.0.0.GA) Affects Version/s: (was: 7.0.0.ER7) > Undertow access_log prefix/suffix default values discrepancy > ------------------------------------------------------------ > > Key: WFLY-6439 > URL: https://issues.jboss.org/browse/WFLY-6439 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > Schema definition of Undertow access log {{prefix}} and {{suffix}} attributes [in this file|https://github.com/jbossas/jboss-eap7/blob/EAP_7.0.0.ER7-dev/underto...] do not match what is [in access log definition|https://github.com/jbossas/jboss-eap7/blob/EAP_7.0.0.ER7-dev/u...] - see the difference in > {{access_log}} -> {{access_log.}} and {{.log}} -> {{log}} > There was a change [in this commit|https://github.com/jbossas/jboss-eap7/commit/f47aa52bf67f4d8a469ba...]. > Those values should match and according to mentioned commit I propose to edit schema definition to what is in access log definition file (therefore: prefix = "access_log." and suffix = "log"). > NOTE: I am setting target for GA as this is trivial change in schema definition and better to change it before GA as after this any change to schema definition is difficult. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6438) Undertow listener max-header-size default value discrepancy

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6438?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-3987 to WFLY-6438: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6438 (was: JBEAP-3987) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Target Release: (was: 7.0.0.GA) Affects Version/s: (was: 7.0.0.ER7) > Undertow listener max-header-size default value discrepancy > ----------------------------------------------------------- > > Key: WFLY-6438 > URL: https://issues.jboss.org/browse/WFLY-6438 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > There is discrepancy in undertow schema definition of [listener attribute 'max-header-size' default value here|https://github.com/jbossas/jboss-eap7/blob/EAP_7.0.0.ER7-dev/underto...] and [ListenerResourceDefinition here|https://github.com/jbossas/jboss-eap7/blob/EAP_7.0.0.ER7-dev/underto...]. > Note: Default value in ListenerResourceDefinition java file was changed by [this commit|https://github.com/undertow-io/undertow/commit/9cfd0c7dca671bd0089...] > These two default values should be unified so they match. > NOTE: I set GA as a target release as this is probably trivial change in Undertow schema definition which is better to do before GA as after that any change into schema is difficult. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1318: ------------------------------------------------ Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1320720|https://bugzilla.redhat.com/show_bug.cgi?id=1320720] from POST to MODIFIED > list driven ExceptionSorter, StaleConnectionChecker > --------------------------------------------------- > > Key: JBJCA-1318 > URL: https://issues.jboss.org/browse/JBJCA-1318 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Johnathon Lee > Assignee: Johnathon Lee > Priority: Minor > Fix For: WildFly/IronJacamar 1.3.4.Final, 1.0.37.Final, 1.2.8.Final > > > Configuration defined ExceptionSorter, StaleConnectionChecker. > Using an externally (from the implementation) defined "," separated list. > Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files. > ie: > set via <config-property name="FatalExceptions">10099,10100,10101</> > set via <config-property name="StaleExceptions">10099,10100,10101</> > Documentation updated to reflect suggested error codes for vendor based upon the current implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-178) Domain to domain identity propagation

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-178?page=com.atlassian.jira.plugin.sy... ] Farah Juma reassigned ELY-178: ------------------------------ Assignee: Farah Juma (was: Darran Lofthouse) > Domain to domain identity propagation > ------------------------------------- > > Key: ELY-178 > URL: https://issues.jboss.org/browse/ELY-178 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 1.1.0.CR1 > > > At the lowest level a users identity is associated with a single SecurityRealm, two accounts that authenticated against different realms will never be considered equal. > However on top of this we have the security domains, a security domain amongst other things is an aggregation of realms. Incoming server connections and also applications can be associated with a security domain. However we still have the following two scenarios of a call to complete the consideration for: - > Connection -> Deployment > Deployment -> Deployment > In the first case the connection may be associated with a security domain with a large set of realms, however the deployment may be associated with a smaller set of realms. In the case that the realm is in both of these domains we need the identity to be able to automatically propagate. > Same for deployment to deployment calls, if there is a common realm the identity should propagate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1106) Better handling of subsequent changes once the server is placed into reload-required

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1106?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1106: ------------------------------------------ Re: "A tricky bit with this part: 2) The kernel detects this and finds the registration for the foo=bar resource type, and sees that the resource provides capability org.wildfly.foo.bar...." I have implemented the following to account for the fact the child resources may be "incorporated" in the config of a capability but don't themselves register the capability: 1) The default behavior when seeing if a resource is affected by a reload-required cap is, if the resource itself hasn't registered any capability to walk up the resource tree looking for one that has, continuing until one is found or... a) the resource being examined has subsystem=??? as the last element in its address. Subsystem resources are not incorporated in the config of kernel capabilities. b) the parent of the resource being examined is the root resource or a /host=??? resource. Capabilities registered by those parents do not incorporate child resources in their config. 2) The MRR for a resource type incorporated in a parent's capability can explicitly declare this. Doing this is expected to be unusual, as it's just an optimization to avoid the searching logic discussed above. 3) An MRR can also explicitly declare that the resources are *not* incorporated in *any* parent resource's capability. This is useful when parent resources register a capability, while *at the moment* child resources do not. The child resources are not part of the parent capability but have no capability of their own. At some point devs will work out the capability API for the child resources, and then the code will be modified and the children will register a capability. Until this happens, letting the children declare they are not part of the parent's capability lets them avoid being affected by an operation on the parent triggering reload-required. All of this is handled in a separate commit in the linked PR. > Better handling of subsequent changes once the server is placed into reload-required > ------------------------------------------------------------------------------------ > > Key: WFCORE-1106 > URL: https://issues.jboss.org/browse/WFCORE-1106 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > When the handler for a configuration change operation determines that it cannot effect the change to the current runtime services, it places the process into "reload-required" state. From the moment this occurs until the reload is performed, the configuration model is inconsistent with the runtime services. > This can lead to problems when, prior to reload, the user makes further configuration changes. Those changes can succeed in Stage.MODEL, since the change is valid given the current state of the configuration model, but then when the handler attempts to update the runtime the changes fail because the runtime services are in a different state. Some common scenarios: > 1) User removes a resource, triggering reload required. Then they re-add the resource, which fails with a DuplicateServiceException since the service from the original version of the resource hasn't been removed yet. > 2) User makes some other config change to a resource which can't be effected immediately, so the server is put into reload-required. The user then adds another resource that depends on the services from the first resource, and that add fails because the runtime service from the first resource is not in the expected state. > A naive fix for this would be once the process goes into reload-required state to stop making any further runtime changes for steps that alter the persistent config. (Runtime changes for ops that don't touch persistent config would be ok, e.g. reload itself, or runtime-only ops like popping a message off a JMS queue.) > The problem with the naive approach is config changes that could take immediate effect no longer will. This could break existing scripts, or just be annoying in general. For example, a server is in reload-required state but is still running. Then the user wants to add a logger category or change the level of an existing one in order to get some diagnostic info. The logging change would not affect the runtime until the reload is done, forcing a reload to get the diagnostic data. > Stuart Douglas had an excellent suggestion today of looking into tying this in to capabilities and requirements. So, for example: > 1) An op targeted at resource foo=bar causes the process to go into reload-required. > 2) The kernel detects this and finds the registration for the foo=bar resource type, and sees that the resource provides capability org.wildfly.foo.bar. > 3) The kernel records in the capability registry that org.wildfly.foo.bar is now "reload-required". > 4) Thereafter, for any op that changes the model and then adds a runtime step, the kernel: > a) finds the registration for the resource type associated with that op's target address > b) finds any capabilities provided by the resource type > c) looks for direct or transitive requirements for those capabilites that are "reload-required" > d) if found, the runtime step is not executed, and instead the "server-requires-reload" response-header is added. > The effect here is the granularity of what ops have their runtime changes skipped is reduced to those associated with capabilities that put the server into reload-required. Unrelated ops, e.g. the logging changes mentioned above, are unaffected. > Some fine points: > 1) The restart-required and reload-required states need to be tracked separately. The information regarding any restart-required capabilities needs to survive a reload. > 2) The information that a capability is reload/restart-required needs to survive the removal of the capability. This allows the remove+add scenario to work. The remove op removes the capability, but the fact it is still present in the runtime is tracked, so when the add comes in no runtime changes are made. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6437) Undertow listener max-post-size attribute default value discrepancy

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6437?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-3986 to WFLY-6437: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6437 (was: JBEAP-3986) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER7) > Undertow listener max-post-size attribute default value discrepancy > ------------------------------------------------------------------- > > Key: WFLY-6437 > URL: https://issues.jboss.org/browse/WFLY-6437 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > There is a discrepancy in undertow schema definition of listener attribute 'max-post-size' [default value here|https://github.com/jbossas/jboss-eap7/blob/EAP_7.0.0.ER7-dev/underto...] and [ListenerResourceDefinition here|https://github.com/jbossas/jboss-eap7/blob/EAP_7.0.0.ER7-dev/underto...]. > These two default values should be unified so they match. > NOTE: I set GA as a target release as this is probably trivial change in Undertow schema definition which is better to do before GA as after that any change into schema is difficult. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1453) module patched in a one-off not included in the next cp is not port-forwarded from the prev cp

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFCORE-1453: ----------------------------------------- Summary: module patched in a one-off not included in the next cp is not port-forwarded from the prev cp Key: WFCORE-1453 URL: https://issues.jboss.org/browse/WFCORE-1453 Project: WildFly Core Issue Type: Bug Components: Patching Affects Versions: 2.1.0.Final Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky If CP1 patches module M, a one-off patch later patches the same module M and the following CP2 does not include M at all, module M will not be port-forwarded from CP1. M will be loaded from the original base instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 March 2016