[wildfly-dev] JBoss Modules - "advanced" PathFilter for ResourceLoaderSpec?

[David M. Lloyd]

On 12/08/2016 08:41 AM, Jaikiran Pai wrote:
> Hi David,
>
> On Thursday 08 December 2016 07:29 PM, David M. Lloyd wrote:
>> Hi Jaikiran!
>>
>> On 12/08/2016 05:59 AM, Jaikiran Pai wrote:
>>> However, although it might work, I then have to keep a very close vigil
>>> or rather keep inspecting what packages (or resources in general) the
>>> modules A, B and C provide. Instead what I'm thinking of is a "smart"
>>> PathFilter or anything along those lines whose semantics would be to
>>> "skip/don't accept/filter out all those resources, from a resource root,
>>> if the resource is provided by any of the specified modules". So
>>> something like:
>>>
>>> ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader,
>>> *PathFilters.excludeResourcesExposedByModules("A**:slot", "B:slot",
>>> "C:slot" ...)*);
>>>
>>>
>>> Having looked at the JBoss Modules code, I don't think this is possible
>>> currently. But that's OK. What I really want to check is, is this
>>> something that would be feasible to implement (doesn't have to be in
>>> JBoss Modules itself) and is there any obvious issues with the approach?
>>> Also, is this something that would be useful to have in JBoss Modules
>>> itself?
>> A smart filter is a pretty good idea!  I think that it might make more
>> sense as part of a dependency specification though,
>
> Agreed, having it on the dependency spec makes more sense and puts it in
> the right context.
>
>
>>   from a user's
>> perspective: if I say "I depend on module org.foo.bar:main" I should
>> also be able to say "...and use their packages" which would exclude all
>> paths in the source module's resource roots (other than META-INF and the
>> root path).
>
> When you say "would exclude all paths in the source module's resource
> roots...", you mean precedence will be given to the paths of the
> dependency module, right? Not literally exclude all paths of the
> source's resource roots? That way if (one or more) resource roots of the
> source module has a path "hello/world" which isn't part of the
> dependency module's paths, then it will get "accepted" and be available
> to the source module. Did I understand this right or did you intend to
> literally mean excluding all paths of the source module's resource roots?

I mean literally excluding.  Dependency-first (aka "parent-first") 
loading is fundamentally flawed in any non-tree graph.  To boil it down 
to the degenerate case, if I have two modules A and B which have a 
mutual interdependency and a common resource or class, using 
parent-first loading, A gets B's resource, while B gets A's resource, 
which is just plain weird.

Using local-first (aka "child-first") loading (as we do) and excluding 
local resource paths that are found in dependencies, A always gets A's 
resource, and B always gets B's resource.  If you want both, then you 
simply don't override, and A gets A's and then B's, and B gets B's and 
then A's.

Does that make sense?

>> In fact, maybe that ought to be the default setting, with the user
>> having to opt in to override packages.  So a user might say:
>>
>>      <dependencies>
>>          ...
>>          <module name="org.foo.bar">
>>              <override-paths/> <!-- now my paths take precedence -->
>>          </module>
>>          ...
>>      </dependencies>
>
> Yes, this looks logical.
>
>> In the programmatic API it'd be fairly straightforward as well.  We
>> could add an overridePaths path filter to the dependency specification
>> (which ought to be builder-based at this point, I now realize, what with
>> the parameter explosion).  Any dependency paths that are not matched by
>> that filter would be subtracted from all resource roots.
>
> Yes, this matches with my expectation.

Great!  I'll open up a JIRA for this enhancement.
-- 
- DML