Adding PortletInvokerInterceptor to chain

[christoph.hennes]

Hello,

we want to add a PortletInvokerInterceptor to the existing chain build by

    org.exoplatform.portal.pc.ExoKernelIntegration

in GateIn Version of EPP 5.1.

As far as I can see, there is no configuration based way (e.g. XML) to do this like in EPP 4.x. In the GateIn Source files I have found a sample (simpe-portal) jboss-beans.xml file, which may be a XML-style way to do this, but in the GateIn portal deployment, this file is not used nor I see a way to enable this file.

My current solution is to write my own KernelIntegration class based on ExoKernelIntegration and replace the existing entry in

    02portal.war\WEB-INF\conf\common\portlet-container-configuration.xml

with our class. This works, but I would like to know, if you there is a better solution for this.

Best regards,

Christoph

[hoang_to]

A more flexible way is to create your own Startable object depending on ExoKernelIntegration service component. Then, from the start() method of the custom Startable you could obtain the list of PortletInvokerInterceptor and insert whatever you want.

A built-in illustration is the integration of WSRP stuff into GateIn Portlet Container

[christoph.hennes]

Hi Minh,

thanks for your answer. I wasn't sure if it is a good idea to modify the interceptor chain after starting ExoKernelIntegration but your recommendation encouraged me to do so now. I will take a look at WSRPServiceIntegration and implement a similar approach for our own interceptor.

Best regards,

Christoph

[hoang_to]

Actually, the canonical way to customize behavior of portlets is building PortletFilter.

[christoph.hennes]

I totally agree with you. Keep with the standard is normally the best solution. But in our case we already had components base on EPP 4.3 and needed to use JBoss internals (Interceptor) in order to customize especially WSRP behaviour to our requirements (error handling, session handling etc.). Therefore I need to adapt these old components to the new EPP 5.1 environment in cases where the new standard (PortletFilter ect.) is still not sufficient for our needs. But nevertheless I will try to replace our usage of Jboss internals with standard API where possible, as this is the more maintainable way in the long term.