[MQ-279] Allow consumer close from any thread, including from a message listener on its own consumer Created: 12/Feb/13  Updated: 27/Mar/13  Resolved: 22/Feb/13

Status: Closed
Project: mq
Component/s: broker-core, jms-client
Affects Version/s: 5.0-RI (Sprint 9 - 27)
Fix Version/s: 5.0-RI (Sprint 10 - 28)

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

The JMS EG has agreed to revise the behaviour of consumer close to:

  • Allow consumer.close to be called from within a message listener
  • Allowing a consumer to be closed from any thread, even if it isn't the thread of control

This issue requests the implementation of this revised behaviour.

A summary of the change can be seen here, but for a definitive definition see the draft JMS specification and the draft API docs .



 Comments   
Comment by amyk [ 18/Feb/13 ]

implemented

Comment by amyk [ 26/Mar/13 ]

dev test cases
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer1
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer2
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer2_waitclose
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer3
~

Comment by mathim [ 27/Mar/13 ]

closing this issue as the dev tests written by amy pass in the tonga milestone test runs.

tonga/jmsclient/api/jms20/closeconsumer/closeconsumer1
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer2
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer2_waitclose
tonga/jmsclient/api/jms20/closeconsumer/closeconsumer3





[MQ-278] Modify JMSProducer#getPropertyNames to return an unmodifiable Set rather than an Enumeration Created: 08/Feb/13  Updated: 12/Apr/13  Resolved: 11/Feb/13

Status: Closed
Project: mq
Component/s: jms-client
Affects Version/s: 5.0-RI (Sprint 9 - 27)
Fix Version/s: 5.0-RI (Sprint 10 - 28)

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

The JMS expert group has changed the definition of JMSProducer#getPropertyNames to return an unmodifiable Set rather than an Enumeration.

This issue requests the implementation and testing of that change.



 Comments   
Comment by Nigel Deakin [ 11/Feb/13 ]

Now implemented

Comment by saradak [ 12/Apr/13 ]


Verified as part of CTS testing.





[MQ-270] Client ID value is not set correctly Created: 16/Jan/13  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Closed
Project: mq
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Meng Assignee: saradak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

CTS test(Client_checkClientIDOnDurableConnFactoryTest) failed at getting client id that is defined in the annotation for the
connection factory.

The test output file is at:
http://mq-hudson.us.oracle.com/job/mq-5.0-javaee7-cts-continuous/261/artifact/test_results/JTwork/com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client_check*

Test code is at: http://mq-hudson.us.oracle.com/job/mq-5.0-javaee7-cts-continuous/ws/javaeetck/src/com/sun/ts/tests/jms/ee20/resourcedefs/annotations/



 Comments   
Comment by Simon Meng [ 16/Jan/13 ]

It looks like com.sun.messaging.jms.ra.DirectConnectionFactory has problem. When using this class to create connection or context, it does not set the client ID attribute correctly.

Comment by Ed Bratt [ 17/Jan/13 ]

Please investigate

Comment by saradak [ 18/Jan/13 ]

This is a bug in CTS testcase.
It looks like CTS test is not closing the context after the appclient test is done. After that immediately calling servlet test which tries to create the context with the same clientid.





[MQ-269] Extend JMSRA to support unset clientId when subscriptionScope not set Created: 10/Jan/13  Updated: 12/Apr/13  Resolved: 19/Feb/13

Status: Closed
Project: mq
Component/s: mq-ra
Affects Version/s: 5.0-RI (Sprint 8 - 26)
Fix Version/s: 5.0-RI (Sprint 10 - 28)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MQ-193 Upgrade JMSRA to support the activati... Closed
Tags: jms-2-implementation

 Description   

The MQ 3.1.2 admin guide currently states here that "If the subscription is being created by the resource adapter for use by a message-driven bean (MDB), and client id is not set, then the resource adapter will set the client id to the name of the MDB."

This is indeed the case if the subscription is non-durable (though the clientId is actually set to the name of the MDB combined with any cluster name).

However if the subscription is durable then if clientId is unset (and the new subscriptionScope is also unset) then an exception is thrown during deployment (the code that does this is EndpointConsumer.setIsDurable)).

The product documentation is probably incorrect. However JMS 2.0 section 12.1 states "Setting this property [ clientId ] is always optional. If subscriptionScope is set (to instance or cluster) then this property must not be set."

This means that JMSRA needs to be changed to allow clientId to be unset in the case where subscriptionScope is unset and subscriptionDurability is Durable.

The simplest way to achieve this is to extend the existing code that generates clientId in the non-durable case to cover the durable case as well. This code is in EndpointConsumer._init. If the application server is not clustered then {{clientId} should be set to the name of the MDB (as passed in from GlassFish via a private API). If the application server is clustered then {{clientId} should be set to the name of the MDB combined with the "group name" which identifies the cluster.

Another way to achieve this is to use a shared durable subscription. That's a possibility (perhaps for the future), but I think it is safer and more consistent to make this consistent with non-durable subscriptions.

In addition, a check should be made to enforce the JMS 2.0 rule that clientId} must not be set if {{subscriptionScope is set.



 Comments   
Comment by David Zhao [ 19/Feb/13 ]

Fixed.

Comment by saradak [ 12/Apr/13 ]


Tests were added to the appserver sqe workspace to verify this bug.





[MQ-263] JMS destination definition in annotation should be enough, no need to define in web.xml Created: 22/Dec/12  Updated: 02/Jan/13  Resolved: 02/Jan/13

Status: Resolved
Project: mq
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arungupta Assignee: Ed Bratt
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

With GlassFish build 68, seems like a JMS destination needs to be defined using annotation and web.xml as:

<jms-destination>
        <name>java:global/jms/myQueue</name>
        <resource-adapter-name>jmsra</resource-adapter-name>
    </jms-destination>

and

@JMSDestinationDefinition(name = "java:global/jms/myQueue",
        resourceAdapterName = "jmsra",
        className = "javax.jms.Queue",
        destinationName="java:global/jms/myQueue",
        description="My Queue")
@WebServlet(name = "TestServlet", urlPatterns = {"/TestServlet"})
public class TestServlet extends HttpServlet {

If only the annotation is used then the following exception is thrown:

Caused by: java.lang.IllegalArgumentException: MQJMSRA_AS4001: setDestination:Invalid destination name=java:global/jms/myQueue
	at com.sun.messaging.jms.ra.ActivationSpec.setDestination(ActivationSpec.java:406)
	... 49 more

Only the annotation should be sufficient.



 Comments   
Comment by arungupta [ 26/Dec/12 ]

The correct annotation is:

@JMSDestinationDefinition(name = "java:global/jms/myQueue",
resourceAdapterName = "jmsra",
className = "javax.jms.Queue",
destinationName="queue1234",
description="My Queue")
@WebServlet(name = "TestServlet", urlPatterns =

{"/TestServlet"}

)

The destinationName attribute is the logical name, not the JNDI name. Will close the bug.

Comment by arungupta [ 26/Dec/12 ]

I'm not authorized to assign this bug to myself. Please close the bug.

Comment by Nigel Deakin [ 02/Jan/13 ]

Closing this issue as requested.

To clarify, the destinationName attribute is the same name as you would pass into the createQueue and createTopic methods on Session or JMSContext. This is referred to as the "provider-specific queue name" to distinguish it from the JNDI name.





[MQ-253] Extend connection consumer API to support shared durable and non-durable subscriptions Created: 06/Dec/12  Updated: 27/Mar/13  Resolved: 10/Dec/12

Status: Closed
Project: mq
Component/s: jms-client
Affects Version/s: 5.0-RI (JMS2.0), 5.0
Fix Version/s: 5.0-RI (Sprint 8 - 26), 5.0-RI (JMS2.0), 5.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-107 Extend connection consumer API to sup... Resolved
Tags: jms-2-implementation

 Description   

This issue has been logged to request the implementation of JMS_SPEC-107. This specifies two new methods on Connection:

ConnectionConsumer createSharedConnectionConsumer(
   Topic topic, String subscriptionName, String messageSelector, ServerSessionPool sessionPool, 
   int maxMessages)
ConnectionConsumer createSharedDurableConnectionConsumer(
   Topic topic, String subscriptionName, String messageSelector, ServerSessionPool sessionPool, 
   int maxMessages)


 Comments   
Comment by Nigel Deakin [ 10/Dec/12 ]

Now implemented (thanks, amyk).

Comment by amyk [ 27/Mar/13 ]

dev test cases -
tonga/jmsclient/serversession/serversessiondura_noclientid
tonga/jmsclient/serversession/serversession_ndshare
tonga/jmsclient/serversession/serversession_dshare

Comment by mathim [ 27/Mar/13 ]

closing this issue as the following tests have passed. thanks amy for the tests.

tonga/jmsclient/serversession/serversessiondura_noclientid
tonga/jmsclient/serversession/serversession_ndshare
tonga/jmsclient/serversession/serversession_dshare





Upgrade JMSRA to support the activation properties required by JMS 2.0 (MQ-193)

[MQ-251] Implement JMSRA activation properties clientId, subscriptionName and subscriptionScope Created: 27/Nov/12  Updated: 19/Feb/13  Resolved: 19/Feb/13

Status: Closed
Project: mq
Component/s: mq-ra
Affects Version/s: 5.0-RI (JMS2.0)
Fix Version/s: 5.0-RI (Sprint 10 - 28)

Type: Sub-task Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CONNECTOR_SPEC-1 New methods on MessageEndpointFactory... Resolved
depends on GLASSFISH-19347 Implement new methods on MessageEndpo... Resolved
depends on JMS_SPEC-30 Define mandatory activation config pr... Resolved
Tags: jms-2-implementation

 Comments   
Comment by Nigel Deakin [ 07/Feb/13 ]

When this issue was first logged it was a case of implementing

  • JMS_SPEC-73 (Define how messages from a topic are delivered to clustered application server instances) and
  • JMS_SPEC-30 (Define mandatory activation config properties clientId and subscriptionName)

Since then there has been a change of requirement. JMS_SPEC-73 has been deferred until a later version of JMS and so is not needed for MQ 5.0. I am therefore removing the dependency on this issue.

Please remove the features defined in JMS_SPEC-73, but make sure that the features defined in JMS_SPEC-30 remain.

Comment by David Zhao [ 19/Feb/13 ]

Defer it because subscriptionScope feature is removed from JMS 2.0 spec.

Comment by David Zhao [ 19/Feb/13 ]

This feature is removed from JMS 2.0 spec, so disable it temporally. It will be reopened in future releases if needed.





Upgrade JMSRA to support the activation properties required by JMS 2.0 (MQ-193)

[MQ-250] Implement JMSRA activation properties destinationLookup, connectionFactoryLookup Created: 27/Nov/12  Updated: 12/Apr/13  Resolved: 21/Feb/13

Status: Closed
Project: mq
Component/s: mq-ra
Affects Version/s: 5.0-RI (JMS2.0), 5.0
Fix Version/s: 5.0-RI (Sprint 10 - 28)

Type: Sub-task Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19558 Deploy MDB with any single property o... Resolved
depends on CONNECTOR_SPEC-4 Clarify whether the ResourceAdapter.e... Resolved
depends on GLASSFISH-19452 Add support for looking up JNDI resou... Closed
depends on JMS_SPEC-54 Define a standard way to configure th... Resolved
depends on JMS_SPEC-55 Define a standard way to configure th... Resolved
Tags: jms-2-implementation

 Comments   
Comment by Ed Bratt [ 07/Dec/12 ]

Pushed to Sprint 8 because of ongoing Spec. debate

Comment by David Zhao [ 11/Dec/12 ]

Fixed.

Comment by Nigel Deakin [ 17/Dec/12 ]

Note that although implementation has been completed, this issue is still dependent on changes to GlassFish to make this work in the case where the resources are in java:comp. GLASSFISH-19452 has been logged to capture this dependency.

Comment by David Zhao [ 04/Jan/13 ]

Reopen it for tracking when the dependency of GLASSFISH-19452 is resolved.

Comment by Nigel Deakin [ 22/Jan/13 ]

Added dependency on GLASSFISH-19558

Comment by David Zhao [ 21/Feb/13 ]

Fixed.

Comment by saradak [ 12/Apr/13 ]


Testcases were added to the appserver SQE workspace.





[MQ-249] Throw IllegalStateException when stop or close called from a message listener Created: 21/Nov/12  Updated: 12/Apr/13  Resolved: 06/Jan/13

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0-RI (JMS2.0), 5.0
Fix Version/s: 5.0-RI (Sprint 8 - 26), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: jigang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

This is a request for the implementation of JMS_SPEC-48.

The methods affected are

  • The Connection method stop
  • The Connection method close
  • The Session method close
  • The MessageConsumer method close
  • The JMSContext method stop
  • The JMSContext method close
  • The JMSConsumer method close

This issue covers both the Java SE client and the JMSRA application client. (It does not affect the Web or EJB containers)



 Comments   
Comment by jigang [ 06/Jan/13 ]

Fixed.Changeset:5785:de0eb1156702

Comment by amyk [ 10/Jan/13 ]

This jira does not include Consumer close methods
MessageConsumer method close
JMSConsumer method close

Comment by saradak [ 12/Apr/13 ]


Verified part of CTS testing.





[MQ-246] JMSRA support JMS 2.0 shared subscription API Created: 14/Nov/12  Updated: 16/Apr/13  Resolved: 27/Nov/12

Status: Closed
Project: mq
Component/s: mq-ra
Affects Version/s: 5.0-RI (JMS2.0)
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0)

Type: Task Priority: Major
Reporter: amyk Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on MQ-178 Implement new API to allow multiple c... Closed
Tags: jms-2-implementation

 Comments   
Comment by Ed Bratt [ 14/Nov/12 ]

This issue is to track changes to the JMSRA component, related to the JMS 2.0 shared subscription updates. Assigning to Nigel for now. (Split since multiple people are working this issue)

Comment by Nigel Deakin [ 19/Nov/12 ]

This issue covers the implementation of MQ-178 in the JMSRA client (both direct mode and TCP mode). For the avoidance of doubt this issue covers only the JMS API. It does NOT cover message-driven beans.

The APi required is exactly as defined for MQ-178. However when implementing this feature there is one additional issue to consider. This is how the new JMS 2.0 API for topic subscriptions interacts with JMSRA's existing "shared subscriptions in a cluster" feature.

The current "shared subscriptions in a cluster" feature (for applications using the JMS API)is defined in
http://docs.oracle.com/cd/E26576_01/doc.312/e24943/jmsra-properties.htm#gjzpg

Attempts by multiple connections to use the same client id do not result in an exception, provided that the connections are from different instances in the cluster.

Two or more subscriptions on the same topic with the same client id and (if the subscription is durable) the same durable subscription name are considered "shared"; that is, they are treated as a single subscription, with each message being sent to only one of the participating subscriptions.

The sharing of subscriptions relies on client id being set, not only for durable subscriptions (which always require client id) but for non-durable subscriptions (which do not normally require client id). If the subscription is being created by the resource adapter for use by a message-driven bean (MDB), and client id is not set, then the resource adapter will set the client id to the name of the MDB. However if the subscription is being created programmatically using the JMS API, and client id is not set, then an exception will be thrown.

Now that the JMS 2.0 has decided to keep the existing behaviour of createDurableSubscriber (and createSubscriber), there is no overlap between the two features.

  • createDurableSubscriber and createSubscriber will continue to behave as they do now, with the existing non-spec-complaint "shared subscriptions in a cluster" behaviour (which allows duplicate clientId and requires clientID to be set even for non-durable subscriptions).
  • createSharedConsumer and createSharedDurableConsumer will exhibit the new JMS 2.0 behaviour (and so not support old-style JMSRA shared subscriptions)
Comment by amyk [ 19/Nov/12 ]

updated Summary accordingly

Comment by amyk [ 20/Nov/12 ]

now implemented

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS & functional testing.





[MQ-243] JMSXDeliveryCount improvement on client side onMessage() retries Created: 11/Nov/12  Updated: 16/Apr/13  Resolved: 27/Nov/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 7 - 25)

Type: Task Priority: Major
Reporter: amyk Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to MQ-173 Implement JMSXDeliveryCount Closed
Tags: jms-2-implementation

 Description   

This covers
1. JMSXDeliveryCount improvement on client side onMessage() retries
2. dev test work for #1 and for MQ-173



 Comments   
Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS testing.





[MQ-240] Implement modified exceptions on JMSContext Created: 07/Nov/12  Updated: 18/Apr/13  Resolved: 27/Nov/12

Status: Closed
Project: mq
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 7 - 25)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-106 Methods on JMSContext that are disall... Resolved
Tags: jms-2-implementation

 Description   

JMS_SPEC-106 proposes that those methods which may not be used if the JMSContext is injected should throw a IllegalStateRuntimeException rather than a JMSRuntimeException if called on a JMSContext which has injected.

This issue requests the implementation of that feature.



 Comments   
Comment by Nigel Deakin [ 14/Nov/12 ]

Please note that this is an extremely small change!

Comment by David Zhao [ 27/Nov/12 ]

Checked into glassfish trunk with revision 57124.

Comment by saradak [ 18/Apr/13 ]


Verified as part of CTS testing.





[MQ-236] Broker support JMS2.0 mandatory JMSXDeliveryCount Created: 01/Nov/12  Updated: 12/Apr/13  Resolved: 09/Nov/12

Status: Closed
Project: mq
Component/s: broker-core
Affects Version/s: 5.0-RI (JMS2.0)
Fix Version/s: 5.0-RI (Sprint 6 - 24), 5.0-RI (JMS2.0)

Type: Task Priority: Major
Reporter: amyk Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-42 Make support for JMSXDeliveryCount ma... Resolved
Related
is related to MQ-173 Implement JMSXDeliveryCount Closed
Tags: jms-2-implementation

 Description   

see Summary



 Comments   
Comment by amyk [ 02/Nov/12 ]

Minimum work has been done on broker side so that MQ-173 can progress

Comment by Ed Bratt [ 06/Nov/12 ]

Fixed typo in summary field (JMSXDeliveryCount).

Comment by amyk [ 09/Nov/12 ]

now implemented

Comment by saradak [ 12/Apr/13 ]


Verified as part of CTS testing.





[MQ-233] Implement API to allow an app server or resource adapter to obtain a XAResource from a JMSContext Created: 30/Oct/12  Updated: 27/Mar/13  Resolved: 13/Dec/12

Status: Closed
Project: mq
Component/s: jms-client
Affects Version/s: None
Fix Version/s: 5.0-RI (Sprint 8 - 26), 5.0-RI (JMS2.0), 5.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-105 Provide API to allow an app server or... Resolved
Tags: jms-2-implementation

 Description   

This issue requests the implementation of JMS_SPEC-105

Implementation of this issue should not start until JMS_SPEC-105 has been approved by the JMS 2.0 expert group and added to the specification.



 Comments   
Comment by Nigel Deakin [ 07/Dec/12 ]

Now implemented but not yet tested.

(Also need to review value of containerType passed in to the XAJMSContext constructor)

Comment by Nigel Deakin [ 13/Dec/12 ]

Now implemented and tested.





[MQ-230] Enhance JMSRA to include cluster name in a generated subscription name Created: 29/Oct/12  Updated: 05/Dec/12  Resolved: 14/Nov/12

Status: Closed
Project: mq
Component/s: mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (JMS2.0), 5.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-103 A JMS 2.0 resource adapter needs to b... Closed
Tags: jms-2-implementation

 Description   

JMS_SPEC-103 proposes that the subscription name generated by a resource adapter should be composed of (1) a name which uniquely identifies the deployed MDB within thin the cluster as well as (2) a name which uniquely identifies the application server cluster.

MQ-193 already covers the implementation of (1). This issue requests implementation of (2).

Implementation work should not begin until JMS_SPEC_103 has been incorporated in the JMS 2.0 specification.

Implementation may also be dependent on the addition of a new feature to the Java EE platform specification to make the cluster name available to a resource adapter.



 Comments   
Comment by Nigel Deakin [ 14/Nov/12 ]

Since implementation of MQ-193 has not started yet I am going to merge this issue with that one.

Closing this issue (as a duplicate of MQ-193).





[MQ-229] Implementing noLocal behavior for shared non-durable subscription Created: 26/Oct/12  Updated: 16/Apr/13  Resolved: 19/Nov/12

Status: Closed
Project: mq
Component/s: broker-core, jms-client
Affects Version/s: 5.0-RI (JMS2.0)
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0)

