Search
Calendar
March 2024
S M T W T F S
« Sep    
 12
3456789
10111213141516
17181920212223
24252627282930
31  
Your widget title
Archives

Posts Tagged ‘BEA’

PostHeaderIcon java.lang.OutOfMemoryError: PermGen space

Case:

I have to redeploy many times a day a WAR on a WebLogic 10 server, using Hotspot (Sun JVM) with Java 6. After some cycles deploy/undeploy, Hotspot crashes with the following error:

java.lang.OutOfMemoryError: PermGen space

Complete stacktrace:

2010-08-17 11:26:56,718 ERROR context.ContextLoader               - Context initialization failed
java.lang.IllegalStateException: Unable to load Java 1.5 dependent class [org.springframework.beans.factory.annotation.QualifierAnnotationAutowireCandidateResolver]
        at org.springframework.beans.factory.support.AutowireUtils.createAutowireCandidateResolver(AutowireUtils.java:125)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.<init>(DefaultListableBeanFactory.java:103)
        at org.springframework.context.support.AbstractRefreshableApplicationContext.createBeanFactory(AbstractRefreshableApplicationContext.java:176)
        at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:121)
        at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:423)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:353)
        at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
        at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
        at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:481)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
        at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:181)
        at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1863)
        at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3126)
        at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1512)
        at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:486)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
        at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:247)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27)
        at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:1267)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
        at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:409)
        at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:43)
        at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:150)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:116)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
        at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.OutOfMemoryError: PermGen space
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:328)
        at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:285)
        at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:253)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:56)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:177)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:37)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:328)
        at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:285)
        at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:253)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:56)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:177)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:37)
        at org.springframework.util.ClassUtils.forName(ClassUtils.java:242)
        at org.springframework.beans.factory.support.AutowireUtils.createAutowireCandidateResolver(AutowireUtils.java:120)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.<init>(DefaultListableBeanFactory.java:103)
        at org.springframework.context.support.AbstractRefreshableApplicationContext.createBeanFactory(AbstractRefreshableApplicationContext.java:176)
        at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:121)
        at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:423)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:353)
        at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
<Aug 17, 2010 11:26:56 AM CEST> <Warning> <HTTP> <BEA-101162> <User defined listener org.springframework.web.context.ContextLoaderListener failed: java.lang.IllegalStateException: Unable to load Java
1.5 dependent class [org.springframework.beans.factory.annotation.QualifierAnnotationAutowireCandidateResolver].
java.lang.IllegalStateException: Unable to load Java 1.5 dependent class [org.springframework.beans.factory.annotation.QualifierAnnotationAutowireCandidateResolver]
        at org.springframework.beans.factory.support.AutowireUtils.createAutowireCandidateResolver(AutowireUtils.java:125)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.<init>(DefaultListableBeanFactory.java:103)
        at org.springframework.context.support.AbstractRefreshableApplicationContext.createBeanFactory(AbstractRefreshableApplicationContext.java:176)
        at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:121)
        at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:423)
        Truncated. see log file for complete stacktrace

Caused By: java.lang.OutOfMemoryError: PermGen space
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:328)
        Truncated. see log file for complete stacktrace
>
<Aug 17, 2010 11:26:56 AM CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1282037204562' for task '9'. Error is: 'weblogic.application.ModuleException: '
weblogic.application.ModuleException:
        at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1514)
        at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:486)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        Truncated. see log file for complete stacktrace

Caused By: java.lang.OutOfMemoryError: PermGen space
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:328)
        Truncated. see log file for complete stacktrace
>

A short explanation

The error seems to be linked to the garbage collection. From what I could read on the web, static objects used in CGlib (and/or jars depending on the library, such as the wide spread Hibernate, Spring, etc.) are the source of the crash.

Fix

Switching HotSpot to Oracle/BEA’s JVM, aka JRockit, makes the error (almost) disappear.
Alternatively, if you can’t change the JVM, a workaround consists in upgrading the following parameter on JVM launching:
-XX:MaxPermSize=256m

PostHeaderIcon Error 403 with Maven 2 deployment

Case

This morning, I tried to redeploy an EAR on a WebLogic 9.2, using Maven 2 and a classical deployment profile. I got this issue:

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing ant tasks

