In Liferay 6.1 The class ServletResponseUtil has been moved to a different package than in Liferay 6.0:
//Liferay 6.0,
// this class lives in util-java.jar in the default tomcat web app, /webapps/ROOT/lib.
import com.liferay.util.servlet.ServletResponseUtil;
//Liferay 6.1
// class lives in portal-service.jar in directory tomcat-7.../lib/ext/
//import com.liferay.portal.kernel.servlet.ServletResponseUtil;
The class is used in our code like this:
String result = personComponentImpl.process(request);
response.setContentType("text/xml");
try {
ServletResponseUtil.write(response, result);
}
catch (Exception e) {
if (_log.isWarnEnabled()) {
_log.warn(e, e);
}
}
I have to maintain and improve a portlet that was written for the Liferay 6.0 release.
Now we are considering upgrading to 6.1, but during internal testing of the portlet I discovered that there are a few line of code where the above mentioned dependency is broken. There are ClassNotFoundExceptions on 6.1 at runtime.
My eclipse project is set up for 6.0 in mind.
What should I do now?:
-
Maintain two different branches of the portlet code. This is doable but might be too much effort in the long run
-
Maintain two different Eclipse projects with one code base, but with different build paths (this is only a general strategy, might not really work)
-
Include a clever hack in the java code, to build easily for 6.0, once for 6.1 (maybe a factory…this is only a vague idea)
-
Include a new ant task that builds + deploys for 6.1, although Eclipse is set up to build for 6.0
-
Remove the dependency on ServletResponseUtil class altogether, use another class that does the same as ServletResponseUtil.
-
Do something else
Since ServletResponseUtil is not much more than a 350 lines long, extremely verbose and even buggy implementation of
response.getOutputStream().write(data);, I would opt for “use another class that does the same”.Perhaps you should combine that with a little “do something else” and never rely on the stability of the Liferay API.