Re[6]: [JBoss-dev] URLConnection and opened files
There was still a problem here in that the jboss.server.home.dir needs to be set before any log4j calls are made or else the boot.log that is generated in between startup and the time the Log4jService is started is dumped to /log/boot.log. I broke out the initialization of the base system properties from the homeURL so that the homeURL can be initialized after the URLStreamHandlerFactory has been set. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 11:42 AM Subject: Re[6]: [JBoss-dev] URLConnection and opened files Alex The light went on and I'm now wondering if I triggered this with the changes for deployment scanning. IIRC the code used to generate new URLs from the File paths returned during the scan, basically using the URL(String) constructor with the path. It now creates URLs relative to the location being scanned using the URL(URL, String) version. The context URL is the one obtained from ServerConfig.getServerHomeURL(). If this is set before the custom handler factory is set up, then all deployed URLs would be using Sun's handler :-( I think this is happening because ServerImpl.doInit() creates the ServerConfigImpl before setting up the URLStreamHandlerFactory. Would it make sense just to move the factory set-up to the very start of doInit()? Jeremy --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Somehow the URL handlers cache has the sun file protocol handler from the start,
at least as early as a debugger will let me stop in the URL.getURLStreamHandler
method. You need to flush this handler cache by setting a URLStreamHandlerFactory.
The change to make your example work is to install a factory that always returns
null:
Tests 1371cat tstProtocol.java
import java.io.*;
import java.net.*;
class tstProtocol
{
static class NullFactory implements java.net.URLStreamHandlerFactory
{
public URLStreamHandler createURLStreamHandler(final String protocol)
{
return null;
}
}
public static void main(String[] args) throws Exception
{
// set handler pkgs
System.out.println(java.protocol.handler.pkgs: + System.getProperty(java.
protocol.handler.pkgs));
// Flush the handlers cache by setting a noop factory
URL.setURLStreamHandlerFactory(new NullFactory());
URL url = new URL(file, null, args[0]);
System.out.println(url: + url);
URLConnection urlCon = url.openConnection();
System.out.println(connection class: + urlCon.getClass().getName());
url = new URL(other, null, args[0]);
System.out.println(url: + url);
urlCon = url.openConnection();
System.out.println(connection class: + urlCon.getClass().getName());
}
}
Tests 1369java -cp .;/tmp/JBoss/jboss-3.0.5/client/jboss-common-client.jar
-Djava.protocol.handler.pkgs=org.jboss.net.protocol tstProtocol /tmp
java.protocol.handler.pkgs: org.jboss.net.protocol
url: file:/tmp
connection class: org.jboss.net.protocol.file.FileURLConnection
java.net.MalformedURLException: unknown protocol: other
at java.net.URL.init(URL.java:302)
at java.net.URL.init(URL.java:219)
at java.net.URL.init(URL.java:238)
at tstProtocol.main(tstProtocol.java:27)
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Alex Loubyansky [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Sent: Tuesday, January 14, 2003 9:48 PM
Subject: Re[6]: [JBoss-dev] URLConnection and opened files
Yes, I thought about it too. There are two cases:
- the thread creating URL can't find custom handlers;
- Sun's handler was somehow initialized/used before (before setting the
property or somehow else?)
But I can't understand why my standalone test doesn't work. I set
property in the command line and my handlers are in the classpath.
I don't see any chance for Sun's handler to be used first.
Ok, I'll update JBoss-3.0 and see.
Thanks,
alex
---
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Here are my findings.
First, JBoss-3.0 is ok. The problem is in JBoss-3.2 and HEAD.
Second, I found the cause.
The resources we want to load with our custom handlers
through class loaders must be added to the classpath AFTER the
(custom) URLStreamHandlerFactory is setup.
URLClassLoaders hold their URLs.
The URLs created before the custom URLStreamHandlerFactory is set up
have Sun's handler. System class loader is a subclass of the
URLClassLoader. Thus, its URLs have Sun's handler. (It seems to me even
if java.protocol.handler.pkgs is setup. Is it a VM's bug or mine?)
Suppose we attempt to load resource that was in the classpath before
the custom handler factory was setup. The URL for the resource is
constructed with: URL(URL context, String spec).
where the context URL comes from the class loader with Sun's handler.
Then resource's URL's handler is assigned context.handler.
So, it doesn't matter whether the custom handler factory is setup.
alex
Tuesday, January 14, 2003, 9:49:45 PM, you wrote:
SMS Oh, I now remeber looking at this but I can't remember the context. There
SMS is a cache of handlers as the URL level. If the file protocol is referenced
SMS before the custom JBoss handler is available then the default Sun one will
SMS be used. Is there a difference between 3.0 and 3.2 with regard to when the
SMS custom protocol handlers are installed? I'll check later today.
SMS
SMS Scott Stark
SMS Chief Technology Officer
SMS JBoss Group, LLC
SMS
SMS - Original Message -
SMS From: Alex Loubyansky [EMAIL PROTECTED]
SMS To: Scott M Stark [EMAIL PROTECTED]
SMS Sent: Tuesday, January 14, 2003 7:07 AM
SMS Subject: Re[4]: [JBoss-dev] URLConnection and opened files
I'm a bit confused. I wrote a simple standalone test.
- main
public static void main(String[] args) throws Exception
{
// set handler pkgs
System.out.println(java.protocol.handler.pkgs: +
System.getProperty(java.protocol.handler.pkgs));
URL url = new URL(file, null, args[0]);
System.out.println(url: + url);
URLConnection urlCon = url.openConnection();
System.out.println(connection class: + urlCon.getClass().getName());
url = new URL(other, null, args[0]);
System.out.println(url: + url);
urlCon = url.openConnection();
System.out.println(connection class: + urlCon.getClass().getName());
}
- run
java -Djava.protocol.handler.pkgs=org.avoka.test.files.protocol -classpath %cp%
org.avoka.test.files.FilesTest build.xml
- output
java.protocol.handler.pkgs: org.avoka.test.files.protocol
url: file:build.xml
connection class: sun.net.www.protocol.file.FileURLConnection
url: other:build.xml
connection class: org.avoka.test.files.protocol.other.OtherURLConnection
I do have org.avoka.test.files.protocol.file.Handler and
org.avoka.test.files.protocol.file.FileURLConnection on the classpath.
My file.Handler isn't called. Am I missing something?
This same thing happens with JBoss-3.2 and HEAD but not JBoss-3.0 (my
3.0 is not up to date).
JDK1.3.1_05, J2SDK1.4.0
Win2K
Thanks,
alex
---
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Alex The light went on and I'm now wondering if I triggered this with the changes for deployment scanning. IIRC the code used to generate new URLs from the File paths returned during the scan, basically using the URL(String) constructor with the path. It now creates URLs relative to the location being scanned using the URL(URL, String) version. The context URL is the one obtained from ServerConfig.getServerHomeURL(). If this is set before the custom handler factory is set up, then all deployed URLs would be using Sun's handler :-( I think this is happening because ServerImpl.doInit() creates the ServerConfigImpl before setting up the URLStreamHandlerFactory. Would it make sense just to move the factory set-up to the very start of doInit()? Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Loubyansky Sent: Wednesday, January 15, 2003 5:21 AM To: Scott M Stark Subject: Re[6]: [JBoss-dev] URLConnection and opened files Here are my findings. First, JBoss-3.0 is ok. The problem is in JBoss-3.2 and HEAD. Second, I found the cause. The resources we want to load with our custom handlers through class loaders must be added to the classpath AFTER the (custom) URLStreamHandlerFactory is setup. URLClassLoaders hold their URLs. The URLs created before the custom URLStreamHandlerFactory is set up have Sun's handler. System class loader is a subclass of the URLClassLoader. Thus, its URLs have Sun's handler. (It seems to me even if java.protocol.handler.pkgs is setup. Is it a VM's bug or mine?) Suppose we attempt to load resource that was in the classpath before the custom handler factory was setup. The URL for the resource is constructed with: URL(URL context, String spec). where the context URL comes from the class loader with Sun's handler. Then resource's URL's handler is assigned context.handler. So, it doesn't matter whether the custom handler factory is setup. alex --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Yes, the setup of the URL handlers should be the very first thing done in doInit. There is nothing in that layer that can rely on ServerConfig information as this is just standard URL protocol handler extension stuff. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 11:42 AM Subject: Re[6]: [JBoss-dev] URLConnection and opened files Alex The light went on and I'm now wondering if I triggered this with the changes for deployment scanning. IIRC the code used to generate new URLs from the File paths returned during the scan, basically using the URL(String) constructor with the path. It now creates URLs relative to the location being scanned using the URL(URL, String) version. The context URL is the one obtained from ServerConfig.getServerHomeURL(). If this is set before the custom handler factory is set up, then all deployed URLs would be using Sun's handler :-( I think this is happening because ServerImpl.doInit() creates the ServerConfigImpl before setting up the URLStreamHandlerFactory. Would it make sense just to move the factory set-up to the very start of doInit()? Jeremy --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[6]: [JBoss-dev] URLConnection and opened files
OK - changed this in 3.2 and HEAD and I can now delete a .war archive I couldn't before. Alex, can you let me know if this worked for you. Sorry about the hassle. Yes, the setup of the URL handlers should be the very first thing done in doInit. There is nothing in that layer that can rely on ServerConfig information as this is just standard URL protocol handler extension stuff. --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Yes, I thought about it too. There are two cases:
- the thread creating URL can't find custom handlers;
- Sun's handler was somehow initialized/used before (before setting the
property or somehow else?)
But I can't understand why my standalone test doesn't work. I set
property in the command line and my handlers are in the classpath.
I don't see any chance for Sun's handler to be used first.
Ok, I'll update JBoss-3.0 and see.
Thanks,
alex
Tuesday, January 14, 2003, 9:49:45 PM, you wrote:
SMS Oh, I now remeber looking at this but I can't remember the context. There
SMS is a cache of handlers as the URL level. If the file protocol is referenced
SMS before the custom JBoss handler is available then the default Sun one will
SMS be used. Is there a difference between 3.0 and 3.2 with regard to when the
SMS custom protocol handlers are installed? I'll check later today.
SMS
SMS Scott Stark
SMS Chief Technology Officer
SMS JBoss Group, LLC
SMS
SMS - Original Message -
SMS From: Alex Loubyansky [EMAIL PROTECTED]
SMS To: Scott M Stark [EMAIL PROTECTED]
SMS Sent: Tuesday, January 14, 2003 7:07 AM
SMS Subject: Re[4]: [JBoss-dev] URLConnection and opened files
I'm a bit confused. I wrote a simple standalone test.
- main
public static void main(String[] args) throws Exception
{
// set handler pkgs
System.out.println(java.protocol.handler.pkgs: +
System.getProperty(java.protocol.handler.pkgs));
URL url = new URL(file, null, args[0]);
System.out.println(url: + url);
URLConnection urlCon = url.openConnection();
System.out.println(connection class: + urlCon.getClass().getName());
url = new URL(other, null, args[0]);
System.out.println(url: + url);
urlCon = url.openConnection();
System.out.println(connection class: + urlCon.getClass().getName());
}
- run
java -Djava.protocol.handler.pkgs=org.avoka.test.files.protocol -classpath %cp%
org.avoka.test.files.FilesTest build.xml
- output
java.protocol.handler.pkgs: org.avoka.test.files.protocol
url: file:build.xml
connection class: sun.net.www.protocol.file.FileURLConnection
url: other:build.xml
connection class: org.avoka.test.files.protocol.other.OtherURLConnection
I do have org.avoka.test.files.protocol.file.Handler and
org.avoka.test.files.protocol.file.FileURLConnection on the classpath.
My file.Handler isn't called. Am I missing something?
This same thing happens with JBoss-3.2 and HEAD but not JBoss-3.0 (my
3.0 is not up to date).
JDK1.3.1_05, J2SDK1.4.0
Win2K
Thanks,
alex
---
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
