[clebert.suconic]

@AndyTaylor: What I did to create the hornetq-int was to rename the old project, and delete a bunch of stuff we don't need any more. On the process I forgot to rename the base package name.

I think we should make it org.jboss.hornetq.spi..

any better idea? there will be implementations on the package also such as the jopr integration, deployers.. etc.

[timfox]

I'd rather not use that package name as it's confusingly similar to our own HornetQ spi packages.

Any spi that JBoss AS offers for messaging server integration should be part of the jboss as package structure, not hornetq's

E.g. org.jboss.as.spi.messaging.*

or something like that

The point of an spi is it allows integration of any messaging provider that implements the spi, therefore provider specifics such as hornetq should not be in the package name

[ataylor]

I will rename my packages as Tim suggests.

The JOPR plugin I am writing works like this. For each HornetQ management object,  i.e. JMSServerControl , there will be a discovery component which will take care of looking up the objects concerned and a standard component for displaying the attributes, metrics and invoking operations. This is the standard way jopr plugins are implemented. The plugin will be connect to the local server but will also allow remote HornetQ servers to be added so a whole cluster can be managed.

The discovery components will lookup mbeans for the particular type. i.e. queue. topic, JMSServer, and the standard component will use this mbean to query attributes or invoke operations. The code will be generic and the jopr config will be mapped 1 to 1 to all out operations etc.

Here's a snippet of the jopr hornetq config:

<service name="HornetQ JMS Server"
            discovery="HornetQJMSServerDiscoveryComponent"
            subCategory="JMS"
            class="HornetQJMSServerComponent"
            singleton="true">
            <operation name="createQueue" displayName="Create a JMS Queue" description="Create a JMS Queue.">
               <parameters>
                    <c:simple-property required="true" name="queueName" displayName="queue name"/>
                  <c:simple-property required="true" name="String:jndiBinding" displayName="jndi binding"/>
                </parameters>
               <results><c:simple-property name="operationResult" description="The Outcome of creating the queue."/></results>
            </operation>
            <operation name="destroyQueue" displayName="Destroy a JMS Queue" description="Destroy a JMS Queue.">
               <parameters>
                    <c:simple-property required="true" name="queueName" displayName="queue name"/>
                </parameters>
               <results><c:simple-property name="operationResult" description="The Outcome of destroying the queue."/></results>
            </operation>
            <operation name="createTopic" displayName="Create a JMS Topic" description="Create a JMS Topic.">
               <parameters>
                    <c:simple-property required="true" name="topicName" displayName="topic name"/>
                  <c:simple-property required="true" name="jndiBinding" displayName="jndi binding"/>
                </parameters>
               <results><c:simple-property name="operationResult" description="The Outcome of creating the topic."/></results>
            </operation>
            <operation name="destroyTopic" displayName="Destroy a JMS Topic" description="Destroy a JMS Topic.">
               <parameters>
                    <c:simple-property required="true" name="topicName" displayName="topic name"/>
                </parameters>
               <results><c:simple-property name="operationResult" description="The Outcome of destroying the topic."/></results>
            </operation>
         </service>

Any changes to our managemnt API in future should mean just updating the config and adding ther correct mappings to the hornetq API.

Before ploughing headlong into this I would liker some feedback from people, probably Brian and the jopr guys.

[clebert.suconic]

that project on the AS6 is caleld hornetq-int. It's about hornetq only.

I was suggesting to have an abstraction layer, but it was getting ugly.. so I've decided to just write the integration needed for horentq. (Which will include a few destination deployers already specified by EJB3) and JOPR integration.

So, I think we should have hornetq somewhere on the package name.

[clebert.suconic]

09:21:05 AM) clebert: I was thinking
(09:21:05 AM) clebert: org.jboss.hornetq.integration
(09:21:05 AM) jbossfox: clebert, something like org.jboss.as.integration.hornetq
(09:21:14 AM) clebert: or that
(09:21:15 AM) clebert: yes
(09:21:26 AM) jbossfox: clebert, org.jboss.hornetq is *not* good
(09:21:33 AM) jbossfox: clebert, since that means it's part of hornetq
(09:21:42 AM) jbossfox: clebert, which it isn't
(09:21:46 AM) jbossfox: clebert, it's part of jboss as
(09:21:53 AM) clebert: jbossfox: lets use org.jboss.as.integration.hornetq
(09:22:01 AM) jbossfox: clebert, ok
(09:22:03 AM) clebert: AndyTaylor ^^
(09:22:33 AM) AndyTaylor: clebert: ok

[clebert.suconic]

An update on how things are going here:

I was struggling with understanding deployers and what's the point of having Meta-Data.. etc.. etc. (Besides, oh boy.. It's hard working on the AS Trunk. Super Heavy. I had to reset my linux box a few times due to some kernel error on forking new processes due to the IDE consuming a lot of resources. It seems I got around it now getting accostumed to what I can and can't do on the IDE... so I'm a bit faster now).

* I have created a XML parser on HornetQ. The HOrnetQ deployers are now using this parser instead of dealing with XML directly.

* I have created two deployers as required on the AS6 integration:

I - a Parser deployer that will take the XML Input and created a JMSConfiguration object. This object is exposed on the Deploying unit. (HornetQJMSParserDeployer)

II - A parser deployer that will take the JMSConfiguration object from the deployment unit (HornetQJMSRealDeployer) and will create a Deployment object (HornetQJMSDeployment).

