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
