I'm working on a web service built-in with AXIS jars (I mean, it's not using the jboss-net files). However, I upgraded from JBOSS 3.2.1 (here it worked just fine) to 3.2.2, but when I redeploy my web service application, any invocation result in the trace error on server below.

But this only happens when I redeploy because if I restart jboss it works just fine. The only issue is that I'm using the standard Axis version that it should work just fine in a simple servlet container as TOMCAT server.

OK. You're using JBoss.NET. I was under the impression that it was just the basic Axis (not JBoss.NET) service.

Two things to test: -Does the service work again if you touch jboss-net.sar/META-INF/jboss-service.xml (when JBoss.NET is redeployed)?Does the service work again if you touch jboss-service.xml for your servlet container (Tomcat/Jetty SAR)?

The classloading behaviour has changed somewhat in this release. I suspect that something is getting tangled up in the redeploy of the WAR.

I guess you can try a few other things:Have you tried putting the Axis library in JBOSS_HOME/server/default/lib? This would stop the system trying to redeploy the Axis classes - I suspect this is probably the thing getting stuck during the deploy/undeploy. Besides, you possibly don't want to redeploy this library all the time - unless there is some purist objection to this restructure.Did causing Tomcat to redeploy (which should cause your WAR to redeploy after it) change anything?Have you tried using the loader repository?Have you tried 3.2.3RC1?

I would do these in order, as the amount of work increases as you go along.

> I guess you can try a few other things:> Have you tried putting the Axis library in> JBOSS_HOME/server/default/lib? This would stop the> system trying to redeploy the Axis classes - I> suspect this is probably the thing getting stuck> during the deploy/undeploy. Besides, you possibly> don't want to redeploy this library all the time -> unless there is some purist objection to this> restructure.

Done. Still not working.

> Did causing Tomcat to redeploy (which should cause> your WAR to redeploy after it) change anything?

Redeploy tomcat? ... I "touched" the directory of tomcat (${JBOSS_HOME}/server/all/deploy/jbossweb-tomcat41.sar) but I didn't saw any log of redeployment on server.log ...I even tried but still not working.

In order to redeploy the exploded SAR, you need to "touch" the META-INF/jboss-service.xml in the SAR. It would be interesting to see if this has any effect as the breakage in your case seems to be at the servlet container end.

There are a few forum postings on setting up the loader repository. Look at the DTD again in the area of the java 2 classloading compliance for a start on the loader repository. Unfortunately, I've got an early start today so I'm signing off. Otherwise if you need help with that and can't get anywhere searching the forums, post it as a different topic and someone should be able to help out.

I should note that I use Axis configured as per the technote, with a Java class and helper deployed in it (not a JWS deployment). I can redeploy the Axis service (by touching the web.xml) and it comes back up fine under JBoss 3.2.2. I'm using Jetty, IBM SDK 1.4.1 and it is running under Slackware Linux 9.1. Fro an operational perspective, it should not be much different from your custom WAR so I'm not quite sure why there is a classloading issue. Since it isn't the Axis library, it may be one of your other libraries in the WAR getting locked nad unable to be properly loaded/unloaded. You could experiment I guess to see which library it is and whether the objects created from the library are being unloaded. You'd need to use some memory profilers for this.

I tried to find out what could be the problem on the 3.2.2 version since the previous stable release (3.2.1) hadn't this problem. I've posted in jboss-user mailing list and I got something about this issue:

"This is a known issue. Axis has made some bug fixing and I know they have been backported in 3.2.3RC1 (if you use JBossNET) "-- replied by Stephane Nicoll

I have a similar problem, except that it happens for me with my EntityBeans. With 3.2.2, if I re-deploy my EAR without re-starting the server, I get something like the following each time an EntityBean is referenced:

2003-11-21 14:04:51,605 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException in method: public abstract java.lang.Integer com.allegis.ats.entity.user.UserEntity.getUserPositionID(), causedBy:java.lang.NullPointerException at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:2953) at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:3107) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.setObject(WrappedPreparedStatement.java:620) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.setParameter(JDBCUtil.java:1278) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setArgumentParameters(JDBCAbstractCMPFieldBridge.java:338) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setPrimaryKeyParameters(JDBCAbstractCMPFieldBridge.java:327) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.setPrimaryKeyParameters(JDBCEntityBridge.java:616) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:154) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:76) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:577) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:559) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:381)...

By the way, the only reason I'm even looking into migrating from 3.2.1 to 3.2.2 is because with 3.2.1 we frequently, but not always get a NoClassDefFoundError the first time any code attempts to access the Oracle database after a re-deploy. I've never seen any of these problems except in the case of "hot deployment", which has been a highly touted feature of JBoss for years now, but has yet to stabilize, at least for the 3.2 version. Believe me, I understand how difficult it is to get classloading 100% correct, as I've had to write my own classloader hierarchies myself and still have nightmares :-) So, I'm not about to be too critical on this one. I just think this one seems fairly critical to prioritize, as it's made several people here a little uneasy about deploying JBoss with this behavior into production. Not saying we won't, just that I'd feel a lot better if hot deployment worked. I think there may be a bug logged for the 3.2.1 problem, but not sure. If I have time after the upcoming holiday week, I'll try to get more detail and log a bug, if one isn't already logged.