Skip to main content

Updated web server in trunk

10 replies [Last post]
kaplanj
Offline
Joined: 2004-07-13

I just committed an updated web server to trunk rev 4323. This new webserver requires changes to the security-session-auth module to maintain compatibility with Wonderland trunk. If you use authentication, please be sure to update the security-session-auth module to rev 1446 or later. The version in the module warehouse has already been updated.

This is a fairly major change. It brings us from using a customized version of an old Glassfish snapshot to using an unmodified version of the Glassfish v3 embedded release. This should be more stable, and allow us to use more features of the embedded web server.

Of course in the short term this change will probably cause some small problems. Please report any issues you run into here, so we can try to fix them as quickly as possible.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
danthedixonman
Offline
Joined: 2008-05-28

Hi Jon - I get the following lines when trying to start the server:

[java] 22/01/2010 12:32:32 AM com.sun.enterprise.security.ssl.SSLUtils checkCertificateDates
[java] SEVERE: java_security.expired_certificate

It also then proceeds to throw an exception with the DTD stuff which just keeps repeating. This machine is behind a proxy, but we also need the ability to not require internet access. I've tried this both on 64-bit Ubuntu and Windows XP and get the same result and I'm not using the authentication module.

[java] 21/01/2010 1:56:02 PM com.sun.enterprise.deployment.io.DeploymentDescriptorFile read
[java] SEVERE: enterprise.deployment.backend.saxParserError
[java] 21/01/2010 1:56:02 PM org.glassfish.api.ActionReport failure
[java] SEVERE: Exception while deploying the app
[java] java.io.IOException: Unable to locate the DTD to validate your deployment descriptor file [WEB-INF/sun-web.xml] in archive [wonderland-web-asset.war]. Please make sure the DOCTYPE is correct (no typo in public ID or system ID) and you have proper access to the Internet.
[java] at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:335)
[java] at com.sun.enterprise.deployment.archivist.Archivist.readRuntimeDeploymentDescriptor(Archivist.java:662)
[java] at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:171)
[java] at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:155)
[java] at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:78)
[java] at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:612)
[java] at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:554)
[java] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:262)
[java] at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:214)
[java] at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:144)
[java] at org.jdesktop.wonderland.webserver.WonderlandAppServer.deploy(WonderlandAppServer.java:95)
[java] at org.jdesktop.wonderland.webserver.WonderlandAppServer.deploy(WonderlandAppServer.java:104)
[java] at org.jdesktop.wonderland.webserver.RunAppServer.deployWebApps(RunAppServer.java:228)
[java] at org.jdesktop.wonderland.webserver.RunAppServer.(RunAppServer.java:97)
[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[java] at java.lang.Class.newInstance0(Class.java:355)
[java] at java.lang.Class.newInstance(Class.java:308)
[java] at org.jdesktop.wonderland.webserver.launcher.WebServerLauncher.main(WebServerLauncher.java:194)
[java] Caused by: java.net.ConnectException: Connection timed out: connect
[java] at java.net.PlainSocketImpl.socketConnect(Native Method)
[java] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
[java] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
[java] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
[java] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
[java] at java.net.Socket.connect(Socket.java:519)
[java] at java.net.Socket.connect(Socket.java:469)
[java] at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
[java] at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
[java] at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
[java] at sun.net.www.http.HttpClient.(HttpClient.java:233)
[java] at sun.net.www.http.HttpClient.New(HttpClient.java:306)
[java] at sun.net.www.http.HttpClient.New(HttpClient.java:323)
[java] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:837)
[java] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:778)
[java] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:703)
[java] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1026)
[java] at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:677)
[java] at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1315)
[java] at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1282)
[java] at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:283)
[java] at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1192)
[java] at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1089)
[java] at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1002)
[java] at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
[java] at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
[java] at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
[java] at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
[java] at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
[java] at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
[java] at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
[java] at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
[java] at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
[java] at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:298)
[java] ... 20 more
[java] classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)

[java] SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@a00fd

kaplanj
Offline
Joined: 2004-07-13

Before this update, we had special code to handle this in Glassfish. The code is pretty ugly, so I was hoping this problem would fix itself. It obviously didn't... I'll investigate a better fix or just put back the old one. Updates will be here:

https://wonderland.dev.java.net/issues/show_bug.cgi?id=1124

danthedixonman
Offline
Joined: 2008-05-28

Thanks Jon - will keep an eye on it. In the mean time will sticking the old glassfish jar file in there make things work or should I just roll back a few revisions and sit tight (although Joe fixed some other stuff I needed which prompted me to get the latest trunk anyway......) ;-)

kaplanj
Offline
Joined: 2004-07-13

I have no idea if this will work, but you could try setting the Java proxy properties in my.run.properties. This may allow the web server to download the necessary .dtd files using the proxy. The properties are:

http.proxyHost
http.proxyPort

More information on proxy settings in Java (a personal favorite topic, as evidenced by bug 222 :-) ):

http://java.sun.com/javase/6/docs/technotes/guides/net/proxies.html

danthedixonman
Offline
Joined: 2008-05-28

Thanks Jon - this works if I set 'Direct Connection' in the Java Console and set a proxy that doesn't need authentication. The usual proxy I use (ie not 700km or ~434 miles away) requires authentication.

Any ideas on how to use an authenticated proxy?

kaplanj
Offline
Joined: 2004-07-13

I don't know about the authenticated proxy -- I know we had code to handle that in Wonderland 0.4, but it would take a while to track down :-)

In the meantime, rev 4324 should fix the original issue by including the required DTDs locally. Let me know if that works for you.

danthedixonman
Offline
Joined: 2008-05-28

Cheers Jon. The update to 4324 works fine as far as I can see (apart from being exceptionally slow to load....... 30-45 mins when it used to take a few minutes tops!). I assume it's something timing out.

I see a lot of the following:

[java] 23/01/2010 12:53:49 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:54:04 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:54:19 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:54:34 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:54:49 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:55:04 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:55:19 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:55:34 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:55:43 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] 23/01/2010 12:55:53 AM org.jdesktop.wonderland.webserver.DefaultSAM$DefaultDelegate validateRequest
[java] WARNING: Rejecting request to default delegate.
[java] classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)

[java] SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@1d74f478

Message was edited by: danthedixonman

nnjones
Offline
Joined: 2006-09-26

I seem to be experiencing the same problem with 40 minute startup time, and lots of the same messages.

kaplanj
Offline
Joined: 2004-07-13

I'm trying to figure out if this is a Wonderland problem, or a more general routing issue. Can you try the following suggestions from bug #1124:

Just to verify this isn't purely a Wonderland problem, trying doing the following
from the server where you run Wonderland:

# telnet www.sun.com 80

How long does that command take to time out? You might also want to try
"traceroute www.sun.com" to see if there is something strange going on in the
routing.

danthedixonman
Offline
Joined: 2008-05-28

According to my watch it takes 3 mins 10 seconds to time out to that address