[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
13 years
[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
13 years
[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
13 years
[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
13 years
[JBoss JIRA] (WFLY-789) HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-789?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-789:
----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 913117|https://bugzilla.redhat.com/show_bug.cgi?id=913117]
Moving this BZ to 6.2.0 as it changes the default behaviour of the server and introduces a new version of the schema of transaction subsystem. Because of these reasons it does not seem to belong to 6.1.1 release.
> HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-789
> URL: https://issues.jboss.org/browse/WFLY-789
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The issue cloned for upstream from an EAP6 bugzilla.
> original description:
> {quote}
> It seems that in case that of using hornetq for implementation of object store (configuration of transaction subsystem via <use-hornetq-store/> tag) the native library (AIO) is used automatically without necessity of user confirmation.
> For EAP 6.0.1 was decided that native library can't be used without explicit customer configuration request. Please check discussion on bug #900591.
> The NIO should be used until customer defined otherwise.
> The configuration option is missing in TM and after the adding it the EAP configuration should reflect fact that the default behaviour should be NIO.
> {quote}
--
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
13 years
[JBoss JIRA] (WFLY-1604) Include the realm name in the users.properties file
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-1604:
--------------------------------------
Summary: Include the realm name in the users.properties file
Key: WFLY-1604
URL: https://issues.jboss.org/browse/WFLY-1604
Project: WildFly
Issue Type: Enhancement
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 8.0.0.Alpha3
Continually prompting for the realm name within add-user.sh has caused problems as it gives the impression that this can be specified for each user added - however all the users within the file need to have the same realm otherwise the pre-prepared hashes will not be valid.
If there is no realm contained within a specially formatted comment then add-user.sh will prompt for the realm name as normal and will write the realm name to the file - if the comment is present add-user.sh will just use it without prompting.
If multiple properties files are found for adding a user and the realms do not match the update will fail with an appropriate error message.
--
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
13 years
[JBoss JIRA] (WFLY-218) Update add-user utility to allow overrides of property file name.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-218?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-218:
----------------------------------
Description:
This enhancement is going to add two additional command line options to the add-user utility: -
-up --user-properties
This will specify the file name of the properties file containing the users and passwords.
-gp --group-properties
This will specify the file name of the properties file containing the users groups.
If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
> Key: WFLY-218
> URL: https://issues.jboss.org/browse/WFLY-218
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.
--
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
13 years