Problem deploying SAR, ClassNotFoundException

[jmihalich]

Hi,

I have been moving our ear and sar achives into an isolated class loader mode, by adding the <loader-repository> to the jboss-app, and jboss-service xml files for the respective applications. We are using jboss 4.0.5 on windows server 2003. Sun JDK 1.4.2.x.

All of my changes are working except the 2 SAR files I have. Even without the loader-repository element in the jboss-service.xml file I still have the problem.

The problem is that for some reason jboss can't find the class that is defined in the mbean tag. Here is what is defined in the service xml file:



Rim.ReaderInstanceManager
rfNetwork



The sar file contains a meta-inf directory with a manifest file, and the jboss-service.xml file as shown above. It also contains a bunch of jars, one of which has the package with the class com.mwvis.ri.instancemgr.ReaderInstanceManager in it.

However, when jboss starts up, I get this error message:

2008-01-29 18:31:27,903 [main] ERROR org.jboss.deployment.MainDeployer : Could not create deployment: file:/D:/java/jboss-4.0.5.GA-Vue/server
/default/deploy/com.mwvis.rim_1_0.sar
org.jboss.deployment.DeploymentException: No ClassLoaders found for: com.mwvis.ri.instancemgr.ReaderInstanceManager; - nested throwable: (jav
a.lang.ClassNotFoundException: No ClassLoaders found for: com.mwvis.ri.instancemgr.ReaderInstanceManager)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
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:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)

Can someone please help me figure out why jboss can't find the class which is in one of the jars in the sar? Is there someplace i have to specify what jar the class is in?

I didn't have this problem when I was in the standard shared class loader mode. But obviously that doesn't mean something was wrong all the time.

Thanks,
Joe

[jmihalich]

Sorry, the xml didn't print out in last post. This is the contents of my jboss-service.xml.

<server>
 <mbean name="Rim.Services:service=InstanceManager"
 code="com.mwvis.ri.instancemgr.ReaderInstanceManager">
 <attribute name="JndiName">Rim.ReaderInstanceManager</attribute>
 <attribute name="SwitchClientType">rfNetwork</attribute>
 </mbean>
</server>

[jmihalich]

Arggghhhh! I figured it out, FINALLY. All day, I've been tracking this down.
Somebody had 3 bogus control characters (UTF-8 likely) at the beginning of the manifest file inside of the jar where the class was. That was killing the deployer I guess. Some editor put them there when it was saved out.

This has been there since day one, but nobody ever saw it because the shared class loading was picking the classes up out of another ear somewhere.

That is all.
Joe

[jmihalich]

By the way, this is a question coming out of the many hours I wasted on the moronic screw up on our side.

Would the jboss classes parsing the manifest files have logged anything useful if I turned on TRACE logging for the relevant packages? If so, at least I know that for next time, as I just thought of that now. If not, is it possible to either have it log problems with parsing the manifest file, or throw exceptions that tell me more about what the problem is rather than just:
org.jboss.deployment.DeploymentException: No ClassLoaders found for ?

Either of those would have saved me hours of debugging.

Thanks,
Joe

[jmihalich]

Well, the answer to my first question is yes. trace or debug mode logging on org.jboss is dumping a lot of information about the manifest file.

Joe