-
1. Re: Configuration changes
timfox Feb 1, 2010 12:15 PM (in response to clebert.suconic)I think that's fine, as long as it's done consistently across both core and JMS. -
2. Re: Configuration changes
clebert.suconic Feb 1, 2010 2:56 PM (in response to clebert.suconic)Few things I don't understand.
I - Why AddressSettings is not exposed on FileConfiguration / Configuration? That's also part of the main config?
II - From what I have seen on the AS6 integration, redploying a destinations file will make us to delete queues, and then add them back. Is that considered a problem? (if it is I don't know how we could do it otherwise)
Also, the deployers are currently using URL. That's fine for standalone but I don't have an URL while on the AS. so I may need to add a few methods.
-
3. Re: Configuration changes
timfox Feb 1, 2010 2:59 PM (in response to clebert.suconic)1. Regarding AddressSettings - this is a good point. I actually noticed this a few weeks ago but forgot to add a JIRA.
Also, currently there is no way to configure address settings, e.g. set an address page size using the management API - this is a big omission and needs to be fixed.
2. Redployment of destinations.
Undeploying a destination *does not* mean deleting it! We had this conversation before a few times if you remember.
-
4. Re: Configuration changes
ataylor Feb 1, 2010 3:04 PM (in response to timfox)you can add address settings like such
server.getAddressSettingsRepository().addMatch(address, addressSettings);
-
5. Re: Configuration changes
timfox Feb 1, 2010 3:05 PM (in response to ataylor)ataylor wrote:
you can add address settings like such
server.getAddressSettingsRepository().addMatch(address, addressSettings);
That's not available using the management api
-
6. Re: Configuration changes
clebert.suconic Feb 1, 2010 4:13 PM (in response to ataylor)you can add address settings like such
server.getAddressSettingsRepository().addMatch(address, addressSettings);
A lot of what's on the configuration is also exposed somewhere else. For instance it's possible to add acceptors directly on the HornetQ objects, and still you can add those on the Fileconfiguration.
My issue now is the deployment life cycle is controlled through MC Beans. I would need something on HornetQ to parse a XML file into a POJO, and have MC calling a method within HornetQ. TorqueBox will also need that kind of feature.
So, instead of having the deployers to take directly a XML, I would need them to take POJOs and the MC on the AS would be able to deal with them.
-
7. Re: Configuration changes
clebert.suconic Feb 1, 2010 5:41 PM (in response to clebert.suconic)More questions:
- Why did we make address-settings and security-settings part of hornetq's main configuration? for me it looks like it should be on a separate configuration.. like you can redeploy the queues settings but not the whole configuration.
- Also.. it's possible to define a hornetq-queues.xml with the entire main configuration on it. It seems it should be a separate schema.
- Can we also make the address and security settings as part of the JMS XSD? Right now it's not possible to define in a single file both security and queue settings.
-
8. Re: Configuration changes
clebert.suconic Feb 2, 2010 11:49 AM (in response to clebert.suconic)
Why these changes are necessary?The life cycle of deployements is controlled by the MicroContainer. On the application server every deployment descriptor is parsed as a simple POJO, and injection is used to invoke methods on the necessary beans.
When the deployment file is gone, the MC will invoke some method on the POJO (such as stop) and it can take proper actions from there.
Currently the deployment at HornetQ is done by just simple URLs, and it won't be possible to use the MC way of doing things.
It would be possible to hack around it by creating a deployer that would accept the HornetQ config files, but that would be "a hack", and AS developers are complaining about creating any deployers on that style.
Besides other projects (such as TorqueBox) currently need this kind of functionality, where the deployment metadata (the simple POJO for the parsed XML) is used.
Currently our POJOs mostly represent the XMLs (with the exception of address-settings and security-settings on the config). So, we would need to change to deployers to always parse the XML into configuration and then deploy the configuration POJOs instead of XML nodes.
-
9. Re: Configuration changes
ataylor Feb 2, 2010 12:00 PM (in response to clebert.suconic)Can you explain a bit more how the AS deployers work. It was my impression that they would pick up a config file, say hornet-queues.xml, and process each element. So from a HornetQ pov these deployers would be used instead of ours(or in conjunction with ours). -
10. Re: Configuration changes
clebert.suconic Feb 2, 2010 12:03 PM (in response to ataylor)was my impression that they would pick up a config file, say hornet-queues.xml, and process each element.
That's not how it's done. (maybe the AS guys will be able to provide more info here)
You parse the XML into a POJO, instatiate it on the MC, and let the Micro Container do the rest.
In fact, most of deployers are using JBossXB to do the parsing automagically. I'm already avoiding that step by using manual parsing, but I still need to parse the XML into a POJO.
-
11. Re: Configuration changes
ataylor Feb 2, 2010 12:08 PM (in response to clebert.suconic)can u give a simple example.
If 'we' parse the xml, i.e. we have written the deployer, dont we just pass this xml straight onto our deployers, changing them to accept xml instead of URL's
-
12. Re: Configuration changes
clebert.suconic Feb 2, 2010 12:15 PM (in response to ataylor)What the deployers on AS is supposed to do is:
JMSQueues config = whateverClass.parseTheDeploymentAsAPOJO(InputStream);
return config;The MicroContainer should take that object and inject it where is needed.
Bob McWhirter wrote a pseudo code of what we should be doing here:
-
13. Re: Configuration changes
clebert.suconic Feb 8, 2010 10:59 AM (in response to clebert.suconic)Is that ok if I at least add address-settings and security-settings to hornetq-jms.xml? (not just for the AS integration, I'm talking about standalone also)
-
14. Re: Configuration changes
timfox Feb 8, 2010 11:13 AM (in response to clebert.suconic)clebert.suconic@jboss.com wrote:
Is that ok if I at least add address-settings and security-settings to hornetq-jms.xml? (not just for the AS integration, I'm talking about standalone also)
I'm not sure that is a good idea.
AddressSettings and SecuritySettings deal with core addresses - not JMS queue/topic names so this would be confusing to the user, since they'd have to prefix everything with jms.queue and jms.topic etc