Comment from Bill Dudney (copied from CARGO-223):
"
OK so what I did was added the ability to specify the server.xml file through a property and a path to the file to use.
If the file is specified it will be sent through the same set of ant filters as the one that comes out of the jar file. It might be over kill but I need it for WADI since I'm using cargo to launch 3 to 8 containers at a time. I did not want to have to keep a list of 8 server.xml files that only varried by port numbers since these classes have code that is already doing the right thing.
I patched ResourceUtils so I could continue to use the filter's.
I also added a way to set the @webapp.token@ through another property. When this is set the sever.xml from the jar file is used but the webapp token is replaced with the specified value instead of the one that is calculated.
I don't really like this because I had to copy the code that does the computing of the webapp.token value to my test class. Setting the manager class is still a better approach for me but I understand it won't scale.
"
Improvement
Comment from Bill Dudney (copied from
CARGO-223):"
OK so what I did was added the ability to specify the server.xml file through a property and a path to the file to use.
If the file is specified it will be sent through the same set of ant filters as the one that comes out of the jar file. It might be over kill but I need it for WADI since I'm using cargo to launch 3 to 8 containers at a time. I did not want to have to keep a list of 8 server.xml files that only varried by port numbers since these classes have code that is already doing the right thing.
I patched ResourceUtils so I could continue to use the filter's.
I also added a way to set the @webapp.token@ through another property. When this is set the sever.xml from the jar file is used but the webapp token is replaced with the specified value instead of the one that is calculated.
I don't really like this because I had to copy the code that does the computing of the webapp.token value to my test class. Setting the manager class is still a better approach for me but I understand it won't scale.
"
CARGO-223): " OK so what I did was added the ability to specify the server.xml file through a property and a path to the file to use. If the file is specified it will be sent through the same set of ant filters as the one that comes out of the jar file. It might be over kill but I need it for WADI since I'm using cargo to launch 3 to 8 containers at a time. I did not want to have to keep a list of 8 server.xml files that only varried by port numbers since these classes have code that is already doing the right thing. I patched ResourceUtils so I could continue to use the filter's. I also added a way to set the @webapp.token@ through another property. When this is set the sever.xml from the jar file is used but the webapp token is replaced with the specified value instead of the one that is calculated. I don't really like this because I had to copy the code that does the computing of the webapp.token value to my test class. Setting the manager class is still a better approach for me but I understand it won't scale. "