Remove outdated documentation references to WebLogic/WebSphere

See gh-22093
This commit is contained in:
Juergen Hoeller 2023-08-12 14:50:45 +02:00
parent d03af15516
commit 92410395e3
8 changed files with 35 additions and 79 deletions

View File

@ -828,13 +828,6 @@ The following table summarizes various `LoadTimeWeaver` implementations:
| Running in Red Hat's https://www.jboss.org/jbossas/[JBoss AS] or https://www.wildfly.org/[WildFly]
| `JBossLoadTimeWeaver`
| Running in IBM's https://www-01.ibm.com/software/webservers/appserv/was/[WebSphere]
| `WebSphereLoadTimeWeaver`
| Running in Oracle's
https://www.oracle.com/technetwork/middleware/weblogic/overview/index-085209.html[WebLogic]
| `WebLogicLoadTimeWeaver`
| JVM started with Spring `InstrumentationSavingAgent`
(`java -javaagent:path/to/spring-instrument.jar`)
| `InstrumentationLoadTimeWeaver`
@ -949,11 +942,11 @@ when you use Spring's LTW support in environments such as application servers an
containers.
[[aop-aj-ltw-environments-tomcat-jboss-etc]]
==== Tomcat, JBoss, WebSphere, WebLogic
==== Tomcat, JBoss, WildFly
Tomcat, JBoss/WildFly, IBM WebSphere Application Server and Oracle WebLogic Server all
provide a general app `ClassLoader` that is capable of local instrumentation. Spring's
native LTW may leverage those ClassLoader implementations to provide AspectJ weaving.
Tomcat and JBoss/WildFly provide a general app `ClassLoader` that is capable of local
instrumentation. Spring's native LTW may leverage those ClassLoader implementations
to provide AspectJ weaving.
You can simply enable load-time weaving, as xref:core/aop/using-aspectj.adoc[described earlier].
Specifically, you do not need to modify the JVM launch script to add
`-javaagent:path/to/spring-instrument.jar`.

View File

@ -13,39 +13,7 @@ javadoc for details.
Spring's `JtaTransactionManager` is the standard choice to run on Jakarta EE application
servers and is known to work on all common servers. Advanced functionality, such as
transaction suspension, works on many servers as well (including GlassFish, JBoss and
Geronimo) without any special configuration required. However, for fully supported
transaction suspension and further advanced integration, Spring includes special adapters
for WebLogic Server and WebSphere. These adapters are discussed in the following
sections.
For standard scenarios, including WebLogic Server and WebSphere, consider using the
convenient `<tx:jta-transaction-manager/>` configuration element. When configured,
this element automatically detects the underlying server and chooses the best
transaction manager available for the platform. This means that you need not explicitly
configure server-specific adapter classes (as discussed in the following sections).
Rather, they are chosen automatically, with the standard
`JtaTransactionManager` as the default fallback.
[[transaction-application-server-integration-websphere]]
== IBM WebSphere
On WebSphere 6.1.0.9 and above, the recommended Spring JTA transaction manager to use is
`WebSphereUowTransactionManager`. This special adapter uses IBM's `UOWManager` API,
which is available in WebSphere Application Server 6.1.0.9 and later. With this adapter,
Spring-driven transaction suspension (suspend and resume as initiated by
`PROPAGATION_REQUIRES_NEW`) is officially supported by IBM.
[[transaction-application-server-integration-weblogic]]
== Oracle WebLogic Server
On WebLogic Server 9.0 or above, you would typically use the
`WebLogicJtaTransactionManager` instead of the stock `JtaTransactionManager` class. This
special WebLogic-specific subclass of the normal `JtaTransactionManager` supports the
full power of Spring's transaction definitions in a WebLogic-managed transaction
environment, beyond standard JTA semantics. Features include transaction names,
per-transaction isolation levels, and proper resuming of transactions in all cases.
Geronimo) without any special configuration required.

View File

