geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Removing attributes and refs from the config.xml
Date Sun, 26 Feb 2006 17:27:09 GMT
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/)


Mime
View raw message