-
Bug
-
Resolution: Done
-
Major
-
None
-
None
SourceForge Submitter: tstanczak .
See #684594 for the beginning of this issue.
URLDirectoryScanner does add functionality over
URLDeploymentScanner, at least one - the ability to
deploy applications/services/etc in the order of the urls
parameter. Like in the example:
<mbean >
...
<attribute name="URLs">
<urls>
<dir name="./deploy-classes"/>
<dir name="./deploy"/>
...
Why is it important? I want to use my own Tomcat SSL
socket factory, I set it in jbossweb-tomcat41.sar/META-
INF/jboss-service.xml. The compiled classes are being
deployed through a service file on /deploy-classes
directory.
The URLDeploymentScanner throws all the deployments
found in the URLs attribute in one big bag, sorts the
bag using its DeploymentSorter, and deploys in the
resulting order.
The very first deployments are service applications
(*.sar), among others Tomcat. *service.xml are next.
So Tomcat gets started before my classes are added to
the unified repository. As you can guess I get
ClassNotFound exceptions.
Now I could put my classes in the system classpath,
but I prefer not to change system classpath as long as I
see other possibilities to get the classes to work.
In case URLDirectoryScanner I just put /deploy-classes
in front of /deploy and everything works.
Of course i could write my own DeploymentSorter, but
the again I had to put my classes in the system
classpath!
Now you have a diff submitted by Markus Kling, I have
noticed that URLDirectoryScanner in Jboss 3.2.2 is the
same as of Jboss 3.2.1, and modified it again
appropriately, I can can upload my changes, too.
Please note, that my aim is not to use
URLDirectoryScanner, but to have the ability to set the
order of deployments by the order of deployer's
parameters. It just happens that URLDirectoryScanner
delivers what I want.
Using PrefixDeploymentSorter is quite awkward, to
deploy one application before all other I would have to
put numbers into the names of all applications except
this very one! Sounds complicated, doesn't it?