[jlumnas]

Has anybody successfully installed and used Cactus with MyEclipse or Eclipse? I have been to the apache website (http://jakarta.apache.org/cactus/integration/eclipse/webapp_plugin.html ) and it says I must down load the org.apache.cactus.integration.eclipse_[version]. However I cannot find the that file anywhere. I have downloaded and explanded the jakarta-cactus-12-1.7.zip file but am not sure what to do with it other that copy the jars into the class path. does anybody know where to get the org.apache.cactus.integration.eclipse_[version]?

Thank you in advance

Jeff Sulman

[jlumnas]

I believe I just found an answer to my question. At http://jakarta.apache.org/cactus/integration/eclipse/index.html apache says:

The Eclipse plugin is a work in progress. In the past it was working, but since we moved to the new Ant integration it has been broken. This requires a rewrite of the plugin code to fix. In the meantime, we have removed the plugin download. Sorry about that. Any help will be much welcome.

I think this answers my question. Does anybody know any thing else about this?

If anybody is using Cactus with MyEclipes please let me know how it is going.

Jeff Sulman

[gsl1]

I have pseudo-successfully gotten Cactus running inside Eclipse 3.2M1 with MyEclipse 4.0GA.

I loaded the following jars into a user library set I called Cactus and placed it into the build path:
jakarta-cactus-13-1.7.1/lib/aspectjrt-1.2.1.jar
jakarta-cactus-13-1.7.1/lib/cactus-1.7.1.jar
jakarta-cactus-13-1.7.1/lib/cactus-ant-1.7.1.jar
jakarta-cactus-13-1.7.1/lib/cargo-0.5.jar
jakarta-cactus-13-1.7.1/lib/commons-httpclient-2.0.2.jar
jakarta-cactus-13-1.7.1/lib/commons-logging-1.0.4.jar
jakarta-cactus-13-1.7.1/lib/httpunit-1.6.jar
jakarta-cactus-13-1.7.1/lib/junit-3.8.1.jar
jakarta-cactus-13-1.7.1/lib/nekohtml-0.9.1.jar
jakarta-cactus-13-1.7.1/lib/org.mortbay.jetty-4.2.17.jar
jakarta-cactus-13-1.7.1/lib/servletapi-2.3.jar
jakarta-cactus-13-1.7.1/lib/jboss-j2ee-3.2.3.jar
apache-ant-1.6/lib/ant.jar

I separately loaded the two jasper jars from Tomcat version 4.1.30 into the build path:
jakarta-cactus-13-1.7.1/lib/jasper-compiler-4.1.30.jar
jakarta-cactus-13-1.7.1/lib/jasper-compiler-4.1.30.jar

I loaded the J2EE 1.3 Library Container into the build path.

I created two source folders called src and srcTest respectively and I loaded the Cactus Jetty sample from the Cactus 1.7.1 distribution into each source folder. Non test classes were placed in the src folder and test classes were placed under the srcTest folder starting with the org package in each case.

I installed the web.xml deployment descriptor from the Cactus Jetty sample under WEB-INF under WebRoot.

I installed the jspRedirector.jsp under WebRoot.

I installed a new folder named test under WebRoot and placed the test.jsp under it.

I created a new folder named conf directly under the project root and placed the Cactus Jetty sample jetty.xml config file under it.

I then opened the org.apached.cactus.sample.jetty.TestJettyAll.java class and right-clicked to select Run As/Run…, confirmed the correct project and test class and entered the following arguments under the Arguments tab as a single line:

-Dcactus.contextURL=”http://localhost:8080/test” -Dcactus.jetty.config=conf/jetty.xml -Dcactus.jetty.resourceDir=WebRoot

I then selected run and Jetty ran in the console with:

20:08:39.063 EVENT Checking Resource aliases
20:08:39.776 EVENT Starting Jetty/4.2.17
20:08:39.961 EVENT Started WebApplicationContext[/test,WebRoot]
20:08:40.008 WARN!! Delete existing temp dir /tmp/Jetty__8080__test for WebApplicationContext[/test,WebRoot]
20:08:40.198 EVENT Started SocketListener on 0.0.0.0:8080
20:08:40.199 EVENT Started org.mortbay.jetty.Server@1457cb
Oct 26, 2005 8:08:41 PM org.apache.commons.httpclient.HttpMethodBase processResponseHeaders
WARNING: Cookie rejected: “$Version=0; responsecookie=this%20is%20a%20response%20cookie; $Domain=jakarta.apache.org”. Illegal domain attribute “jakarta.apache.org”. Domain of origin: “localhost”
20:08:47.719 EVENT Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8080]
20:08:47.723 EVENT Stopped SocketListener on 0.0.0.0:8080
20:08:47.724 EVENT Stopped WebApplicationContext[/test,WebRoot]
20:08:47.724 EVENT Stopped org.mortbay.jetty.Server@1457cb

