Archive for the ‘en-US’ Category

Case

My project is deployed via Maven on a Jetty 6 server. I have to upgrade the server to Jetty 7.
(BTW: notice that the plugin maven-jetty-plugin was renamed as jetty-maven-plugin)

I get this error:

[java]java.lang.NoClassDefFoundError: javax/servlet/ServletRequestListener[/java]

Quick Fix

In Jetty plugin, add a dependency to servlet-api, eg:
[xml] <plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.4.4.v20110707</version>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
</dependency>
</dependencies>[/xml]

Case

My project is deployed via Maven on a Jetty 6 server. I have to upgrade the server to Jetty 7.
(BTW: notice that the plugin maven-jetty-plugin was renamed as jetty-maven-plugin)

I get this error:

[java] Cause: Class name which was explicitly given in configuration using ‘implementation’ attribute: ‘org.mortbay.jetty.bio.SocketConnector’ cannot be loaded[/java]

Quick fix

org.mortbay.jetty.bio.SocketConnector was removed from Jetty with the release 7. To fix the issue, use a more recent implementation. For instance, replace this block:
[xml]<connector implementation="org.mortbay.jetty.bio.SocketConnector">[/xml]
with that one:
[xml]<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">[/xml]

Case

My project is deployed via Maven on a Jetty 6 server. I have to upgrade the server to Jetty 7.
(BTW: notice that the plugin maven-jetty-plugin was renamed as jetty-maven-plugin)

I get this error:

[java] Error configuring: org.mortbay.jetty:jetty-maven-plugin. Reason: ERROR: Cannot override read-only parameter: contextPath in goal: jetty:run-exploded[/java]

Quick fix

Insert a tag <webAppConfig> between <configuration> and <contextPath>. In other terms, replace this block:

[xml]<configuration>
<contextPath>/I/love/USA</contextPath>
</configuration>[/xml]

with that one:

[xml]<configuration>
<webAppConfig>
<contextPath>/I/love/USA</contextPath>
</webAppConfig>
</configuration>[/xml]

Case

I have a WAR containing Axis2-built on webservices. I must deploy it under Jetty 6. The version of Axis2 is 1.5.X.
I get this exception:
[java]java.lang.ClassNotFoundException: org.apache.axis2.transport.http.AxisAdminServlet[/java]

I assume the same case may occur with Tomcat.

Explanation

The class AxisAdminServlet was removed from Axis2 between the releases 1.4 and 1.5.

Quick fix

Add the following dependency in Maven’s Jetty plugin:
[xml]<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<dependencies>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.4.1</version>
</dependency>
</dependencies>
(…)[/xml]

Abstract

The application I work on packages Mule ESB 2.2.1 in a WAR and deploys it under a WebLogic 10.3 server. My team mates and I noticed that, on multiple deploy/undeploy cycles, the PermGen size dramatically decreased. The cause of this was the number of threads, which hardly decreased on undeployment phases, unlike the expected behaviour.
Indeed, Mule is seldom deployed as a WebApp. Rather, it is designed to be run as a standalone application, within a Tanuki wrapper. When the JVM is killed, all the threads are killed, too, and therefore no thread survives ; hence, the memory is freed and there is no reason to fear a thread leak.

Moreover, when the application is redeployed, new threads -with the same names as the “old” threads- are created. The risk is that, for any reason, a thread-name-based communication between threads may fail, because the communication pipe may be read by the wrong thread.

In my case: on WebLogic startup, there are 31 threads ; when the application is deployed, there are 150 ; when the application works (receives and handles messages), the number of threads climbs to 800 ; when the application is undeployed, only 12 threads are killed, the other remaining alive.

The question is: how to kill Mule-created threads, in order to avoid a Thread leak?

WebLogic Threads

I performed a thread dump at WebLogic startup. Here are WebLogic threads, created before any deployment occurs:

[java]Attach Listener
DoSManager
DynamicListenThread[Default[1]]
DynamicListenThread[Default]
ExecuteThread: ‘0’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘1’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘2’ for queue: ‘weblogic.socket.Muxer’
Finalizer
JMX server connection timeout 42
RMI Scheduler(0)
RMI TCP Accept-0
RMI TCP Connection(1)-127.0.0.1
RMI TCP Connection(2)-127.0.0.1
Reference Handler
Signal Dispatcher
Thread-10
Thread-11
Timer-0
Timer-1
VDE Transaction Processor Thread
[ACTIVE] ExecuteThread: ‘0’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[ACTIVE] ExecuteThread: ‘2’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘5’ for queue: ‘weblogic.kernel.Default (self-tuning)’
main
weblogic.GCMonitor
weblogic.cluster.MessageReceiver
weblogic.time.TimeEventGenerator
weblogic.timers.TimerThread
[/java]