@ -453,10 +453,9 @@ on rollback rule semantics, patterns, and warnings regarding possible unintentio
matches for pattern-based rollback rules.
Currently, you cannot have explicit control over the name of a transaction, where 'name'
means the transaction name that appears in a transaction monitor, if applicable
(for example, WebLogic's transaction monitor), and in logging output. For declarative
transactions, the transaction name is always the fully-qualified class name + `.`
+ the method name of the transactionally advised class. For example, if the
means the transaction name that appears in a transaction monitor and in logging output.
For declarative transactions, the transaction name is always the fully-qualified class
name + `.` + the method name of the transactionally advised class. For example, if the
`handlePayment(..)` method of the `BusinessService` class started a transaction, the
name of the transaction would be: `com.example.BusinessService.handlePayment`.

View File

@ -56,14 +56,13 @@ locally, as the following example shows:
----
The specified `WorkManager` can also point to an environment-specific thread pool --
typically through a `SimpleTaskWorkManager` instance's `asyncTaskExecutor` property. Consider
defining a shared thread pool for all your `ResourceAdapter` instances if you happen to
use multiple adapters.
typically through a `SimpleTaskWorkManager` instance's `asyncTaskExecutor` property.
Consider defining a shared thread pool for all your `ResourceAdapter` instances
if you happen to use multiple adapters.
In some environments (such as WebLogic 9 or above), you can instead obtain the entire `ResourceAdapter` object
from JNDI (by using `<jee:jndi-lookup>`). The Spring-based message
listeners can then interact with the server-hosted `ResourceAdapter`, which also use the
server's built-in `WorkManager`.
In some environments, you can instead obtain the entire `ResourceAdapter` object from JNDI
(by using `<jee:jndi-lookup>`). The Spring-based message listeners can then interact with
the server-hosted `ResourceAdapter`, which also use the server's built-in `WorkManager`.
See the javadoc for {api-spring-framework}/jms/listener/endpoint/JmsMessageEndpointManager.html[`JmsMessageEndpointManager`],
{api-spring-framework}/jms/listener/endpoint/JmsActivationSpecConfig.html[`JmsActivationSpecConfig`],

View File

@ -1,5 +1,5 @@
/*
* Copyright 2002-2021 the original author or authors.
* Copyright 2002-2023 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@ -67,9 +67,9 @@ import org.springframework.util.Assert;
* </pre>
*
* <p>The target ResourceAdapter may be configured as a local Spring bean as well
* (the typical case) or obtained from JNDI (e.g. on WebLogic). For the
* example above, a local ResourceAdapter bean could be defined as follows
* (matching the "resourceAdapter" bean reference above):
* (the typical case) or obtained from JNDI. For the example above, a local
* ResourceAdapter bean could be defined as follows (matching the "resourceAdapter"
* bean reference above):
*
* <pre class="code">
* &lt;bean id="resourceAdapter" class="org.springframework.jca.support.ResourceAdapterFactoryBean"&gt;

View File

@ -1,5 +1,5 @@
/*
* Copyright 2002-2022 the original author or authors.
* Copyright 2002-2023 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@ -265,7 +265,7 @@ public interface TransactionDefinition {
/**
* Return the name of this transaction. Can be {@code null}.
* <p>This will be used as the transaction name to be shown in a
* transaction monitor, if applicable (for example, WebLogic's).
* transaction monitor, if applicable.
* <p>In case of Spring's declarative transactions, the exposed name will be
* the {@code fully-qualified class name + "." + method name} (by default).
* @return the name of this transaction ({@code null} by default}

View File

@ -1,5 +1,5 @@
/*
* Copyright 2002-2022 the original author or authors.
* Copyright 2002-2023 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@ -67,16 +67,15 @@ public class SpringJtaSynchronizationAdapter implements Synchronization {
/**
* Create a new SpringJtaSynchronizationAdapter for the given Spring
* TransactionSynchronization and JTA TransactionManager.
* <p>Note that this adapter will never perform a rollback-only call on WebLogic,
* since WebLogic Server is known to automatically mark the transaction as
* rollback-only in case of a {@code beforeCompletion} exception. Hence,
* on WLS, this constructor is equivalent to the single-arg constructor.
* @param springSynchronization the Spring TransactionSynchronization to delegate to
* @param jtaUserTransaction the JTA UserTransaction to use for rollback-only
* setting in case of an exception thrown in {@code beforeCompletion}
* (can be omitted if the JTA provider itself marks the transaction rollback-only
* in such a scenario, which is required by the JTA specification as of JTA 1.1).
* @deprecated as of 6.0.12 since JTA 1.1+ requires implicit rollback-only setting
* in case of an exception thrown in {@code beforeCompletion}, so the regular
* {@link #SpringJtaSynchronizationAdapter(TransactionSynchronization)} constructor
* is sufficient for all scenarios
*/
@Deprecated(since = "6.0.12")
public SpringJtaSynchronizationAdapter(TransactionSynchronization springSynchronization,
@Nullable UserTransaction jtaUserTransaction) {
@ -87,21 +86,21 @@ public class SpringJtaSynchronizationAdapter implements Synchronization {
/**
* Create a new SpringJtaSynchronizationAdapter for the given Spring
* TransactionSynchronization and JTA TransactionManager.
* <p>Note that this adapter will never perform a rollback-only call on WebLogic,
* since WebLogic Server is known to automatically mark the transaction as
* rollback-only in case of a {@code beforeCompletion} exception. Hence,
* on WLS, this constructor is equivalent to the single-arg constructor.
* @param springSynchronization the Spring TransactionSynchronization to delegate to
* @param jtaTransactionManager the JTA TransactionManager to use for rollback-only
* setting in case of an exception thrown in {@code beforeCompletion}
* (can be omitted if the JTA provider itself marks the transaction rollback-only
* in such a scenario, which is required by the JTA specification as of JTA 1.1)
* @deprecated as of 6.0.12 since JTA 1.1+ requires implicit rollback-only setting
* in case of an exception thrown in {@code beforeCompletion}, so the regular
* {@link #SpringJtaSynchronizationAdapter(TransactionSynchronization)} constructor
* is sufficient for all scenarios
*/
public SpringJtaSynchronizationAdapter(
TransactionSynchronization springSynchronization, @Nullable TransactionManager jtaTransactionManager) {
@Deprecated(since = "6.0.12")
public SpringJtaSynchronizationAdapter(TransactionSynchronization springSynchronization,
@Nullable TransactionManager jtaTransactionManager) {
this(springSynchronization);
this.jtaTransaction = new UserTransactionAdapter(jtaTransactionManager);
this.jtaTransaction =
(jtaTransactionManager != null ? new UserTransactionAdapter(jtaTransactionManager) : null);
}

View File

@ -156,8 +156,6 @@
<xsd:documentation><![CDATA[
Creates a default JtaTransactionManager bean with name "transactionManager",
matching the default bean name expected by the "annotation-driven" tag.
Automatically detects WebLogic and WebSphere: creating a WebLogicJtaTransactionManager
or WebSphereUowTransactionManager, respectively.
For customization needs, consider defining a JtaTransactionManager bean as a regular
Spring bean definition with name "transactionManager", replacing this element.