Develop Reference

Running tag library from older Tomcat version

First some background.
I am developing a web application. This application is installed as an extension of a third party commercial web application. The thrid party provides an SDK for our application to interact with the main web application. As such, we have no control over the environment in which our application runs. We are at the mercy of the third party application.
Now for the problem.
Our application packages a custom tag library used by our JSPs. It is a requirement of the third party application that we ship only precompiled JSPs. We have no problem compiling the JSPs along with the necessary .tag files.
The third party has come out with a new version of their software. We are to support a smooth upgrade of our extension from the old version of their software to the new version.
The old version of the third party software runs on top of Tomcat 5.5. Our JSPs are built using the tomcat 5.5 JSP compiler. The new version runs on Tomcat 7. After the upgrade, our extension still runs except the tags are not evaluated correctly.
The tags emit the correct HTML however, any attributes passed to the tags seem to be lost.
As an example, I created a simple test tag:
<%# attribute name="testValue" required="true" %>
<div name="${testValue}" >
${testValue}
</div>
This is used in the JSP as such:
<my:testDiv testValue="myNewTestValue" />
On Tomcat 5.5, it is evaluated and produces the following:
<div name="myNewTestValue" >
myNewTestValue
</div>
However, the same code when run Tomcat 7, the HTML is output, but the attribute is not. Note that ${testValue} is processed but replaced with an empty value, not the value that was given.
<div name="" >
</div>
If I compile the same code using the Tomcat 7 compiler, it works again.
<div name="myNewTestValue" >
myNewTestValue
</div>
Obviously, the version built with the Tomcat 7 JSP compiler won't run on the old version. Given the Tomcat 5.5 build won't run on the new version we don't have a smooth transition.
I've been poking around for a few weeks online trying to find a mention of this issue or even something similar and have come up with little. At least nothing that has lead me to a solution.
Is there a known issue running tags compiled with the Tomcat 5.5 compiler on Tomcat 7? Is there some magic incantation I need to chant?
Some additional info:
We are building with Maven. The relevant portions of the pom:
<!-- Precompile JSPs -->
<!-- <dependency> -->
<!-- <groupId>org.apache.tomcat</groupId> -->
<!-- <artifactId>tomcat-jasper</artifactId> -->
<!-- <version>7.0.21</version> -->
<!-- <scope>compile</scope> -->
<!-- </dependency> -->
<dependency>
<groupId>tomcat</groupId>
<artifactId>jasper-compiler</artifactId>
<version>5.5.23</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>tomcat</groupId>
<artifactId>jasper-runtime</artifactId>
<version>5.5.23</version>
<scope>compile</scope>
</dependency>
Built using the antrun plugin:
<execution>
<id>compile-jspc</id>
<phase>compile</phase>
<configuration>
<target>
<taskdef classname="org.apache.jasper.JspC" name="jasper">
<classpath>
<pathelement location="${env.JAVA_HOME}\lib\tools.jar"/>
<path refid="maven.compile.classpath" />
</classpath>
</taskdef>
<jasper
caching="false"
verbose="0"
uriroot="${project.build.directory}/jsp"
webXmlFragment="${project.build.directory}/generated_web.xml"
outputDir="${project.build.directory}/jspc_out" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
<execution>
<id>compile-jspc-java</id>
<phase>compile</phase>
<configuration>
<target>
<javac fork="true" executable="${env.JAVA_HOME}/bin/javac"
srcdir="${project.build.directory}/jspc_out" destdir="${project.build.directory}/classes"
deprecation="false" optimize="true">
<classpath refid="maven.compile.classpath" />
</javac>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>

I think the best thing to do is probably install a Tomcat 7 test box and put your application on it as is. Get it working on 7 and then replace even the production box of the old version with Tomcat 7. When I did that, I also had an issue with tags moving from Tomcat 5.5 to Tomcat 7, but a simpler one.
I had to change:
<jsp:param name="UserID" value="<%=request.getParameter("UserID")%>" />
to:
<jsp:param name="UserID" value='<%=request.getParameter("UserID")%>' />
Double quotes to single where I was printing a request parameter into an attribute value and obviously had to use double quotes in the code inside the attribute value. Either way works in Tomcat 5.5, but only the second works in 7.

How to configure hibernate logging using log4j2.xml?

I recently switched to Apache log4j2, and still can not find a way to configure hibernate logging using log4j2.xml.
Because I can not find a way around this problem I still use log4j.properties file explicitly for hibernate. This is not the best solution since my log4j2.xml uses JPA appender (writes logs to db). I do not want to write separate logic for hibernate.
Is there a way to configure hibernate logging using log4j2?

As suggested in
https://issues.apache.org/jira/browse/LOG4J2-172
you can add system property to force hibernate use slf4j
-Dorg.jboss.logging.provider=slf4j
also log4j-slf4j-impl should be added to classpath
My custom solution:
with Spring you can place
org.jboss.logging.provider=slf4j
in property file
(envConfigLocation is file url)
<bean id="propertyConfigurer" class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
<property name="location" ref="envConfigLocation" />
<property name="order" value="1"/>
</bean>

I found an answer to this question at: How to redirect all logs from hibernate and spring to log4j2?
Basically log4j2 doesn't work with Hibernate so you have to use log4j. But you still use your log4j2 configuration. You need the following dependencies and then the magic happens in the background.
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<!--HIBERNATE LOGGER (log4j)-->
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.6</version>
</dependency>