Dispose Disposables, Stop Stoppables…

The application being deployed in a WAR, I created a servlet implementing ServletContextListener. In the method contextDestroyed(), I destroy Mule objects (Disposable, Stoppable, Model, Service, etc.) one per one.
Eg#1:

[java] final Collection<Model> allModels;
try {
allModels = MuleServer.getMuleContext().getRegistry().lookupObjects(Model.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Disposing models " + allModels.size());
}
for (Model model : allModels) {
model.dispose();
}
allModels.clear();
} catch (Exception e) {
LOGGER.error(e);
}[/java]

Eg#2:

[java] private void stopStoppables() {
final Collection<Stoppable> allStoppables;
try {
allStoppables = MuleServer.getMuleContext().getRegistry().lookupObjects(Stoppable.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Stopping stoppables " + allStoppables.size());
}
for (Stoppable stoppable : allStoppables) {
stoppable.stop();
}
allStoppables.clear();
} catch (MuleException e) {
LOGGER.error(e);
}
}[/java]

This first step is needed because default mechanism is flawed: Mule re-creates objects that were destroyed.

Kill Threads

The general idea to kill Mule threads is the following: perform a Unix-style “diff” between WebLogic native threads, and the threads still alive once all Mule objects have been stopped and disposed.

On Application Startup

In the ServletContextListener, I add a field that will be set in a method called in the constructor:
[java] private List<String> threadsAtStartup;
(…)
/**
* This method retrieves the Threads present at startup: mainly speaking, they are Threads related to WebLogic.
*/
private void retrieveThreadsOnStartup() {
final Thread[] threads;
final ThreadGroup threadGroup;
threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
} catch (IllegalAccessException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
}

threadsAtStartup = new ArrayList<String>(threads.length);
for (int i = 0; i < threads.length; i++) {
final Thread thread;
try {
thread = threads[i];
if (null != thread) {
threadsAtStartup.add(thread.getName());
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("This Thread was available at startup: " + thread.getName());
}
}
} catch (RuntimeException e) {
LOGGER.error("An error occured on initial Thread statement: ", e);
}
}
}
/**
* Hack to retrieve the field ThreadGroup.threads, which is package-protected and therefore not accessible
*
* @param threadGroup
* @return
* @throws NoSuchFieldException
* @throws IllegalAccessException
*/
private Thread[] retrieveCurrentActiveThreads(ThreadGroup threadGroup) throws NoSuchFieldException, IllegalAccessException {
final Thread[] threads;
final Field privateThreadsField;
privateThreadsField = ThreadGroup.class.getDeclaredField("threads");
privateThreadsField.setAccessible(true);

threads = (Thread[]) privateThreadsField.get(threadGroup);
return threads;
}
[/java]

On application shutdown

In the method ServletContextListener.contextDestroyed(), let’s call this method:
[java] /**
* Cleanses the Threads on shutdown: theorically, when the WebApp is undeployed, should remain only the threads
* that were present before the WAR was deployed. Unfornately, Mule leaves alive many threads on shutdown, reducing
* PermGen size and recreating new threads with the same names as the old ones, inducing a kind of instability.
*/
private void cleanseThreadsOnShutdown() {
final Thread[] threads;
final ThreadGroup threadGroup;
final String currentThreadName;

currentThreadName = Thread.currentThread().getName();

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("On shutdown, currentThreadName is: " + currentThreadName);
}

threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
} catch (IllegalAccessException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
}

for (Thread thread : threads) {
final String threadName = thread.getName();
final Boolean shouldThisThreadBeKilled;

shouldThisThreadBeKilled = isThisThreadToBeKilled(currentThreadName, threadName);
if (LOGGER.isDebugEnabled()) {
LOGGER.info("should the thread named " + threadName + " be killed? " + shouldThisThreadBeKilled);
}
if (shouldThisThreadBeKilled) {
thread.interrupt();
thread = null;
}
}

}

