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.jar 51384 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. Jeremy > > 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 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 would be nice if configuring netboot was transparent) > > > > > > > > And, in general, only file: and http: protocols are supported > > > (not https: > > > > even); adding others is not pluggable. > > > > > > > > Jeremy > > > > > > > > > ----- Original Message ----- > > > > > From: "Jeremy Boynes" <[EMAIL PROTECTED]> > > > > > To: "Jboss-Development" <[EMAIL PROTECTED]> > > > > > Sent: Saturday, December 07, 2002 10:36 AM > > > > > Subject: [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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
