June 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1594) Domain Management logout 'feature' not working for HTTP BASIC authentication.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1594: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> made a comment on [bug 976917|https://bugzilla.redhat.com/show_bug.cgi?id=976917] Sure, feel free to take both issues and I can review what you have. > Domain Management logout 'feature' not working for HTTP BASIC authentication. > ----------------------------------------------------------------------------- > > Key: WFLY-1594 > URL: https://issues.jboss.org/browse/WFLY-1594 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha3 > > > The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-182) Timed rules can disrupt other activations as they are being fired

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-182: ------------------------------------- Summary: Timed rules can disrupt other activations as they are being fired Key: DROOLS-182 URL: https://issues.jboss.org/browse/DROOLS-182 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Beta3, 5.5.1.Final Reporter: Davide Sottara Assignee: Mark Proctor Priority: Blocker Timer-driven rules are executed by separated thread. One such thread may retract a fact which is being used by the (main) thread in a rule being fired. This preemption will lead to a NPE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1594) Domain Management logout 'feature' not working for HTTP BASIC authentication.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1594: ----------------------------------------------- Jesse Sightler <jsightle(a)redhat.com> made a comment on [bug 976917|https://bugzilla.redhat.com/show_bug.cgi?id=976917] I see... I would be happy to continue working on this as the assignee. At the time, I thought the changes in the PR were adequate but further testing has shown issues in Chrome. Would you be able to assist with reviewing patches here? I think I have an algorithm that works, but it will need more testing and review. I had initially started with the EAP branch, as I had (incorrectly) assumed that the Wildfly code in this area had diverged dramatically. It looks like it is actually very similar, so I will start sending PRs to it instead. > Domain Management logout 'feature' not working for HTTP BASIC authentication. > ----------------------------------------------------------------------------- > > Key: WFLY-1594 > URL: https://issues.jboss.org/browse/WFLY-1594 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha3 > > > The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1606) Refactor wildfly-clustering-api/wildfly-clustering-impl modules

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-1606: ---------------------------------- Summary: Refactor wildfly-clustering-api/wildfly-clustering-impl modules Key: WFLY-1606 URL: https://issues.jboss.org/browse/WFLY-1606 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 8.0.0.Alpha2 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 8.0.0.Alpha3 The goal is to create a single publicly exported clustering module, with a refined, stable public API. The current wildfly-clustering-api module is too cluttered. Once the api module is cleaned up, we can merge it with the current wildfly-clustering-annotations module - which does not need to be separate. We should also clean up the wildfly-clustering-impl module. CoreGroupCommunicationService needs to be overhauled, and split into smaller, light-weight components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1605) Jackson type info is lost in a GET request returning a collection of objects

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1605?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-1605: --------------------------------- Assignee: Bill Burke (was: Stuart Douglas) > Jackson type info is lost in a GET request returning a collection of objects > ---------------------------------------------------------------------------- > > Key: WFLY-1605 > URL: https://issues.jboss.org/browse/WFLY-1605 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.0.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Bill Burke > Attachments: testcase-WFLY-1605.zip > > > I'm having a simple class hierarchy: an abstract class AbstractCustomer and 2 derived concrete classes. > 1) When the GET request's method directly returns a list of objects of AbstractCustomer, then the mapping information is available (as defined with @JsonTypeInfo and @JsonSubTypes) > 2) However, when the GET request's method returns a Response object encapsulating the same list (plus a link header), then the mapping information isn't sent to the client. > I'll attach a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1605) Jackson type info is lost in a GET request returning a collection of objects

by Juergen Zimmermann (JIRA)

[ https://issues.jboss.org/browse/WFLY-1605?page=com.atlassian.jira.plugin.... ] Juergen Zimmermann updated WFLY-1605: ------------------------------------- Attachment: testcase-WFLY-1605.zip The test class contains 2 test methods 1) The method "failure" tests the URL according to a GET method which returns a Response object (containing a list of objects) and fails because of the lost type info 2) The method "success" tests the URL according to a GET method which directly returns a list of objects > Jackson type info is lost in a GET request returning a collection of objects > ---------------------------------------------------------------------------- > > Key: WFLY-1605 > URL: https://issues.jboss.org/browse/WFLY-1605 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.0.0.Alpha2 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > Attachments: testcase-WFLY-1605.zip > > > I'm having a simple class hierarchy: an abstract class AbstractCustomer and 2 derived concrete classes. > 1) When the GET request's method directly returns a list of objects of AbstractCustomer, then the mapping information is available (as defined with @JsonTypeInfo and @JsonSubTypes) > 2) However, when the GET request's method returns a Response object encapsulating the same list (plus a link header), then the mapping information isn't sent to the client. > I'll attach a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1573) Extension observer method doesn't get invoked if meta-annotations are given as a filter via @WithAnnotations

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-1573?page=com.atlassian.jira.plugin.... ] Jozef Hartinger updated WFLY-1573: ---------------------------------- Fix Version/s: 8.0.0.Alpha3 > Extension observer method doesn't get invoked if meta-annotations are given as a filter via @WithAnnotations > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-1573 > URL: https://issues.jboss.org/browse/WFLY-1573 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.0.0.Alpha1 > Reporter: Farah Juma > Assignee: Jozef Hartinger > Fix For: 8.0.0.Alpha3 > > > An extension observer method with meta-annotations given as a filter via @WithAnnotations only gets invoked if the annotation classes that contain the meta-annotations are added to the deployment. The problem is that if an annotation isn't part of the deployment, it's not part of the deployment Jandex index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1605) Jackson type info is lost in a GET request returning a collection of objects

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-1605: ---------------------------------------- Summary: Jackson type info is lost in a GET request returning a collection of objects Key: WFLY-1605 URL: https://issues.jboss.org/browse/WFLY-1605 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 8.0.0.Alpha2 Reporter: Juergen Zimmermann Assignee: Stuart Douglas I'm having a simple class hierarchy: an abstract class AbstractCustomer and 2 derived concrete classes. 1) When the GET request's method directly returns a list of objects of AbstractCustomer, then the mapping information is available (as defined with @JsonTypeInfo and @JsonSubTypes) 2) However, when the GET request's method returns a Response object encapsulating the same list (plus a link header), then the mapping information isn't sent to the client. I'll attach a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1634) LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1634?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1634: -------------------------------- 3.3.2 has been released > LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken > -------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-1634 > URL: https://issues.jboss.org/browse/JGRP-1634 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3 > Environment: JGroups 3.3.0 Final > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Fix For: 3.4 > > Attachments: AbstractJdkLockManager.java, DistributedJGroupsLockManager.java, jgroups.xml, LockingTest.java > > > We upgraded from 3.3.0.CR1 to 3.3.0.Final and began to experience all sorts of weird lock acquisition issues. The symptoms are: > (a) tryLock() randomly hangs > (b) tryLock(timeout) times out, without acquiring the lock (even though it should, as the lock is only requested from a single node) > This happens both with CENTRAL_LOCK as well as PEER_LOCK. I have attached the configuration we are using. > 3.3.0.CR1 worked fine. This bug seems to have been introduced by JGRP-1610. I have carefully reviewed the code changes introduced by said fix, and they seems to be: > (i) OOB used for lock messages. This should not be causing problems. > (ii) Use of a striped ReentrantLock table instead of synchronized blocks. By itself, this change alone should not be causing problems. > (iii) Much, much more tightening locking around the server lock table. I think this is where something goes wrong, and deadlocks end up occuring. > The following methods on Locking.java did not even have a synchronized block before, and now they are protected with the striped ReentrantLocks: > - handleLockRequest() > - handleAwaitRequest() > - handleDeleteAwaitRequest() > - handleSignalRequest() > This is the major change I see which could introduce deadlocks. Other methods which were already synchronized before (handleCreateLockRequest, handleDeleteLockRequest, handleCreateAwaitingRequest, handleDeleteAwaitingRequest) now are stripe-locked, which should not be the cause of problems. > I would have liked to be able to indicate steps to reproduce, but it is quite random, although the bug is consistent enough that we can see it every single time we deploy our app. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1634) LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1634?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1634. ---------------------------- Resolution: Duplicate Issue JGRP-1639 > LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken > -------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-1634 > URL: https://issues.jboss.org/browse/JGRP-1634 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3 > Environment: JGroups 3.3.0 Final > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Fix For: 3.4 > > Attachments: AbstractJdkLockManager.java, DistributedJGroupsLockManager.java, jgroups.xml, LockingTest.java > > > We upgraded from 3.3.0.CR1 to 3.3.0.Final and began to experience all sorts of weird lock acquisition issues. The symptoms are: > (a) tryLock() randomly hangs > (b) tryLock(timeout) times out, without acquiring the lock (even though it should, as the lock is only requested from a single node) > This happens both with CENTRAL_LOCK as well as PEER_LOCK. I have attached the configuration we are using. > 3.3.0.CR1 worked fine. This bug seems to have been introduced by JGRP-1610. I have carefully reviewed the code changes introduced by said fix, and they seems to be: > (i) OOB used for lock messages. This should not be causing problems. > (ii) Use of a striped ReentrantLock table instead of synchronized blocks. By itself, this change alone should not be causing problems. > (iii) Much, much more tightening locking around the server lock table. I think this is where something goes wrong, and deadlocks end up occuring. > The following methods on Locking.java did not even have a synchronized block before, and now they are protected with the striped ReentrantLocks: > - handleLockRequest() > - handleAwaitRequest() > - handleDeleteAwaitRequest() > - handleSignalRequest() > This is the major change I see which could introduce deadlocks. Other methods which were already synchronized before (handleCreateLockRequest, handleDeleteLockRequest, handleCreateAwaitingRequest, handleDeleteAwaitingRequest) now are stripe-locked, which should not be the cause of problems. > I would have liked to be able to indicate steps to reproduce, but it is quite random, although the bug is consistent enough that we can see it every single time we deploy our app. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 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 June 2013