/**
* Says whether a thread is to be killed<br/>
* Rules:
* <ul><li>a Thread must NOT be killed if:</li>
* <ol>
* <li>it was among the threads available at startup</li>
* <li>it is a Thread belonging to WebLogic (normally, WebLogic threads are among the list in the previous case</li>
* <li>it is the current Thread (simple protection against unlikely situation)</li>
* </ol>
* <li>a Thread must be killed: in all other cases</li>
* </ul>
*
* @param currentThreadName
* @param threadName
* @return
*/
private Boolean isThisThreadToBeKilled(String currentThreadName, String threadName) {
final Boolean toBeKilled;
toBeKilled = !threadsAtStartup.contains(threadName)
&amp;&amp; !StringUtils.contains(threadName, "weblogic")
&amp;&amp; !threadName.equalsIgnoreCase(currentThreadName);
return toBeKilled;
}
[/java]

EhCache

My application uses an EhCache. Its threads names usually end with “.data”. They are not killed by the previous actions. To get rid of them, the most elegant way is to add this block in the web.xml:
[xml] <listener>
<listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class>
</listener>
[/xml]
cf EhCache documentation

With all these operations, almost all threads are killed. But Java VisualVM still displays 34, vs. 31 at startup.

Tough Threads

A thread dump confirms that, at this point, 3 rebellious threads still refuse to be kill:
[java]MuleServer.1
SocketTimeoutMonitor-Monitor.1
SocketTimeoutMonitor-Monitor.1
[/java]
Let’s examine them:

• MuleServer.1: This thread is an instance of the inner class MuleServer.ShutdownThread. Indeed, this is the first thread created by Mule, and therefore appears among the threads available at startup, before the ServletContextListener is called… I did not succeed in killing it, even why trying to kill it namely, which makes sense: killing the father thread looks like suiciding the ServletContextListener.
• SocketTimeoutMonitor-Monitor.1: This thread is created by Mule’s TcpConnector and its daughter classes: HttpConnector, SslConnector, etc. Again, I could not kill them.

Conclusion

We have seen Mule suffers of major thread leaks when deployed as a WAR. Anyway, most of these leaks may be sealed.
I assume MuleSoft was aware of this issue: in the version 3 of Mule, the deployment of webapps was refactored.

How to access a non-acccessible field (either protected, package-protected or private) of an object in Java?

For instance, you would like to access the field threads of ThreadGroup:

[java]ThreadGroup threadGroup = Thread.currentThread().getThreadGroup();
final Field privateThreadsField;
privateThreadsField = ThreadGroup.class.getDeclaredField(&quot;threads&quot;);
privateThreadsField.setAccessible(true);
threads = (Thread[]) privateThreadsField.get(threadGroup);[/java]

Case

After rooting my Nexus S, I tried to flash the ROM, in order to replace the genuine GingerBread with a CyanoGen ehanced version. This worked pretty well, but for a amazing reason I do not know, I missed the so-called “GApps”: GMail, GMaps, etc., this way a Nexus S (or any other Android-driven mobile device) losing any interest. Then, it was the worst catastrophic epiphenomenon I might fear: the Nexus was “bricked”. Indeed, the splash screen, with the Android robot on a skate, did not stop from looping…

Brick, Block and Pitfall

I tried to restore CyanoGen, wipe the memory, etc., but nothing efficient. At last I decided to restore a genuine Gingerbread version.
Here is the puzzling block that stands on the road: a Nexus S does not contain an actual (I mean physical) SD memory card. The “virtual” SD card must be mounted via ADB. But ADB does not recognize the device, since the Nexus is “bricked”. The only access to the Nexus appears to be FastBoot… which does not recognize the /sdcard folder. And the circle is complete.

As you understand, the key is to be able to mount /sdcard, which is sufficient to copy a ROM, and then apply it as a regular update.

Fix

Here we assume you have a minimal knownledge on how to use ADB and FastBoot:

• Download recovery-clockwork-3.0.2.4-crespo.img
• Download GingerBread original ROM: da8206299fe6.signed-soju-ota-121341.da820629.zip
• Switch on your Nexus in recovery mode (sound up and on/off buttons at the same time)
• Select “recovery“
• Connect it to your PC
• On the PC: fastboot boot ~/recovery-clockwork-3.0.2.4-crespo.img
• Your phone reboots with a yellow on black console.
  • Select “mounts and storage” > “mount usb storage”
• Now your PC detects the phone as a regular mass storage device.
  • Copy GingerBread ROM to /sdcard folder.
  • Rename it as update.zip (optionnal, easier for the next step)
• On the PC: fastboot boot ~/recovery-clockwork-3.0.2.4-crespo.img
• On the phone,
  • select the option “apply update“
  • select update.zip
• Restart the phone
• If the phone freezes a long time, shut it down and switch it on again
• Now the regular Nexus splash screen should be OK

Case

