[Design of Messaging on JBoss (Messaging/JBoss)] - JBM 2.0 destination config.
by 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117491#4117491
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117491
18 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Hot Deploy with JBM 2
by ataylor
anonymous wrote : The JBM 2.0 messaging core will be JMS agnostic, but is also a fully functioning messaging system that can be used/ embedded for OEMs etc.
|
| The core should know nothing about JMS queues, topics, or durable subscriptions since these are JMS concepts, not core concepts.
I agree.
anonymous wrote : Therefore the core should have no destination deployment configuration at all.
What about configuring destination properties such as redeliverydelay etc, where would these be held.
anonymous wrote : With core, connection factories are created directly (new JBossConnectionFactory()), so there is no need for them to exist in JNDI, same for destinations.
Again, where would we set these properties.
anonymous wrote : So, it's the security policy that determines whether users can create, read or write to a queue, the actual queues are created on the fly (if the security config allows it).
what about topics, how would the security work since the user may not know the name of each consumer at deployment time?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117489#4117489
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117489
18 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Hot Deploy with JBM 2
by timfox
I have been thinking about this (and other things - more later) a lot over the Christmas period.
I would like to make some changes, that I believe would make our system's configuration much simpler and more elegant.
The JBM 2.0 messaging core will be JMS agnostic, but is also a fully functioning messaging system that can be used/ embedded for OEMs etc.
The core should know nothing about JMS queues, topics, or durable subscriptions since these are JMS concepts, not core concepts.
Therefore the core should have no destination deployment configuration at all.
With core, connection factories are created directly (new JBossConnectionFactory()), so there is no need for them to exist in JNDI, same for destinations.
We can avoid a destination deployment script altogether - instead destinations are created on the fly as users use them - the first to use a destination creates it.
We then control access as to who can create, read and write using our security policy - so there's no need for destination deploy/undeploy etc. Just need a security policy.
The security policy should be overhauled to work hierarchically, e.g. you would declare something like:
| <security name="topics.newsfeed.bbc.*">
| <role name="guest" read="true" write="false"/>
| <role name="publisher" read="true" write="false" create="false"/>
| <role name="admin" read="true" write="true" create="true"/>
| </security>
|
| <security name="*">
| ..default security...
| </security>
|
| <security name="tmp.*">
| ...temp destination security...
| </security>
|
| etc
|
|
So, it's the security policy that determines whether users can create, read or write to a queue, the actual queues are created on the fly (if the security config allows it).
This removes the need for a redeployable destination deployment file. The only thing that needs to be hot deployable is the security policy.
So that's the core messaging.
Now, for JMS we have a further requirement of "JMS administered objects" (see JMS spec).
These are the connection factories and JMS queues and topics that the user may want preconfigured in JNDI.
This is not part of the messaging core, and is very simple to implement - just a trivial JBoss service that instantiates the connection factory and destination objects and inserts them in JNDI - this service does not need to talk to messaging core at all - it's completely independent.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117471#4117471
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117471
18 years, 3 months
[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test
by akostadinov
"ryan.campbell(a)jboss.com" wrote :
| Well, the process.destroy logic doesn't seem to work from what I've seen. So it's basically a useless line.
| This is why Dimitris suggested the use of the -H option to try to clean things up. Can you replace the process.destroy with the shutdown -H ?
|
>From my testing of jboss-test/trunk, destroy does work. But it is not yet released and used for AS 5. I think Martin Vecera fixed the logic. Martin, right? AFAICT before Martin's changes it worked on ant exit only effectively breaking the test suite execution.
You could test trunk with /qa/tools/opt/jboss-test-1.0.5-SNAPSHOT.jar
"ryan.campbell(a)jboss.com" wrote :
| What about setting the value of this property to the name of the server config which fails? That way we can have a line which says:
|
| "The "tomcat-sso-cluster-01 server failed to stop"
|
| Even if we have multiple servers failing to stop, it is enough to know that one failed.
|
That makes sense!
"ryan.campbell(a)jboss.com" wrote :
| I'm fine with you making these changes.
|
Cool, I'll try to do these this week.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117439#4117439
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117439
18 years, 3 months
[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test
by akostadinov
Well, the process.destroy logic doesn't seem to work from what I've seen. So it's basically a useless line.
This is why Dimitris suggested the use of the -H option to try to clean things up. Can you replace the process.destroy with the shutdown -H ?
>From my testing of jboss-test/trunk, destroy does work. But it is not yet released and used for AS 5. I think Martin Vecera fixed the logic. Martin, right? AFAICT before Martin's changes it worked on ant exit only effectively breaking the test suite execution.
You could test trunk with /qa/tools/opt/jboss-test-1.0.5-SNAPSHOT.jar
What about setting the value of this property to the name of the server config which fails? That way we can have a line which says:
"The "tomcat-sso-cluster-01 server failed to stop"
Even if we have multiple servers failing to stop, it is enough to know that one failed.
That makes sense!
I'm fine with you making these changes.
Cool, I'll try to do these this week.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117438#4117438
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117438
18 years, 3 months