Fix (APAR): PK65526 Status: Fix Release: 6.0.2.21 Operating System: AIX,HP-UX,i5/OS,Linux,Linux pSeries,Linux zSeries,OS/400,Solaris,Windows Supersedes Fixes: CMVC Defect: xxxxxx Byte size of APAR: 28563 Date: 2008-08-21 Abstract: The current behavior of Application Server makes it difficult for you to use a Listener Port and also deprives you of having the flexibility of controlling the bindings that have t Description/symptom of problem: PK65526 resolves the following problem: ERROR DESCRIPTION:? Currently for message-driven beans (MDBs) there are 2 possible ways to collect bindings - 1) From bindings file packaged with the Enterprise Archive file (EAR) (ejb.jar/META-INF/ibm-ejb-bnd.xmi) 2) From external binding strategy xml file specified by you during applicaton install. If you attempt to collect bindings with a mixture of #1 or #2 along with certain defaults for example, prefer activaciton specificationover lister port for J2EE 1.4 et. the following exception snipet is thrown: [4/29/08 10:55:21:232 EDT] 00000041 RALifeCycleMa E J2CA0052E: The lookup of the ActivationSpec with JNDI Name eis/ActivationSpaec failed due to exception javax.naming.NameNotFoundException: Context: SomeCell/clusters/SomeCluster, name: eis/ActivationSpec: First component in name AckNakMessage not found. Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0 at com.ibm.ws.naming.ipcos.WsnOptimizedNamingImpl.do_resolve_comple te_info( WsnOptimizedNamingImpl.java:543) at com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.resolve_com plete_in fo(WsnOptimizedNamingImplBase.java:2213) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessor Impl.jav a:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessor Impl.jav a:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod Accessor Impl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at com.ibm.rmi.util.ProxyUtil$2.run(ProxyUtil.java:654) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.jav a(Compil ed Code)) at com.ibm.rmi.util.ProxyUtil.invokeWithPrivilege(ProxyUtil.java:65 0) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:115 0) at $Proxy0.resolve_complete_info(Unknown Source) at com.ibm.WsnOptimizedNaming._NamingContextStub.resolve_complete_i nfo(Unkn own Source) at com.ibm.ws.naming.jndicos.CNContextImpl.cosResolve(CNContextImpl .java:40 43) at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.j ava:1746 ) at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.j ava:1707 ) at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl. java:141 2) at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.jav a:1290) at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:145) at javax.naming.InitialContext.lookup(InitialContext.java:361) at com.ibm.ejs.j2c.RALifeCycleManagerImpl.activateEndpoint(RALifeCy cleManag erImpl.java:1345) at com.ibm.ejs.container.MessageEndpointFactoryImpl.activateEndpoin t(Messag eEndpointFactoryImpl.java:256) at com.ibm.ws.runtime.component.EJBContainerImpl.install(EJBContain erImpl.j ava:2908) at com.ibm.ws.runtime.component.EJBContainerImpl.start(EJBContainer Impl.jav a:3578) at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(Applicatio nMgrImpl .java:1249) at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeploye dObjectS tart(DeployedApplicationImpl.java:1067) at ---- Begin backtrace for Nested Throwables org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0 at com.ibm.ws.naming.ipcos.WsnOptimizedNamingImpl.do_resolve_comple te_info( WsnOptimizedNamingImpl.java:543) at com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.resolve_com plete_in fo(WsnOptimizedNamingImplBase.java:2213) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessor Impl.jav a:85) The problem was observed in WebSphere Application Server v60.2.21 LOCAL FIX:? N/A PROBLEM SUMMARY:? USERS AFFECTED: All users of IBM WebSphere Application Server V 6.0.2 and V6.1 PROBLEM DESCRIPTION: The current behavior of Application Server makes it difficult for you to use a Listener Port and also deprives you of having the flexibility of controlling the bindings that have to be generated for Message Driven Beans (MDB's) via a custom bindings file. RECOMMENDATION: None Currently when you have Enterprise Archive files (EARs) that have Message Driven Beans (MDBs) while deploying the application the code base creates a default Activation Spec based on the following rules: a) For EJB 2.1 regardless of whether a listener port is specified in the custom bindings or in the EAR, we always populate an activation spec (that is, we will first see if there is one in the custom bindings and if not then populate the default activation spec JNDI name). b) For EJB 2.0, the code base is more lenient towards a listener port in that if there is no activation spec in a custom file or in the bindings xmi then we will use listener port. So if Activation Spec JNDI is in the bindings inside the EAR and a listener port is in a custom file we will ignore it. This current behavior of the code base makes it difficult for you to use Listener Port and also deprives you of having the flexibility of controlling the bindings that have to be generated for Message Driven Beans (MDB's) via a custom bindings file. PROBLEM CONCLUSION:? The code has been modified to address this issue by providing a system property which you have to set. 1) To enable the system property edit the wsadmin.properties file, and add the following line (all on one line): com.ibm.websphere.management.application.dfltbndng.mdb.preferMDB CustomBindingsExclusive= true 2) From the administrative console: a) For Network Deployment edition, the property has to be set in deployment manager. The property need to be defined as a JVM property in Deployment manager. In the administrative console, System administration --> Deployment manager --> Process Definition --> Java Virtual Machine --> Custom Properties Name : com.ibm.websphere.management.application.dfltbndng.mdb.preferMDB CustomBindingsExclusive Value : true b) For Application Server Base edition the value has to be set for Server1 instead of deployment manager. . . Once the property is set when you deploy an application with a custom binding file then for the Message Driven Beans (MDB's) the bindings inside the custom binding file will override the bindings defined inside the EAR. If the bindings are not defined and you select the options to generate default bindings then default bindings are generated as they were before. With the property set the behavior will be as follows: 1) If custom binding has a listener port then the result would be just a listener port from the custom bindings file even though there is a listener port/Activation Spec defined at bindings inside the EAR. 2) If the custom binding file has Activation Spec then the result would be just an Activation Spec from the custom bindings file even though there is a listener port/Activation Spec defined at the bindings inside the EAR. 3) If the custom binding file has both listener port and Activation Spec defined then the result would be just an Activation Spec from the custom bindings 4) If the custom binding file does not have any binding but the EAR has both listener port and Activation Spec defined then the result would be just an Activation Spec from the EAR. 5) If there are no bindings inside the EAR and custom binding file and you choose to generate Default bindings then an activation spec is generated. But in the case of a Destination JNDI Name for the activation Spec, as per design we do not read the destinationJndiName from the custom binding file. If it is specified in the ear and as per the logic explained earlier if activationspec remains as the final binding then we are retaining the value of the destinationJndiName obtained from the ear (if any) otherwise if listenerport is the result of the logic then we omit the destinationJndiName in the end result bindings. So the only place where destinationJndiNamecan be specified is inside the EAR. Note: You need to remove the following custom property if it exists: com.ibm.websphere.management.application.dfltbndng.mdb.preferexi sting=true The two properties are mutually execlustive. If both are present, perferexisting will take precedence over preferMDB CustomBindingsExclusive. The fix for this APAR is currently targeted for inclusion in fix packs 6.1.0.21 and 6.0.2.30. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980 Directions to apply fix: NOTE: Choose the: 1) Release the fix applies to 2) The Editions that apply 3) Delete the Editions & Methods that do not apply and this Note Fix applies to Editions: Release 6.0 X_ Application Server (Express or BASE) X_ Network Deployment (ND) __ WebSphere Business Integration Server Foundation (WBISF) __ Edge Components __ Developer __ Extended Deployment (XD) Install Fix to: Method: __ Application Server Nodes __ Deployment Manager Nodes X_ Both NOTE: The user must: * Have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * Logged in with the same authority level when unpacking a fix, fix pack or refresh pack. * Be at V6.0.2.2 or newer of the Update Installer. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 For detailed instructions to Extract the Update Installer see the following Technote: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21205400 1) Copy PKxxxxx.pak file directly to the maintenance directory 2) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) Launch Update Installer 4) Enter the installation location of the WebSphere product you want to update. 5) Select the "Install maintenance package" operation. 6) Enter the file name of the maintenance package to install (PKxxxxx.pak file which was copied in the maintenance directory). 7) Install the maintenance package. 8) Restart WebSphere Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (PKxxxxx.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere. Additional Information: