[JBoss JIRA] (ELY-143) Revisit DigestPassword API and implementation
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-143:
------------------------------------
Summary: Revisit DigestPassword API and implementation
Key: ELY-143
URL: https://issues.jboss.org/browse/ELY-143
Project: WildFly Elytron
Issue Type: Task
Components: Passwords
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Alpha1
At the moment some mech specifics have leaked into the credential type e.g. nonce and nonceCount.
Move this to follow the same pattern as 'SaltedSimpleDigestPassword'.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4311) Wildfly patching 8.1 to 8.2 does not update jackson to 2.4.1
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4311?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4311:
---------------------------------
Assignee: Jason Greene (was: Stuart Douglas)
> Wildfly patching 8.1 to 8.2 does not update jackson to 2.4.1
> ------------------------------------------------------------
>
> Key: WFLY-4311
> URL: https://issues.jboss.org/browse/WFLY-4311
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Affects Versions: 8.2.0.Final
> Reporter: Christian Beutenmüller
> Assignee: Jason Greene
>
> Wildfly 8.2 final should update jackson-core, -annotation and -databind modules to 2.4.1, however when using the patch to upgrade an existing Wildfly 8.1 final to 8.2 the jackson libraries are not updated.
> Steps to reproduce:
> Download wildfly 8.1 distribution
> unzip
> Download wildfly 8.2 patch
> apply patch using jboss-cli
> check version in modules/system/layers/base/com/fasterxml/jackson/core/jackson-core/main
> It should be 2.4.1 but it is still 2.3.2.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4311) Wildfly patching 8.1 to 8.2 does not update jackson to 2.4.1
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4311?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-4311:
------------------------------
Component/s: Patching
(was: REST)
> Wildfly patching 8.1 to 8.2 does not update jackson to 2.4.1
> ------------------------------------------------------------
>
> Key: WFLY-4311
> URL: https://issues.jboss.org/browse/WFLY-4311
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Affects Versions: 8.2.0.Final
> Reporter: Christian Beutenmüller
> Assignee: Stuart Douglas
>
> Wildfly 8.2 final should update jackson-core, -annotation and -databind modules to 2.4.1, however when using the patch to upgrade an existing Wildfly 8.1 final to 8.2 the jackson libraries are not updated.
> Steps to reproduce:
> Download wildfly 8.1 distribution
> unzip
> Download wildfly 8.2 patch
> apply patch using jboss-cli
> check version in modules/system/layers/base/com/fasterxml/jackson/core/jackson-core/main
> It should be 2.4.1 but it is still 2.3.2.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4311) Wildfly patching 8.1 to 8.2 does not update jackson to 2.4.1
by Christian Beutenmüller (JIRA)
Christian Beutenmüller created WFLY-4311:
--------------------------------------------
Summary: Wildfly patching 8.1 to 8.2 does not update jackson to 2.4.1
Key: WFLY-4311
URL: https://issues.jboss.org/browse/WFLY-4311
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 8.2.0.Final
Reporter: Christian Beutenmüller
Assignee: Stuart Douglas
Wildfly 8.2 final should update jackson-core, -annotation and -databind modules to 2.4.1, however when using the patch to upgrade an existing Wildfly 8.1 final to 8.2 the jackson libraries are not updated.
Steps to reproduce:
Download wildfly 8.1 distribution
unzip
Download wildfly 8.2 patch
apply patch using jboss-cli
check version in modules/system/layers/base/com/fasterxml/jackson/core/jackson-core/main
It should be 2.4.1 but it is still 2.3.2.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2081) IronJacamarResourceCreator Throws ConcurrentModificationException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2081?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2081:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 981093|https://bugzilla.redhat.com/show_bug.cgi?id=981093] from NEW to ASSIGNED
> IronJacamarResourceCreator Throws ConcurrentModificationException
> -----------------------------------------------------------------
>
> Key: WFLY-2081
> URL: https://issues.jboss.org/browse/WFLY-2081
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
> Reporter: James Olsen
> Assignee: Stefano Maestri
>
> Recent wildfly-8.0.0.Beta1-SNAPSHOT (IronJacamar 1.1.0.Final) throws following error intermittently when there are multiple RARs in an EAR:
> 13:12:34,710 ERROR [org.jboss.msc.service] (MSC service thread 1-10) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@e7b3aee" failed: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_25]
> at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_25]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:335) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:350) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:145) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:244) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Older versions had a similar problem as detailed in JBJCA-933 (which also shows interleaving example with 3 RARs).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (ELY-142) A generic atomic reloadable KeyStore
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-142:
------------------------------------
Summary: A generic atomic reloadable KeyStore
Key: ELY-142
URL: https://issues.jboss.org/browse/ELY-142
Project: WildFly Elytron
Issue Type: Feature Request
Components: SSL
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Alpha1
Existing KeyStores can be re-initialised on demand, however this does not give us an option to roll back the change in the context of other management operations.
If we have a KeyStore implementation that internally creates a new KeyStore and returns a copy of the previous KeyStore we have something we can swap back in the event of a roll back.
This is intended to be used in environments where threading is controlled externally e.g. in the case of WildFly management ops the concurrency of management ops is controlled.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4310) Race condition registering resource adapters at startup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4310?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-4310:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1184610
> Race condition registering resource adapters at startup
> -------------------------------------------------------
>
> Key: WFLY-4310
> URL: https://issues.jboss.org/browse/WFLY-4310
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 9.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Upstream Jira of https://bugzilla.redhat.com/show_bug.cgi?id=1184610
> Please see bugzilla description for details and reproducer
> {noformat}
> Description of problem:
> During startup of JBoss, the following occurs randomly (not on every start):
> java.lang.IllegalStateException: JBAS014666: Duplicate resource resource-adapters
> Version-Release number of selected component (if applicable):
> jboss-as-connector-7.4.2.Final-redhat-2.jar:
> How reproducible:
> Random - it's a race condition but adding Byteman which slows execution (due to synchronous logging) of the code in which the race takes place seems to increase the frequency at which the failure occurs.
> Steps to Reproduce:
> 1. Copy a resource adapter archive to standalone/deployments
> 2. Configure the standalone.xml with two adapter configs specified (single RAR)
> 3. Start JBoss (a few restarts may be required as it doesn't always happen)
> Actual results:
> The server.log shows the exception below (and I suspect at least one of the adapter configs is not deployed - though I didn't confirm the latter).
> 12:40:44,463 ERROR [org.jboss.msc.service] (MSC service thread 1-12) MSC000002: Invocation of listener "org.jboss.as.connector.util.RaServicesFactory$1@5fc7026f" failed: java.lang.IllegalStateException: JBAS014666: Duplicate
> resource resource-adapters
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:225) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:122) [jboss-as-connector-7.4.2.Final-redhat-2.jar:7.4
> .2.Final-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1565) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:52) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2131) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
> Expected results:
> No exception should be raised
> Additional info:
> Document URL:
> Section Number and Name:
> Describe the issue:
> It appears that where there are multiple adapter configurations, registering of the adapters is done on different threads and sometimes two threads check to see if the resource-adapters "subsystem" (I think that is what is being created) exists ... it is possible for two threads to be told it doesn't exist - in which case both threads will try to create it.
> I think the code at issue is found in lines 120 and 122 of ./connector/src/main/java/org/jboss/as/connector/deployers/ra/processors/AbstractResourceAdapterDeploymentServiceListener.java
> At line 120, we check if the path exists ... and if it does not try to create it at line 122 ... but it possible that between the two lines one thread is executing, another thread may do the same - one will "win the race" and the other will fail with the exception.
> I did note that the entire block is wrapped in a synchronization block - synchronized on 'this' - so there must be multiple instances of the AbstractResourceAdapterDeploymentServiceListener class since the logging shows interleaved execution of the check and register calls across multiple threads.
> Suggestions for improvement:
> Additional information:
> Attached an archive containing a simple adapter (generated using the Ironjacamar generation tool), an excerpt of the standalone.xml configuration used as well as an excerpt of the log file and a byteman script used to produce the stack traces in the log excerpt.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4310) Race condition registering resource adapters at startup
by Chao Wang (JIRA)
Chao Wang created WFLY-4310:
-------------------------------
Summary: Race condition registering resource adapters at startup
Key: WFLY-4310
URL: https://issues.jboss.org/browse/WFLY-4310
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 9.0.0.Alpha1
Reporter: Chao Wang
Assignee: Chao Wang
Upstream Jira of https://bugzilla.redhat.com/show_bug.cgi?id=1184610
Please see bugzilla description for details and reproducer
{noformat}
Description of problem:
During startup of JBoss, the following occurs randomly (not on every start):
java.lang.IllegalStateException: JBAS014666: Duplicate resource resource-adapters
Version-Release number of selected component (if applicable):
jboss-as-connector-7.4.2.Final-redhat-2.jar:
How reproducible:
Random - it's a race condition but adding Byteman which slows execution (due to synchronous logging) of the code in which the race takes place seems to increase the frequency at which the failure occurs.
Steps to Reproduce:
1. Copy a resource adapter archive to standalone/deployments
2. Configure the standalone.xml with two adapter configs specified (single RAR)
3. Start JBoss (a few restarts may be required as it doesn't always happen)
Actual results:
The server.log shows the exception below (and I suspect at least one of the adapter configs is not deployed - though I didn't confirm the latter).
12:40:44,463 ERROR [org.jboss.msc.service] (MSC service thread 1-12) MSC000002: Invocation of listener "org.jboss.as.connector.util.RaServicesFactory$1@5fc7026f" failed: java.lang.IllegalStateException: JBAS014666: Duplicate
resource resource-adapters
at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:225) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:122) [jboss-as-connector-7.4.2.Final-redhat-2.jar:7.4
.2.Final-redhat-2]
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1565) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:52) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2131) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
Expected results:
No exception should be raised
Additional info:
Document URL:
Section Number and Name:
Describe the issue:
It appears that where there are multiple adapter configurations, registering of the adapters is done on different threads and sometimes two threads check to see if the resource-adapters "subsystem" (I think that is what is being created) exists ... it is possible for two threads to be told it doesn't exist - in which case both threads will try to create it.
I think the code at issue is found in lines 120 and 122 of ./connector/src/main/java/org/jboss/as/connector/deployers/ra/processors/AbstractResourceAdapterDeploymentServiceListener.java
At line 120, we check if the path exists ... and if it does not try to create it at line 122 ... but it possible that between the two lines one thread is executing, another thread may do the same - one will "win the race" and the other will fail with the exception.
I did note that the entire block is wrapped in a synchronization block - synchronized on 'this' - so there must be multiple instances of the AbstractResourceAdapterDeploymentServiceListener class since the logging shows interleaved execution of the check and register calls across multiple threads.
Suggestions for improvement:
Additional information:
Attached an archive containing a simple adapter (generated using the Ironjacamar generation tool), an excerpt of the standalone.xml configuration used as well as an excerpt of the log file and a byteman script used to produce the stack traces in the log excerpt.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months