Showing results for 
Search instead for 
Did you mean: 

ResourceBundle java exception when adding UDP to 8845 or 8865 via AXL


Hi guys,

I am currently adding an existent UDP to a 8845 or 8865 SIP phone, but keep on getting the following Java Exception.

"ERROR [http-bio-443-exec-17] axlapiservice.AXLAPIServiceSkeleton -

java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key TypeProduct.

  at java.util.ResourceBundle.getObject(

  at java.util.ResourceBundle.getString(





  at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(

  at org.apache.axis2.receivers.AbstractMessageReceiver.receive(

  at org.apache.axis2.engine.AxisEngine.receive(

  at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(

  at org.apache.axis2.transport.http.AxisServlet.doPost(

  at javax.servlet.http.HttpServlet.service(

  at javax.servlet.http.HttpServlet.service(


It is important to note the following information:

a) We can manually perform the operation on CUCM GUI without any issues.

b) We can add the handset (8845 or 8865) without problems via AXL.

c) It is only the addition of UDP that fails via AXL for 8845 or 8865; addition works with no problems with 8945 (and other phones like 8831, 9971, 7925, etc).

d) When running the SQL query (for 8845 and 8895) via CLI we obtain similar results, except that the following fields are different:










The following is the query that is ran just before the ERROR above, the query is exact same for both 8845 and 8895, only difference is the Device.pkid.

"axlapiservice.GetDeviceProfileHandler - SELECT Device.*, as CallingSearchSpaceName, as MlppDomainname11, as PhoneTemplatename18, PT.numOfButtons as numOfButtons, as defaultProfileName, as currentProfileName, EU.userid as loginUserIdName,EU.pkid as loginUserId, DND.dndstatus as dndStatus, as CallingSearchSpacename41, EMD.loginduration as loginDuration, EMD.logintime as loginTime, EMD.fkdevice_currentloginprofile as currentProfileId, as softkeyTemplateName, DPD.tkStatus_CallInfoPrivate as privacy FROM Device left OUTER join CallingSearchSpace CSS on CSS.pkid = device.fkcallingsearchspace left OUTER join MlppDomain MLPP on MLPP.pkid = device.fkmlppdomain left OUTER join PhoneTemplate PT on PT.pkid = device.fkphonetemplate left OUTER join Device D on D.pkid = device.ikdevice_defaultprofile left outer join DndDynamic DND on DND.fkDevice = device.pkid left OUTER join DevicePrivacyDynamic DPD on DPD.fkdevice = device.pkid left outer join ExtensionMobilityDynamic EMD on EMD.fkDevice = device.pkid left outer join Device D1 on D1.pkid = EMD.fkdevice_currentloginprofile left outer join EndUser EU on EU.pkid = device.fkEndUser left OUTER join SoftkeyTemplate softkey on softkey.pkid = device.fksoftkeytemplate where Device.pkid = '5bb1d78b-9afc-1923-bc74-4df25e0181cb'"

This is the AXL query being executed:

servletRouters.AXLFilter - AXL REQUEST :

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:ns1="" xmlns:soapenv="" xmlns:xsd="" xmlns:xsi=""><soapenv:Body><ns1:getDeviceProfile><name xsi:type="xsd:string">UDP_8845_Template</name></ns1:getDeviceProfile></soapenv:Body></soapenv:Envelope>

We are using CUCM and 8845 are using load sip8845_65.11-0-1-11.

Any comments with some help would be greatly appreciated it.

Thanks indeed.


2 Replies 2

Cisco Employee
Cisco Employee

It appears that the 8845/65 models were released some time after CUCM 9.1 appeared.  As a result, it's possible that some code present in the 9.1 AXL layer may be dependent on a hard-coded list of phone 'product' types that doesn't include the product types for the 8845/65.

Normally in such a situation, the customer installs a device 'COP' file or device-pack COP which adds the newly released phones' specs/data/types to the CUCM system and database, allowing admin UI and AXL operations to work as expected.  If AXL is indeed having a problem due to such a hard-coded product-type list, then this would probably be considered a defect.

I would suggest opening a DevNet Developer Support ticket to further investigate:

You may be able to work around this by reading/updating via SQL with the <executeSqlQuery/Update> requests.

Thanks for the reply and detailed feedback. Before your comments, I did not think about a dependent relationship between the 9.1 AXL layer and some hard coded list of phone product types; it would make some sense to think our case could be a defect. I would evaluate to open the case to DevNet Support as suggested, because the workaround does not seem to be an option for the customer.

We installed the 'COP' file following the instructions (cluster reboot), and in fact we can perform same configuration without issues using the CUCM GUI; so I think the problem relies on the AXL layer as you mentioned.

Will keep this updated with the progress obtained. Thanks again.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers