Problem with "wsDefaultBindings" ant task - Websphere

This is a discussion on Problem with "wsDefaultBindings" ant task - Websphere ; Hello! WebSphere offers an ant task "wsDefaultBindings" based on the class "com.ibm.websphere.ant.tasks.DefaultBindings" which helps with the mapping of the ejb jndi names, resource jndi names etc. My application uses MDBs with listener post (EJB 2.0), the JMS provider is MQ. ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Problem with "wsDefaultBindings" ant task

  1. Problem with "wsDefaultBindings" ant task

    Hello!

    WebSphere offers an ant task "wsDefaultBindings" based on the class "com.ibm.websphere.ant.tasks.DefaultBindings" which helps with the mapping of
    the ejb jndi names, resource jndi names etc.

    My application uses MDBs with listener post (EJB 2.0), the JMS provider is MQ.

    An ant script building the ear file creates a wrong IBM EJB DD for MDBs which contains not listener ports but activation spec:








    The resulting ear cannot be installed on the server and has to be fixed manually.

    I'd appreciate your help!

    Thanks!


  2. Re: Problem with "wsDefaultBindings" ant task

    I experienced a similar issue where when using the defaultbindings
    option, I could not override the activation spec default so that an
    application could be scripted and installed to use a ListenPort. In
    summary, it seems that the fefaultingbindgs "default" is to utilize
    the activation spec instead of the listener spec. As long as you use
    default bindings I don't think it's possible to override this bias--at
    least I didn't find a way around it.

    However, I resolved the issue by avoiding the generate default
    bindings option entirely and explicitly supplying mappings for the
    necessary bindings (not a bad practice when you think about it).

    Instead I specified the necessary bindings by utilizing a WebSphere
    strategy file based on IBM's dfltbnding

    In this file I explicitly mapped the necessary bindings and then
    specified the strategy file as part of my install.options string of
    options.
    As an alternative, you might be able to include all the install
    options in the install.options parameter.

    But I personally like to use a strategy file because a strategy file
    can be "reused" and becomes part of one's application deployment set
    of reusable artifacts.

    If you decide to go the deployment strategy route you can find the dtd
    IBM supplies for creating the strategy file in the following
    location: /opt/IBM/WebSphere6/AppServer/properties/dfltbndgs.dtd

    This dtd include some very good examples of how to use the deploy
    strategy to bind resource to application--well worth looking into.

    I will post some specific examples this weekend. My company hosts a
    (nascent) forum dedicated to WebSphere application configuration and
    deployment at http://www.bronzedrum.com/Forums

    Best Regards,

    Brian McCallion

    http://www.bronzedrum.com



+ Reply to Thread