- This topic has 20 replies, 4 voices, and was last updated 19 years, 12 months ago by
.
-
Posts
-
Whenever I try to run our JBoss-based project for debugging through MyEclipse, we see the following exception:
org.jboss.deployment.DeploymentException: Could not parse dd; – nested throwable: (org.xml.sax.SAXParseException: Document root element is missing.)
at org.jboss.deployment.XSLSubDeployer.findDd(XSLSubDeployer.java:268)
at org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:192)
at org.jboss.deployment.MainDeployer.init(MainDeployer.java:696)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:632)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
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.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy6.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:201)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:274)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:394)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:589)
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.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:384)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:291)
at org.jboss.Main.boot(Main.java:150)
at org.jboss.Main$1.run(Main.java:395)
at java.lang.Thread.run(Thread.java:534)It’s complaining about the file we’re using to describe the data source.
A lot of other related complaints follow, but this seems to be the heart of the problem.The exact same configuration starts up without problems from the command line, (regular or debug) and it also used to start without difficulty through the JBoss IDE plugin (regular or debug).
I am using essentially the default settings for JBoss 3, with the exception of having changed the server name to the directory for our project.
I have tried switching from Crimson to Xerces without any impact.
JBoss JDK setting is J2SDK 1.4.2_02
No classpath or library path modifications.
Any clues?
Do you still have the JBossIDE plugin installed? ME uses a modified version of this and currently the two conflict with eachother.
I disabled it, but since that obviously had no effect I removed the plugin directories completely, and that still had no effect.
What gets my attena to stand up is this part:
org.xml.sax.SAXParseException: Document root element is missing.is this a valid descriptor? I know you said it runs fine otherwise, but is it possible that it got edited at some point between your transition from JBossIDE to MyEclipseIDE?
@support-rkalla wrote:
What gets my attena to stand up is this part:
org.xml.sax.SAXParseException: Document root element is missing.is this a valid descriptor? I know you said it runs fine otherwise, but is it possible that it got edited at some point between your transition from JBossIDE to MyEclipseIDE?
That makes me very suspicious, too, but I don’t see how it’s possible. I try from MyEclipse and it fails. Without doing anything else, I try from the command line and it succeeds. The file isn’t being changed.
Having had a certain amount of experience with the vagaries of XML parsing, I’m wondering if the descriptor is passing through some stricter XML parsing or validation when starting through MyEclipse, which would suggest to me some difference in the classpath at startup.
Can you post your XML config file? I’d like to take a look at the structure then compare this to the dtd/schema being used and then pass it through a validator to make sure we are playing with a full deck. I’d hate to havea bunch of people chasing ghosts.
@support-rkalla wrote:
Can you post your XML config file? I’d like to take a look at the structure then compare this to the dtd/schema being used and then pass it through a validator to make sure we are playing with a full deck. I’d hate to havea bunch of people chasing ghosts.
I’m not sure how profitable that exercise will be, since the descriptor cites neither a DTD nor a schema. Our descriptor is based on the hsqldb-ds.xml file supplied with the JBoss 3.2.2 distribution, changed to talk to a MS SQL Server 2000 database instance. Nevertheless, I’ve solicited permission from my management to show you the file, although I’d prefer to mail it rather than post it. Is there an address it should go to?
I agree I’m not convinced its a great solution either. I’ve request Scott/Michael take a look at this as its a weird one and I’m not terribly keen on having someone (you) sending confidential information to us if you don’t need to.
You can send the file to support@genuitec.com and we’ll have a look-see.
Thank you for your patience with this.
A couple of thoughts on this. First, since your datasource file is based on the hsqldb-ds.xml file that is shipped with the JBoss distribution, have you tried simply starting up a default installation of JBoss through MyEclipse, without any external application deployments? Naturally, I can do this without issue and the hsqldb-ds.xml file is read and parsed properly. Testing the same setup against your installation will tell us if the issue is environment or configuration.
One thing to try is a different JDK and to verify that you’re using exactly the same JDK for launching JBoss both inside and outside of Eclipse. You can often run into problems with XML parsing if you’ve used the 1.4 ‘endorsement’ mechanism to change the XML infrastructure in the JDK as this will take precidence over anything you do on the classpath. Often people do this to experiment and then forget about it.
Starting the default server, sans applications, did work.
I’m starting to suspect this has something to do with our utilization of the Sun-supplied reference implementation of JAXB, which we positively cannot do without.
:|, what happens when you clean out the endorsed JARs from your JDK install? If it doesn’t work, would you mind installing a new JDK in another location and configuring Eclipse to use that?
I don’t so far as I can tell, have endorsed jars in my JDK (1.4.2_02) install. I have some that were supplied with the Java Web Services Developer Pack, but we don’t move them over when we create our server directory — we only use them in the course of generating Java bindings for XML schemas. In the scope of a specific Ant target, if you like.
We do move the JAXB jars into the server/xxx/lib directory, where xxx is our application, but moving those out doesn’t seem to affect this problem (not to mention the dire implications it would have for the generated binding code).
It’s good of you guys to try and solve this with so little information. I wish I could be more obliging, but my current situation doesn’t allow for disrupting my development environment to the point of trying things like different JDKs.
It’s good of you guys to try and solve this with so little information
Well we appreciate your patience.
Ok I just ran the WSDP installer to see what it asks you to do, so try and undo (temporarily) these steps:
1) Unset the ‘java.endorsed.dirs’ system property. A quick way to do this (on windows) Win+Pause->Advanced->Env. Variables->Find it, select it and change its name to ‘java.endorsed.dirs_OLD’ or something invalid like that.
2) You may have a dir, <JAVA_HOME>/jre/lib/endorsed, rename that last dir from ‘lib’ to ‘lib_OLD’, again something invalid but easy to revert
3) Restart computer (just incase)
4) Give everything a go.Does it work? If not we can fly Scott out there to come live with you and fix the problem (you have to feed him though) 😀
