geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Removing attributes and refs from the config.xml
Date Sun, 26 Feb 2006 19:09:34 GMT
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

If there is a better idea, then please bring it up...I am open to anything.


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 <> 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 (
>> Castor (

View raw message