Type: Task Priority: Major
Reporter: amyk Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-40 Allow multiple consumers to be create... Resolved
Tags: jms-2-implementation

 Description   

Ensure that MQ implements noLocal argument behavior on creation of shared non-durable subscription as defined in JMS_SPEC-40.



 Comments   
Comment by amyk [ 19/Nov/12 ]

implemented

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS testing.





[MQ-228] Implement new name and behaviour for the JMSConsumer methods receivePayload and receivePayloadNoWait Created: 26/Oct/12  Updated: 12/Apr/13  Resolved: 17/Dec/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0-RI (JMS2.0), 5.0
Fix Version/s: 5.0-RI (Sprint 8 - 26)

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-102 Make JMSConsumer.receivePayload metho... Closed
Tags: jms-2-implementation

 Description   

JMS_SPEC-102 proposes renaming the JMSConsumer methods receivePayload(Class<T> c), receivePayload(Class<T> c, long timeout) and receivePayloadNoWait(Class<T> c) to receiveBody(Class<T> c), receiveBody(Class<T> c, long timeout) and receiveBodyNoWait(Class<T> c), and changing throw behaviour slightly.

This issue requests the implementation of that feature.

Implementation work should not begin until JMS_SPEC-102 is approved by the expert group.



 Comments   
Comment by Nigel Deakin [ 19/Nov/12 ]

This is now implemented with the exception of the case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE. Currently the message is auto-acknowledged, whereas the JMS 2.0 API requires that the JMS provider behaves as if the unsuccessful call to receiveBody had not occurred and delivers the message again (without setting the redelivery flag) before any subsequent messages. Will leave this issue open until this is implemented.

Also, the behaviour after a MessageFormatRuntimeException is thrown in the CLIENT_ACKNOWLEDGE and transacted cases needs to be tested.

Comment by Nigel Deakin [ 06/Dec/12 ]

The case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE is now handled in the Java SE client and in JMSRA in TCP mode. However this case is still not handled correctly in JMSRA direct mode.

New tests have been added to check that a MessageFormatRuntimeException has the correct behaviour (in respect of message delivery) in all modes except JTA.

Remaining tasks:

  • Add support for the case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE in JMSRA direct mode. (Tests already written).
  • Add tests for JTA transactions (both TCP and direct modes)

Will leave this issue open until this is implemented.

Comment by Nigel Deakin [ 17/Dec/12 ]

Now fully implemented and tested.

Comment by saradak [ 12/Apr/13 ]


Verified as part of the CTS testing.





[MQ-226] Implement new method Message.getBody and Message.isBodyAssignableTo Created: 26/Oct/12  Updated: 12/Apr/13  Resolved: 19/Nov/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0-RI (JMS2.0), 5.0
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-101 New methods Message.getBody(Class<T> ... Resolved
Tags: jms-2-implementation

 Description   

This issue requests the implementation of the new JMS 2.0 methods Message.getBody and Message.isBodyAssignableTo that have been proposed in JMS_SPEC-101.

Note that implementation should not commence until JMS_SPEC-101 has been approved by the JMS expert group.



 Comments   
Comment by Nigel Deakin [ 26/Oct/12 ]

Adding dependency on JMS_SPEC-101

Comment by Nigel Deakin [ 19/Nov/12 ]

Now implemented and tested.

Comment by saradak [ 12/Apr/13 ]


Verified as part of CTS testing.





[MQ-212] JMS 2.0 4.6.2.2 when async send thread throws exception Created: 21/Sep/12  Updated: 16/Apr/13  Resolved: 24/Sep/12

Status: Closed
Project: mq
Component/s: jms-client
Affects Version/s: None
Fix Version/s: 5.0-RI (Sprint 4 - 22), 5.0-RI (JMS2.0)

Type: Improvement Priority: Major
Reporter: amyk Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

This is to adjust the implementation to conform latest JMS 2.0 specification clarification in 4.6.2.2. Exceptions

"If an exception is encountered during the call to the send method then an appropriate exception should be thrown in the thread that is calling the send method. In this case the JMS provider must not invoke the CompletionListener's onCompletion or onException method."



 Comments   
Comment by amyk [ 24/Sep/12 ]

It's now implemented

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS testing.





[MQ-211] Implement simplified API for JMS 2.0 (phase 2) Created: 18/Sep/12  Updated: 27/Mar/13  Resolved: 19/Nov/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: None
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0), 5.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on MQ-176 Implement simplified API for JMS 2.0 Closed
Related
is related to MQ-178 Implement new API to allow multiple c... Closed
Tags: jms-2-implementation

 Description   

This issue covers the second phase of the implementation of the JMS 2.0 simplified API (JMS_SPEC-64).

Most of this feature was implemented in MQ-176. However the following aspects remain:

AutoCloseable (dependent on MQ-191)
Multiple consumers on a topic subscription (dependent on MQ-178)
Don't auto-acknowledge messages when "payload receive" methods fail with a ClassCastException



 Comments   
Comment by Nigel Deakin [ 19/Nov/12 ]

Support for AutoCloseable has now been added.

Support for multiple consumers on a topic subscription will be provided by MQ-178 and MQ-246.

Updating the "payload receive" methods to handle invalid class exceptions will be provided by MQ-228.

This issue is therefore no longer needed and can be closed.





[MQ-210] CTS GlassFish+EMBEDDED mode broker: durableTopicEmptyStringSelTest_from_ejb fail Created: 17/Sep/12  Updated: 12/Apr/13  Resolved: 17/Sep/12

Status: Closed
Project: mq
Component/s: broker-core
Affects Version/s: 4.1, 4.2, 4.3, 4.4, 4.4u1, 4.4u2, 4.5, 4.5.1, 4.5.2
Fix Version/s: 5.0-RI (Sprint 4 - 22), 5.0-RI (JMS2.0)

Type: Bug Priority: Major
Reporter: amyk Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

The following CTS failures are reported by Sarada when running CTS7 with MQ in embedded mode in GlassFish

> FAILED........com/sun/ts/tests/jms/core/selectorTopic/MsgSelectorTopicTests.java#durableTopicEmptyStringSelTest_from_ejb
> FAILED........com/sun/ts/tests/jms/core/selectorTopic/MsgSelectorTopicTests.java#durableTopicEmptyStringSelTest_from_jsp
> FAILED........com/sun/ts/tests/jms/core/selectorTopic/MsgSelectorTopicTests.java#durableTopicEmptyStringSelTest_from_servlet



 Comments   
Comment by amyk [ 17/Sep/12 ]

It's now fixed.

Comment by saradak [ 12/Apr/13 ]


Verified the bug.





[MQ-197] JMS TCK test queueRequestorExceptionTests fail Created: 28/Aug/12  Updated: 12/Apr/13  Resolved: 04/Sep/12

Status: Closed
Project: mq
Component/s: jms-client
Affects Version/s: 4.1, 4.2, 4.3, 4.4, 4.4u1, 4.4u2, 4.5, 4.5.1, 4.5.2
Fix Version/s: 5.0-RI (Sprint 3 - 21), 5.0-RI (JMS2.0)

Type: Bug Priority: Major
Reporter: amyk Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-78 JMS implementation of QueueRequestor ... Resolved
Tags: jms-2-implementation

 Description   

The javadoc documents QueueRequestor construstor
/*

  • ......
  • @exception InvalidDestinationException if an invalid queue is specified.
    */

public
QueueRequestor(QueueSession session, Queue queue) throws JMSException {



 Comments   
Comment by Nigel Deakin [ 04/Sep/12 ]

Now fixed.

New tonga tests added:
tonga/jmsclient/api/QueueRequestor/TestQueueRequestorWithNullQueue
tonga/jmsclient/api/TopicRequestor/TestTopicRequestorWithNullTopic

Comment by saradak [ 12/Apr/13 ]


Verified the bug.





[MQ-193] Upgrade JMSRA to support the activation properties required by JMS 2.0 Created: 22/Aug/12  Updated: 12/Apr/13  Resolved: 22/Feb/13

Status: Closed
Project: mq
Component/s: mq-ra
Affects Version/s: None
Fix Version/s: 5.0-RI (Sprint 10 - 28)

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Dependency
depends on MQ-269 Extend JMSRA to support unset clientI... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MQ-250 Implement JMSRA activation properties... Sub-task Closed David Zhao  
MQ-251 Implement JMSRA activation properties... Sub-task Closed David Zhao  
Tags: jms-2-implementation

 Description   

JMSRA needs to be upgraded to support the activation properties required by JMS 2.0 chapter 12 "Resource adapter"

This defines the activation properties destinationLookup, connectionFactoryLookup, clientId, subscriptionName and shareSubscriptions

In addition, if a durable subscription is specified but shareSubscriptions is not set then a suitable value must automatically be generated.



 Comments   
Comment by Ed Bratt [ 04/Sep/12 ]

As discussed

Comment by Nigel Deakin [ 24/Oct/12 ]

Assigning to David, as discussed. Will send some notes on implementation directly.

Comment by Nigel Deakin [ 10/Jan/13 ]

Making MQ-193 a dependency of this issue.

Comment by David Zhao [ 22/Feb/13 ]

Fixed.

Comment by saradak [ 12/Apr/13 ]


Verified the bug.





[MQ-191] Migrate the MQ 5.0 codebase to compile, build, test and run with Java 7 Created: 09/Aug/12  Updated: 12/Apr/13  Resolved: 08/Nov/12

Status: Closed
Project: mq
Component/s: build
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 6 - 24)

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Jill Sato
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19181 Upgrade the GlassFish codebase to req... Resolved
blocks MQ-169 Make Connection and other interfaces ... Closed
Tags: jms-2-implementation

 Description   

This task covers the work required to migrate the MQ 5.0 codebase to compile, build, test and run with Java 7.

This is dependent on GlassFish 4.0 making the same change.



 Comments   
Comment by Jill Sato [ 04/Sep/12 ]

I have a hudson job that:

  • Compiles MQ 5.0 source and tests with JDK7,
  • Starts broker,
  • Runs putback.list (jdk7)
  • Stops broker

http://gf-hudson.us.oracle.com/hudson/view/MQ/job/mq-5.0-build-dev-jdk7/

However, the official RE builds will continue to use JDK6 until GF 4.0 moves to JDK7 or we'll be blocked from integrating into GF.

Comment by Jill Sato [ 08/Nov/12 ]

build and running tests with jdk7.

Comment by saradak [ 12/Apr/13 ]


Verified the bug.





[MQ-188] Migrate the MQ 5.0 codebase to implement the JMS 2.0 interfaces Created: 23/Jul/12  Updated: 28/Mar/13  Resolved: 04/Sep/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 2 - 20), 5.0-RI (JMS2.0), 5.0

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MQ-166 Implement Delivery Delay Closed
blocks MQ-169 Make Connection and other interfaces ... Closed
blocks MQ-171 New methods to replace Session.create... Closed
blocks MQ-172 Implement two new Connection.createS... Closed
blocks MQ-174 Implement new API to send a message w... Closed
blocks MQ-176 Implement simplified API for JMS 2.0 Closed
blocks MQ-177 Implement injection of JMSContext obj... Closed
blocks MQ-178 Implement new API to allow multiple c... Closed
Tags: jms-2-implementation

 Description   

This issue covers the following tasks:

  • Replace the JMS 1.1 API classes used in the MQ build with an unreleased snapshot of the JMS 2.0 API classes
  • Add new dummy methods methods as needed to ensure that the MQ source and tests both compile
  • Release the API jar, source jar and javadoc jar into Maven Central so that it can be used by GlassFish


 Comments   
Comment by Nigel Deakin [ 21/Aug/12 ]

Add dependency on Java 7

Comment by Nigel Deakin [ 22/Aug/12 ]

Now complete except for making Connection, Session, MessageConsumer, MessageProducer and QueueBrowser implement AutoCloseable, which is not possible until MQ and GlassFish has been upgraded to use Java 7.

Comment by Nigel Deakin [ 22/Aug/12 ]

Adding dependency on Java 7

Comment by Nigel Deakin [ 04/Sep/12 ]

I am going to mark this as fixed even though the Java 7 dependent aspects have not been implemented, since the Java 7 dependent aspects aspects are covered by MQ-169.

Comment by Nigel Deakin [ 04/Sep/12 ]

Removing dependency on Java 7.





[MQ-185] Migrate community build to Maven Created: 11/Jul/12  Updated: 12/Apr/13  Resolved: 04/Sep/12

Status: Closed
Project: mq
Component/s: build
Affects Version/s: 5.0-RI (JMS2.0)
Fix Version/s: 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Ed Bratt Assignee: Jill Sato
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: jms-2-implementation

 Description   

