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

[Jaikiran Pai]

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?


> 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.


-Jaikiran