Discussion: #MutableConfigurations, #LazyConfigurationAndInstantiation, #CyclicDependences, & #DiscardableModules

David M. Lloyd david.lloyd at redhat.com
Tue Dec 6 00:10:18 UTC 2016

On 12/05/2016 05:07 PM, mark.reinhold at oracle.com wrote:
> 2016/11/29 18:47:59 -0800, david.lloyd at redhat.com:
>> On 11/29/2016 06:09 PM, mark.reinhold at oracle.com wrote:
>>> 2016/11/22 13:19:19 -0800, david.lloyd at redhat.com:
>>>> On 11/21/2016 03:52 PM, mark.reinhold at oracle.com wrote:
>>>>> ...
>>>>> If you're using an approach similar to what I suggested for OSGi [1]
>>>>> then you should be able to implement cycles amongst JBoss modules by
>>>>> inserting the necessary readability edges after each module is
>>>>> instantiated in its own layer.  This will be much easier with the new
>>>>> API proposed for #ReadabilityAddedByLayerCreator [2].
>>>> I asked earlier whether this allows the class resolver
>>> (What's a "class resolver" in this context?)
>> The part of the class loader that resolves references between classes
>> and performs linkage.  There seems to be no non-overloaded term for
>> this, anymore.
> If that's what you mean by "class resolver" then you're really talking
> about class loaders, not the module system, or at least not JPMS, since
> JPMS doesn't change how class loading works.
>>> ...
>>> If you want to allow cycles amongst your own modules then you can resolve
>>> them yourself and add whatever cycle-inducing readability edges you need.
>>> That is, as I understand it, how Watson's OSGi embedding works.
>> But it fails when the actual classes have direct references to one
>> another.
> Can you be more specific?  How does it fail?  Is Watson's OSGi embedding
> broken?
> In addition to writing your own resolver you can -- and I've assumed that
> you, like Watson, would -- write your own class loaders to resolve class
> references in whatever way you require, even looking up classes in nearby
> cyclically-related modules according to whatever module-graph data
> structure you construct.

Hmm, if this is true then maybe there isn't a problem anymore; I'll 
update to the latest and see if I can make this work.

> Unless that approach is broken then my original question remains [3]:
>   Is this approach workable for JBoss Modules as well?  If so then I'd
>   like to close these issues out; if not then I'd like to understand if
>   there are additional, smaller changes that would make this approach
>   acceptable while avoiding the complexity of complete solutions to
>   these issues.

I'll try and produce a definitive answer as quickly as possible.

More information about the jpms-spec-experts mailing list