- This topic has 19 replies, 7 voices, and was last updated 17 years, 11 months ago by Richard Weston.
-
AuthorPosts
-
monocongoMemberI am trying to start JBoss from the workbench and getting the following exception:
15:21:36,577 ERROR [MainDeployer] Could not initialise deloyment: file:/C:/jboss-3.2.3/server/default/conf/jboss-service.xml
org.jboss.deployment.DeploymentException: Document root element is missing.; – nested throwable: (org.xml.sax.SAXParseException: Document root element is missing.)However I can run JBoss just fine from my desktop. So it appears that MyEclipse is doing something different and is unable to make it past the jboss-service.xml file, which appears to be OK otherwise.
Is this a known issue ? Is there a workaround for this ? I would like to be able to debug an application running in JBoss, but I can’t get this first step to work.
Any feedback will be appreciated, thanks in advance.
-James
Riyad KallaMemberJames,
Hmm nope this isn’t currently a known issue AFAIK. When you open the file in the error above, can you paste it into a new XML file in MyEclipse and validate it to see if its valid? The “Document root element is missing” certain looks like a big enough problem to warrent a double check of that file.
monocongoMemberI can edit and save the file (jboss-service.xml) with no trouble in the MyEclipse XML editor, all elements are highlighted correctly, etc. Is this enough to show XML validity, or is there another validation menu choice somewhere ?
Thanks…
Riyad KallaMemberAhh yea, the file needs to have a DOCTYPE directive at the top, then you can right click and select “Validate”.
monocongoMemberI can’t find the DTD to use in the DOCTYPE directive, can you advise ?
Is MyEclipse doing an additional validation of the JBoss XML files before allowing the server to process them ? Why doesn’t the error happen when running JBoss from the command line ?
Thanks…
Riyad KallaMemberMyEclipse does not do additional validation, the error you are seeing is from the server’s startup. MyEclipse’s server connectors just startup the server in the same fashion that its startup scripts do, so any parsing or validation exceptions are actually from the server itself while its attempting to parse its own config file…
I’m not sure why this isn’t happening on the command line unless there are some command line switches being set in the bat file that you areu sing to run JBoss?
Also if there is no doctype at the top of the XML file, then you might want to check the JBoss or google to see if there IS a defined DTD for that XML file, or if its just a free form file without a DTD (like Ant scripts).
Riyad KallaMemberJames,
Are you sure that you setup the correct connector for JBoss? (JBoss 3) also are you using a JDK to launch it? What version of Eclipse, MyEclipse and JDK are you using?Also could you paste your jboss-service.xml file into a message here for us to look at?
monocongoMemberI think I have set up the connector, in that I have set the correct JBoss home directory, server name, XML document builder factory class, etc. The JDK being used to launch it is JDK 1.4.2_03, the Eclipse version is 3.0, MyEclipse version 3.7.2.
Below is the jboss-service.xml:
<?xml version="1.0" encoding="UTF-8"?> <!-- $Id: jboss-service.xml,v 1.59.2.41 2003/11/15 17:08:35 pilhuhn Exp $ --> <!-- ===================================================================== --> <!-- JBoss Server Configuration --> <!-- ===================================================================== --> <server> <!-- Load all jars from the JBOSS_DIST/server/<config>/lib directory. This can be restricted to specific jars by specifying them in the archives attribute. --> <classpath codebase="lib" archives="*"/> <!-- ==================================================================== --> <!-- JSR-77 Single JBoss Server Management Domain --> <!-- ==================================================================== --> <mbean code="org.jboss.management.j2ee.LocalJBossServerDomain" name="jboss.management.local:j2eeType=J2EEDomain,name=Manager"> <attribute name="MainDeployer">jboss.system:service=MainDeployer</attribute> <attribute name="SARDeployer">jboss.system:service=ServiceDeployer</attribute> <attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute> <attribute name="EJBDeployer">jboss.ejb:service=EJBDeployer</attribute> <attribute name="RARDeployer">jboss.jca:service=RARDeployer</attribute> <attribute name="CMDeployer">jboss.jca:service=ConnectionFactoryDeployer</attribute> <attribute name="WARDeployer">jboss.web:service=WebServer</attribute> <attribute name="MailService">jboss:service=Mail</attribute> <attribute name="JMSService">jboss.mq:service=DestinationManager</attribute> <attribute name="JNDIService">jboss:service=Naming</attribute> <attribute name="JTAService">jboss:service=TransactionManager</attribute> <attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute> <attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute> </mbean> <!-- Preload all custom editors for VMs that don't use the thread context class loader when searching for PropertyEditors. Uncomment if your JDK 1.3.0 VM fails to find JBoss PropertyEditors. <mbean code="org.jboss.varia.property.PropertyEditorManagerService" name="jboss:type=Service,name=BootstrapEditors"> <attribute name="BootstrapEditors"> java.math.BigDecimal=org.jboss.util.propertyeditor.BigDecimalEditor java.lang.Boolean=org.jboss.util.propertyeditor.BooleanEditor java.lang.Class=org.jboss.util.propertyeditor.ClassEditor java.util.Date=org.jboss.util.propertyeditor.DateEditor java.io.File=org.jboss.util.propertyeditor.FileEditor java.net.InetAddress=org.jboss.util.propertyeditor.InetAddressEditor java.lang.Integer=org.jboss.util.propertyeditor.IntegerEditor javax.management.ObjectName=org.jboss.mx.util.propertyeditor.ObjectNameEditor java.util.Properties=org.jboss.util.propertyeditor.PropertiesEditor [Ljava.lang.String;=org.jboss.util.propertyeditor.StringArrayEditor java.net.URL=org.jboss.util.propertyeditor.URLEditor </attribute> </mbean> --> <!-- ==================================================================== --> <!-- Log4j Initialization --> <!-- ==================================================================== --> <mbean code="org.jboss.logging.Log4jService" name="jboss.system:type=Log4jService,service=Logging"> <attribute name="ConfigurationURL">resource:log4j.xml</attribute> <!-- Set the org.apache.log4j.helpers.LogLog.setQuiteMode. As of log4j1.2.8 this needs to be set to avoid a possible deadlock on exception at the appender level. See bug#696819. --> <attribute name="Log4jQuietMode">true</attribute> </mbean> <!-- ==================================================================== --> <!-- JBoss RMI Classloader - only install when available --> <!-- ==================================================================== --> <mbean code="org.jboss.util.property.jmx.SystemPropertyClassValue" name="jboss.rmi:type=RMIClassLoader"> <attribute name="Property">java.rmi.server.RMIClassLoaderSpi</attribute> <attribute name="ClassName">org.jboss.system.JBossRMIClassLoader</attribute> </mbean> <!-- ==================================================================== --> <!-- Service Binding --> <!-- ==================================================================== --> <!-- Automatically activated when generatting the clustering environment --> <!-- @TESTSUITE_CLUSTER_CONFIG@ --> <!-- | Binding service manager for port/host mapping. This is a sample | config that demonstrates a JBoss instances with a server name 'jboss1' | loading its bindings from an XML file using the ServicesStoreFactory | implementation returned by the XMLServicesStoreFactory. | | ServerName: The unique name assigned to a JBoss server instance for | lookup purposes. This allows a single ServicesStore to handle mulitiple | JBoss servers. | | StoreURL: The URL string passed to org.jboss.services.binding.ServicesStore | during initialization that specifies how to connect to the bindings store. | StoreFactory: The org.jboss.services.binding.ServicesStoreFactory interface | implementation to create to obtain the ServicesStore instance. <mbean code="org.jboss.services.binding.ServiceBindingManager" name="jboss.system:service=ServiceBindingManager"> <attribute name="ServerName">ports-01</attribute> <attribute name="StoreURL">../docs/examples/binding-manager/sample-bindings.xml</attribute> <attribute name="StoreFactoryClassName"> org.jboss.services.binding.XMLServicesStoreFactory </attribute> </mbean> --> <!-- ==================================================================== --> <!-- Class Loading --> <!-- ==================================================================== --> <mbean code="org.jboss.web.WebService" name="jboss:service=WebService"> <attribute name="Port">8083</attribute> <!-- Should resources and non-EJB classes be downloadable --> <attribute name="DownloadServerClasses">true</attribute> <attribute name="Host">${jboss.bind.address}</attribute> <attribute name="BindAddress">${jboss.bind.address}</attribute> </mbean> <!-- ==================================================================== --> <!-- JNDI --> <!-- ==================================================================== --> <mbean code="org.jboss.naming.NamingService" name="jboss:service=Naming"> <!-- The listening port for the bootstrap JNP service. Set this to -1 to run the NamingService without the JNP invoker listening port. --> <attribute name="Port">1099</attribute> <!-- The bootstrap JNP server bind address. This also sets the default RMI service bind address. Empty == all addresses --> <attribute name="BindAddress">${jboss.bind.address}</attribute> <!-- The port of the RMI naming service, 0 == anonymous --> <attribute name="RmiPort">1098</attribute> <!-- The RMI service bind address. Empty == all addresses --> <attribute name="RmiBindAddress">${jboss.bind.address}</attribute> </mbean> <mbean code="org.jboss.naming.JNDIView" name="jboss:service=JNDIView" xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml"> </mbean> <!-- ==================================================================== --> <!-- Security --> <!-- ==================================================================== --> <mbean code="org.jboss.security.plugins.SecurityConfig" name="jboss.security:service=SecurityConfig"> <attribute name="LoginConfig">jboss.security:service=XMLLoginConfig</attribute> </mbean> <mbean code="org.jboss.security.auth.login.XMLLoginConfig" name="jboss.security:service=XMLLoginConfig"> <attribute name="ConfigResource">login-config.xml</attribute> </mbean> <!-- JAAS security manager and realm mapping --> <mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name="jboss.security:service=JaasSecurityManager"> <attribute name="SecurityManagerClassName"> org.jboss.security.plugins.JaasSecurityManager </attribute> </mbean> <!-- ==================================================================== --> <!-- Transactions --> <!-- ==================================================================== --> <!-- The configurable Xid factory. For use with Oracle, set pad to true --> <mbean code="org.jboss.tm.XidFactory" name="jboss:service=XidFactory"> <!--attribute name="Pad">true</attribute--> </mbean> <!-- | The fast in-memory transaction manager. --> <mbean code="org.jboss.tm.TransactionManagerService" name="jboss:service=TransactionManager" xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml"> <attribute name="TransactionTimeout">300</attribute> <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends> </mbean> <!-- | UserTransaction support. --> <mbean code="org.jboss.tm.usertx.server.ClientUserTransactionService" name="jboss:service=ClientUserTransaction" xmbean-dd="resource:xmdesc/ClientUserTransaction-xmbean.xml"> <depends> <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory" name="jboss:service=proxyFactory,target=ClientUserTransactionFactory"> <attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute> <attribute name="TargetName">jboss:service=ClientUserTransaction</attribute> <attribute name="JndiName">UserTransactionSessionFactory</attribute> <attribute name="ExportedInterface">org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory</attribute> <attribute name="ClientInterceptors"> <interceptors> <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor> <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> </interceptors> </attribute> <depends>jboss:service=invoker,type=jrmp</depends> </mbean> </depends> <depends optional-attribute-name="TxProxyName"> <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory" name="jboss:service=proxyFactory,target=ClientUserTransaction"> <attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute> <attribute name="TargetName">jboss:service=ClientUserTransaction</attribute> <attribute name="JndiName"></attribute> <attribute name="ExportedInterface">org.jboss.tm.usertx.interfaces.UserTransactionSession</attribute> <attribute name="ClientInterceptors"> <interceptors> <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor> <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> </interceptors> </attribute> <depends>jboss:service=invoker,type=jrmp</depends> </mbean> </depends> </mbean> <!-- ==================================================================== --> <!-- Invokers to the JMX node --> <!-- ==================================================================== --> <!-- RMI/JRMP invoker --> <mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker" name="jboss:service=invoker,type=jrmp"> <attribute name="RMIObjectPort">4444</attribute> <attribute name="ServerAddress">${jboss.bind.address}</attribute> <!-- <attribute name="RMIClientSocketFactory">custom</attribute> <attribute name="RMIServerSocketFactory">custom</attribute> <attribute name="SecurityDomain">ssl-domain-name</attribute> --> <depends>jboss:service=TransactionManager</depends> </mbean> <mbean code="org.jboss.invocation.local.LocalInvoker" name="jboss:service=invoker,type=local"> <depends>jboss:service=TransactionManager</depends> </mbean> <mbean code="org.jboss.invocation.pooled.server.PooledInvoker" name="jboss:service=invoker,type=pooled"> <attribute name="NumAcceptThreads">1</attribute> <attribute name="MaxPoolSize">300</attribute> <attribute name="ClientMaxPoolSize">300</attribute> <attribute name="SocketTimeout">60000</attribute> <attribute name="ServerBindAddress">${jboss.bind.address}</attribute> <attribute name="ServerBindPort">4445</attribute> <attribute name="ClientConnectAddress">${jboss.bind.address}</attribute> <attribute name="ClientConnectPort">0</attribute> <attribute name="EnableTcpNoDelay">false</attribute> <depends optional-attribute-name="TransactionManagerService">jboss:service=TransactionManager</depends> </mbean> <!-- ==================================================================== --> <!-- The deployers... --> <!-- ==================================================================== --> <!-- EJB deployer, remove to disable EJB behavior--> <mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer"> <attribute name="VerifyDeployments">true</attribute> <attribute name="ValidateDTDs">false</attribute> <attribute name="MetricsEnabled">false</attribute> <attribute name="VerifierVerbose">true</attribute> <!-- StrictVerifier: Setting this to 'true' will cause all deployments to fail when the Verifier detected a problem with the contained Beans. --> <attribute name="StrictVerifier">true</attribute> <depends optional-attribute-name="TransactionManagerServiceName">jboss:service=TransactionManager</depends> <depends optional-attribute-name="WebServiceName">jboss:service=WebService</depends> </mbean> <!-- EAR deployer, remove if you are not using Web layers --> <mbean code="org.jboss.deployment.EARDeployer" name="jboss.j2ee:service=EARDeployer"> </mbean> <mbean code="org.jboss.varia.deployment.BeanShellSubDeployer" name="jboss.scripts:service=BSHDeployer"> </mbean> <!-- ==================================================================== --> <!-- Monitoring and Management --> <!-- ==================================================================== --> <!-- Uncomment to enable JMX monitoring of the bean cache <mbean code="org.jboss.monitor.BeanCacheMonitor" name="jboss.monitor:name=BeanCacheMonitor"/> --> <!-- Uncomment to enable JMX monitoring of the entity bean locking <mbean code="org.jboss.monitor.EntityLockMonitor" name="jboss.monitor:name=EntityLockMonitor"/> --> <!-- ==================================================================== --> <!-- Deployment Scanning --> <!-- ==================================================================== --> <!-- An mbean for hot deployment/undeployment of archives. --> <mbean code="org.jboss.deployment.scanner.URLDeploymentScanner" name="jboss.deployment:type=DeploymentScanner,flavor=URL"> <!-- Uncomment (and comment/remove version below) to enable usage of the DeploymentCache <depends optional-attribute-name="Deployer">jboss.deployment:type=DeploymentCache</depends> --> <depends optional-attribute-name="Deployer">jboss.system:service=MainDeployer</depends> <!-- The URLComparator can be used to specify a deployment ordering for deployments found in a scanned directory. The class specified must be an implementation of java.util.Comparator, it must be able to compare two URL objects, and it must have a no-arg constructor. Two deployment comparators are shipped with JBoss: - org.jboss.deployment.DeploymentSorter Sorts by file extension, as follows: "sar", "service.xml", "rar", "jar", "war", "wsr", "ear", "zip", "*" - org.jboss.deployment.scanner.PrefixDeploymentSorter If the name portion of the url begins with 1 or more digits, those digits are converted to an int (ignoring leading zeroes), and files are deployed in that order. Files that do not start with any digits will be deployed first, and they will be sorted by extension as above with DeploymentSorter. --> <!-- The below setting makes the deployment of SAR files which are prefixed with digits come last --> <!-- This is what enables us to deploy our UserManager MBean under the deploy directory as 1000UserManager.sar --> <!-- Not sure exactly why this approach is required, but it is --> <!-- <attribute name="URLComparator">org.jboss.deployment.DeploymentSorter</attribute> --> <attribute name="URLComparator">org.jboss.deployment.scanner.PrefixDeploymentSorter</attribute> <!-- The Filter specifies a java.io.FileFilter for scanned directories. Any file not accepted by this filter will not be deployed. The org.jboss.deployment.scanner.DeploymentFilter rejects the following patterns: "#*", "%*", ",*", ".*", "_$*", "*#", "*$", "*%", "*.BAK", "*.old", "*.orig", "*.rej", "*.bak", "*,v", "*~", ".make.state", ".nse_depinfo", "CVS", "CVS.admin", "RCS", "RCSLOG", "SCCS", "TAGS", "core", "tags" --> <attribute name="Filter">org.jboss.deployment.scanner.DeploymentFilter</attribute> <attribute name="ScanPeriod">5000</attribute> <!-- URLs are comma separated and resolve relative to the server home URL unless the given path is absolute. If the URL ends in "/" it is considered a collection and scanned, otherwise it is simply deployed; this follows RFC2518 convention and allows discrimination between collections and directories that are simply unpacked archives. URLs may be local (file:) or remote (http:). Scanning is supported for remote URLs but unpacked deployment units are not. Example URLs: deploy/ scans ${jboss.server.url}/deploy/, which is local or remote depending on the URL used to boot the server ${jboss.server.home}/deploy/ scans ${jboss.server.home)/deploy, which is always local file:/var/opt/myapp.ear deploy myapp.ear from a local location file:/var/opt/apps/ scans the specified directory http://www.test.com/netboot/myapp.ear deploys myapp.ear from a remote location http://www.test.com/netboot/apps/ scans the specified WebDAV location --> <attribute name="URLs"> deploy/ </attribute> <!-- Indicates if the scanner should recursively scan directories that contain no "." in their names. This can be used to group applications and services that must be deployed and that have the same logical function in the same directory i.e. deploy/JMX/ deploy/JMS/ ... --> <attribute name="RecursiveSearch">True</attribute> </mbean> </server>
Scott AndersonParticipantI can edit and save the file (jboss-service.xml) with no trouble in the MyEclipse XML editor,
I’m confused. Are you saying that the jboss-service.xml file is in your workspace? It should be out in your JBoss domain, external to the workspace where you unzipped it. Have you compared your JBoss setup with the example in the FAQ here:
http://www.myeclipseide.com/FAQ+index-myfaq-yes-id_cat-19.html#4Also, please note that for source level JSP debugging to work with JBoss you’ll need version 3.2.4+ since only the later versions included Tomcat 5 rather than Tomcat 4.
monocongoMemberNo I only edited the file in MyEclipse just to see if there were any errors highlighted by the XML editor (there were none).
Thanks for the link — I’ll go through the info to make sure that I’ve done everything as I should have.
monocongoMemberI have verified that everything is as it should be according to the page referenced above (as well as what is described in the Help). It appears that something is still not right – JBoss doesn’t like the jboss-service.xml when I start it from MyEclipse, but when I start JBoss from a command line or shortcut it runs without a error. Can anyone suggest a reason for this, or where I might look for more info ?
My system is running WindowsXP Pro, MyEclipse 3.7.2, Eclipse 3.0.0, JBoss 3.2.3, JDK 1.4.2_03
Thanks for any feedback…
-James
Riyad KallaMemberJames,
I’ve asked our JBoss guy to help you out, please stay tuned.
GregMemberI have searched some jboss information sites and haven’t seen anything like this. I also haven’t been able to replicate it on a test machine. Have you tried a new fresh copy of jboss+myeclipse?
lilinMemberI had the same problem as well. The problem occured when I modified the xml files in JBoss (using UltraEdit – a text editor) for my application to start on a different port. However, I believe the xml files are not of DOS format initially and when I saved them after making the modification, the xml file is somehow altered, thus, causing the errors mentioned above.
I resolved the problem by reverting back to the original XML and making changes to them jus using Notepad.Afterwhich, I can start JBoss from the workbench without any problems. 🙂
Riyad KallaMemberlilin,
This is a very elusive problem and we much appreciate you posting your workaround, definately an easy-to-miss solution!Thanks again.
-
AuthorPosts