Posts Tagged ‘Tomcat’

Stacktrace

On deploying a WAR in Tomcat:
[java]org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (128938160) exceeds the configured maximum (52428800)[/java]

Quick fix

Edit the file $CATALINA_HOME/webapps/manager/WEB-INF/web.xml
Replace the block
[xml] <multipart-config>
<!– 50MB max –>
<max-file-size>52428800</max-file-size>
<max-request-size>52428800</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config> [/xml]

with:

[xml] <multipart-config>
<!– 200 MB max –>
<max-file-size>209715200</max-file-size>
<max-request-size>209715200</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
[/xml]

Lecturer

Alexis Hassler has devoted more than fifteen years to Java development. Operating independently, he engages in programming while also guiding enterprises through training and advisory roles to refine their Java-based workflows and deployment strategies. As co-leader of the Lyon Java User Group, he plays a pivotal part in orchestrating community gatherings, including the acclaimed annual Mix-IT conference held in Lyon.

Abstract

Alexis Hassler meticulously examines the enduring complexities surrounding Java’s classpath and classloading mechanisms, drawing a sharp contrast between conventional hierarchical approaches and the rise of sophisticated modular frameworks. By weaving historical insights with hands-on illustrations and deep integration of JBoss Modules, he unravels the intricacies of dependency clashes, application isolation techniques, and viable transition pathways. The exploration extends to profound consequences for application server environments, delivering practical remedies to alleviate classpath-induced frustrations while casting an anticipatory gaze toward the transformative potential of Jigsaw.

Tracing the Roots: Classloaders and the Enduring Classpath Conundrum

Hassler opens by invoking Mark Reinhold’s bold 2009 JavaOne proclamation that the classpath’s demise was imminent, a statement that fueled expectations of modular systems seamlessly resolving all dependency conflicts. Despite the passage of four years, the classpath remains a fixture within the JDK and application server landscapes, underscoring its stubborn resilience.

Within the JDK, classloaders operate through a delegation hierarchy: the Bootstrap classloader handles foundational rt.jar components, the Extension classloader manages optional javax packages, and the Application classloader oversees user-defined code. This parent-first delegation model effectively safeguards core class integrity yet frequently precipitates version mismatches when disparate libraries demand conflicting implementations.

Hassler vividly demonstrates notorious pitfalls, such as the perplexing ClassNotFoundException that arises despite a JAR’s presence in the classpath or the insidious NoDefClassError triggered by incompatible transitive dependencies. These issues originate from the classpath’s flat aggregation paradigm, which indiscriminately merges all artifacts without regard for scoping or versioning nuances.

Hierarchical Containment Strategies in Application Servers: The Tomcat Paradigm

Application servers like Tomcat invert the delegation flow to enforce robust isolation among deployed artifacts. The WebappClassLoader prioritizes local resources before escalating unresolved requests to parent loaders, thereby permitting each web application to maintain its own dependency ecosystem.

This inverted hierarchy facilitates per-application versioning, substantially mitigating library collisions. Hassler delineates Tomcat’s layered loader architecture, encompassing common, server, shared, and per-webapp classloaders, each serving distinct scoping responsibilities.

Nevertheless, memory leaks persist as a formidable challenge, particularly during hot redeployments when static fields retain references to obsolete classes, inflating PermGen space. Mitigation demands meticulous resource cleanup through context listeners and disciplined finalization practices.

Modular Paradigms on the Horizon: OSGi, Jigsaw, and the Pragmatism of JBoss Modules

OSGi introduces the concept of bundles equipped with explicit import and export declarations, complete with version range specifications. This dynamic loading and unloading capability proves ideal for plugin architectures, though it necessitates substantial refactoring of existing codebases.

Project Jigsaw, slated for Java 9, aspires to embed modularity natively through module declarations that articulate precise dependencies. Despite repeated delays, its eventual integration promises standardized resolution, yet its absence compels interim solutions.