Migrate community build to Maven. Will almost certainly continue to rely on some Ant, but will provide better alignment with GlassFish build



 Comments   
Comment by Jill Sato [ 04/Sep/12 ]

I'd like to call this the open source build instead of community build.
The open source build now builds with maven.

Comment by saradak [ 12/Apr/13 ]


Open source & RI builds now build with Maven.





[MQ-184] Topic subscription matching time/QueueBrowser in message delivery delay Created: 11/Jul/12  Updated: 16/Apr/13  Resolved: 21/Sep/12

Status: Closed
Project: mq
Component/s: broker-core
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 4 - 22), 5.0-RI (JMS2.0)

Type: Task Priority: Major
Reporter: amyk Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-44 New API to specify delivery delay Resolved
Tags: jms-2-implementation

 Description   

This is for implementation adjustment needed when the JMS_SPEC-44 clarifies following regarding the message delivery delay

  • Topic subscription matching time
  • QueueBrowser


 Comments   
Comment by amyk [ 21/Sep/12 ]

It is now implemented

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS testing.





[MQ-178] Implement new API to allow multiple consumers to be created on the same topic subscription Created: 11/May/12  Updated: 16/Apr/13  Resolved: 06/Dec/12

Status: Closed
Project: mq
Component/s: broker-core, jms-client
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-40 Allow multiple consumers to be create... Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
blocks MQ-246 JMSRA support JMS 2.0 shared subscrip... Closed
Related
is related to MQ-211 Implement simplified API for JMS 2.0 ... Closed
Tags: jms-2-implementation

 Description   

Implement JMS_SPEC-40



 Comments   
Comment by amyk [ 16/Jul/12 ]

similar feature already exist in OpenMQ when working in GlassFish

Comment by Ed Bratt [ 04/Sep/12 ]

Removed from Sprint 4. Will re-map after JavaOne effort is completed.

Comment by amyk [ 01/Nov/12 ]

temporarily paused due to higher priority MQ-236

Comment by amyk [ 09/Nov/12 ]

now implemented

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS testing.





[MQ-177] Implement injection of JMSContext objects (Phase 1) Created: 11/May/12  Updated: 17/Apr/13  Resolved: 07/Sep/12

Status: Closed
Project: mq
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-18899 Implement support for Java EE platfor... Resolved
depends on MQ-176 Implement simplified API for JMS 2.0 Closed
depends on JMS_SPEC-70 Define annotations for injecting Mess... Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
blocks GLASSFISH-19004 Implement injection of JMSContext obj... Resolved
Tags: jms-2-implementation

 Description   

Implement the injection of JMS Context objects, as specified in JMS_SPEC-70.

This issue is logged here as a placeholder, as it probably requires changes to GlassFish rather than MQ.



 Comments   
Comment by Ed Bratt [ 11/Jul/12 ]

Reassigning to David. I expect there will be other dependent Issues in the GlassFish project.

Comment by Nigel Deakin [ 15/Aug/12 ]

Added dependency on GLASSFISH-18899

Comment by Nigel Deakin [ 15/Aug/12 ]

The initial implementation of this feature will support the scope defined in the JMS 2.0 Early Draft, which is "request scope with a separate JMSContext for each injection point".

A separate issue will be created to cover the final implementation of this feature to support the different scope defined in the JMS 2.0 Public Draft

Renaming this issue as "phase 1" to clarify.

Comment by Nigel Deakin [ 15/Aug/12 ]

Added dependency on MQ-176

Comment by David Zhao [ 07/Sep/12 ]

This has been resolved by checkin revision 55828 to glassfish trunk.

Comment by David Zhao [ 17/Apr/13 ]

Verified by CTS jms cditests.





[MQ-176] Implement simplified API for JMS 2.0 Created: 11/May/12  Updated: 17/Apr/13  Resolved: 18/Sep/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 3 - 21), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-64 Define simplified JMS API Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
blocks MQ-177 Implement injection of JMSContext obj... Closed
blocks MQ-211 Implement simplified API for JMS 2.0 ... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MQ-187 Integrate JMS 2.0 API JAR Sub-task Closed Nigel Deakin  
Tags: jms-2-implementation

 Description   

Implement JMS_SPEC-64. This is the simplified API, but excluding injection.



 Comments   
Comment by Nigel Deakin [ 21/Aug/12 ]

Slipping from "Sprint 2-20" to "Sprint 3-21".

Comment by Nigel Deakin [ 30/Aug/12 ]

Now complete except for the following:

  • Async send (dependent on MQ-174)
  • AutoCloseable (dependent on MQ-191)
  • Multiple consumers on a topic subscription (dependent on MQ-178)
  • Don't auto-acknowledge messages when "payload receive" methods fail with a ClassCastException
Comment by Ed Bratt [ 04/Sep/12 ]

Removed master issue from Sprint 3. Remainder of work to be mapped after JavaOne effort completed.

Comment by Nigel Deakin [ 06/Sep/12 ]

Added implementation for Async send. However this still won't work until MQ-174 is implemented.

Comment by Nigel Deakin [ 18/Sep/12 ]

MQ-174 is now implemented (that's why it's shown with an overstrike) and so async send in the simplified API now works (and is tested).

Comment by Nigel Deakin [ 18/Sep/12 ]

I am marking this issue as resolved singe it is 95% finished. A new issue MQ-211 has been created to cover the remaining 5%.

Comment by Nigel Deakin [ 17/Apr/13 ]

Now closing this issue as JMS 2.0 has been released.





[MQ-175] support optional clientId when creating a JMS 2.0 shared durable subscription Created: 11/May/12  Updated: 12/Apr/13  Resolved: 03/Aug/12

Status: Closed
Project: mq
Component/s: broker-core
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 2 - 20), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-40 Allow multiple consumers to be create... Resolved
Tags: jms-2-implementation

 Description   

Implementing optional clientid aspect of JMS_SPEC-40 for creating JMS 2.0 shared durable subscription



 Comments   
Comment by amyk [ 03/Aug/12 ]

This feature has been implemented in 5.0 build3-h

Comment by amyk [ 21/Nov/12 ]

updated Summary accordingly due to latest update on JMS 2.0 spec JMS_SPEC-40

Comment by saradak [ 12/Apr/13 ]


Verified the bug.





[MQ-174] Implement new API to send a message with async acknowledgement from server Created: 11/May/12  Updated: 12/Apr/13  Resolved: 14/Sep/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 4 - 22), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-43 New API to send a message with async ... Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
Tags: jms-2-implementation

 Description   

Implement JMS_SPEC-43



 Comments   
Comment by Ed Bratt [ 11/Jul/12 ]

Reassigning to Amy for preliminary implementation

Comment by amyk [ 10/Aug/12 ]

This feature has now been implemented in MQ 5.0 (build4-c). If any spec update that requires implementation adjustement, it will be tracked by separate jira (see MQ-212)

Comment by saradak [ 12/Apr/13 ]


Verified as part of CTS testing.





[MQ-173] Implement JMSXDeliveryCount Created: 11/May/12  Updated: 12/Apr/13  Resolved: 11/Nov/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 7 - 25), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-42 Make support for JMSXDeliveryCount ma... Resolved
Related
is related to MQ-236 Broker support JMS2.0 mandatory JMSXD... Closed
is related to MQ-243 JMSXDeliveryCount improvement on clie... Closed
Tags: jms-2-implementation

 Description   

Implement JMS_SPEC-42



 Comments   
Comment by amyk [ 11/Nov/12 ]

David's client side basic support for JMSXDeliveryCount has been checked in.
The remaining work
1. JMSXDeliveryCount improvement on client side onMessage() retries
2. dev test work

will be covered by MQ-243

Comment by saradak [ 12/Apr/13 ]


Verified as part of CTS testing.





[MQ-172] Implement two new Connection.createSession() methods and ensure that existing method confirms with clarified specification Created: 11/May/12  Updated: 27/Mar/13  Resolved: 14/Aug/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 2 - 20), 5.0-RI (JMS2.0), 5.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-45 Clarify and improve Connection.create... Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
Tags: jms-2-implementation

 Description   

Ensure that the existing Session method createSession(boolean transacted, int acknowledgeMode) confirms with the behaviour clarified in JMS_SPEC-45.

Implement the two new Session methods defined in JMS_SPEC-45.



 Comments   
Comment by saradak [ 27/Mar/13 ]


Verified.





[MQ-171] New methods to replace Session.createDurableSubscriber() and return a MessageConsumer Created: 11/May/12  Updated: 27/Mar/13  Resolved: 14/Aug/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 2 - 20), 5.0-RI (JMS2.0), 5.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-51 New methods to replace Session.create... Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
Tags: jms-2-implementation

 Description   

Implement JMS_SPEC-51



 Comments   
Comment by saradak [ 27/Mar/13 ]


Verified.





[MQ-169] Make Connection and other interfaces implement AutoCloseable Created: 11/May/12  Updated: 17/Apr/13  Resolved: 06/Nov/12

Status: Closed
Project: mq
Component/s: jms-client, mq-ra
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 6 - 24)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19181 Upgrade the GlassFish codebase to req... Resolved
depends on JMS_SPEC-53 Make Connection and other interfaces ... Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
depends on MQ-191 Migrate the MQ 5.0 codebase to compil... Closed
Tags: jms-2-implementation, jms2-spec

 Description   

Implement JMS_SPEC-53



 Comments   
Comment by Nigel Deakin [ 09/Aug/12 ]

Removed target for "Sprint 2-20" because this feature is dependent on GlassFish and MQ migrating to Java 7, which will not take place until later.

Comment by Nigel Deakin [ 09/Aug/12 ]

Add dependency on MQ-191

Comment by Nigel Deakin [ 17/Apr/13 ]

Now done





[MQ-168] Implement clarified behaviour of noLocal arg when using createDurableSubscriber Created: 11/May/12  Updated: 16/Apr/13  Resolved: 26/Oct/12

Status: Closed
Project: mq
Component/s: broker-core
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (Sprint 6 - 24), 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-65 Clarify use of NoLocal arg when using... Resolved
Tags: jms-2-implementation

 Description   

Ensure that MQ follows the clarified interpretation of the noLocal argument for createDurableSubscriber, as defined in JMS_SPEC-65.



 Comments   
Comment by amyk [ 16/Jul/12 ]

implemented

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS testing.





[MQ-166] Implement Delivery Delay Created: 09/May/12  Updated: 16/Apr/13  Resolved: 30/Jun/12

Status: Closed
Project: mq
Component/s: broker-core
Affects Version/s: 5.0
Fix Version/s: 5.0-RI (JMS2.0)

Type: New Feature Priority: Major
Reporter: Ed Bratt Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-44 New API to specify delivery delay Resolved
depends on MQ-188 Migrate the MQ 5.0 codebase to implem... Closed
Tags: jms-2-implementation

 Description   

Implementation JMS_SPEC-44



 Comments   
Comment by amyk [ 30/Jun/12 ]

Implemented in 5.0 build3-e based on current JMS 2.0 specification (JMS_SPEC-44). Future work for any pending spec clarification in JMS 2.0 JMS_SPEC-44 will be covered by separate jira issues (see MQ-184)

Comment by saradak [ 16/Apr/13 ]


Verified as part of CTS & functional testing.





[GLASSFISH-20165] Final integration for JMS RI, to version 2.0 Created: 04/Apr/13  Updated: 17/Apr/13  Due: 15/Apr/13  Resolved: 17/Apr/13

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Ed Bratt Assignee: Jill Sato
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, jms-2-implementation

 Description   

Tracking issue for final JMS integration. Any show-stopper bugs will be linked to this issue. As of this date, the only change planned is to bump the revision to 2.0. Corresponding maven artifacts as well as RI binary and source bundles will be created from this build.

Information for the 4.0 bug review process:

What is the impact on the customer of the bug?
Should be minimal if no other issues are attached.

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

Required to bring the API serial ID to 2.0

What is the cost/risk of fixing the bug?

Minimal. Tests have already been performed to assure this build will complete as planned.

Is there an impact on documentation or message strings?

No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

MQ QA will verify, prior to final integration into GlassFish RI / 4.0

Which is the targeted build of 4.0 for this fix?

Build 86 (RC2)



 Comments   
Comment by michael.y.chen [ 04/Apr/13 ]

This is approved. I thought Nigel wants to integ during build 85 or build 86 rather than build 84 since he wants to see the ballot results for other specs.

Comment by Ed Bratt [ 04/Apr/13 ]

This will be build 86. I have corrected the description

Comment by Jill Sato [ 04/Apr/13 ]

I just want to clarify that for the "final" JMS integration, we will be updating:
MQ 5.0 b15
and
JMS 2.0

Comment by Jill Sato [ 17/Apr/13 ]

JMS 2.0 (final) and MQ 5.0 b14 has been integrated into GF.





[GLASSFISH-19895] JMS resource configuration annotations and deployment descriptor elements changes: use of className Created: 15/Mar/13  Updated: 21/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19894 JMS resource configuration annotation... Resolved
Tags: jms-2-implementation

 Description   

The JMS API will soon be updated to add a new element interfaceName to the annotations JMSConnectionFactoryDefinition and JMSDestinationDefinition.

The Java EE schema will also soon be updated to add a new element <interface-name> to the deployment descriptor elements <jms-connection-factory> and <jms-destination>.

The initial implementation of these changes is defined in GLASSFISH-19894. However once that has been done, the following additional handling is required for JMSDestinationDefinition/<jms-destination>.

Normally the className/<class-name> element is not used and should be ignored, since interfaceName/<interface-name> is sufficient to identify the <admin-object> element in the resource adapter's ra.xml which defines the managed connection factory class name.

However the connector spec allows the case where ra.xml contains two <admin-object>> elements with the same interface. In this case the className/<class-name> element should be used to determine which <admin-object>> element to use.

Note that for JMSConnectionFactoryDefinition/<jms-connection-factory>, no further changes are needed to the handling of these definitions beyond those defined in GLASSFISH-19894. className/<class-name> should always be ignored.



 Comments   
Comment by Simon Meng [ 19/Mar/13 ]

The new attribute is interfaceName. Update the issue description accordingly.

Comment by Simon Meng [ 20/Mar/13 ]

Fix at revision 60613

Comment by Simon Meng [ 21/Mar/13 ]

When updating MDB runtime info, it uses className, the new attribute interfaceName should be used here.
Committed revision 60664 to fix this issue.





[GLASSFISH-19894] JMS resource configuration annotations and deployment descriptor elements changes: new attribute interfaceName Created: 15/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19895 JMS resource configuration annotation... Resolved
Tags: jms-2-implementation

 Description   

The JMS API will soon be updated to add a new element interfaceName to the annotations JMSConnectionFactoryDefinition and JMSDestinationDefinition.

The Java EE schema will also soon be updated to add a new element <interface-name> to the deployment descriptor elements <jms-connection-factory> and <jms-destination>.

This requires the following changes to the processing of these definitions in GlassFish:

1. The required interface should be obtained from interfaceName/<iinterface-name> rather than className/<class-name> as previously.

2. The className/<class-name> elements should now be ignored. (A separate issue will be logged to handle supporting the cases where className/<class-name> is used.)

3. In the case of JMSConnectionFactoryDefinition and <jms-connection-factory>, if interfaceName/<interface-name> is not specified then a value of javax.jms.Connectionfactory should be used.



 Comments   
Comment by Simon Meng [ 19/Mar/13 ]

The new attribute is interfaceName. Update the summary and description accordingly.

Comment by Simon Meng [ 20/Mar/13 ]

Fix at revision 60613





[GLASSFISH-19890] Handling of JMS resource configuration annotations and deployment descriptor elements should use jmsra if resource adapter not specified Created: 15/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b81

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

This issue relates to the JMS resource configuration annotations JMSConnectionFactoryDefinition and JMSDestinationDefinition and to the corresponding deployment descriptor elements <jms-connection-factory> and <jms-destination>.

If the resource adapter is not specified (using the resourceAdapter annotation element or the <resource-adapter> deployment descriptor element) then the jmsra resource adapter should be used by default. Previously this would have been an error.

Note that this change can be implemented immediately with no need to wait for any changes to the JMS API or to the Java EE schema.



 Comments   
Comment by Simon Meng [ 20/Mar/13 ]

Fix at revision 60613





[GLASSFISH-19872]  GlassFish does not correctly delist connections which are closed when CDI TransactionScope ends Created: 14/Mar/13  Updated: 13/Apr/13  Resolved: 13/Apr/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, jms-2-implementation

 Description   

