RE: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Hello,
I already saw that when writing the first extension, which is why I ended up
using the GET mechanism to quickly have something working. If you want to
make a second extension, I suggest it to be a real WebDAV one ;)
You should check this as well:
http://www.innovation.ch/java/HTTPClient/FAQ.html It is not so big and
implements tons of http stuff (I will most probably use that for HTTP
Session clustering automated test suite).
BTW, what is the size of all these appache libs? What is the size of
dav4j? What is the license?
Cheers,
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Jeremy Boynes
Envoyé : mardi, 10 décembre 2002 19:03
À : [EMAIL PROTECTED]
Objet : RE: [JBoss-dev] Proposal for changes to URL deployment to clean
up netboot
I have a prototype of the changes to SARDeployer ready to go. However, I
have run into a dependency I don't like.
I had originally thought of writing a trivial DAV client but had forgotten
that HttpURLConnection disallows non-standard request methods
such as DAV's
PROPFIND. As a result any DAV client needs to implement its own
transport -
which is no longer quite so trivial :-(
I looked at three options:
1) write the transport
2) use the WebDAV client from the Apache Slide project
(this is the basis for the Tomcat implementation)
3) use dav4j
(this is the basis for the Websphere implementation)
Which to use depends on if sun.net.www.protocol.http.HttpURLConnection is
portable across JDK's. If so, it would easy enough to subclass to
extend the
protocol; this is exactly what dav4j does. However, I'm assuming it isn't
(portable), which means writing the transport from scratch; this is what
Slide did (in the form of commons-httpclient).
So, right now the prototype uses the Slide api, making jboss-common
dependent on webdavlib and commons-httpclient.
Being new here, I wanted to ask which direction I should take:
A) Press on with webdavlib and accept the dependency
B) Implement our own DAV client using Sun's HttpURLConnection (like dav4j)
C) Implement our own DAV client with our own transport
D) Give up on DAV as a default mechanism and revert to a GET based
protocol (needs server side helpers)
I lean toward A) as there are existing dependencies during boot (e.g.
getopt, gnu-regexp, log4j) but I realise that adding more is undesirable.
Thanks
Jeremy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha
Labourey
Sent: Monday, December 09, 2002 12:18 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Proposal for changes to URL deployment to clean
up netboot
Hello Jeremy,
I did the recent netboot changes to allow for HTTP hot-redeployment and
wildcard usage. That was a first step and the usage of WebDAV
is a must (I
spoke about this to Greg in Geneva). And I agree, there is an
inconsistency
about the root used for file listing: the current advanced
mode doesn't
allow for clients to request different configurations from the
same JBossWeb
server. I will send you a very small doco I wrote about the
current status.
Cool changes.Cheers,
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Jeremy Boynes
Envoyé : dimanche, 8 décembre 2002 09:00
À : [EMAIL PROTECTED]
Objet : RE: [JBoss-dev] Proposal for changes to URL
deployment to clean
up netboot
Scott Stark wrote:
Sounds ok, but let see some more details. Show how you propose
to rewrite
SARDeployer.parseXMLClasspath using this helper framework.
I think bbtaining a URLLister should mirror the mechanism for
obtain a URL
protocol handler in that one can install the class that obtains a
listing for a given
URL via package search paths.
I was thinking something like
public abstract class URLLister {
/**
* Obtain a lister appropriate for the supplied URL.
* @param baseUrl the URL to list; should end in / but need not
*/
public static URLLister getLister(URL baseUrl)
throws UnsupportedProtocolException // or something
{
}
/**
* Return the URLs of members matching the pattern.
* The pattern may contain multiple elements separated by ,
* Each element may be a wildcard e.g. *.jar
* @param pattern a pattern to filter members by
* @return a Collection of java.net.URL's containing every matching
member
*/
public abstract Collection listMembers(String pattern);
}
but a URLListerFactory with URLLister as an interface is
probably better.
Either implementation would allow handlers to be plugged in.
Then the big block of code in SARDeployer.parseXMLClasspath beginning
// jason: This section needs to be rewritten to be non
http file
//specific. Should
RE: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
OK. Good luck. Cheers, sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Jeremy Boynes Envoyé : mercredi, 11 décembre 2002 16:56 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot Sacha Labourey wrote: You should check this as well: http://www.innovation.ch/java/HTTPClient/FAQ.html It is not so big and implements tons of http stuff (I will most probably use that for HTTP Session clustering automated test suite). Thanks, I will BTW, what is the size of all these appache libs? What is the size of dav4j? What is the license? From Slide: webdavlib.jar 107739 commons-httpclient.jar51384 From dav4j dav4j.jar 170598 it's released under IBM's open source license I plan to go with webdavlib for now and (maybe) switch to a thinner implementation using just an http library later. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
tisdagen den 10 december 2002 kl 19.03 skrev Jeremy Boynes: I lean toward A) as there are existing dependencies during boot (e.g. getopt, gnu-regexp, log4j) but I realise that adding more is undesirable. Functionality is desired ... when 'one' dives in a prob on a moving xp target - the 'one' is often the most well versed on the issue at hand - at that time ... so just go ahead and impl for proofing ... later ... if some academic discurce is made ... adjustments can be made ... Being new here not really ... You been lurking ;-) /peter_f --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Hello Jeremy,
I did the recent netboot changes to allow for HTTP hot-redeployment and
wildcard usage. That was a first step and the usage of WebDAV is a must (I
spoke about this to Greg in Geneva). And I agree, there is an inconsistency
about the root used for file listing: the current advanced mode doesn't
allow for clients to request different configurations from the same JBossWeb
server. I will send you a very small doco I wrote about the current status.
Cool changes.Cheers,
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Jeremy Boynes
Envoyé : dimanche, 8 décembre 2002 09:00
À : [EMAIL PROTECTED]
Objet : RE: [JBoss-dev] Proposal for changes to URL deployment to clean
up netboot
Scott Stark wrote:
Sounds ok, but let see some more details. Show how you propose
to rewrite
SARDeployer.parseXMLClasspath using this helper framework.
I think bbtaining a URLLister should mirror the mechanism for
obtain a URL
protocol handler in that one can install the class that obtains a
listing for a given
URL via package search paths.
I was thinking something like
public abstract class URLLister {
/**
* Obtain a lister appropriate for the supplied URL.
* @param baseUrl the URL to list; should end in / but need not
*/
public static URLLister getLister(URL baseUrl)
throws UnsupportedProtocolException // or something
{
}
/**
* Return the URLs of members matching the pattern.
* The pattern may contain multiple elements separated by ,
* Each element may be a wildcard e.g. *.jar
* @param pattern a pattern to filter members by
* @return a Collection of java.net.URL's containing every matching
member
*/
public abstract Collection listMembers(String pattern);
}
but a URLListerFactory with URLLister as an interface is probably better.
Either implementation would allow handlers to be plugged in.
Then the big block of code in SARDeployer.parseXMLClasspath beginning
// jason: This section needs to be rewritten to be non http file
//specific. Should probably try to convert to a URL early.
through the end of the for loop (lines 359 to 501)
would become something like:
// handle . special - is this necessary?
URL baseUrl;
if (..equals(codebase) || .equals(codebase)) {
// use the parent of the location I am deploying
baseUrl = new URL(di.url, ..);
} else {
// resolve codebase URL relative to SERVER_HOME
baseUrl = new URL(serverHomeUrl, codebase);
}
if (.equals(archives)) {
// no archives supplied so add the codebase itself
classpath.add(baseUrl);
} else {
// obtain a URLLister for this location
URLLister lister = URLLister.getLister(baseUrl);
classpath.addAll(lister.listMembers(archives));
}
The basic assumption here is that the baseUrl is a collection (as per
RFC2518 (WebDAV)) and hence its members can be listed. The
implementation of
URLLister does this in whatever manner is appropriate for the
protocol; e.g.
for file: scan the directory (as now) using a FilenameFilter to pattern
match.
For an http: based lister, the DAV implementation would issue a PROPFIND
request and filter the response using the search pattern; in the
future this
could be extended to use DASL to filter server side. If the
server supports
DAV natively, no additional support would be required; if it doesn't, a
servlet would be used to provide a trivial DAV implementation using either
the app context or by reading the server's configs (like the JBossWeb
helper).
The current http: approach, using a listing URL, could migrate to DAV or
could be a another implementation. However, the details are all hidden
behind URLLister.
This snippet is my thoughts for SARDeployer classpath but the changes to
URLDeploymentScanner would be similar. It would use a different method on
URLLister to return a collection of URLs with properties (e.g.
last-modified) similar to NetBootFile.
Examples of the special cases are:
* SARDeployer treats codebase=. as meaning the directory containing
the unit being deployed; but codebase=lib is resolved relative to
SERVER_HOME. This seems inconsistent, at least to me.
* SARDeployer makes several (6) checks for the file: protocol
* SARDeployer has to handle the special URL:* syntax used by
NetBootHelper
* NetBootHelper relies on the jboss.netboot.listing.url system property
which means all netboot servers involved must use the same mechanism.
If this is not defined, it relies on the netboot location URL ending
in /files - see NetBootHelper.getDefaultListUrl()
* URLDeploymentScanner can't handle dynamic lists off the network -
HttpUrlDeploymentScanner must be used instead. This means
conf/jboss-service.xml must be modified for netboot (not a big deal
but it
Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
A factory + interface is the way to go, otherwise looks good.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 07, 2002 11:59 PM
Subject: RE: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Scott Stark wrote:
Sounds ok, but let see some more details. Show how you propose to rewrite
SARDeployer.parseXMLClasspath using this helper framework.
I think bbtaining a URLLister should mirror the mechanism for obtain a URL
protocol handler in that one can install the class that obtains a
listing for a given
URL via package search paths.
I was thinking something like
public abstract class URLLister {
/**
* Obtain a lister appropriate for the supplied URL.
* @param baseUrl the URL to list; should end in / but need not
*/
public static URLLister getLister(URL baseUrl)
throws UnsupportedProtocolException // or something
{
}
/**
* Return the URLs of members matching the pattern.
* The pattern may contain multiple elements separated by ,
* Each element may be a wildcard e.g. *.jar
* @param pattern a pattern to filter members by
* @return a Collection of java.net.URL's containing every matching
member
*/
public abstract Collection listMembers(String pattern);
}
but a URLListerFactory with URLLister as an interface is probably better.
Either implementation would allow handlers to be plugged in.
Then the big block of code in SARDeployer.parseXMLClasspath beginning
// jason: This section needs to be rewritten to be non http file
//specific. Should probably try to convert to a URL early.
through the end of the for loop (lines 359 to 501)
would become something like:
// handle . special - is this necessary?
URL baseUrl;
if (..equals(codebase) || .equals(codebase)) {
// use the parent of the location I am deploying
baseUrl = new URL(di.url, ..);
} else {
// resolve codebase URL relative to SERVER_HOME
baseUrl = new URL(serverHomeUrl, codebase);
}
if (.equals(archives)) {
// no archives supplied so add the codebase itself
classpath.add(baseUrl);
} else {
// obtain a URLLister for this location
URLLister lister = URLLister.getLister(baseUrl);
classpath.addAll(lister.listMembers(archives));
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Wanted to get feedback before starting to implement... The current support for loading deployment units has several special cases to deal with loading from the network e.g. in SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or even HttpURLDeploymentScanner itself. I would like to make changes to simplify this and at the same time offer additional flexibility. The main change would be to factor out the URL listing functionality into helpers with a factory to create them based on the scheme. Examples would be: * file: using java.io.File as now * http(s): using DAV * http: using the current listing mechanisms (if still applicable) others could be added as needed (e.g ftp:) The DAV client would allow JBoss to be netbooted from any web server supporting DAV, either directly (e.g. Tomcat 4.1, Apache+mod_dav or even IIS) or via a helper servlet (which could read either the content of its war or config of its host). This change would isolate the SARDeployer and the URLDeploymentScanner's from the different URL schemes and remove the special cases. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Wanted to get feedback before starting to implement... ;) The current support for loading deployment units has several special cases to deal with loading from the network e.g. in SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or even HttpURLDeploymentScanner itself. Specifically what are the special cases? It has been a while since I looked, refresh my memory. Some work still needs to be done to remove all of the http: specific bits are replace them with plain URLConnnection bits. I would like to make changes to simplify this and at the same time offer additional flexibility. The main change would be to factor out the URL listing functionality into helpers with a factory to create them based on the scheme. Examples would be: * file: using java.io.File as now * http(s): using DAV * http: using the current listing mechanisms (if still applicable) others could be added as needed (e.g ftp:) Explain some of the details here. The DAV client would allow JBoss to be netbooted from any web server supporting DAV, either directly (e.g. Tomcat 4.1, Apache+mod_dav or even IIS) or via a helper servlet (which could read either the content of its war or config of its host). I am all about more network proto support. Can this be abstracted into a URL Handler used with a URLConnection? This change would isolate the SARDeployer and the URLDeploymentScanner's from the different URL schemes and remove the special cases. Again, explain some details please. =] --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