JBoss Modules, already battle-tested within JBoss AS7, employs a dependency graph resolution mechanism. Modules are defined with dedicated resource paths and dependency linkages, enabling parallel coexistence of multiple library versions. Hassler elucidates a module descriptor:

<module xmlns="urn:jboss:module:1.1" name="com.example.app">
    <resources>
        <resource-root path="app.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="org.hibernate" slot="4.3"/>
    </dependencies>
</module>

This structure empowers fine-grained version isolation, exemplified by simultaneous deployment of Hibernate 3 and 4 instances.

Hands-On Deployment Scenarios: JBoss Modules in Standalone and Tomcat Environments

Within JBoss AS7, modules reside in a dedicated directory structure, and applications declare dependencies via jboss-deployment-structure.xml manifests. Standalone execution leverages module-aware classloaders, either through MANIFEST entries or programmatic instantiation.

Hassler showcases a proof-of-concept integration with Tomcat, wherein a custom ClassLoader delegates to JBoss Modules, thereby endowing legacy web containers with modern dependency management. The prototype, available on GitHub, acknowledges limitations in hot-redeployment memory cleanup but validates conceptual soundness.

This adaptability extends modular benefits to environments traditionally tethered to classpath constraints.

Forward-Looking Consequences for Java Ecosystems: Transition Pathways and Jigsaw’s Promise

Classpath tribulations exact a heavy toll on developer productivity, manifesting in protracted debugging sessions and fragile builds. Modular frameworks counter these by enhancing maintainability, accelerating startup through lazy initialization, and fortifying deployment reliability.

Migration hurdles encompass tooling maturity and knowledge gaps, yet the advantages—conflict elimination, streamlined packaging—outweigh transitional friction. Hassler advocates incremental adoption, leveraging JBoss Modules as a bridge to Jigsaw’s eventual standardization.

In conclusion, while the classpath lingers, modular evolution heralds its obsolescence, equipping practitioners with robust tools to transcend historical limitations.

Links:

• Video of the lecture

David Blevins, a veteran in open-source Java EE and founder of projects like OpenEJB and TomEE, showcased Apache TomEE. With over a decade in specifications like EJB and CDI, David positioned TomEE as a bridge for Tomcat users seeking Java EE capabilities.

He polled the audience, revealing widespread Tomcat use alongside other servers, highlighting the migration pain TomEE addresses. David described TomEE as Tomcat enhanced with Java EE, unzipping Tomcat, adding Apache projects like OpenJPA and CXF, then certifying the bundle.

Emphasizing small size, certification, and Tomcat fidelity, David outlined distributions: Web Profile (minimal specs), JAX-RS (adding REST), and Plus (including JMS, JAX-WS).

Understanding the Web Profile

David clarified the Java EE 6 Web Profile, a subset of 12 specs from the full 24, excluding outdated ones like CORBA and CMP. This acknowledges Java EE’s growth, focusing on essentials for modern apps.

He noted exclusions like JAX-RS (added in EE 7) and inclusions like JavaMail in TomEE’s Web Profile for practicality. David projected EE 7’s profile reductions, potentially enabling full-profile TomEE certification.

Demonstrating TomEE in Action

In a live demo, David set up TomEE in Eclipse using Tomcat adapters, creating a servlet with EJB injection and JPA. He deployed seamlessly, showcasing CDI, transactions, and web services, all within Tomcat’s familiar environment.

David highlighted TomEE’s lightweight footprint—under 30MB—booting quickly with low memory. He integrated tools like Arquillian for testing, demonstrating in-container and embedded modes.

Advanced Features and Configuration

David explored clustering with Hazelcast, enabling session replication without code changes. He discussed production readiness, citing users like OpenShift and Jelastic.

Configuration innovations include flat XML-properties hybrids, human-readable times (e.g., “2 minutes”), and dynamic resource creation. David showed overriding via command-line or properties, extending for custom objects injectable via @Resource.

Error handling stands out: TomEE collects all deployment issues before failing, providing detailed, multi-level feedback to accelerate fixes.

