Randy Watler wrote:
After plenty of false starts, I'd like to propose the following
enhancement for a common logging configuration approach for the Jetspeed
2.2 release.
Goals:
1. Simplify log configuration in portlet applications via preconfigured
system properties setup in container scope, (resolving JIRA issue APA-9).
2. Provide a technique that allows administrators with access to the
portal web application container configuration to simply relocate log
files outside expanded war file directories.
3. Maintain separate log files per portlet application and portal so
that originating application code can be determined.
4. Avoid container/portal logging implementation requirements and class
path pollution so that portlet applications are able to utilize a
logging implementation of choice.
5. Provide a "zero-configuration" for Jetspeed demo, installer, and
developer build environments.
Proposed Solution:
1. Configure portlet application logging using a well known system
property as directory for logging, (i.e. 'org.apache.portals.logdir').
2. By convention, require that all portlet applications write to log
files with names prefixed by application name.
3. Provide a Tomcat 5.5 and Tomcat 6.0 compatible server listener class
implementation that will dynamically set the logging directory system
property before the portlet applications are started to the default
Tomcat ./logs or specified directory.
4. Implement a deployment extension to the Jetspeed Maven plugins that
configures the Tomcat 5.5 or Tomcat 6.0 server.xml file to add the
required <Listener/> tag as a child of the <Engine/> tags, (if not
already specified).
5. Extend the Jetspeed Maven deployment plugin configuration to add a
jar, (jetspeed-logging), containing the listener to the Tomcat
./server/lib directory for 5.5 or ./lib directory for 6.0.
6. Initially document how to set the logging directory property for
other web containers as part of the manual deployment process for
Jetspeed and Portals Applications that conform to this approach.
7. Encourage contribution of similar auto configuration plugins for
other web container implementations.
All thoughts/comments appreciated,
+1, I'm cool with this approach!
Don't know how much work and time this solution will take to implement, but I assume such Tomcat server listeners are pretty straightforward
to write?
As the well known system property for logging (org.apache.portals.logdir) "derives" from Apache Portals, and the APA applications will
leverage it, would it be a good idea to provide this library containing the Tomcat server listeners as an APA artifact (e.g. apa-logging)
instead of through Jetspeed?
Doing so fits well in the goals of APA (provide generic solutions useful for all portals) and might also be more attractive for others to
contribute similar plugins for other web containers too.
And, if I understand the above proposal correctly, by implementing this, we no longer need to keep our jetspeed and j2-admin
log4j.properties outside WEB-INF/classes, right? If so, I think it would be good to move them back to this "default" location.
Regards,
Ate
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
