The weird case of a JMS Proxy Service who failed to deploy

But it was reported as "Enabled" in the Operations console...

Some JMS messages were stuck in a AcmeQ

In the JMS Queue monitoring tab, we verified that no consumer was registered in any instance of the queue.

In JNDI tree, all the queues and connection factories were deployed.

In the deploment tab, it was noticed that 11 deploments exists with name _ALSB_nnnnnnnnnn.ear

while in the /opt/oracle/domains/osbpr1do/sbgen/ there were 12 ears.
Each of there ears contain the MDB corresponding to a JMS proxy service.

Unjarring each ear and examining the application.xml revealed that /opt/oracle/domains/osbpr1do/sbgen/_ALSB_1339780728059.ear was the AcmeQ ear,

and that it was NOT in the WebLogic config.xml as a deployment.

(normally there should be a section

<app-deployment>

    <name>_ALSB_1339780726229</name>

    <target>osbpr1cl</target>

    <module-type>ear</module-type>

    <source-path>sbgen/_ALSB_1339780726229.ear</source-path>

    <plan-dir>shared/osb/config/plan</plan-dir>

    <plan-path>Plan-_ALSB_1339780726229.ear.xml</plan-path>

    <security-dd-model>DDOnly</security-dd-model>

    <staging-mode>stage</staging-mode>

  </app-deployment>

for each ALSB ear)



It was taken the resolution to

- export into a sbconfig.jar the Acme OSB project alone

- delete the Acme OSB project and activate

- reimport the Acme OSB project and activate


this fixed the issue and the JMS messages were consumed.