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
