WildFly 35.0.0.Final (Domain Mode) – Issue deploying Cocoon 1.8.6 framework (Turbine/XSPProcessor classpath error)

36 views
Skip to first unread message

Ganesh pandiyaraj

unread,
Sep 19, 2025, 4:56:12 AM (10 days ago) Sep 19
to WildFly
Hello WildFly community,

I am trying to deploy an application built on the **Apache Cocoon 1.8.6** framework (legacy) on WildFly 35.0.0.Final in **domain mode**, but I am running into classpath issues.

**Environment:**
- WildFly: 35.0.0.Final (domain mode)
- JDK: Oracle JDK 17
- OS: RHEL 7.9
- Deployment: unmanaged (WAR file copied into domain/deployments)
- Framework: Apache Cocoon 1.8.6

**Problem:**
Deployment fails with the following error:

java.lang.RuntimeException: Error creating org.apache.cocoon.processor.xsp.XSPProcessor:
make sure the needed classes can be found in the classpath
(org/apache/turbine/services/resources/TurbineResourceService)


**What I tried so far:**
1. Added `turbine-pool.jar` and other Cocoon 1.8.6 libraries into `WEB-INF/lib`
2. Updated `jboss-deployment-structure.xml` to include dependencies
3. Restarted both servers using `jboss-cli.sh --connect` (domain reload)
4. Verified `$CLASSPATH` on the Linux host
5. Tested with Xerces/Xalan jars, but error persists

**My question:**
Since I am deploying **Cocoon 1.8.6** in **WildFly domain mode** with **Oracle JDK 17**, what is the recommended way to make these legacy libraries (Turbine, Xerces, Xalan, etc.) available to the application?
- Should I create a **WildFly module** for Cocoon and reference it in the domain profile?
- Or should everything stay in `WEB-INF/lib` with proper `jboss-deployment-structure.xml`?
- Are there known compatibility issues between Cocoon 1.x and modern WildFly (Jakarta EE on JDK 17)?

Any advice or examples from others who deployed Cocoon 1.x on WildFly would be very helpful.

Thank you!

Ganesh pandiyaraj

unread,
Sep 19, 2025, 4:56:12 AM (10 days ago) Sep 19
to WildFly
Hello WildFly community,

I am trying to deploy an application built on the **Apache Cocoon 1.8.6** framework (legacy) on WildFly 35.0.0.Final in **domain mode**, but I am running into classpath issues.

**Environment:**
- WildFly: 35.0.0.Final (domain mode)
- JDK:Oracle JDK 17
- OS: RHEL 7.9
- Deployment: unmanaged (WAR file copied into domain/deployments)
- Framework: Apache Cocoon 1.8.6

**Problem:**
Deployment fails with the following error:

java.lang.RuntimeException: Error creating org.apache.cocoon.processor.xsp.XSPProcessor:
make sure the needed classes can be found in the classpath
(org/apache/turbine/services/resources/TurbineResourceService)


**What I tried so far:**
1. Added `turbine-pool.jar` and other Cocoon 1.8.6 libraries into `WEB-INF/lib`
2. Updated `jboss-deployment-structure.xml` to include dependencies
3. Restarted both servers using `jboss-cli.sh --connect` (domain reload)
4. Verified `$CLASSPATH` on the Linux host
5. Tested with Xerces/Xalan jars, but error persists

**My question:**
Since I am deploying **Cocoon 1.8.6** in **WildFly domain mode**, what is the recommended way to make these legacy libraries (Turbine, Xerces, Xalan, etc.) available to the application?

- Should I create a **WildFly module** for Cocoon and reference it in the domain profile?
- Or should everything stay in `WEB-INF/lib` with proper `jboss-deployment-structure.xml`?
- Are there any known compatibility issues between Cocoon 1.x and modern WildFly (Java EE / Jakarta EE)?
Reply all
Reply to author
Forward
0 new messages