September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-901) Align spring version with the eap fuse layer spring version

by David virgil naranjo (JIRA)

David virgil naranjo created DROOLS-901: ------------------------------------------- Summary: Align spring version with the eap fuse layer spring version Key: DROOLS-901 URL: https://issues.jboss.org/browse/DROOLS-901 Project: Drools Issue Type: Enhancement Affects Versions: 6.3.0.Final Reporter: David virgil naranjo Assignee: Mark Proctor Right now on drools it is used spring 3, while on the eap fuse layer it is used the version 4.1.6.RELEASE. It wouldb e good to have the same version, because in that case some of the fuse-bxms-integ quickstarts could be deployed on eap. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-901) Align spring version with the eap fuse layer spring version

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/DROOLS-901?page=com.atlassian.jira.plugin... ] David virgil naranjo reassigned DROOLS-901: ------------------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Align spring version with the eap fuse layer spring version > ----------------------------------------------------------- > > Key: DROOLS-901 > URL: https://issues.jboss.org/browse/DROOLS-901 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.3.0.Final > Reporter: David virgil naranjo > Assignee: Mario Fusco > > Right now on drools it is used spring 3, while on the eap fuse layer it is used the version 4.1.6.RELEASE. > It wouldb e good to have the same version, because in that case some of the fuse-bxms-integ quickstarts could be deployed on eap. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-890) Thread deadlock issue in class ProjectClassLoader.java

by Vivek Hingorani (JIRA)

[ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin... ] Vivek Hingorani reopened DROOLS-890: ------------------------------------ Did the patch locally in drools-core 6.2.0.Final jar but issue still exists. Not sure if patch was right and hence requesting to patch in drools 6.2.0.Final please > Thread deadlock issue in class ProjectClassLoader.java > ------------------------------------------------------- > > Key: DROOLS-890 > URL: https://issues.jboss.org/browse/DROOLS-890 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.1.0.Final > Reporter: Vivek Hingorani > Assignee: Mario Fusco > Fix For: 6.3.0.Final > > > In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is > at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284) > Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-890) Thread deadlock issue in class ProjectClassLoader.java

by Vivek Hingorani (JIRA)

[ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin... ] Vivek Hingorani commented on DROOLS-890: ---------------------------------------- Thanks a lot Mario for the fix. I checked the drools.org site and still can't see Drools 6.3.0.Final. Also we tried to reproduce the issue with Drools 6.2.0.Final and the same issue is there with drools 6.2.0.Final as well. Can you please provide the same patch on Drools6.2.0.Final as we would be using Drools 6.2.0.Final only in our project. > Thread deadlock issue in class ProjectClassLoader.java > ------------------------------------------------------- > > Key: DROOLS-890 > URL: https://issues.jboss.org/browse/DROOLS-890 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.1.0.Final > Reporter: Vivek Hingorani > Assignee: Mario Fusco > Fix For: 6.3.0.Final > > > In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is > at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284) > Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5225) Server is not responding after attempt to set parent of profile to non-existent profile

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFLY-5225?page=com.atlassian.jira.plugin.... ] Marek Kopecký commented on WFLY-5225: ------------------------------------- [~kabirkhan]: this issue is still valid for Wildfly master (it use WF-Core 2.0.0.Beta5). Do you have time estimation for this issue? > Server is not responding after attempt to set parent of profile to non-existent profile > --------------------------------------------------------------------------------------- > > Key: WFLY-5225 > URL: https://issues.jboss.org/browse/WFLY-5225 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Beta2 > Reporter: Marek Kopecký > Assignee: Kabir Khan > Priority: Critical > > *Description of problem:* > Server is not responding after attempt to set parent of profile to non-existent profile. > Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group. > This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue. > Priority of this jira tends to be critical. > *How reproducible:* > Always > *Steps to Reproduce (profile):* > # Get fresh EAP > # ./domain.sh > # ./jboss-cli.sh > ## /profile=new:add() > ## /profile=new:write-attribute(name=includes,value=\[nonsence\]) > ## /profile=new:remove > *Actual results:* > {noformat} > [domain@localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence]) > { > "outcome" => "failed", > "failure-description" => "java.lang.NullPointerException:null" > } > [domain@localhost:9990 /] /profile=new:remove > {noformat} > * server needs to be restarted > *Expected results:* > {noformat} > [domain@localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence]) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available: > org.wildfly.domain.profile.nonsence in context 'profiles'"}, > "rolled-back" => true > } > [domain@localhost:9990 /] /profile=new:remove > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > {noformat} > *Steps to reproduce (socket-binding-group):* > # Get fresh EAP > # ./domain.sh > # ./jboss-cli.sh > ## /profile=new:add() > ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\]) > ## /profile=new:remove -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5225) Server is not responding after attempt to set parent of profile to non-existent profile

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFLY-5225?page=com.atlassian.jira.plugin.... ] Marek Kopecký updated WFLY-5225: -------------------------------- Priority: Critical (was: Major) > Server is not responding after attempt to set parent of profile to non-existent profile > --------------------------------------------------------------------------------------- > > Key: WFLY-5225 > URL: https://issues.jboss.org/browse/WFLY-5225 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Beta2 > Reporter: Marek Kopecký > Assignee: Kabir Khan > Priority: Critical > > *Description of problem:* > Server is not responding after attempt to set parent of profile to non-existent profile. > Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group. > This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue. > Priority of this jira tends to be critical. > *How reproducible:* > Always > *Steps to Reproduce (profile):* > # Get fresh EAP > # ./domain.sh > # ./jboss-cli.sh > ## /profile=new:add() > ## /profile=new:write-attribute(name=includes,value=\[nonsence\]) > ## /profile=new:remove > *Actual results:* > {noformat} > [domain@localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence]) > { > "outcome" => "failed", > "failure-description" => "java.lang.NullPointerException:null" > } > [domain@localhost:9990 /] /profile=new:remove > {noformat} > * server needs to be restarted > *Expected results:* > {noformat} > [domain@localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence]) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available: > org.wildfly.domain.profile.nonsence in context 'profiles'"}, > "rolled-back" => true > } > [domain@localhost:9990 /] /profile=new:remove > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > {noformat} > *Steps to reproduce (socket-binding-group):* > # Get fresh EAP > # ./domain.sh > # ./jboss-cli.sh > ## /profile=new:add() > ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\]) > ## /profile=new:remove -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-880) Return a success response but the rule seems to be not running.

