Re: [wildfly-dev] Capabilities and Requirements - Common Definitions

Thanks for raising this; it's a good set of questions. I'll be AFK for a week starting late today, so I'll start with point #2 even though that's backwards. It's just the one where I have a stronger opinion. The controller module should be about basic API for creating resources, attributes, handlers. Having other stuff like the actual ModelControllerImpl in there isn't pure, but I don't mind much. But then over time I and others have put some stuff in there basically just because both server and host-controller use it. We need to move away from that kind of thing, and not add more. As for your question 1, I don't feel strongly at all, just have some thoughts. To initially use a capability, people are going to have to look up data. We're not going to stick all of these in controller, so that means there's going to be a search, and these kinds of classes are going to be dispersed. Trying to maintain some fairly centralized document somewhere would actually make that initial search easier. Using constants like in your PR is helpful for later maintenance. If some constant is deprecated, referrers will see that in their IDE. They can easily click to read javadoc and learn if the requirement's dynamic and the service type. The biggest concern I have is avoiding premature classloading links. This is important in the case of optional requirements. If a requirement is optional, it's critical that the declaration of the requirement in the code doesn't force loading of classes from the required capability's module. Otherwise that module is no longer optional and its harder to create a slim distribution. On 5/22/15 5:31 AM, Darran Lofthouse wrote: -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat