As of Jetspeed 1.6, Jetspeed now supports the JMS API. This is done through the new Messaging service. While the interface is able to support a JMS 1.0.2 implementation, the AbstractJMSMessagingService makes use of the JMS 1.1 API to provide easier integration with other JMS implementations.
Currently, Jetspeed uses ActiveMQ as the JMS implementation. In order to substitute another JMS 1.1 compatiable implementation, all that needs to be done is to derive from the AbstractJMSMessagingService, implementing the createConnection method. Also, any unique parameters that your JMS implementation needs will need to be configured in the new implementations init() method.
The Messaging service allows Jetspeed to be ran in a multi-node configuration (multiple Jetspeed instances running in different VMs or different webapps). When configured properly, Jetspeed's Registry and SecurityCache services will enable listeners on appropriate JMS topics. When a registry entry is updated or a change is made in the security (user/role/group), a message will be sent to the topic. The other nodes will receive the message and clear their cache of the appropriate item. The next access to the same item will cause Jetspeed to reload the information from the underlying storage mechanism.
You will need to setup a central database where the data (Registry/Security) will be stored. Without this, the Messaging service will yield no results. When the services reload their data, they will still be loading from the local files.
In order to activate the messaging service, the following property will
need to be added to the JetspeedResources.properties file.
No other configuration is needed. If you wish to configure the service, see the section on configuration.
This will enable the Messaging service. However, the Registry and SecurityCache service will not use it by default.
To enable the use of the Messaging service, add the following propertis to the JetspeedResources.properties file.
|url||The URL for the service to connect to. If this is specified, the other parameters are ignored||Configured by the Implementation||rmi://localhost:616161|
|schema||The connection schema||Configured by the Implementation||http, rmi, tcp|
|host||The server to connect to||Configured by the Implementation||localhost|
|port||The port to connect to||Configured by the Implementation||8080, 61616|
|name||Extra path information, servlet name||Configured by the Implementation||jmsservlet|
|connection_factory||Classname of the JNDI connection factory||Configured by the Implementation||org.apache.jndi.my.factory|
|transacted||Whether the messages should be transacted or not||false||true/false|
|ack_mode||The acknowledgement mode of the session||auto||auto, client, dups_ok|
|topic_enabled||Chooses between queues and topics||true||true/false|
|durable||Enables the client to receive messages that are persistent and were sent while the client was not listening||false||true/false|
|nolocal||Whether the local node should also receive messages generated by the same node.||true||true/false|
|delivery_mode||Whether messages should persist beyond the life of the sender||non_persistent||non_persistent, persistent|
|priority||The priority of the message being sent||0||0 < X < 10|
|time_to_live||How long the message should live||0||0 < 2^16|