[JBoss JIRA] (JBASMP-80) PackageType doesn't ignore any types
by James Perkins (JIRA)
James Perkins created JBASMP-80:
-----------------------------------
Summary: PackageType doesn't ignore any types
Key: JBASMP-80
URL: https://issues.jboss.org/browse/JBASMP-80
Project: JBoss AS Maven Plugins
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The {{PackageType.isIgnored()}} always returns {{false}} even for pom and maven-plugin types. This should return {{true}} for these types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JBASMP-68) execute-commands does not work for module command
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.... ]
James Perkins closed JBASMP-68.
-------------------------------
Resolution: Won't Fix
I don't think this is going to be fixable for this plugin. It's fixed in the wildfly-maven-plugin and in WildFly Core as part of https://issues.jboss.org/browse/WFCORE-599.
> execute-commands does not work for module command
> -------------------------------------------------
>
> Key: JBASMP-68
> URL: https://issues.jboss.org/browse/JBASMP-68
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Affects Versions: 7.6.Final
> Reporter: Alfio Gloria
>
> I'm trying to remove a jboss module by means of maven.
> {code:xml}
> <configuration>
> <jbossHome>${project.build.directory}/server/jboss72</jbossHome>
> <execute-commands>
> <commands>
> <command>module remove --slot=main --name=system.layers.base.org.jboss.weld.core</command>
> </commands>
> </execute-commands>
> </configuration>
> {code}
> execute-commands fails with the following stack trace:
> {code}
> Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180)
> at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134)
> at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> ... 20 more
> Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set.
> at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176)
> ... 23 more
> {code}
> (tested with the last snapshot too)
> The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy.
> There are some points of confusion:
> # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
> # usually there are more than one installation or jboss-as-maven-plugin can download the server;
> # jbossHome config parameter is not take into account;
> # what if I want to make operations on more the one server at the same time?
> At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-558) Introduce generalized support for authentication timeout of mechanisms
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-558?page=com.atlassian.jira.plugin.sy... ]
Farah Juma reassigned ELY-558:
------------------------------
Assignee: Farah Juma
> Introduce generalized support for authentication timeout of mechanisms
> ----------------------------------------------------------------------
>
> Key: ELY-558
> URL: https://issues.jboss.org/browse/ELY-558
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Mechanisms, Utils
> Reporter: David Lloyd
> Assignee: Farah Juma
> Fix For: 1.1.0.Beta6
>
>
> Paraphrasing from HipChat discussion.
> Generic mechanism wrappers for handling authentication timeout will not only support OTP-style credential read-modify-write authentication mechanisms, but generally avoid certain DoS conditions and failure states that would be associated with long locking of credentials (even in the read case).
> This issue is to implement a wrapping mechanism factory (for at least SASL and possibly HTTP as well, eventually) which supports authentication timeout by judicious usage of concurrency primitives and timed executors. It is important to guarantee thread-safe access to the underlying mechanism, which are generally concurrency-unsafe.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-558) Introduce generalized support for authentication timeout of mechanisms
by David Lloyd (JIRA)
David Lloyd created ELY-558:
-------------------------------
Summary: Introduce generalized support for authentication timeout of mechanisms
Key: ELY-558
URL: https://issues.jboss.org/browse/ELY-558
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Mechanisms, Utils
Reporter: David Lloyd
Fix For: 1.1.0.Beta6
Paraphrasing from HipChat discussion.
Generic mechanism wrappers for handling authentication timeout will not only support OTP-style credential read-modify-write authentication mechanisms, but generally avoid certain DoS conditions and failure states that would be associated with long locking of credentials (even in the read case).
This issue is to implement a wrapping mechanism factory (for at least SASL and possibly HTTP as well, eventually) which supports authentication timeout by judicious usage of concurrency primitives and timed executors. It is important to guarantee thread-safe access to the underlying mechanism, which are generally concurrency-unsafe.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ELY-557) Introduce bearer token credential type
by David Lloyd (JIRA)
David Lloyd created ELY-557:
-------------------------------
Summary: Introduce bearer token credential type
Key: ELY-557
URL: https://issues.jboss.org/browse/ELY-557
Project: WildFly Elytron
Issue Type: Task
Components: API / SPI, Authentication Mechanisms
Reporter: David Lloyd
Priority: Minor
Fix For: 1.1.0.Beta6
Right now we have a special callback for bearer tokens. Instead of having BearerTokenCallback we should have a BearerTokenCredential type, and use CredentialCallback instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-644:
------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1212634|https://bugzilla.redhat.com/show_bug.cgi?id=1212634] from ASSIGNED to NEW
> jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-644
> URL: https://issues.jboss.org/browse/WFCORE-644
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Derek Horton
> Assignee: Alexey Loubyansky
>
> The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file.
> This is problematic when the JVM is running in FIPS mode.
> The cli throws the following exception on startup:
> $ ./bin/jboss-cli.sh
> org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89)
> at javax.net.ssl.SSLContext.init(SSLContext.java:283)
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537)
> ... 11 more
> It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file:
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2073?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2073.
----------------------------
Resolution: Done
Fixed and backported to 3.6.10
> RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
> -----------------------------------------------------------------------------
>
> Key: JGRP-2073
> URL: https://issues.jboss.org/browse/JGRP-2073
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4.3, 3.5, 3.6, 3.6.8, 3.6.9
> Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
> Reporter: Roman Fischer
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
> At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
> if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
> So i have seen it is planned to remove NAKACK in the Future - i create this issue.
> Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2073?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2073:
--------------------------------
The problem is an incorrect implementation of {{up(MessageBatch)}} in {{RELAY}}. Will fix this shortly.
> RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
> -----------------------------------------------------------------------------
>
> Key: JGRP-2073
> URL: https://issues.jboss.org/browse/JGRP-2073
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4.3, 3.5, 3.6, 3.6.8, 3.6.9
> Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
> Reporter: Roman Fischer
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
> At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
> if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
> So i have seen it is planned to remove NAKACK in the Future - i create this issue.
> Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2073?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2073:
---------------------------
Fix Version/s: 3.6.10
> RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
> -----------------------------------------------------------------------------
>
> Key: JGRP-2073
> URL: https://issues.jboss.org/browse/JGRP-2073
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4.3, 3.5, 3.6, 3.6.8, 3.6.9
> Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
> Reporter: Roman Fischer
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
> At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
> if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
> So i have seen it is planned to remove NAKACK in the Future - i create this issue.
> Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months