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

[Jaikiran Pai]

On Thursday 08 December 2016 08:28 PM, David M. Lloyd wrote:
> On 12/08/2016 08:41 AM, Jaikiran Pai wrote:
>>
>>>    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?

Yes, it does now. Thanks for explaining that part.



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

Thanks, I'll keep a watch and test it out whenever it's available.


-Jaikiran