As it turns out the autoloader functionality is called when PHP is unable to find the class you are using automatically itself as a last effort. Though that wasn't the issue I encountered. It took me about 3 hours of debugging the function to find out there was a problem with the logic of the autoloader function I wrote myself, doh!

Something with breaking out of a loop to early . After fixing this issue my autoloader was working beautifully. So I am happy to say that it is possible to write a modular PHP web application after all.

Of course you could include every single file that you might need manually at the top of your index.php. But what if you don't need every single class every time a page is loaded, do you really want to create that kind of an overhead in loading un-needed files? I didn't, so I started looking into the autoloader functionality of PHP. What this feature does is allow you to scan through files in the predefined include directories and attempts to locate the class.

So what I did was build a simple autoloader function to scan each file in predefined directories to find the classes, and if found to stop. To my surprise this was working rather well. All classes that where needed would automatically get loaded by my little autoloader function. However somehow one particular class was not able to be loaded for some reason. The setup was something simple, something like:

• A predefined class A
• A class B which extended class A
• A class C which extended class B
• A class D which extended class C, and was located in a separate directory as it was specific for the website

All of the classes loaded beautifully, except for class D. For some reason when I tried using it I got exceptions that class C was undefined. When I added some debugging to find out which files where loaded I did see every file for classes A, B and C being loaded, but the actual classes defined inside where not added to PHP. Somehow I have magically created a black whole in PHP that would include files and then forget to create the class definitions internally. To this day I still haven't figured out why PHP refused to store the actual classes in its memory.

The quick fix I applied was ugly and stupid, just manually load the classes and build a big if statement around them to prevent duplicate declarations using the class_exists function.

Note: some parts of this script rely on the ant-contrib library. Download this library and include it in the tomcat.xml with the following code:

<taskdef resource="net/sf/antcontrib/antcontrib.properties">
 <classpath>
  <pathelement location="./ant-contrib-1.0b3.jar"/>
 </classpath>
</taskdef>

Starting tomcat

Though starting tomcat may seem easy. You could just use the development IDE (like Netbeans) to start and stop Tomcat, but what this lacks is the ability to control several instances with easy shortcuts. So I defined the following Ant macrodef in a file called tomcat.xml:

<macrodef name="tomcat-start">
 <sequential>
   <trycatch>
    <try>
      <if>
       <not><http url="http://localhost"/></not>
       <then>
         <java classname="org.apache.catalina.startup.Bootstrap"
             fork="yes"
             dir="${tomcat.dir}"
             spawn="true"
             jvm="${tomcat.java.home}/bin/java">
          <jvmarg value="-Dcatalina.home=${tomcat.dir}"/>
          <jvmarg value="-Dcatalina.base=${tomcat.dir}"/>
          <jvmarg value="-Djava.io.tmpdir=${tomcat.dir}/temp"/>
          <jvmarg value="-Djava.endorsed.dirs=${tomcat.dir}/common/endorsed"/>
          <jvmarg value="-Xdebug"/>
          <jvmarg value="-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"/>
          <classpath>
           <pathelement location="${tomcat.java.home}/lib/tools.jar"/>
           <pathelement location="${tomcat.dir}/bin/bootstrap.jar"/>
          </classpath>

          <arg line="start" />
         </java>

         <waitfor maxwait="10" maxwaitunit="second" checkevery="5000">
          <http url="http://localhost"/>
         </waitfor>
         <echo message="Tomcat started"/>
       </then>
       <else>
        <echo message="Tomcat already started..." />
       </else>
     </if>
    </try>
    <catch>
     <echo message="Unable to start tomcat"/>
    </catch>
  </trycatch>
 </sequential>
</macrodef>

This macro is really easy. First it starts of by checking if tomcat is not already running (well actually it just checks to see if there is something running on port 80). If nothing is running then tomcat is started using the java defined by the ant property tomcat.java.home. This macro also depends on some other properties that are set by a different macro, which will be a bit further on in the post. Tomcat is started by using the Bootloader class provided by the server, to make sure it loads correctly the classpath is set.

The last step in the macro is to wait for tomcat to start, this has to be done since we start tomcat in a seperate java instance (the spawn option).

