What scans default/lib? (or, how do I enforce order in defau

[ljnelson]

I am not sure where to ask this question, so I'll start here. I'm using JBoss 3.2.6 on Windows.

I need to enforce a particular order in the classpath in <my server config>/lib.

In my <my server config>/conf/jboss-service.xml there is a entry like this:


I thought that would enforce an order, but I've since come to realize that no, the archives attribute is only used by (in this case) the FileURLLister to exclude or include files, not order the listing of them.

So then, as I understand it, a SARDeployer fires up and does the initial spin through the directory. Turning on debug logging confirms this suspicion. The order in which the jars are added to the classpath is alphabetical. I don't know whether this is coincidence or not.

Now, there is something called a URLComparator attribute, but that seems to apply to the DeploymentScanner that is monitoring--surprise--the *deploy* directory, not the lib directory.

So, again, what is the preferred way to affect the ordering of jars in the <my server config>/lib directory? I'm guessing that there is none, unless I can somehow worm my way in and replace the FileLister class.

Thanks,
Laird

[ljnelson]

Now, I read the documentation and found this:

server/classpath: This element specifies one or more external JARs that should be deployed with the MBean(s). The optional archives attribute specifies a comma separated list of the JAR names to load, or the * wild card to signify that all jars should be loaded. The wild card only works with file URLs, and http URLs if the web server supports the WEBDAV protocol. The codebase attribute specifies the URL from which the JARs specified in the archive attribute should be loaded. If the codebase is a path rather than a URL string, the full URL is built by treating the codebase value as a path relative to the JBoss distribution server/ directory. The order of JARs specified in the archives as well as the ordering across multiple classpath element is used as the classpath ordering of the JARs. Therefore, if you have patches or inconsistent versions of classes that require a certain ordering, use this feature to ensure the correct ordering. Both the codebase and archives attributes values may reference a system property using a pattern ${x} to refer to replacement of the x system property.

But I have found that this is not the case. As far as I can tell, SARDeployer uses the "archives" attribute to build up a list of jars, yes, but the FileURLLister then simply uses this list to decide what to keep and what to filter out, not how to order the list.