1 2 Previous Next 23 Replies Latest reply on Jan 9, 2008 11:31 AM by ataylor

    JBM 2.0 destination config.

    timfox

      I would like to propose the following for JBM 2.0 declarative queue security and destination settings overrides.

      I believe it is more elegant and flexible than the current 1.x approach.

      Note that in JBM 2.0 messaging core, *everything* is a queue - core does not know about JMS topics and queues.

      A JMS queue is a queue and a JMS topic subscription is also a queue.

      A JMS queue has a name something like:

      
      queues.acme.orderprocessing.inputqueue1
      
      


      A JMS topic subscription is just a queue with a name something like:

      
      topics.acme.marketdata.RHAT.xyz123
      
      or
      
      topics.acme.newsfeed.europe.*
      
      


      The declarative security is hierarchical and can work with wildcards.

      E.g.

      
      <!-- default - deny all creates -->
      <security match="queues.*">
       ...
      </security>
      
      <security match = "queues.finance.stocks.*">
       <permission="read", roles="all">
       <permission="write", roles="admin">
      </security>
      
      


      We should also allow the ability to specify groups of override settings for groups of queues, e.g.

      e.g.
      
      <queue-settings match="queues.stocks.*">
       <max-size>10000</max-size>
       <no-persistence>true</no-persistence>
       <lazy-load>true</lazy-load>
      </queue-settings>
      
      


      This should probably go in a file called queues.xml which is loaded by core on startup.

      The file should be hot deployable.




        • 1. Re: JBM 2.0 destination config.
          ataylor

          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

            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

               

              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

                 

                "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

                   

                  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

                    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

                       

                      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

                        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

                          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

                            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

                              Ok, I'll do that at the same time i remove the jndi dependancy

                              • 12. Re: JBM 2.0 destination config.
                                starksm64

                                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

                                  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

                                     

                                    "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

                                    1 2 Previous Next