[wildfly-dev] Capabilities and Requirements - Common Definitions

[Darran Lofthouse]

On 22/05/15 13:57, Brian Stansberry wrote:
> 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.

I can move it to a different module but most likely I think that would 
be a new module, 'server' could have been a candidate but that depends 
on too many artifacts that will also need to reference these.

> 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.

At the moment with this PR all I am proposing is a central location for 
capabilities that we know will be widely used, in this case the server 
and subsystems etc. are going to have hard coded dependencies on Elytron 
APIs - what is not hard coded is how the implementations of those APIs 
are actually made available.

The Elytron project could not contain these definitions as that has no 
dependencies on WildFly, the Elytron Subsystem can not contain this as 
that is an optional module.

> 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.

In this case the only classes being referenced are classes from the 
Elytron module and that module is going to be mandatory within the server.

Generally it sounds like 'controller' is a no-go so the format of any 
constants in code will probably dictate where this lives.

If we are only talking Strings I may be able to add it to the 
'wildfly-core-security-api' module although javadoc can not reference 
any capability related classes so that may not be preferable - of I can 
create a new module with a dependency on controller and everything else 
that uses Elytron capabilities can then depend on this new artifact / 
module.

> 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
>>
>
>