Community and Future Directions

Celebrating TomEE’s first year, David shared growth metrics—surging commits and mailing lists—inviting contributions. He mentioned production adopters praising its simplicity and performance.

David announced a logo contest, encouraging participation. In Q&A, he affirmed production use, low memory needs, and solid components like OpenJPA.

Overall, David’s talk positioned TomEE as an empowering evolution for Tomcat loyalists, blending familiarity with Java EE power.

Links:

• David Blevins on LinkedIn
• David Blevins on Twitter/X
• Tomitribe website
• Apache TomEE website

Case

You have a WAR to deploy on Tomcat, let’s say jonathan.war for instance. Usually, the application will be reached through the URL http://machine:port/jonathan.
Let’s say you would like to exclude the WAR name from the address, ie the application to be reached on http://machine:port/. This operation is called “to deploy in root”, since the context will be simple slash: '/'.

Solution

You can implement that with two means:

• rename the war as ROOT.war, then deploy.
• or: edit conf/server.xml, replace [xml]<context>[/xml] with
  [xml]<context path="" docBase="jonathan" debug="0" reloadable="true"> [/xml]

Case

I had the following issue: when I undeployed the WAR from Tomcat using the manager instance, the undeploy failed. As a workaround, I had to restart Tomcat for the undeploy to be taken in account.
This issue occured only in Windows ; when the exact same WAR and the same version of Tomcar on Debian, I was able to deploy and undeploy many times.

Quick Fix

In the %CATALINA_HOME%\conf\context.xml, replace:
[xml]<Context>[/xml]
with:
[xml]<Context antijarlocking="true" antiResourceLocking="true"/>[/xml]

Install and Config

• Let’s assume you would like to run OpenJMS and Tomcat on the same server, eg myLocalServer
• Download OpenJMS from this page.
• Unzip the archive, extract it to C:\exe\openjms-0.7.7-beta-1
• Set an environment variable:set OPENJMS_HOME=C:\exe\openjms-0.7.7-beta-1
• Take the archive $OPENJMS_HOME/lib/openjms-tunnel-0.7.7-beta-1.war
  • copy it to: $CATALINA_HOME/webapps
  • rename it as: openjms-tunnel.war
• Edit OPENJMS_HOME/config/openjms.xml:
  • Before the ending tag</connectors>, add the block:

    <Connector scheme="http">
          <ConnectionFactories>
            <ConnectionFactory name="HTTPConnectionFactory"/>
          </ConnectionFactories>
     </Connector>

  • After the ending tag </connectors>, add the block:

    <HttpConfiguration port="3030" bindAll="true"
           webServerHost="myLocalServer" webServerPort="8080"
           servlet="/openjms-tunnel/tunnel"/>

Run applications

• Launch $OPENJMS_HOME/bin/startup.bat. The following output is expected:

  OpenJMS 0.7.7-beta-1
  The OpenJMS Group. (C) 1999-2007. All rights reserved.
  http://openjms.sourceforge.net
  15:15:27.531 INFO  [Main Thread] - Server accepting connections on tcp://myLocalServer:3035/
  15:15:27.547 INFO  [Main Thread] - JNDI service accepting connections on tcp://myLocalServer:3035/
  15:15:27.547 INFO  [Main Thread] - Admin service accepting connections on tcp://myLocalServer:3035/
  15:15:27.609 INFO  [Main Thread] - Server accepting connections on rmi://myLocalServer:1099/
  15:15:27.609 INFO  [Main Thread] - JNDI service accepting connections on rmi://myLocalServer:1099/
  15:15:27.625 INFO  [Main Thread] - Admin service accepting connections on rmi://myLocalServer:1099/
  15:15:27.625 INFO  [Main Thread] - Server accepting connections on http-server://myLocalServer:3030/
  15:15:27.625 INFO  [Main Thread] - JNDI service accepting connections on http-server://myLocalServer:3030/
  15:15:27.625 INFO  [Main Thread] - Admin service accepting connections on http-server://myLocalServer:3030/

