Tim Holloway wrote:Actually, your definition of "one war" and mine don't seem to be the same. I, too, build only one war, but it's the same war for development, test, and production. Bit-for-bit, byte-for-byte. Build one WAR file and deploy it to whichever server. There's no per-server properties files inside the WAR. And no danger of accidentally deploying a test WAR on the production server, since the test WAR is the production WAR. The attributes that make a WAR a "test" war are all injected from external sources.
I think you actually already know about Maven profiles, but you're mistaken about one thing. You most definitely can specify more than one profile on a build, and that can be useful when you have to do things like say, build a WebSphere WAR for iSeries when you also provide a WebLogic WAR for Linux. Mix and match OS's and server environments using combinations of profiles.
Incidentally, I find this annoying, but profiles do not override mainstream resources. If you want a custom web.xml, for example, you can't provide a default web.xml in the src/main/webapp or it will take precedence over a profile-specific src/tomcat/webapp version of the same file.
Campbell Ritchie wrote:Please tell us some more details, eg your classpath, how you are setting it, and the contents of your manifest file.
Christophe Verré wrote:Which handler are you using for this logger ? If you are using the ConsoleHandler, its default level is INFO. So even if you change the level of your root logger to FINEST, messages below INFO won't be printed to the console. You have to use the following in your logging.properties :
Then, if you change the level of your root logger to FINEST, the "child" logger should also have the same level.
Loggers keep track of their parent loggers in the logging namespace. A logger's parent is its nearest extant ancestor in the logging namespace. The root Logger (named "") has no parent. Anonymous loggers are all given the root logger as their parent. Loggers may inherit various attributes from their parents in the logger namespace. In particular, a logger may inherit:
* Logging level. If a Logger's level is set to be null then the Logger will use an effective Level that will be obtained by walking up the parent tree and using the first non-null Level.
* Handlers. By default a Logger will log any output messages to its parent's handlers, and so on recursively up the tree.
* Resource bundle names. If a logger has a null resource bundle name, then it will inherit any resource bundle name defined for its parent, and so on recursively up the tree
Originally posted by Darrin Holst:
I'm trying to solve the exact same problem, pretty frustrating how limiting the servlet mapping is. Anyway, I tried
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/images/*</url-pattern>
</servlet-mapping>
which stops sending it to my dispatcher, but I'm still getting a 404 on any image I request.
Originally posted by William Brogden:
But thats what the default request handler does - one way or another it has to be done.
Essentially handling all /* means you are replacing the default handler - if this was my problem, and I was working with Tomcat, I would remove the default handler mapping and just forward all requests that did not require custom handling to it.
Bill
Originally posted by Bear Bibeault:
Mapping /* is going to cause a lot of headaches, including the static resource issue. Why is it a requirement? What's wrong with having a reasonable servlet path? (E.g. /something/*).
Originally posted by Tim Holloway:
Did you define public double getMaximum() and getMinimum methods on your backing bean? What do they return when called?