Topic
  • 13 replies
  • Latest Post - ‏2013-07-24T08:54:02Z by IvanHargreaves
yairbar
yairbar
20 Posts

Pinned topic MQ/JMS probs under CICS5.1 JVMServer

‏2013-07-03T07:30:37Z |

Hello,

When trying a CICS java appl using JMS API, I get in run time the following Exception:

"Unresolved compilation problems: The import javax.jms cannot be resolved" (and of course as aconsequence all JMS Types , e.g. "Connection", cannot be resolved to a type , etc.)

Note that at Eclipse, before Exporting the proper bundle to CICS, There were no errors,

In the Build Path of the Project in Eclipse  I have concatenated as External jars the jms jars which I have transferrec from zOS ' (e.g. jms.jar,     com.ibm.mq.jmqi.jar,  com.ibm.jmsmq.jar ).    All relevant "import" were resolved at Eclipse and all  JMS "Types" were resolved there. 

Note also that in JVM Profile at CICS (DFH$WLP) I have added  the reference to OSGi Bundles for using MQ/JMS as I undestood it.

Attached my DFHWLP Profile.

Why I encounter the above Exception at run time in CICS ?

Appreciate any  tip,

Regards,

Yair Barzilai

Attachments

Updated on 2013-07-03T08:15:07Z at 2013-07-03T08:15:07Z by yairbar
  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-04T11:05:03Z  

    Hi Yair,

    JMS is not supported in WebSphere Application Server Liberty Profile v8.5.0 or in CICS. Although the recent version of W.A.S Liberty (v8.5.5) has introduced support for JMS - that version is not shipped with CICS TS v5.1. We are aware that JMS will be a popular requirement.

    If you wish to connect to WebSphere MQ from a CICS Java program (OSGI bundle) then you will need to use the MQ base classes (WebSphere MQ classes for Java).

    thx

    Ivan

  • yairbar
    yairbar
    20 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-08T06:30:18Z  

    Hi Yair,

    JMS is not supported in WebSphere Application Server Liberty Profile v8.5.0 or in CICS. Although the recent version of W.A.S Liberty (v8.5.5) has introduced support for JMS - that version is not shipped with CICS TS v5.1. We are aware that JMS will be a popular requirement.

    If you wish to connect to WebSphere MQ from a CICS Java program (OSGI bundle) then you will need to use the MQ base classes (WebSphere MQ classes for Java).

    thx

    Ivan

    Hello Ivan,

     

    Thanks!!

    So we will use MQ  base classes meanwhile.

    Two Q's if you're not too busy: 

    1. For using it - do we have to customize OSGI_BUNDLES in JVM Profile (DFH$WLP)  to activate  MQ  middleware bundles  within JVMServer ?

    (if so - is there a documented example ?)

    2. Is there a  special sample code of  an applicative class using MQ base classes under CICS -  or we can use the sample MQSample.java under path like  /usr/lpp/mqm/...../java/samples/wmqjava/

    Regards,

     

    Yair

     

  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-08T08:55:36Z  
    • yairbar
    • ‏2013-07-08T06:30:18Z

    Hello Ivan,

     

    Thanks!!

    So we will use MQ  base classes meanwhile.

    Two Q's if you're not too busy: 

    1. For using it - do we have to customize OSGI_BUNDLES in JVM Profile (DFH$WLP)  to activate  MQ  middleware bundles  within JVMServer ?

    (if so - is there a documented example ?)

    2. Is there a  special sample code of  an applicative class using MQ base classes under CICS -  or we can use the sample MQSample.java under path like  /usr/lpp/mqm/...../java/samples/wmqjava/

    Regards,

     

    Yair

     

    Hi Yair,

     

    For a CICS Java program you would add the MQ classes to OSGI_BUNDLES. I'm not aware of any sample code or documentation beyond that provided by WebSphere MQ.

    thx

    Ivan

  • yairbar
    yairbar
    20 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-09T15:24:20Z  

    Hi Yair,

     

    For a CICS Java program you would add the MQ classes to OSGI_BUNDLES. I'm not aware of any sample code or documentation beyond that provided by WebSphere MQ.

    thx

    Ivan

    Helo Ivan,

    Thanks. 

    I have checked it (inc WMQ "Using Java" docs and by  a test  run) , and it  looks to me  like Base  MQ classes jars  are not provided  by WMQ  as OSGI Bundles (only JMS classes  are), so refering to them using OSGI_BUNDLES  in our DFHWLP profile for JVM w/Liberty doesnt work. 

    I suppose those classes  can be used only in a "regular"  non-Liberty/OSGi  (i.e. CLASSPATH controlled)  JVMServer in CICS, but I want use them from a JSP/Servlet  under Liberty.

    Am I   misunderstand framework  or  is it   really a problem ?

    Thanks again ,

    Yair

  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-09T17:56:37Z  
    • yairbar
    • ‏2013-07-09T15:24:20Z

    Helo Ivan,

    Thanks. 

    I have checked it (inc WMQ "Using Java" docs and by  a test  run) , and it  looks to me  like Base  MQ classes jars  are not provided  by WMQ  as OSGI Bundles (only JMS classes  are), so refering to them using OSGI_BUNDLES  in our DFHWLP profile for JVM w/Liberty doesnt work. 

    I suppose those classes  can be used only in a "regular"  non-Liberty/OSGi  (i.e. CLASSPATH controlled)  JVMServer in CICS, but I want use them from a JSP/Servlet  under Liberty.

    Am I   misunderstand framework  or  is it   really a problem ?

    Thanks again ,

    Yair

    Hi Yair,

    Those classes have been tested successfully in an OSGi (but non-Liberty) JVM server where they were placed on the OSGI_BUNDLES option. Are you picking up the later versions of the WMQ classes that have been 'bundle-ised'? I'll double-check with our test team which versions they used.

    If you use JVMProfile "DFHOSGI" - it will give you what we call an OSGi JVM server (subtly different from the DFHWLP profile to give you a Liberty JVM server), both are OSGi enabled. Neither is 'classpath' controlled.

    The OSGi JVM server with a 'Plug-in project' style Java application (deployed via a CICS bundle) should be able to use the MQ classes. We don't claim support for MQ classes in a Web application (but we know its a requirement that needs satisfying).

    The only use of 'classpath' in a JVM server is for Axis2 Web-services. We don't advocate use of classpath based applications in a JVM server except for Axis2 and something we called the Vendor Interface (DFHSJJI) introduced in CICS TS 4.1.

    ...Ivan

  • yairbar
    yairbar
    20 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-11T10:19:36Z  

    Hi Yair,

    Those classes have been tested successfully in an OSGi (but non-Liberty) JVM server where they were placed on the OSGI_BUNDLES option. Are you picking up the later versions of the WMQ classes that have been 'bundle-ised'? I'll double-check with our test team which versions they used.

    If you use JVMProfile "DFHOSGI" - it will give you what we call an OSGi JVM server (subtly different from the DFHWLP profile to give you a Liberty JVM server), both are OSGi enabled. Neither is 'classpath' controlled.

    The OSGi JVM server with a 'Plug-in project' style Java application (deployed via a CICS bundle) should be able to use the MQ classes. We don't claim support for MQ classes in a Web application (but we know its a requirement that needs satisfying).

    The only use of 'classpath' in a JVM server is for Axis2 Web-services. We don't advocate use of classpath based applications in a JVM server except for Axis2 and something we called the Vendor Interface (DFHSJJI) introduced in CICS TS 4.1.

    ...Ivan

     Hello Ivan,

    thanks.

    ...So adjusting to the current support level which you've mentioned but still not giving up  MQ CICS Java application  which we want to start under WEB container , pls  let me ask:

     Would it be possible to launch a main transaction as Servlet/JSP  in Liberty,  i.e. under JVMServer DFH$WLP, and issue a   'JCICS link program'    from it    to an OSGi applicative Class(which uses base MQ classes)  which is defined in CICS as Prograsm that  belongs to JVMServer DFH$JVMS (prof DFHOSGI)  -  would it be possible at all ?  if so, would it run under a single CICS task & LUW   in both JVMServers ???

    Thanks again,

    Yair   

     

  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-12T14:08:36Z  
    • yairbar
    • ‏2013-07-11T10:19:36Z

     Hello Ivan,

    thanks.

    ...So adjusting to the current support level which you've mentioned but still not giving up  MQ CICS Java application  which we want to start under WEB container , pls  let me ask:

     Would it be possible to launch a main transaction as Servlet/JSP  in Liberty,  i.e. under JVMServer DFH$WLP, and issue a   'JCICS link program'    from it    to an OSGi applicative Class(which uses base MQ classes)  which is defined in CICS as Prograsm that  belongs to JVMServer DFH$JVMS (prof DFHOSGI)  -  would it be possible at all ?  if so, would it run under a single CICS task & LUW   in both JVMServers ???

    Thanks again,

    Yair   

     

    Hi Yair,

    So the question... can I send a request to a Servlet application in a JVM server running Liberty technology, and then make a JCICS link from that servlet to an OSGi application either in the same JVM server, or another JVM server - is a very good question!

    It would run under the same UOW and CICS task, and in theory you could configure the OSGi application and the JVM server in the normal way (OSGI_BUNDLES) to access MQ base classes. I say in theory because I haven't tried it personally. You would of course have to deploy two CICS bundles, one for the Web application into the Liberty web container part of the JVM server, and then one for the OSGi bundle into the 'normal' OSGi framework part of the JVM server (and register a CICS-MainClass as the Java program entry point).

    One other mechanism I envisage, if you are using the very latest CICS TS v5.1 service (PM80214) is to put both the Web application as a WAB, and the OSGi bundle(s) inside an EBA, then deploy the EBA to CICS inside a CICS bundle project. Putting the MQ classes (bundles) in a bundle_repository in the Liberty server.xml *should* make them available to the application. Perhaps i will investigate this as a potential solution. We don't currently claim support for this, but my investigations may change that...

    thx

    Ivan

     

  • yairbar
    yairbar
    20 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-16T13:18:25Z  

    Hi Yair,

    So the question... can I send a request to a Servlet application in a JVM server running Liberty technology, and then make a JCICS link from that servlet to an OSGi application either in the same JVM server, or another JVM server - is a very good question!

    It would run under the same UOW and CICS task, and in theory you could configure the OSGi application and the JVM server in the normal way (OSGI_BUNDLES) to access MQ base classes. I say in theory because I haven't tried it personally. You would of course have to deploy two CICS bundles, one for the Web application into the Liberty web container part of the JVM server, and then one for the OSGi bundle into the 'normal' OSGi framework part of the JVM server (and register a CICS-MainClass as the Java program entry point).

    One other mechanism I envisage, if you are using the very latest CICS TS v5.1 service (PM80214) is to put both the Web application as a WAB, and the OSGi bundle(s) inside an EBA, then deploy the EBA to CICS inside a CICS bundle project. Putting the MQ classes (bundles) in a bundle_repository in the Liberty server.xml *should* make them available to the application. Perhaps i will investigate this as a potential solution. We don't currently claim support for this, but my investigations may change that...

    thx

    Ivan

     

    Hello Ivan,

    So as long as we are heading to find an optimal method for running JCICS-Base MQ applicatiion in this OSGi  framework, I have tested a Java application ,main class which is def'ined in CICS as Program, using a Bundle for JVMserver DFH$JVMS.

    I  made reference thru OSGI_BUNDLES in profile DFHOSGI to the jar that I think is supposed to be tha base-MQ classes OSGi bundle which should suit CICS also.

    The project has beeen compiled successfully in EClipse, the "import com.ibm.mq.* and the using of base MQseries objects had been accepted - but in run time under CICS I get a "compilation error" execption and all MQ objects are not resolved.

    I attach below the logs (dfhjvmerr & dfhjvmtrc) of my DFH$JVMS server, and my profile for DFHOSGI where you can see the OSGI_BUNDLES  path.

    Hope you will find time to help me further,

     

    Thanks

     

    Yair

  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-16T14:19:48Z  
    • yairbar
    • ‏2013-07-16T13:18:25Z

    Hello Ivan,

    So as long as we are heading to find an optimal method for running JCICS-Base MQ applicatiion in this OSGi  framework, I have tested a Java application ,main class which is def'ined in CICS as Program, using a Bundle for JVMserver DFH$JVMS.

    I  made reference thru OSGI_BUNDLES in profile DFHOSGI to the jar that I think is supposed to be tha base-MQ classes OSGi bundle which should suit CICS also.

    The project has beeen compiled successfully in EClipse, the "import com.ibm.mq.* and the using of base MQseries objects had been accepted - but in run time under CICS I get a "compilation error" execption and all MQ objects are not resolved.

    I attach below the logs (dfhjvmerr & dfhjvmtrc) of my DFH$JVMS server, and my profile for DFHOSGI where you can see the OSGI_BUNDLES  path.

    Hope you will find time to help me further,

     

    Thanks

     

    Yair

    Hi Yair,

    That error message indicates the OSGi plug-in project that you uploaded from the client development environment (Eclipse + CICS Explorer SDK) to CICS via a CICS bundle project did not actually compile successfully. Either that are there was an issue with building the bundle as part of the z/FS Export process.

    I'd start by double checking that your CICS bundle project includes the expected version of your OSGi plug-in, and that there are no warnings or errors in that application. You could also check that the export process was successful by inspecting the zFS directory to which the CICS bundle was exported. You should see a cics.xml manifest, which points to an osgibundlepart. You should also see a .jar which corresponds to your osgibundlepart - if you could open the .jar to ensure it contains the correct .class files for your application we could rule out an export problem.

    Beyond that, I think we need to look at the development environment. In particular have you enhanced the 'Target Platform' to include the MQ bundles? or have you added them to the 'build path'. Hopefully it's the former, as adding things to the build-path is not the OSGi way (and may cause problems).

    ...Ivan

  • yairbar
    yairbar
    20 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-21T14:11:23Z  

    Hi Yair,

    That error message indicates the OSGi plug-in project that you uploaded from the client development environment (Eclipse + CICS Explorer SDK) to CICS via a CICS bundle project did not actually compile successfully. Either that are there was an issue with building the bundle as part of the z/FS Export process.

    I'd start by double checking that your CICS bundle project includes the expected version of your OSGi plug-in, and that there are no warnings or errors in that application. You could also check that the export process was successful by inspecting the zFS directory to which the CICS bundle was exported. You should see a cics.xml manifest, which points to an osgibundlepart. You should also see a .jar which corresponds to your osgibundlepart - if you could open the .jar to ensure it contains the correct .class files for your application we could rule out an export problem.

    Beyond that, I think we need to look at the development environment. In particular have you enhanced the 'Target Platform' to include the MQ bundles? or have you added them to the 'build path'. Hopefully it's the former, as adding things to the build-path is not the OSGi way (and may cause problems).

    ...Ivan

    Hello Ivan,

    Following  your comments  i have examined my steps & infra again.

    It looks to me now that my prob has to do with the fact that the MQ OSGi Bundle contains a "Bundle-ClassPath" statement which refers to the very jars that are declared as "unresolved" when I run the application under DFH$JVMS.  And  I find no way to cause OSGi in Cics to resolve these jars at runtime.   Note that there is no prob when compiling at Eclipse - but only when the base MQ jars themselves are added to project's Build path. Only the MQ OSgi Bundle can be bound as plug-in dependency thru the target platform.  ( please have a look at the attached stuff...)

     It looks to me that we need (in addition to the plug-in project bundle and its accompanied Cics Bundle )  also some kind of  a "wrapper" bundle which would "export" all MQ jars, and that we declare "import" for them in our plug-in (the CiscMQ application)...does it make sense ? and if so - how do I generate such a bundle ?

    Anyway, I attach here 7 files which I hope would enable you to  examine the problem. One of them (""OSGi_Prob notes") describes briefly my deveop environment and  the rest of  attched files.

    Thanks again very much for helping us !

    Yair

     

    Updated on 2013-07-21T14:25:47Z at 2013-07-21T14:25:47Z by yairbar
  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-22T17:52:57Z  
    • yairbar
    • ‏2013-07-21T14:11:23Z

    Hello Ivan,

    Following  your comments  i have examined my steps & infra again.

    It looks to me now that my prob has to do with the fact that the MQ OSGi Bundle contains a "Bundle-ClassPath" statement which refers to the very jars that are declared as "unresolved" when I run the application under DFH$JVMS.  And  I find no way to cause OSGi in Cics to resolve these jars at runtime.   Note that there is no prob when compiling at Eclipse - but only when the base MQ jars themselves are added to project's Build path. Only the MQ OSgi Bundle can be bound as plug-in dependency thru the target platform.  ( please have a look at the attached stuff...)

     It looks to me that we need (in addition to the plug-in project bundle and its accompanied Cics Bundle )  also some kind of  a "wrapper" bundle which would "export" all MQ jars, and that we declare "import" for them in our plug-in (the CiscMQ application)...does it make sense ? and if so - how do I generate such a bundle ?

    Anyway, I attach here 7 files which I hope would enable you to  examine the problem. One of them (""OSGi_Prob notes") describes briefly my deveop environment and  the rest of  attched files.

    Thanks again very much for helping us !

    Yair

     

    Hi Yair,

    Please forgive any delayed responses I'm extremely busy on some internal activities. I haven't yet had chance to look at all your setup, but I did notice a couple of unusual things.

    The first thing that struck me was the use of Require-bundle. I would advise you to use Import-package instead. The problem with Require-bundle is that the contents of a particular bundle may change, or a package may better be provided in another bundle. Using Require-bundle reduces the flexibility of OSGi architecture.

    Also regarding the client setup, you mention the need to put jars on the project's build-path in order to resolve imports. I believe that may be the cause of the runtime issues and I suggest you remove them from the build-path. Instead I would expect the com.ibm.mq.osgi.java_7.1.0.1.jar to be added to the Target platform, and then corresponding Import-package statements in your application bundle be added to your manifest to resolve the Import statements in the Java source. In fact, you talk about having a single wrapper bundle as the solution - that is exactly what that jar is.

    For example, the jar  com.ibm.mq is 'wrapped' by com.ibm.mq.osgi.java... and the package com.ibm.mq is exported by this same bundle. The 'inner' jars never need referring to because the outer bundle exports their packages and the statement in the Manifest (Bundle-classpath) allows the outer bundle to expose the inner jars in a controlled fashion.

    So I'd expect that 'bundle' from the MQ OSGi directory to be placed in the Target platform on the client, and used in the JVMSERVER runtime via OSGI_BUNDLES. You should not need to add anything to the buildpath.

    I hope that helps,

    Ivan

  • yairbar
    yairbar
    20 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-24T07:07:54Z  

    Hi Yair,

    Please forgive any delayed responses I'm extremely busy on some internal activities. I haven't yet had chance to look at all your setup, but I did notice a couple of unusual things.

    The first thing that struck me was the use of Require-bundle. I would advise you to use Import-package instead. The problem with Require-bundle is that the contents of a particular bundle may change, or a package may better be provided in another bundle. Using Require-bundle reduces the flexibility of OSGi architecture.

    Also regarding the client setup, you mention the need to put jars on the project's build-path in order to resolve imports. I believe that may be the cause of the runtime issues and I suggest you remove them from the build-path. Instead I would expect the com.ibm.mq.osgi.java_7.1.0.1.jar to be added to the Target platform, and then corresponding Import-package statements in your application bundle be added to your manifest to resolve the Import statements in the Java source. In fact, you talk about having a single wrapper bundle as the solution - that is exactly what that jar is.

    For example, the jar  com.ibm.mq is 'wrapped' by com.ibm.mq.osgi.java... and the package com.ibm.mq is exported by this same bundle. The 'inner' jars never need referring to because the outer bundle exports their packages and the statement in the Manifest (Bundle-classpath) allows the outer bundle to expose the inner jars in a controlled fashion.

    So I'd expect that 'bundle' from the MQ OSGi directory to be placed in the Target platform on the client, and used in the JVMSERVER runtime via OSGI_BUNDLES. You should not need to add anything to the buildpath.

    I hope that helps,

    Ivan

    Hello Ivan,

    I have reinstalled my CicsMQappl  plug-in  project after updating the active Target platform and Manifests , following your recommendations ().

    Current status is:  Trying to set the SDK environment first (i.e.at Eclipse) The "import" statements for the Base MQ entities within my source remain unresolved, after I have removed MQ jars from Build path and left out only  the references to OSGi bundles.

    For  Target Platform the MQ OSGi bundle and jars are installed under path .../targets/cics51  and  exposed to the target platform definition as "content of location" and also as "implicit dependencies".  Both" cics.server..."  and "mq.osgi.java.."  appear in the package explorer tree under  "plug-in dependencies" folder title.

    Manifest of the plug-in contains explicit "Import-Package" statement for Base MQ packages and their IBM's bundle is "Required".

    The IBM's given Manifest of MQ bundle declares those packages ("Export"...), and  of course we cannot manipulate it.

    Attached the two Manifests and the JVMserver's error log(dfhjvmerr).

    Your answers are welcomed at any time which is convenient to you, no prob.

    Thanks,

    Yair

  • IvanHargreaves
    IvanHargreaves
    27 Posts

    Re: MQ/JMS probs under CICS5.1 JVMServer

    ‏2013-07-24T08:54:02Z  
    • yairbar
    • ‏2013-07-24T07:07:54Z

    Hello Ivan,

    I have reinstalled my CicsMQappl  plug-in  project after updating the active Target platform and Manifests , following your recommendations ().

    Current status is:  Trying to set the SDK environment first (i.e.at Eclipse) The "import" statements for the Base MQ entities within my source remain unresolved, after I have removed MQ jars from Build path and left out only  the references to OSGi bundles.

    For  Target Platform the MQ OSGi bundle and jars are installed under path .../targets/cics51  and  exposed to the target platform definition as "content of location" and also as "implicit dependencies".  Both" cics.server..."  and "mq.osgi.java.."  appear in the package explorer tree under  "plug-in dependencies" folder title.

    Manifest of the plug-in contains explicit "Import-Package" statement for Base MQ packages and their IBM's bundle is "Required".

    The IBM's given Manifest of MQ bundle declares those packages ("Export"...), and  of course we cannot manipulate it.

    Attached the two Manifests and the JVMserver's error log(dfhjvmerr).

    Your answers are welcomed at any time which is convenient to you, no prob.

    Thanks,

    Yair

    Hi Yair,

    On the 'content' tab of the Target Platform (in edit) have you selected the com.ibm.mq.osgi.java package? Even though it is visible does not always mean it is selected. You don't need any entries in 'Implicit Dependencies'.

    I can't see any attachments in the last message, but in your Applications manifest I expect to see some Import-package statements, like in my example below.

    Manifest-Version: 1.0
    Bundle-ManifestVersion: 2
    Bundle-Name: Mq
    Bundle-SymbolicName: com.ibm.cics.ivan.mq
    Bundle-Version: 1.0.0
    Bundle-Vendor: IBM
    Bundle-RequiredExecutionEnvironment: JavaSE-1.6
    Import-Package: com.ibm.mq,
     com.ibm.mq.constants
    CICS-MainClass: com.ibm.cics.ivan.mq.test.MQTest
     

    You don't need any entries in 'Required Plug-ins'. It should be empty. Don't forget to save and 'apply' the edited Target Platform and then perform a 'clean' build of your application project.

    If you prefer (and there is no confidential or sensitive information in your application) you can e-mail me the project and related files and I can take a look at it (ivanh@uk.ibm.com). It may also be worth looking at the XML source of your Target Platform as I have seen a number of Eclipse bugs when these are generated. One way to do this is goto "Window | Preferences | Plug in development | Target Platform" select your Target platform and click the 'share' button. Give it a name, and pick your application project as the destination. Within your project a file is created   "nnnnn.target". Right clicking on this file allows you to select "Open with XML editor" from where you can see the xml source. If you want to send that to me I can check it over.

    thx

    Ivan