smithproject.org

I thought I'd try smith under j2ee and deploy the war, it wouldn't start, the administration interface has an option to verify the war integrity so I clicked it and this is what I got
Code:

 10/21 11:45:53 validating WAR
 10/21 11:45:53 web.xml: scanned
 10/21 11:45:55 web.xml: parsed
 10/21 11:45:57 web.xml: no errors found in syntax
 10/21 11:45:58 web.xml: processing
 10/21 11:45:59 cfmservlet: init
 10/21 11:46:05 testing welcome-file 
 10/21 11:46:06 error javax.servlet.http.HttpServletResponse.setCharacterEncoding(Ljava/lang/String;)V
 java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.setCharacterEncoding(Ljava/lang/String;)V
         at com.youngculture.smith.engine.servlets.SmithWrapperResponse.defineResponseHeader(SmithWrapperResponse.java:229)
         at com.youngculture.smith.engine.servlets.SmithServlet.writeOutput(SmithServlet.java:333)
         at com.youngculture.smith.engine.servlets.SmithServlet.serviceRequest(SmithServlet.java:206)
         at com.youngculture.smith.engine.servlets.SmithServlet.service(SmithServlet.java:112)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 10/21 11:46:08 incomplete or missing dependancies, WAR is defective 
 10/21 11:46:09 validation aborted

Pretty frustrating for somehting that is claimed to be so good yet so difficult to utilize.

Well, my next step was to try it under JRun4 and deploy the WAR there, well it didn't work there either.

Last, I deicided to try JBoss, strangely enough it worked there but since I'm not a JBoss fan I shit-canned it.

My understanding of a WAR is that it should be self contained and all depndancies included because all j2ee environments are not created equal but this rule appears not to have been followed as noted by the error.

For grins and giggles I tried it as an EAR, it was amusing to say the least, it puked on the paths and due to the lack of ability to specify work and scratch dirs in the init stage it just refused to cooperate, no I didn't try to deply it an a physical archive, I used the EAR tree structure which seems to work with everything else I've deployed in this manner.

Is everything broken in the smithcf distributions or did they specifically design it to work OK in Tomcat and JBoss and the tainted method of jetty deployment included in the distribution?

I wouldn't mind contributing my work to the project but since I'm feeling the lack of any support I find it hard to justify any contributions.

Maybe it's time to take the smithcf engine and fork/rebrand it so that these issues can be resolved in a timely manner cause I can't see them fixing even the basic distribution deployment issues.

Maybe I'll wait for the next release to see if they have at least fixed the path configuration issues and the jetty deployment issue before moving ahead with a fork/rebrand thus moving forward towards a more easily deployable package.

Hello BuildSmart,

it's not that a dependency jar is missing in the war.

javax.servlet.http.HttpServletResponse mentioned in the error report is a standard java interface, but it seems not to be the same in j2ee and in j2se.

j2se version has javax.servlet.http.HttpServletResponse.setCharacterEncoding() method, but it seems to be unavailable in j2ee.

this should be fixable by replacing the call to setCharacterEncoding() with a call to setContentType() method, but a little problem here is that, at this point, smith cf does not know the content type (i.e., from your cfml page, you could emit plain text, xml, html, ...)

here's a little example of content type: "text/html; charset=UTF-8" denoting that output has html format and is encoded in utf-8.

I'm not sure if you can set content type only to " ; charset=UTF-8", actually omitting the content type and specifying only the encoding.

anyway, you should post this as a bug at smithcf sourceforge tracker.

setCharacterEncoding was added to ServletResponse in J2EE 1.4.
The container should provide javax.servlet.http.HttpServletResponse.setCharacterEncoding, not Smith.

ref: http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#setCharacterEncoding(java.lang.String)

Perhaps you were using a J2EE 1.3-only (or earlier...) server?

-tom-