Both deployers can't have any dependency on any HornetQ Server. as the deployers will scan places like /deploy before the HornetQ is started. The HornetQJMSDeployment is actually created through BeanMetaDataBuilder and the JMSServerManager is added through injection.

The cool thing on this, is that other deployers (TorqueBox, MDBDestinationsCreationg) will be able to do something like this:

deploymentUnit.add(JMSConfiguration.class, queuesConfig);

without the need of calling createQueue or deleteQueue manually. Everything will just be automatic on deployment and undeploy.

For being able to do that I also had to change the JMSConfiguration to allow it to take just names on the connector-configs, as it would require access to the Main Configuration (which will not happen before the parsing).

I'm now adding address-settings and security-settings to the deployers, but that should be quick now since I have a full understanding on how this works.

Thanks a lot to Brian who gave initial help on this, and a lot of thanks to Bob McWhirter who helped me put the deployers up and running.

[clebert.suconic]

There was a fake facade on JBoss Application server, that would take any MQ destination and it would deploy it as a JBoss Messaging destination that was written by Scott.

This way, if a user came with this following deployment descriptor:

  <mbean code="org.jboss.mq.server.jmx.Topic"
         name="jboss.mq.destination:service=Topic,name=securedTopic">
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
    <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
    <attribute name="SecurityConf">
      <security>
        <role name="publisher" read="true" write="true" create="false"/>
      </security>
    </attribute>
  </mbean>

it would be translated as a JBoss Messaging destination:

Which I'm not doing.

All the mq and jboss-messaging destinations will be gone on JBoss 6. (accordingly to what I am doing now)

All the destinations and deployment descriptors will have to be written accordingly to HornetQ and JBoss 6, since this is a major release.

[jason.greene]

All the mq and jboss-messaging destinations will be gone on JBoss 6. (accordingly to what I am doing now)

All the destinations and deployment descriptors will have to be written accordingly to HornetQ and JBoss 6, since this is a major release.

I am fine with this. AS6 is a good cycle to drop some of the legacy baggage. However, we just need to be able to backport this work for EAP 5.1, and EAP 5.1 has to maintain compatibility. Some kind of pluggable solution may allow you to have your cake and eat it too.

[brian.stansberry]

Three posts above, Clebert comments on having two deployers, one that parses into metadata and one that interacts with HQ to actually install the destination. If the legacy configs express all the info needed to produce HQ destinations, perhaps the EAP folks could add a POST_PARSE deployer that handles deployments w/ ServiceMetaData, checks if the ServiceMetaData specifies one of these legacy classes, uses the ServiceMetaData to create and attach to the DeploymentUnit the HQ metadata objects, and detaches the ServiceMetaData objects.  Then the 2nd HQ deployer would handle it the same as in the normal HQ deployment case.

(The ServiceMetaData comes from the regular PARSE stage deployer that parses -service.xml files.)

If the information in the legacy configs is incompatible with what HQ requires then I don't see how folks can expect to make an (optional) switch to HQ w/o changing their destination configuration.

[clebert.suconic]

Well.. If we need to support that on EAP, I guess it's better to just keep the fake destinations and delegate to a createQueue on HornetQ. The entire Hornetq-int project will then be merged into EAP 5.1.

I will print a big warning with a deprecated message when in use (log.warn)

[timfox]

I don't think we need to support that on EAP.

When we replace the default JMS provider in EAP, then there are no compatibility guarantees with the previous messaging system.

JBM and HQ are different systems, they're not compatible either on the wire, by config, or by features.

[clebert.suconic]

Thanks... +1

[jaikiran]

[e-mail] wrote:

Three posts above, Clebert comments on having two deployers, one that parses into metadata and one that interacts with HQ to actually install the destination. If the legacy configs express all the info needed to produce HQ destinations, perhaps the EAP folks could add a POST_PARSE deployer that handles deployments w/ ServiceMetaData, checks if the ServiceMetaData specifies one of these legacy classes, uses the ServiceMetaData to create and attach to the DeploymentUnit the HQ metadata objects, and detaches the ServiceMetaData objects.  Then the 2nd HQ deployer would handle it the same as in the normal HQ deployment case.

(The ServiceMetaData comes from the regular PARSE stage deployer that parses -service.xml files.)

From the AS (not EAP) point of view too, i think we should do something along those lines. Either that or if we are not going to allow those legacy JBoss Messaging configs, then i think we should have a documentation (in AS) which explains the steps required to migrate those configs from JBM to HornetQ.

[e-mail] wrote:

If the information in the legacy configs is incompatible with what HQ requires then I don't see how folks can expect to make an (optional) switch to HQ w/o changing their destination configuration.

Right. From a AS end user point of view, most of them would just want to be able to deploy their queues/topics without having to worry about JBM or HornetQ.

[clebert.suconic]

I foresee use cases where JBoss Messaging will be running along with HornetQ.

Say during a certain migration period the customer may have part of his applications running on HornetQ while other part on JBoss Messaging, until everything is converted.

So, I don't think we should provide any sort of facade on destinations as we may have the fake and the real code live at the same time.

[jaikiran]

[e-mail] wrote:

I foresee use cases where JBoss Messaging will be running along with HornetQ.

Say during a certain migration period the customer may have part of his applications running on HornetQ while other part on JBoss Messaging, until everything is converted.

I wasn't aware of this. My understanding about the switch to HornetQ in AS was that there will no longer be JBoss Messaging in AS - which means, users can no longer deploy their JBM artifacts (queue/topic configs) in AS.