Hi Jesper
Thanks again for sharing your inputs on these.
On Monday 28 January 2013 08:08 PM, Jesper Pedersen wrote:
> Hi,
>
> On 01/23/2013 02:49 PM, Sivakumar Thyagarajan wrote:
>> 1. Providing an ActivationName to the RA (CONNECTOR_SPEC-1):
>> We have two choices:
>> - Choice #1: Introduce MessageEndpointFactory.getActivationName, and
>> have the JMS RA use them.
>> - Choice #2a: Upgrade or extend the MEF interface (for instance
>> introduce a new
>> ActivationNameMessageEndpointFactory that extends MessageEndpointFactory
>> and adds a method String getActivationName()). JMS spec must be required
>> to pass in instances ActivationNameMessageEndpointFactory for JMS
>> MessageEndpoints, and the JMS RA uses the
>> ActivationNameMessageEndpointFactory to get the activation name.
>>
>> ACTION: Please state your choice or alternative ideas.
>>
>
> Choice 2:
>
> public interface NamedMessageEndpointFactory extends MessageEndpointFactory
> {
> /**
> * Get the activation name of the message endpoint factory
> * @return The value
> * @exception ResourceException Thrown in case an internal occurs
> * in the message endpoint factory
> */
> public String getActivationName() throws ResourceException;
> }
Ok. Overall, I am not very convinced with the reasoning for a separate MEF
for the following reasons:
1. the SOA usecase is a vendor-specific feature that the spec doesn't
directly address
2. the change is not a backward incompatible change, and there are
vendor-specific options to handle this change gracefully for those
vendor-specific MEF implementations (that we discussed in last week's call
-- I agree that it is more work for the AS vendor, but this is a
AS-specific feature anyway).
3. We have already made changes to the MEF interface in 1.6, and we
haven't heard objections from the AS and developer community.
4. This change would require the AS (MDB container) to behave specially
for JMS RAs by providing a NamedMessageEndpointFactory. This would break
the design where we wanted endpoint containers to not care about the
messaging type backed by inbound RAs.
5. Minor: the activation name, as we would be proposing in 1.7, is not
JMS-specific and can be provided by all MEF implementations (including the
SoA MEF)
So, let us go with Choice #1.
>> 2. Resource Definition Annotations:
>> There has been discussions on how a resource adapter name could be used
>> to identify a deployment of a RAR, and how such Resource Definition
>> annotations can be used in a portable manner in most development
>> usecases. We have also discussed some vendor-specific concerns on these.
>>
>> ACTION: Could you share your inputs
>> on those discussions and whether we should defer them? If your choice is
>> to defer, please state what technical reasons are there to defer them,
>> and in particular what additional information that we don't have today
>> would be gained if we defer to a future release.
>>
>
> Defer.
>
> The current suggestion relies on an 'all-is-default-and-by-spec-only'
> scenario.
IMO, the "by-spec-only" point is not true. Could you please let me know
what in the current draft brings this out? I have tried to tread carefully
in the verbiage in Chapter 18 to ensure that vendor-specific deployment
models may not get affected and still make it easier for applications to
state their resource definitions portably for development scenarios.
The resource adapter name is a String and can be specified to be any
vendor-specific value by the application component developer. However at
this point the application becomes vendor-specific and non-portable.
The application component developer could always, and is recommended to if
they want their app to be portable, to use the default module name of the
RAR, and this would work in all Java EE application servers.
The current design handles the standard scenarios well, and allows (as in:
doesn't prevent) vendor-specific deployment models.
> Vendor specific properties for the deployment maybe mandatory, and the
> implicit rules used may not align against the vendor best practice
> deployment model.
>
> This will lead to overrides has to be able to be managed out the way
> "out": web.xml, vendor specific web.xml and so on. This is confusing for
> the developer.
We have discussed these points at length. Vendors could default
intelligently for any vendor-specific properties that are "required" for a
connection factory. If they can't default in the annotations scenario,
then they would not be default even otherwise (and so that is a problem
with the vendor's deployment model).
Thanks
--Siva.
> Having deployment annotations that doesn't depend on implicit rules would
> be a better solution.
>
> Best regards,
> Jesper
>