|<< Back to previous view|
[GLASSFISH-20441] JMSContext cannot be injected in a @SessionScoped bean Created: 30/Apr/13 Updated: 15/May/13 Resolved: 03/May/13
|Fix Version/s:||4.0_b88_RC4, 4.0.1|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Participants:||arungupta, Bruno Borges and David Zhao|
I can inject ConnectionFactory and use it to create a local JMSContext but using the code fragment above shows the following deployment failure.
|Comment by David Zhao [ 02/May/13 02:47 AM ]|
Could you share a small application for reproduction?
I tried injecting JMSContext into a SessionScoped managed bean and then inject the managed bean into jsf. Both deployment and run are OK with only warning printed in server.log.
[2013-05-02T10:43:04.912+0800] [glassfish 4.0] [WARNING]  [org.jboss.weld.Bootstrap] [tid: _ThreadID=37 _ThreadName=ad
|Comment by arungupta [ 02/May/13 04:40 PM ]|
Tried with b87 and got the same error. Attaching the sample app as well.
Complete stack trace below:
In-place deployment at /Users/arungup/code/workspaces/javaee7-samples~source/samples/jms/jmscontext-cdi/target/jmscontext-cdi-1.0-SNAPSHOT
|Comment by arungupta [ 02/May/13 04:52 PM ]|
Sample is now available at:
|Comment by David Zhao [ 03/May/13 12:48 AM ]|
What is the impact on the customer of the bug?
What is the cost/risk of fixing the bug?
Is there an impact on documentation or message strings?
Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Which is the targeted build of 4.0 for this fix?
If this an integration of a new version of a component from another project,
|Comment by David Zhao [ 03/May/13 09:55 AM ]|
Fixed in 4.0 by revision 61813.
|Comment by Bruno Borges [ 14/May/13 09:24 PM ]|
Tried this on GlassFish 4.0 b88 promoted on 08-May-2013 18:59 and it is not fixed.
|Comment by David Zhao [ 14/May/13 10:26 PM ]|
What do you mean for it is not fixed? What have you observed? JMSContext injection failure or just the warning logged?
|Comment by arungupta [ 15/May/13 05:58 AM ]|
I tried my simple use case that sends a message as:
and receives a message as:
And that worked.
I filed the bug because this scenario was not working and now works with 88.
What exactly is not working ?