[wildfly-dev] Capabilities and Requirements - Common Definitions

[Brian Stansberry]

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:
> Following on from PR https://github.com/wildfly/wildfly-core/pull/757
> and my final comment in the PR we need to have a discussion on how we
> coordinate capability and requirement definitions - especially where
> multiple components need a common definition.
>
> The first option is to do it all by convention and have no shared
> constants, the down side of this is we now need to document this and
> keep the document maintained.  A document would also make it hard in the
> future to flag certain capabilities as deprecated if preferred
> alternatives are made available.
>
> The second option would be to just define the Strings somewhere and use
> Javadoc to specify if the capability is dynamic and it's service type.
>
> The third option is defining the string and RuntimeCapability instances
> in a central place so they can both be referenced as needed.
>
> Any other options?
>
> Where these live will be a second point to discuss but that is heavily
> driven based on what we will share in the first place.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat