Brainstorming. Right now we have a filesystem directory structure for configuration, containing multiple Properties serializations in various directories, XML documents, template texts, etc. We need support for standalone simple values, structures that group related values, and opaque structured values (such as database connections and maybe email connections). Some of it is "owned" by the repository admin.s and some of it by the container admin.s (who might be different people).
Why not throw the whole problem over the fence and use JNDI to access it all? Directory services have the shape that we need, and we can leave it up to the site as to how the data are actually stored: LDAP, a huge list of <Environment> elements, a custom provider (possibly filesystem- or DBMS-backed), or even a federated structure of different providers for different bits. We could provide a default setup using <Environment> elements. Non-JEE containers aren't *required* to have a built-in JNDI provider, but I can't think offhand of any that do not. -- Mark H. Wood, Lead System Programmer [email protected] Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
