[EJB 3.0 Development] New message: "Re: Deferring instance creation/injection to CDI"
by Andrew Rubinger
JBoss development,
A new message was posted in the thread "Deferring instance creation/injection to CDI":
http://community.jboss.org/message/532123#532123
Author : Andrew Rubinger
Profile : http://community.jboss.org/people/ALRubinger
Message:
--------------------------------------------------------------
https://jira.jboss.org/jira/browse/EJBTHREE-2046
Looks like we can extract the instantiation logic, and let EJB3 provide it's own implementation. CDI, if it likes, can swap out for their own during deployment. I've committed r102436 to see if this can be a workable solution for both teams.
/**
* Contract of a component responsible for creation of EJB bean
* and instances. Though the EJB specification dictates
* the use of a no-arg constructor, contextual EJBs defined by JSR-299
* provides for additional features such as injected constructor parameters,
* so alternate implementations of this type may be used by the
* EJB container.
*
* @author <a href="mailto:andrew.rubinger@jboss.org">ALR</a>
* @version $Revision: $
*/
public interface BeanInstantiator
{
//-------------------------------------------------------------------------------------||
// Contracts --------------------------------------------------------------------------||
//-------------------------------------------------------------------------------------||
/**
* Creates a new instance of the specified implementation {@link Class}
* using the supplied parameters. While the implementation class
* must be specified, <code>null</code> is a valid value for the parameters,
* and will be treated as a 0-length array.
*
* @throws IllegalArgumentException If the implementation class was not specified
* or the implementation does not support parameters (while they've been supplied).
* @throws InvalidConstructionParamsException If the implementation of this type does
* not support the parameters supplied.
* @throws BeanInstantiationException If an unexpected error occurred in constructing the bean
* instance
*/
<T> T create(Class<T> implClass, Object[] parameters) throws IllegalArgumentException,
InvalidConstructionParamsException, BeanInstantiationException;
}
The EJB3 impl is simple:
/**
* Implementation of {@link BeanInstantiator} strictly conforming to the
* EJB 3.1 Specification. Any non-0-length or non-null parameter arguments to
* {@link Ejb31SpecBeanInstantiator#create(Class, Object[])}
* will result in {@link InvalidConstructionParamsException}
*
* @author <a href="mailto:andrew.rubinger@jboss.org">ALR</a>
* @version $Revision: $
*/
public class Ejb31SpecBeanInstantiator implements BeanInstantiator
{
//-------------------------------------------------------------------------------------||
// Class Members ----------------------------------------------------------------------||
//-------------------------------------------------------------------------------------||
/**
* Logger
*/
private static final Logger log = Logger.getLogger(Ejb31SpecBeanInstantiator.class.getName());
/**
* Message used in reporting exceptions during instantiation
*/
private static final String MSG_PREFIX_INSTANTIATION_EXCEPTION = "Could not create new instance with no arguments of: ";
//-------------------------------------------------------------------------------------||
// Required Implementations -----------------------------------------------------------||
//-------------------------------------------------------------------------------------||
/**
* {@inheritDoc}
* @see org.jboss.ejb3.instantiator.spi.BeanInstantiator#create(java.lang.Class, java.lang.Object[])
*/
public <T> T create(final Class<T> implClass, final Object[] parameters) throws IllegalArgumentException,
InvalidConstructionParamsException, BeanInstantiationException
{
// Precondition checks
if (parameters != null && parameters.length > 0)
{
throw InvalidConstructionParamsException
.newInstance("EJB Specification requires a no-argument constructor be invoked for bean instances on "
+ implClass.getName());
}
// Instantiate
final T obj;
try
{
obj = implClass.newInstance();
}
catch (final InstantiationException e)
{
throw BeanInstantiationException.newInstance(MSG_PREFIX_INSTANTIATION_EXCEPTION + implClass, e);
}
catch (final IllegalAccessException e)
{
throw BeanInstantiationException.newInstance(MSG_PREFIX_INSTANTIATION_EXCEPTION + implClass, e);
}
// Log
if (log.isLoggable(Level.FINER))
{
log.finer("Created: " + obj + "; instance of " + implClass.getName());
}
// Return
return obj;
}
}
S,
ALR
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532123#532123
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 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.
*
#EJB_Proxies
**
#Remote_Proxies
***
#Invocation
****
#Proxy_Invocation_Handler
****
#Invocation_501674
****
#Invocation_Processor
****
#Invocation_Dispatcher
****
#Invocation_Target
***
#Proxy_Serialization_and_Deserialization
****
#Proxy_Deserialization_Constraints
*****
#Remote_Invocation_Context
****
#Proxy_Serialization_Constraints
*****
#Remote_Invocation_Context_585717
***
#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
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. 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.
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. 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
[EJB 3.0 Development] New message: "Re: Proxy Requirements"
by David Lloyd
JBoss development,
A new message was posted in the thread "Proxy Requirements":
http://community.jboss.org/message/532098#532098
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> wolfc wrote:
>
> Serialization of a remote proxy can happen within any context. It could be because the proxy was dropped in an HttpSession, which can get serialized for any reason or it was injected into a far-away SFSB that's passivated.
I think it's safe to assume that the context is generally always available from a yet-to-be-serialized proxy, one way or another. I will update the document to this effect.
> wolfc wrote:
> I'm also missing bits for security and transaction propagation.
It's implied (vaguely) in the discussion of attachments. I'll elaborate that section a bit.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532098#532098
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 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.
*
#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_470320
***
#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
[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Kabir Khan
JBoss development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/532084#532084
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
One thing I have been doing which might be unnecessary is to wrap things with wildcards with a delegating class, e.g.:
/**
* Type info for a wildcard type
*
* @author <a href="kabir.khan(a)jboss.com">Kabir Khan</a>
* @version $Revision: 1.1 $
*/
public class WildcardTypeInfo extends DelegateClassInfo
{
private static final long serialVersionUID = 1L;
private final String name;
public WildcardTypeInfo(String name, ClassInfo delegate)
{
super(delegate);
this.name = name;
}
@Override
public void toShortString(JBossStringBuilder buffer)
{
buffer.append(name);
}
@Override
protected void toString(JBossStringBuilder buffer)
{
buffer.append("name=").append(name);
}
}
So if you try to get the typeInfo for Class<? extends some.Thing> we end up with a ParameterizedClassInfo for Class which contains one type argument. This type argument is for some.Thing. The original introspection implemetation would just use that directly. What I am doing now is to
get the TypeInfo for some.Thing (1) and decorate that with a WildcardTypeInfo that delegates to 1, but has the name '? extends some.Thing' which is ONLY used in these two cases:
* invoking toString().
* looking up the WildcardTypeInfo in the cache
This has been done for both implementations.
The reason I am unsure if this is needed after all is that I am currently implementing TypeVariables, e.g.:
public <T extends some.Thing> T signatureMethod()
If I were to wrap it, I would end up with 1 and wrapping that with a TypeVariableTypeInfo which overrides toString with 'T extends some.Thing'. The problem is that if we also have
public <U extends some.Thing> T signatureMethod2()
public <V extends some.Thing> T signatureMethod3()
We end up with 3 different cached versions with a different name used for toString(), which all delegate to 1.
The only reason I did this was to have nice output when calling toString(), so I am wondering if that is really necessary?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/532084#532084
16 years