• Launch Tomcat. A webapp with path /openjms-tunnel and display name “OpenJMS HTTP tunnel” should appear.

Checks

• • Open Console² or an MS-DOS prompt
  • Go to $OPENJMS/examples/basic

  • Run: build. This will compile all the examples.

Check that OpenJMS is OK:

• • Edit jndi.properties,
    • Comment the property
      java.naming.provider.url

    • Add the line:

      java.naming.provider.url=tcp://myLocalServer:3035

  • Run:
    run Listener queue1

  • Open a second tab
  • Run:
    run Sender queue1 5

    • Expected output in the second tab:

      C:\exe\openjms-0.7.7-beta-1\examples\basic>run Sender queue1 5
      Using OPENJMS_HOME: ..\..
      Using JAVA_HOME:    C:\exe\beaweblo922\jdk150_10
      Using CLASSPATH:    .\;..\..\lib\openjms-0.7.7-beta-1.jar
      Sent: Message 1
      Sent: Message 2
      Sent: Message 3
      Sent: Message 4
      Sent: Message 5

    • Expected output in the first tab:

      C:\exe\openjms-0.7.7-beta-1\examples\basic>run Listener queue1
      Using OPENJMS_HOME: C:\exe\openjms-0.7.7-beta-1
      Using JAVA_HOME:    C:\exe\beaweblo922\jdk150_10
      Using CLASSPATH:    .\;C:\exe\openjms-0.7.7-beta-1\lib\openjms-0.7.7-beta-1.jar
      Waiting for messages...
      Press [return] to quit
      Received: Message 1
      Received: Message 2
      Received: Message 3
      Received: Message 4
      Received: Message 5

Check that OpenJMS/Tomcat link is OK:

Manual Check

• • Stop the Listener instance launched sooner
  • Edit jndi.properties,
    • Comment the line
      java.naming.provider.url=tcp://myLocalServer:3035

    • Add the line:

      java.naming.provider.url=http://myLocalServer:8080

      (this is Tomcat manager URL)

  • Run: run Listener queue1

  • Open a second tab
  • Run:
    run Sender queue1 5

  • The expected output are the same as above.

GUI Check

• Stop the Listener instance launched sooner
• Ensure jndi.properties contains the line:

  java.naming.provider.url=http://myLocalServer:8080

• Run: $OPENJMS_HOME/bin/admin.bat

  • A Swing application should start.
  • Go to:
    Actions > Connections > Online

  • The queue queue1 should be followed by a ‘0’.
  • Run: run Sender queue1 50

    • Action > Refresh

    • The queue queue1 should be followed by a ’50’.
  • Run: run Listener queue1

    • Action > Refresh

    • The queue queue1 should be followed by a ‘0’.

Abstract

You would like to work on the client side of your GWT application, without building and deploying the Jetty server. Or, in the same way, you need test some server features available in WebLogic but not in Jetty, such as the EJB.
GWT 2.0 documentation, at the segment How do I use my own server in hosted mode instead of GWT’s built-in Jetty instance? is not precise at all on the 3rd step: it simply states:

“change the URL at the end of the argument list to match the URL you recorded in step #1.”

Process

• Let’s assume your WAR is deployed on http://distantMachine:8080/myApplication. The servlet container may be Tomcat or WebLogic, it does not matter
• In Eclipse, go in “Run Configuration...“. Duplicate your current and classic GWT application configuration.
• Go in Server , uncheck “Run built-in server“.
• In Arguments tab, write the following line:
  [java]-noserver -remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -logLevel INFO -war C:\eclipse\workspace\myApplication\src\main\webapp\lalou.jonathan.web.gwt.MyApplication -startupUrl http://distantMachine:8080/myApplication lalou.jonathan.web.gwt.MyApplication[/java]
• Run
• The application is available at the following address:
  [html]http://distantMachine:8080/muyApplication/?gwt.codesvr=127.0.0.1:9997[/html]

Case

