Re[2]: Patch-module with dynamic layer creating.

[Alex Sviridov]

Суббота, 13 октября 2018, 10:43 +03:00 от Alan Bateman <Alan.Bateman at oracle.com>:
>
>On 12/10/2018 21:57, Alex Sviridov wrote:
>> Hi Alan,
>>
>> Thank you for detailed explanation. It is great that we have API that allows to implement
>> such features. However, what I suggest is a little different. I am speaking about using
>> existing code for such features.
>>
>> I think this way - firstly, we can do write the same code many times. We can, but we
>> don't want. Secondly if we pass parameters to JPMS via JVM options to configure boot
>> layer, it would be great if we had possibility to pass the same parameters to configure a
>> custom layer without writing a line of code and use existing JDK code.
>>
>> Of course this is my person opinion. It is interesting to hear what other developers think.
>>
>I'm skeptical on both the feasibility and desirability of going there. 
>If a container is creating module layers at runtime then it is arranging 
>which modules are observable, e.g. it may choose one version of JAX-RS 
>for one configuration/layer, and another version for another 
>configuration/layer. In your scenario it may want to patch or augment 
>one of these modules. I don't think you can easily express this on the 
>command line as there isn't anything to identify the layer than you want 
>to adjust. 
I am sorry, maybe I didn't express this very clear: I mean something like this:
 ModuleLayer layer = parent.defineModulesWithOneLoader(cf, scl, args); Where args are for example String[] and we pass the same --add-exports, --add-opens, --patch-module, 
--add-modules, --add-reads etc that we pass to configure boot layer. The disadvantage of such way
is using String. However, there are two main advantages: 1) no line of code 2) use the same parameters
that we use to configure boot layer - one solution within one technology.

-- 
Alex Sviridov