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)[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/)
