IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST - Websphere

This is a discussion on IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST - Websphere ; Hello. I'm experiencing a big problem when using MQ Workflow API 3.6 and IBM Struts Portlets 5.0.2. I have not been able to encapsulate the Workflow API in a class, for example, WorkflowDelegate component, because in runtime either in WSAD ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST

  1. IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST

    Hello.
    I'm experiencing a big problem when using MQ Workflow API 3.6 and IBM Struts Portlets 5.0.2. I have not been able to encapsulate the Workflow API in a class, for example, WorkflowDelegate component, because in runtime either in WSAD or WAS, when the code line that instantiates WorkflowDelegate (in the Struts action) is reached the class logic finishes but no exception is thrown. But if the Worflow API is embedded in the Struts action class or JSP, it works fine!

    In short, when using struts portlets and workflow API, if you encapsulate workflow API in a business class in the web or business tiers, anywhere, that class is just not loaded, but the worst is that no exception is thrown. In both WSAD and WAS/WPS.

    The idea is to apply a design pattern to encapsulate the Workflow API in a reusable integration tier component, but if it's not possible because of that bug, all the Workflow API code will have to be replicated in every each Struts action or JSP and maintenance will be a nightmare!

    Does anybody know if there's a discussion, workaround or reference about this bug? I'll appreciate enormously any valuable help.

    Thank you in advance.

    Best regards.


  2. Re: IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST

    I had to catch Throwable to get the exception:

    try {
    ArrayList workitems = logWorflowAdapter.getWorkItems(workflowContext);
    } catch (Throwable e) {
    log.error(e.getMessage());
    }

    And the exception is:
    "Native Library D:\Archivos de programa\IBM\WebSphere MQ\Java\lib\mqjbnd05.dll already loaded in another classloader"

    I thought that the new workflow API 3.6 was pure Java, but it seems that it doesn't. It appears that continues using JNI and causing problems with the classloader. Is there any workaround or solution related to it?

    Thanks.




  3. Re: IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST

    Well....

    The native Java API 3.6 IS pure Java.
    Unfortunately the undelying MQ API is not ;-)
    As far as I know the client part of the MQ API should be pure Java.
    You should use the client MQ API anyway for MQWF Java client programs
    even if you have installed MQ Server API on your box.
    Please tell us whether this solves your problem.

    Volker Hoss
    IBM WebSphere MQ Workflow Development

  4. Re: IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST

    Useful information, Volker! I did a research about what you wrote and I solved the problem with this article:

    http://www-128.ibm.com/developerwork..._kulhanek.html

    Thanks! :-)

  5. Re: IBM MQ Workflow API and IBM Struts Portlets CAN NOT CO-EXIST

    Azbel,

    I have to make a comment on you reference to Wolgang's article.
    This article describes the problem of the former MQWF Java API (based on
    JNI)
    and how to overcome it so that you can run multiple applications using the
    MQWF Java API.

    This description is obsolete now with the MQWF 3.6 native Java API!
    The only valid point is that you must ensure that MQ is loaded by a global
    classloader of the AppServer. This is usually achieved by setting the
    WebSphere
    MQ_INSTALL_ROOT variable.

    Volker Hoss
    IBM WebSphere MQ Workflow Development

+ Reply to Thread