Hot Deploy with JBM 2

[ataylor]

As part of the move to using POJO's we have lost some of the functionality we get from mbeans being redeployed on changes to the configuration. Since all the configuration is in one file we have to decide how best to replace this functionality.

As it stands now we deploy a directory structure that looks as follows:

|-- META-INF
| `-- jbm-beans.xml
|-- jbm-configuration.xml
|-- jgroups.jar
|-- mina-core.jar
|-- slf4j-api-1.4.3.jar
`-- slf4j-log4j12.jar

At the minute any changes to the jbm-configuration.xml file will force a redeploy (albeit there is a bug in JBoss 5 Beta 3 and it doesnt work).

However i think we should go for the following deployment configuration: deploy as an actual archive, which would have the same structure as above apart from the jbm-configuration.xml file which we would put in the conf dir. We then implement our own redeployment of changes to the config file, and also support multiple configuration files. This means that users can ship apps with a built in configuration file specific to the app.

thoughts?

PS Ive already implemented this on my local machine so not to much work would be involved.

[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.

[ataylor]

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.

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.

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.

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?

[timfox]

"ataylor" wrote:


What about configuring destination properties such as redeliverydelay etc, where would these be held.

Any overrides can be specified on any group of queues using wildcards in the queues.xml file.

what about topics, how would the security work since the user may not know the name of each consumer at deployment time?

Can you elaborate on that?

[ataylor]

its ok, ive ready the other post.