Thanks, Marina. Yes. That answers those questions.
Any additional thoughts on inAppClientContainer residing in java:comp?
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Date: 07/18/2012 08:32 PM
Subject: [ejb-spec users] [jsr345-experts] Re: Fwd: Proposals for
MDB and RA standardisation (JMS_SPEC-30,55,54,25,73)
Jeremy,
About the questions in the "General questions" section:
* Do "java:comp" entries need to be available outside the call to
activateEndpoint? If yes, what are the semantics for EJB-in-WAR
(wherein all components share java:comp)?
* Further, do the "java:comp" entries need to be available when
activateEndpoint is called outside the scope of an MDB?
I got the following answer from the JCA spec lead:
> During endpointActivation access to java:/comp is available for a
> Resource adapter [Please see Section 13.4.4 of the Connectors spec].
> The endpointActivation is only called by an application container for
> endpoint activations.
Does it answer your questions?
thanks,
-marina
Jeremy Bauer wrote:
> Sorry this is a bit late. I have some comments & questions on the
> EJB, JMS, and JCA alignment proposal.
>
> General comments
>
> * For consistency with the platform spec, the lookup strings should be
> "java:comp", not "java:/comp".
>
> * JNDI names should be in "java:comp", not "java:comp/env".
> java:comp/env is owned by the app. Using env could cause backward
> compatibility issues for apps that have declared these names.
>
> * JNDI names should be capitalized for consistency with other
> builtins: UserTransaction, TransactionSynchronizationRegistry, ORB,
> EJBContext, TimerService, etc.
>
> Section 2.2.2
>
> * uniqueMDBName - What is the scope of the uniqueness? Within the
> current module, app, server, cluster, or UUID?
>
> * instanceName - This name is confusing in the context of an EJB.
> Perhaps "ServerInstanceName" or "ClusterMemberName"?
>
> Section 2.2.3
>
> * inAppClientContainer - Why was type String chosen instead of
> Boolean? (I think this may just be a copy/paste bug)
>
> * inAppClientContainer -Since this property is component specific it
> seems to make more sense to bind it into java:comp. (In addition,
> using shared namespaces such as java:global or java:app to store this
> setting will cause complications for some of the federated deployment
> modes that WebSphere supports.)
>
> General questions
>
> * Do "java:comp" entries need to be available outside the call to
> activateEndpoint? If yes, what are the semantics for EJB-in-WAR
> (wherein all components share java:comp)?
> * Further, do the "java:comp" entries need to be available when
> activateEndpoint is called outside the scope of an MDB?
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net,
> Date: 07/05/2012 08:11 PM
> Subject: [jsr345-experts] Fwd: Proposals for MDB and RA
> standardisation (JMS_SPEC-30,55,54,25,73)
> ------------------------------------------------------------------------
>
>
>
> Experts,
>
> This is the email and the revised proposal on alignment of EJB, JMS, and
> JCA specs in the MDB configuration areas.
>
> Please read carefully the email and the proposed changes and let me and
> Nigel (who is on the users alias) know if you agree with the proposal or
> not (and if not, the why).
>
> thanks,
> -marina
>
> -------- Original Message --------
> Subject: [jms-spec users] [jsr343-experts] Proposals
> for MDB and RA
> standardisation (JMS_SPEC-30,55,54,25,73)
> Date: Fri, 29 Jun 2012 18:59:23 +0100
> From: Nigel Deakin <nigel.deakin_at_oracle.com>
> Reply-To: jsr343-experts_at_jms-spec.java.net
> To: jsr343-experts_at_jms-spec.java.net
>
>
>
> This email covers a number of related issues, all covered in the
> attached document.
>
> Some time ago we discussed and agreed on a number of changes that we
> would like to see made to the EJB spec to
> standardise the way in which JMS MDBs were configured. Here are the
> JIRA issues:
>
> http://java.net/jira/browse/JMS_SPEC-30
> Define mandatory activation config properties for JMS MDBs
>
> http://java.net/jira/browse/JMS_SPEC-55
> Define a standard way to configure the connection factory used by a
> JMS MDB to consume messages
>
> http://java.net/jira/browse/JMS_SPEC-54
> Define a standard way to configure the destination on which a JMS MDB
> consumes messages
>
> I have spent quite a lot of time negotiating with the EJB spec lead
> about the details of these changes and have now come
> to provisional agreement, though these change have yet to be confirmed
> by the EJB EG. The attached document contains a
> summary of what we agreed. I would now like to bring these proposals
> back to the JMS EG for comments.
>
> Separately, also agreed in principle even longer ago that we should
> standardise the interface between a JMS provider and
> a Java EE application server by making it mandatory for a JMS vendor
> to provide a JCA resource adapter. Here is this
> JIRA issue:
>
> http://java.net/jira/browse/JMS_SPEC-25
> Standardise the interface between a JMS provider and a Java EE
> application server
>
> However if we're going to standardise on MDB configuration we also
> need to standardise on ActivationSpec properties. The
> attached document also contains some proposals to define a JMS
> resource adapter as part of the JMS specification. This
> essentially consists of moving the section on JMS resource adapter out
> of the JCA 1.6 spec, adding it to the JMS spec,
> and adding some additional properties.
>
> Finally, on 15th June I raised this new issue:
>
> http://java.net/jira/browse/JMS_SPEC-73
> Define how messages from a topic are delivered to clustered
> application server instances
>
> I made some provisional proposals to address this here
>
http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2012-06/message/7
>
> I haven't received any comments on that email. However since these
> proposals involve the standardisation of an
> additional ActivationSpec property, and the container making varius
> pieces of information available to the resource
> adapter, I thought it helpful to combine these proposals within this
> document as well.
>
> So please have a look at the attached document and make any comments.
> I'm not setting a deadline for comments but it
> would be really helpful if you could have a look within the next week
> or so. If it's not obvious why I've made a
> particular proposal please do ask and I'll try to explain.
>
> I know we're approaching the vacation season, and it's the 4th July
> next Wednesday as well.
>
> If this EG is generally happy with this document I plan to turn this
> document (except for the parts that go into the EJB
> spec) into a new chapter for the JMS spec.
>
> Thanks,
>
> Nigel
>
>
>
>
> [attachment "MDBAndRAConfiguration.pdf" deleted by Jeremy
> Bauer/Rochester/IBM]