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
