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:

<ejbBindings xmi:type="com.ibm.ejs.models.base.bindings.ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="jms/vertrag_vertrag_pran_Worker_1_0_Activation" destinationJndiName="jms/vertrag_vertrag_pran_Worker_1_0_PackageCreator_Worker">
<enterpriseBean xmi:type="com.ibm.etools.ejb:MessageDriven" href="META-INF/ejb-jar.xml#PranWorkerMDB"/>
<ejbRefBindings xmi:id="EjbRefBinding_1170172349439" jndiName="ejb/pran//PranWorkerHome">
<bindingEjbRef href="META-INF/ejb-jar.xml#ejb_mdb_worker"/>
</ejbRefBindings>
</ejbBindings>

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

I'd appreciate your help!

Thanks!

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 [url]http://www.bronzedrum.com/Forums[/url]

Best Regards,

Brian McCallion

[url]http://www.bronzedrum.com[/url]