Instead of using a static error page, use a servlet as the front controller for error pages. What this servlet does, generally, is forward on to appropriate 'real' error pages. Alternatively you can get it to show you stack traces and the like (and display something better than the 'standard' error page; eg dump the request environment as well).
You're describing different behaviour based on the deployment environment, so you really want to use your application's environment to get hold of the flags you need (in J2EE apps this is via JNDI, directly or indirectly; eg JNDI provides a DataSource, you fetch the flag from a DB; JNDI provides a filename, you read it...).
As for the log4j config, the log4j docs themselves give the hint: use a config servlet with load-on-startup set, and configure things in there. Again, you can get from your environment what log4j.xml to use. In practice we try JNDI and if nothing is set up, we default to one inside the webapp; that means the 'production' setup is easier to support.
Using the same rationale, the error handler would use a JNDI flag to disable error pages in some environments.
Jo�l Wijngaarde [Us Media] wrote:
You're right! We used it to update some project specific meta information in the code headers. We're not actively changing code here using filters ;-).
Where I would like to use it was in the 'web.xml'. This way I could do with only one 'web.xml' for the staging, development and live server. Small differences (for instance no error page definitions in the development 'web.xml' file - so we see all errors clearly) could be done with filters. Having only one file prevents people adding something in one 'web.xml' file and forgetting to add / remove / change a similar line of code in the other 'web.xml' files.
- Joel
On Mon, 2003-07-21 at 23:44, Brett Porter wrote:
Filtering Java files? Sounds like a recipe for disaster to me... What are you trying to do that can't be done by reading properties from an external resource file? The only thing I can think of is JDK specific code, but most people solve this by abstracting it to separate classes and conditionally including it in the project.
Cheers, Brett
-- Brett Porter Developer, Content & Distribution f2 network ~ everything essential
-----Original Message-----
From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: Tuesday, 22 July 2003 6:59 AM
To: Maven Users List
Subject: RE: Hoto use filters before compilation in Maven
-----Original Message----- From: Jo�l Wijngaarde [Us Media] [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 1:27 PM To: 'Maven Users List' Subject: Hoto use filters before compilation in Maven
Hi,
I'm building a web application for a client. During testing we deploy the application on a staging server. There are some slight differences between the configuration of the staging server and the live environment. Mainly the 'web.xml' and the 'log4j.xml' files, but also some slight differences in the .java files.
In ant we can use the filter tag to perform some changes. We first copy the class files to a new folder using a filter rule and then compile the filtered classes.
Is there a 'standard' way of doing something similar in maven. Or does it require creating 'pre-goals' in a 'maven.xml' file? How I could use filtering inside a maven project?
I will try to add the answers received here in the maven wiki at: http://wiki.codehaus.org/maven/CreatingWebApplications
Currently in Maven you can do filtering of "resources". see: http://maven.apache.org/reference/project-descriptor.html#resources
You cannot do this with Java classes (unless you do will create pre-goals).
Michal
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
