This sounds good. Only thing I am wondering is the connection between the property in the "if" attribute and how to tie the availability of a particular service/app. One way might be to create a data file from an ant target that transforms the service.x.y or app.z properties into the file, and then to read that from the configuration process?
Shash
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.
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.
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
