Hi Erik, If the AppManifest is present then it overrides/replaces the isis.services key in the configuration file.
The general idea is to provide an empty module class at the base package of your app. Include this class in the list returned from getModules(). The framework uses the package of this module class to identify where in the classpath to go searching. You'll see that all the isisaddons use this approach. The framework itself uses this for the applib services, but there is also a hard coded list of additional packages that are for internally implemented services. From memory that hardcoded last is a constant field of AppManifest interface. In addition to all that, you can also specify additional service classes in the AppManifest 's getServices() method. The intended usage of this is for integ tests and demos to subclass the app' s normal production AppManifest, eg to stub out/mock external services. The solution to your bootstrap problem is a bit of lateral thinking... just define a module for your quartz stuff, but in the app module. So long as that module's package matches (or is in a parent package of) the service you want to pick up over in the webapp module, you should be good. HTH Dan On 4 May 2016 2:43 pm, "Erik de Hair" <[email protected]> wrote: Hi again :-) Something's not clear to me. Since using the AppManifest some services are not automatically registered. After adding them to the AppManifest they were. Other services though, were registered like in older Apache Isis versions. Did anything change? I can't find it in the docs/release/migration notes. And I have a service in the webapp for registering Quartz-jobs (dependencies only added in the webapp). Because of the above issue it's not registered and doesn't show up in the main menu. The app-module doesn't have a dependency on the web app (and it can't be added because of circular annotation processing problems). How can I add a service from the webapp to the AppManifest or at least make sure it is loaded? Erik
