You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@apache.org> on 2006/02/24 09:51:39 UTC
Removing attributes and refs from the config.xml
The config.xml allows us to declare new GBeans and override references
and attributes of already existing Gbeans. But there is a missing
configuration item here, which is the ability to *remove* a reference or
attribute value from the configuration. Currently there is no way to do
this.
Matt Hogstrom and I ran into this when trying to remove a logging
reference in one of the GBeans.
An example of this is the TomcatValveChain on the TomcatEngine. As it
stands, our default implementation installs an AccessLogValve into the
TomcatValveChain reference. We wanted to shut off logging to test
different performance numbers and found that there was no way to "clear"
or remove a reference that was set in the car plan via the config.xml,
without rebuilding the car from the source.
On further discussion with David J and Dain, we came up with a new xml
attribute to place on refs and attribute tags. You would use:
empty="true"
Example: You want to remove the access logger to improve web container
performance, you would declare the following in the config.xml, which
would remove the TomcatValveChain from the TomcatEngine:
...
<configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
...
<gbean name="FirstValve" load="false"/>
<gbean name="TomcatEngine">
<reference name="TomcatValveChain" empty="true"/>
</gbean>
...
</configuration>
...
You would do the same for attributes that needed to be removed.
I have this all coded up and ready to check in, but wanted to get any
feedback or issues before I went ahead and did it.
Comments?
Jeff
Re: Removing attributes and refs from the config.xml
Posted by Dain Sundstrom <da...@iq80.com>.
I like the form Aaron suggested better.
<gbean name="TomcatEngine">
<reference name="TomcatValveChain" />
<attribute name="someAttribute" />
</gbean>
Both the attribute and value would be reset. The only drawback is
that there would be no way to create an empty string, but I don't
think that is possible today anyway. Also, I don't think there is
anything that needs it.
-dain
On Feb 24, 2006, at 2:56 PM, Aaron Mulder wrote:
> What's wrong with just listing the attribute or reference with no
> content but without the new "empty=true"? As in:
>
> <gbean name="TomcatEngine">
> <reference name="TomcatValveChain" />
> </gbean>
>
> Thanks,
> Aaron
>
> On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
>> The config.xml allows us to declare new GBeans and override
>> references
>> and attributes of already existing Gbeans. But there is a missing
>> configuration item here, which is the ability to *remove* a
>> reference or
>> attribute value from the configuration. Currently there is no way
>> to do
>> this.
>>
>> Matt Hogstrom and I ran into this when trying to remove a logging
>> reference in one of the GBeans.
>>
>> An example of this is the TomcatValveChain on the TomcatEngine.
>> As it
>> stands, our default implementation installs an AccessLogValve into
>> the
>> TomcatValveChain reference. We wanted to shut off logging to test
>> different performance numbers and found that there was no way to
>> "clear"
>> or remove a reference that was set in the car plan via the
>> config.xml,
>> without rebuilding the car from the source.
>>
>> On further discussion with David J and Dain, we came up with a new
>> xml
>> attribute to place on refs and attribute tags. You would use:
>>
>> empty="true"
>>
>> Example: You want to remove the access logger to improve web
>> container
>> performance, you would declare the following in the config.xml, which
>> would remove the TomcatValveChain from the TomcatEngine:
>>
>> ...
>> <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
>> ...
>> <gbean name="FirstValve" load="false"/>
>>
>> <gbean name="TomcatEngine">
>> <reference name="TomcatValveChain" empty="true"/>
>> </gbean>
>> ...
>> </configuration>
>> ...
>>
>> You would do the same for attributes that needed to be removed.
>>
>> I have this all coded up and ready to check in, but wanted to get any
>> feedback or issues before I went ahead and did it.
>>
>> Comments?
>>
>> Jeff
>>
Re: Removing attributes and refs from the config.xml
Posted by Dain Sundstrom <da...@iq80.com>.
I completely agree with the assessment of the problem, but I don't
think we have a good solution yet. Regardless of using the existing
GBean code, Spring or xbean-reflect to wire services together, the
user must have a fairly deep understanding of the code.
Lets look into the future. Say that configurations use xml instead
of object serialization for the persistence format. Say we even have
a plugin based server where users can download, install, use and
unload extensions to the server. In this case we could let users
hack the raw xml files in the unpacked cars, but every time they
upgrade their server, or a single plugin, they loose all
configuration changes to the server or plugin.
Where does that leave us. I think we need to have a two level
configuration system, like most user land software and a lot of
system software has. In this design, you have the default
configuration that ships with an install or plugin and user
preferences which override that configuration. This is what we
currently have, but I don't think we have a very elegant solution.
I have a few ideas for this area, but we are at least a few months
from having xml based and downloadable plugins.
-dain
On Feb 25, 2006, at 6:11 PM, Bruce Snyder wrote:
> I'm gonna go out on a limb here and ask why we're trying to make all
> of this more difficult for users instead of easier? Requiring a user
> to: 1) gain knowledge of the plans used to create the CARs, and 2) to
> create a brand new XML file (config.xml) to define new functionality
> or override existing functionality seems ridiculous. The proposed
> solution seems to be treating the symptoms rather than the real
> disease.
>
> IMHO, CARs need to either be made more dynamic or need to be replaced
> with something more dynamic. The trouble I have with CARs is that
> changing them requires them to be fully rebuilt which requires the
> Geronimo source. Average users don't have the knowledge or time to
> deal with this so we offered the config.xml which we're finding
> doesn't really solve the whole problem either. If I had my druthers,
> I'd leave CARs the way they are and work to offer something more
> dynamic as a long-term solution.
>
> The idea I have is to use a standard XML dialect for configuration
> files - like XBean which currently requires Spring. I'm sure that this
> idea won't have many fans, but it's an easy way to reuse an existing
> solution to deliver an easier experience for Geronimo users which,
> IMO, should be our ultimate goal.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 26, 2006, at 10:46 AM, Jason Dillon wrote:
> Commit it and let the community implement the rest... seems to have
> worked for at least one project I know of... sorta... kinda... um,
> well nevermind.
I'd rather not. It would break the build and I need to finish the
configid changes.
-dain
On Feb 26, 2006, at 11:09 AM, Jeff Genender wrote:
> So I think we have 2 issues here...
>
> 1) What we want in the future?
>
> So the future holds XBean. This is great.
>
> 2) What to do now?
>
> For now, I put in the empty="true" (yes *that* was Dain's idea :D -
> sorry Dain, gotta throw you back under the bus - hehehe - j/k). I
> probably would rather have a value="empty" and a value="remove" and a
> value="null" attribute, or something along those lines...similar to
> Spring. I just think we need an interim solution relatively quick,
> and
> this was the best I could come up with. Minimally we need the ability
> to "unset" an attribute all together...thats where the empty="true"
> thing came in. But this brought up the ability to force a null and
> empty String to attributes and references. I think using this
> optional
> attribute keeps things the same as they are today, but offers the
> flexibility to pass what we need to, including removing the value all
> together.
>
> If there is a better idea, then please bring it up...I am open to
> anything.
>
> Jeff
>
>
> Dain Sundstrom wrote:
>> I think we are all past the old concerns. The problem now is how
>> do we
>> switch, which is not an easy problem. On my laptop I have about
>> half of
>> the server switched to use xbean-reflect, which is xml friendly,
>> but I
>> got sucked into the configId problem.
>>
>> -dain
>>
>> On Feb 25, 2006, at 11:17 PM, Bruce Snyder wrote:
>>
>>> On 2/26/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> Why would anyone object to using XBean+Spring?
>>>>
>>>> I think that sounds like a good idea.
>>>
>>> Well the objection wasn't to XBean and Spring per se - they weren't
>>> even in the picture back then. The objection was to using XML as the
>>> configuraiton mechanism instead of CAR files. Way back when CARs
>>> were
>>> being suggested as the configuration mechanism, I entered the debate
>>> with the rationale that we should use XML instead because it's is
>>> easy
>>> to change, it's easy to understand, etc. At that time, there were
>>> objections to this line of reasoning because of the overhead of
>>> parsing the XML on every startup. The argument was made that CAR
>>> files
>>> would start up much faster. I have no idea if this is true or not
>>> but
>>> IMO the advantages of using XML (and a well known XML dialect like
>>> Spring) far outweigh the disadvantages, especially when it comes to
>>> offering users a simple but very powerful experience.
>>>
>>> Bruce
>>> --
>>> perl -e 'print
>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>> );'
>>>
>>> Apache Geronimo (http://geronimo.apache.org/)
>>>
>>> Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Jeff Genender <jg...@apache.org>.
Dain,
This looks good to me.
Others - Any objections to this proposal? If not, I am happy to
implement it.
Jeff
Dain Sundstrom wrote:
> On Feb 26, 2006, at 11:09 AM, Jeff Genender wrote:
>
>> 2) What to do now?
>>
>> For now, I put in the empty="true" (yes *that* was Dain's idea :D -
>> sorry Dain, gotta throw you back under the bus - hehehe - j/k). I
>> probably would rather have a value="empty" and a value="remove" and a
>> value="null" attribute, or something along those lines...similar to
>> Spring. I just think we need an interim solution relatively quick, and
>> this was the best I could come up with. Minimally we need the ability
>> to "unset" an attribute all together...thats where the empty="true"
>> thing came in. But this brought up the ability to force a null and
>> empty String to attributes and references. I think using this optional
>> attribute keeps things the same as they are today, but offers the
>> flexibility to pass what we need to, including removing the value all
>> together.
>>
>> If there is a better idea, then please bring it up...I am open to
>> anything.
>
> I think using the an attribute name "value" will be confusing for spring
> users, but it does bring up a better idea...
>
> 1) Normal value
> <attribute name="someAttribute" value="42"/>
> <attribute name="someAttribute">42</attribute>
>
> 2) Don't set... constructor args will be injected with java default values
> <reference name="TomcatValveChain"/>
> <attribute name="someAttribute"/>
> <attribute name="someAttribute"></attribute>
>
> 3) Inject empty string or pass empty string to property editor and inject
> <attribute name="someAttribute" value=""/>
>
> 4) Inject null
> <attribute name="someAttribute" null="true"/>
>
> -dain
Re: Removing attributes and refs from the config.xml
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 26, 2006, at 11:09 AM, Jeff Genender wrote:
> 2) What to do now?
>
> For now, I put in the empty="true" (yes *that* was Dain's idea :D -
> sorry Dain, gotta throw you back under the bus - hehehe - j/k). I
> probably would rather have a value="empty" and a value="remove" and a
> value="null" attribute, or something along those lines...similar to
> Spring. I just think we need an interim solution relatively quick,
> and
> this was the best I could come up with. Minimally we need the ability
> to "unset" an attribute all together...thats where the empty="true"
> thing came in. But this brought up the ability to force a null and
> empty String to attributes and references. I think using this
> optional
> attribute keeps things the same as they are today, but offers the
> flexibility to pass what we need to, including removing the value all
> together.
>
> If there is a better idea, then please bring it up...I am open to
> anything.
I think using the an attribute name "value" will be confusing for
spring users, but it does bring up a better idea...
1) Normal value
<attribute name="someAttribute" value="42"/>
<attribute name="someAttribute">42</attribute>
2) Don't set... constructor args will be injected with java default
values
<reference name="TomcatValveChain"/>
<attribute name="someAttribute"/>
<attribute name="someAttribute"></attribute>
3) Inject empty string or pass empty string to property editor and
inject
<attribute name="someAttribute" value=""/>
4) Inject null
<attribute name="someAttribute" null="true"/>
-dain
Re: Removing attributes and refs from the config.xml
Posted by Jeff Genender <jg...@apache.org>.
So I think we have 2 issues here...
1) What we want in the future?
So the future holds XBean. This is great.
2) What to do now?
For now, I put in the empty="true" (yes *that* was Dain's idea :D -
sorry Dain, gotta throw you back under the bus - hehehe - j/k). I
probably would rather have a value="empty" and a value="remove" and a
value="null" attribute, or something along those lines...similar to
Spring. I just think we need an interim solution relatively quick, and
this was the best I could come up with. Minimally we need the ability
to "unset" an attribute all together...thats where the empty="true"
thing came in. But this brought up the ability to force a null and
empty String to attributes and references. I think using this optional
attribute keeps things the same as they are today, but offers the
flexibility to pass what we need to, including removing the value all
together.
If there is a better idea, then please bring it up...I am open to anything.
Jeff
Dain Sundstrom wrote:
> I think we are all past the old concerns. The problem now is how do we
> switch, which is not an easy problem. On my laptop I have about half of
> the server switched to use xbean-reflect, which is xml friendly, but I
> got sucked into the configId problem.
>
> -dain
>
> On Feb 25, 2006, at 11:17 PM, Bruce Snyder wrote:
>
>> On 2/26/06, Jason Dillon <ja...@planet57.com> wrote:
>>> Why would anyone object to using XBean+Spring?
>>>
>>> I think that sounds like a good idea.
>>
>> Well the objection wasn't to XBean and Spring per se - they weren't
>> even in the picture back then. The objection was to using XML as the
>> configuraiton mechanism instead of CAR files. Way back when CARs were
>> being suggested as the configuration mechanism, I entered the debate
>> with the rationale that we should use XML instead because it's is easy
>> to change, it's easy to understand, etc. At that time, there were
>> objections to this line of reasoning because of the overhead of
>> parsing the XML on every startup. The argument was made that CAR files
>> would start up much faster. I have no idea if this is true or not but
>> IMO the advantages of using XML (and a well known XML dialect like
>> Spring) far outweigh the disadvantages, especially when it comes to
>> offering users a simple but very powerful experience.
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> Apache Geronimo (http://geronimo.apache.org/)
>>
>> Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Jason Dillon <ja...@planet57.com>.
Commit it and let the community implement the rest... seems to have
worked for at least one project I know of... sorta... kinda... um,
well nevermind.
--jason
On Feb 26, 2006, at 9:29 AM, Dain Sundstrom wrote:
> I think we are all past the old concerns. The problem now is how
> do we switch, which is not an easy problem. On my laptop I have
> about half of the server switched to use xbean-reflect, which is
> xml friendly, but I got sucked into the configId problem.
>
> -dain
>
> On Feb 25, 2006, at 11:17 PM, Bruce Snyder wrote:
>
>> On 2/26/06, Jason Dillon <ja...@planet57.com> wrote:
>>> Why would anyone object to using XBean+Spring?
>>>
>>> I think that sounds like a good idea.
>>
>> Well the objection wasn't to XBean and Spring per se - they weren't
>> even in the picture back then. The objection was to using XML as the
>> configuraiton mechanism instead of CAR files. Way back when CARs were
>> being suggested as the configuration mechanism, I entered the debate
>> with the rationale that we should use XML instead because it's is
>> easy
>> to change, it's easy to understand, etc. At that time, there were
>> objections to this line of reasoning because of the overhead of
>> parsing the XML on every startup. The argument was made that CAR
>> files
>> would start up much faster. I have no idea if this is true or not but
>> IMO the advantages of using XML (and a well known XML dialect like
>> Spring) far outweigh the disadvantages, especially when it comes to
>> offering users a simple but very powerful experience.
>>
>> Bruce
>> --
>> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D
>> \!G;6%I;\"YC;VT*"
>> );'
>>
>> Apache Geronimo (http://geronimo.apache.org/)
>>
>> Castor (http://castor.org/)
>
Re: Removing attributes and refs from the config.xml
Posted by Dain Sundstrom <da...@iq80.com>.
I think we are all past the old concerns. The problem now is how do
we switch, which is not an easy problem. On my laptop I have about
half of the server switched to use xbean-reflect, which is xml
friendly, but I got sucked into the configId problem.
-dain
On Feb 25, 2006, at 11:17 PM, Bruce Snyder wrote:
> On 2/26/06, Jason Dillon <ja...@planet57.com> wrote:
>> Why would anyone object to using XBean+Spring?
>>
>> I think that sounds like a good idea.
>
> Well the objection wasn't to XBean and Spring per se - they weren't
> even in the picture back then. The objection was to using XML as the
> configuraiton mechanism instead of CAR files. Way back when CARs were
> being suggested as the configuration mechanism, I entered the debate
> with the rationale that we should use XML instead because it's is easy
> to change, it's easy to understand, etc. At that time, there were
> objections to this line of reasoning because of the overhead of
> parsing the XML on every startup. The argument was made that CAR files
> would start up much faster. I have no idea if this is true or not but
> IMO the advantages of using XML (and a well known XML dialect like
> Spring) far outweigh the disadvantages, especially when it comes to
> offering users a simple but very powerful experience.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Bruce Snyder <br...@gmail.com>.
On 2/26/06, Jason Dillon <ja...@planet57.com> wrote:
> Why would anyone object to using XBean+Spring?
>
> I think that sounds like a good idea.
Well the objection wasn't to XBean and Spring per se - they weren't
even in the picture back then. The objection was to using XML as the
configuraiton mechanism instead of CAR files. Way back when CARs were
being suggested as the configuration mechanism, I entered the debate
with the rationale that we should use XML instead because it's is easy
to change, it's easy to understand, etc. At that time, there were
objections to this line of reasoning because of the overhead of
parsing the XML on every startup. The argument was made that CAR files
would start up much faster. I have no idea if this is true or not but
IMO the advantages of using XML (and a well known XML dialect like
Spring) far outweigh the disadvantages, especially when it comes to
offering users a simple but very powerful experience.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Jason Dillon <ja...@planet57.com>.
Why would anyone object to using XBean+Spring?
I think that sounds like a good idea.
--jason
On Feb 25, 2006, at 6:11 PM, Bruce Snyder wrote:
> I'm gonna go out on a limb here and ask why we're trying to make all
> of this more difficult for users instead of easier? Requiring a user
> to: 1) gain knowledge of the plans used to create the CARs, and 2) to
> create a brand new XML file (config.xml) to define new functionality
> or override existing functionality seems ridiculous. The proposed
> solution seems to be treating the symptoms rather than the real
> disease.
>
> IMHO, CARs need to either be made more dynamic or need to be replaced
> with something more dynamic. The trouble I have with CARs is that
> changing them requires them to be fully rebuilt which requires the
> Geronimo source. Average users don't have the knowledge or time to
> deal with this so we offered the config.xml which we're finding
> doesn't really solve the whole problem either. If I had my druthers,
> I'd leave CARs the way they are and work to offer something more
> dynamic as a long-term solution.
>
> The idea I have is to use a standard XML dialect for configuration
> files - like XBean which currently requires Spring. I'm sure that this
> idea won't have many fans, but it's an easy way to reuse an existing
> solution to deliver an easier experience for Geronimo users which,
> IMO, should be our ultimate goal.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I agree that the end goal here is the user experience. When I was working with
Jeff the other night the way to fix the logging problem at that point was to
rebuild the server. IMHO a user would at most be required to edit the
config.xml and at least be able to click a radio button for a binary operation
like enable/disable logging. Anything beyond that and we will limit our user
base as the server will be too expensive to work with.
The other thinkg to avoid is multiple configuration files. As a user I want to
find all config files in a single directory if possible (reduces my knowledge
required to use the server) and then to have as few files as possible. Again,
this all front-ended with a console that can manipulate all (or at least as many
options as possible).
I may not have captured this thought in my first post so apologies for repeating
myself.
Matt.
Bruce Snyder wrote:
> I'm gonna go out on a limb here and ask why we're trying to make all
> of this more difficult for users instead of easier? Requiring a user
> to: 1) gain knowledge of the plans used to create the CARs, and 2) to
> create a brand new XML file (config.xml) to define new functionality
> or override existing functionality seems ridiculous. The proposed
> solution seems to be treating the symptoms rather than the real
> disease.
>
> IMHO, CARs need to either be made more dynamic or need to be replaced
> with something more dynamic. The trouble I have with CARs is that
> changing them requires them to be fully rebuilt which requires the
> Geronimo source. Average users don't have the knowledge or time to
> deal with this so we offered the config.xml which we're finding
> doesn't really solve the whole problem either. If I had my druthers,
> I'd leave CARs the way they are and work to offer something more
> dynamic as a long-term solution.
>
> The idea I have is to use a standard XML dialect for configuration
> files - like XBean which currently requires Spring. I'm sure that this
> idea won't have many fans, but it's an easy way to reuse an existing
> solution to deliver an easier experience for Geronimo users which,
> IMO, should be our ultimate goal.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>
>
>
Re: Removing attributes and refs from the config.xml
Posted by Bruce Snyder <br...@gmail.com>.
I'm gonna go out on a limb here and ask why we're trying to make all
of this more difficult for users instead of easier? Requiring a user
to: 1) gain knowledge of the plans used to create the CARs, and 2) to
create a brand new XML file (config.xml) to define new functionality
or override existing functionality seems ridiculous. The proposed
solution seems to be treating the symptoms rather than the real
disease.
IMHO, CARs need to either be made more dynamic or need to be replaced
with something more dynamic. The trouble I have with CARs is that
changing them requires them to be fully rebuilt which requires the
Geronimo source. Average users don't have the knowledge or time to
deal with this so we offered the config.xml which we're finding
doesn't really solve the whole problem either. If I had my druthers,
I'd leave CARs the way they are and work to offer something more
dynamic as a long-term solution.
The idea I have is to use a standard XML dialect for configuration
files - like XBean which currently requires Spring. I'm sure that this
idea won't have many fans, but it's an easy way to reuse an existing
solution to deliver an easier experience for Geronimo users which,
IMO, should be our ultimate goal.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
Posted by Jeff Genender <jg...@apache.org>.
Aaron Mulder wrote:
> I accidentally followed up to this off-list, but I think Jeff and I
> have agreed to disagree. I prefer to avoid adding extra attributes to
> support an empty string value when we don't seem to really have a need
> for empty string values. Jeff (if I can try to summarize) feels that
> we ought to support all 3 possibilities (null, empty, not set) for the
> benefit of future GBean implementers who might have different needs.
> Additional input would be appreciated.
Aaron...you summarized me correctly ;-)
As Aaron said, input from others would be appreciated.
Jeff
>
> Thanks,
> Aaron
>
> On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
>>
>> Aaron Mulder wrote:
>>> What's wrong with just listing the attribute or reference with no
>>> content but without the new "empty=true"? As in:
>>>
>>> <gbean name="TomcatEngine">
>>> <reference name="TomcatValveChain" />
>>> </gbean>
>>>
>> This may be fine for references, but an empty string could be a
>> reasonable and valid setting for an attribute. Therefore we need a way
>> to designate a difference between an empty string value, a null value,
>> and full removal of setting the value.
>>
>> I also believe that we should be consistent. So the way we do it for
>> one, we probably should do it for the other.
>>
>> Jeff
>>
>>> Thanks,
>>> Aaron
>>>
>>> On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
>>>> The config.xml allows us to declare new GBeans and override references
>>>> and attributes of already existing Gbeans. But there is a missing
>>>> configuration item here, which is the ability to *remove* a reference or
>>>> attribute value from the configuration. Currently there is no way to do
>>>> this.
>>>>
>>>> Matt Hogstrom and I ran into this when trying to remove a logging
>>>> reference in one of the GBeans.
>>>>
>>>> An example of this is the TomcatValveChain on the TomcatEngine. As it
>>>> stands, our default implementation installs an AccessLogValve into the
>>>> TomcatValveChain reference. We wanted to shut off logging to test
>>>> different performance numbers and found that there was no way to "clear"
>>>> or remove a reference that was set in the car plan via the config.xml,
>>>> without rebuilding the car from the source.
>>>>
>>>> On further discussion with David J and Dain, we came up with a new xml
>>>> attribute to place on refs and attribute tags. You would use:
>>>>
>>>> empty="true"
>>>>
>>>> Example: You want to remove the access logger to improve web container
>>>> performance, you would declare the following in the config.xml, which
>>>> would remove the TomcatValveChain from the TomcatEngine:
>>>>
>>>> ...
>>>> <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
>>>> ...
>>>> <gbean name="FirstValve" load="false"/>
>>>>
>>>> <gbean name="TomcatEngine">
>>>> <reference name="TomcatValveChain" empty="true"/>
>>>> </gbean>
>>>> ...
>>>> </configuration>
>>>> ...
>>>>
>>>> You would do the same for attributes that needed to be removed.
>>>>
>>>> I have this all coded up and ready to check in, but wanted to get any
>>>> feedback or issues before I went ahead and did it.
>>>>
>>>> Comments?
>>>>
>>>> Jeff
>>>>
Re: Removing attributes and refs from the config.xml
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I accidentally followed up to this off-list, but I think Jeff and I
have agreed to disagree. I prefer to avoid adding extra attributes to
support an empty string value when we don't seem to really have a need
for empty string values. Jeff (if I can try to summarize) feels that
we ought to support all 3 possibilities (null, empty, not set) for the
benefit of future GBean implementers who might have different needs.
Additional input would be appreciated.
Thanks,
Aaron
On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
>
>
> Aaron Mulder wrote:
> > What's wrong with just listing the attribute or reference with no
> > content but without the new "empty=true"? As in:
> >
> > <gbean name="TomcatEngine">
> > <reference name="TomcatValveChain" />
> > </gbean>
> >
>
> This may be fine for references, but an empty string could be a
> reasonable and valid setting for an attribute. Therefore we need a way
> to designate a difference between an empty string value, a null value,
> and full removal of setting the value.
>
> I also believe that we should be consistent. So the way we do it for
> one, we probably should do it for the other.
>
> Jeff
>
> > Thanks,
> > Aaron
> >
> > On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
> >> The config.xml allows us to declare new GBeans and override references
> >> and attributes of already existing Gbeans. But there is a missing
> >> configuration item here, which is the ability to *remove* a reference or
> >> attribute value from the configuration. Currently there is no way to do
> >> this.
> >>
> >> Matt Hogstrom and I ran into this when trying to remove a logging
> >> reference in one of the GBeans.
> >>
> >> An example of this is the TomcatValveChain on the TomcatEngine. As it
> >> stands, our default implementation installs an AccessLogValve into the
> >> TomcatValveChain reference. We wanted to shut off logging to test
> >> different performance numbers and found that there was no way to "clear"
> >> or remove a reference that was set in the car plan via the config.xml,
> >> without rebuilding the car from the source.
> >>
> >> On further discussion with David J and Dain, we came up with a new xml
> >> attribute to place on refs and attribute tags. You would use:
> >>
> >> empty="true"
> >>
> >> Example: You want to remove the access logger to improve web container
> >> performance, you would declare the following in the config.xml, which
> >> would remove the TomcatValveChain from the TomcatEngine:
> >>
> >> ...
> >> <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
> >> ...
> >> <gbean name="FirstValve" load="false"/>
> >>
> >> <gbean name="TomcatEngine">
> >> <reference name="TomcatValveChain" empty="true"/>
> >> </gbean>
> >> ...
> >> </configuration>
> >> ...
> >>
> >> You would do the same for attributes that needed to be removed.
> >>
> >> I have this all coded up and ready to check in, but wanted to get any
> >> feedback or issues before I went ahead and did it.
> >>
> >> Comments?
> >>
> >> Jeff
> >>
>
Re: Removing attributes and refs from the config.xml
Posted by Jeff Genender <jg...@apache.org>.
Aaron Mulder wrote:
> What's wrong with just listing the attribute or reference with no
> content but without the new "empty=true"? As in:
>
> <gbean name="TomcatEngine">
> <reference name="TomcatValveChain" />
> </gbean>
>
This may be fine for references, but an empty string could be a
reasonable and valid setting for an attribute. Therefore we need a way
to designate a difference between an empty string value, a null value,
and full removal of setting the value.
I also believe that we should be consistent. So the way we do it for
one, we probably should do it for the other.
Jeff
> Thanks,
> Aaron
>
> On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
>> The config.xml allows us to declare new GBeans and override references
>> and attributes of already existing Gbeans. But there is a missing
>> configuration item here, which is the ability to *remove* a reference or
>> attribute value from the configuration. Currently there is no way to do
>> this.
>>
>> Matt Hogstrom and I ran into this when trying to remove a logging
>> reference in one of the GBeans.
>>
>> An example of this is the TomcatValveChain on the TomcatEngine. As it
>> stands, our default implementation installs an AccessLogValve into the
>> TomcatValveChain reference. We wanted to shut off logging to test
>> different performance numbers and found that there was no way to "clear"
>> or remove a reference that was set in the car plan via the config.xml,
>> without rebuilding the car from the source.
>>
>> On further discussion with David J and Dain, we came up with a new xml
>> attribute to place on refs and attribute tags. You would use:
>>
>> empty="true"
>>
>> Example: You want to remove the access logger to improve web container
>> performance, you would declare the following in the config.xml, which
>> would remove the TomcatValveChain from the TomcatEngine:
>>
>> ...
>> <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
>> ...
>> <gbean name="FirstValve" load="false"/>
>>
>> <gbean name="TomcatEngine">
>> <reference name="TomcatValveChain" empty="true"/>
>> </gbean>
>> ...
>> </configuration>
>> ...
>>
>> You would do the same for attributes that needed to be removed.
>>
>> I have this all coded up and ready to check in, but wanted to get any
>> feedback or issues before I went ahead and did it.
>>
>> Comments?
>>
>> Jeff
>>
Re: Removing attributes and refs from the config.xml
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
What's wrong with just listing the attribute or reference with no
content but without the new "empty=true"? As in:
<gbean name="TomcatEngine">
<reference name="TomcatValveChain" />
</gbean>
Thanks,
Aaron
On 2/24/06, Jeff Genender <jg...@apache.org> wrote:
> The config.xml allows us to declare new GBeans and override references
> and attributes of already existing Gbeans. But there is a missing
> configuration item here, which is the ability to *remove* a reference or
> attribute value from the configuration. Currently there is no way to do
> this.
>
> Matt Hogstrom and I ran into this when trying to remove a logging
> reference in one of the GBeans.
>
> An example of this is the TomcatValveChain on the TomcatEngine. As it
> stands, our default implementation installs an AccessLogValve into the
> TomcatValveChain reference. We wanted to shut off logging to test
> different performance numbers and found that there was no way to "clear"
> or remove a reference that was set in the car plan via the config.xml,
> without rebuilding the car from the source.
>
> On further discussion with David J and Dain, we came up with a new xml
> attribute to place on refs and attribute tags. You would use:
>
> empty="true"
>
> Example: You want to remove the access logger to improve web container
> performance, you would declare the following in the config.xml, which
> would remove the TomcatValveChain from the TomcatEngine:
>
> ...
> <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
> ...
> <gbean name="FirstValve" load="false"/>
>
> <gbean name="TomcatEngine">
> <reference name="TomcatValveChain" empty="true"/>
> </gbean>
> ...
> </configuration>
> ...
>
> You would do the same for attributes that needed to be removed.
>
> I have this all coded up and ready to check in, but wanted to get any
> feedback or issues before I went ahead and did it.
>
> Comments?
>
> Jeff
>
Re: Removing attributes and refs from the config.xml
Posted by Jeff Genender <jg...@apache.org>.
Matt Hogstrom wrote:
> I'm not sure I get the relevance of empty=true. For instance, in the
> current config.xml there is no reference to the FirstValve as it is
> added when the car is built at assembly time. As a consequence, the end
> user (in this case me) had no idea that the FirstValve existed. So in
> the above exmple I think specifying load=false should be sufficient to
> disable the logging.
I think we have 2 separate issues here. One is the ability to remove a
set attribute or reference, the other is as it pertains to this
situation. Let me address each one.
The empty="true" really is no different than overriding a value. The
developer/user is not going to really know its original value w/o
looking at the original plan file (which is why I think we should
include them for reference like we did before).
IMHO if someone dinks around in the config.xml, they should have a
reasonable understanding of what they are messing with.
The empty="true" should allow you to remove a setting, whether it be a
reference to another GBean or an attribute, so that the originating
GBean can use its internal default, all without the need to recompile G.
As for the chaining, the example you give would be great, but the
problem is when GBeans refer to other Gbeans, just shutting them off
will not work, since there is an innate kernel issue that expects the
dependency to be available. Sure, we shut off the FirstValve, but now
the kernel won't start up the EngineGbean because it has a reference to
another GBean that doesn't exist. Is there a better way to order Valves
and make them declarative and pluggable into the Engine, all without
affecting references? Its worth a chat and probably a good discussion.
>
> As a second note, if there had been several items in the ValveChain
> (some of which were created at assembly time) would the empty=true mean
> that all entries in the chain would be invalidated (and the FirstValve
> one also) would not be loaded?
Not totally. IIU what you are saying, you would need to shut off all
the Valve GBeans in the chain (load=false), and only do an empty=true on
the EngineGbean/HostBean that refers to the first one in the chain.
>
> From a user perspective we would want to expose this configuration
> attribute "logging" as a checkbox in the console so one could avoid
> editing the config.xml if possible. I'm probably missing something in
> how this all is wired together so apologies in advance if I'm on the
> same planet but a different world.
Yes, and I completely agree. But this should go much further than that.
It would be great to have a GUI make it simple to set up valves, order
them (which means they will get chained)...but until then we are stuck
with the old config.xml and an editor. :(
>
> This fixes the problem we have with logging Jeff and this is awesome.
> As we talked this attribute will probably double our WebContainer
> performance. I think we need to go back through these configuration
> options and get them into the console. I'd volunteer but my plated
> overfloweth with good ideas and unfinished projects. Probably should
> add this to the what can I do list.
>
Sounds great. We can chat more on this and I would be happy to help out
there.
Jeff
Re: Removing attributes and refs from the config.xml
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Inline:
Jeff Genender wrote:
> The config.xml allows us to declare new GBeans and override references
> and attributes of already existing Gbeans. But there is a missing
> configuration item here, which is the ability to *remove* a reference or
> attribute value from the configuration. Currently there is no way to do
> this.
>
> Matt Hogstrom and I ran into this when trying to remove a logging
> reference in one of the GBeans.
>
> An example of this is the TomcatValveChain on the TomcatEngine. As it
> stands, our default implementation installs an AccessLogValve into the
> TomcatValveChain reference. We wanted to shut off logging to test
> different performance numbers and found that there was no way to "clear"
> or remove a reference that was set in the car plan via the config.xml,
> without rebuilding the car from the source.
>
> On further discussion with David J and Dain, we came up with a new xml
> attribute to place on refs and attribute tags. You would use:
>
> empty="true"
>
> Example: You want to remove the access logger to improve web container
> performance, you would declare the following in the config.xml, which
> would remove the TomcatValveChain from the TomcatEngine:
>
> ...
> <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car">
> ...
> <gbean name="FirstValve" load="false"/>
>
> <gbean name="TomcatEngine">
> <reference name="TomcatValveChain" empty="true"/>
> </gbean>
> ...
> </configuration>
> ...
>
> You would do the same for attributes that needed to be removed.
>
I'm not sure I get the relevance of empty=true. For instance, in the current
config.xml there is no reference to the FirstValve as it is added when the car
is built at assembly time. As a consequence, the end user (in this case me) had
no idea that the FirstValve existed. So in the above exmple I think specifying
load=false should be sufficient to disable the logging.
As a second note, if there had been several items in the ValveChain (some of
which were created at assembly time) would the empty=true mean that all entries
in the chain would be invalidated (and the FirstValve one also) would not be loaded?
From a user perspective we would want to expose this configuration attribute
"logging" as a checkbox in the console so one could avoid editing the config.xml
if possible. I'm probably missing something in how this all is wired together
so apologies in advance if I'm on the same planet but a different world.
This fixes the problem we have with logging Jeff and this is awesome. As we
talked this attribute will probably double our WebContainer performance. I
think we need to go back through these configuration options and get them into
the console. I'd volunteer but my plated overfloweth with good ideas and
unfinished projects. Probably should add this to the what can I do list.
> I have this all coded up and ready to check in, but wanted to get any
> feedback or issues before I went ahead and did it.
>
> Comments?
>
> Jeff
>
>
>