Shash: > 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?
Yep, that's exactly what I did. I've added lines in custom.xml that append a line for each service to a modules-system.xconf. Then when KeelContainer fires up, it can read that config, use it to filter the remaining config. Seems to work on my initial tests, but I'll beat on it a bit before I check anything in. Mike > > 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 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
