-
1. Re: JBM 2.0 destination config.
ataylor Jan 7, 2008 6:13 AM (in response to timfox)Its definitely a more elegant and flexible approach, however we have to make sure that it doesn't become unintuitive to a user. Most of them are actually wanting to configure a JMS system as easily as possible, They shouldn't have to understand the concept of a messaging system that only deals with queue's.
-
2. Re: JBM 2.0 destination config.
timfox Jan 7, 2008 6:22 AM (in response to timfox)For a JMS user, they just need to add their connection factory and/or destinations in the jms-jndi.xml file (or whatever we want to call it).
This is the one that instantiates the jms objects and puts them in JNDI. This is not really any different to how it currently works. -
3. Re: JBM 2.0 destination config.
ataylor Jan 7, 2008 6:29 AM (in response to timfox)For a JMS user, they just need to add their connection factory and/or destinations in the jms-jndi.xml file (or whatever we want to call it).
but still have to configure the security elsewhere in the queues.xml file, or am i missing something.
Removing the JNDI stuff is down as a JIRA task for me to do, so this probably needs doing first. I'll add a comment to it that we need a seperate JBoss service to that takesd care of adding destinations and factories via the jms-jndi.xml file. Also, it might make sense to move some(or all then we'll have a clean seperation) of the exposed JMX methods, createqueue for instance would expect it to be added to JNDI. -
4. Re: JBM 2.0 destination config.
timfox Jan 7, 2008 6:35 AM (in response to timfox)"ataylor" wrote:
but still have to configure the security elsewhere in the queues.xml file, or am i missing something.
The default security will probably be fine without changes for the majority of users, but if they want to change it from the default then they just do something like:<security match = "queues.finance.stocks.*"> <permission="read", roles="traders"> <permission="write", roles="admin"> </security>
-
5. Re: JBM 2.0 destination config.
ataylor Jan 7, 2008 6:39 AM (in response to timfox)The default security will probably be fine without changes for the majority of users, but if they want to change it from the default then they just do something like:
Ok
Will jms-jndi.xml be hot deployable as well? -
6. Re: JBM 2.0 destination config.
timfox Jan 7, 2008 7:04 AM (in response to timfox)Can't we just make them a standard MC POJO service and get hot deployability for free?
-
7. Re: JBM 2.0 destination config.
ataylor Jan 7, 2008 7:09 AM (in response to timfox)Can't we just make them a standard MC POJO service and get hot deployability for free?
As long as the jms-jndi.xml file is under the same deployment path as the ..-beans.xml mc config file. Anything changed under the deployment path gets redeployed. -
8. Re: JBM 2.0 destination config.
timfox Jan 7, 2008 7:12 AM (in response to timfox)E.g.:
jndi-jms.xml:<bean name="JBM_JBMS_JNDI_Objects" class="org.jboss.messaging.jms.jndi.JNDIObjectDeployer"> <property name="queues"> <entry name="myqueue1"/> <entry name="myqueue2"/> </property> <property name="topics"> <entry name="mytopic1"/> </property> </bean>
-
9. Re: JBM 2.0 destination config.
ataylor Jan 7, 2008 7:16 AM (in response to timfox)thats fine but i thought we had decided that we want to move away from having configuration in the deployment file. so we would have:
jms-deployer-beans.xml<bean name="JBM_JBMS_JNDI_Objects" class="org.jboss.messaging.jms.jndi.JNDIObjectDeployer"> </bean>
and then a separate config file(s)
jndi-jms.xml<queues> <entry name="myqueue1"/> <entry name="myqueue2"/> </queue> <topics> <entry name="mytopic1"/> </topic>
-
10. Re: JBM 2.0 destination config.
timfox Jan 7, 2008 7:40 AM (in response to timfox)Yes we could do that.
You'll have to manually code the redeploy functionality, but when we run standalone we probably still want to retain hot deploy functionality without being reliant on the JBoss MC deployers, so this is probably a good thing. -
11. Re: JBM 2.0 destination config.
ataylor Jan 7, 2008 10:19 AM (in response to timfox)Ok, I'll do that at the same time i remove the jndi dependancy
-
12. Re: JBM 2.0 destination config.
starksm64 Jan 8, 2008 1:50 AM (in response to timfox)You also need to think about the metadata model that will be exposed as the management interface as that is generally how the destinations will be managed in jbossas 5+.
-
13. Re: JBM 2.0 destination config.
ataylor Jan 9, 2008 10:04 AM (in response to timfox)Should we have a seperate file for configuring Connection Factories in the same manner, say factories.xml? which would look like:
<factory-settings match="jboss.messaging.connectionfactory:service=MyExampleConnectionFactory"> <client-id>MyClientID</client-id> <prefetch-size>150</prefetch-size> <default-temp-queue-full-size>200000</default-temp-queue-full-size> <default-temp-queue-page-size>2000</default-temp-queue-page-size> <default-temp-queue-down-cache-size>2000</default-temp-queue-down-cache-size> <dups-ok-batch-size>5000</dups-ok-batch-size> <supports-failover>false</supports-failover> <supports-load-balancing>false</supports-load-balancing> <load-balancing-factory>org.jboss.jms.client.plugin.RoundRobinLoadBalancingFactory</load-balancing-factory> <strict-tck>true</strict-tck> <disable-remoting-checks>false</disable-remoting-checks> </factory-settings>
also do we need to have defaults in the jbm-configuration.xml file if we have a catch all default in both these files?
e.g.<queue-settings match="*"> <clustered>false</clustered> <full-size>200000</full-size> <page-size>2000</page-size> <down-cache-size>2000</down-cache-size> <dlq>DLQ</dlq> <expiry-queue>ExpiryQueue</expiry-queue> <redelivery-delay>0</redelivery-delay> <max-size>-1</max-size> <max-delivery-attempts>10</max-delivery-attempts> </queue-settings>
-
14. Re: JBM 2.0 destination config.
timfox Jan 9, 2008 10:11 AM (in response to timfox)"ataylor" wrote:
Should we have a seperate file for configuring Connection Factories in the same manner, say factories.xml?
I don't think there is any need for that - we can just put them in jms-jndi-objects.xml with the jms jndi destinations.
No need to a core file since with core, connection factories are not repreloaded - they are created by the user.
also do we need to have defaults in the jbm-configuration.xml file if we have a catch all default in both these files?
I don't think that's necessary - we can just specify the settings in jms-jndi-objects.xml