Custom Velocity Tools and Liferay 6.0

A while back I wrote a post about adding custom tools to the Liferay Velocity context.

In 6.0 a change was made such that the behaviour has changed slightly. Now all such tools are plain old beans which must implement an interface.

The changes also means that I have a lot less code to write and less wiring to do. Let's see how we'd do it now using exactly the same tool as that old post.

The interface again:

package com.mytool;

public interface MyTool {

	public String operationOne();

	public String operationTwo(String name);

}

We need an implementation of the interface:

package com.mytool;

public class MyToolImpl implements MyTool {

	public String operationOne() {
		return "Hello out there!";
	}

	public String operationTwo(String name) {
		return "Hello " + name + "!";
	}

}

Our spring configuration only requires a single bean definition:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
	<bean id="com.mytool.MyTool" class="com.mytool.MyToolImpl" />
</beans>

Of course in order for our bean definitions to be read we need to make sure it gets loaded, so we'll name it so that it's found by the context loader WEB-INF/applicationContext.xml (We could have used the portal-esk spring config mechanism, but I wanted to demonstrate that Liferay is flexible and sensitive to existing coding behaviors.

I mentioned that we need a context loader, so there is one more change required. While before you could only add tools within a ServiceBuilder enabled plugin, that is no longer required. All you have to do is add the following context loader listener the your web.xml (but only if your plugin is not a portlet type plugin):

    <listener>
        <listener-class>com.liferay.portal.kernel.spring.context.PortletContextLoaderListener</listener-class>
    </listener>

This effectively tells the portal to create a BeanLocator object associated with your plugin and to read the beans definitions that were defined in WEB-INF/applicationContext.xml.

Now we're ready to use our tool in a Velocity template:

Since we've done this in a plugin, you will have to specify the 'contextPathName' of the plugin so that the appropriate BeanLocator can be used to lookup your tool. For example, the context path name of your plugin being "test-velotool-hook", then you'd use the following in your template:

#set ($myTool = $utilLocator.findUtil('test-velotool-hook', 'com.mytool.MyTool'))

$myTool.operationOne()

$myTool.operationTwo('Ray')

I've linked a source hook plugin that you can drop into your plugins SDK and deploy just by doing ant deploy.

[test-velotool-hook.zip]

Blogs
Thanks, this is useful information. Question - is this 6.0 only or did you backport this to EE ( 5.2sp4 )?

And one more thing zip file is not available. I'm getting "Forbidden".
Hello Ray,
In this context i would like to ask a Question what are the other ways that we can use for Liferay to pickup the liferay plugins from an archive a WAR or EAR etc.,
I see that adding PortletContextListener will do the job just curious to know any other alternatives any Liferay service we can invoke to do this job.
Thanks.
Kamesh
Hmm.. If you're referring to programmatic injection I don't think we do. At least not yet. The bootstrapping process for plugins is pretty intense. I'm hoping that once we get going with OSGi that sort of scenario begins to open as an option.

Then again, maybe I didn't understand your question!
Actually I was referring to the ways how Liferay picks up the plugins from the Archieves e.g war, since WAR undergoes normal deployment model in any J2EE server, Liferay adds one more additional step of registering the plugins from the WAR, not sure which service is called to do the same this will help when we deploy EAR in bigger servers where Liferay is deployed to enable registering of Liferay specific plugins.
Hope i made it clear
Ah, I see! Typically when ear deployment of the portal is used, it's expected that the plugins that are to be used are pre-bundled in the ear (using plugin pre-deployment technique).
Thanks very much for the information Ray, can you please point to WIKI where it talks on the "plugin pre-deployment technique", i search the WIKI in vain emoticon
Thanks for a very useful article. I am able to build extra functionality and use it in velocity theming. Works great!

However, these extra tools I am building do not seem to be available for Journal Velocity Templates. I have set

journal.template.velocity.restricted.variables=

in my portal-ext.properties so as to remove all restrictions.

What gives?

Thanks

- ashok
They should be... as there is no difference in the access to them between themes and WCT! You still have to make the load call first though to retrieve them (Even if already loaded in the theme, since it's a completely different context... not sure if that's the issue though).
[...] One approach to overcome these challenges is to use a utility class written in Java and called within your script. We'll follow the approach that Ray outlined in a blog post about using Java utils... [...] Read More
Really awesome feature. Thanks a lot Ray for sharing such a nice tutorial.

Thanks
Jignesh
Is there a way to call this MyTool implementation from a portlet? Thanks
Object bean = PortletBeanLocatorUtil.locate(String servletContextName /* plugin context name */, String name /* name of bean */);

then do whatever you need to do with it.
Thank you Ray this is very helpful.
I was able to create a hook with methods I can call from a VM. This works great in 6.0eespX. When I moved to 6.1eega2 the VM call couldn't find the bean until I added the ext-spring.xml definition back in to the hook in addition to the applicationContext.xml. Something to look at.

Now I am trying to access the hook methods from a portlet with the PortletBeanLocatorUtil call and I'm getting ClassNotFoundExceptions in my portlet. This is in 6.1eega2, haven't tried it in 6.0.

I'm getting an object from the bean locator call but when I try to use a method in the class I get the exception. Would you please expand on your "...do whatever you need to do with it." statement and provide a more detailed example so I can see where I may be getting off track?

Thank you,
Craig
Hey Craig,

The main difference is that we're creating a Proxy around the spring bean. What that means is that the bean you're exposing must implement an interface that the Proxy can implement. This breaks when the bean is a static Util wrapper (which doesn't actually implement the interface).
Thank you very much for this useful post, Ray!
I've deployed the test-velotool-hook on a Liferay 6.1 EE SP2 but I weren't able to get it working.
I tested on a clean bundle following these steps:
1. Deploy the "test-velotool-hook". The log is OK.
2. Create a "Dummy" structure with a "dummy" text field.
3. Create a "Dummy" journal template associated to the "Dummy" structure. Its script is
#set ($myTool = $utilLocator.findUtil('test-velotool-hook', 'com.mytool.MyTool'))
<p>myTool=[$myTool]</p>
4. Create a "Dummy" web content that uses the "Dummy" structure and the "Dummy" template.
5. Add a "Web Content Display" showing the "Dummy" content in a page. In the log appears an exception that, in short, says:

[UtilLocator:53] com.liferay.portal.kernel.bean.BeanLocatorException: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'com.mytool.MyTool' is defined
com.liferay.portal.kernel.bean.BeanLocatorException: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'com.mytool.MyTool' is defined
at com.liferay.portal.bean.BeanLocatorImpl.locate(BeanLocatorImpl.java:89)
at com.liferay.portal.kernel.bean.PortletBeanLocatorUtil.locate(PortletBeanLocatorUtil.java:47)
at com.liferay.portal.velocity.UtilLocator.findUtil(UtilLocator.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'com.mytool.MyTool' is defined
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:529)
at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1094)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:276)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1075)
at com.liferay.portal.bean.BeanLocatorImpl.doLocate(BeanLocatorImpl.java:125)
at com.liferay.portal.bean.BeanLocatorImpl.locate(BeanLocatorImpl.java:83)
....

