# Meeting minutes of the meeting on Jan 23, 2013
* Participants: Jesper, Wilson, Nigel (JMS 2.0 Spec Lead -- Thanks Nigel
for participating in the call)
* Agenda:
- Close on our choice for handling CONNECTOR_SPEC-1
- Resource Definition annotations: Specification of a
resource-adapter-name and defining how a name is specified for embedded RARs.
- Any other items for discussion.
* CONNECTOR_SPEC-1
I had invited Nigel, the JMS 2.0 spec lead to participate in the call
to share his inputs on CONNECTOR_SPEC-1.
- MessageEndpointFactory.getActivationName()
Nigel clarified the need for this capability. The usecase is an ease of
development feature for JMS MDBs. Instead
of having the MDB developer/deployer set the subscription name of a
durable topic subscription (which is usually set to the MDB's name), we
would like the MDB name available to the RA so that it can generate and set
the subscription name automatically. Since this name is seen in JMS tools
it can't be a random name. The name must survive restarts as the
topic subscription in the JMS provider holds messages for that MDB.
Jesper raised the following concerns:
1. Adding a new method to the MEF prevents the use of JMS 2.0 RAs against
an older application server: Limits deployments of JMS2 on older versions
of the container. Nigel shared that JMS spec doesn't prevent a MoM vendor
from using an older version (1.5) RA that uses AS vendor-specific schemes
for the two functionalities requested in CONNECTOR_SPEC-1, except that this
would be AS-specific and hence not portable. What JMS want to do is allow
a JMS vendor to implement a RA and have it portably working with all EE7
containers.
2. Adding a method to MEF impacts all existing MEF implementations. Jesper
shared more details on the usecase of a SoA Connector 1.5 based MEF
implementation deployed to an EE7 container using AS-specific mechanisms.
The JMS RA cannot deliver to this MEF as the SoA MEF would have the
new methods missing. This would move the use of JMS RAs further away
from existing MEF implementations. Siva stated that since scenario
is a vendor-specific scenario not covered by the spec, the spec can't
do much to help here. The AS vendor does have workarounds to handle such
scenarios (eagerly fail the deployment of a 1.5 MEF to a EE7 container,
lazily prevent an endpointActivation of a 1.7 RAR on a 1.5 SoA MEF etc)
- We brainstormed on ways that don't require modification of MEF
so that JMS RAs could be based on an older version of the spec (1.5). We
discussed Choice #3 (java:comp/UniqueMDBName) and how that won't work
for MDBs-in-WAR scenario.
- We then discussed Choice 2: This requires the JMS spec to define a
JMSActivationSpec that has a "required" config property. We can then
require or recommend the MDB container to require support for this
config property. If it is a recommendation and the MDB container
doesn't support it, then we are back to status quo as we would need
the MDB developer/deployer
to specify the subscription name. We can't require the MDB container
to support the JMSActivationSpec property as we don't want to tie a MEF
implementation to a messaging style.
Jesper suggested a variant of choice 2. Let us call it "Choice 2a".
2a) Upgrade or extend the MEF interface (for instance a new
ActivationNameMessageEndpointFactory). JMS spec must be required
to pass in ActivationNameMEF for JMS passed MEFs, and the JMS RA uses it.
Again this suffers from the same issues listed above for Choice 2, and
it only allows for use of the ActivationNameMEF in JMS RAs, whereas
choice #1 allows this to be used in any RARs.
Siva suggested that the issue raised against Choice 1 is for a
vendor-specific usecase (1.5 SoA MEFs). Vendor-specific workarounds
possible to handle them and hence preferred Choice 1. Jesper preferred
Choice 2a as it requires on no impact on existing MEF implementations.
It was decided to request inputs from other members of the EG on whether
we go with (1) or (2a), and then document that approach in the first draft
that should be shared by the end of this week.
* We then discussed concerns over the getUniqueId javadoc proposal
from Jesper:
- '128char length': Nigel felt that it is important for the name to be
unique between activations as if two MDBs share a subscription name,
they may receive each other messages and that is catastrophic, and hence
it is important for the container to specify unique names.
- 'Survive restart': recommended. Jesper discussed how difficult it may be
for certain implementations to get a name for a BC instance to survive
restarts.
- Nigel then clarified that a unique application server instance name
is all that is needed and we don't need to be concerned about multiple
BC instances in the same AS instance.
- Siva then suggested that we use EE.5.16 of the latest EE7 Public Review
Draft
that defines a predefined JNDI name java:comp/InstanceName. The group
agreed that this should be good enough. We clarified that this instance
name is usable only during endpointActivation, hence since we fix
http://java.net/jira/browse/CONNECTOR_SPEC-4, this JNDI name should be
useful for the RA to obtain the server name in endpointActivation.
- Jesper suggested that though is a solution for the JMS 2.0 usecase, we
should keep this idea around for the next iteration while handling cloud
related requirements.
* Resource Definition Annotations
- Jesper said that though there is an EE spec defined module name,
relying on that as the identifier doesn't cover all scenarios. The
name for a RA is basically vendor-specific. Everytime an admin changes
a name of a RA to be different from the default, the descriptor has
to be updated.
Everytimethere is a vendor specific deployment mode (support for more
than one deployments of the same RAR), the descriptor has to be updated etc.
- Siva clarified that these issues are vendor-specific and infrequent
development scenarios. 90% dev. scenarios would be covered by the default
names. The EoD resource definition annotations are designed to cover the
most common development deployment scenarios and not all production
or vendor-specific configuration. Vendor DDs and tools would continue to be
used for those scenarios.
- Jesper felt that at this late stage, we should defer this. Siva wondered
what would change if we defer. The above concerns would still be valid in
the future etc. The group decided to get inputs from the other members
in the EG. AI: Siva to send out an email to the EG, requesting the other
members to share their comments on these two issues.
- We clarified that even if we move to the scoped deployment model in
the future, what we are proposing today would work in that model as well.
- Jesper stated that some vendors may require additional properties
for these annotations to work effectively making the application component
that uses it non-portable. He shared his experience with
DataSourceDefinition. In their WebProfile implementations, connections
handed out by DataSourceDefinition required to be enlisted in
transactions, and for that Connectors support was required. In order
for connectors to work the user needed to specify AS-specific connector
specific properties. Siva suggested that this is a vendor-specific
implementation issue.
and our annotaions would not have this problem as they have all the minimal
information needed to create a CF and a AO in a connector container.
* There would be a meeting next week to discuss comments on the draft,
and any other open issues.
Thanks
--Siva.
On Tuesday 22 January 2013 11:32 PM, Sivakumar Thyagarajan wrote:
> Hi
>
> Let us meet tomorrow (Jan 23) for this week's EG call.
>
> Time: Jan 23, Tuesday 8am ET/1pm GMT: http://bit.ly/143QbCk
>
> Duration: 1 hour
>
> Conference Coordinates:
> US: 866-682-4770/1-408-774-4073
> India: 080-39890080
> Others:
> https://www.intercallonline.com/listNumbersByCode.action?confCode=8747157
>
> Conference Code: 874-7157
> Security Code: 1234
>
> Agenda:
> - Close on our choice for handling CONNECTOR_SPEC-1
> - Resource Definition annotations: Specification of a
> resource-adapter-name and defining how a name is specified for embedded RARs.
> - Any other items for discussion.
>
> Looking forward to seeing you in the call.
>
> Thanks
> --Siva.