Hi,
I have a question about the following ...
On 07/13/2016 11:47 PM, mark.reinh...@oracle.com wrote:
To point (2), if some packages in a user module need to be exported for
reflection at run time, and a container wishes to ensure that only select
"trusted" framework modules can access the types in those packages, then
that's already expressible today. We can also ensure that the set of
packages exported by a module is the same whether it's used standalone
on Java SE versus inside a container, which as you observe elsewhere in
this thread [1] could be problematic.
Suppose, e.g., we have an application module that's written against JPA,
rather than any specific JPA implementation, and exports the package
containing its entity classes for reflection at run time:
module com.foo.data {
requires java.persistence;
exports dynamic com.foo.data.model;
}
When used standalone, outside of a container, this module will export the
package containing its entity classes for reflection at run time. The
classes will be accessible to every other module, but from a security and
integrity standpoint we assume that whoever invokes the run-time system,
i.e., whoever provides the command-line arguments to the `java` launcher
or its equivalent, is trusted to ensure that no adversarial modules are
present.
When used inside a container, the container already has the power to
prevent an adversarial module from accessing the module's entity classes.
That's because we expect containers to load every application into a
unique layer [2], and a container can rewrite module descriptors when
configuring a layer. This is nothing to be ashamed of -- we fully expect
it to become a common practice.
If the container is set up to provide, e.g., Hibernate to this particular
application, then it could narrow the accessibility of the entity classes
by rewriting the above module declaration to refine the `exports dynamic`
directive:
module com.foo.data {
requires java.persistence;
exports dynamic com.foo.data.model
to hibernate.core, hibernate.entitymanager;
}
(This is one of the very few use cases for qualified dynamic exports.)
Whether standalone or in a container the same set of packages is exported
by the module; the only difference is that, inside the container, the
exports are qualified.
What additional metadata does container need to rewrite a module
descriptor like in above example? Does it need the whole set of exports
that replace existing dynamic exports? Or only the target modules that
it "attaches" to all unqualified dynamic exports? If the later, then
what does container do if one wants to rewrite only a selection of
unqualified dynamic exports to target one set of modules (for example an
IoC implementation) and another (possibly overlapping) selection of
exports to target some other set of modules (for example a JPA
implementation)? Does it give up and "attaches" all targets to all
unqualified dynamic exports ?
I think something is missing here. A kind of hook to identify or "tag" a
set of unqualified dynamic exports so that it can be located by the
container.
Regards, Peter