and I received a green bar and 24/24 passed tests under the Eclipse Junit plugin.

The only problem with this, is that MyEclipse has moved beyond Cactus (J2EE 1.3, Servlet 2.3, Jasper for Tomcat 4.1.30) and appears to use Servlet 2.4 and Jasper for Tomcat 5.x. This causes a conflict to occur in the JSP editor during validation and will do the same during some types of runs with Cactus where the classes, of course, don’t match up. For example, the jspRedirector.jsp when in the JSP editor shows the following class mismatch error:

org.apache.jsp.jspRedirector_jsp is not abstract and does not override abstract method getIncludes() in org.apache.jasper.runtime.HttpJspBase: public final class jspRedirector_jsp extends org.apache.jasper.runtime.HttpJspBase.

jspRedirector.jsp CactusJettySample/WebRoot line 1 October 26, 2005 7:13:30 PM

where the code __seems__ to be compiled with the new Jasper runtime class org.apache.jasper.runtime.HttpJspBase which does not contain the method getIncludes() but is being validated with the old Jasper runtime classes that require it. This seems strange to me, since the old Jasper jars are the ones that I put into the build path (see above list).

Trying to go forward and use Tomcat 5.x Jasper jars in the build path just exacerbates the mismatches with Cactus. Going backwards seems less painful.

Is there any way to get MyEclipse to revert back to the old Jasper compiler and runtime jars from Tomcat 4.1.30? Is MyEclipse even the culprit?

I changed the runtime jar at:

MyEclipse/eclipse/plugins/com.genuitec.eclipse.wdt.jsp.debug_3.9.310/jasper-runtime.jar

to the older jasper runtime jar and restarted Eclipse, but this did not seem to do the trick. I suspect I changed the wrong jar, but I couldn’t find another good candidate to change.

Here is the complete command line from a “successful” run:

/usr/local/java/jdk1.5.0_04/bin/java -Dcactus.contextURL=http://localhost:8080/test -Dcactus.jetty.config=conf/jetty.xml -Dcactus.jetty.resourceDir=WebRoot -Xbootclasspath/a:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/activation.jar:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/jts.jar:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/jsse.jar:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/mail.jar:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/javax.servlet.jar:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/jboss-jaas.jar:/usr/local/java/MyEclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_4.0.0/data/libraryset/1.3/jboss-j2ee.jar -classpath /home/gsl/workspace/CactusJettySample/WebRoot/WEB-INF/classes:/usr/local/java/jakarta-cactus-13-1.7.1/lib/aspectjrt-1.2.1.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/cactus-1.7.1.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/cactus-ant-1.7.1.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/cargo-0.5.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/commons-httpclient-2.0.2.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/commons-logging-1.0.4.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/httpunit-1.6.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/junit-3.8.1.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/nekohtml-0.9.1.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/org.mortbay.jetty-4.2.17.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/servletapi-2.3.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/jboss-j2ee-3.2.3.jar:/usr/local/java/apache-ant-1.6/lib/ant.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/jasper-compiler-4.1.30.jar:/usr/local/java/jakarta-cactus-13-1.7.1/lib/jasper-runtime-4.1.30.jar:/usr/local/java/eclipse/plugins/org.eclipse.jdt.junit_3.1.0/junitsupport.jar:/usr/local/java/eclipse/plugins/org.eclipse.jdt.junit.runtime_3.1.0/junitruntime.jar org.eclipse.jdt.internal.junit.runner.RemoteTestRunner -version 3 -port 2861 -classNames org.apache.cactus.sample.jetty.TestJettyAll

-=> Gregg <=-

[gsl1]

Well, I attempted to go forward again and discovered that I had been missing jars which were causing some of the problems I had previously seen. I replaced the two old Jasper jars with the two new Jasper jars from Tomcat 5.5.9 and I added the missing jars:

tomcat-5.5.9/common/lib/jsp-api.jar
tomcat-5.5.9/common/lib/comons-el.jar

to my Cactus library set, cleaned and rebuilt the project and ran it yielding:

