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