Jonathan Lalou's Blog

Archive for the ‘en-US’ Category

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:

[java]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"[/java]

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:

[java]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)[/java]

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]<?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>[/xml]

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

[java]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
[/java]

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:

[xml] <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>[/xml]

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

Let’s assume you have a “Hello World” GWT application. You need emulate a basic RPC call (RMI, EJB, etc.). Here is the program:

Under the *.gwt.client folder:

Create an service interface:

[java]@RemoteServiceRelativePath("fooService")
public interface FooService extends RemoteService {
public String getHelloFoo(String totoName);
}[/java]

Create another interface for asynchronous call. You can notice the method name differs lightly from the one in the other interface:

[java]public interface FooServiceAsync {
void getHelloFoo(String fooName, AsyncCallback<String> callback);
}[/java]

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

[java]public class FooServiceImpl extends RemoteServiceServlet implements FooService {
public FooServiceImpl() {
// TODO init
}

public String getHelloFoo(String fooName) {
// TODO call actual service
return "hello world!";
}
}[/java]

In the web.xml file, add the following blocks:

[xml] <!– Servlets –>
<servlet>
<servlet-name>fooService</servlet-name>
<servlet-class>com…….server.FooServiceImpl</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>fooService</servlet-name>
<url-pattern>/ivargwt/fooService</url-pattern>
</servlet-mapping>
[/xml]

The tags content match the argument given as parameter to RemoteServiceRelativePath annotation above.

From then, in your concrete code, you can instantiate the service and call remote method:

[java]FooServiceAsync fooService = GWT.create(FooService.class);
fooService.getHelloFoo("how are you?", new AsyncCallback<String>() {

public void onSuccess(String result) {
MessageBox.alert("OK", result, null);
}

public void onFailure(Throwable caught) {
MessageBox.alert("ERROR", "rpc call error-" + caught.getLocalizedMessage(), null);
}
});
[/java]

Now you can compile, package your war and deploy under Tomcat or WebLogic.

NB: special to “black-belt GWT guy” David Chau from SFEIR.

These days, I am discovering GWT, and more accurately ExtGWT, aka GXT.

Case

I have to write a “Hello World” application based on GXT.

Steps

• Firstly, follow Lars Vogel’s tutorial to have a “Hello World” in GWT.
• In Eclipse, add a dependancy from your project to extjs-gxt-lib-2.1.1.jar (version compatible with your GWT version: 1.7 or 2.0), available at this link.
• In your *.gwt.xml file, remove:
  [xml]<inherits name=’com.google.gwt.user.theme.standard.Standard’/>[/xml]

  and add:

  [xml]<inherits name=’com.extjs.gxt.ui.GXT’/>[/xml]

• Get the gxt-all.css file, copy it into war/css/ folder
• In your *.html file, add the lines:
  [xml]<link rel="stylesheet" type="text/css" href="css/gxt-all.css" />[/xml]
• Now, adapt your Java entry point source class, replacing GWT widgets with GXT ones.
• Restart your server and refresh the page in your browser. You have your “Hello World” in GXT!

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.

Case

Your have a multi-module project. For any reason, the build fails on your 32nd project (out of 70).
You indentify the issue, fix it, and need rebuild your project. Yet, you don’t want to rebuild the 31 first projects. Rather, you prefer to start on the 32nd one.
On older version of Maven, you had to edit your pom.xml, comment the 31 projects, launch the build and uncomment the projects.

Fix

From Maven 2.1, a new option is available: -rf or —resume-from. Thanks to this option, you can hint to Maven to restart the build at any point you like.

Case

You have this code
[java]ServletAuthentication servletAuthentication = new ServletAuthentication(LOGIN_USERNAME_LABEL, LOGIN_PASSWORD_LABEL);
Integer answer = servletAuthentication.weak(request, response);[/java]

But you always get FAILED_AUTHENTICATION as answer, while you expect to receive AUTHENTICATED.

Fix

In WebLogic configuration, set the control flag for Custom Authentication Provider and Default Weblogic Authentication Provider at SUFFICIENT.

Case
With Mule ESB 2.2.1, I use a classic <file:inbound-endpoint>:

[xml]<file:inbound-endpoint path="${fromPath}"
pollingFrequency="3000" fileAge="5000"
moveToDirectory="${moveToDirectory}"
synchronous="true"
>
<transformers>
<transformer ref="mySimpleCSVParser">
</transformers>
</file:inbound-endpoint>
[/xml]

When I launch the Mule with no component (entreprise layer), everything is OK: the file is loaded, parsed and moved. But when I introduce a minimal component, which does nothing, then the file is read many times. Mule ESB seems to loop indefinitely, reading the file many times, without deleting it from the directory.

[java]INFO  2010-03-04 15:47:18,291 [connector.file.0.receiver.6] org.mule.transport.file.FileMessageReceiver: Lock obtained on file: C:\temp\myFile.txt[/java]

Fix

Firstly I tried to increase the pollingFrequency attribute, assuming that the file had not yet been completely parsed when another cycle of “load-parse-move”. But it did not fix the issue.

Indeed, the problem was not related to the component layer, but to the parser itself. To fix the issue, you have to ensure the InputStream is properly closed in your Transformer layer:

[java]try
{
inputStream.close();
return  answer;
} catch (IOException e)
{
throw new TransformerException((Message)null, e);
}[/java]

Case

I have to instanciate an object of type FooDao. The only constructor available is FooDao(Connection connection).

On another hand, I have a bean of type BasicDataSource. From this BasicDataSource, I can get a Connection, through the call of BasicDataSource.getConnection().

Question: how to instanciate a bean of type FooDao in Spring?

Solution

The idea, to retrieve a field member of a bean, is to use the attributes factory-bean and factory-method, from which we will get a new bean.

Use the following Spring context file:

[xml]

<bean id="myBasicDataSource" class="org.apache.commons.dbcp.BasicDataSource">
<!– complete … –>
</bean>

<bean id="connection" factory-bean="myBasicDataSource" factory-method="getConnection"
scope="singleton"/>

<bean id="myFooDao" class="com.my.company.FooDao">
<constructor-arg ref="connection"/>
</bean>
[/xml]

Many thanks to David Chau from SFEIR for his help in this issue!

Case

You have to use a EhCache in a couple of beans, instancied via Spring.

Fix

In your main Spring configuration file, declare the following block:

[xml]
<bean id="customCache" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="shared" value="false" />
<property name="cacheManager">
<bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="configLocation" value="classpath*:ehcache.xml" />
</bean>
</property>
<property name="cacheName" value="SampleConfigOne" />
</bean>
[/xml]

Then, in any of your beans, declare the following property:

[xml]<property name="cache" value="customCache"/>[/xml]

Case

You have to build your project. All tests are OK when you run them in your IDE, but one or more unit tests fail when you launch the build with Maven 2. When this happens, you have to open the SureFire tests reports to read the failures details.

But you’d rather read the failure in the standard output. In other terms, you would like the output to be redirected onto the console, and not in log files.

Fix

When you launch the build, specify the following option:

-Dsurefire.useFile=false