Embedded error: The following error occurred while executing this line:
(...)
weblogic.deploy.api.internal.utils.DeployerHelperException: The source 'C:\DOCUME~1\myLogin\LOCALS~1\Temp\myApplication-ear.ear' for the application 'my-application-ear' could not be loaded to the server 'http://myServer:1234/bea_wls_deployment_internal/DeploymentService'.
Response: '403: Forbidden' for url: 'http://myServer:1234/bea_wls_deployment_internal/DeploymentService'

Yesterday, I got a similar error when I launched a mvn tomcat:deploy to deploy a WAR on a Tomcat 6.0 server:

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot invoke Tomcat manager

Embedded error: Server returned HTTP response code: 403 for URL: http://myServer:3210/manager/deploy?path=%2FmyWebArchive&war=&update=true

Quick Fix

Running Maven2 in offline line, ie adding the option "-o", allows me to redeploy both the EAR on WebLogic and the WAR on Tomcat.
eg: mvn tomcat:deploy -o
I keep on investigating on this matter. I think there is an issue on the DNS. Indeed, when I deploy locally to my own machine myServer (ie with its network name), this error is raised, but when I deploy to localhost the build is successful.

PostHeaderIcon GWT: call a remote EJB with Spring lookup

Abstract

Let’s assume you have followed the article “Basic RPC call with GWT“. Now you would like to call an actual EJB 2 as remote, via a Spring lookup.
Let’s say: you have an EJB MyEntrepriseComponentEJB, which implements an interface MyEntrepriseComponent. This EJB, generates a remote MyEntrepriseComponentRemote.

Entry Point

In myApplication.gwt.xml entry point file, after the line:

<inherits name='com.google.gwt.user.User'/>

add the block:

  <inherits name='com.google.gwt.user.User' />
 <inherits name="com.google.gwt.i18n.I18N" />
 <inherits name="com.google.gwt.http.HTTP" />

Add the line:

<servlet path='/fooService.do'/>

Client

Under the *.gwt.client folder:

Update the service interface. Only the annotation parameter is amended:

@RemoteServiceRelativePath("services/fooService")
public interface FooService extends RemoteService {
 public String getHelloFoo(String fooName);
}

You have nothing to modify in asynchronous call interface (FooServiceAsync).

Server

Under the *.gwt.server folder, update the implementation for service interface:

Change the super-class, replacing RemoteServiceServlet with GWTSpringController:

public class FooServiceImpl extends GWTSpringController implements FooService {
 public FooServiceImpl() {
 // init
 }
}

Add new field and its getter/setter:

// retrieved via Spring
 private myEntrepriseComponent myEntrepriseComponent;

 public myEntrepriseComponent getMyEntrepriseComponent() {
 return myEntrepriseComponent;
 }

 public void setmyEntrepriseComponent(myEntrepriseComponent _myEntrepriseComponent) {
     myEntrepriseComponent = _myEntrepriseComponent;
 }

Write the actual call to EJB service:

 public String getHelloFoo(String fooName) {
    return myEntrepriseComponent.getMyDataFromDB();
 }
}

web.xml