Stopping Tomat

Off course you also want to be able to stop tomcat to load some new data, or an entire web-app. I use the following macro to stop Tomcat:

<macrodef name="tomcat-stop">
 <sequential>
  <trycatch>
   <try>
    <java classname="org.apache.catalina.startup.Bootstrap"
         fork="yes"
         dir="${tomcat.dir}"
         spawn="true"
         jvm="${java.home}/bin/java">
     <jvmarg value="-Dcatalina.home=${tomcat.dir}"/>
     <jvmarg value="-Dcatalina.base=${tomcat.dir}"/>
     <jvmarg value="-Djava.io.tmpdir=${tomcat.dir}/temp"/>
     <classpath>
      <pathelement location="${tomcat.java.home}/lib/tools.jar"/>
      <pathelement location="${tomcat.dir}/bin/bootstrap.jar"/>
     </classpath>

     <arg line="stop" />
    </java>

    <kill-java name="Bootstrap" />
    <echo message="Tomcat stopped" />
   </try>
   <catch>
    <echo message="Unable to stop tomcat forcing shutdown....."/>
    <kill-java name="Bootstrap" />
   </catch>
  </trycatch>
 </sequential>
</macrodef>

Just like with the starting of Tomcat I use the provided Bootloader class to instruct tomcat to stop. Again I use the java that is set in tomcat.java.home as well as some other properties loaded by another macro. Since Tomcat sometimes fails to stop gracefully (due to poorly designed webapps) you also have to kill the Java process of Tomcat. This is done with the call to kill-java.

Killing any java process

As you saw in the tomcat-stop macro I used a macro called kill-java to make sure that Tomcat is really killed and no longer running in the background. The macro is as follows:

<macrodef name="kill-java"
          description="Forcefully stop tomcat....">
 <attribute name="name"/>
 <sequential>
  <!-- Execute the jps and check for any Java process with the provided @{name} attribute -->
  <exec executable="${tomcat.java.home}/bin/jps" output="pid.out.file" />
  <!-- Load in the name / pid file and strip all information except the PID -->
  <loadfile srcfile="pid.out.file" property="pid.out">
   <filterchain>
     <linecontains>
      <contains value="@{name}"/>
     </linecontains>
    <tokenfilter>
    <deletecharacters chars="@{name}"/>
    <trim/>
    <ignoreblank/>
    </tokenfilter>
    <striplinebreaks/>
   </filterchain>
  </loadfile>
  <echo message="Killing java process with pid ${pid.out}"/>
  <!-- Kill the process, warning this only Works on Windows -->
  <exec spawn="true" executable="taskkill">
   <arg line="/PID ${pid.out}" />
   <arg line="/F" />
  </exec>
  <delete file="pid.out.file" />
 </sequential>
</macrodef>

This macro is really simple and relies on the jps application provided by Java. This application returns a list of all running processes with name and process id (PID). All we need to do is get the line containing the process name provided and strip everything except the PID.

Please note: the task killing the proces is designed for Windows, you could change this with kill in Linux.

Rounding it up

Though you now have all you need to manipulate tomcat there is one last macro that we are tegenkant upon. That is the initializer of the various Tomcat properties. I use the following macro:

<macrodef name="tomcat-init">
 <attribute name="from"/>
 <sequential>
  <property name="tomcat.dir" value="${tomcat.@{from}.dir}"/>
  <property name="tomcat.server" value="${tomcat.@{from}.server}"/>
  <property name="tomcat.port" value="${tomcat.@{from}.port}" />
  <property name="j2ee.server.type" value="${tomcat.server}" />
  <taskdef name="webapp-stop"
          classname="org.apache.catalina.ant.StopTask"
          classpath="${tomcat.dir}/server/lib/catalina-ant.jar"/>
  <taskdef name="webapp-start"
           classname="org.apache.catalina.ant.StartTask"
           classpath="${tomcat.dir}/server/lib/catalina-ant.jar"/>
 </sequential>
</macrodef>

This little macro will initialize tomcat for a specific environment (for exemple DEV). Of course none of this works without the loading of some preset properties in a property file tomcat.properties. Which contains the following data:

tomcat.java.home=C:/jdk1.5.0_22_32b

