[JBoss JIRA] (WFLY-4846) Unable to create vault
by Sören Dierkes (JIRA)
[ https://issues.jboss.org/browse/WFLY-4846?page=com.atlassian.jira.plugin.... ]
Sören Dierkes commented on WFLY-4846:
-------------------------------------
I found a "resolution". If the storepass is EQUAL to the keypass it works.
But I guess it ist he wrong place anyways and can be closed/moved.
> Unable to create vault
> ----------------------
>
> Key: WFLY-4846
> URL: https://issues.jboss.org/browse/WFLY-4846
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.CR2
> Reporter: Sören Dierkes
> Assignee: Darran Lofthouse
>
> I was unable to create a vault with the current release.
> The last version I've tried and which works was 8.2.0 with Java 8
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFCORE-784) [PATCH] fix 2 bugs in bin/standalone.sh
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-784?page=com.atlassian.jira.plugin... ]
Tomaz Cerar moved WFLY-4297 to WFCORE-784:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-784 (was: WFLY-4297)
Component/s: Scripts
(was: Scripts)
> [PATCH] fix 2 bugs in bin/standalone.sh
> ---------------------------------------
>
> Key: WFCORE-784
> URL: https://issues.jboss.org/browse/WFCORE-784
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Martin Petricek
> Assignee: Tomaz Cerar
> Attachments: bin-fix.patch
>
>
> bin/standalone.sh does not use "shift" correctly when parsing commandline option, failing with "bin/standalone.sh: 34: shift: can't shift that many" if "--debug" without a parameter is used on dash (default shell in debian)
> Second issue is that the script does not handle correctly situation when CDPATH environment variable is set, failing completely.
> Attaching patch that fixes both these issues.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ELY-218) Logical RoleMapper Implementation(s)
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-218?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-218.
-----------------------------
Resolution: Done
> Logical RoleMapper Implementation(s)
> ------------------------------------
>
> Key: ELY-218
> URL: https://issues.jboss.org/browse/ELY-218
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha2
>
>
> In addition to the current role mapper implementation it would be useful to have implementation(s) that can handle logical operations i.e. and, or, xor.
> Not sure at this point if it makes sense for this to be single implementations or a single mapper that can be provided a set of operations to perform.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4846) Unable to create vault
by Sören Dierkes (JIRA)
[ https://issues.jboss.org/browse/WFLY-4846?page=com.atlassian.jira.plugin.... ]
Sören Dierkes updated WFLY-4846:
--------------------------------
Description:
I was unable to create a vault with the current release.
The last version I've tried and which works was 8.2.0 with Java 8
was:
I was unable to create a vault with the current release.
The last version I've tried and which works was 8.2.0.
> Unable to create vault
> ----------------------
>
> Key: WFLY-4846
> URL: https://issues.jboss.org/browse/WFLY-4846
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.CR2
> Reporter: Sören Dierkes
> Assignee: Darran Lofthouse
>
> I was unable to create a vault with the current release.
> The last version I've tried and which works was 8.2.0 with Java 8
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4846) Unable to create vault
by Sören Dierkes (JIRA)
Sören Dierkes created WFLY-4846:
-----------------------------------
Summary: Unable to create vault
Key: WFLY-4846
URL: https://issues.jboss.org/browse/WFLY-4846
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 9.0.0.CR2
Reporter: Sören Dierkes
Assignee: Darran Lofthouse
I was unable to create a vault with the current release.
The last version I've tried and which works was 8.2.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-2885) HttpListenerService start doesn't clean up if start fails
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2885?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2885:
------------------------------
Fix Version/s: 10.0.0.Alpha5
> HttpListenerService start doesn't clean up if start fails
> ---------------------------------------------------------
>
> Key: WFLY-2885
> URL: https://issues.jboss.org/browse/WFLY-2885
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 10.0.0.Alpha5
>
>
> HttpListenerService.prestart() does some registration stuff that doesn't get cleaned up if start() fails later on.
> I noticed this in the logs while debugging RolloutPlanTestCase failures on JDK8. Probably unrelated to those failures; just an FYI to give context.
> What happens in the test is it does an http-listener=xxx:add that is deliberately meant to fail in Stage.RUNTIME (due to a port conflict.) Later on the test does the same thing again. It's meant to fail there too, but I noticed in the logs that it failed for the *wrong reason*, before the port conflict:
> {code}
> [Server:main-one] 10:13:44,128 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.undertow.listener.maxFailOnePlan: org.jboss.msc.service.StartException in service jboss.undertow.listener.maxFailOnePlan: Failed to start service
> [Server:main-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> [Server:main-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> [Server:main-one] Caused by: java.lang.IllegalArgumentException: UT000053: Listener maxFailOnePlan already registered
> [Server:main-one] at io.undertow.server.ListenerRegistry.addListener(ListenerRegistry.java:32) [undertow-core-1.0.0.CR5.jar:1.0.0.CR5]
> [Server:main-one] at org.wildfly.extension.undertow.HttpListenerService.preStart(HttpListenerService.java:107)
> [Server:main-one] at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:121)
> [Server:main-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:main-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:main-one] ... 3 more
> {code}
> The error ^^^ will continue to happen until the server is restarted, even if the port conflict situation was fixed. It's because the ListenerRegistry.addListener call from the first attempt was never cleaned up.
> Cleaning up would have to be done in a catch block in ListenerService.start(). The code in stop() that normally does the cleanup does not get called if service start has failed.
> I expect we have this kind of problem in many places in the WF code.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4845) jboss-client.jar use jms 2.0 specification from geronimo-jms
by Martin Styk (JIRA)
Martin Styk created WFLY-4845:
---------------------------------
Summary: jboss-client.jar use jms 2.0 specification from geronimo-jms
Key: WFLY-4845
URL: https://issues.jboss.org/browse/WFLY-4845
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Martin Styk
Assignee: Jeff Mesnil
jboss-client.jar uses jms 2.0 specification from geronimo-jms_2.0_spec not from jboss-jms-api_2.0_spec. As EAP 7.0.0.DR5 uses jboss specs, we should use it in the client jar as well.
There is also issue in geronimo-jms_2.0_spec :
public @interface JMSDestinationDefinitions {
public JMSConnectionFactoryDefinition[] value();
}
This should contain public JMSDestinationDefinition[] value(); instead of public JMSConnectionFactoryDefinition[] value();
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-3564) Remove support for mixed-domain transforming to < 7.3.0 versions
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3564?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3564.
-------------------------------
Fix Version/s: 9.0.0.Final
10.0.0.Alpha4
Resolution: Done
Most of this work was one some time ago.
As result of this we no longer run any transformers tests that target older versions.
Tests & transformers itself ware not touched as part of this task
> Remove support for mixed-domain transforming to < 7.3.0 versions
> ----------------------------------------------------------------
>
> Key: WFLY-3564
> URL: https://issues.jboss.org/browse/WFLY-3564
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
> We will not support WF 9 mixed domains with slaves running releases prior to 7.3 / EAP 6.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
> KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months