Under WebLogic, I deploy RMI services:

[xml] <bean id="fakeRmiServer" class="org.springframework.remoting.rmi.JndiRmiServiceExporter">
<property name="service" ref="fakeInterfaceImpl" />
<property name="serviceInterface" value="lalou.jonathan.FakeInterface" />
<property name="jndiName" value="fakeRmiServer" />
</bean>
<bean id="fakeInterfaceImpl" class="lalou.jonathan.FakeInterfaceImpl" />
[/xml]

The WAR is hosted by a WebLogic 10.3.3 server (this point does not matter).

I retrieve the RMI services on client side, with this Spring config:

[xml] <bean id="fakeServiceClient" class="org.springframework.remoting.rmi.JndiRmiProxyFactoryBean">
<property name="jndiName" value="fakeRmiServer"/>
<property name="jndiEnvironment">
<props>
<prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>
<prop key="java.naming.provider.url">t3://localhost:7003</prop>
</props>
</property>
<property name="serviceInterface" value="lalou.jonathan.FakeInterface"/>
</bean>
[/xml]

On launching the client side, I get this error:

[java]java.lang.ClassCastException: Cannot narrow remote object ClusterableRemoteRef(-2462835584319760815S:123.123.123.123:[7003,7003,-1,-1,-1,-1,-1]:JonathanApplication:JonathanAdminServer [-2462835584319760815S:123.123.123.123:[7003,7003,-1,-1,-1,-1,-1]:JonathanApplication:JonathanAdminServer/375])/375 to lalou.jonathan.FakeInterface[/java]

Complete Stacktrace

[java]java.lang.ClassCastException: Cannot narrow remote object ClusterableRemoteRef(-2462835584319760815S:123.123.123.123:[7003,7003,-1,-1,-1,-1,-1]:JonathanApplication:JonathanAdminServer [-2462835584319760815S:123.123.123.123:[7003,7003,-1,-1,-1,-1,-1]:JonathanApplication:JonathanAdminServer/375])/375 to lalou.jonathan.FakeInterface

org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘fakeServiceClient’ defined in class path resource [lalou/jonathan/java/webservices/jonathan-services.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [lalou.jonathan.java.webservices.FakeServiceWSServer]: Constructor threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘fakeServiceClient’ defined in class path resource [lalou/jonathan/java/webservices/jonathan-rmi-client-spring.xml]: Invocation of init method failed; nested exception is org.springframework.remoting.RemoteLookupFailureException: Could not narrow RMI stub to service interface [lalou.jonathan.FakeInterface]; nested exception is java.lang.ClassCastException: Cannot narrow remote object ClusterableRemoteRef(-2462835584319760815S:123.123.123.123:[7003,7003,-1,-1,-1,-1,-1]:JonathanApplication:JonathanAdminServer [-2462835584319760815S:123.123.123.123:[7003,7003,-1,-1,-1,-1,-1]:JonathanApplication:JonathanAdminServer/375])/375 to lalou.jonathan.FakeInterface
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:883)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:839)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
at org.apache.cxf.transport.servlet.CXFServlet.loadAdditionalConfig(CXFServlet.java:171)
at org.apache.cxf.transport.servlet.CXFServlet.updateContext(CXFServlet.java:139)
at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.java:101)
at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:70)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.init(AbstractCXFServlet.java:78)
at (…)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:736)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:454)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:396)
at org.mortbay.jetty.plugin.Jetty6RunWarExploded.execute(Jetty6RunWarExploded.java:170)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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:597)
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]

Fix

Indeed, this issue appeared with Spring 2.5.4, and was fixed with 2.5.6 release. I let you guess which version I was using…
(cf. Spring 2.5.6 Changelog: * JndiRmiClientInterceptor skips narrowing for RmiInvocationHandler stubs (fixing a regression in 2.5.4)
Therefore, to fix this issue you have to upgrade your Spring version to 2.5.6.

I faced a very embarassing situation: trying to root my Nexus S, I had to unlock the device. My Android SDK was succesfully installed, the drivers too. The device was succesfully recognized by ADB… But fastboot devices failed to detect the device. From this point, it was impossible to unlock the device by launching fastboot oem unlock. I tried many basic solutions, but none worked.

At last, I found this post:
http://forum.xda-developers.com/showthread.php?t=875580

When ADB works but not FastBoot, the solution is to… install PdaNet. Amazing ; but efficient.

Many thanks to BigRick10 from XDA forums!

Following the post on widely used DTDs, here is a list of some XSD (aka XML Schemas):