Bugs item #669112, was opened at 2003-01-16 15:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669112&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: Rejected
Priority: 7
Submitted By: Andrew Everitt (andieveritt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Server.log not created when using xerces
Initial Comment:
If JBoss is installed into a path with a space in the
name (e.g. C:\Program Files\JBoss) and you are using
Xerces as the JAXP implementation the server.log file
is not created. All logging is written to boot.log.
I see the following exception on the screen (but not in
boot.log):
16:04:35,656 INFO [Log4jService$URLWatchTimerTask]
Configuring from URL: resource:log4j.xml
log4j:ERROR Could not parse input source
[EMAIL PROTECTED]
java.net.MalformedURLException: no protocol: log4j.dtd
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807)
at
org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:767)
at
org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581)
at
org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at
org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:672)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:602)
at
org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:704)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:486)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:425)
at
org.jboss.logging.Log4jService.startService(Log4jService.java:281)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:164)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:397)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy3.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:249)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:802)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:221)
at
com.xms.install.jboss.JBossJService.bootJBoss(JBossJService.java:139)
at
com.xms.install.jboss.JBossJService.start(JBossJService.java:64)
----------------------------------------------------------------------
>Comment By: Ceki Gulcu (cgu)
Date: 2003-03-18 14:53
Message:
Logged In: YES
user_id=14048
Have your tried using log4j version 1.2.8. It should normally
solve this problem.
--
Ceki
----------------------------------------------------------------------
Comment By: Ceki Gulcu (cgu)
Date: 2003-03-18 14:01
Message:
Logged In: YES
user_id=14048
Does log4j 1.2.8 solve the problem? It normally should.
--
Ceki
----------------------------------------------------------------------
Comment By: Andrew Everitt (andieveritt)
Date: 2003-02-28 08:48
Message:
Logged In: YES
user_id=689882
Luke,
With respect I don't think saying 'simply install to a path
without spaces' is good enough.
If JBoss is to be used as a realistic production J2EE server
it needs to work on standard platforms - including Windows.
On Windows the expected behaviour for applications is to
install into C:\Program Files\AppName.
Although the route cause lies in Java itself Sun have stated
that they won't resolve the bug in java.net.URL. I have
proposed a fix in jboss-Bugs-676243 which will work with any
path that doesn't contain a '%' (illegal on most file
systems anyway). That fix clears up all the issues that I
have found and I believe is 'safe' and should be applied.
----------------------------------------------------------------------
Comment By: Luke Taylor (luke_t)
Date: 2003-02-27 23:27
Message:
Logged In: YES
user_id=369802
This (installing in a path with spaces) has been mentioned
many times in the forums and elsewhere. If it really is
"critical" then simply install to a path without spaces. So
closing.
----------------------------------------------------------------------
Comment By: Andrew Everitt (andieveritt)
Date: 2003-02-26 10:14
Message:
Logged In: YES
user_id=689882
This problem is closely related to:
[ jboss-Bugs-676243 ] FileURLConnection needs URL decode for
JDK 1.4
I am now using Xerces 2.3.0 which still has problems related
to URL encoding of spaces in paths. However the problems
route cause seems to by the JDK itself, see:
http://developer.java.sun.com/developer/bugParade/bugs/4273532.html
Which seems to explain at length why java.net.URL is
inconsistent!
----------------------------------------------------------------------
Comment By: Andrew Everitt (andieveritt)
Date: 2003-02-20 17:43
Message:
Logged In: YES
user_id=689882
This problem is resolved with Xerces 2.3.0.
However there are then a lot of deployment failures with
'%20' getting in the paths instead of spaces. I will raise a
new bug for that issue when I understand it a little more.
----------------------------------------------------------------------
Comment By: Andrew Everitt (andieveritt)
Date: 2003-01-28 18:28
Message:
Logged In: YES
user_id=689882
This problem is critical for me. I need to use the latest
version of Xerces because the version that ships with JBoss
3.2 has a bug with respect to creating DOCTYPE objects. That
bug is fixed in Xerces 2.2.1 but unfourtunately creates the
problem that this bug is about.
I have now tried with the latest version of Xerces (2.3.0)
which fixes the logging problem but breaks the JBoss web
service. I have traced that to a bug in
org.jboss.net.protocol.file.FileURLConnection caused by JDK
1.4 URL encoding stuff. I have raised that as a separate bug:
[ 676243 ] FileURLConnection needs URL decode for JDK 1.4
Which includes a fix which works for me.
----------------------------------------------------------------------
Comment By: Andrew Everitt (andieveritt)
Date: 2003-01-17 18:56
Message:
Logged In: YES
user_id=689882
1 long day later ...
I am making progress, this problem is logged as a bug with
Log4J, see their bug Id 12366 (Cannot use Xerces 2.1.0 with
XML configuration file because the file is not referred to
as a URL by Log4J.)
It seems that Log4j's method of switching the DTD location
so it loads from the Log4j jar got broken in Xerces 2.1
(InputSource.setSystemId() not working correctly).
There is a bug raised for xerces:
Bug 12845 MalformedURLException if DTD in directory with a
space in the path
I guess when Xerces fix that bug this problem will go away.
----------------------------------------------------------------------
Comment By: Andrew Everitt (andieveritt)
Date: 2003-01-16 16:28
Message:
Logged In: YES
user_id=689882
It appears that this isn't a problem with the version of
Xerces shipped with 3.2.0 beta 3. It also works fine with
Xerces v2.0.1.
This behaviour is seen with Xerces 2.1.0 and Xerces 2.2.1.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=669112&group_id=22866
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
