[EJB 3.0 Development] Document updated/added: "Requirements: EJB Proxies"
by David Lloyd
JBoss development,
The document "Requirements: EJB Proxies", was updated Mar 15, 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 do *not* remove any sections. If a requirement is to be removed, please strike it out so that the numbering remains consistent.
*
#EJB_Proxies
**
#Remote_Proxies
***
#Invocation
****
#Proxy_Invocation_Handler
****
#Invocation_Processor
****
#Invocation_Dispatcher
****
#Invocation_Target
***
#Proxy_Serialization_and_Deserialization
****
#Proxy_Deserialization_Constraints
*****
#Remote_Invocation_Context
****
#Proxy_Serialization_Constraints
*****
#Remote_Invocation_Context_572805
***
#High_Availability_and_Clustering
h1. EJB Proxies
h2. Remote Proxies
h3. Invocation
h4. 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.
h4. 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 attach additional information to the Invocation, or modify such attachments. 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.
h4. 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.
h4. 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. Proxy Serialization and Deserialization
When a proxy is deserialized, it is expected that the deserialized Proxy will be functional regardless of where and when the proxy is deserializaed. There shall be constraints on the functionality of deserialized proxies, as follows.
h4. Proxy Deserialization Constraints
h5. Remote Invocation Context
In order for a proxy to be functional after deserialization, it shall be required that the user provide, directly or indirectly, a +Remote Invocation Context+ which is necessary to fully reconstitute a working remote proxy. Proxy instances which are deserialized without the presense of such a context will not be usable and will cause an exception to be thrown upon invocation.
h4. Proxy Serialization Constraints
h5. Remote Invocation Context
A proxy must be serialized in the presence of a Remote Invocation Context. Attempting to serialize a proxy without such a context will cause an object validation exception.
h3. High Availability and Clustering
--------------------------------------------------------------
16 years
[EJB 3.0 Development] Document updated/added: "Requirements: EJB Proxies"
by David Lloyd
JBoss development,
The document "Requirements: EJB Proxies", was updated Mar 15, 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 do *not* remove any sections. If a requirement is to be removed, please strike it out so that the numbering remains consistent.
*
#EJB_Proxies
**
#Remote_Proxies
***
#Invocation
****
#Proxy_Invocation_Handler
****
#Invocation_Processor
****
#Invocation_Dispatcher
***
#Proxy_Serialization_and_Deserialization
****
#Proxy_Deserialization_Constraints
*****
#Remote_Invocation_Context
****
#Proxy_Serialization_Constraints
*****
#Remote_Invocation_Context_483294
***
#High_Availability_and_Clustering
h1. EJB Proxies
h2. Remote Proxies
h3. Invocation
h4. 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.
h4. 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 attach additional information to the Invocation, or modify such attachments. 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.
h4. Invocation Dispatcher
The Invocation Dispatcher represents the target of the Invocation and shall have the ability to execute an Invocation appropriately. For Remote proxies this typically will entail transmitting the Invocation across the network in some form. The receiving side may dispatch the Invocation directly, or it may pass the Invocation through another set of Invocation Processors which may or may not correspond to the sending side's Processor set.
h3. Proxy Serialization and Deserialization
When a proxy is deserialized, it is expected that the deserialized Proxy will be functional regardless of where and when the proxy is deserializaed. There shall be constraints on the functionality of deserialized proxies, as follows.
h4. Proxy Deserialization Constraints
h5. Remote Invocation Context
In order for a proxy to be functional after deserialization, it shall be required that the user provide, directly or indirectly, a +Remote Invocation Context+ which is necessary to fully reconstitute a working remote proxy. Proxy instances which are deserialized without the presense of such a context will not be usable and will cause an exception to be thrown upon invocation.
h4. Proxy Serialization Constraints
h5. Remote Invocation Context
A proxy must be serialized in the presence of a Remote Invocation Context. Attempting to serialize a proxy without such a context will cause an object validation exception.
h3. High Availability and Clustering
--------------------------------------------------------------
16 years
[JBoss Microcontainer Development] New message: "Issues with vfs30 MountHandle"
by Thomas Diesler
JBoss development,
A new message was posted in the thread "Issues with vfs30 MountHandle":
http://community.jboss.org/message/531973#531973
Author : Thomas Diesler
Profile : http://community.jboss.org/people/thomas.diesler@jboss.com
Message:
--------------------------------------------------------------
Folks,
I had a look at the MountHandle that was advertised in https://jira.jboss.org/jira/browse/JBVFS-147. Here some feedback.
MountHandle is not part of VirtualFile. This forces clients to maintain an association of VirtualFile to MountHandle
VirtualFile.isFile()
VirtualFile.openStream()
behaves differently depending on whether the VF has been mounted or not. Client code that needs stream access to the file's content would need to do some complicated processing like this
if (isMountedSomehow(vfile))
{
is = getStreamFromMountHandleSomehow(vfile);
}
else
{
is = vfile.openStream();
}
Also, consider this
vfile1 = VFS.getChild("file:/somepath/somearchive.jar")
mountHandle = mount(vfile1);
vfile2 = VFS.getChild("file:/somepath/somearchive.jar")
Both files behave quite differently WRT stream handling, etc.
Consider the case of AbstractVFSArchiveStructureDeployer, which does an automount of the underlying file. Any structure deployer that comes after it cannot access the underlying file as a stream any more.
IMHO there ought to be a layer that schields clients from changes in semantic behaviour caused by mounting. A client cannot know what happend to a VirtualFile before it accesses it methods. For example
VFSUtils.getManifest(vfile)
does vfile.getChild("META-INF/MANIFEST.MF") internally, which only works when the file had been mounted. A client would not know that nor is it obvious how to obtain the manifest from an unmounted file.
Somehow I try to shield the OSGi layer from these semantic differences in
http://fisheye.jboss.org/browse/JBossOSGi/projects/vfs/trunk/vfs30/src/ma...
http://fisheye.jboss.org/browse/JBossOSGi/projects/vfs/trunk/vfs30/src/ma...
which involves registries for VF/MH associactions. Additional methods like VirtualFile.getStreamURL() etc. The abstraction for VFS21 is more direct and cleaner in comparison. Again, IMHO a client of VFS30 should have access to an API which "always works" regardless of the internal details on VFS30 mounting.
One obvious example is that my client code would need to do vfile access very differently dependeing on whether AbstractVFSArchiveStructureDeployer had automounted the vfile or not. This doesn't seem right especially if I need access to the "unmounted" bytes to pass on to 3rd party.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531973#531973
16 years