Discussion:
Listener port vs. Activation Specification
(too old to reply)
A***@fnf.com
2007-06-08 13:25:07 UTC
Permalink
Hello all,

Cross-posting here from
http://ecommunity.groupintelligence.com/websphere/forums/showthread.php?t=1782

My ws_ant <wsInstallApp> installs w/o error. However, my app won't start.
WAS thinks I'm using Activation Specification bindings instead of Listener port bindings, even though I've told it differently (as I see it, at least).

To get the app to start, I have to use the admin console to manually select Listener port vs. Activation Specification for one particular MDB.
The WAS admin console screen I use is here:

Enterprise Applications > [myApp] > Provide listener bindings for message-driven beans

More specifically, after I redeploy with my ws_ant script, WAS has set the 'radio button' on this screen to Activation Specification instead of Listener port.
When I set it back to 'Listener port' ( somehow WAS already has the correct values for module,ejbname, uri, lp ?!), everything runs swimmingly.

Any thoughts would be helpful on how to fix this.

Thanks,

--Erik Ostermueller

IBM WebSphere Application Server - ND, 6.0.2.17
Build Number: cf170648.10
Build Date: 11/29/06
os=solaris


<wsInstallApp
wasHome="${wasHome}"
ear="${local.ear.dir}/${EARFile.de}"
conntype="${conntype}"
host="${wasHostName}"
port="${wasPortNo}"
options="-usedefaultbindings -BindJndiForEJBMessageBinding {{DeMdbSvr DeMdbSvr DEBackend.jar,META-INF/ejb-jar.xml DEServerListenerPor
t}} -node ${wasNode} -cell ${wasCell} -server ${wasAppServer}" />


To no avail, I've tried this with and without the BindJndiForEJBMessageBinding option, as reccomended here:
http://www-1.ibm.com/support/docview.wss?uid=swg21248211

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="ejb-jar_ID" version="2.1" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
<display-name>DeMdbSvr</display-name>
<enterprise-beans>
<message-driven id="DeMdbSvr">
<ejb-name>DeMdbSvr</ejb-name>
<ejb-class>com.fnf.defaultmanager.pa.DEMdbAdaptor</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Bean</transaction-type>
<message-destination-type>javax.jms.Queue</message-destination-type>
<env-entry>
<description>
DE Boc Config File</description>
<env-entry-name>xes/DEMdbAdaptorBocConfigName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>minimalBocConfig.xml</env-entry-value>
</env-entry>
<resource-ref id="ResourceRef_1162408166817">
<description>
</description>
<res-ref-name>jms/TPQCF</res-ref-name>
<res-type>javax.jms.ConnectionFactory</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
<resource-ref id="ResourceRef_1162408958151">
<description>
</description>
<res-ref-name>jms/DEServerQ</res-ref-name>
<res-type>javax.jms.Queue</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</message-driven>
</enterprise-beans>
<assembly-descriptor/>
</ejb-jar>


<?xml version="1.0" encoding="UTF-8"?>
<com.ibm.ejs.models.base.bindings.ejbbnd:EJBJarBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.ejs.models.base.bindings.commonbnd="commonbnd.xmi" xmlns:com.ibm.ejs.models.base.bindings.ejbbnd="ejbbnd.xmi" xmlns:com.ibm.etools.ejb="ejb.xmi" xmi:id="EJBJarBinding_1162401219984">
<defaultDatasource xmi:id="ResourceRefBinding_1169482627445">
<defaultAuth xmi:type="com.ibm.ejs.models.base.bindings.commonbnd:BasicAuthData" xmi:id="BasicAuthData_1169482627445"/>
</defaultDatasource>
<ejbJar href="META-INF/ejb-jar.xml#ejb-jar_ID"/>
<ejbBindings xmi:type="com.ibm.ejs.models.base.bindings.ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1162401219984" listenerInputPortName="DEServerListenerPort">
<enterpriseBean xmi:type="com.ibm.etools.ejb:MessageDriven" href="META-INF/ejb-jar.xml#DeMdbSvr"/>
<resRefBindings xmi:id="ResourceRefBinding_1162408166817" jndiName="jms/TPQCF">
<bindingResourceRef href="META-INF/ejb-jar.xml#ResourceRef_1162408166817"/>
</resRefBindings>
<resRefBindings xmi:id="ResourceRefBinding_1162408958151" jndiName="jms/DEServerQ">
<bindingResourceRef href="META-INF/ejb-jar.xml#ResourceRef_1162408958151"/>
</resRefBindings>
</ejbBindings>
<defaultCMPConnectionFactory xmi:id="CMPConnectionFactoryBinding_1169482627445"/>
</com.ibm.ejs.models.base.bindings.ejbbnd:EJBJarBinding>
A***@fnf.com
2007-06-11 16:34:38 UTC
Permalink
I'm replying to self, here.

