[JBoss JIRA] (WFLY-3299) Outdated default app client configuration
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-3299:
-------------------------------------
Summary: Outdated default app client configuration
Key: WFLY-3299
URL: https://issues.jboss.org/browse/WFLY-3299
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Application Client, Build System
Reporter: Eduardo Martins
Assignee: Stuart Douglas
Priority: Blocker
Fix For: 8.1.0.Final
The app client xml configuration is outdated, most subsystems are not using latest version.
--
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
10 years, 3 months
[JBoss JIRA] (WFLY-3296) NullPointerException with JDK 1.8.0_05 on Windows
by Dino Tsoumakis (JIRA)
[ https://issues.jboss.org/browse/WFLY-3296?page=com.atlassian.jira.plugin.... ]
Dino Tsoumakis commented on WFLY-3296:
--------------------------------------
Yes, seems to be a JDK Problem. I will try to extract the essential part out of my code into a simple App.
> NullPointerException with JDK 1.8.0_05 on Windows
> -------------------------------------------------
>
> Key: WFLY-3296
> URL: https://issues.jboss.org/browse/WFLY-3296
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.1.0.CR1
> Environment: Microsoft Windows [Version 6.1.7601]
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) Client VM (build 25.5-b02, mixed mode)
> Reporter: Dino Tsoumakis
> Assignee: Farah Juma
>
> Running the same web-app on Wildfly 8.1.0.CR1 with
> a) JDK 1.7.0_51
> b) JDK 1.8.0_05
> results in no problem on 1.7 JDK, but throws a NullPointerException on JDK 1.8. This might be a JDK bug.
> Stack trace on JDK 1.8 is:
> 2014-04-27 21:05:52,207 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-15) Error Rendering View[/secure/dashboard.xhtml]: java.lang.NullPointerException
> at java.lang.Class.isAssignableFrom(Native Method) [rt.jar:1.8.0_05]
> at java.beans.Introspector.isAssignable(Introspector.java:809) [rt.jar:1.8.0_05]
> at java.beans.Introspector.processPropertyDescriptors(Introspector.java:705) [rt.jar:1.8.0_05]
> at java.beans.Introspector.getTargetPropertyInfo(Introspector.java:553) [rt.jar:1.8.0_05]
> at java.beans.Introspector.getBeanInfo(Introspector.java:428) [rt.jar:1.8.0_05]
> at java.beans.Introspector.getBeanInfo(Introspector.java:173) [rt.jar:1.8.0_05]
> at javax.el.BeanELResolver$BeanProperties.<init>(BeanELResolver.java:223) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:726) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:]
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.facelets.component.UIRepeat.getValue(UIRepeat.java:279) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.facelets.component.UIRepeat.getDataModel(UIRepeat.java:255) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.facelets.component.UIRepeat.setIndex(UIRepeat.java:523) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.facelets.component.UIRepeat.process(UIRepeat.java:577) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.facelets.component.UIRepeat.encodeChildren(UIRepeat.java:1110) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:115) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:115) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1857) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.renderkit.html_basic.CompositeRenderer.encodeChildren(CompositeRenderer.java:78) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1857) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.render.Renderer.encodeChildren(Renderer.java:176) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1857) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1860) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1860) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.6-jbossorg-3.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at de.diehl.metering.izar.net.application.components.fileupload.FileUploadFilter.doFilter(FileUploadFilter.java:53) [classes:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
--
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
10 years, 3 months
[JBoss JIRA] (WFLY-3267) Confusing error message when tag file's attribute type is unknown
by Paul Benedict (JIRA)
[ https://issues.jboss.org/browse/WFLY-3267?page=com.atlassian.jira.plugin.... ]
Paul Benedict commented on WFLY-3267:
-------------------------------------
Yes, I verify the error message is the same in 8.1.0.CR1. I can tell by the stacktrace the message is generated by the Jasper compiler -- which is not a JBoss component. If you want to open up a corresponding ticket in Tomcat (owners of jasper?), that would be ideal.
> Confusing error message when tag file's attribute type is unknown
> -----------------------------------------------------------------
>
> Key: WFLY-3267
> URL: https://issues.jboss.org/browse/WFLY-3267
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Paul Benedict
> Assignee: Remy Maucherat
> Priority: Trivial
>
> I have a JSP tag file that requires a "size" attribute:
> {code}
> <%@ attribute name="size" required="true" type="Long" %>
> {code}
> Because the type accidentally wasn't a FQN (it should have been a {{java.lang.Long}}), this error was generated:
> {code}
> JBWEB004193: Unknown attribute type (size) for attribute Number
> {code}
> The message doesn't make any sense. "size" isn't the attribute type and the attribute is not "Number". A possible fix:
> {code}
> JBWEB004193: Unknown type (Number) was declared for attribute (size)
> {code}
> PS: It's really important to talk about the "declaration" here because the tag file isn't mentioned at all in the exception. The Jasper compiler only reports the enclosing JSP, which makes it look like the problem is with the usage not the tag file itself.
--
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
10 years, 3 months
[JBoss JIRA] (JASSIST-210) MethodCall.replace() throws inconsistent stack height in certain scenarios
by Patson Luk (JIRA)
[ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugi... ]
Patson Luk edited comment on JASSIST-210 at 4/28/14 1:04 PM:
-------------------------------------------------------------
Many thanks for the detailed reply!
Since the JVM pops everything off the operation stack, looks like either we would have to track whatever is the operand stack (such that we can restore at the end of the catch block before the goto instruction) which is extremely complicated (don't know if it's even feasible)
or
refactor the code and take the target method invocation out if it's a part of another method's invocation, such that
ref.testMethod1(ref.testMethod2()); becomes
Ref tempVar = ref.testMethod2();
ref.testMethod(tempVar)
then I can add the try catch statement before or after the testMethod2 invocation statement (but not wrapping it).
I will try the latter. Thanks!
was (Author: pluk):
Many thanks for the detailed reply!
There is still one piece that I do not quite understand, would you please kindly elaborate?
You mentioned that after the translation 2 and 3 are replaced with a try-catch statement, but in the sample code, the replacement block $_ = $proceed($$) itself is NOT surrounded by try-catch, only the injected System.out... was surrounded by try-catch:
"{ try
{ System.out.println(\"injected\"); }
catch (Exception e)
{ e.printStackTrace(); }
$_ = $proceed($$); }";
Therefore, if $_ = $proceed($$) does throw exception, it should still follow the same flow as if there is no try-catch? (as that piece of the code is not really wrapped)
Many thanks for your clarification in advanced
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
> Key: JASSIST-210
> URL: https://issues.jboss.org/browse/JASSIST-210
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.18.1-GA
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial, the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
> public void edit(MethodCall m) throws CannotCompileException {
> if (m.getMethodName().equals("testMethod2")) {
> String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
> m.replace(newBlock);
> }
> }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
> public static void main(String[] args) {
> RefClass ref = new RefClass();
> ref.testMethod2();
> }
> }
> class RefClass {
> public void testMethod1(Object o) {}
> public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!
--
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
10 years, 3 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 updated JBASMP-68:
--------------------------------
Description:
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.
was:
I'm trying to remove a jboss module by means of maven.
<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>
execute-commands fails with the following stack trace:
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
(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:
1) JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
2) usually there are more than one installation or jboss-as-maven-plugin can download the server;
3) jbossHome config parameter is not take into account;
4) 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.
> 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
> Assignee: James Perkins
>
> 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 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
10 years, 3 months