[JBoss JIRA] (JBASMP-68) execute-commands does not work for module command
by Ram S (JIRA)
[ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.... ]
Ram S commented on JBASMP-68:
-----------------------------
Hi [~heatseeker], would you please share some details on the patching. thanks.
> 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 was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager
by shinzey shinzey (JIRA)
[ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.... ]
shinzey shinzey commented on WFLY-4096:
---------------------------------------
However, with this workaround, CDI stops working. For example if I annotate a class with:
{quote}
@Named
@Stateless
@PermitAll
@Path("rest")
{quote}
The the following exception is thrown when trying to access the service:
{quote}
org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBException: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance
{quote}
> Datasource Defined in web.xml Does Not Work with JPA Entity Manager
> -------------------------------------------------------------------
>
> Key: WFLY-4096
> URL: https://issues.jboss.org/browse/WFLY-4096
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Web (JBoss Web)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Scott Marlow
> Priority: Critical
> Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit
>
> The datasource defined in web.xml:
> {quote}
> <data-source>
> <name>java:/datasources/test</name>
> <class-name>org.apache.derby.jdbc.ClientDataSource</class-name>
> <database-name>test</database-name>
> <url>jdbc:derby://localhost:1527/test</url>
> <user>test</user>
> <password>test</password>
> </data-source>
> {quote}
> The persistence unit:
> {quote}
> <persistence-unit name="wtpu" transaction-type="JTA">
> <jta-data-source>java:/datasources/test</jta-data-source>
> </persistence-unit>
> {quote}
> The deployment error:
> {quote}
> 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war")
> 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu
> 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"])
> 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war")
> 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__]
> {quote}
> If I remove the persistence unit, the datasource can be successfully bound:
> {quote}
> 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test]
> {quote}
> The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager
by shinzey shinzey (JIRA)
[ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.... ]
shinzey shinzey commented on WFLY-4096:
---------------------------------------
Just found that this issue had been reported before but still not resolved:
https://issues.jboss.org/browse/WFLY-2727
> Datasource Defined in web.xml Does Not Work with JPA Entity Manager
> -------------------------------------------------------------------
>
> Key: WFLY-4096
> URL: https://issues.jboss.org/browse/WFLY-4096
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Web (JBoss Web)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Scott Marlow
> Priority: Critical
> Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit
>
> The datasource defined in web.xml:
> {quote}
> <data-source>
> <name>java:/datasources/test</name>
> <class-name>org.apache.derby.jdbc.ClientDataSource</class-name>
> <database-name>test</database-name>
> <url>jdbc:derby://localhost:1527/test</url>
> <user>test</user>
> <password>test</password>
> </data-source>
> {quote}
> The persistence unit:
> {quote}
> <persistence-unit name="wtpu" transaction-type="JTA">
> <jta-data-source>java:/datasources/test</jta-data-source>
> </persistence-unit>
> {quote}
> The deployment error:
> {quote}
> 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war")
> 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu
> 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"])
> 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war")
> 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__]
> {quote}
> If I remove the persistence unit, the datasource can be successfully bound:
> {quote}
> 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test]
> {quote}
> The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager
by shinzey shinzey (JIRA)
[ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.... ]
shinzey shinzey commented on WFLY-4096:
---------------------------------------
Setting "wildfly.jpa.twophasebootstrap" to "false" works. It's a valid workaround but also vender-specific.
> Datasource Defined in web.xml Does Not Work with JPA Entity Manager
> -------------------------------------------------------------------
>
> Key: WFLY-4096
> URL: https://issues.jboss.org/browse/WFLY-4096
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Web (JBoss Web)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Scott Marlow
> Priority: Critical
> Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit
>
> The datasource defined in web.xml:
> {quote}
> <data-source>
> <name>java:/datasources/test</name>
> <class-name>org.apache.derby.jdbc.ClientDataSource</class-name>
> <database-name>test</database-name>
> <url>jdbc:derby://localhost:1527/test</url>
> <user>test</user>
> <password>test</password>
> </data-source>
> {quote}
> The persistence unit:
> {quote}
> <persistence-unit name="wtpu" transaction-type="JTA">
> <jta-data-source>java:/datasources/test</jta-data-source>
> </persistence-unit>
> {quote}
> The deployment error:
> {quote}
> 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war")
> 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu
> 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"])
> 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war")
> 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__]
> {quote}
> If I remove the persistence unit, the datasource can be successfully bound:
> {quote}
> 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test]
> {quote}
> The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-99:
-----------------------------------------------
James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from ASSIGNED to POST
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
> Key: LOGMGR-99
> URL: https://issues.jboss.org/browse/LOGMGR-99
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: James Perkins
> Priority: Critical
> Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2
>
> Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
> {code}
> ...
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:527)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:266)
> at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
> at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
> at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months