Request unique id

[Ruben Martin Pozo, geändert vor 11 Jahren.]

Is there any way to get a request unique id?

We need to log a unique id associated to every request in our production environment. This id has to be unique for the entire request and it has to be available to every portlet that gets executed in that request.

We've tried to create that id ourselves using the Log4j MDC singleton to store it. There are some issues with the classloader structure that prevent us from using this solution.

Any ideas?

[David H Nebinger, geändert vor 11 Jahren.]

I would do this using a standard servlet filter on the ROOT web application.

The fun part of this, however, is that not all requests go through ROOT (i.e. images, ajax, etc. can go directly to the web app containing the plugin(s)).

[Ruben Martin Pozo, geändert vor 11 Jahren.]

Do you know of any article or paper where we can learn how the ROOT application, plugins, hooks, portlets work together?

It's being quite confusing for us to understand the server request lifecycle

Thanks

[David H Nebinger, geändert vor 11 Jahren.]

Unfortunately not...

Basically you're in an application container, so all of those rules still apply. Incoming requests go through designated servlet filters to a designated servlet (based upon mappings defined in the web.xml file).

The fun part is the portal side. All requests at a portal level go to ROOT through the servlet filters to a designated servlet. They use struts 2, so all of the views are JSPs.

For a given page, the portal will determine which portlets need to be rendered on a page. It will cross the web app boundary to invoke portlet API methods on those portlets to have each render their content, and the portal will aggregate the content into the final html.

So content is generated by your portlet and can include references to resources in your portlet (i.e. images, javascript, and css among others). The browser, while processing the aggregated html, will make various calls back to your (and other) portlet to retrieve those resources.

Hooks apply changes to the ROOT web application w/o modifying the core Liferay code. You can make changes to Liferay's JSP pages, alter some behaviour, etc. Doesn't change the general lifecycle of the request process, just ends up changing some of the outcomes.