[mule-user] serviceOverrides

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[mule-user] serviceOverrides

Andrew Perepelytsya
Hello All,

I'm trying to find out if there is a way to pass the properties to the
underlying javax.jms.ConnectionFactory. For example, JmsConnector has
the providerProperties, but it sets JNDI props. ActiveMQ wants some
properties set to be configured, but currently there's no way to pass
the values from JmsConnector XML section to the ConnectionFactory it
uses.

I remember serviceOverrides was targeted at the mule's infrastructure,
so not sure it is the way to go. Anyway, before I file the bug and
patch the code, I want to confirm my findings.

Regards,
Andrew
Reply | Threaded
Open this post in threaded view
|

Re: [mule-user] serviceOverrides

Foo Shoong Weng
Hi Andrew,

Is the following what you looking for?

<properties>
            <property name="acknowledgeMode" value="1"/>
           -<property name="specification" value="1.1"/>
             ...

            *<map name="providerProperties">
                <property name="java.naming.referral"
value="throw"/>          
                ** <property name="otherProperty"
value="value"/>            *
*            </map>*
</properties>

Hope it helps.

Best rgds,
Weng

Andrew Perepelytsya wrote:

>Hello All,
>
>I'm trying to find out if there is a way to pass the properties to the
>underlying javax.jms.ConnectionFactory. For example, JmsConnector has
>the providerProperties, but it sets JNDI props. ActiveMQ wants some
>properties set to be configured, but currently there's no way to pass
>the values from JmsConnector XML section to the ConnectionFactory it
>uses.
>
>I remember serviceOverrides was targeted at the mule's infrastructure,
>so not sure it is the way to go. Anyway, before I file the bug and
>patch the code, I want to confirm my findings.
>
>Regards,
>Andrew
>
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: [mule-user] serviceOverrides

Andrew Perepelytsya
:)) oh yeah, the same mistake.

The point is those are not working. The name is misleading, as it is
__JNDI__ provider properties, not the connectionfactory. The doc is
also wrong in that respect (see jira.muleumo.org/browse/MULE-308).

I have already fixed the problem locally, so if there will be no other
suggestions in some time, I will post the test cases and patches.

Best regards,
Andrew
Reply | Threaded
Open this post in threaded view
|

Re: [mule-user] serviceOverrides

Ross Mason-x
What we could do here is as well as pass the provider properties via the
Jndi context, we could also apply the the properties to the
ConnectionFactory object using
BeanUtils.setPropertiesWithoutFail(connectionFactory, providerProperties);

While I would usually frown on the this dual role of the
providerProperties it does seem the logical place for developers to set
these attributes for both scenarios.

Cheers,

Ross

Andrew Perepelytsya wrote:

>:)) oh yeah, the same mistake.
>
>The point is those are not working. The name is misleading, as it is
>__JNDI__ provider properties, not the connectionfactory. The doc is
>also wrong in that respect (see jira.muleumo.org/browse/MULE-308).
>
>I have already fixed the problem locally, so if there will be no other
>suggestions in some time, I will post the test cases and patches.
>
>Best regards,
>Andrew
>
>
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: [mule-user] serviceOverrides

Andrew Perepelytsya
What I did is added the connectionFactoryProperties to JmsConnector.
Sounds reasonable. I would go as far as renaming providerProperties to
jndiProviderProperties, but afraid cannot do this in order to keep the
API compatibility.

What do you think?
Reply | Threaded
Open this post in threaded view
|

Re: [mule-user] serviceOverrides

Guillaume Nodet
Andrew Perepelytsya a ?crit :

>What I did is added the connectionFactoryProperties to JmsConnector.
>Sounds reasonable. I would go as far as renaming providerProperties to
>jndiProviderProperties, but afraid cannot do this in order to keep the
>API compatibility.
>
>What do you think?
>
>
>  
>
You can, if you keep the old setter and deprecate it :)

Cheers,
Guillaume Nodet