Demo.setup: Tomcat properties only working for Linux and Mac

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

thilka

… but not for windows.

In the tomcat.install task in the demo setup, there is some special handling to put the JAVA_OPTS in the catalina.sh file for Linux and Mac. But there is no equivalent handling for the catalina.bat file used under windows.

There was an error concerning the PermGenSpace of the tomcat under windows. It was almost impossible to try the demos since the tomcat ran out of (PermGenSpace) Memory. That's how I found the missing JAVA_OPTS handling for windows.

I fixed the issue, see the code below.

  <target name="tomcat.install">
    <mkdir dir="${activiti.home}/apps" />
    <property name="tomcat.distro" value="${downloads.dir}/${tomcat.filename}" />
    <available property="is.tomcat.available" file="${tomcat.distro}" />
    <antcall target="internal.download.tomcat" />
    <unzip src="${tomcat.distro}" dest="${activiti.home}/apps"/>
    <available file="${user.home}/.activiti/tomcat-users.xml" property="tomcat.users.available" />
    <antcall target="tomcat.copy.users" />
    <antcall target="tomcat.enable.debug" />
    <replace file="${tomcat.home}/bin/catalina.sh">
      <replacetoken><![CDATA[#!/bin/sh]]></replacetoken>
      <replacevalue><![CDATA[#!/bin/sh

JAVA_OPTS=$JAVA_OPTS" @tomcat.java.opts@"
]]></replacevalue>
    </replace>
    <replace file="${tomcat.home}/bin/catalina.sh" token="@tomcat.java.opts@" value="${tomcat.java.opts}" />
    <chmod perm="a+x" os="Linux, Mac OS X">
      <fileset dir="${tomcat.home}/bin">
        <include name="*.sh" />
      </fileset>
    </chmod>
     
     <!– begin special handling for windows –>
     <replace file="${tomcat.home}/bin/catalina.bat">
           <replacetoken><![CDATA[rem —– Execute The Requested Command —————————————]]></replacetoken>
           <replacevalue><![CDATA[rem —– Execute The Requested Command —————————————

set JAVA_OPTS=%JAVA_OPTS% @tomcat.java.opts@
     ]]></replacevalue>
   </replace>
    <replace file="${tomcat.home}/bin/catalina.bat" token="@tomcat.java.opts@" value="${tomcat.java.opts}" />
     <!– end special handling for windows –>
     
     <copy file="${activiti.home}/setup/files/tomcat/logging.properties" todir="${tomcat.home}/conf" overwrite="true" /> 
  </target>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

In general, could you please add some troubleshooting guide to your demo setup environment?
There were three problems when I tried to run RC1 demos on my computer:
(1) The proxy was not set correctly. Therefore, maven could not find the jars to download. (Fixed by patching the settings.xml file in maven's conf folder)
(2) If the libs-runtime/libs-test folder already existed, maven did not download the files after setting the proxy correctly. Removing those folder resulted in proper downloading of the dependent libraries. I think the folders were created before the proxy error failed the demo.setup. So could you just add some kind of clean task to clean those output folders?
(3) The issue with PermGenSpace which were caused by the error described above.

I think it is great to have some kind of "magic" target like demo.setup which sets up all the necessary components. But if something goes wrong, the users are frustrated since they don't understand all the magic behind the scenes. Some troubleshooting guide and some more testing on windows would help the user to get going with activiti more quickly. I already heared from a friend of mine who tried to evaluate activiti, but gave up after half a day since the magic did not work.

Don't get me wrong, I really like activiti. But it would be nice to get the demo-setup working without having to fix several "magic" issues.

Tobias

jbarrez

Hi Tobias,

Thanks for the feedback. It this kind of feedback that makes Activiti better every day.
We do test on Windows. We run a demo setup and try everything out. But apparantly not enough.

Some responses:

(1) The proxy was not set correctly. Therefore, maven could not find the jars to download. (Fixed by patching the settings.xml file in maven's conf folder)

Could you elaborate on that? We test the demo setup on a clean windows VM, which doesnt have any settings.xml configured …

(2) If the libs-runtime/libs-test folder already existed, maven did not download the files after setting the proxy correctly. Removing those folder resulted in proper downloading of the dependent libraries. I think the folders were created before the proxy error failed the demo.setup. So could you just add some kind of clean task to clean those output folders?

Yes, cleaning should fix it. However, seeing all the issues attached to it, we are aware that our approach here has been not working out as how we have thought it would.
We are currently refactoring it completely. We will go back to a more simple, one big /lib folder.

(3) The issue with PermGenSpace which were caused by the error described above.

Could you make a patch of your fix, and attach it to the following Jira issue: http://jira.codehaus.org/browse/ACT-320. This way, we can track it, and it ends up in the changelog of next release.

Don't get me wrong, I really like activiti. But it would be nice to get the demo-setup working without having to fix several "magic" issues.

Thats obviously our no 1 priority.
We try to make it as simple as possible, but it seems not to be perfect yet -  but we're working on that!
Many thanks for your elaborate feedback, these kind of posts really bring the project further!