[EJB 3.0 Development] Document updated/added: "Requirements: EJB Proxies"
by David Lloyd
User development,
The document "Requirements: EJB Proxies", 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_Implementations
***
#Invocation_Target
***
#Remove_Invoker_Context
****
#Inbound_Invocations
***
#Remote_Dispatcher_Identification
*
#Remote_Proxies
*
#EJB_Proxies
**
#Remote_Proxies_549275
***
#Invocation_685284
****
#Proxy_Deserialization_Constraints
*****
#Remote_Invocation_Context
****
#Proxy_Serialization_Constraints
*****
#Remote_Invocation_Context_647432
***
#High_Availability_and_Clustering
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 should 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 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.
h4. Default 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. Remove Invoker Context
A +Remote Invoker Context+ is a realm from which invocations originate, and/or to which invocations arrive.
h4. Inbound Invocations
Inbound invocations are mapped to their unique destination Dispatchers by a +Remote Dispatcher Identifier+. Thus an inbound invocation associated with a given Remote Invoker Context will consist of the Invocation itself, plus a Remote Invoker Identifier which will select the Dispatcher to send the Invocation to.
h3. Remote Dispatcher Identification
Within a single Remote Invoker Context,
h1. Remote Proxies
h1. EJB Proxies
h2. Remote Proxies
h3. Invocation
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. A remote invocation proxy will be associated with a Remote Invocation Context, which may contribute to the serialization of a proxy.
h3. High Availability and Clustering
--------------------------------------------------------------
16 years, 4 months
[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Kabir Khan
User development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/532580#532580
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Trying to run the kernel tests with the jboss-reflect snapshot and javassist implementation with security disabled results in loads of failures. A lot of these seem to be due to BeanInfo never having been tested with the Javassist implementation, and fall into the following categories:
* PropertyInfo.getUnderlyingAnnotation() is not working properly w/ Javassist so we get problems in jbossxb since the @XmlTransient annotation is not read
* I need to dig in properly, but it seems that when configuring Collection/Map/Array properties, the individual elements are null rather than containing the expected values
* There might be more
I am currently creating Javassist versions of the org.jboss.test.beaninfo.test.* tests and fixing what comes up. The first thing I found is that when creating property infos for things like
public class BeanInfoGenericInconsistentTypes
{
public BeanInfoGenericClass<String> getSomething()
{
return null;
}
public void setSomething(BeanInfoGenericClass<Integer> x)
{
}
}
With the Javassist implementation the 'something' property gets both a getter and a setter, while with introspection it gets only a getter. The code that determines this is this in AbstractBeanInfoFactory.getBeanProperties():
TypeInfo pinfo = thisSetter.getParameterTypes()[0];
if (getter.getReturnType().equals(pinfo) == true)
The introspection implementation returns ParameterizedClassInfos containing the generic information for the parameter and return types, so it looks like I will need to implement that for javassist anyway.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532580#532580
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/532567#532567
Author : Jeff Mesnil
Profile : http://community.jboss.org/people/jmesnil
Message:
--------------------------------------------------------------
> vickyk wrote:
>
> The client application will get the ConnectionFactory which will call the ConnectionManager::allocateConnection() and further invoke createManagedConnection Or matchManagedConnection.
>
> The createManagedConnection will basically invoke the MCF::createConnection().
>
> PS: If you could explain the details then I could take a deeper look at the specs and corresponding details, right now I am putting all what is there in top of my mind.
In HornetQRAManagedConnectionFactory.createConnection(), I create the ManagedConnection which in turn create the underlying HornetQ JMS resources.
At that time, I need to know if I should create a XASession (if <xa-transaction /> was specified), a transacted Session (if <local-transaction />) or a non-transacted Session (if in a <no-tx-connection-factory> element).
This created session will be returned later by ManagedConnection.getConnection(). Is that correct?
I'm diving into the JCA spec to have a better picture of this...
thanks for the help
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532567#532567
16 years, 4 months
[JBoss Web Services Development] New message: "modify ENDPOINT_ADDRESS_PROPERTY at runtime"
by simone bagnolesi
User development,
A new message was posted in the thread "modify ENDPOINT_ADDRESS_PROPERTY at runtime":
http://community.jboss.org/message/532559#532559
Author : simone bagnolesi
Profile : http://community.jboss.org/people/bagnos
Message:
--------------------------------------------------------------
hi,
i have some problems about changing ENDPOINT_ADDRESS_PROPERTY inside client soap handler, i have jbossws native and jboss-5.1.0.GA.
It works outside the handler with the follow instructions:
Sample port1 =
service.getSamplePort();String newAddress=
"http://-contesto-:8080/COPERGMPS.SOA/PTGateway";((BindingProvider)port1).getRequestContext().put(BindingProvider.
+ENDPOINT_ADDRESS_PROPERTY+, newAddress);
inside the handler, with the follow:
**public
**
*
*boolean* handleMessage(SOAPMessageContext arg0) {
arg0.put(BindingProvider.
+ENDPOINT_ADDRESS_PROPERTY+, "http://-contesto-:8080/COPERGMPS.SOA/PTGateway");
*return* *true*;}
the above instruction doesn't work.
The +ENDPOINT_ADDRESS_PROPERTY + remains the same as the orginal wsdl soap address.
The above instruction works with websphere 7.0 , tomcat and jdk.
Someone can I help me?
thanks
*
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532559#532559
16 years, 4 months
[jBPM] New message: "Re: Adding comments to an execution?"
by Ricardo Zuasti
User development,
A new message was posted in the thread "Adding comments to an execution?":
http://community.jboss.org/message/532556#532556
Author : Ricardo Zuasti
Profile : http://community.jboss.org/people/rzuasti
Message:
--------------------------------------------------------------
I took a dirtier approach,something like:
List<HistoryTask> executionTasks = pe.getHistoryService().createHistoryTaskQuery().executionId(task.getExecutionId()).orderAsc(TaskQuery.PROPERTY_CREATEDATE).list();
for (HistoryTask executionTask : executionTasks){
List<HistoryComment> comments = taskService.getTaskComments(executionTask.getId());
//... merge all comments in one big list
}
ie listing all comments of all the tasks in the execution ID, I hope it doesn't hit my systems performance too hard
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532556#532556
16 years, 4 months