Hi,
On 12/20/2012 09:05 AM, Sivakumar Thyagarajan wrote:
>> So 'destination' would be a java.lang.String (as it is today), and a JNDI
>> lookup would take place in endpointActivation() to resolve the
>> javax.jms.Destination object.
>
> Sorry, I didn't quite understand this. Could you please help me
> understand this?
>
> In Approach #2, we would have defined a standard ActivationSpec, as
> follows:
> [as shown in Table #2 of
> jmsra-connectors-mdb-spec-enhancements-in-ee7-a-comparison.pdf attached
> earlier in this thread]
>
> class JMSActivationSpec implements ActivationSpec{
> ...
> javax.jms.Destination getDestination();
> void setDestination(Destination d);
> ...
> }
>
Yes, but javax.jms.Destination isn't a valid config-property type, so
you can't use that.
All properties on the ActivationSpec has to follow the restrictions set
forth by the XSD, as defined by 'config-property-typeType', e.g. all the
simple Java types.
Having complex objects would create a strong dependency, as users
doesn't have a possibility to set those, as configuration is done by
strings.
> In MEFs that support JMSActivationSpec, we would have the MEF container
> looking up a Destination (based on some configuration that was specified
> by the user during deployment of that endpoint) in JNDI, and setting
> that looked up 'javax.jms.Destination' object in the JMSActivationSpec
> bean instance. In the cases where MEF doesn't support JMSActivationSpec,
> we expect the user to specify the value for the "javax.jms.Destination"
> java object, not a "String" that a container/RA then looksup, because we
> expect the RA to be unaware of whether the MEF container supports
> JMSActivationSpec or not.
>
So the lookup has to be done using the spec defined types,
interface JmsActivationSpec extends ActivationSpec
{
public String getDestination();
public void setDestination(String v);
}
::endpointActivation(MEF, AS)
{
if (!(AS instanceof JmsActivationSpec))
throw ...;
JmsActivationSpec jas = (JmsActivationSpec)AS;
Context context = null;
try
{
context = new InitialContext();
javax.jms.Destination d = context.lookup(jas.getDestination());
...
}
Plus the ManagedConnectionFactory's knows which destination/topic they
control, so using ResourceAdapterAssociation could simplify
configuration for the user even further, e.g. why enter the destination
name twice ? Having an unique identifier would be less error prone.
Best regards,
Jesper