Re: Dual ActiveMQ configuration style [WAS: Add tomcat-specific configuration]
OK, I would like to do some investigation about it, maybe we could take use of JexlExpressionParser in geronimo-system modules. 2009/1/15 David Jencks > > On Jan 14, 2009, at 6:05 PM, Ivan wrote: > > One way may be write a new property holder bean to replace the default one > in the current activemq,xml file (I remember David has mentioned it in the > last related thread). > > > I think this is the best option. I think it will be useful for all the > spring based projects we integrate or want to integrate (such as apacheds, > jetspeed 2, roller, .) > > Another way I could see is that in the BrokerServiceGBean or > ConnectorGBean, before we start the broker service, we could add the portoff > to the port numbers (suppose we should get the portoffset from somewhere) > that the users input. However, we should have a way to let the user know > that the portoffset will be added to the port numbers they input, or I guess > it will make them feel confusion, for when they input the number, what they > expect is that a connector will listen on the port they input. > > > I don't like this way of proceeding. I think it forces a lot too much > configuration code into the components. > > By the way, currently in the ActiveMQ plugins do not have any > implementation codes about adding and removing connectors. > > > I could be very wrong but got the impression talking to Hiram some time ago > that changing connectors while the broker is running is not a good idea. > If I'm wrong we might want to wrap the connectors in gbeans... I don't know > how complicated their configuration is. > > thanks > david jencks > > > 2009/1/15 David Jencks > >> >> On Jan 14, 2009, at 3:10 AM, Gianny Damour wrote: >> >> Hi David, >>> >>> Your post is opportunistic for me to raise some concerns on dual >>> configuration style, one via GBean and another one via the native >>> configuration mechanism, which may cause trouble to users. >>> >>> No more than a couple of hours ago, I was trying to make sense of a port >>> conflict related to the ActiveMQ Broker trying to bind to the same port >>> whatever the value of PortOffSet. I figured out that I had to change the >>> port configuration in the activemq.xml configuration file of the instance I >>> was trying to start. The typical user expectation is that PortOffset should >>> be honored whatever the configuration style. >>> >>> I do not have a solution; though I wanted to report on this bad >>> experience. >>> >> >> You are not the first to run into this brick wall :-) >> >> I couldn't figure out any way to give spring a map or properties object to >> use in property substitution. All the solutions spring offers appear to >> read directly from files. Do you have any ideas on how to fix this? >> >> thanks >> david jencks >> >> >> >>> >>> Thanks, >>> Gianny >>> >>> Begin forwarded message: >>> >>> From: David Jencks Date: 14 January 2009 7:18:59 PM To: u...@geronimo.apache.org Subject: Re: Add tomcat-specific configuration Reply-To: u...@geronimo.apache.org On Jan 13, 2009, at 8:32 PM, Ivan wrote: I was always thinking that shall we have a better way to handle all the > available setting provided by the third-party modules? As we all know, > usually, all the GBeans only delegate those important and popular > settings, > it is impossible for us to allow all the configurations could be done via > GBean. Let us take Tomcat as an example, maybe we shall give an interface > to set those configurations that we do not provide now. > I think we could expose all the knobs on tomcat components in our gbeans but it might not be the most usable approach. Basically the problem is that we have two component containers -- tomcat and geronimo -- both of which insist on creating all the components themselves. While I tend to think that the main problem is that tomcat mixes the lifecycle and runtime code to intimately the only realistic way to get farther than we have now is to change geronimo so the components don't have to be created directly by the gbean infrastructure. david jencks > > 2009/1/14 Jack Cai > Thanks Ivan! I've examined the geronimo-tomcat-2.0.1.xsd and > geronimo-tomcat-config-1.0.xsd, and am pretty sure many configurations are > not available, like antiJARLocking, unloadDelay, etc. I understand that > many > of these settings might not work in Geronimo. Just try to see how we can > play with the context.xml etc., which might be some good tips for > migration > from Tomcat. > > -Jack > > 2009/1/14 Ivan > > Basically, Geronimo have created a GBean for each element in the > server.xml, which means we should configure those settings via GBeans in > the > config.xml. But so far, I am sure the existing GBeans have not covered all > the settings that to
Re: Dual ActiveMQ configuration style [WAS: Add tomcat-specific configuration]
On Jan 14, 2009, at 6:05 PM, Ivan wrote: One way may be write a new property holder bean to replace the default one in the current activemq,xml file (I remember David has mentioned it in the last related thread). I think this is the best option. I think it will be useful for all the spring based projects we integrate or want to integrate (such as apacheds, jetspeed 2, roller, .) Another way I could see is that in the BrokerServiceGBean or ConnectorGBean, before we start the broker service, we could add the portoff to the port numbers (suppose we should get the portoffset from somewhere) that the users input. However, we should have a way to let the user know that the portoffset will be added to the port numbers they input, or I guess it will make them feel confusion, for when they input the number, what they expect is that a connector will listen on the port they input. I don't like this way of proceeding. I think it forces a lot too much configuration code into the components. By the way, currently in the ActiveMQ plugins do not have any implementation codes about adding and removing connectors. I could be very wrong but got the impression talking to Hiram some time ago that changing connectors while the broker is running is not a good idea. If I'm wrong we might want to wrap the connectors in gbeans... I don't know how complicated their configuration is. thanks david jencks 2009/1/15 David Jencks On Jan 14, 2009, at 3:10 AM, Gianny Damour wrote: Hi David, Your post is opportunistic for me to raise some concerns on dual configuration style, one via GBean and another one via the native configuration mechanism, which may cause trouble to users. No more than a couple of hours ago, I was trying to make sense of a port conflict related to the ActiveMQ Broker trying to bind to the same port whatever the value of PortOffSet. I figured out that I had to change the port configuration in the activemq.xml configuration file of the instance I was trying to start. The typical user expectation is that PortOffset should be honored whatever the configuration style. I do not have a solution; though I wanted to report on this bad experience. You are not the first to run into this brick wall :-) I couldn't figure out any way to give spring a map or properties object to use in property substitution. All the solutions spring offers appear to read directly from files. Do you have any ideas on how to fix this? thanks david jencks Thanks, Gianny Begin forwarded message: From: David Jencks Date: 14 January 2009 7:18:59 PM To: u...@geronimo.apache.org Subject: Re: Add tomcat-specific configuration Reply-To: u...@geronimo.apache.org On Jan 13, 2009, at 8:32 PM, Ivan wrote: I was always thinking that shall we have a better way to handle all the available setting provided by the third-party modules? As we all know, usually, all the GBeans only delegate those important and popular settings, it is impossible for us to allow all the configurations could be done via GBean. Let us take Tomcat as an example, maybe we shall give an interface to set those configurations that we do not provide now. I think we could expose all the knobs on tomcat components in our gbeans but it might not be the most usable approach. Basically the problem is that we have two component containers -- tomcat and geronimo -- both of which insist on creating all the components themselves. While I tend to think that the main problem is that tomcat mixes the lifecycle and runtime code to intimately the only realistic way to get farther than we have now is to change geronimo so the components don't have to be created directly by the gbean infrastructure. david jencks 2009/1/14 Jack Cai Thanks Ivan! I've examined the geronimo-tomcat-2.0.1.xsd and geronimo-tomcat-config-1.0.xsd, and am pretty sure many configurations are not available, like antiJARLocking, unloadDelay, etc. I understand that many of these settings might not work in Geronimo. Just try to see how we can play with the context.xml etc., which might be some good tips for migration from Tomcat. -Jack 2009/1/14 Ivan Basically, Geronimo have created a GBean for each element in the server.xml, which means we should configure those settings via GBeans in the config.xml. But so far, I am sure the existing GBeans have not covered all the settings that tomcat provides. e.g. for server.xml, we have host gbean for the element, actually, you could check the current setting in the geronimo\plugins\tomcat \tomcat6\src\main\plan\plan.xml. For the context.xml, a TomcatWebAppContext GBean will be created while deploying the web applications, and most configurations could be set in the geronimo- web.xml file. Thanks for any comment, if any mistake is made, please point it out ! 2009/1/13 Jack Cai I just realize that I can put a context.xml in v
Re: Dual ActiveMQ configuration style [WAS: Add tomcat-specific configuration]
One way may be write a new property holder bean to replace the default one in the current activemq,xml file (I remember David has mentioned it in the last related thread). Another way I could see is that in the BrokerServiceGBean or ConnectorGBean, before we start the broker service, we could add the portoff to the port numbers (suppose we should get the portoffset from somewhere) that the users input. However, we should have a way to let the user know that the portoffset will be added to the port numbers they input, or I guess it will make them feel confusion, for when they input the number, what they expect is that a connector will listen on the port they input. By the way, currently in the ActiveMQ plugins do not have any implementation codes about adding and removing connectors. 2009/1/15 David Jencks > > On Jan 14, 2009, at 3:10 AM, Gianny Damour wrote: > > Hi David, >> >> Your post is opportunistic for me to raise some concerns on dual >> configuration style, one via GBean and another one via the native >> configuration mechanism, which may cause trouble to users. >> >> No more than a couple of hours ago, I was trying to make sense of a port >> conflict related to the ActiveMQ Broker trying to bind to the same port >> whatever the value of PortOffSet. I figured out that I had to change the >> port configuration in the activemq.xml configuration file of the instance I >> was trying to start. The typical user expectation is that PortOffset should >> be honored whatever the configuration style. >> >> I do not have a solution; though I wanted to report on this bad >> experience. >> > > You are not the first to run into this brick wall :-) > > I couldn't figure out any way to give spring a map or properties object to > use in property substitution. All the solutions spring offers appear to > read directly from files. Do you have any ideas on how to fix this? > > thanks > david jencks > > > >> >> Thanks, >> Gianny >> >> Begin forwarded message: >> >> From: David Jencks >>> Date: 14 January 2009 7:18:59 PM >>> To: u...@geronimo.apache.org >>> Subject: Re: Add tomcat-specific configuration >>> Reply-To: u...@geronimo.apache.org >>> >>> >>> On Jan 13, 2009, at 8:32 PM, Ivan wrote: >>> >>> I was always thinking that shall we have a better way to handle all the available setting provided by the third-party modules? As we all know, usually, all the GBeans only delegate those important and popular settings, it is impossible for us to allow all the configurations could be done via GBean. Let us take Tomcat as an example, maybe we shall give an interface to set those configurations that we do not provide now. >>> >>> I think we could expose all the knobs on tomcat components in our gbeans >>> but it might not be the most usable approach. Basically the problem is that >>> we have two component containers -- tomcat and geronimo -- both of which >>> insist on creating all the components themselves. While I tend to think >>> that the main problem is that tomcat mixes the lifecycle and runtime code to >>> intimately the only realistic way to get farther than we have now is to >>> change geronimo so the components don't have to be created directly by the >>> gbean infrastructure. >>> >>> david jencks >>> >>> 2009/1/14 Jack Cai Thanks Ivan! I've examined the geronimo-tomcat-2.0.1.xsd and geronimo-tomcat-config-1.0.xsd, and am pretty sure many configurations are not available, like antiJARLocking, unloadDelay, etc. I understand that many of these settings might not work in Geronimo. Just try to see how we can play with the context.xml etc., which might be some good tips for migration from Tomcat. -Jack 2009/1/14 Ivan Basically, Geronimo have created a GBean for each element in the server.xml, which means we should configure those settings via GBeans in the config.xml. But so far, I am sure the existing GBeans have not covered all the settings that tomcat provides. e.g. for server.xml, we have host gbean for the element, actually, you could check the current setting in the geronimo\plugins\tomcat\tomcat6\src\main\plan\plan.xml. For the context.xml, a TomcatWebAppContext GBean will be created while deploying the web applications, and most configurations could be set in the geronimo-web.xml file. Thanks for any comment, if any mistake is made, please point it out ! 2009/1/13 Jack Cai I just realize that I can put a context.xml in var/catalina/conf so that I can specify lots of Tomcat options there. I did a small experiment with the "workDir" param and it seems taking effect. Wondering whether this is supposed to work? Can I also put a server.xml there? Thanks! - Jack -- Ivan -- Ivan >>> >>> >> > -- Ivan
Re: Dual ActiveMQ configuration style [WAS: Add tomcat-specific configuration]
On Jan 14, 2009, at 3:10 AM, Gianny Damour wrote: Hi David, Your post is opportunistic for me to raise some concerns on dual configuration style, one via GBean and another one via the native configuration mechanism, which may cause trouble to users. No more than a couple of hours ago, I was trying to make sense of a port conflict related to the ActiveMQ Broker trying to bind to the same port whatever the value of PortOffSet. I figured out that I had to change the port configuration in the activemq.xml configuration file of the instance I was trying to start. The typical user expectation is that PortOffset should be honored whatever the configuration style. I do not have a solution; though I wanted to report on this bad experience. You are not the first to run into this brick wall :-) I couldn't figure out any way to give spring a map or properties object to use in property substitution. All the solutions spring offers appear to read directly from files. Do you have any ideas on how to fix this? thanks david jencks Thanks, Gianny Begin forwarded message: From: David Jencks Date: 14 January 2009 7:18:59 PM To: u...@geronimo.apache.org Subject: Re: Add tomcat-specific configuration Reply-To: u...@geronimo.apache.org On Jan 13, 2009, at 8:32 PM, Ivan wrote: I was always thinking that shall we have a better way to handle all the available setting provided by the third-party modules? As we all know, usually, all the GBeans only delegate those important and popular settings, it is impossible for us to allow all the configurations could be done via GBean. Let us take Tomcat as an example, maybe we shall give an interface to set those configurations that we do not provide now. I think we could expose all the knobs on tomcat components in our gbeans but it might not be the most usable approach. Basically the problem is that we have two component containers -- tomcat and geronimo -- both of which insist on creating all the components themselves. While I tend to think that the main problem is that tomcat mixes the lifecycle and runtime code to intimately the only realistic way to get farther than we have now is to change geronimo so the components don't have to be created directly by the gbean infrastructure. david jencks 2009/1/14 Jack Cai Thanks Ivan! I've examined the geronimo-tomcat-2.0.1.xsd and geronimo-tomcat-config-1.0.xsd, and am pretty sure many configurations are not available, like antiJARLocking, unloadDelay, etc. I understand that many of these settings might not work in Geronimo. Just try to see how we can play with the context.xml etc., which might be some good tips for migration from Tomcat. -Jack 2009/1/14 Ivan Basically, Geronimo have created a GBean for each element in the server.xml, which means we should configure those settings via GBeans in the config.xml. But so far, I am sure the existing GBeans have not covered all the settings that tomcat provides. e.g. for server.xml, we have host gbean for the element, actually, you could check the current setting in the geronimo \plugins\tomcat\tomcat6\src\main\plan\plan.xml. For the context.xml, a TomcatWebAppContext GBean will be created while deploying the web applications, and most configurations could be set in the geronimo-web.xml file. Thanks for any comment, if any mistake is made, please point it out ! 2009/1/13 Jack Cai I just realize that I can put a context.xml in var/catalina/conf so that I can specify lots of Tomcat options there. I did a small experiment with the "workDir" param and it seems taking effect. Wondering whether this is supposed to work? Can I also put a server.xml there? Thanks! - Jack -- Ivan -- Ivan
Dual ActiveMQ configuration style [WAS: Add tomcat-specific configuration]
Hi David, Your post is opportunistic for me to raise some concerns on dual configuration style, one via GBean and another one via the native configuration mechanism, which may cause trouble to users. No more than a couple of hours ago, I was trying to make sense of a port conflict related to the ActiveMQ Broker trying to bind to the same port whatever the value of PortOffSet. I figured out that I had to change the port configuration in the activemq.xml configuration file of the instance I was trying to start. The typical user expectation is that PortOffset should be honored whatever the configuration style. I do not have a solution; though I wanted to report on this bad experience. Thanks, Gianny Begin forwarded message: From: David Jencks Date: 14 January 2009 7:18:59 PM To: u...@geronimo.apache.org Subject: Re: Add tomcat-specific configuration Reply-To: u...@geronimo.apache.org On Jan 13, 2009, at 8:32 PM, Ivan wrote: I was always thinking that shall we have a better way to handle all the available setting provided by the third-party modules? As we all know, usually, all the GBeans only delegate those important and popular settings, it is impossible for us to allow all the configurations could be done via GBean. Let us take Tomcat as an example, maybe we shall give an interface to set those configurations that we do not provide now. I think we could expose all the knobs on tomcat components in our gbeans but it might not be the most usable approach. Basically the problem is that we have two component containers -- tomcat and geronimo -- both of which insist on creating all the components themselves. While I tend to think that the main problem is that tomcat mixes the lifecycle and runtime code to intimately the only realistic way to get farther than we have now is to change geronimo so the components don't have to be created directly by the gbean infrastructure. david jencks 2009/1/14 Jack Cai Thanks Ivan! I've examined the geronimo-tomcat-2.0.1.xsd and geronimo-tomcat-config-1.0.xsd, and am pretty sure many configurations are not available, like antiJARLocking, unloadDelay, etc. I understand that many of these settings might not work in Geronimo. Just try to see how we can play with the context.xml etc., which might be some good tips for migration from Tomcat. -Jack 2009/1/14 Ivan Basically, Geronimo have created a GBean for each element in the server.xml, which means we should configure those settings via GBeans in the config.xml. But so far, I am sure the existing GBeans have not covered all the settings that tomcat provides. e.g. for server.xml, we have host gbean for the element, actually, you could check the current setting in the geronimo \plugins\tomcat\tomcat6\src\main\plan\plan.xml. For the context.xml, a TomcatWebAppContext GBean will be created while deploying the web applications, and most configurations could be set in the geronimo-web.xml file. Thanks for any comment, if any mistake is made, please point it out ! 2009/1/13 Jack Cai I just realize that I can put a context.xml in var/catalina/conf so that I can specify lots of Tomcat options there. I did a small experiment with the "workDir" param and it seems taking effect. Wondering whether this is supposed to work? Can I also put a server.xml there? Thanks! - Jack -- Ivan -- Ivan
