[JBoss-user] Lost the HTMLAdaptor

[Mark.Gargan]

Hi folks,           The other day I attempted to deploy a webservice into a Jboss4.0 alpha build I created from a nightly snapshot. Anyway it all went horribly wrong and now anytime I boot up the server, the jmx-console module can’t deploy as it says that It can’t find the org.jboss.jmx.html.HtmlAdaptorServlet, however this servlet is sitting in the WEB-INF/classes directory of the jmx-console.war In the deploy directory. Here’s the trace…   : : CLASSPATH being used is ;c:\j2sdk1.4.1_01\lib\tools.jar;C:\java\jboss-head\build\output\jboss-4.0.0alpha\bin\\run.jar   16:15:36,462 INFO  [Manager] cloning Manager: [EMAIL PROTECTED] 16:15:36,462 INFO  [JBossWebApplicationContext] setDistributableSessionManager [EMAIL PROTECTED] 16:15:36,727 INFO  [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationContext=1,context=/jmx-console 16:15:38,462 INFO  [jbossweb] Started WebApplicationContext[/jmx-console,file:/C:/java/jboss-head/build/output/jboss-4.0.0alpha/server/default/d eploy/jmx-console.war/] 16:15:38,493 INFO  [jbossweb] Stopped WebApplicationContext[/jmx-console,file:/C:/java/jboss-head/build/output/jboss-4.0.0alpha/server/default/d eploy/jmx-console.war/] 16:15:38,493 INFO  [jbossweb] Deregister jboss.web:Jetty=0,JBossWebApplicationContext=1,context=/jmx-console 16:15:38,493 INFO  [jbossweb] Successfully undeployed file:/C:/java/jboss-head/build/output/jboss-4.0.0alpha/server/default/deploy/jmx-console.w ar/ 16:15:38,509 WARN  [ServiceController] Problem starting service jboss.deployment:name=file%3a/C%3a/java/jboss-head/build/output/jboss-4.0.0alpha /server/default/deploy/jmx-console.war/,service=DeploymentInfo org.jboss.deployment.DeploymentException: org.jboss.jmx.adaptor.html.HtmlAdaptorServlet; - nested throwable: (java.lang.ClassNotFoundException: org.jboss.jmx.adaptor.html.HtmlAdaptorServlet)         at org.jboss.jetty.Jetty.deploy(Jetty.java:359)         at org.jboss.jetty.JettyService.performDeploy(JettyService.java:250)         at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:315)         at org.jboss.deployment.DeploymentInfo.start(DeploymentInfo.java:259)         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.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:72)         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:56)         at org.jboss.mx.server.Invocation.invoke(Invocation.java:81)         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:160)         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:559)         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:993)         at $Proxy12.start(Unknown Source)         at org.jboss.system.ServiceController.start(ServiceController.java:388)         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)   Notice how it attempts to start the web application context and then immediately stops it again? I’ve removed all the offending webservices that caused this in the first place.   In an attempt to see if my classpath had changed I build a clean version from the snapshot and inserted a statement to print out the classpath just before the exception occurs in the Badbuild. Sure enough with the fresh build it started up fine and had no problems deploying the jmx-console. The classpath is as in the first line of the stack trace. The classpath values were the same at the same point in the fresh build and the bad build.   Has anyone any ideas what might have caused this? I can’t go rebuilding the whole head each time this occurs cos it takes the guts of 5 mins a go on my machine (for which I suppose I should be thankful ;) )   Thanks, Mark.