This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 165105

Summary:	Queue resources are incorrectly created for Message Driven Beans for GlassFish
Product:	serverplugins	Reporter:	bastian_knight <bastian_knight>
Component:	GlassFish	Assignee:	Vince Kraemer <vkraemer>
Status:	NEW ---
Severity:	blocker	CC:	marfous, pjiricka, vkraemer
Priority:	P3
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Exception Reporter:

Description bastian_knight 2009-05-13 19:07:41 UTC

If one creates new Message Driven EJB there is a possibility to create a new destination. This destination is created as
a GlassFish resource. The resources are created with an error: all automatically created destinations are linked to the
same physical queue. The effect is that if user creates more than one MDB than they are all connected to the same queue
when deployed in glassfish.

Because user isn't asked to enter physical queue name it can be very annoying to find out, that messages aren't
correctly routed after deploying a project in GlassFish.

The wizard for creating MDBs should ask for physical queue name or generate unique physical queue names based on MDB name.

Comment 1 Martin Fousek 2011-10-10 13:52:38 UTC

From EJB point of view it seems that managing of message destinations is too much server dependent. Troubles which you are facing for GF are not valid i.e. for WebLogic. So finally I don't think that it's good idea to create there any server dependent wizard for it.

If I'm not wrong, for EJB application should be important just the JNDI name and the rest - real Queue or Topic for the resource provides the server. 

I'm moving to GF component and please Vince evaluate that from your point of view. Probably you could generate unique physical queue/topic for every "virtual".

Comment 2 TomasKraus 2013-07-19 23:29:45 UTC

Some old 6.x request for enhancement. I don't think we have time to implement this in near future. Moving to RFE queue.