I think the internal consensus is to have it in java:comp. But I'm
waiting for the JMS spec lead to confirm.
-marina
Jeremy Bauer wrote:
> 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]
>
>