[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[JBoss JIRA] (JBAS-9544) Add sun.security.action package export to sun.jdk module
by Tomas Gustavsson (JIRA)
Tomas Gustavsson created JBAS-9544:
--------------------------------------
Summary: Add sun.security.action package export to sun.jdk module
Key: JBAS-9544
URL: https://issues.jboss.org/browse/JBAS-9544
Project: Application Server 3 4 5 and 6
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0
Reporter: Tomas Gustavsson
An application that uses a simple:
System.getProperty("line.separator");
gets a stacktrace during startup:
{quote}
0m[31m11:38:22,418 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/ejbca/cmp-tcp]] (ServerService Thread Pool -- 64) JBWEB000289: Servlet CmpTcpInitServlet threw load() exception: java.lang.ClassNotFoundException: sun.security.action.GetPropertyAction
{quote}
The simple solution is to export sun/security/action in modules/system/layers/base/sun/jdk/main/module.xml. Simply add:
{code}<path name="sun/security/action"/>{code}
--
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
10 years, 10 months