I think I have found a bug in the enlistment/delistment of connections which are created using the new JMSContext injection CDI extension.

Here's a quick summary:
1. This concerns the case when an injected JMSContext has transaction scope.
2. Run a simple CMT business method that uses an injected JMSContext
3. When the business method completes the transaction is committed and the connection closed. The XAResource is committed and its connection returned to the pool, but something goes wrong with its delistment from the TM.
4. We then wait for idle-timeout-in-seconds seconds to pass
5. Then call the business method again. When the transaction is started the TM thinks the XAresource used in the previous call is still enlisted, and so calls start(). However since its connection has been (quite correctly) destroyed by the pool manager, this fails with an exception.

Here is the session bean:

@TransactionManagement(TransactionManagementType.CONTAINER) 
@Stateless
public class CMBean1 {

    @Inject
    @JMSConnectionFactory("jms/ConnectionFactory")
    JMSContext context;

    @Resource(mappedName="jms/MY_QUEUE")
    Queue queue;

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void method5() {
	System.out.println("CMBean1.method5() entry");
	JMSProducer producer = context.createProducer();
	System.out.println("Sending message [Message 1]");
        producer.send(queue,"Message 1");

      	System.out.println("CMBean1.method5() exit");
    }
}

To reproduce this, deploy the above bean and call its business method. I reproduced this using glassfish-4.0-b80-03_13_2013. I also turned on the following logging:

com.sun.messaging.jms.ra.DirectXAResource.level=FINE
javax.jms.Connection.mqjmsra.level=FINE

The first time it is called it appears to work fine. Here's an edited extract from the server log for that operation. We'll refer to this in a moment.

INFO:   CMBean1.method5() entry
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) Start   (GlobalTransactionID=[B@3f6f1925, BranchQualifier=[B@16dbecac) 
        (Flags: TMNOFLAGS ), connectionId=5976344228131155712
FINE:   MQJMSRA_DC1101: connectionId=5976344228131155712:createSession():isTransacted=false:acknowledgeMode=1
INFO:   Sending message [Message 1]
INFO:   CMBean1.method5() exit
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) End     (GlobalTransactionID=[B@3f6f1925, BranchQualifier=[B@16dbecac) 
        (Flags: TMNOFLAGS TMSUCCESS ), connectionId=5976344228131155712
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) Commit  (GlobalTransactionID=[B@3f6f1925, BranchQualifier=[B@16dbecac)  
        (onePhase=true), connectionId=5976344228131155712
FINE:   MQJMSRA_DC1101: connectionId=5976344228131155712:close():
INFO:   Running caseJ 1 completed

Now we wait until the connections in the pool reach their idle-timeout-in-seconds. To make this easy to reproduce I had previously set the idle-timeout-in-seconds to 2 seconds.

Now we call the bean's business method again. This throws an exception. The (first) exception logged in the server log, together with nearby logging, is:

INFO:   Running caseJ 2
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) Start   
(GlobalTransactionID=[B@65982356, BranchQualifier=[B@67381735) (Flags: TMNOFLAGS ), connectionId=5976344228131155712
SEVERE:   startTransaction (XA) on JMSService:jmsdirect failed for connectionId:5976344228131155712
due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsservice.JMSServiceException:
startTransaction: connection ID not found: 5976344228131155712
WARNING:   JTS5041: The resource manager is doing work outside a global transaction
javax.transaction.xa.XAException
	at com.sun.messaging.jms.ra.DirectXAResource.sendStartToBroker(DirectXAResource.java:836)
	at com.sun.messaging.jms.ra.DirectXAResource.start(DirectXAResource.java:792)
	at com.sun.jts.jta.TransactionState.startAssociation(TransactionState.java:341)
	at com.sun.jts.jta.TransactionImpl.enlistResource(TransactionImpl.java:212)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.enlistResource(JavaEETransactionImpl.java:660)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistXAResource(JavaEETransactionManagerSimplified.java:1277)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistResource(JavaEETransactionManagerSimplified.java:368)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistComponentResources(JavaEETransactionManagerSimplified.java:1299)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistComponentResources(JavaEETransactionManagerSimplified.java:487)
	at com.sun.ejb.containers.EJBContainerTransactionManager.startNewTx(EJBContainerTransactionManager.java:312)
	at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:248)
	at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4451)
	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1939)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy314.method5(Unknown Source)
	at beans.__EJB31_Generated__CMBean1__Intf____Bean__.method5(Unknown Source)
	at servlets.NewServlet.caseBug(NewServlet.java:121)
	at servlets.NewServlet.processRequest(NewServlet.java:52)
	at servlets.NewServlet.doGet(NewServlet.java:82)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:176)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
Caused by: com.sun.messaging.jmq.jmsservice.JMSServiceException: startTransaction: connection ID not found: 5976344228131155712
	at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.checkConnectionId(IMQDirectService.java:2521)
	at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.startTransaction(IMQDirectService.java:1535)
	at com.sun.messaging.jms.ra.DirectXAResource.sendStartToBroker(DirectXAResource.java:811)
	... 47 more

It is obvious that something has gone wrong with the enlistment/delistment of resources since this that trace shows that the container is calling XAResource.start when the transaction is being started by the container. At this point no bean code has been executed and there should be no resources enlisted (registered) with the transaction manager.

However the logging shows that when the second transaction is being started, the transaction manager is calling XAResource.start on the same XAResource that was used in the previous transaction, even though the previous transaction has been committed and the connection has been closed (from the perspective of the application).

Look for where DirectXAResource (1635975195) is logged. The big number {[(1635975195)}} is a hashcode used to identify the XAResource instance.

More detailed analysis

Further investigation confirms that when the first transaction was committed by the container, after XAResource.end and XAResource.commit were called, the injected JMSContext scope ends and JMSContext.close is called. This calls Connection.close(), as shown in the above log. Using the debugger I have confirmed that the Connection has broadcast the required javax.resource.spi.ConnectionEvent.CONNECTION_CLOSED event which the container's ConnectionEventListener has received and uses to delist the resource. (Of course calling Connection.close() doesn't physically connection, it simply returns it to the pool).

Then, when idle-timeout-in-seconds is reached, the connection is physically closed by the container by calling the destroy method on the ManagedConnection.

Next, we call the bean's business method a second time. The CMT transaction is started by the container, which causes the TM to call start on all enlisted resources. At this point there shouldn't be any resources to enlist. However the TM somehow still has a reference to the XAResource that was used in the previous transaction and calls start. Since the underlying connection has been closed, this throws an exception. The error that is thrown is

SEVERE:   startTransaction (XA) on JMSService:jmsdirect failed for connectionId:5976344228131155712 
due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsservice.JMSServiceException: 
startTransaction: connection ID not found: 5976344228131155712

which means that start is called even though the connection is closed.

Steps to reproduce
I have created a NetBeans project which allows this bug to be demonstrated easily. It can be downloaded from http://java.net/projects/jms-spec/downloads/download/GlassFishIssue2.zip . Simply unzip this file, open it in NetBeans and deploy and run it. Wait for the browser to open, click on the link, and wait for the error. Then look at the server log.

If you don't to use NetBeans, the key files are:

  • src\java\beans\CMBean1.java - the session bean
  • src\java\servlets
    NewServlet
    - a simple servlet which calls the bean once, waits 3 seconds, and calls it again
  • setup\glassfish-resources.xml - defines the connection factory resource required by the application and sets its idle-timeout-in-seconds to 2.


 Comments   
Comment by Nigel Deakin [ 14/Mar/13 ]

I believe this bug is causing failures in the JMS CTS tests.

Comment by Nigel Deakin [ 21/Mar/13 ]

At the request of project management, setting fix version to 4.0 since this appears to cause CTS failures.

Comment by marina vatkina [ 26/Mar/13 ]

I think the issue is in the JMS container code, or in the JMS resource handling (check how JDBS connection timeouts are handled).

(I needed to call asadmin add-resources to add the jms/MY_QUEUE)

This is what's going on:

The enlist and delist for a single com.sun.messaging.jms.ra.DirectXAResource was done correctly and the resource became NOT_ASSOCIATED at the end of the 1st call.

On the 2nd call the enlist fails in preInvoke, but the TM code only logs this error (the change in v2 code from throwing exception to just logging it, is marked with bugid 4664284 - I'm not sure if we can find that old bug and the reason for the change now):

javax.transaction.xa.XAException
    at com.sun.messaging.jms.ra.DirectXAResource.sendStartToBroker(DirectXAResource.java:836)
    at com.sun.messaging.jms.ra.DirectXAResource.start(DirectXAResource.java:792)
    at com.sun.jts.jta.TransactionState.startAssociation(TransactionState.java:341)
    at com.sun.jts.jta.TransactionImpl.enlistResource(TransactionImpl.java:212)
...
Caused by: com.sun.messaging.jmq.jmsservice.JMSServiceException: startTransaction: connection ID not found: 1403783500477313536
    at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.checkConnectionId(IMQDirectService.java:2521)
    at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.startTransaction(IMQDirectService.java:1535)

So the method starts execution, and when it tries to use the resource, it fails with:

Caused by: com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown XID 6D6172696E612D7 (snip remainder)

But now the exception is propagated back to the caller, and there are also exceptions in postInvoke, which seems that the failure cause is different.

Comment by Nigel Deakin [ 27/Mar/13 ]

On the second call to the business method, when the transaction was started by the container,
the TM called XAResource.start on an obsolete (and destroyed) XAResource left over
from the previous call to the business method. Why was this? There should be no resources
enlisted at this point.

You mention that this causes a connection ID not found. This is what I reported in my
initial report, and is because the pool timeout has destroyed the connection.

Comment by marina vatkina [ 27/Mar/13 ]

I suspect it is the same problem as GLASSFISH-19769

Comment by David Zhao [ 28/Mar/13 ]

At the first time the CMT bean is called, when the EJB container completes TX, it triggers JMSContext @PreDestroy and then it sends javax.resource.spi.ConnectionEvent.CONNECTION_CLOSED event to connector runtime. So connector delists resource according to JCA spec. But when delisting occurs, connector runtime gets com.sun.enterprise.web.WebComponentInvocation(ComponentInvocation) from InvocationManager. Why WebComponentInvocation here? I guess EjbInvocation might be expected because it is called from EJB container.

"http-listener-1(1)" daemon prio=6 tid=0x326bdc00 nid=0x1f24 runnable [0x33afe000]
   java.lang.Thread.State: RUNNABLE
	at org.glassfish.api.invocation.ComponentInvocation.getTransaction(ComponentInvocation.java:172)
	at com.sun.enterprise.resource.rm.ResourceManagerImpl.unregisterResource(ResourceManagerImpl.java:273)
	at com.sun.enterprise.resource.rm.ResourceManagerImpl.delistResource(ResourceManagerImpl.java:235)
	at com.sun.enterprise.resource.pool.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:379)
	at com.sun.enterprise.resource.allocator.ConnectorAllocator$ConnectionListenerImpl.connectionClosed(ConnectorAllocator.java:81)
	at com.sun.messaging.jms.ra.ConnectionEventListener.sendEvent(ConnectionEventListener.java:144)
	at com.sun.messaging.jms.ra.ManagedConnection.sendEvent(ManagedConnection.java:700)
	at com.sun.messaging.jms.ra.DirectConnection.close(DirectConnection.java:273)
	- locked <0x1204cf90> (a com.sun.messaging.jms.ra.DirectConnection)
	at com.sun.messaging.jms.ra.DirectConnection.close(DirectConnection.java:232)
	at com.sun.messaging.jmq.jmsclient.JMSContextImpl.close(JMSContextImpl.java:562)
	- locked <0x1204d098> (a java.util.HashSet)
	at org.glassfish.jms.injection.AbstractJMSContextManager.cleanup(AbstractJMSContextManager.java:117)
	- locked <0x11f4d2f0> (a org.glassfish.jms.injection.TransactedJMSContextManager)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
	at org.jboss.weld.annotated.runtime.RuntimeAnnotatedMembers.invokeMethod(RuntimeAnnotatedMembers.java:78)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:72)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:65)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:104)
	at org.jboss.weld.injection.producer.BeanInjectionTarget.preDestroy(BeanInjectionTarget.java:64)
	at org.glassfish.jms.injection.JMSCDIExtension$LocalBean.destroy(JMSCDIExtension.java:224)
	at org.jboss.weld.context.ForwardingContextual.destroy(ForwardingContextual.java:31)
	at org.glassfish.cdi.transaction.TransactionScopedBean.afterCompletion(TransactionScopedBean.java:78)
	at com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:146)
	at com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs.java:191)
	at com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2589)
	- locked <0x120434e0> (a com.sun.jts.CosTransactions.TopCoordinator)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:414)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	- locked <0x12043580> (a com.sun.jts.CosTransactions.TerminatorImpl)
	at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
	at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:185)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4477)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2011)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1981)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy179.method5(Unknown Source)
	at beans.__EJB31_Generated__CMBean1__Intf____Bean__.method5(Unknown Source)
	at servlets.NewServlet.caseBug(NewServlet.java:112)
	at servlets.NewServlet.processRequest(NewServlet.java:52)
	at servlets.NewServlet.doGet(NewServlet.java:82)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)

Comment by marina vatkina [ 28/Mar/13 ]

That might explain why the resource wasn't unregistered from the EJB - it was registered while it was the EjbInvocation. Now we need to trace why the invocation has changed - the EJB container is clearly on the invocation stack...

Comment by David Zhao [ 28/Mar/13 ]

Debuging it further, It shows the EjbInvocation was poped up from InvocationManager before doing TX processing. That explains why the connector runtime gets WebComponentInvocation instead of expected EjbInvocation when delisting jms resource.

Class com.sun.ejb.containers.BaseContainer, around line 2000,

BaseContainer.java
        if ( inv.ejb != null ) {
            // counterpart of invocationManager.preInvoke
            if (! inv.useFastPath) {
                invocationManager.postInvoke(inv);  <-- pop up EjbInvocation from InvocationManager.
                delistExtendedEntityManagers(inv.context);
            } else {
                doTxProcessing = doTxProcessing && (inv.exception != null);
            }
            
            try {
                if( doTxProcessing ) {
                    postInvokeTx(inv);  <-- process TX commitment, which will trigger jms resource delistment.
                }
            } catch (Exception ex) {
                _logger.log(Level.FINE, "ejb.postinvoketx_exception", ex);
                if (ex instanceof EJBException)
                    inv.exception = (EJBException) ex;
                else
                    inv.exception = new EJBException(ex);
            }
            
            releaseContext(inv);
        }
Comment by marina vatkina [ 01/Apr/13 ]

Adding __pm to both, the setup resource and the name for the injected resource worked!!!!

Now we need to test with the flag, and either just document its use in CAPS or figure out how to do it auto-magically.

Comment by Nigel Deakin [ 02/Apr/13 ]

Information for the 4.0 bug review process:

What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

This is a new feature and by definition is not a regression, has no impact on existing applications and has no impact on performance. It causes intermittent failure of the CTS test com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#beanUseCaseB.

A new user who uses this feature is likely to hit this bug. Bug GLASSFISH-19872 causes intermittent failures (exceptions) in an important use case. Bug GLASSFISH-19769 causes constant failures in a use case where the behaviour is not defined, but which users are nevertheless likely to encounter.

What is the cost/risk of fixing the bug?

The fix is already written so there is no cost in fixing this bug.

The fix is quite simple, It fixes both GLASSFISH-19872 (this issue) and GLASSFISH-19769 (which is a different use case).

It is moderately risky as it involves changes to the way in which injected JMSContext resources are handled by the transaction manager.

The fix to GLASSFISH-19872 is limited because it involves following an approach already adopted for database resources.

The fix to GLASSFISH-19769 is more risky as it introduces a significant difference between the way that injected and non-injected JMSContext objects behave in the use case described in that issue. Even though no spec defines what behaviour is required, the fact that the two modes behave completely differently in this use case may be considered undesirable.

Is there an impact on documentation or message strings?

This release does not include documentation so there is no impact on documentation.

The behaviour should however probably be documented on the GlassFish wiki.

This change has no impact on message strings.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

All JMS CTS tests. All GlassFish devtest involving injection of JMSContext objects.

Which is the targeted build of 4.0 for this fix?

TBD

Comment by Tom Mueller [ 02/Apr/13 ]

Approved for 4.0

Comment by David Zhao [ 10/Apr/13 ]

Committed __PM workaround by revision 61190.

Comment by michael.y.chen [ 10/Apr/13 ]

Is this fixed with revision 61190?

Comment by marina vatkina [ 10/Apr/13 ]

