[JBoss JIRA] (WFLY-8186) CS tool, can't list --help without NPE occurence
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8186?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-8186:
-------------------------------
Description:
{code}
java -jar wildfly-elytron-tool.jar credential-store -h
{code}
or because of WFLY-8176
{code}
java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230
{code}
leads to
{code}
usage: java -jar wildfly-elytron-tool.jar credential-store <sub-command>
<options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c] [-f] [-i
<arg>] [-l <arg>] [-p <arg>] [-s <arg>] [-t <arg>] [-u <arg>] [-x
<arg>]
Exception in thread "main" java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
at java.util.regex.Matcher.reset(Matcher.java:309)
at java.util.regex.Matcher.<init>(Matcher.java:229)
at java.util.regex.Pattern.matcher(Pattern.java:1093)
at java.util.Formatter.parse(Formatter.java:2547)
at java.util.Formatter.format(Formatter.java:2501)
at java.io.PrintStream.format(PrintStream.java:970)
at java.io.PrintStream.printf(PrintStream.java:871)
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58)
{code}
was:
{code}
java -jar wildfly-elytron-tool.jar credential-store -h
{code}
or because of JBEAP-8996
{code}
java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230
{code}
leads to
{code}
usage: java -jar wildfly-elytron-tool.jar credential-store <sub-command>
<options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c] [-f] [-i
<arg>] [-l <arg>] [-p <arg>] [-s <arg>] [-t <arg>] [-u <arg>] [-x
<arg>]
Exception in thread "main" java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
at java.util.regex.Matcher.reset(Matcher.java:309)
at java.util.regex.Matcher.<init>(Matcher.java:229)
at java.util.regex.Pattern.matcher(Pattern.java:1093)
at java.util.Formatter.parse(Formatter.java:2547)
at java.util.Formatter.format(Formatter.java:2501)
at java.io.PrintStream.format(PrintStream.java:970)
at java.io.PrintStream.printf(PrintStream.java:871)
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58)
{code}
> CS tool, can't list --help without NPE occurence
> ------------------------------------------------
>
> Key: WFLY-8186
> URL: https://issues.jboss.org/browse/WFLY-8186
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
>
> {code}
> java -jar wildfly-elytron-tool.jar credential-store -h
> {code}
> or because of WFLY-8176
> {code}
> java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230
> {code}
> leads to
> {code}
> usage: java -jar wildfly-elytron-tool.jar credential-store <sub-command>
> <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c] [-f] [-i
> <arg>] [-l <arg>] [-p <arg>] [-s <arg>] [-t <arg>] [-u <arg>] [-x
> <arg>]
> Exception in thread "main" java.lang.NullPointerException
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> at java.util.regex.Matcher.reset(Matcher.java:309)
> at java.util.regex.Matcher.<init>(Matcher.java:229)
> at java.util.regex.Pattern.matcher(Pattern.java:1093)
> at java.util.Formatter.parse(Formatter.java:2547)
> at java.util.Formatter.format(Formatter.java:2501)
> at java.io.PrintStream.format(PrintStream.java:970)
> at java.io.PrintStream.printf(PrintStream.java:871)
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8186) CS tool, can't list --help without NPE occurence
by Martin Choma (JIRA)
Martin Choma created WFLY-8186:
----------------------------------
Summary: CS tool, can't list --help without NPE occurence
Key: WFLY-8186
URL: https://issues.jboss.org/browse/WFLY-8186
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Critical
{code}
java -jar wildfly-elytron-tool.jar credential-store -h
{code}
or because of JBEAP-8996
{code}
java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230
{code}
leads to
{code}
usage: java -jar wildfly-elytron-tool.jar credential-store <sub-command>
<options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c] [-f] [-i
<arg>] [-l <arg>] [-p <arg>] [-s <arg>] [-t <arg>] [-u <arg>] [-x
<arg>]
Exception in thread "main" java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
at java.util.regex.Matcher.reset(Matcher.java:309)
at java.util.regex.Matcher.<init>(Matcher.java:229)
at java.util.regex.Pattern.matcher(Pattern.java:1093)
at java.util.Formatter.parse(Formatter.java:2547)
at java.util.Formatter.format(Formatter.java:2501)
at java.io.PrintStream.format(PrintStream.java:970)
at java.io.PrintStream.printf(PrintStream.java:871)
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8185) Introduce credential-store.sh
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8185?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-8185:
-------------------------------
Labels: credential-store user_experience (was: credential-store)
> Introduce credential-store.sh
> -----------------------------
>
> Key: WFLY-8185
> URL: https://issues.jboss.org/browse/WFLY-8185
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: credential-store, user_experience
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8185) Introduce credential-store.sh
by Martin Choma (JIRA)
Martin Choma created WFLY-8185:
----------------------------------
Summary: Introduce credential-store.sh
Key: WFLY-8185
URL: https://issues.jboss.org/browse/WFLY-8185
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Currently there is just delivered wildfly-elytron-tool.jar in ${EAP_HOME}/bin folder. I think for convenience it would be better if it will contain also credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
- It saves space on command line ;)
- It is analogous to vault.sh - so obvious when looking for credential store tool
- With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
- Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8185) Introduce credential-store.sh
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8185?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-8185:
-------------------------------
Description:
Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
- It saves space on command line
- It is analogous to vault.sh - so obvious when looking for credential store tool
- With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
- Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user
was:
Currently there is just delivered wildfly-elytron-tool.jar in ${EAP_HOME}/bin folder. I think for convenience it would be better if it will contain also credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
- It saves space on command line ;)
- It is analogous to vault.sh - so obvious when looking for credential store tool
- With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
- Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user
> Introduce credential-store.sh
> -----------------------------
>
> Key: WFLY-8185
> URL: https://issues.jboss.org/browse/WFLY-8185
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: credential-store
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8184) Singleton deployment not stopped on the previous singleton provider after new provider is elected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8184?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-9010 to WFLY-8184:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8184 (was: JBEAP-9010)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: (was: 7.1.0.DR8)
(was: 7.1.0.DR9)
(was: 7.1.0.DR10)
(was: 7.1.0.DR11)
Affects Testing: (was: Regression)
> Singleton deployment not stopped on the previous singleton provider after new provider is elected
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-8184
> URL: https://issues.jboss.org/browse/WFLY-8184
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> Scenario: failover clustering test with singleton deployment.
> {code:xml|title=Singleton subsystem configuration}
> <subsystem xmlns="urn:jboss:domain:singleton:1.0">
> <singleton-policies default="default">
> <singleton-policy name="default" cache-container="server">
> <random-election-policy/>
> </singleton-policy>
> </singleton-policies>
> </subsystem>
> {code}
> Nodes startup order: node1, node2, node3, node4.
> During node1 startup, this server is elected as the singleton provider and deploys singleton deployment. During other servers startup, some other node (usually node2) is elected as the singleton provider and deploys singleton deployment. However, node1 has the singleton deployment still deployed, so there are *2 nodes* effectively providing a singleton deployment.
> Deployment used: [clusterbench-ee7-singleton-jbossall.ear|http://jenkins.mw.lab.eng.bos.red...]
> Standard clusterbench application with modified jboss-all.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss xmlns="urn:jboss:1.0">
> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
> </jboss>
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8183) Anonymous Elytron SASL authentication fails for JMS
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8183:
---------------------------------
Summary: Anonymous Elytron SASL authentication fails for JMS
Key: WFLY-8183
URL: https://issues.jboss.org/browse/WFLY-8183
Project: WildFly
Issue Type: Bug
Components: JMS, Security
Reporter: Josef Cacek
Assignee: Jeff Mesnil
Priority: Blocker
Anonymous JMS client access is not possible with Elytron.
When the ANONYMOUS SASL mechanism is configured, then creating A-MQ session fails with:
{code}
22:06:26,119 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: java.lang.IllegalArgumentException: Parameter 'guess' may not be null
at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:70)
at org.wildfly.common.Assert.checkNotNullParam(Assert.java:48)
at org.wildfly.security.evidence.PasswordGuessEvidence.<init>(PasswordGuessEvidence.java:40)
at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:87)
at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62)
at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132)
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:627)
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months