Hi Vivek,
Well, I'm not sure that you should be doing that in the portal to be honest. I'll explain how you CAN in a second, but I think you should consider your architecture a little. You are, potentially, add ing a lot of load to your app server and your database (assuming you are storing these in a db) because you are tasking LIFERAY with all the detection and recording activities. A system requiring this much auditing would, from my experience, have proxies higher up the nextwork path that would be responsible to tracking this kind of stuff. For example, if you have an apache or nginx in front of your Liferay server, then you can use the access logs as a way to track all the requested paths.
But ... if you MUST ask Liferay to do it.
There are a few properties that you can use that might be all you need for out of the box.
#
# Set this to true to track user clicks in memory for the duration of a
# user's session. Setting this to true allows you to view all live sessions
# in the Admin portlet.
#
session.tracker.memory.enabled=true
#
# Set this to true to track user clicks in the database after a user's
# session is invalidated. Setting this to true allows you to generate usage
# reports from the database. Use this cautiously because this will store a
# lot of usage data.
#
session.tracker.persistence.enabled=false
#
# Set this to true to convert the tracked paths to friendly URLs.
#
session.tracker.friendly.paths.enabled=false
Now they come with performance costs, so again, consider them and their values carefully. Now, if you need your records to be stored in a specific format or location or whatever, then you may have to opt for a custom solution. For this scenario, I think what you would want here is a static portlet. So you would create a portlet and then configure this property in your portal-ext.
... with this property configured (with your portlet name) the porlet will automatically live on every page. The view for the portlet can be empty, such that the portlet is on the page but since it doesn't render any content, you won't "see it" per se. Now, in terms of the recording, if you want just the pages, then I think you could probably get away with just using the render method and in that method get the user out of the request (be careful ... there is user and a REAL user, if you are supporting impersonation then you might want to grab both) and then record the record. If they refresh the same page, let's say user profile, then you would see
userid page
1234 home
1234 user-profile
1234 user-profile
in your trail. This is a pretty basic record though. I mean, there are so many more options to consider. The real user, as I said a moment ago, but also in a clustered environment you might want to record which node they are on, their source ip, etc.
Regardless, I would still consider wiring up the handlers and using the message bus so that you can record the records asynchronously and not block the request. It would also allow you to more easily buffer and pool records so that, for example, you collect 50 records at a time and then do a batch write rather than hammering your database with a write for ever page requested (same goes for file I/O and not thrashing your HDD)
Anyway, that's one way to do it -- with a poor mans audit.