Partially.

Comment by marina vatkina [ 13/Apr/13 ]

Enable workaround to use __pm resource upon request: either via "-Dorg.glassfish.jms.skip-resource-registration-in-transaction=true" or choosing an __pm resource for the JMSContext.

See rev 61418 of trunk/main/appserver/jms/gf-jms-injection/src/main/java/org/glassfish/jms/injection/InjectableJMSContext.java





[GLASSFISH-19850] Can't inject JMSContext when security manager is enabled Created: 13/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: David Zhao Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19774 Add QuickLook test case for JMSContex... Closed
Tags: jms-2-implementation

 Description   

When I tried to add the JMS injection quicklook case, I found it failed in hudson jobs because security manager is enabled by default in hudson jobs.

It is easy to be reproduced: Enable the security manager for the domain by adding an option in the JVM Settings and then restart glassfish domain/server. We can see the following exception when accessing the EJB/Web with JMSContext injection (deployment succeeds).

[2013-03-13T14:04:01.787+0800] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1363154641787] [levelValue: 800] [[
Loading application [injection] at [/injection]]]

[2013-03-13T14:04:01.849+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1363154641849] [levelValue: 800] [[
injection was successfully deployed in 3,416 milliseconds.]]

[2013-03-13T14:04:02.910+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154642910] [levelValue: 800] [[
JACC Policy Provider: Failed Permission Check, context(injection/injection)- permission(("java.lang.reflect.ReflectPermission" "suppressAccessChecks"))]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [SEVERE] [ejb.stateless_ejbcreate_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 1000] [[
EJB5070: Exception creating stateless session bean : [SimpleEjb]]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB SimpleEjb, method: public boolean org.glassfish.tests.jms.injection.SimpleEjb.testRequestScope()]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 900] [[

javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:435)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2534)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1924)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy310.testRequestScope(Unknown Source)
at org.glassfish.tests.jms.injection._EJB31_GeneratedSimpleEjbIntf__Bean_.testRequestScope(Unknown Source)
at org.glassfish.tests.jms.injection.TestServlet.processRequest(TestServlet.java:80)
at org.glassfish.tests.jms.injection.TestServlet.doGet(TestServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:323)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:321)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:356)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:214)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1676)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:176)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:700)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
... 46 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:514)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
... 48 more
Caused by: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean org.glassfish.jms.injection.JMSCDIExtension$LocalBean@e5472a with class class org.glassfish.jms.injection.RequestedJMSContextManager using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:400)
at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:181)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:681)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:745)
at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76)
at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:108)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:58)
at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:29)
at org.jboss.weld.injection.producer.DefaultInstantiator.newInstance(DefaultInstantiator.java:67)
at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:84)
at org.glassfish.jms.injection.JMSCDIExtension$LocalBean.create(JMSCDIExtension.java:208)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:687)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:745)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:88)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:368)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
at org.jboss.weld.injection.producer.StatelessSessionBeanInjector.inject(StatelessSessionBeanInjector.java:50)
at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:133)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:96)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:251)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1701)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:475)
... 50 more
Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean org.glassfish.jms.injection.JMSCDIExtension$LocalBean@e5472a with class class org.glassfish.jms.injection.RequestedJMSContextManager using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:298)
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:253)
at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:100)
at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:157)
at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:147)
at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:49)
at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:57)
at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:53)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:358)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:396)
... 76 more
Caused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
at java.security.AccessController.checkPermission(AccessController.java:560)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:102)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:91)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:408)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:291)
... 88 more
]]



 Comments   
Comment by Nigel Deakin [ 19/Mar/13 ]

Setting fix version to 4.0. This bug currently causes failure of the JMSContext injection quicklook tests

Comment by jjsnyder83 [ 19/Mar/13 ]

JBoss is aware of the issue. See https://issues.jboss.org/browse/WELD-1242

Comment by David Zhao [ 10/Apr/13 ]

JJ,

I tried latest build with revision 67218, and can't reproduce the problem. Could you please verify if/when the defect is available to be closed?

-david

Comment by jjsnyder83 [ 10/Apr/13 ]

David,
Can you try it again on the latest trunk. Before you start quicklook do the following:

1) start GF
2) use asadmin to do the following 2 commands

asadmin create-module-config cdi-service
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=true

3) stop GF

4) run quicklook.

Then do it all over again except set the enable-implicit-cdi=false.

thanks,
JJ

Comment by David Zhao [ 11/Apr/13 ]

JJ,

I tried jms injection devtests and QL with both enable-implicit-cdi=true and enable-implicit-cdi=false against revision 61359, it worked fine and all passed.

-david





[GLASSFISH-19769] GlassFish does not correctly delist connections which are closed when CDI request ends Created: 05/Mar/13  Updated: 13/Apr/13  Resolved: 13/Apr/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, jms-2-implementation

 Description   

I think I have found a bug in the enlistment/delistment of connections which are created using the new JMSContext injection CDI extension.

Here's a quick summary:
1. This concerns the case when the injected JMSContext has request scope.
2. When the connection is created it is enlisted and saved in the EJBInvocation
3. When the business method returns and the CDI request ends, the connection is closed and the TM tries to remove it from its list of enlisted resources. However it looks in the WebComponentInvocation and so doesn't find it.
4. This means that the EJBInvocation still contains a resource, which causes an exception the next time the business method is called.

Here is the session bean in its simplest form:

@Inject JMSContext context;
@Inject UserTransaction ut;

void businessMethod(){
   JMSProducer producer = context.createProducer();
   ut.begin();
   // send message here (optional)
   ut.end();
}

To reproduce this, deploy and run the above bean. (Note that due to GLASSFISH-19760 you need to use glassfish-4.0-b78-02_26_2013 or earlier)

The first time it is called it appears to work fine. However the second time it is called the call to ut.begin() throws an internal exception which is caught at JavaEETransactionManagerSimplified.enlistComponentResources(ComponentInvocation) line: 1301. This causes XAResource.end() to be called before ut.begin() returns, which is obviously wrong.

This doesn't throw an exception to the bean unless you actually use the JMSProducer to send a message (within the transaction). This works the first time and fails the second time since the XAResource is in the wrong state.

More detailed analysis

Here's a more details analysis of the problem based on an examination using the debugger. This analysis may be incorrect, in which case please go back to the initial problem and assess what the cause it.

The call to context.createProducer() causes the {[JMSContext}}, and its underlying Connection, to be created. This follows the same code path as any other code in a session bean which creates a Connection: stack trace follows. The newly-created Connection's XAResource is registered with the transaction manager and added to a list of resources managed by the EJBInvocation. This has a context field which contains a SessionContextImpl. Its resources field is an ArrayList to which the new resource is added. Here's the stack trace for the point where this is done:

Daemon Thread [http-listener-1(3)] (Suspended (breakpoint at line 547 in JavaEETransactionManagerSimplified))	
	owns: RequestedJMSContextManager  (id=1839)	
	JavaEETransactionManagerSimplified.registerComponentResource(TransactionalResource) line: 547	
	ResourceManagerImpl.registerResource(ResourceHandle) line: 147	
	ResourceManagerImpl.enlistResource(ResourceHandle) line: 112	
	PoolManagerImpl.getResource(ResourceSpec, ResourceAllocator, ClientSecurityInfo) line: 211	
	ConnectionManagerImpl.getResource(int, PoolManager, ManagedConnectionFactory, ResourceSpec, Subject, ConnectionRequestInfo, ClientSecurityInfo, ConnectorDescriptor, boolean) line: 337	
	ConnectionManagerImpl.internalGetConnection(ManagedConnectionFactory, ResourcePrincipal, ConnectionRequestInfo, boolean, String, Object, boolean) line: 306	
	ConnectionManagerImpl.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo, String, Object) line: 195	
	ConnectionManagerImpl.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo, String) line: 170	
	ConnectionManagerImpl.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo) line: 165	
	DirectConnectionFactory._allocateConnection(String, String) line: 592	
	DirectConnectionFactory.createConnection(String, String) line: 266	
	DirectConnectionFactory.createConnection() line: 245	
	JMSContextImpl.<init>(ConnectionFactory, ContainerType, int) line: 206	
	DirectConnectionFactory.createContext(int) line: 291	
	RequestedJMSContextManager(AbstractJMSContextManager).createContext(String, JMSContextMetadata, ConnectionFactory) line: 78	
	RequestedJMSContextManager(AbstractJMSContextManager).getContext(String, String, JMSContextMetadata, ConnectionFactory) line: 93	
	RequestedJMSContextManager$Proxy$_$$_WeldClientProxy.getContext(String, String, JMSContextMetadata, ConnectionFactory) line: not available	
	InjectableJMSContext.delegate() line: 124	
	InjectableJMSContext(ForwardingJMSContext).createProducer() line: 61	
	BMBean1.method3() line: 37	
	GeneratedMethodAccessor105.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	EJBSecurityManager.runMethod(Method, Object, Object[]) line: 1038	
	EJBSecurityManager.invoke(Method, boolean, Object, Object[]) line: 1110	
	StatelessSessionContainer(BaseContainer).invokeBeanMethod(EjbInvocation) line: 4713	
	EjbInvocation.invokeBeanMethod() line: 630	
	AroundInvokeChainImpl.invokeNext(int, InterceptorManager$AroundInvokeContext) line: 822	
	EjbInvocation.proceed() line: 582	
	SessionBeanInterceptor.aroundInvoke(InvocationContext) line: 42	
	GeneratedMethodAccessor102.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	AroundInvokeInterceptor.intercept(InterceptorManager$AroundInvokeContext) line: 883	
	AroundInvokeChainImpl.invokeNext(int, InterceptorManager$AroundInvokeContext) line: 822	
	EjbInvocation.proceed() line: 582	
	_SystemInterceptorProxy_Serializable(SystemInterceptorProxy).doAround(InvocationContext, Method) line: 162	
	_SystemInterceptorProxy_Serializable(SystemInterceptorProxy).aroundInvoke(InvocationContext) line: 144	
	GeneratedMethodAccessor101.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	AroundInvokeInterceptor.intercept(InterceptorManager$AroundInvokeContext) line: 883	
	AroundInvokeChainImpl.invokeNext(int, InterceptorManager$AroundInvokeContext) line: 822	
	InterceptorManager.intercept(InterceptorManager$InterceptorChain, InterceptorManager$AroundInvokeContext) line: 369	
	StatelessSessionContainer(BaseContainer).__intercept(EjbInvocation) line: 4685	
	StatelessSessionContainer(BaseContainer).intercept(EjbInvocation) line: 4673	
	EJBLocalObjectInvocationHandler.invoke(Class, Method, Object[]) line: 212	
	EJBLocalObjectInvocationHandlerDelegate.invoke(Object, Method, Object[]) line: 88	
	$Proxy344.method3() line: not available	
	__EJB31_Generated__BMBean1__Intf____Bean__.method3() line: not available	
	NewServlet.caseG() line: 240	
	NewServlet.processRequest(HttpServletRequest, HttpServletResponse) line: 75	
	NewServlet.doGet(HttpServletRequest, HttpServletResponse) line: 113	
	NewServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 687	
	NewServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 790	
	StandardWrapper.service(ServletRequest, ServletResponse, Servlet) line: 1682	
	StandardWrapperValve.invoke(Request, Response) line: 318	
	StandardContextValve.invoke(Request, Response) line: 160	
	StandardPipeline.doInvoke(Request, Response, boolean) line: 734	
	StandardPipeline.invoke(Request, Response) line: 673	
	StandardHostValve.invoke(Request, Response) line: 176	
	CoyoteAdapter.doService(Request, Request, Response, Response, boolean) line: 357	
	CoyoteAdapter.service(Request, Response) line: 260	
	ContainerMapper.service(Request, Response) line: 188	
	ContainerMapper(HttpHandler).doHandle(Request, Response) line: 164	
	HttpServerFilter.handleRead(FilterChainContext) line: 175	
	ExecutorResolver$9.execute(Filter, FilterChainContext) line: 119	
	DefaultFilterChain.executeFilter(FilterExecutor, Filter, FilterChainContext) line: 273	
	DefaultFilterChain.executeChainPart(FilterChainContext, FilterExecutor, int, int, DefaultFilterChain$FiltersState) line: 200	
	DefaultFilterChain.execute(FilterChainContext) line: 134	
	DefaultFilterChain.process(Context) line: 112	
	ProcessorExecutor.execute(Context) line: 77	
	TCPNIOTransport.fireIOEvent(IOEvent, Connection, IOEventProcessingHandler) line: 820	
	AbstractIOStrategy.fireIOEvent(Connection, IOEvent, IOEventProcessingHandler, Logger) line: 113	
	WorkerThreadIOStrategy.run0(Connection, IOEvent, IOEventProcessingHandler) line: 115	
	WorkerThreadIOStrategy.access$100(Connection, IOEvent, IOEventProcessingHandler) line: 55	
	WorkerThreadIOStrategy$WorkerThreadRunnable.run() line: 135	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 564	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 544	
	DefaultWorkerThread(Thread).run() line: 722	