I'm one step further. After running my redeploy script (and reproducing the problem), I discovered that the ibm-ejb-jar-bnd.xmi being used is different than the one I put in the jar file. Did it not like mine for some reason?

Here is the line from ibm-ejb-jar-bnd.xmi that I put in the jar file:

<ejbBindings xmi:type="com.ibm.ejs.models.base.bindings.ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1162401219984" listenerInputPortName="DEServerListenerPort">

After the redeploy WAS _adds_ the following attribute to the above:

activationSpecJndiName="eis/DeMdbSvr"

How do I keep WAS from doing this?

I discovered this by looking at this file: demss005AppSrv01\config\cells\demss005Cell01\applications\DEBackend.ear\deployments\DEBackend\DEBackend.jar\META-INF\ibm-ejb-jar-bnd.xmi

The stdout of the redeploy didn't indicate that anything was wrong.
Is there a more detailed log somewhere of the redeploy process?

--Erik


output from redeploy:
---------------------------------------------
uninstall.de:
[wsUninstallApp] Uninstalling Application [DEBackend]...
[wsadmin] WASX7209I: Connected to process "dmgr" on node demss005CellManager01 using SOAP connector; The type of process is: DeploymentManager
[wsadmin] ADMA5017I: Uninstallation of DEBackend started.
[wsadmin] ADMA5104I: The server index entry for WebSphere:cell=demss005Cell01,node=DefaultNode is updated successfully.
[wsadmin] ADMA5102I: The configuration data for DEBackend from the configuration repository is deleted successfully.
[wsadmin] ADMA5011I: The cleanup of the temp directory for application DEBackend is complete.
[wsadmin] ADMA5106I: Application DEBackend uninstalled successfully.
[wsUninstallApp] Uninstalled Application [DEBackend]

install.de:
[wsInstallApp] Installing Application [/usr/deploy/de/scripts/./ears/s2A-DDV/DEBackend-dev.ear]...
[wsadmin] WASX7209I: Connected to process "dmgr" on node demss005CellManager01 using SOAP connector; The type of process is: DeploymentManager
[wsadmin] ADMA5016I: Installation of DEBackend started.
[wsadmin] ADMA5058I: Application and module versions validated with versions of deployment targets.
[wsadmin] ADMA5005I: The application DEBackend is configured in the WebSphere Application Server repository.
[wsadmin] ADMA5053I: The library references for the installed optional package are created.
[wsadmin] ADMA5005I: The application DEBackend is configured in the WebSphere Application Server repository.
[wsadmin] ADMA5001I: The application binaries are saved in /opt/IBM/WebSphere/AppServer/profiles/demss005CellManager01/wstemp/Script1131b37d323/workspace/c
ells/demss005Cell01/applications/DEBackend.ear/DEBackend.ear
[wsadmin] ADMA5005I: The application DEBackend is configured in the WebSphere Application Server repository.
[wsadmin] SECJ0400I: Successfuly updated the application DEBackend with the appContextIDForSecurity information.
[wsadmin] ADMA5011I: The cleanup of the temp directory for application DEBackend is complete.
[wsadmin] ADMA5013I: Application DEBackend installed successfully.
[wsInstallApp] Installed Application [/usr/deploy/de/scripts/./ears/s2A-DDV/DEBackend-dev.ear]
A***@fnf.com
2007-06-21 16:13:21 UTC
Permalink
Just me again.

When I manually make the correction in the WAS console and save/synchronize my changes, here are the files that are changed:

cells / demss008Cell01 / applications / DEBackend.ear / deltas / DEBackend / delta-1181566356593 Added
cells / demss008Cell01 / applications / DEBackend.ear / deployments / DEBackend / DEBackend.jar / META-INF / ibm-ejb-jar-bnd.xmi Updated
cells / demss008Cell01 / applications / DEBackend.ear / deployments / DEBackend / DEBackend.jar / META-INF / ejb-jar.xml Updated
cells / demss008Cell01 / applications / DEBackend.ear / deployments / DEBackend / META-INF / application.xml Updated
cells / demss008Cell01 / applications / DEBackend.ear / deployments / DEBackend / META-INF / ibm-application-bnd.xmi Updated
cells / demss008Cell01 / applications / DEBackend.ear / deployments / DEBackend / deployment.xml Updated


So the task here will be discovering _which_ processes alter these files during the deploy (and why).

--Erik
j***@bcbsfl.com
2007-09-27 16:55:24 UTC
Permalink
Any luck on this?
We are having the same problem when using the WebSphere APIs
j***@bcbsfl.com
2007-10-09 18:11:51 UTC
Permalink
We were able to solve this by using nousedefaultbindings instead of usedefaultbindings when installing the EAR. The default for EJB 2.1 is Activation Specifications so the Listener Port is not used with default bindings.
Loading...