This morning, I tried to redeploy an EAR on a WebLogic 9.2, using Maven 2 and a classical deployment profile. I got this issue:
[java][ERROR] BUILD ERROR
[INFO] ————————————————————————
[INFO] Error executing ant tasks

Embedded error: The following error occurred while executing this line:
(…)
weblogic.deploy.api.internal.utils.DeployerHelperException: The source ‘C:\DOCUME~1\myLogin\LOCALS~1\Temp\myApplication-ear.ear’ for the application ‘my-application-ear’ could not be loaded to the server ‘http://myServer:1234/bea_wls_deployment_internal/DeploymentService’.
Response: ‘403: Forbidden’ for url: ‘http://myServer:1234/bea_wls_deployment_internal/DeploymentService'[/java]

Yesterday, I got a similar error when I launched a mvn tomcat:deploy to deploy a WAR on a Tomcat 6.0 server:
[java][ERROR] BUILD ERROR
[INFO] ————————————————————————
[INFO] Cannot invoke Tomcat manager

Embedded error: Server returned HTTP response code: 403 for URL: http://myServer:3210/manager/deploy?path=%2FmyWebArchive&war=&update=true[/java]

Quick Fix

Running Maven2 in offline line, ie adding the option "-o", allows me to redeploy both the EAR on WebLogic and the WAR on Tomcat.
eg: mvn tomcat:deploy -o
I keep on investigating on this matter. I think there is an issue on the DNS. Indeed, when I deploy locally to my own machine myServer (ie with its network name), this error is raised, but when I deploy to localhost the build is successful.

Abstract

Let’s assume you have followed the article “Basic RPC call with GWT“. Now you would like to call an actual EJB 2 as remote, via a Spring lookup.
Let’s say: you have an EJB MyEntrepriseComponentEJB, which implements an interface MyEntrepriseComponent. This EJB, generates a remote MyEntrepriseComponentRemote.

Entry Point

In myApplication.gwt.xml entry point file, after the line:

[xml]<inherits name=’com.google.gwt.user.User’/>[/xml]

add the block:

[xml]
<inherits name=’com.google.gwt.user.User’ />
<inherits name="com.google.gwt.i18n.I18N" />
<inherits name="com.google.gwt.http.HTTP" />[/xml]

Add the line:

[xml]<servlet path=’/fooService.do’/>[/xml]

Client

Under the *.gwt.client folder:

Update the service interface. Only the annotation parameter is amended:

[java]@RemoteServiceRelativePath("services/fooService")
public interface FooService extends RemoteService {
public String getHelloFoo(String fooName);
}[/java]

You have nothing to modify in asynchronous call interface (FooServiceAsync).

Server

Under the *.gwt.server folder, update the implementation for service interface:

Change the super-class, replacing RemoteServiceServlet with GWTSpringController:

[java]public class FooServiceImpl extends GWTSpringController implements FooService {
public FooServiceImpl() {
// init
}
}
[/java]

Add new field and its getter/setter:

[java]// retrieved via Spring
private myEntrepriseComponent myEntrepriseComponent;

public myEntrepriseComponent getMyEntrepriseComponent() {
return myEntrepriseComponent;
}

public void setmyEntrepriseComponent(myEntrepriseComponent _myEntrepriseComponent) {
myEntrepriseComponent = _myEntrepriseComponent;
}[/java]

Write the actual call to EJB service:

[java]
public String getHelloFoo(String fooName) {
return myEntrepriseComponent.getMyDataFromDB();
}
}[/java]

web.xml

Fill the web.xml file:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

