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
