[EJB 3.0 Development] Document updated/added: "Requirements: Remote Invocation"
by David Lloyd
User development,
The document "Requirements: Remote Invocation", was updated Mar 17, 2010
by David Lloyd.
To view the document, visit:
http://community.jboss.org/docs/DOC-14983#cf
Document:
--------------------------------------------------------------
This is a requirements document for EJB proxies. *Please direct questions and comments to this thread:* http://community.jboss.org/thread/149477
Please do *not* remove any sections. If a requirement is to be removed, please strike it out so that the numbering remains consistent.
*
#Invocation_Dispatch
**
#Invocation_Components
***
#Proxy_Invocation_Handler
***
#Invocation
****
#Serialized_Format
***
#Invocation_Processor
***
#Invocation_Dispatcher
****
#Default_Simple_Implementations
***
#Invocation_Target
***
#Client_Invocation_Context
****
#Local_Invocation_Processor_Chain
****
#Remote_Invocation_Forwarder_Registry
****
#Remote_Invocation_Forwarders
****
#Availability
***
#Server_Invocation_Context
****
#Exportable_Dispatchers
*****
#Registry
****
#Availability_334899
*
#Remote_Proxies
**
#Properties_of_Remote_Proxies
***
#Equality
***
#Serializability
*
#EJB_Proxies
**
#Properties_of_EJB_Proxies
***
#Serializability_701898
h1. Invocation Dispatch
h2. Invocation Components
h3. Proxy Invocation Handler
The invocation handler of an EJB proxy shall convert the invocation details into an +Invocation+ object which contains the details of this invocation. The invocation will then be passed to an +Invocation Processor+ to be handled.
h3. Invocation
The +Invocation+ object shall consist of the reflection Method which was invoked, as well as the parameters of the method invocation. In addition, it shall provide an +Attachment+ mechanism by which contextual information may be associated with the Invocation (for example, security and transactional information).
h4. Serialized Format
The serialized format of the invocation shall consist of no more or less than a means to identify the target method, the arguments passed to the target method, and the set of attachments which are associated with the invocation.
h3. Invocation Processor
A mechanism shall be provided by which each Invocation may be preprocessed in one or more steps before it is +dispatched+ to its final target. Such processors should have the opportunity to add, remove, or modify Attachments on the Invocation. Processors should also have the opportunity to "short-circuit" an invocation and reply directly, either with a successful return or an exception of some sort.
h3. Invocation Dispatcher
The Invocation Dispatcher represents the path to the target of the Invocation and shall have the ability to execute an Invocation. For Remote proxies this typically will entail transmitting the Invocation across the network in some form, to be received and forwarded to another Invocation Dispatcher to be executed directly, or passed through another set of Invocation Processors which may or may not correspond to the sending side's Processor set before handing it to a Dispatcher to be executed.
Since the Invocation Disptacher is solely responsible for the execution of the method, it can and should impose whatever policy is appropriate for the management of any target objects which may exist (such as a registration policy, or instance pooling, or session management). The Dispatcher need not correspond to one single target object instance, though that may be the common usage outside of EJB. In particular, a target object instance may be acquired from a pool, or by way of a session ID which may be attached to the Invocation.
h4. Default (Simple) Implementations
A Dispatcher implementation shall be provided which calls the Invocation method on a given fixed Object.
A Dispatcher implementation shall be provided which passes an Invocation through an Invocation Processor to a delegate Invocation Dispatcher.
h3. Invocation Target
The +target+ of an Invocation is an object upon which the Invocation is ultimately intended to be executed. Since there is not always a one-to-one correspondance between a remote proxy and a target instance, the task of passing an invocation to a target is always fulfilled by an +Invocation Dispatcher+.
h3. Client Invocation Context
A +Client Invocation Context+ is an environment which is aware of how to forward Invocations from an +Exported+ Dispatcher to its corresponding +Server Invocation Context+(s).
h4. Local Invocation Processor Chain
Each Client Invocation Context has a local Invocation Processor chain which is used for any Invocations which are sent through an exported Dispatcher. The purpose of this Processor chain is to associate any local context - such as transactional or security information - with the outbound Invocation, to be consumed the the Processor chain on the receiving side.
h4. Remote Invocation Forwarder Registry
The Client Invocation Context shall maintain a registry of +Remote Invocation Forwarders+ which are responsible for forwarding Invocations to the appropriate destination +Server Invocation Context+. The registry is keyed by a +Server Invocation Context Identifier+. This registry may be maintained statically or by some dynamic detection mechanism.
h4. Remote Invocation Forwarders
A Remote Invocation Forwarder is responsible for implementing the transport layer for forwarding an Invocation to a specific Dispatcher in a specific Server Invocation Context. A Forwarder may forward to exactly one Server Invocation Context, or it may have a clustering policy of some sort.
Forwarders may have a specific policy for dealing with connection or networking failures, changes in networking topology, or any other transport-specific concerns.
h4. Availability
In a standalone environment, a global Client Invocation Context shall be made available in order to support simple, rapid bootstraping of a working remote invocation environment. In a container (application server) environment, the Client Invocation Context may be attached to a deployment and made available in a container-specific manner.
h3. Server Invocation Context
A +Server Invocation Context+ is an environment which can receive and act upon incoming remote Invocations. In addition, a Server Invocation Context has an associated Client Invocation Context which is responsible for handling outbound Invocations as well as Invocations which are handled locally by the Server Invocation Context.
h4. Exportable Dispatchers
In order for a Dispatcher to be sendable to, and usable by, Client Invocation Contexts (i.e. Serializable), it must be exported via the Server Invocation Context which "owns" it. This registration may optionally include an Invocation Processor which should be applied to any Invocation before it is passed to the corresponding local Dispatcher.
Any Invocation which is sent to an exported Dispatcher shall always be processed by the current Client Invocation Context. When a Server Invocation Context is active, the Server Invocation Context's associated Client Invocation Context shall be used to process Invocations. The local Invocation Processor chain associated with the Client Invocation Context shall always be used to process Invocations, even if the Invocation is forwarded to the currently active Server Invocation Context.
h5. Registry
The Server Invocation Context shall maintain a registry of exported Invocation Dispatchers. The exported Dispatchers are registered by name; thus, a name must be provided when initially exporting a Dispatcher instance.
h4. Availability
A Server Invocation Context is generally a container (application server)-related entity. As such, the availability of a Server invocation Context may be attached to a deployment and made available in a container-specific manner.
h1. Remote Proxies
A +Remote Proxy+ is a proxy object whose proxy invocation handler executes Invocations through an exported Invocation Dispatcher.
h2. Properties of Remote Proxies
h3. Equality
It is possible that more than one remote proxy can ultimately resolve into invocation of the same target object. Because of the variety of ways in which the destination of an Invocation is ultimately resolved, there is no way to meaningfully express equality between two remote proxies.
h3. Serializability
A remote proxy is always Serializable, since its constituent Dispatcher is exported. Since an exported Dispatcher is at the heart of a remote proxy, a Client Invocation Context must be present to deserialize a remote proxy instance.
h1. EJB Proxies
An +EJB Proxy+ is a remote proxy which utilizes a Dispatcher that may associate a session ID (in the case of stateful session beans, for example) or other EJB-specific information with an Invocation. This Dispatcher will ultimately delegate to an exported Invocation Dispatcher.
h2. Properties of EJB Proxies
EJB proxies are generally similar to general remote proxies in behavior; where they differ is listed below.
h3. Serializability
An EJB proxy is serializable like a remote proxy; however it may have an additional serializable Dispatcher or Dispachers associated with it.
--------------------------------------------------------------
16 years, 4 months
[JBoss AS Documentation] New message: "Include custom library in classpath"
by Felipe Rodriguez
User development,
A new message was posted in the thread "Include custom library in classpath":
http://community.jboss.org/message/532628#532628
Author : Felipe Rodriguez
Profile : http://community.jboss.org/people/Psynox
Message:
--------------------------------------------------------------
Hi All,
I'm currently seeking for a way to include a library folder to the classpath of jboss so I went to jboss-service.xml on my server configuration which is "all"
I'm using jboss 4.2.2.GA on this server so my custom library is located at /app/jboss/ext so i went and modify the jboss-service.xml file as follows:
<classpath codebase="/app/jboss/ext" archives="*"/>
also tried with:
<classpath codebase="file:/app/jboss/ext" archives="*"/>
But no success on this matter, seems the only way to load my jars is having them inside JBOSS_HOME/server/all/lib/ext folder. Any idea on what could be wrong or where should I look?
Thanks!
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532628#532628
16 years, 4 months
[JCA] New message: "Re: HornetQ RA integration"
by Vicky Kak
User development,
A new message was posted in the thread "HornetQ RA integration":
http://community.jboss.org/message/532617#532617
Author : Vicky Kak
Profile : http://community.jboss.org/people/vickyk
Message:
--------------------------------------------------------------
> jmesnil wrote:
>
> Session.recover() is used to recover message acknowledgementswhen the JMS session is not transacted. Sorry for the confusion.
>
> thanks for the clarification,
> jeff
Not sure if I understood this, it seems that Session.recovery is not the part of the jms API.
Would you explain the failure cause in details, your earlier description wasn't that clear to me?
Also you could take a look at the older implementation for some reference, since this implementation would have passed the TCK tests
http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/java/org/...
AFAIR the tx enlistment will not happen if the xa specific RA if it is not used in tx context, it should not pose any issues. I don't know how the recovery() call as pointed by you is being made after the session is retrieved from the jms RA.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532617#532617
16 years, 4 months
[JCA] New message: "Re: HornetQ RA integration"
by Jeff Mesnil
User development,
A new message was posted in the thread "HornetQ RA integration":
http://community.jboss.org/message/532613#532613
Author : Jeff Mesnil
Profile : http://community.jboss.org/people/jmesnil
Message:
--------------------------------------------------------------
> vickyk wrote:
>
> Using the xa resource with transaction context does not make any sense as there is no tx propagation, in such cases no-tx resource could be used.
I agree. Unfortunately, this is to pass TCK tests and some of them uses the same ConnectionFactory with transactions and others don't.
>
> I don't understand how the Session.recovery would be called in tests where there is no tx propagation, if the TX is not being present in the usecases then i don't see recovery being called , therefore the TX recovey mechanism will not call Session::recovery.
> The recovery will come in picture in case of TX only.
>
> I may need to understand the TCK testcase to provide more details.
I was talking about JMS Session.recover(), not XAResource.recover().
Session.recover() is used to recover message acknowledgementswhen the JMS session is not transacted. Sorry for the confusion.
thanks for the clarification,
jeff
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532613#532613
16 years, 4 months
[JCA] New message: "Re: HornetQ RA integration"
by Vicky Kak
User development,
A new message was posted in the thread "HornetQ RA integration":
http://community.jboss.org/message/532609#532609
Author : Vicky Kak
Profile : http://community.jboss.org/people/vickyk
Message:
--------------------------------------------------------------
> According to the log, getXAResource() is called on the ManagedConnection-> I create the underlying JMS XA Session
> Then the tm realizes there is no TX and does not enlist the xaresource
> Finally getConnection() is called on the ManagedConnection
> -> It will return the JMS XA session
yes this flow is in the CM::allocateConnection(), you can see the implementation here
http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/java/org/...
> jmesnil wrote:
> It's not clear to me but this seems to imply that a ManagedConnection with XA transaction has to accept doing work outside a transaction.
> I don't find the relevant section in the JCA spec. wdyt?
It does work outside the transaction, you will only get the pooling functionality and not the transparent TX enlistment since this is not called in the TX context.
Check "7.6.4 Scenario: Transactional Setup for a ManagedConnection" of JCA1.5 specs, this talks about the case when the TX propagation is there.
>
> If the application server decides that the transaction manager will manage the
>
> current transaction, it conducts the following transactional setup on the
> ManagedConnection instance:
>
>
Using the xa resource with transaction context does not make any sense as there is no tx propagation, in such cases no-tx resource could be used.
I don't understand how the Session.recovery would be called in tests where there is no tx propagation, if the TX is not being present in the usecases then i don't see recovery being called , therefore the TX recovey mechanism will not call Session::recovery.
The recovery will come in picture in case of TX only.
I may need to understand the TCK testcase to provide more details.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532609#532609
16 years, 4 months