Should this hook work out-of-the-box on Liferay 6.1 EE SP2? Or does it need some tweaks?

Thank you.
Oh! I forget to say that I changed the "web.xml" of the hook. I needed to use the Servlet 2.4 XSD declaration instead of the Servlet 2.3 DTD to deploy it.

The declaration used is:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
Hi all,

for version 6.1 or later you need to add the next param to the web.xml.

<context-param>
<param-name>portalContextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

Kind regards!!!
Other option for LF 6.1 or later:

Add a file service.properties to the src folder of the plugin and configure the property spring.config. eg:

spring.configs=\
WEB-INF/applicationContext.xml,\
\
WEB-INF/other-beans-def.xml

Enjoy!! emoticon
Please let me know if there is a way to pass PortletSession object or RenderRequest to Custom method.

E.g.

I have tried to create the following interface:

package com.myTool;


import javax.portlet.PortletSession;
import javax.portlet.RenderRequest;

public interface MyTest{
public String getUserCountry(PortletSession portletSession);
public String getUserCountry(RenderRequest request);
}

In class that implements interface I have the following methods:

public String getUserCountry(PortletSession portletSession) {
try {
myUtil.setPortletSession(portletSession);
return "Success";
}
catch (Exception e) {
e.printStackTrace();
return "exception-portletSession";
}

};