Subsequently UserTransaction.begin is called and all the XAResource}}s in the above {{ArrayList are enlisted by calling XAresource.start().

Then UserTransaction.end is called. Again the XAResource}}s in the above {{ArrayList are delisted by calling XAresource.end().

Finally the business method returns, and a short time later the CDI session context ends. This causes the injected JMSContext's "dispose" method to be called which calls connection.close.

As with any call to connection.close(), this broadcasts a javax.resource.spi.ConnectionEvent.CONNECTION_CLOSED event which the container's ConnectionEventListener receives and uses to delist the resource. This is done using JavaEETransactionManagerSimplified.unregisterComponentResource. This calls invMgr.getCurrentInvocation() to return the current invocation which returns a WebComponentInvocation. This has no resources and so the XAResource is not unregistered.

Here's the stack trace for the code which performs the call to JavaEETransactionManagerSimplified.unregisterComponentResource.

	JavaEETransactionManagerSimplified.unregisterComponentResource(TransactionalResource) line: 415	
	ResourceManagerImpl.unregisterResource(ResourceHandle, int) line: 274	
	ResourceManagerImpl.delistResource(ResourceHandle, int) line: 235	
	PoolManagerImpl.resourceClosed(ResourceHandle) line: 379	
	ConnectorAllocator$ConnectionListenerImpl.connectionClosed(ConnectionEvent) line: 81	
	ConnectionEventListener.sendEvent(int, Exception, Object) line: 144	
	ManagedConnection.sendEvent(int, Exception, Object) line: 692	
	DirectConnection.close(boolean) line: 273	
	DirectConnection.close() line: 232	
	JMSContextImpl.close() line: 524	
	RequestedJMSContextManager(AbstractJMSContextManager).cleanup() line: 118	
	GeneratedMethodAccessor104.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	SecureReflections$13.work() line: 267	
	SecureReflections$13(SecureReflectionAccess<T>).run() line: 52	
	SecureReflections$13(SecureReflectionAccess<T>).runAsInvocation() line: 137	
	SecureReflections.invoke(Object, Method, Object...) line: 263	
	WeldMethodImpl<T,X>.invoke(Object, Object...) line: 174	
	ManagedBean<T>(AbstractClassBean<T>).defaultPreDestroy(T) line: 389	
	ManagedBean$ManagedBeanInjectionTarget<T>.preDestroy(T) line: 182	
	ManagedBean<T>.destroy(T, CreationalContext<T>) line: 305	
	SerializableContextualImpl<C,I>(ForwardingContextual<T>).destroy(T, CreationalContext<T>) line: 31	
	HttpRequestContextImpl(AbstractContext).destroy(String) line: 128	
	HttpRequestContextImpl(AbstractContext).destroy() line: 142	
	HttpRequestContextImpl(AbstractManagedContext).deactivate() line: 41	
	HttpRequestContextImpl(AbstractBoundContext<S>).deactivate() line: 72	
	HttpRequestContextImpl.deactivate() line: 86	
	WeldListener.requestDestroyed(ServletRequestEvent) line: 103	
	WebModule(StandardContext).fireRequestDestroyedEvent(ServletRequest) line: 5251	
	StandardHostValve.postInvoke(Request, Response) line: 257	
	CoyoteAdapter.doService(Request, Request, Response, Response, boolean) line: 359	
	CoyoteAdapter.service(Request, Response) line: 260	
	ContainerMapper.service(Request, Response) line: 188	
	ContainerMapper(HttpHandler).doHandle(Request, Response) line: 164	
	HttpServerFilter.handleRead(FilterChainContext) line: 175	
	ExecutorResolver$9.execute(Filter, FilterChainContext) line: 119	
	DefaultFilterChain.executeFilter(FilterExecutor, Filter, FilterChainContext) line: 273	
	DefaultFilterChain.executeChainPart(FilterChainContext, FilterExecutor, int, int, DefaultFilterChain$FiltersState) line: 200	
	DefaultFilterChain.execute(FilterChainContext) line: 134	
	DefaultFilterChain.process(Context) line: 112	
	ProcessorExecutor.execute(Context) line: 77	
	TCPNIOTransport.fireIOEvent(IOEvent, Connection, IOEventProcessingHandler) line: 820	
	AbstractIOStrategy.fireIOEvent(Connection, IOEvent, IOEventProcessingHandler, Logger) line: 113	
	WorkerThreadIOStrategy.run0(Connection, IOEvent, IOEventProcessingHandler) line: 115	
	WorkerThreadIOStrategy.access$100(Connection, IOEvent, IOEventProcessingHandler) line: 55	
	WorkerThreadIOStrategy$WorkerThreadRunnable.run() line: 135	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 564	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 544	
	DefaultWorkerThread(Thread).run() line: 722	

Now consider what happens the next time the business method is called.

When the connection is created it is registered in the EJBInvocation. This appears to be the same object as in the previous call, and so already contains the XAResource from the previous call. As a result, the EJBInvocation now contains two XAResource objects, which appear to be identical.

Then, when UserTransaction.begin() is called, the JavaEETransactionManagerSimplified attempts to enlist both. This works fine for the first XAResource, and XAResource.start is called. However when it tries to enlist the second XAResource, since this is the same object the JavaEETransactionManagerSimplified detects that this has already been enlisted, and so throws a "java.lang.IllegalStateException: Wrong XAState: 0". This is caught further up in the stack, in a catch block in JavaEETransactionManagerSimplified.enlistComponentResources. This invokes some cleanup code which causes XAResource.end() to be called. Remember we're still in UserTransaction.begin() here. This means that when UserTransaction.begin() returns, the XAResource is not in the correct state for it to be used by JMS.



 Comments   
Comment by marina vatkina [ 05/Mar/13 ]

Is this a stateless or a stateful session bean?

Comment by Nigel Deakin [ 06/Mar/13 ]

Stateless. I've supplied a test case directly.

Comment by Nigel Deakin [ 14/Mar/13 ]

I've confirmed that I still see this bug with glassfish-4.0-b80-03_13_2013

Comment by Nigel Deakin [ 14/Mar/13 ]

Test case available at
http://java.net/projects/jms-spec/downloads/download/GLASSFISH-19769.zip

Comment by marina vatkina [ 26/Mar/13 ]

I think the problem is in the JMS code that does not unregister JMSContext from the resource list early enough. Here are the details:

1. Currently JMSContext is registered with the TM during JMSContextImpl.<init> (-> DirectConnectionFactory.createConnection call).
2. Registering means adding resource to the resource list, which in EJB container is the bean context instance.
3. The bean context instance is created when the bean is created, and they stay together until the instance is destroyed.
4. The bean context is associated with the current invocation until the bean method completes (postInvoke completes).
5. A JDBC connection is unregistered at the time of the connection.close() but there is no corresponding method on the JMSContext for the user to call.
6. Unregister call from the JMSContext when it comes it is too late because the context is cleared from the invocation. Which means that it can't be removed from the list. But remember that the context itself stays around so the resource list actually stays there...
7. On the next run step #1 is executed again, but it's a List, so we have 2 resources, the old one and the new one.
8. The old one is re-enlisted, and the new one throws an exception (because they both point to the same resource?)
9. It all goes upside-down after that...

Note, the list is completely cleared only when component is destroyed.

Comment by marina vatkina [ 27/Mar/13 ]

JMS team needs to decide what's next....

Comment by David Zhao [ 27/Mar/13 ]

In this case, the request scoped JMSContext looks like being destroyed at web moudle servlet request end, not at ejb module method end because it is not ejb remote method invocation. Per CDI spec, the request context is destroyed:

at the end of the servlet request, after the service() method, all doFilter() methods, and all requestDestroyed() and onComplete() notifications return,
after the web service invocation completes,
after the asynchronous observer notification completes,
after the EJB remote method invocation, asynchronous method invocation, timeout or message delivery completes, or
after the message delivery to the MessageListener completes.

This can be verified by adding breakpoint at @PreDestroy method of RequestedJMSContextManager.

Daemon Thread [http-listener-1(4)] (Suspended (breakpoint at line 111 in AbstractJMSContextManager))	
	owns: RequestedJMSContextManager  (id=422)	
	RequestedJMSContextManager(AbstractJMSContextManager).cleanup() line: 111	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	SecureReflections$13.work() line: 264	
	SecureReflections$13(SecureReflectionAccess<T>).run() line: 52	
	SecureReflections$13(SecureReflectionAccess<T>).runAsInvocation() line: 137	
	SecureReflections.invoke(Object, Method, Object...) line: 260	
	RuntimeAnnotatedMembers.invokeMethod(AnnotatedMethod<X>, Object, Object...) line: 78	
	DefaultLifecycleCallbackInvoker<T>.invokeMethods(List<AnnotatedMethod<? super T>>, T) line: 72	
	DefaultLifecycleCallbackInvoker<T>.preDestroy(T, Instantiator<T>) line: 65	
	BeanInjectionTarget<T>(BasicInjectionTarget<T>).preDestroy(T) line: 104	
	BeanInjectionTarget<T>.preDestroy(T) line: 64	
	JMSCDIExtension$LocalBean.destroy(Object, CreationalContext) line: 224	
	SerializableContextualFactory$DefaultSerializableContextual<C,I>(ForwardingContextual<T>).destroy(T, CreationalContext<T>) line: 31	
	HttpRequestContextImpl(AbstractContext).destroyContextualInstance(ContextualInstance<T>) line: 150	
	HttpRequestContextImpl(AbstractContext).destroy() line: 163	
	HttpRequestContextImpl(AbstractManagedContext).deactivate() line: 41	
	HttpRequestContextImpl(AbstractBoundContext<S>).deactivate() line: 72	
	HttpRequestContextImpl.deactivate() line: 88	
	WeldListener.requestDestroyed(ServletRequestEvent) line: 168	
	WebModule(StandardContext).fireRequestDestroyedEvent(ServletRequest) line: 5261	
	StandardHostValve.postInvoke(Request, Response) line: 255	
	CoyoteAdapter.doService(Request, Request, Response, Response, boolean) line: 359	
	CoyoteAdapter.service(Request, Response) line: 260	
	ContainerMapper.service(Request, Response) line: 188	
	ContainerMapper(HttpHandler).runService(Request, Response) line: 191	
	ContainerMapper(HttpHandler).doHandle(Request, Response) line: 168	
	HttpServerFilter.handleRead(FilterChainContext) line: 189	
	ExecutorResolver$9.execute(Filter, FilterChainContext) line: 119	
	DefaultFilterChain.executeFilter(FilterExecutor, Filter, FilterChainContext) line: 288	
	DefaultFilterChain.executeChainPart(FilterChainContext, FilterExecutor, int, int, DefaultFilterChain$FiltersState) line: 206	
	DefaultFilterChain.execute(FilterChainContext) line: 136	
	DefaultFilterChain.process(Context) line: 114	
	ProcessorExecutor.execute(Context) line: 77	
	TCPNIOTransport.fireIOEvent(IOEvent, Connection, IOEventProcessingHandler) line: 838	
	AbstractIOStrategy.fireIOEvent(Connection, IOEvent, IOEventProcessingHandler, Logger) line: 113	
	WorkerThreadIOStrategy.run0(Connection, IOEvent, IOEventProcessingHandler) line: 115	
	WorkerThreadIOStrategy.access$100(Connection, IOEvent, IOEventProcessingHandler) line: 55	
	WorkerThreadIOStrategy$WorkerThreadRunnable.run() line: 135	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 564	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 544	
	DefaultWorkerThread(Thread).run() line: 722	
Comment by marina vatkina [ 27/Mar/13 ]

JMSContext needs to be unregistered earlier or a new instance should not be created and registered...

Comment by marina vatkina [ 01/Apr/13 ]

It's the same problem as in GLASSFISH-19872 because adding __pm to both, the setup resource and the name for the injected resource worked!!!!

Comment by marina vatkina [ 03/Apr/13 ]

Reopening as this issue needs to be addressed separately

Comment by Tom Mueller [ 11/Apr/13 ]

Approved for 4.0 since the fix for GLASSFISH-19872 fixes this bug too and it is approved.

Comment by marina vatkina [ 13/Apr/13 ]

Fixed by storing ComponentInvocation at which JMSContextEntry was created with the JMSContextEntry.

Sending gf-jms-injection/pom.xml
Sending gf-jms-injection/src/main/java/org/glassfish/jms/injection/AbstractJMSContextManager.java
Sending gf-jms-injection/src/main/java/org/glassfish/jms/injection/InjectableJMSContext.java
Sending gf-jms-injection/src/main/java/org/glassfish/jms/injection/JMSContextEntry.java
Transmitting file data ....
Committed revision 61418.





[GLASSFISH-19760] Exception when deploying an application that injects a JMSContext Created: 01/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19774 Add QuickLook test case for JMSContex... Closed
Tags: jms-2-implementation

 Description   

If I deploy a session bean which injects a JMSContext I get an exception {[org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [JMSContext] with qualifiers [@Default] at injection point [[BackedAnnotatedField]}}

Here's an extract from the server log.

INFO: WELD-000900 2.0.0 (Beta4)
WARNING: Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled
WARNING: Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled
INFO: Loading application [TestGFInjectionBug] at [/TestGFInjectionBug]
SEVERE: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [JMSContext] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject servlets.NewServlet.context]
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:247)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:364)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:528)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:524)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:523)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
	at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
	at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:273)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:820)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [JMSContext] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject servlets.NewServlet.context]
	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:381)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:172)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:203)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:493)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:69)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:67)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	... 1 more

SEVERE: Exception while loading the app
WARNING: JCDI shutdown error
java.lang.IllegalStateException: Singleton not set for WebappClassLoader (delegate=true)
	at org.glassfish.weld.ACLSingletonProvider$ACLSingleton.get(ACLSingletonProvider.java:110)
	at org.jboss.weld.Container.instance(Container.java:54)
	at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:597)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:293)
	at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:123)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)

SEVERE: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [JMSContext] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject servlets.NewServlet.context]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [JMSContext] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject servlets.NewServlet.context]
	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:381)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:172)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:203)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:493)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:69)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:67)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by Nigel Deakin [ 01/Mar/13 ]

I have created a NetBeans project which may be used to reproduce the issue.

It may be downloaded here:
http://java.net/projects/jms-spec/downloads/download/TestGFInjectionBug.zip

This contains a servlet NewServlet which injects a JMSContext
(but doesn't actually cause it to be instantiated)

The war file is TestGFInjectionBug\dist\TestGFInjectionBug.war

Comment by jjsnyder83 [ 05/Mar/13 ]

There is a Weld Jira issue for this: https://issues.jboss.org/browse/WELD-1182

Comment by jjsnyder83 [ 10/Mar/13 ]

Committed revision 60274.

Comment by David Zhao [ 11/Mar/13 ]

I tested currently the @WeldGFExtension workaround doesn't work if I change nothing on JMS injection impl yet. It still throw the Unsatisfied dependencies exception.

[exec] remote failure: Error occurred during deployment: Exception while loading the app : CDI deployment failure:W
ELD-001408 Unsatisfied dependencies for type [JMSContext] with qualifiers [@Default] at injection point [[BackedAnnotate
dField] @Inject @JMSConnectionFactory @JMSSessionMode private org.glassfish.tests.jms.injection.SimpleEjb.jmsContext]. P
lease see server.log for more details.
[exec] Command deploy failed.

But if I remove the @WeldGFExtension workaround codes and register the JMS beans via JMSCDIExtension at AfterBeanDiscoveryEvent, It seems the InjectPoint bean cannot be resolved.

deploy-v3-impl-windows:
[exec] remote failure: Error occurred during deployment: Exception while loading the app : CDI definition failure:E xception List with 1 exceptions:
[exec] Exception 0 :
[exec] org.jboss.weld.exceptions.IllegalArgumentException: WELD-001405 Cannot inject [BackedAnnotatedParameter] Par ameter 1 of [BackedAnnotatedConstructor] @Inject public org.glassfish.jms.injection.InjectableJMSContext(InjectionPoint,
RequestedJMSContextManager, TransactedJMSContextManager) in a class which isnt a bean
[exec] at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.ja
va:66)
[exec] at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1015)
[exec] at org.jboss.weld.util.ForwardingBeanManager.createInjectionTarget(ForwardingBeanManager.java:201)
[exec] at org.glassfish.jms.injection.JMSCDIExtension.createLocalBean(JMSCDIExtension.java:66)
[exec] at org.glassfish.jms.injection.JMSCDIExtension.afterBeanDiscovery(JMSCDIExtension.java:71)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
[exec] at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
[exec] at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137
)
[exec] at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
[exec] at org.jboss.weld.annotated.runtime.InvokableAnnotatedMethod.invokeOnInstance(InvokableAnnotatedMethod.j
ava:82)
[exec] at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.j
ava:77)
[exec] at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:273)
[exec] at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:129)
[exec] at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:260)
[exec] at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:239)
[exec] at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:155)
[exec] at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:
44)
[exec] at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:116)
[exec] at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:101)
[exec] at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:69)
[exec] at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEven
t.java:38)
[exec] at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
[exec] at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:464)
[exec] at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:194)
[exec] at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
[exec] at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
[exec] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
[exec] at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
[exec] at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
[exec] at java.security.AccessController.doPrivileged(Native Method)
[exec] at javax.security.auth.Subject.doAs(Subject.java:356)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
[exec] at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
[exec] at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
[exec] at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.jav
a:234)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMe
thodInvocationHandlerFactory.java:81)
[exec] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaRe
sourceMethodDispatcher.java:133)
[exec] at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.do
Dispatch(JavaResourceMethodDispatcherProvider.java:152)
[exec] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJava
ResourceMethodDispatcher.java:101)
[exec] at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
[exec] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
[exec] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
[exec] at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:207)
[exec] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
[exec] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
[exec] at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
[exec] at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
[exec] at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
[exec] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
[exec] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:183)
[exec] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:859)
[exec] at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:321)
[exec] at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandServic
e.java:161)
[exec] at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
[exec] at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
[exec] at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
[exec] at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
[exec] at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
[exec] at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
[exec] at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
[exec] at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
[exec] Command deploy failed.
[exec] at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
[exec] at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
[exec] at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
[exec] at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
[exec] at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
[exec] at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
[exec] at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
[exec] at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrate
gy.java:135)
[exec] at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
[exec] at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
[exec] at java.lang.Thread.run(Thread.java:722)
[exec] Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-001405 Cannot inject [BackedAnnotatedParamete r] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.glassfish.jms.injection.InjectableJMSContext(Injection
Point, RequestedJMSContextManager, TransactedJMSContextManager) in a class which isnt a bean
[exec] at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDefinitionErrors(Validator.java:344)
[exec] at org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java
:39)
[exec] at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.ja
va:63)
[exec] ... 85 more
[exec] . Please see server.log for more details.

Comment by David Zhao [ 12/Mar/13 ]

Now it works by applying JJ's workaround in JMSCDIExtension: Use getInjectionTargetFactory instead of createInjectionTarget.





[GLASSFISH-19663] JMSConnectionFactoryDefinition and JMSDestinationDefinition resourceAdapterName attribute renamed Created: 11/Feb/13  Updated: 08/Mar/13  Resolved: 08/Mar/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b76_EE7MS5
Fix Version/s: 4.0_b80_EE7MS6

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

There's been yet another small change to the JMSConnectionFactoryDefinition and JMSDestinationDefinition annotations and to the <jms-connection-factor> and <jms-destination> deployment descriptor elements.

In the JMSConnectionFactoryDefinition and JMSDestinationDefinition annotations, the attribute resourceAdapterName has been renamed to resourceAdapter

In the Java EE 7 schema, the resource-adapter-name sub-element under the <jms-connection-factor> and <jms-destination> elements has been renamed resource-adapter

Please make whatever changes are necessary to GlassFish to handle this change.

You can view the updated Java EE schema at
https://svn.java.net/svn/glassfish~svn/trunk/schemas/javaee7/src/javaee_7.xsds

You can view the updated API at
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSConnectionFactoryDefinition.html
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSDestinationDefinition.html



 Comments   
