Michael Nash JGlobal.com wrote:
As we recently discovered, a problem can arise with configuration when an application is built with a different "mix" of services. For example: if you build the default applications with default persistence, the references to default-persistent in the configuration for, say, app-poll work just fine - they add the default security records and all is well.+1 Your idea seems great, and I don't see any problem with it.
If, OTOH, you build for Hibernate, you'll have a problem, as these "default-persistent" entries have no class defined for them, and the Keel container will choke on startup as a result. Of course, you can go back and remove them all, then put in the hibernate equivilants, but that's painful.
Instead, I'm trying a method that will allow certain configuration elements to be skipped if a specific service is not selected. This works much like the Ant "if" attribute - in fact, I used the "if" attribute to do it, for consistency. Then, you could do something like this:
<default-persistent id="..." if="service.persist.default"> .... </default-persistent>
If you build with service.persist.default=true in your *-deploy.properties, this configuration will be enabled as usual. If you do not have service.persist.default set, it will be "pruned" from the configuration before the container sees it during startup. Along similar lines, there is configuration in app-poll for the "Navigate" application:
<nav.navigate id="nav.navigate"> <menu id="...."> ... menu entries for poll ... </menu> </nav.navigate>
If you're *not* using Navigate (app.navigate) then this configuration will also complain on startup, as nav.navigate's class is not found. You could now (with this proposed feature) say:
<nav.navigate id="nav.navigate" if="app.navigate"> .... as before ....
And not have to worry about the specific deployment. If navigate is there, it's used. If it's not, it's skipped.
One added bonus would be that it is then possible for a model (or another service) to determine which services are available at runtime, before trying to access them - not something needed a lot, but handy in some cases.
Anyone see a gotcha in this plan? If not, I'll test it and get it into CVS.
This is a pretty good illustration of the usefulness of a rules engine as applied to configuration issues.
Given:
Your approach, quite appropriately, takes a specific set of rules (if="service.persist.default" +++) and hard codes it into a specific technology implementation (ant).
Future:
It shall be nice when we can finally migrate all rules to a generic rules engine, and harness this rules engine by any client and any implementtion, including, but not limited to, configuration black boxes. When (not if) that happens, we will be able to take these specific configuration rules you already implement in ant, and migrate them to this more generic framework, and in turn hook them up to all models, all guis, and by implication, any subset of issues, configuration or not.
Even more interesting, if not a bit academic, is that configuration is the ultimate recursive keel implementation. A very flexibile framework that calls upon it's own flexibibility to configure it's own flexibility.
It's a bugger that the guy that was working on this went lame for a while.... What's up with that?
Regards,
Michael Nash
JGlobal Ltd Next-Generation Web Application Development and Open Source Support
http://www.jglobal.com
Bahamas Commerce and Trade Offshore eCommerce Hosting and Business Services http://www.bahamascommerce.com
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
