> On Nov 26, 2014, at 12:54 PM, David M. Lloyd <david.lloyd(a)redhat.com&gt; 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: Could you give an overview of how applications that are using only standard APIs would be affected?

As an example, the scope stuff was all config driven, so I imagine that for most users this will just be property changes, and there existing code will most likely work as is.

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(a)redhat.com <mailto:david.lloyd@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/__mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>

Hi David, I'm looking more from the functional side not from the implementation. So in general simplifying the code will make it better to understand. From my perspective we need to cover the requirements from our users and make it easy to handle. I don't care whether we have different possibilities to configure the client. But the most important is to create a InitialContext programatic with properties and use it for all server actions. This should be done with a minimum of properties, i.e. default SSL=off as there is a need to configure it correct at server side. So I would assume that we deprecate the scoped-context and remote-naming complete and use the new approach.

I'll create a client project to show typical use-cases with the new API and check whether we cover the current issues. For this I appreciate if you have some examples if the creation and handling for the client has changed.

BTW, is it possible to use the ejb-client 3.0 with current EAP/WildFly? Is there any restriction or dependency? At the moment I'm not able to compile the project (branch uri_invocation), there is a missing dependency. org.wildfly.common:wildfly-common:jar:1.0.0.Beta1-SNAPSHOT

please find my other comments inline.

On 26/11/14 19:54, David M. Lloyd 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 What does that mean? Is it possible to use an InitialContext without any jboss-ejb-client configuration to be able to invoke ejb's and lookup other JNDI stuff like JMS with one IC and no redundant server properties?

> • Elimination of all "nested" EJB client context functionality > • Integration with Elytron for client identity management Does that mean the credentials for the connection and ejb invocation are decoupled?

Is there a possibility to use the old style CallBackHandler and/or being able to change the user for an existing remoting connection?

Also whether the credentials are used to invoke ejb's in a server-to-server communication and the user will be the invocation use of the first EJB and not the connection user?

> • 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 Great!

> • 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 As Cluster/Deployment NodeSelector is being removed and replaced by discovery this sounds to me that there is no possibility to customize the load-balancing process This might affect some use-cases where such policy was implemented to control specific behaviour.

Does this mean also that the cluster configuration at client side is deprecated and not longer necessary?

Also the need to configure the cluster-name within the server configuration to distinguish between different clusters?

> • EJBClientContext > • No longer implements Closeable Does this mean there is no longer a need to close a context to avoid "too much channel" problems. I suppose the "scoped context" will be removed

> 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.

Is there a possibility to use the InitialContext and do a lookup("UserTransaction") to get a reference to UserTransaction without any knowledge of the server environment? This was used <AS7 and also from other vendor.

Also is the ejb and other invocations sticky during the Tx is active?