12:36 a.m.
Hi,
I have couple of questions regarding access to resources in imported
modules. I noticed the following:
1) Assume that there's a module X, which contains resources under
META-INF, eg. META-INF/x.foo
2) Deployment Y declares a dependency on module X (via
META-INF/MANIFEST.MF 'Dependencies:') - to my best understanding the
same would happen even if there was a module Y declaring a <dependency/>
on X
If that is the case, the classloader of module Y will be able to find
resources contained in one of the jars of module X, except for anything
undeneath META-INF - so META-INF/x.foo will not be found.
In summary:
classLoaderModuleY.getResources("META-INF/x.foo") , 0 results
classLoaderModuleY.getResources("META-INF") will basically return an
entry for each and every JAR from dependencies
classLoaderModuleY.getResources("x/foo/bar/stuff") returns resource
'stuff' found in package x.foo.bar exported by module X
Apart from META-INF/services which is treated in a special fashion, how
is it possible to install and consume a set of libraries as modules
(e.g. shared libraries), if they contain files underneath META-INF,
since they are not accessible from within the referencing module? And
why is there a default restriction on META-INF (the way I read the
modules.xsd schema, this behaviour can never be overridden through the
module definition)?
Thanks,
Marius
8:58 a.m.
On 04/19/2011 12:36 AM, Marius Bogoevici wrote:
Hi,
I have couple of questions regarding access to resources in imported
modules. I noticed the following:
[...]
Apart from META-INF/services which is treated in a special fashion,
how
is it possible to install and consume a set of libraries as modules
(e.g. shared libraries), if they contain files underneath META-INF,
since they are not accessible from within the referencing module?
See below.
And why is there a default restriction on META-INF
Because basically if you do:
someModule.getClassLoader().getResourceAsStream("/META-INF/MANIFEST.MF"), you
don't want to get the manifest of every transitive dependency, just the
module you query directly. Other files in META-INF act similarly.
(the way I read the
modules.xsd schema, this behaviour can never be overridden through the
module definition)?
It can actually. Modules export all of their paths (including META-INF)
by default. The filtering happens on the import side because the filter
sequence for a module import contains some default entries at the end
which exclude META-INF. Now if you want to *include* some subpath of
META-INF, you may add an inclusive import filter which will override the
default exclusion. Like this:
...
<dependencies>
<module name="org.foo.bar">
<imports>
<include path="META-INF/mydirectory"/>
...
</imports>
</module>
...
</dependencies>
Right now we do not have support for filtering individual resource files
within a directory, but that is forthcoming [1].
[1] https://issues.jboss.org/browse/MODULES-69
--
- DML
9:43 a.m.
On 11-04-19 09:58 AM, David M. Lloyd wrote:
It can actually. Modules export all of their paths (including
META-INF)
by default. The filtering happens on the import side because the filter
sequence for a module import contains some default entries at the end
which exclude META-INF. Now if you want to *include* some subpath of
META-INF, you may add an inclusive import filter which will override the
default exclusion. Like this:
...
<dependencies>
<module name="org.foo.bar">
<imports>
<include path="META-INF/mydirectory"/>
...
</imports>
</module>
...
</dependencies>
Right now we do not have support for filtering individual resource files
within a directory, but that is forthcoming [1].
[1] https://issues.jboss.org/browse/MODULES-69
I guess this means that the module
definition above is applicable only
for paths (directories), but not individual files.
Will this be customizable in a deployment too, either via MANIFEST.MF,
or using a module definition for a deployment (are there some guidelines
on how can that can be done, except for customizing MANIFEST.MF)?
9:43 a.m.
On 04/19/2011 09:43 AM, Marius Bogoevici wrote:
On 11-04-19 09:58 AM, David M. Lloyd wrote:
> It can actually. Modules export all of their paths (including META-INF)
> by default. The filtering happens on the import side because the filter
> sequence for a module import contains some default entries at the end
> which exclude META-INF. Now if you want to *include* some subpath of
> META-INF, you may add an inclusive import filter which will override the
> default exclusion. Like this:
>
> ...
> <dependencies>
> <module name="org.foo.bar">
> <imports>
> <include path="META-INF/mydirectory"/>
> ...
> </imports>
> </module>
> ...
> </dependencies>
> Right now we do not have support for filtering individual resource files
> within a directory, but that is forthcoming [1].
>
> [1] https://issues.jboss.org/browse/MODULES-69
I guess this means that the module definition above is applicable only
for paths (directories), but not individual files.
Will this be customizable in a deployment too, either via MANIFEST.MF,
or using a module definition for a deployment (are there some guidelines
on how can that can be done, except for customizing MANIFEST.MF)?
Yes using MANIFEST.MF, no using a module definition but yes using
jboss-deployment-structure.xml (theoretically, I don't know if that
support is there yet).
--
- DML
5016
days inactive
5016
days old
3 comments
2 participants
participants (2)
-
David M. Lloyd -
Marius Bogoevici