It is possible to redirect calls to the log4j-1.x API to the log4j-2.0 implementation. The FAQ about which jars to include explains how to do this. You probably need to remove the old log4j-1.x jar from the classpath when you do this.

Spring - Build path is incomplete. Cannot find class file for org/springframework/beans/factory/Aware in dispatcher-servlet.xml

I installed Spring Tool Suite and am now using it for a little sample project. However I keep having an error in my dispatcher-servlet.xml file:
Build path is incomplete. Cannot find class file for org/springframework/beans/factory/Aware
This error is highlighted here:
<bean
**class="org.springframework.web.servlet.view.InternalResourceViewResolver">**
<property name="prefix">
<value>/WEB-INF/pages/</value>
</property>
<property name="suffix">
<value>.jsp</value>
</property>
</bean>
Any thought?

I think you may have some old jar files in your configuration. Try using the most current spring libraries.

I found my self in exactly the same case when I used incompatible maven spring-dependencies i.e check Spring Security Site on the right side where it explains what spring version should be used with what spring security version.

The project is missing the servlet-api jar and the error can be resolved by adding the dependency in the maven pom file
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>

you can put this dependency with your spring version :
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring-version}</version>
<scope>compile</scope>
</dependency>

If you are using eclipse:
Right click on root project -> properties.
Click on Deployment Assembly.
Click add button.
Double click on Java Build Path Entries and Select build path
entries to include. (maybe if you are using maven, you need also
include those dependencies).
Finally clean and build.
This worked for me.

Apache Camel scripting problem

I have a very strange problem with Apache ActiveMQ with Camel - I tried the examples with javascript and groovy, but they both produce error "Failed to install route: Failed to create route... because of No language could be found for: groovy"
The groovy example I use is
<route>
<from uri="queue:foo"/>
<filter>
<groovy>request.lineItems.any { i -> i.value > 100 }</groovy>
<to uri="queue:bar"/>
</filter>
</route>
The same issue goes for JavaScript. The only scripting that works is "Simple" - the internal Camel scripting language. Please give me advice how to fix this. I am using ActiveMQ 5.2.4 with the integrated Apache Camel 2.4.0.

Yeah you need to add the JARs from camel-script and the scripting language of choice, eg for groovy you need the groovy JAR. If you run AMQ you should drop them in the lib folder.

Do you have a dependency on camel-script fulfilled?
For instance in maven this would be declared as:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-script</artifactId>
<version>2.6.0</version>
</dependency>
In your <dependencies> declaration.

I added artifact camel-groovy because camel-script didn't work for me.
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-groovy</artifactId>
<version>2.23.0</version>
</dependency>

Running web app in both Jetty and Tomcat

I have a web app which in production I run on Tomcat. It uses the MySQL connector, however it is not bundled up with the war, rather it is included under Tomcat's common lib directory, so that I can access the data source through JNDI.
I would like to do something similar with Jetty (while developing), and more precisely Jetty + Maven. Is there a way for me to include the mysql-connector jar in the classpath when running Jetty through Maven (i.e. not have it bundled in the war file)?
Also I should note that I am using Maven for my build process and have the mysql-connector specified as "provided" scope.

Additinally to previous answer:
you have to add to your jetty plugin in maven config dependency:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.version}</version>
<configuration>
<stopKey>blah-blah-blah</stopKey>
<stopPort>9966</stopPort>
<webAppConfig>
<contextPath>/</contextPath>
</webAppConfig>
<jettyEnvXml>${basedir}/src/jetty-env.xml</jettyEnvXml>
</configuration>
<dependencies>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4-701.jdbc4</version>
</dependency>
</dependencies>
</plugin>
And then you can use provided scope at main project dependencies. I did it right now, and it works. Thank you for your question (and Nishant too)

Does not directly answer your question but since I love portability in webapps my war will contain the connector jar and a connection pool (e.g the super duper c3p0). That means that the container will not manage the database connection for me anymore nor will I use JNDI to describe the connection properties. But the webapp is now 100% portable and predictable on tomcat, jetty, resin, jboss etc.

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<New class="org.mortbay.jetty.plus.naming.Resource">
<Arg>hd-props</Arg>
<Arg>
<New class="java.util.Properties">
<Call name="load">
<Arg>
<New class="java.io.FileReader">
<Arg>cfg/dev-local.properties</Arg>
</New>
</Arg>
</Call>
</New>
</Arg>
</New>
It is a jetty-env.xml, which points to .properties file, which contains all the connect params to DB.
<bean id="jndi" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/hd-props"/>
</bean>
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties" ref="jndi"/>
</bean>
It is a spring config (i'm using spring too)
And then, I call mvn jetty:run, and it works fine...

Perhaps you could try using Maven .war overlays for this purpose, though I don't know if they work with other dependencies.
So basically your project would be
parent
|---- original-war
|---- new-war
Where your original-war project has the mysql dependency as <scope>provided</scope> but the the new-war module is just a pom that has a <packaging>war</packaging>, depends on the original war (for the overlay) has the mysql dependency with the compile scope, and runs the jetty plugin (leave the jetty plugin out of the original-war module). If this works, then you'll have to deal with the minor inconvenience of doing your development in one module but whatever testing you are doing in maven within another module.