Fill the web.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
 PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

 <!-- Spring -->
 <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/applicationContext.xml</param-value>
 </context-param>
 <listener>
     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
 </listener>

 <servlet>
    <servlet-name>gwt-controller</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
 </servlet>

 <servlet-mapping>
    <servlet-name>gwt-controller</servlet-name>
    <url-pattern>/myApplication/services/*</url-pattern>
 </servlet-mapping>

 <!-- Default page to serve -->
 <welcome-file-list>
     <welcome-file>MyApplicationGwt.html</welcome-file>
 </welcome-file-list>

</web-app>

JNDI

Add a jndi.properties file in src/resources folder:

java.naming.provider.url=t3://localhost:12345
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=yourLogin
java.naming.security.credentials=yourPassword
weblogic.jndi.enableDefaultUser=true

These properties will be used by Spring to lookup the remote EJB. The last option is very important, otherwise you may happen to face issues with EJB if they were deployed under WebLogic.

WEB-INF

In the WEB-INF folder, add an applicationContext.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<beans>

 <util:properties id="jndiProperties" location="classpath:jndi.properties" />

 <jee:remote-slsb id="myEntrepriseComponentService"
      jndi-name="ejb.jonathan.my-entreprise-component"
      business-interface="lalou.jonathan.myApplication.services.myEntrepriseComponent"
      environment-ref="jndiProperties" cache-home="false"
      lookup-home-on-startup="false" refresh-home-on-connect-failure="true" />

</beans>

Add a gwt-controller-servlet.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans.xsd
 http://www.springframework.org/schema/context
 http://www.springframework.org/schema/context/spring-context.xsd">

 <bean>
    <property name="order" value="0" />
    <property name="mappings">
        <value>
            /fooService=fooServiceImpl
        </value>
     </property>
 </bean>

 <bean id="fooServiceImpl"
 class="lalou.jonathan.myApplication.web.gwt.server.FooServiceImpl">
      <property name="myEntrepriseComponent" ref="myEntrepriseComponentService" />
 </bean>
</beans>

Of course, if your servlet mapping name in web.xml is comoEstasAmigo, then rename gwt-controller-servlet.xml as comoEstasAmigo-servlet.xml 😉

Build and deploy

Now you can compile, package your war and deploy under Tomcat or WebLogic. WebLogic server may raise an error:
java.rmi.AccessException: [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB
This error is related to the rights required to call a method on the EJB. Indeed, two levels of rights are used by WebLogic: firstly to lookup / instanciate the EJB (cf. the property java.naming.security.principal we set sooner), and another to call the method itself. In this second case, WebLogic requires an authentication (think of what you do when you login an web application deployed: your login and rights are kept for all the session) to grant the rights. I wish to handle this subject in a future post.

NB: thanks to David Chau and Didier Girard from SFEIR, Sachin from Mumbai team and PYC from NYC.

PostHeaderIcon WebLogic deployment automatization with Maven and/or Ant

Case

I had to automatize the deployment of a basic GWT application, packaged as a WAR archive, on a WebLogic 9.2 server.

Maven 2

Mojo Plugin

Firstly, I tried to use Mojo’s maven plugin for Weblogic. I had to add some lines in my pom.xml, almost identical to those available in Mojo’s documentation.

The main issue I encountered was to retrieve the jars mandatory to the plugin, and install them in my local Maven repository. Since the missing jars names given by Maven are not so obvious, here are the paths to retrieve these jars, all included with WebLogic 9.2 installation:

mvn install:install-file -DgroupId=weblogic -DartifactId=xbean -Dversion=9.2 -Dpackaging=jar -Dfile=%BEA_HOME%\server\lib\wlxbean.jar
mvn install:install-file -DgroupId=weblogic -DartifactId=wlw-langx -Dversion=9.2 -Dpackaging=jar -Dfile=%BEA_HOME%\server\lib\wlw-langx.jar
mvn install:install-file -DgroupId=weblogic -DartifactId=wlw-util -Dversion=9.2 -Dpackaging=jar -Dfile="%BEA_HOME%\common\lib\wlw-util.jar"
mvn install:install-file -DgroupId=weblogic -DartifactId=bcel -Dversion=5.1 -Dpackaging=jar -Dfile="%BEA_HOME%\javelin\lib\bcel-5.1.jar"
mvn install:install-file -DgroupId=weblogic -DartifactId=javelinx -Dversion=9.2 -Dpackaging=jar -Dfile="%BEA_HOME%\javelin\lib\javelinx.jar"
mvn install:install-file -DgroupId=weblogic -DartifactId=weblogic-container-binding -Dversion=9.2 -Dpackaging=jar -Dfile="%BEA_HOME%\server\lib\schema\weblogic-container-binding.jar"

Issues

Once this issue fixed, I tried to launch the deployment (with mvn weblogic:deploy). But I encountered the following error:
Response: '404: Not Found' for url: 'http://localhost:7070/bea_wls_deployment_internal/DeploymentService'
Complete stacktrace in debug and verbose mode:

weblogic.deploy.api.internal.utils.DeployerHelperException: The source 'C:\LOCALS~1\Temp\appliGWT-1.0-SNAPSHOT.war' for the application 'iVarGwt' could not be loaded to the server 'http://localhost:7070/bea_wls_deployment_internal/DeploymentService'.
Response: '404: Not Found' for url: 'http://localhost:7070/bea_wls_deployment_internal/DeploymentService'
        at weblogic.deploy.api.internal.utils.JMXDeployerHelper.uploadSource(JMXDeployerHelper.java:658)
        at weblogic.deploy.api.spi.deploy.internal.ServerConnectionImpl.upload(ServerConnectionImpl.java:653)
        at weblogic.deploy.api.spi.deploy.internal.BasicOperation.uploadFiles(BasicOperation.java:319)
        at weblogic.deploy.api.spi.deploy.internal.BasicOperation.execute(BasicOperation.java:411)
        at weblogic.deploy.api.spi.deploy.internal.BasicOperation.run(BasicOperation.java:169)
        at weblogic.deploy.api.spi.deploy.WebLogicDeploymentManagerImpl.deploy(WebLogicDeploymentManagerImpl.java:369)
        at weblogic.deploy.api.tools.deployer.DeployOperation.execute(DeployOperation.java:47)
        at weblogic.deploy.api.tools.deployer.Deployer.perform(Deployer.java:139)
        at weblogic.deploy.api.tools.deployer.Deployer.runBody(Deployer.java:88)
        at weblogic.utils.compiler.Tool.run(Tool.java:158)
        at weblogic.utils.compiler.Tool.run(Tool.java:115)
        at weblogic.Deployer.run(Deployer.java:70)
        at org.codehaus.mojo.weblogic.DeployMojoBase.executeDeployer(DeployMojoBase.java:510)
        at org.codehaus.mojo.weblogic.DeployMojo.execute(DeployMojo.java:49)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Deploying another application worked, deploying my application using WebLogic console worked too… After many hours of search, I gave up Maven2 way.

Ant

After retiring from using Mojo’s plugin, I used a way I feared would be less elegant: Ant.

Indeed, Ant script is very short and efficient:

<?xml version="1.0" encoding="UTF-8"?>

<project name="redeploy" basedir="." default="deploy">
	<property file="redeploy.properties" />

	<target name="init-weblogic-task">
		<available file="${env.WL_HOME}/server/lib/weblogic.jar"
			property="weblogic-jar.present" />
		<fail unless="weblogic-jar.present">${env.WL_HOME}/server/lib/weblogic.jar does not
			exist</fail>

		<taskdef name="wldeploy" classname="weblogic.ant.taskdefs.management.WLDeploy"
			classpath="${env.WL_HOME}/server/lib/weblogic.jar" />
	</target>

	<target name="deploy" depends="init-weblogic-task">
		<wldeploy action="deploy" source="${source}"
			name="${name}" user="${user}" password="${password}" verbose="true"
			adminurl="${adminurl}" debug="true" targets="${targets}" upload="true"
			securitymodel="${securitymodel}" stage="stage" />
	</target>

</project>

In the same folder, I created a property file, gathering the properties hinted at in Ant build.xml.

env.WL_HOME=C:/bea/weblogic_9_2
adminurl=t3://localhost:7070
name=appliGWT
user=weblogic
password=myPassword
targets=myTarget
securitymodel=Advanced
source=../../../target/appliGWT-1.0-SNAPSHOT.war

I launched Ant and the deployment was successful.

Maven anyway, but with Ant

Yet, since I build with Maven, I do not want to have to build, change folder, and then deploy: I want a unique command line to package and deploy. To perform that, I added a profile in my pom.xml, using a Maven plugin to call Ant tasks:

    <profiles>
        <profile>
            <id>deploy</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>2.4.2</version>
                        <configuration>
                            <skipTests>true</skipTests>
                        </configuration>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.1</version>
                        <executions>
                            <execution>
                                <phase>package</phase>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                                <configuration>
                                    <tasks>
                                        <ant antfile="./src/resources/ant/build.xml"
                                             target="deploy"
                                             inheritall="false" inheritrefs="false"/>
                                    </tasks>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

At last, my target was OK: I can build and deploy with a simple mvn package -Pdeploy

PostHeaderIcon This RJVM has already been shutdown

Error

Could not connect to remote service [ejb.services.myEjb]; nested exception is java.rmi.ConnectException: This RJVM has already been shutdown 4967659282374941940S:myServer:[7404,7404,-1,-1,-1,-1,-1]:myDomain:myEjbInstance

Explanation

Your EJB instance tries to lookup for a remote instance which seems to be shutdown. There may be many causes: IP / hostname resolution failed, remote servers are actually unreachables (such in the case of network issues), etc. Another potential issue may come from a bug in cluster management by WebLogic. Such a bug was identified and fixed by BEA with version 8 release ; yet, the bug may have kept on occuring on later version (9.2 in my case).
In my current case, the issue was that webservices, theorically deployed in the same WebLogic, were not started. Once the web services started, the issue vanished.