Comment by Simon Meng [ 08/Mar/13 ]

Fix at revision 60046.





[GLASSFISH-19609] Connector runtime transforms a SecurityException into a ResourceAllocationException Created: 31/Jan/13  Updated: 01/Mar/13  Resolved: 01/Mar/13

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b72_EE7MS4
Fix Version/s: 4.0_b79

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

In our resource adapter (JMSRA) we want our implementation of ManagedConnectionFactory#createManagedConnection to handle a user/password error by throwing a javax.resource.spi.SecurityException, which is explicitly listed in the API as one of the exceptions which may be thrown.

http://docs.oracle.com/javaee/6/api/javax/resource/spi/ManagedConnectionFactory.html#createManagedConnection%28javax.security.auth.Subject,%20javax.resource.spi.ConnectionRequestInfo%29

However we have discovered that when this exception is passed through the connector runtime to ConnectionManager#allocateConnection this is turned into a javax.resource.spi.ResourceAllocationException. This is despite the API for this method also explicitly listing javax.resource.spi.SecurityException as one of the exceptions that can be thrown.

http://docs.oracle.com/javaee/6/api/javax/resource/spi/ConnectionManager.html#allocateConnection%28javax.resource.spi.ManagedConnectionFactory,%20javax.resource.spi.ConnectionRequestInfo%29

This means that the RA code which calls ConnectionManager#allocateConnection cannot handle this correctly. This is a problem cause the RA needs to know that the exception is security-related and throw a JMS-specific security exception. This is required to support JMS 1.1

The relevant stack of connector code is below:

 at com.sun.messaging.jms.ra.ManagedConnectionFactory.createManagedConnection(ManagedConnectionFactory.java:226)
 at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:160)
 at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
 at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1189)
 at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
 at com.sun.enterprise.resource.pool.ConnectionPool.addResource(ConnectionPool.java:282)
 at com.sun.enterprise.resource.pool.ConnectionPool.createResourceAndAddToPool(ConnectionPool.java:1512)
 at com.sun.enterprise.resource.pool.ConnectionPool.createResources(ConnectionPool.java:944)
 at com.sun.enterprise.resource.pool.ConnectionPool.initPool(ConnectionPool.java:230)
 at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:511)
 at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
 at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
 at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
 at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:337)
 at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:306)
 at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:207)
 at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:170)
 at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)

It looks as if the code that transforms the exception is as follows:

\workspace\trunk\main\appserver\connectors\connectors-runtime\src\main\java\com\sun\enterprise\resource\allocator\ConnectorAllocator.java (line 157-183)

public ResourceHandle createResource()

            throws PoolingException {
        try {
            ManagedConnection mc =
                    mcf.createManagedConnection(subject, reqInfo);
            ResourceHandle resource =
                    createResourceHandle(mc, spec, this, info);
            ConnectionEventListener l =
                    new ConnectionListenerImpl(resource);
            mc.addConnectionEventListener(l);
            return resource;
        } catch (ResourceException ex) {
            Object[] params = new Object[]{spec.getPoolInfo(), ex.toString()};
            _logger.log(Level.WARNING,"poolmgr.create_resource_error",params);
            if(_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE,"Resource Exception while creating resource",ex);
            }
            
            if (ex.getLinkedException() != null) {
                _logger.log(Level.WARNING,
                        "poolmgr.create_resource_linked_error", ex
                                .getLinkedException().toString());
            }
            throw new PoolingException(ex);
        }
    }

workspace\trunk\main\appserver\connectors\connectors-runtime\src\main\java\com\sun\enterprise\connectors\ConnectionManagerImpl.java (line 308-315)

 } catch (PoolingException ex) {
            Object[] params = new Object[]{poolInfo, ex};
            getLogger().log(Level.WARNING, "poolmgr.get_connection_failure", params);
            String i18nMsg = getLocalStrings().getString("con_mgr.error_creating_connection", ex.getMessage());
            ResourceAllocationException rae = new ResourceAllocationException(i18nMsg);
            rae.initCause(ex);
            throw rae;
        }


 Comments   
Comment by Nigel Deakin [ 11/Feb/13 ]

Please note that this fix is needed to resolve a CTS failure.

Comment by Jagadish [ 28/Feb/13 ]

Provided a fix such that SecurityException would be unwrapped.

svn log -v -r 59912
------------------------------------------------------------------------
r59912 | jr158900 | 2013-02-28 22:41:43 +0530 (Thu, 28 Feb 2013) | 4 lines
Changed paths:
M /trunk/main/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/ConnectionManagerImpl.java





[GLASSFISH-19561] Remove references to JMSConnectionFactoryDefinition maxIdleTime attribute Created: 21/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b73
Fix Version/s: 4.0_b71

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

JMS 2.0 has removed the maxIdleTime attribute from JMSConnectionFactoryDefinition, and Java EE 7 has removed the <max-idle-time> sub-element from the <jms-connection-factory> element.

Please make sure that GlassFish does not contain references to this property.



 Comments   
Comment by Simon Meng [ 24/Jan/13 ]

Fix at revision 58777





[GLASSFISH-19558] Deploy MDB with any single property of destinationLookup, mappedName and destination specified. Created: 19/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b70
Fix Version/s: 4.0_b71

Type: Bug Priority: Major
Reporter: David Zhao Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MQ-250 Implement JMSRA activation properties... Closed
Tags: jms-2-implementation

 Description   

With current jms implementation, if mappedName or <message-destination> in DD is not specified, whether or not destinationLookup/destination is specified in activationSpec is specified, the MDB deployment will fail by error message "missing destination JNDI name". This is incorrect.

It is expected that any single property of destinationLookup, mappedName and destination specified can take effect for sucessful MDB deployment. If all of them are provided, the desired overriding order should be "destinationLookup over destination, and destination over mappedName".

One more thing that can be enhanced is about the error message, which could be misleading: "missing destination JNDI name". It is proposed being changed to "MDB destination not specified".



 Comments   
Comment by David Zhao [ 24/Jan/13 ]

Fixed by revision 58778.





[GLASSFISH-19492] MDB @MessageDriven listens on Topic for @JMSDestinationDefinition className="javax.jms.Queue" Created: 03/Jan/13  Updated: 06/Jan/13  Resolved: 06/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b68_EE7MS3
Fix Version/s: 4.0_b71

Type: Bug Priority: Critical
Reporter: amyk Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by MQ-264 Async receiver does not receive the m... Closed
Tags: jms-2-implementation

 Description   

Please see Arun's async receiver sample (which is currently commented as not working in the following blog link) and analysis in MQ-264
https://blogs.oracle.com/arungupta/entry/simple_jms_2_0_sample



 Comments   
Comment by Nigel Deakin [ 03/Jan/13 ]

I have tried this in the debugger and agree that this appears to be the problem.

If you define a MDB which uses mappedName to refer to a queue resource created in the normal way (e.g. using glassfish-resources.xml) then ActivationSpec.setDestinationType() is called with a value of "javax.jms.Queue".

However if you define a MDB which uses mappedName to refer to a queue resource created using a @JMSDestinationDefinition annotation then ActivationSpec.setDestinationType() is NOT called. As a result the MDB creates a consumer on a topic (but the correct physical name).

So this seems to be an issue specifically with resources created using a @JMSDestinationDefinition annotation.

There is a workaround, which is to explicitly specify the destinationType activation property. Note that setting this property should not be necessary.

@MessageDriven(mappedName = "java:global/jms/myQueue", activationConfig =
 {@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")})
Comment by arungupta [ 03/Jan/13 ]

Tried the workaround in my simple sample and it worked.

Comment by Simon Meng [ 05/Jan/13 ]

Assume we create a jms destination resource via the following command:
asadmin create-jms-resource --restype javax.jms.Queue --property Name=myQueue jms/myQueue
The resource should be created successfully. It appears in domain.xml

In an application (a MDB), it also defines a jms destination by annotation

@JMSDestinationDefinition(name = "jms/myQueue",
resourceAdapterName = "jmsra",
className = "javax.jms.Queue",
destinationName="myQueue9",
description="My Queue9")

@MessageDriven(mappedName = "jms/myQueue")
public class MessageReceiverAsync implements MessageListener

{ .... }

When deploy a MDB, we need use the mappedName to find jms destination resource in domain.xml or EJbMessageBeanDescriptor. I need know the clear answer for the following questions:

1. If the mappedName does not start with "java:" prefix, whether need add "java:comp/env" prefix to match the resources.
2. If two jms destination resources have the same name (name does not start with "java:" prefix), the two resources are defined in both domain.xml and application, which resource should be used.

Comment by Simon Meng [ 06/Jan/13 ]

Fixed at revision 57990.





[GLASSFISH-19452] Add support for looking up JNDI resources from java:comp when performing endpoint activation Created: 17/Dec/12  Updated: 21/Feb/13  Resolved: 21/Feb/13

Status: Closed
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b67_ms7
Fix Version/s: 4.0_b77

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: amy.yang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CONNECTOR_SPEC-4 Clarify whether the ResourceAdapter.e... Resolved
blocks MQ-250 Implement JMSRA activation properties... Closed
Tags: jms-2-implementation

 Description   

This is a request to enhance GlassFish to allow JNDI resources (JMS connection factory and destination objects) to be looked up from java:comp when performing endpoint activation.

This currently causes an exception to be thrown.

This functionality is required CONNECTOR_SPEC-4



 Comments   
Comment by Jagadish [ 11/Jan/13 ]

This is related to making the naming context available during end point
activation.
Looking at all the upstream issues :
http://java.net/jira/browse/JMS_SPEC-55
http://java.net/jira/browse/JMS_SPEC-54
http://java.net/jira/browse/EJB_SPEC-43
http://java.net/jira/browse/EJB_SPEC-42
http://java.net/jira/browse/MQ-250

the expectation is that the connectionFactoryJndiName and
destinationLookup activation-config property values are made available
via JNDI lookup during end point activation.

Connector Spec so far has not defined anything about naming context
availability and is being clarified in the current iteration of the
specification (Connector 1.7) that naming context can be made available
during end point activation.

Connector specification / implementation does not define/do anything
specific w.r.t the "connectionFactoryJndiName", "destinationLookup"
activation-config property as these are protocols between MDB Container
and JMS RA.

Currently, there is no JNDI naming context setup when MDB Container
calls connector container to do end point activation.

Requesting EJB team (Srini) to evaluate making the naming context available before
calling connector container to setup the end point.
[Ref : org.glassfish.ejb.mdb.MessageBeanContainer, line 225 that sets up
the end point by calling "messageBeanClient_.setup(this)" ]

I would also assume that resources indicated by the "connectionFactoryJndiName" and
"destinationLookup" activation-config property values would be set as
part of this, if those resources are defined via the MDB application (eg: @JMSConnectionFactoryDefinition, @JMSDestinationDefinition).

To clarify this further :

JMS RA will be doing the lookup of the resources where the
resource-names are defined in the "activation-spec" configuration
properties by name "connectionFactoryJndiName" and "destinationLookup".
So, those resources should be made available in JNDI for JMS RA to
lookup.

These resources may be from :
a) vendor specific resources (eg: create-jms-resource --restype
Destination jms/foo)
b) A @JMSDestinationDefinition annotation defined in a component (eg: an
EJB) of the application that also has the MDB being deployed.

Comment by Jagadish [ 12/Feb/13 ]

Similar to the availability of naming (component) context during "endpointActivation", it is also required during "endpointDeactivation". While supporting this feature, please consider endpointDeactivation use-case also.

This was suggested and added sometime last week by the Connectors EG .
This is reflected in the latest specification submitted to JCP :
http://java.net/projects/connector-spec/downloads/download/connector-1_7-spec-final-with-change-bars.pdf

Reference :
Page 289 :
"The application server must make the application component environment
namespace of the endpoint (that is being activated), available to the resource adapter
during the call to the endpointActivation and endpointDeactivation
methods. The resource adapter may use this JNDI context to access other resources."

Comment by amy.yang [ 21/Feb/13 ]

implementation was checked in by r58995

Comment by amy.yang [ 21/Feb/13 ]

Closing





[GLASSFISH-19442]  @JMSConnectionFactoryDefinition ignores clientId attribute Created: 14/Dec/12  Updated: 16/Jan/13  Resolved: 16/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b47
Fix Version/s: 4.0_b71

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

If I define a JMS connection factory using the following annotation:

@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    clientId="myClientID",
    resourceAdapterName="jmsra",
    user="guest",
    password="guest"
)  

then inject it into my session bean using:

    @Resource(lookup = "java:global/jms/demoConnectionFactory")
    ConnectionFactory connectionFactory;

use it to create a connection

Connection connection = connectionFactory.createConnection();

and then report the clientid

String clientId = connection.getClientID();
System.out.println("ClientID = "+clientId);

I get a value of null printed,

However if I change the annotation to

@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    properties="clientId=myClientID",
    resourceAdapterName="jmsra",
    user="guest",
    password="guest"
)     

then the correct clientId is displayed.

Both ways to configure clientId should work.



 Comments   
Comment by Simon Meng [ 04/Jan/13 ]
@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    clientId="myClientIDAttribute",
    properties="clientId=myClientIDProperty",
    resourceAdapterName="jmsra",
    user="guest",
    password="guest"
)    

If clientId is defined in both annotation attribute and property list, which one takes effect?

Comment by Nigel Deakin [ 04/Jan/13 ]

I would suggest processing the "properties" attribute after the other attributes.

Comment by Simon Meng [ 05/Jan/13 ]

Fixed at revision 57972.

Comment by saradak [ 11/Jan/13 ]

Reopening the bug as test is still failing with latest glassfish build(b-71)after the fix.

CTS test(Client_checkClientIDOnDurableConnFactoryTest) failed at getting client id that is defined in the annotation for the
connection factory. This fixed the descriptor version but not the annotation version.

-Sarada

Comment by Simon Meng [ 11/Jan/13 ]

getClientID works fine with the reporter provide sample.
How to get the CTS code and run it? I need check the failed case.

Comment by Simon Meng [ 16/Jan/13 ]

@JMSConnectionFactoryDefinition works fine. The root cause is in MQ, relative bug is MQ-270.





[GLASSFISH-19441] ConnectionFactory created using @JMSConnectionFactoryDefinition does not use default credentials Created: 14/Dec/12  Updated: 05/Jan/13  Resolved: 05/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b67_ms7
Fix Version/s: 4.0_b71

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive JMS20Demo.zip     Text File server.log    
Tags: jms-2-implementation

 Description   

I have a simple application which defines a JMS connection factory using the following annotation:

@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    resourceAdapterName="jmsra"
)  

It then uses the following annotation to inject a connection factory:

    @Resource(lookup = "java:global/jms/demoConnectionFactory")
    ConnectionFactory connectionFactory;

and uses it to create a connection:

Connection connection = connectionFactory.createConnection();

This fails with

SEVERE: com.sun.messaging.jmq.auth.api.FailedLoginException: [B4051]: Forbidden guest

See attached server log for the full exception.

To reproduce the problem, unzip the attached Netbeans project and deploy in GlassFish (I used build 67). The navigate directly to http://localhost:8080/JMS20Demo/Servlet1?option=JavaEESenderOld and look in the server log.

The code itself is in the session bean JavaEESenderOld. Note that the same business method also creates a connection using a connection factory defined in glassfish-resources.xml. That works fine using the default credentials.

A quick analysis of the exception in the debugger suggests that if the connection factory is created using glassfish-resources.xml then the password used us "guest", but if the connection factory is created using @JMSConnectionFactoryDefinition then the password used is "", which is invalid.

If you explicitly set user and password in @JMSConnectionFactoryDefinition then it works fine. The problem is if user/password is not set. A quick analysis in the debugger suggests that JMSRA is passing a correct user/password to the connection pool (using a javax.resource.spi.ConnectionRequestInfo). However the password is getting overridden somewhere.

This example was demonstrated at JavaOne in October 2012, and so is a regression since then.



 Comments   
Comment by Nigel Deakin [ 02/Jan/13 ]

Confirmed that this is still an issue with glassfish-4.0-b70-12_31_2012.

This is a regression since glassfish-4.0-b56-09_24_2012.

Comment by Simon Meng [ 04/Jan/13 ]

@JMSConnectionFactoryDefinition(
name="java:global/jms/demoConnectionFactory",
className= "javax.jms.ConnectionFactory",
description="ConnectionFactory to use in demonstration",
properties=

{"UserName=myuser", "Password=mypassword"}

,
resourceAdapterName="jmsra",
user="guest",
password="guest"
)