06:28:30.382 EVENT Checking Resource aliases
06:28:30.833 EVENT Starting Jetty/4.2.17
06:28:31.012 EVENT Started WebApplicationContext[/test,WebRoot]
06:28:31.041 WARN!! Delete existing temp dir /tmp/Jetty__8080__test for WebApplicationContext[/test,WebRoot]
06:28:31.141 EVENT Started SocketListener on 0.0.0.0:8080
06:28:31.142 EVENT Started org.mortbay.jetty.Server@1457cb
Oct 27, 2005 6:28:32 AM org.apache.commons.httpclient.HttpMethodBase processResponseHeaders
WARNING: Cookie rejected: “$Version=0; responsecookie=this%20is%20a%20response%20cookie; $Domain=jakarta.apache.org”. Illegal domain attribute “jakarta.apache.org”. Domain of origin: “localhost”
Oct 27, 2005 6:28:37 AM org.apache.jasper.runtime.PageContextImpl release
WARNING: Internal error flushing the buffer in release()
Oct 27, 2005 6:28:37 AM org.apache.jasper.runtime.PageContextImpl release
WARNING: Internal error flushing the buffer in release()
Oct 27, 2005 6:28:37 AM org.apache.jasper.runtime.PageContextImpl release
WARNING: Internal error flushing the buffer in release()
Oct 27, 2005 6:28:37 AM org.apache.jasper.runtime.PageContextImpl release
WARNING: Internal error flushing the buffer in release()
Oct 27, 2005 6:28:37 AM org.apache.jasper.runtime.PageContextImpl release
WARNING: Internal error flushing the buffer in release()
06:28:38.097 EVENT Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8080]
06:28:38.125 EVENT Stopped SocketListener on 0.0.0.0:8080
06:28:38.127 EVENT Stopped WebApplicationContext[/test,WebRoot]
06:28:38.128 EVENT Stopped org.mortbay.jetty.Server@1457cb

This eliminated the class mismatch in the JSP validation of jspRedirectory.jsp (and test.jsp for getIncludes()) and produced 24/24 successful tests. I’m still investigating the buffer flushing warning from Jetty, but this looks more promising and its using current api’s.

-=> Gregg <=-

[gsl1]

Further analysis of the following warning:

Oct 29, 2005 8:29:37 AM org.apache.jasper.runtime.PageContextImpl release
WARNING: Internal error flushing the buffer in release()

has shown the following:

This warning is located in the org.apache.jasper.runtime.PageContextImpl.release method. After some analysis, I have determined that the org.apache.cactus.server.JspRedirector class invokes its doGet method in order to get the test results. This in turn invokes the org.apache.cactus.internal.server.AbstractWebTestCaller.doGetResults which invokes org.apache.jasper.runtime.JspWriterImpl.close. Now close, as one would expect, flushes the buffer and then sets a close flag to true to indicate that the stream is closed.

Now we come to the problem and the reason why the above warning is generated. If we look at the code generated by the Jasper compiler for the jspRedirector.jsp, we find the following (To highlight the relevant code, I removed some irrelevant stuff at the beginning and middle of the file):

… (code removed here)

public final class jspRedirector_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {

… (code removed here)

JspTestRedirector redirector = new JspTestRedirector();
redirector.doGet(objects); # <<<<<<<<<<<<————————-

} catch (Throwable t) {
if (!(t instanceof SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
if (_jspx_page_context != null) _jspx_page_context.handlePageException(t);
}
} finally {
if (_jspxFactory != null) _jspxFactory.releasePageContext(_jspx_page_context); # <<<<———
}
}
}

Notice that after the doGet and after the stream is closed, releasePageContext is invoked on the same stream in the finally clause. This causes another attempt to flush the buffer as shown by the following:

0:org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:219)
1:org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:118)
2:org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:183)
3:org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:115)
4:org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:75)
5:org.apache.jsp.jspRedirector_jsp._jspService(jspRedirector_jsp.java:80)
…

As soon as ensureOpen is invoked, it checks to see if the stream is open, discovers that it is not and throws an IOException which
percolates up into the warning described above.

Now, since the buffer was already flushed when the stream close was invoked, I assume that the warning can safely be ignored (please correct me, if I’m wrong); however, I’m not sure how the code can be fixed without having Jasper __not__ produce the buffer release in the finally clause or by not issuing the close within AbstractWebTestCaller.doGetResults (something that doesn’t seem right either).

I have sent the above analysis to the Cactus dev group and am awaiting their input. In the mean time, I have been successfully using Cactus for a day, so it appears that the warning can safely be ignored.

-=> Gregg <=-

[Author]

Posts