A portable enterprise application combines standard APIs with a deployment environment that supplies the resources it expects. Novell exteNd’s Java Verified announcement is a useful starting point for understanding that contract. To assess a move, identify the exact platform versions, external dependencies and business behavior you must preserve.
What the 2003 verification claim concerned
Novell’s May 15, 2003 announcement, preserved in its Chinese-language archive describes Java Verified status for exteNd following Sun’s Java Application Verification Kit (AVK) testing. The integration and portal products were exteNd Composer and exteNd Director. This was a claim about those products in the contemporary J2EE ecosystem.
Sun’s Application Server 8 migration guide (PDF, page 61) presents AVK as a way to build and test portable J2EE applications. Such verification addresses a defined platform contract. A deployment still needs its database, naming resources, security configuration and external services.
Today, the Jakarta EE compatible-products directory organizes platform implementations by specification version and profile. Use it to check the destination server’s documented compatibility, then separately verify your application. Historical application verification and current platform certification answer different questions.
Map the dependencies before moving the archive
On narrow screens, scroll the table horizontally. Keyboard users can focus it and use the arrow keys.
| Dependency | Record on both sides | A useful check |
|---|---|---|
| Java and platform version | JDK, J2EE/Java EE/Jakarta EE version, profile and supported combinations | Compile and deploy with the documented API level. |
| Application APIs | Standard packages, vendor extensions and bundled libraries | Identify imports and descriptors that require changes. |
| Database and transactions | Driver, SQL dialect, schema and transaction boundary | Test commit and deliberate rollback against a test database. |
| Naming and configuration | JNDI names, connection pools, paths and environment values | Resolve each required resource in the destination. |
| Identity and authorization | Authentication integration and role mappings | Run allowed and denied actions with separate test users. |
| External services | Endpoints, timeouts, credentials and retry policy | Exercise success, failure and recovery without duplicate work. |
Keep credentials outside the matrix; record their approved configuration locations. Give every row an owner, evidence link and pass/fail/unknown status. Unknown is useful information: it identifies the next experiment instead of hiding an assumption.
For later migrations across the Java EE/Jakarta EE namespace boundary, inspect the APIs the application actually uses. The JSP and servlet migration guide provides a bounded example. A package rename is one part of a migration, and its scope depends on the specification version.
Work a deployment failure into an actionable change
Fictional example: the application starts but cannot read orders
A team moves a small orders application from Server A to Server B. The archive deploys successfully. A request for the orders page fails because the application looks up jdbc/Orders, while the destination administrator created only jdbc/OrderDB.
First compare the application’s expected resource name with the server binding. Configure the appropriate mapping using Server B’s documentation, restart or redeploy as required, and repeat the read. Then exercise a committed update and a forced rollback. Resolving a name establishes resource access; transaction checks establish that a larger part of the contract still holds.
Record this as a deployment configuration difference, with the expected name and mapping location. Editing business code merely to conceal a configuration mismatch would make the next move harder.
Use a small acceptance sequence with observable results
- Freeze the inputs: application build identifier, dependency list, schema revision and environment configuration. Use representative test data, not a copied production database.
- Verify startup and resource resolution. Save the relevant deployment output and confirm that the application is responding through its intended route.
- Run a read and a state-changing operation. Check both the response and stored state; force a failure to check rollback.
- Test allowed and denied users. Verify the application role mapping and response without relying only on a successful login.
- Simulate one external dependency failure. Confirm the timeout, user-visible outcome and absence of duplicate state changes on retry.
- Compare results with the original environment. Investigate differences and define a rollback route before a production change.
These checks form an initial acceptance suite. Add workload, clustering, messaging, scheduling and recovery tests when the application uses those features. A passing smoke test supports the behaviors it exercised, while performance and failover need their own evidence.
Download the portability matrix and acceptance record. Use the JDBC transaction example to practice distinguishing successful reads, committed writes and rollbacks.