public String getUserCountry(RenderRequest request) {
try {
myUtil.setPortletSession(request.getPortletSession());
return "Success request";
}
catch (Exception e) {
e.printStackTrace();
return "exception-renderRequest";
}

};


I have tried the following ways with no luck:


1)
#set($currentProfileUtil = $utilLocator.findUtil("myportlets-1.0-SNAPSHOT", "com.myTool.MyTest"))
#set($result = $currentProfileUtil.getUserCountry($request.getAttribute("javax.portlet.response")))
$result

2)
#set($currentProfileUtil = $utilLocator.findUtil("myportlets-1.0-SNAPSHOT", "com.myTool.MyTest"))
#set($result = $currentProfileUtil.getUserCountry($request.get("portlet-session")))
$result

3)
#set($currentProfileUtil = $utilLocator.findUtil("myportlets-1.0-SNAPSHOT", "com.myTool.MyTest"))
#set($result = $currentProfileUtil.getUserCountry($request.getSession()))
$result

4)
#set($currentProfileUtil = $utilLocator.findUtil("myportlets-1.0-SNAPSHOT", "com.myTool.MyTest"))
#set($result = $currentProfileUtil.getUserCountry($request.getSession()))
$result


P.S. Please do not say "why do you need this?" - just provide any ideas on how to send PortletSession or any object from which PortletSession can be retrieved. Thanks
I hope I don't generally come off so pesimistic or condesending. My appologies if I do!

I'd just like to ask if you may be attempting this in web content templates? If so, there isn't a real "ServletRequest" or "HttpServletRequest" object. It's just a Map<String,<[String|Map]>> tree of string leaf nodes.

But what you are showing should be completely doable from theme template.

The reason the request is not a real "ServletRequest" is because the rendering happens within the service tier which can be invoked without any web context.

I've been wanting to add support for web context execution, but never had chance to do it.
Thanks for prompt response.

I am using Liferay-portal-6.1.1-ce-ga

even HttpSession should work for me though I am not sure how that should be passed correctly.

I am trying to send this from WebContent Template.
Ok, try this to get the real request:

#set ($serviceContext = $portal.getClass().forName("com.liferay.portal.service.ServiceContextThreadLocal").getServiceContext())
#set ($httpServletRequest = $serviceContext.getRequest())

For all the methods on ServiceContext see: https://github.com/liferay/liferay-portal/blob/6.1.1-ga2/portal-service/src/com/liferay/portal/service/ServiceContext.java
Hi Ray.Great Thread.

I have a question.

Velocity have a new tool that is ImportTool and i wanted to used in Templates(WebContent).

My problem is that in a hook i can not access to velocity-tools.jar, so my question is i need to make it in ext-plugin or exists any other way to do it.

The final goal is to include a jsp in a webcontent template.

Regards,

Rui Horta
You cannot include a jsp in a web content template even using that tool.

Why? The web content template context does not contain a real request/response object which is required for JSPs execution.
Hello Ray,

i'm trying this with an Spring-MVC Portlet istead of a Hook.
So in my web.xml is 'org.springframework.web.context.ContextLoaderListener' defined, which prevents me from using the mentioned 'PortletContextLoaderListener'.

When i try to lookup my bean, the BeanLocator for my context is 'null' (PortletBeanLocatorUtil->_beanLocators).

Do i need more configuration than the 'applicationContext.xml'-File in WEB-INF ?
Hello Ray,

Thank you for the useful post! However I'm having some troubles with classloaders while creating the spring context. I would like to import spring resource files from external libraries (<import resource="classpath:my-lib-resource.xml"/>) but I am always getting a FileNotFoundException. When I directly declare the beans in my "WEB-INF/applicationContext.xml" file, there is no problem.

From what I understood, the services created here will be registered in the PortalContext and made accessible to all the WARs deployed on the same server. However the classloader being the classloader of the server it cannot find the files defined with "classpath" that are located in the WAR file. Is this correct? And is there a way to import spring configuration files located in the classpath of the WAR?

I am using Liferay 6.2.10 on weblogic.

Thank you in advance !

Cédric
Hi

In Liferay 6.2 the com.liferay.portal.kernel.spring.context.PortletContextLoaderListener is deprecated and the methods i empty, do not ask me why Liferay has left a method without any code. To get this to work in Liferay 6.2 you can add this in you web.xml and remove the listener.

<context-param>
<param-name>portalContextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>