portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 11737] - Portlet Usage Logging
Date Mon, 19 Aug 2002 22:35:15 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11737>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11737

Portlet Usage Logging





------- Additional Comments From franck.lumpe@iberplus.com  2002-08-19 22:35 -------

> I would like to provide simple usage report without creating a dependency
> on another product. The usage data will be there, it's just a matter of
> dumping it using a Velocity or JSP template.

In my opinion, dependency on another product is not a problem in this case, 
because logfile analysis is a commodity product, not a critical software 
component.

I suggest logfile processing to be done apart from Web Application (JetSpeed in 
this case) because:

1) Logfile generation and analysis are very different processes.
2) Log files are getting big very quickly, therefore batch processing is 
recommended.
3) Open source tools are available for the job.
4) Logfile processing is not so trivial. Look at feature list of packages at 
http://awstats.sourceforge.net/#COMPARISON.
5) When an administrator is used to a specific log file report output from his 
usual log analysis tool, he wants to keep using the same tool.
6) Tomcat offers no logfile processing, only logfile generation.

In any case I suggest starting implementation with logfile generation only, so 
it can be done faster.

> That was actually my plan: either log portlet usage as virtual directory
> or page to "fool" the analyzer that it's dealing with a static resource.
> Of course, the length will always be zero and status code 200
> (401 for denied requests).

OK.

It would be more exact to register the actual length of the HTML / WML served 
in the portlet instead of length zero, but I have no idea if this is 
technically possible in this case. At least that's the way standard Web Server 
logging works. It would be useful to know which portlet is heavy on bandwidth.

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message