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 
>>>>> 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 .
>>>> 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
> Can you be more specific? How does it fail? Is Watson's OSGi embedding
> 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 :
> 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-observers