Hi Marina,
WebSphere provides a deployment mode that allows applications which
contain client jars to be deployed on the server. When an application
client is started, the java: namespace and the comp, module, and app
contexts are hosted on the server. Since the application may have modules
running on both the client and server, binding inAppClientContainer in
java:global or java:app will report the incorrect value in one of the
environments.
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Date: 07/17/2012 04:23 PM
Subject: [ejb-spec users] [jsr345-experts] Re: Fwd: Proposals for
MDB and RA standardisation (JMS_SPEC-30,55,54,25,73)
Hi Jeremy,
Thank you for the detailed comments.
* 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.)
This property was intended to be an indication that the component is
running in an ACC, not on the server. What are your concerns about the
federated deployment modes that WebSphere supports?
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]