JBossDeveloper

Summary of Friday's meeting      

Clebert and Emanuel to liaise to complete the deployers and the Management Objects for all management objects, any queues created dynamically via the HornetQ API's will bypass the deployers tho, for performance reasons. Clebert, if you could come up with a timeframe for completing this part.

Once MO's are done i will update the AS 5 jopr plugin to use the HQ Managament View but will make the plugin adaptable so it will also work with standalone instances of HornetQ. I will liaise with Charles on where to do this. The plugin will work with both JBM and HQ so it will work once it is integrated with eap. Did we say we would create an AS 6 plugin branch?

Anything ive missed?

.

Alexey is working on the ProfileService tests, to map them to the new MOs - also implementing some missing functionality.

One thing i'm not sure is what we do about the other properties which used to be on the queue configuration itself. Like security and other settings. I know that they moved to the main hornetQ-config, so i'm wondering if we should be looking into creation some management objects for this as well?

We discussed the admin console plugin at the face to face and the following issues cam out of this.

We have decided that it should be possible for all queues to be accessable via the admin console. The problem is that since in HornetQ a queue can represent a subscription creating a Managed Object for each queue would be a huge performance hit. So the following was suggested: instead of having a managed object for a queue we have a single managed object for all the queues, say a queue manager mo. this would allow users to view all queues created. from a console point of view this means the user would see a list of queues with a set of actions available against each queue. users could either list just jms queues or all queues depending if they were viewing via jms or core. This queue manager mo would also allow the creation of queues and setting the attributes on a queue in a single action rather than having to move all over console. A similar thing would be added for topics altho would only show in the jms tree.

Obviously this is different to what we discussed in the meeting but we feel that this is the only approach we can take. thoughts everyone?

I am prototyping this new approach and will try and have some screen shots and something checked into the branch by tomorrow.

Also, i will need to start developing this on the jopr branch, Charles, is there any update on this?

Guys - can we have an update of where we are with this task, and how long for completion.

That includes the *whole* task:

Console

Test suite

TCK

ataylor wrote:

 

We discussed the admin console plugin at the face to face and the following issues cam out of this.

 

We have decided that it should be possible for all queues to be accessable via the admin console. The problem is that since in HornetQ a queue can represent a subscription creating a Managed Object for each queue would be a huge performance hit. So the following was suggested: instead of having a managed object for a queue we have a single managed object for all the queues, say a queue manager mo. this would allow users to view all queues created. from a console point of view this means the user would see a list of queues with a set of actions available against each queue. users could either list just jms queues or all queues depending if they were viewing via jms or core. This queue manager mo would also allow the creation of queues and setting the attributes on a queue in a single action rather than having to move all over console. A similar thing would be added for topics altho would only show in the jms tree.

 

Obviously this is different to what we discussed in the meeting but we feel that this is the only approach we can take. thoughts everyone?

 

I am prototyping this new approach and will try and have some screen shots and something checked into the branch by tomorrow.

I think this is fine provided that any queues/topics that are created will survive restart. Is that the case today with existing hornetq infrastructure?

jason.greene@jboss.com wrote:

 

ataylor wrote:

 

We discussed the admin console plugin at the face to face and the following issues cam out of this.

 

We have decided that it should be possible for all queues to be accessable via the admin console. The problem is that since in HornetQ a queue can represent a subscription creating a Managed Object for each queue would be a huge performance hit. So the following was suggested: instead of having a managed object for a queue we have a single managed object for all the queues, say a queue manager mo. this would allow users to view all queues created. from a console point of view this means the user would see a list of queues with a set of actions available against each queue. users could either list just jms queues or all queues depending if they were viewing via jms or core. This queue manager mo would also allow the creation of queues and setting the attributes on a queue in a single action rather than having to move all over console. A similar thing would be added for topics altho would only show in the jms tree.

 

Obviously this is different to what we discussed in the meeting but we feel that this is the only approach we can take. thoughts everyone?

 

I am prototyping this new approach and will try and have some screen shots and something checked into the branch by tomorrow.

I think this is fine provided that any queues/topics that are created will survive restart. Is that the case today with existing hornetq infrastructure?

ataylor wrote:

 

jason.greene@jboss.com wrote:

 

ataylor wrote:

 

We discussed the admin console plugin at the face to face and the following issues cam out of this.

 

We have decided that it should be possible for all queues to be accessable via the admin console. The problem is that since in HornetQ a queue can represent a subscription creating a Managed Object for each queue would be a huge performance hit. So the following was suggested: instead of having a managed object for a queue we have a single managed object for all the queues, say a queue manager mo. this would allow users to view all queues created. from a console point of view this means the user would see a list of queues with a set of actions available against each queue. users could either list just jms queues or all queues depending if they were viewing via jms or core. This queue manager mo would also allow the creation of queues and setting the attributes on a queue in a single action rather than having to move all over console. A similar thing would be added for topics altho would only show in the jms tree.

 

Obviously this is different to what we discussed in the meeting but we feel that this is the only approach we can take. thoughts everyone?

 

I am prototyping this new approach and will try and have some screen shots and something checked into the branch by tomorrow.

I think this is fine provided that any queues/topics that are created will survive restart. Is that the case today with existing hornetq infrastructure?

 

With queues yes but there is no such thing as topics in HornetQ internally.

OK so this is a major problem, and was essentially one of the reasons why we were using deployments to drive the creation of JMS resources. In the long term AS7/Andiamo will require a unified centralized configuration file (domain model) that will specify everything a user can configure. Persistence will be provided for this model by AS. So in the short term we need to find a way to support this, at least by 6 GA.  We can either delegate it to AS like in the past, or add the capability to hornetq's persistence mechanism.

jason.greene@jboss.com wrote:

 

ataylor wrote:

 

jason.greene@jboss.com wrote:

 

ataylor wrote:

 

We discussed the admin console plugin at the face to face and the following issues cam out of this.

 

We have decided that it should be possible for all queues to be accessable via the admin console. The problem is that since in HornetQ a queue can represent a subscription creating a Managed Object for each queue would be a huge performance hit. So the following was suggested: instead of having a managed object for a queue we have a single managed object for all the queues, say a queue manager mo. this would allow users to view all queues created. from a console point of view this means the user would see a list of queues with a set of actions available against each queue. users could either list just jms queues or all queues depending if they were viewing via jms or core. This queue manager mo would also allow the creation of queues and setting the attributes on a queue in a single action rather than having to move all over console. A similar thing would be added for topics altho would only show in the jms tree.

 

Obviously this is different to what we discussed in the meeting but we feel that this is the only approach we can take. thoughts everyone?

 

I am prototyping this new approach and will try and have some screen shots and something checked into the branch by tomorrow.

I think this is fine provided that any queues/topics that are created will survive restart. Is that the case today with existing hornetq infrastructure?

 

With queues yes but there is no such thing as topics in HornetQ internally.

 

OK so this is a major problem, and was essentially one of the reasons why we were using deployments to drive the creation of JMS resources. In the long term AS7/Andiamo will require a unified centralized configuration file (domain model) that will specify everything a user can configure. Persistence will be provided for this model by AS. So in the short term we need to find a way to support this, at least by 6 GA.  We can either delegate it to AS like in the past, or add the capability to hornetq's persistence mechanism.

We have an outstanding JIRA to add extra persistence, https://jira.jboss.org/jira/browse/HORNETQ-45 , we will make sure this is completed for AS6.

Can we have a status update with where you all are with this before the end of the day?

thx