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 <[email protected]> > > 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 <[email protected]> > >> >> 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 <[email protected]> >>>> Date: 14 January 2009 7:18:59 PM >>>> To: [email protected] >>>> Subject: Re: Add tomcat-specific configuration >>>> Reply-To: [email protected] >>>> >>>> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>> >>>>> 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 <HOST> 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 <[email protected]> >>>>> >>>>> 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 > > > -- Ivan