by 재우 이 (JIRA)

[ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin... ] 재우 이 commented on DROOLS-880: ----------------------------- My environment is below CPU : Intel(R) Xeon(R) CPU E5-2650 RAM : 128Gb Linux Kernel : 2.6.32-431.el6.x86_64 Drools : 6.3.0.CR1 Rest Client : Soap UI WAS: Wildfly 8.1.0 Please, let me know your environment. If the problem is that in my environment, I want to know your environment. > Return a success response but the rule seems to be not running. > --------------------------------------------------------------- > > Key: DROOLS-880 > URL: https://issues.jboss.org/browse/DROOLS-880 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.3.0.CR1 > Environment: CPU : Intel(R) Xeon(R) CPU E5-2650 > RAM : 128Gb > Linux Kernel : 2.6.32-431.el6.x86_64 > Drools : 6.3.0.CR1 > Rest Client : Soap UI > Reporter: 재우 이 > Assignee: Edson Tirelli > Attachments: 2015_08_20_11_27_43_987.mp4, window-1.1.4.jar > > > Kie_server returns a success rest response status code, but nothing show up in my log file. > It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final") -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-882) Fix for SECURITY-868 breaks flush-cache capability

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-882?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-882: -------------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ASSIGNED to POST > Fix for SECURITY-868 breaks flush-cache capability > -------------------------------------------------- > > Key: SECURITY-882 > URL: https://issues.jboss.org/browse/SECURITY-882 > Project: PicketBox > Issue Type: Bug > Components: AS-Integration > Affects Versions: PicketBox_4_0_19.Final > Environment: EAP 6.3.3, JDV 6.1.0 > Reporter: Hisanobu Okuda > Assignee: Stefan Guilhen > > The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ASSIGNED to POST > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Final > > Attachments: stacktraces.log > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-888) Revert changes made in SECURITY-868

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-888?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-888: -------------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ASSIGNED to POST > Revert changes made in SECURITY-868 > ----------------------------------- > > Key: SECURITY-888 > URL: https://issues.jboss.org/browse/SECURITY-888 > Project: PicketBox > Issue Type: Task > Affects Versions: PicketBox_4_9_1.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_2.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 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 September 2015