Jetspeed 2.2 Logging Configuration Proposal

[Randy Watler <wa...@wispertel.net>]

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,

Randy


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org

Re: Jetspeed 2.2 Logging Configuration Proposal

[Niels van Kampenhout <n....@onehippo.com>]

On Fri, May 8, 2009 at 3:51 PM, Randy Watler <wa...@wispertel.net> 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,

Sounds like a good plan to me Randy!

Niels

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org

Re: Jetspeed 2.2 Logging Configuration Proposal

[Ate Douma <at...@douma.nu>]

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-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org