[wildfly-dev] IMPORTANT: First overview of changes to jboss-ejb-client 3.0 for WildFly 10 (probably)
David M. Lloyd
david.lloyd at redhat.com
Wed Nov 26 17:05:24 EST 2014
No, nothing assembled in one place other than a couple etherpads and
(IIRC) previous emails to this list and the discussion from last year's
meeting in Brno.
The core design elements basically change like this:
• Add URIAffinity, including ensuring that affinity is part of
equals/hashCode for all locators
• Existing node/cluster affinity becomes equivalent to the URI schemes
"node:xxx" and "cluster:xxx" (presently I am retaining the classes
though, and creating a URI affinity with one of these schemes
automatically creates Node/ClusterAffinity instances for maximum
compatibility)
• Extract transactions out of EJB and into a separate mechanism (either
part of Remoting or a separate client lib); EJB invocations still carry
transaction associations though
• Remote protocol implements "remote" schemas
• Add discovery for resolving Affinity.NONE EJBs and
"node:xxx"/"cluster:xxx" into "remote:" schemas (first impl will simply
be config-driven static "discovery", which should allow most existing
code to run unchanged)
• Compatibility protocol ties into discovery mechanism for equivalent
functionality to previous versions
• Generally eliminate or modify all SPI code that makes special
assumptions about location outside of URIs
• A "local:"/Affinity.LOCAL is added so that discovery can be used to
map "self" URLs ("remote:" URLs that refer to the calling container)
back to the local container, if a matching EJBReceiver is installed
Otherwise things are largely the same. The configuration stuff ties in,
but it's not centrally important to the design. We'd rely on Remoting
to maintain connections, which would be established by URI and shared
among services like we discussed. Elytron does all the authentication
(including association of identity for each invocation); EJB no longer
needs to be aware of that. The interceptor structure is basically
unchanged.
I think that's it. It's pretty simple at its core - it's basically 90%
just code simplification - though I feel like I haven't explained it
very well at all. :)
On 11/26/2014 03:24 PM, Stuart Douglas wrote:
> Is there any documentation somewhere about the new design (I am talking
> about a broad overview rather than changes to specific classes)?
>
> Stuart
>
> On Thu Nov 27 2014 at 5:55:16 AM David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
> I don't want to commit this to a specific WildFly release but I guess
> and hope it'll come in around WildFly 10 or so (definitely not 9).
>
> As previously discussed, the EJB client architecture is undergoing the
> following substantial changes:
>
> • Introduction of URIAffinity, and URI-based invocation
> • Expansion of the 'ejb' JNDI initial context to auto-associate the
> PROVIDER_URL as the URI affinity for looked-up proxies
> • Elimination of all "nested" EJB client context functionality
> • Integration with Elytron for client identity management
> • Deferral to Remoting for automatic connection management
> • Unification of client configuration, so the Elytron authentication
> client, Remoting connection management, remote transaction client, and
> EJB client configurations all can be configured in one file or
> deployment descriptor
>
> As such, I've introduced a 2.x branch for upstream where continued
> development of the 2.x series will take place. The "master" branch is
> being re-purposed towards this new development, targeted for 3.x of this
> library.
>
> There are a number of compatibility considerations from 2.x to 3.x.
> Most (I hope) existing client code (which avoids specialized manual
> configuration or nested client contexts) should continue to function
> as-is, with the following exceptions:
>
> • The following classes and interfaces are currently removed in my
> working copy:
> • ClusterContext - replaced with discovery (?)
> • ClusterNodeManager - replaced with discovery
>
> • ClusterNodeSelector - replaced with discovery
> • DeploymentNodeSelector - replaced with discovery
>
> • ContextSelector - replaced with general selector class
> • ConstantContextSelector
> • IdentityEJBClientContextSelect__or
> • ThreadLocalContextSelector
>
> • EJBClientContextInitializer - no replacement
> • DefaultInterceptorsClientConte__xtInitializer
> • TransactionRecoveryContextInit__ializer
>
> • EJBClientContextIdentifier - no replacement
> • NamedEJBClientContextIdentifie__r
>
> • DefaultCallbackHandler - no replacement
>
> • EJBClientConfiguration - replaced with context builder
> • PropertiesBasedEJBClientConfig__uration
>
> • EJBClientContextListener - no replacement
> • EJBClientInterceptor.__Registration - no replacement (interceptor
> set cannot be changed)
> • EJBClient*TransactionContext - replaced by
> wildfly-transaction-client facility
> • EJBReceiverContext - no replacement
> • ReceiverInterceptor - no replacement (internal class)
>
> • ALL public classes in the org.jboss.ejb.client.remoting package
> including ReconnectHandler
>
> • The following changes will be made to these core classes and
> interfaces:
> • EJBClient
> • Added more createSession() variants to support new
> affinity types
> • Change createSession() methods to throw CreateException
> instead
> of Exception
> • Remove createProxy() and createSession() variants which accept
> EJBClientContextIdentifier
> • Remove getEJBClientContextIdentifierF__or() method
> • Attachable
> • Remove getAttachments() method
> • EJBClientContext
> • No longer implements Closeable
> • Remove close() method
> • Remove all static create() methods, replaced with Builder
> class
> • Remove finalize() method
> • Remove getClusterContext(), getEJBClientConfiguration(),
> getOrCreateClusterContext(), removeCluster()
> • Remove selector-related methods, replaced with general
> Selector
> class
> • Remove register*() and unregister*() methods (providers are
> added to Builder)
> • Remove require() method which accepts
> EJBClientContextIdentifier
> • Add getInvocationTimeout() method
> • Affinity
> • Add forUri() factory method
> • EJBClientInvocationContext
> • Add getCompressionLevel(), isClientAsync(), and isIdempotent()
> query methods
> • Remove finalize()
> • EJB*Locator classes
> • Additional constructors which also accept an affinity
> • Additional "copy" constructors which accept a locator and
> affinity, to change the target affinity
> • EJBReceiver class
> • openSession() method changed to accept a stateless EJB locator
> • Constructor changed to no args
> • Remove all send*() and other methods related to transactions
> • Remove associate(), getNodeName(), [de]registerModule(),
> exists()
> • EJBReceiverInvocationContext
> • Remove retryInvocation() method
> • Remove getEjbReceiverContext() method
> • Remove getNodeName() method
> • EJBMetaDataImpl
> • Deprecated, changed to not use raw types
> • RequestSendFailedException
> • Replaced constructor with standard exception
> four-constructor setup
> • The following API classes are added:
> • EJBClientPermission - a general permission class
> • AbstractEJBMetaData - type-safe hierarchical version of
> EJBMetaDataImpl
> • EJBClientContext.Builder - forwards-compatible builder for
> EJBClientContext
> • EJBDiscoveryProvider - an interface to provide pluggable
> discovery
> • EJBTransportProvider - an interface to provide URI-compatible
> transport (factory for EJBReceivers)
> • URIAffinity - a type of affinity which has a URI for a target
>
> Note in particular that most of the cluster-support infrastructure is
> presently removed with no replacement. It is my hope and intent that
> the discovery infrastructure will be able to take over this function.
> How much of the code will be new, compared to how much of the code can
> be forward-ported and reintroduced from 2.x, remains to be discussed.
>
> At present, the plan is for wire compatibility to be supported for 2.x
> clients talking to 3.x servers and vice-versa.
>
> Transaction handling will be relegated to a separate
> wildfly-transaction-client API. However the getUserTransaction(node)
> method will continue to be supported as a deprecated delegation to the
> transaction-client API. In addition, when talking to a 2.x server, it
> is expected that a wildfly-transaction-client SPI implementation will
> piggyback on the existing EJB protocol transaction messages.
>
> If any of these API changes seems unacceptable, now is the time to
> discuss it. All the code that was removed was determined to be tied too
> tightly to the previous location or configuration strategy, and thus
> couldn't sensibly be supported going forward. I have hopefully been
> adequately upfront about what I intended to remove or support going
> forward. In addition, by supporting the 2.x client, most migration
> concerns can hopefully be mitigated. But it's possible that some
> classes or methods could indeed be reintroduced with sensible semantics
> and in such a way as to not cause problems; if you have any thoughts
> along these lines, please share them and we can discuss them on a
> case-by-case basis.
>
> I've pushed up the proposed baseline 3.0 API at
> https://github.com/dmlloyd/__jboss-ejb-client/tree/uri___invocation
> <https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation> for
> review. I intend for pull requests that are relevant to both old and
> new code bases to be applied to both if possible, to avoid increasing
> the incompatibility window even further.
>
> --
> - DML
> _________________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/__mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
--
- DML
More information about the wildfly-dev
mailing list