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 <david_jencks@yahoo.com>
>
> 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 <david_jencks@yahoo.com>
> Date: 14 January 2009 7:18:59 PM
> To: user@geronimo.apache.org
> Subject: Re: Add tomcat-specific configuration
> Reply-To: user@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 <greensight@gmail.com>
> 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 <xhhsld@gmail.com>
>
> 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 <greensight@gmail.com>
>
> 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
|