Hi
Please find the minutes of our meeting yesterday below. Please let me/the
list know if there is anything I had missed or misrepresented.
Thanks again for participating in the call and sharing your valuable comments.
Agenda:
http://java.net/projects/connector-spec/lists/jsr322-experts/archive/2013-01/message/24
Participants: Jesper, Jun, Wilson and Fred
* JMS related enhancements (Spec issue #1 and #5)
- We discussed the two approaches and their benefits and issues.
- BootstrapContext.getInstanceName:
- Jesper: There was a discussion on whether a developer could specify
the instance name as part of activation spec configuration. We can't have
the MEF setup the configuration as this would result in the MEF being
messaging specific, which we want to avoid. We can't have the developer
specify it as the instance name is related to where the MessageEndpoint is
being deployed to (in the case of cluster, a user would then have to
specify a distinct value for this activation spec configuration in every
instance of the cluster). There was a discussion on how certain connector
containers may not have the notion of an instance name or have multiple
instances running in the same VM. Siva suggested that the instance name
could be considered as the unique identifier of the instance (application
server in the case of traditional EE environments ) that had activated the
resource adapter. The name is vendor-specific. Even if a BootstrapContext
instance is shared across multiple connector container instances, the spec
only requires that a unique name be returned for this method in each of
those connector instances.
- There was a discussion on what constitutes human-readable, but since
this is vendor-specific the vendor defines how this is named. A JMS RA
cannot assume that the returned value is human understandable.
- The group felt that since this value is vendor-specific and this
could be used by non-JMS RARs, the specification of 128-char limit is
arbitrary. The group felt that if needed, the JMS RA could use some
private mechanism (hash/trim or something else) to limit it to the size
that is acceptable as a topic subscription name in the messaging system it
supports. AI: Siva to start a EG thread with Nigel on this.
- MessageEndpointFactory.getActivationName:
- Jesper/Fred: A concern on this addition impacting all MEF
implementations was raised. There was a suggestion that this could
probably be worked through a required configuration property. If the
MessageEndpoint application developer specifies the value for this, we
would not need the MEF implementation to provide this. AI: Siva to start
an EG thread with Nigel on this. Nigel to provide more details on the
usecase that needs this capability and the EG would provide suggestions
based on what is needed.
- One suggestion was that even if we had to implement this, was to have
a MEF subclass that has this additional method, that is only implemented
by the MDB container's MEF implementation.
- There was a discussion on backward compatibility of making such
changes to MessageEndpointFactory. Siva clarified that as per the EE
compat requirements
(
http://java.net/projects/javaee-spec/pages/CompatibilityRequirements) and
the JLS binary compatibility requirements, addition of a method to a SPI
is backwards compatible. Wilson pointed to the group to the fact that in
Connectors 1.6, we had added an additional method to MEF (createEndpoint
that takes a timeout).
AI: Jesper plans to write more about a scenario that he brought to the
group's attention (a 1.7 connector container that has a 1.6 MEF
implementation) that may be problematic to support and send to the group
for further discussion
- Jesper/Jun: Agreed that RA can lookup JNDI context during
endpointActivation (issue #5). It was clarified that the component context
of the MessageEndpoint that is being activated must be made available
during endpointActivation so that the RA can lookup resources defined in
the component context (including java:comp) of the MessageEndpoint.
- In general, approach A is preferred by the group, but we would still
need to address the open question of the need for
MessageEndpointFactory.getActivationName. Jesper suggested that we be
careful bringing in new methods such as this, as there may be new
container approaches made possible in EE8 (as part of the cloud requirements).
* Resource Definition Annotations CONNECTOR-SPEC-6
- We discussed the issue of the package name for the new resource
definition annotations. Jesper felt that since these annotations are
deployment focussed as against the Connector 1.6 EoD annotations, it would
be better to place them in a separate package (javax.resource.deployment).
This separation is also useful when we clarify how these annotations must
not (or must) be supported in other (non-EE-full-profile) environments.
These annotations are useful from a developer point of view, but in
testing and production scenarios vendor-specific tools are recommended and
these annotations are overridden. Siva and Jun shared that other specs
(JMS) don't make this distinction about package names. Siva stated that he
would add this to a list of issues to be discussed further.
- We discussed how these annotations must be supported in standalone
connector containers. Jesper raised a point about how a standalone
connector container may include a servlet container to support an admin
UI, but may not want to support these resource definition annotations. AI:
Siva said that he would work with the platform spec leads to understand
the requirements here, and get back to the group.
- The group confirmed that these annotations cannot be placed in a
resource adapter module. The spec would not require the support of these
annotations in application client containers as connector support in ACC
is not required
- Resource adapter name: Deployment of resource adapters are
vendor-specific in the spec. It appears that the deployment models of
JBoss is different from say GlassFish, and the way a resource adapter
module is deployed(activated) is distinct from its packaging structure.
Resource adapter artifacts are created in a single unit of Work, and not
independently addressable from outside through a "name". AI:Jesper said
that he would send a writeup to the EG the differences between the
deployment models and how the notion of a resource adapter 'name' may not
work in all containers.
- JNDI namespaces: We had a brief discussion on which JNDI namespaces
would a resource definition annotation be allowed to define names in. AI:
Siva to send a writeup on the possible options to the EG and we can then
have a discussion on it.
- We talked about the proposed model by Jesper where other resource
adapter related entities such as the RA configuration etc could be defined
using annotations. We tried to understand why the resource adapter name
approach wouldn't still work. Once we have Jesper's writeup on the
differences in the deployment model, we can discuss this issue further.
- We talked about timelines. The Java EE 7 schedule at
http://java.net/projects/javaee-spec/pages/Home is the schedule we follow
(We are in group #3). Siva said that he would send out an interim draft of
the spec changes to the EG for review by late this week or end of next
week, and the group should aim for the availability of a final change log
by the end of this month, so that we can be available for submission to
the JCP in the first week of February.
- Jesper shared with the group that he was the spec lead for the
OSGi-Connector RFC in the OSGi Alliance and invited members to participate
in that effort and said he would share details in a separate email.
Thanks
--Siva.
On Tuesday 08 January 2013 08:48 PM, Sivakumar Thyagarajan wrote:
> Hi
>
> Let us meet tomorrow (Jan 9) for this week's EG call.
>
> Time: Jan 9, Tuesday 9am ET/2pm GMT: http://bit.ly/VIql46
>
> Duration: Upto 2 hours (max).
>
> Conference Coordinates:
> US: 866-682-4770/1-408-774-4073
> India: 080-39890080
> Others: http://www.intercall.com/oracle/access_numbers.htm
>
> Conference Code: 874-7157
> Security Code: 1234
>
> [I will ensure that this conf code works]
>
> Agenda: remains the same.
>
> Thanks
> --Siva.