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 <[EMAIL PROTECTED]> 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)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache Geronimo (http://geronimo.apache.org/)

Castor (http://castor.org/)

Reply via email to