APAR status
Closed as program error.
Error description
The endptEnabler tool should not allow the customer to specify
JMS routers for two different EJB modules within the same EAR
be bound to the same listener port.
These two EJB modules are the basis of web services and have
two separate endpoint interfaces and two separate port names.
I specified a properties file when running endptEnabler on an
EAR. This is part of what that properties file looks like:
WSInsSession20EJB.jms.listenerInputPortName:
InsuranceWebServices_ListenerPort
WSInsSession20EJB.jms.routerModuleName:
WSInsSession20EJB_JMSRouter
WSInsAnnexSession20EJB.jms.listenerInputPortName:
InsuranceWebServices_ListenerPort
WSInsAnnexSession20EJB.jms.routerModuleName:
WSInsAnnexSession20EJB_JMSRouter
Notice that the listener ports are the same.
So, when I installed this EAR using the admin console, in the
"Binding Enterprise Beans to Listener Port Names" panel of the
installation wizard, the value of the listener port for each
JMS router module was already there. The admin console
doesn't complain about this.
Even upon app start-up, I did not see any error or warning
messages. However, when a client actually calls the web
service through JMS transport, these errors are
thrown to the client:
[4/5/04 21:42:08:583 CDT] 5821d0 JMSListenerMD E WSWS3018E:
Caught exception during request processing: WSWS3163E: Error:
The Web services engine could not find a target service to
invoke! targetService is InsuranceWebServices
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users of web *
* services *
****************************************************************
* PROBLEM DESCRIPTION: endptEnabler should not allow 2 MDBs *
* to use same listener *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The endptEnabler tool should not allow the customer to specify
JMS routers for two different EJB modules within the same EAR
be bound to the same listener port.
These two EJB modules are the basis of web services and have
two separate endpoint interfaces and two separate port names.
If you specify a properties file when running endptEnabler on
an EAR and this is part of what that properties file looks like:
WSInsSession20EJB.jms.listenerInputPortName:
InsuranceWebServices_ListenerPort
WSInsSession20EJB.jms.routerModuleName:
WSInsSession20EJB_JMSRouter
WSInsAnnexSession20EJB.jms.listenerInputPortName:
InsuranceWebServices_ListenerPort
WSInsAnnexSession20EJB.jms.routerModuleName:
WSInsAnnexSession20EJB_JMSRouter
Notice that the listener ports are the same.
So, when this EAR is installed using the admin console, in the
"Binding Enterprise Beans to Listener Port Names" panel of the
installation wizard, the value of the listener port for each
JMS router module was already there. The admin console
doesn't complain about this.
Even upon app start-up, there were not any error or warning
messages. However, when a client actually calls the web
service through JMS transport, these errors are
thrown to the client:
[4/5/04 21:42:08:583 CDT] 5821d0 JMSListenerMD E WSWS3018E:
Caught exception during request processing: WSWS3163E: Error:
The Web services engine could not find a target service to
invoke! targetService is InsuranceWebServices
Problem conclusion
The endpointEnabler is changed so that it will warn if 2 (or
more) different MDBs are using the same listener port, but this
will only catch the situation where this happens all within
the same EAR. It's still possible that one MDB in one EAR
and one MDB in another EAR are configured to use the same
listener port, but endpointEnabler would not catch that
situation since it operates on only 1 EAR at a time.
In general (from the JMS provider's standpoint), there's
nothing wrong with having multiple MDBs configured to use the
same listener port. It's just that this causes problems
with web services and it, in fact, doesn't make sense when
you add web services to the picture.
Temporary fix Comments
APAR information |
APAR number |
PQ87557 |
Reported component name |
WAS BASE 5.0 |
Reported component ID |
5630A3600 |
Reported release |
00W |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2004-04-14 |
Closed date |
2004-04-26 |
Last modified date |
2004-04-26 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
Applicable component levels |
R003 PSY |
UP |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
R103 PSY |
UP |
R10A PSY |
UP |
R10H PSY |
UP |
R10I PSY |
UP |
R10P PSY |
UP |
R10S PSY |
UP |
R10W PSY |
UP |
|