<!– Spring –>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
<servlet-name>gwt-controller</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>gwt-controller</servlet-name>
<url-pattern>/myApplication/services/*</url-pattern>
</servlet-mapping>

<!– Default page to serve –>
<welcome-file-list>
<welcome-file>MyApplicationGwt.html</welcome-file>
</welcome-file-list>

</web-app>
[/xml]

JNDI

Add a jndi.properties file in src/resources folder:

[java]
java.naming.provider.url=t3://localhost:12345
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=yourLogin
java.naming.security.credentials=yourPassword
weblogic.jndi.enableDefaultUser=true[/java]

These properties will be used by Spring to lookup the remote EJB. The last option is very important, otherwise you may happen to face issues with EJB if they were deployed under WebLogic.

WEB-INF

In the WEB-INF folder, add an applicationContext.xml file:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<beans>

<util:properties id="jndiProperties" location="classpath:jndi.properties" />

<jee:remote-slsb id="myEntrepriseComponentService"
jndi-name="ejb.jonathan.my-entreprise-component"
business-interface="lalou.jonathan.myApplication.services.myEntrepriseComponent"
environment-ref="jndiProperties" cache-home="false"
lookup-home-on-startup="false" refresh-home-on-connect-failure="true" />

</beans>[/xml]

Add a gwt-controller-servlet.xml file:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd">

<bean>
<property name="order" value="0" />
<property name="mappings">
<value>
/fooService=fooServiceImpl
</value>
</property>
</bean>

<bean id="fooServiceImpl"
class="lalou.jonathan.myApplication.web.gwt.server.FooServiceImpl">
<property name="myEntrepriseComponent" ref="myEntrepriseComponentService" />
</bean>
</beans>
[/xml]

Of course, if your servlet mapping name in web.xml is comoEstasAmigo, then rename gwt-controller-servlet.xml as comoEstasAmigo-servlet.xml 😉

Build and deploy

Now you can compile, package your war and deploy under Tomcat or WebLogic. WebLogic server may raise an error:
java.rmi.AccessException: [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB
This error is related to the rights required to call a method on the EJB. Indeed, two levels of rights are used by WebLogic: firstly to lookup / instanciate the EJB (cf. the property java.naming.security.principal we set sooner), and another to call the method itself. In this second case, WebLogic requires an authentication (think of what you do when you login an web application deployed: your login and rights are kept for all the session) to grant the rights. I wish to handle this subject in a future post.

NB: thanks to David Chau and Didier Girard from SFEIR, Sachin from Mumbai team and PYC from NYC.

Let’s assume you have a “Hello World” GWT application. You need emulate a basic RPC call (RMI, EJB, etc.). Here is the program:

Under the *.gwt.client folder:

Create an service interface:

[java]@RemoteServiceRelativePath("fooService")
public interface FooService extends RemoteService {
public String getHelloFoo(String totoName);
}[/java]

Create another interface for asynchronous call. You can notice the method name differs lightly from the one in the other interface:

[java]public interface FooServiceAsync {
void getHelloFoo(String fooName, AsyncCallback<String> callback);
}[/java]

Under the *.gwt.server folder, create an implementation for service interface:

[java]public class FooServiceImpl extends RemoteServiceServlet implements FooService {
public FooServiceImpl() {
// TODO init
}

public String getHelloFoo(String fooName) {
// TODO call actual service
return "hello world!";
}
}[/java]

In the web.xml file, add the following blocks:

[xml] <!– Servlets –>
<servlet>
<servlet-name>fooService</servlet-name>
<servlet-class>com…….server.FooServiceImpl</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>fooService</servlet-name>
<url-pattern>/ivargwt/fooService</url-pattern>
</servlet-mapping>
[/xml]

The tags content match the argument given as parameter to RemoteServiceRelativePath annotation above.

From then, in your concrete code, you can instantiate the service and call remote method:

[java]FooServiceAsync fooService = GWT.create(FooService.class);
fooService.getHelloFoo("how are you?", new AsyncCallback<String>() {

public void onSuccess(String result) {
MessageBox.alert("OK", result, null);
}

public void onFailure(Throwable caught) {
MessageBox.alert("ERROR", "rpc call error-" + caught.getLocalizedMessage(), null);
}
});
[/java]

Now you can compile, package your war and deploy under Tomcat or WebLogic.

NB: special to “black-belt GWT guy” David Chau from SFEIR.