tomcat.DEV.dir=d:/jakarta/tomcat5.0
tomcat.DEV.server=tomcat55-DEV
tomcat.DEV.port=8000

tomcat.MAIN.dir=d:/jakarta/tomcat5.0-MAIN
tomcat.MAIN.server=tomcat55-MAIN
tomcat.MAIN.port=8000

To load the property file just include the following instruction in the build script:

<property file="./tomcat.properties" />

Last week I did a lot of debugging on the Debian server to try and find out what was the issue. And initially it was Dovecots memory usage. After disabling this tool for a couple of days the server was still running fine. However the day after I posted the article on Dovecot the server crashed again. So I had to restart my investigation.

First off I had to had to get a better memory management tool, so I installed Htop on the server (apt-get htop). This shows the current memory usage of each running application. After installing this I enabled all services and applications again and started running stress tests. And though Dovecot was causing some peeks in memory usage it did not keep the high memory usage after the requests where done.

As it turns out for some reason Apache 2.2 was using a lot of memory during peak loads. But even more frustrating it didn’t seem to release any memory any more. Which was causing issues for services that only spawn when they are being accessed like Dovecot and Postfix, which explained why both of these services crashed when the server halted.

After tweaking the maximum amount of servers Apache is allowed to start and the maximum amount of client threads to handle the memory usage dropped dramatically. And I am very happy to report that the server has been running again for more then a week, without any glitches.

Still it doesn’t explain why all of this only happened after updating my server with the latest versions and patches. But I’m glad it’s solved for now.

The reason for me not to write one straight away was simple, I first wanna play around a little to find all the pleasant features and those less pleasant ones.

Bigger, better, best

The first thing you expect is this new version to be bigger, better and the best one yet. Well it is bigger in size, with 190MiB for just Java development. So this means a lot more time downloading, but hey that’s a one time thing.

So lets move onto something more relevant. Is it better then Netbeans 6.1. Lets summorize some of the issues I had with the previous version and see if the problem is solved:

1. It crashed when working on larger projects. This issue has been fixed, netbeans won’t crash or hang. Though on occasion the parser may crash. Disabling autocomplete and syntax checking.
2. For some reason previous versions had difficulty displaying the names of parameters when using Java libraries. For as far as I’ve been able to determine this has been solved.
3. The autocomplete completely fails in some more complicated web projects. Well I’m sorry to say this is still true. For some projects not only does autocomplete fail, but so does the syntax checker, both for the JSP files as well as the Java Source files.

So are there any other changes that would make you consider moving from Netbeans 5.5 to 6.5?

New stuff you will like in Netbeans 6.5

Well have there been any changes that would make you wanna switch to the new version.

• The new version actually has some basic debugging integrated of JavaScript. Though I haven’t got it working yet.
• PHP development is now support. Which is a big plus, but it still kinda feels like a cheap addon that doesn’t work perfectly yet. (Maybe in the next release)
• Thread debugging has been improved and made easier

Unfortunattely not all is good in the world of Netbeans. There are also some new bugs, some of which are really annoying.

• For some unexplainable reason adding of libraries by right clicking the ‘Libraries’ in the project view doesn’t work all the time.
• Like I stated earlier the code completion fails in some of the older Java project I’m working on. Not only does code completion fail, but the syntax checker tells me every single line is wrong. Even though the project compiles beautifully

As a final note: is it worth upgrading to this version. Then I’d have to say hell yeah, it’s a lot better then previous versions. If you are a PHP developer however I suggest not using it, for the moment. Especially when you are already using Zend-Studio, which is still a lot better.

This on its own is not that big of a deal, but I can’t seem to trace down why it’s happening. If I debug the function that causes the error has no issues. No memory violations, but when I continue running (without debugging every single call) then all of a sudden at some point in time I get a memory access violation.

Now I don’t exactly know where it’s comming from. It may have something to do with the fact that the object I’m deleting is a prototype of a prototype. And also occasionally gives me an error during compile time that I have no destructor in the class. But when I compile the files one by one it does not give this error. And the class in question does have a default destructor.

Hmm, guess it’s time for some real line by line debugging and digging into the internet about the obscure error message I got.