If user and password are defined in both annotation attribute and property list, which one takes effect?

Comment by Simon Meng [ 05/Jan/13 ]

Fixed at revision 57972.





[GLASSFISH-19360] Update handling of JMS connection factory resource configuration metadata to match latest spec Created: 20/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.0_b64_EE7MS2

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

Since GLASSFISH-18900 was implemented the <jms-connection-factory> element (defined in the Java EE 7 schema) and the JMSConnectionFactoryDefinition annotation (defined in MQ) have changed.

The url and connectionTimeout elements have been removed from the JMSConnectionFactoryDefinition annotation

The connectionTimeout element has been removed from the <jms-connection-factory> element.

GlassFish's support for <jms-connection-factory> and JMSConnectionFactoryDefinition needs to be updated accordingly.



 Comments   
Comment by Nigel Deakin [ 20/Nov/12 ]

This needs to be done before MQ sprint 7 can be integrated into GlassFish.

Comment by Simon Meng [ 28/Nov/12 ]

Fixed at revision 57184.





[GLASSFISH-19347] Implement new methods on MessageEndpointFactory to support JMS 2.0 Created: 14/Nov/12  Updated: 28/Dec/12  Resolved: 28/Dec/12

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: dapeng_hu
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CONNECTOR_SPEC-1 New methods on MessageEndpointFactory... Resolved
blocks MQ-251 Implement JMSRA activation properties... Closed
Tags: jms-2-implementation

 Description   

This is a request for the implementation (in the GlassFish connector runtime) of the new methods on MessageEndpointFactory to support JMS 2.0 which are proposed in CONNECTOR_SPEC-1.

Note that implementation of this feature is dependent on CONNECTOR_SPEC-1 being approved for JCA 1.7



 Comments   
Comment by prasads [ 27/Nov/12 ]

Assigning to Dapeng

Comment by dapeng_hu [ 12/Dec/12 ]

The new proposal for getEndpointUniqueName() and getInstanceName() are:

The name "getEndpointUniqueName" is changed to "getActivationUniqueName".

The method getInstanceName(): will be added in the BootstrapContext interface, instead of MessageEndpointFactory, since the instance name is static and stable for a server instance.

The value for instanceName in non-clustered setups be null, and for clustered setups be unique among every instance in the cluster. By making this change, we can have a RA also find out if it is operating in a cluster by checking for a non-null instanceName.

The final proposal is still under discussion.

Comment by dapeng_hu [ 18/Dec/12 ]

The final implementation is that:

1. add new method getActivationName() in MessageEndpointFactory interface which returns the unique name for the activation related to the MEF.
2. add new method getInstanceName() in BootstrapContext interface which returns the server instance name if it is a member of a cluster, or return null if it is a standalone server.

Comment by dapeng_hu [ 18/Dec/12 ]

Provides an implementation based on the proposal http://java.net/jira/browse/CONNECTOR_SPEC-1. If final connector MR choose different proposal, this issue should be re-opened.

Comment by Ed Bratt [ 18/Dec/12 ]

commit 57621 was reverted by RE.

Comment by dapeng_hu [ 20/Dec/12 ]

The method BootstrapContext.getInstanceName() is used during the activation of a message endpoint. It is only needed in server-side container. When RA is running in App client container, it don't need call the getInstanceName() method at all. So this method just return null while running in App client container.

Send out new code change for code review, and wait for comments.

Comment by dapeng_hu [ 28/Dec/12 ]

The implementation of getInstanceName and getActivationName has been submitted.





[GLASSFISH-19272] deploy MDB failed Created: 01/Nov/12  Updated: 17/Dec/12  Resolved: 17/Dec/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b60
Fix Version/s: 4.0_b68_EE7MS3

Type: Bug Priority: Major
Reporter: Simon Meng Assignee: Simon Meng
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File MDBApp.ear     Java Source File MessageBean.java     Text File server.log    
Tags: ee7platspec, jms-2-implementation

 Description   

Use case 1
An application contains a session bean and a MDB. The MDB uses the "@MessageDriven(mappedName=" annotation to specify the JNDI name of the destination. This destination resource is defined using a @JMSDestinationDefinition annotation in the session bean. When the application is deployed, deployment of the MDB fails because the resource does not exist.

Use case 2
An application contains a MDB only. The MDB uses the "@MessageDriven(mappedName=" annotation to specify the JNDI name of the destination. This destination resource is defined using a @JMSDestinationDefinition annotation in the MDB.
When the application is deployed, deployment of the MDB fails because the resource does not exist.

Following exception occured when deploy the MDB, detailed exception stack can see the attached server.log
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: JMS resource not created : java:global/jms/myInboundQueue

Can the resources defined in an application be deployed before MDB deployment?

Attachment list:
MDBApp.ear the reproducer application,
MessageBean.java MDB source code
server.log GF server log



 Comments   
Comment by Hong Zhang [ 05/Nov/12 ]

As this is a JMS specific issue (per Jagadish' comments from the email discussions), ressign to Simon to drive the fix for this issue. The deployment team will work with the JMS team to provide any necessary APIs from the deployment side.

Comment by Simon Meng [ 17/Dec/12 ]

Fixed at revision 57591.





[GLASSFISH-19053] Implement new predefined JNDI name java:comp/InstanceName Created: 05/Sep/12  Updated: 15/Nov/12  Resolved: 15/Nov/12

Status: Closed
Project: glassfish
Component/s: naming
Affects Version/s: 4.0
Fix Version/s: 4.0_b64_EE7MS2

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: guojun.shan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 2 weeks, 6 days, 19 hours
Time Spent: 5 hours
Original Estimate: 3 weeks

Tags: ee7platspec, jms-2-implementation

 Description   

In the draft Java EE 7 platform spec, section EE 5.16 "Application Server Instance Name" states that:

A component may access the name of the application server instance in which it is executing using the pre-defined JNDI name java:comp/InstanceName. This name is represented by a String object. If the application has been deployed into a clustered application server, this name identifies the application server instance within the cluster. If the application server is not clustered, it is the empty string.

This issue requests the implementation of this feature.



 Comments   
Comment by Nigel Deakin [ 05/Sep/12 ]

This issue blocks MQ-193

Comment by shreedhar_ganapathy [ 18/Oct/12 ]

Assigning to Guojun to look into implementing this based on Ed Bratt's request.
The implementation is required for JMS integration work to progress.

Comment by guojun.shan [ 19/Oct/12 ]

sorry, I haven't found this part in the latest jsr342:
http://jcp.org/en/jsr/detail?id=342

Comment by Nigel Deakin [ 19/Oct/12 ]

The latest draft of Java EE 7 is at
http://java.net/projects/javaee-spec/downloads/download/JavaEE_Platform_Spec_EDR2_candidate.pdf

(This is a draft of the "second early draft" and will be superseded by the official "second early draft" when it is released)

Nigel

Comment by Tom Mueller [ 19/Oct/12 ]

Targeting for 4.0 release because these are Java EE 7 RI/SDK related.

Comment by guojun.shan [ 24/Oct/12 ]

I think 3 weeks is ok.that should include review and adding dev tests. progress of review is hard to be estimated. and current naming dev test is still broken in 4.0.

Comment by guojun.shan [ 25/Oct/12 ]

how can I get current application server instance name in Glassfish?

Comment by Nigel Deakin [ 25/Oct/12 ]

If you're asking me, I don't know. That's a question for the GlassFish team.

Comment by guojun.shan [ 02/Nov/12 ]

I think there are some discusstions in developers about the instance name.
can you re-define the requirement if needed?
we're blocked now.

Comment by Nigel Deakin [ 14/Nov/12 ]

This issue is superseded by GLASSFISH-19347 and is no longer required.





[GLASSFISH-19052] Implement new predefined JNDI name java:comp/InAppClientContainer Created: 05/Sep/12  Updated: 27/Apr/13  Resolved: 06/Dec/12

Status: Resolved
Project: glassfish
Component/s: naming
Affects Version/s: 4.0
Fix Version/s: 4.0_b68_EE7MS3

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: guojun.shan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 3 weeks
Time Spent: Not Specified
Original Estimate: 3 weeks

Issue Links:
Dependency
blocks GENERICJMSRA-52 Make use of new Java EE new predefine... Open
Tags: ee7platspec, jms-2-implementation

 Description   

In the draft Java EE 7 platform spec, section EE.5.17 "Application Client Container Property" states that "An application may determine whether it is executing in a Java EE application client container by using the pre-defined JNDI name java:comp/InAppClientContainer."

This issue requests the implementation of this feature.

The complete text of that section is

An application may determine whether it is executing in a Java EE application client container by using the pre-defined JNDI name java:comp/InAppClientContainer. This property is represented by a Boolean object. If the application is running in a Java EE application client container, the value of this property is true. If the application is running in a Java EE web or EJB container, the value of this property is false.



 Comments   
Comment by Tim Quinn [ 07/Sep/12 ]

Changing component to "naming." This change needs to occur inside naming, not in the ACC.

Comment by Tom Mueller [ 19/Oct/12 ]

Targeting for 4.0 release because these are Java EE 7 RI/SDK related.

Comment by David Zhao [ 25/Apr/13 ]

It is expected that java:comp/InAppClientContainer should not be set in "client without the ACC" mode (i.e. a lookup throws a NamingException), since this is not a Java EE environment of any kind and it is incorrect to set it.

Comment by guojun.shan [ 27/Apr/13 ]

will modify it in GLASSFISH-20407





Integrate CDI 1.1 (GLASSFISH-19191)

[GLASSFISH-19016] Implement support for transaction scope Created: 17/Aug/12  Updated: 13/Nov/12  Resolved: 13/Nov/12

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0
Fix Version/s: 4.0_b63

Type: Sub-task Priority: Major
Reporter: Nigel Deakin Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JTA_SPEC-7 TransactionScoped annotation for CDI ... Closed
blocks GLASSFISH-19004 Implement injection of JMSContext obj... Resolved
Tags: ee7cdi, jms-2-implementation

 Description   

This issue covers the implementation of a built-in transaction scope for use by the injectable JMSContext implementation.



 Comments   
Comment by tlcksnyder [ 19/Oct/12 ]

New TransactionScope:https://issues.jboss.org/browse/CDI-121
8/17/2012: This annotation will be defined in the JTA area.
The implementation should be provided as a portable extension by the application server and made available to all applications.
I need to discuss this with Paul Parkinson so that we can schedule the work.

Declarative transactions on managed beans, Transaction JTA IssueInterceptor:https://issues.jboss.org/browse/CDI-27
After speaking with Paul Parkinson most, and quite likely all, of this work will be done in the JTA area of GlassFish. CDI may have to help implement the interceptors.
See Linda's blog entry:https://blogs.oracle.com/ldemichiel/entry/transactional_interceptors
Some Jave EE platform discussions (http://java.net/projects/javaee-spec/lists/jsr342-experts/archive)

New JMS annotation-handling...talk to Nigel

Comment by jjsnyder83 [ 13/Nov/12 ]

Committed revision 56977.

Comment by jjsnyder83 [ 13/Nov/12 ]

Error in previous revision. Fixed in revision 56979.





[GLASSFISH-19004] Implement injection of JMSContext objects (Phase 2) Created: 15/Aug/12  Updated: 13/Dec/12  Resolved: 13/Dec/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.0_b68_EE7MS3

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19016 Implement support for transaction scope Resolved
depends on MQ-177 Implement injection of JMSContext obj... Closed
Tags: jms-2-implementation

 Description   

Implement the injection of JMS Context objects, as specified in JMS_SPEC-70.

Phase 1 of this work was covered by MQ-177

Phase 2 of this work involves the implementation of the scope combined transaction/request scope expected to be defined in the JMS 2.0 Public Draft.



 Comments   
Comment by Nigel Deakin [ 15/Aug/12 ]

Added dependency on MQ-177, which is the first phase of this work.

Comment by David Zhao [ 01/Nov/12 ]

This feature is expected to be ready in GlassFish Milestone 3 (Dec. 17) if the dependency 19016 can be finished by Milestone 2 (Nov. 19) on time.

Comment by David Zhao [ 13/Dec/12 ]

Revision: 57494





[GLASSFISH-18936] EJB 3.2 Add support for publishing java:comp/UniqueMDBName Created: 24/Jul/12  Updated: 14/Nov/12  Resolved: 02/Nov/12

Status: Closed
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: ying.x.hu
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7platspec, ejb_3_2, jms-2-implementation

 Description   

See 5.7.3 Unique Identifier for JMS Message-Driven Bean:

The Container Provider must make a name which uniquely identifies the deployed MDB in an application server instance, available in the JNDI naming context under java:comp/UniqueMDBName so that it can be looked up by the resource adapter when its endpointActivation method is called.



 Comments   
Comment by marina vatkina [ 11/Oct/12 ]

The spec left the rules on the value of the unique id non-defined, but various JMS vendors might have different rules on the valid characters in the subscription name (for which the published value is intended to be used). So the easiest way to keep the unique id alpha-numeric is to use the containerId with some prefix...

Comment by ying.x.hu [ 02/Nov/12 ]

There're some EG discussions on account of the Thread Local usage for this issue. And current plan is to go with an API instead. So close this issue temporarily, waiting for the API be ready.

Comment by Nigel Deakin [ 14/Nov/12 ]

This issue is superseded by Superseded by GLASSFISH-19347 and is not longer required.





[GLASSFISH-18900] Implement support for Java EE Connection Factory and Destination Resource Definition Created: 13/Jul/12  Updated: 07/Nov/12  Resolved: 12/Sep/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.0_b54

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7platspec, jms-2-implementation

 Description   

This issue covers the implementation of the following sections of the Java EE 7 specification: EE.5.17.4 "JMS Connection Factory Resource Definition" and EE.5.17.5 "JMS Destination Definition".

For a definitive description of this requirement, see the Java EE 7 specification.



 Comments   
Comment by Nigel Deakin [ 23/Jul/12 ]

The annotation itself, and the standard properties that will be defined, will be defined as part of JMS 2.0. The JMS specification issues are JMS_SPEC-96 and JMS_SPEC-97.

Comment by Simon Meng [ 12/Sep/12 ]

Committed revision 55843.





[GLASSFISH-18899] Implement support for Java EE platform default connection factory Created: 13/Jul/12  Updated: 07/Nov/12  Resolved: 19/Oct/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.0_b58

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MQ-177 Implement injection of JMSContext obj... Closed
Tags: ee7platspec, jms-2-implementation

 Description   

This issue covers the implementation of Java EE 7 section EE.5.19 "Default JMS Connection Factory"

For a definitive description of this requirement, see the Java EE 7 specification. In the Java EE 7 Early Draft this was:

The Java EE Platform requires that a Java EE Product Provider provide a JMS provider in the operational environment (see Section EE.2.7.8, "Java™ Message Service (JMS)") . The Java EE Product Provider must also provide a preconfigured, JMS ConnectionFactory for use by the application in accessing this JMS provider.

The Java EE Product Provider must make the default JMS connection factory accessible to the application under the JNDI name java:comp/defaultJMSConnectionFactory.

The Application Component Provider or Deployer may explicitly bind a JMS ConnectionFactory resource reference to the default connection factory using the lookup element of the Resource annotation or the lookup-name element of the resource-ref deployment descriptor element. For example,

@Resource(name="myJMSCF",
lookup="java:comp/defaultJMSConnectionFactory")
ConnectionFactory myJMScf;

In the absence of such a binding for a JMS connection factory resource reference, the reference will map to a JMS connection factory for the product's JMS provider.
For example, the following will map to a preconfigured connection factory for the product's default JMS provider:

@Resource(name="myJMSCF")
ConnectionFactory myJMScf;


 Comments   
Comment by David Zhao [ 10/Sep/12 ]

Revision 55867.

Comment by David Zhao [ 11/Sep/12 ]

Revert for waiting 1 admin test case pass.

Comment by David Zhao [ 13/Sep/12 ]

Re-commit it by revision 55940.

Comment by Nigel Deakin [ 17/Oct/12 ]

According to the second "Java EE 7 EDR candidate" (EE.5.21) at
http://java.net/projects/javaee-spec/downloads/download/JavaEE_Platform_Spec_EDR2_candidate.pdf the JNDI name of the platform default connection factory has changed to java:comp/DefaultJMSConnectionFactory. The implementation will need updating accordingly.

Comment by David Zhao [ 19/Oct/12 ]

Changed the jndi name to java:comp/DefaultJMSConnectionFactory accordingly.





Generated at Fri Sep 04 02:12:21 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.