Resource encapsulation

[Peter Kriens]

I think I understand how a module aware JPA can use the Module API to load resources and classes. This sounds similar to how OSGi works.

For the service loader scenario I am not clear how you would then discover and load the persistence.xml resources. Would you then not still be forced to go through the Module API anyway to read resources since the javax.persistence.Configuration implementation would not allow the JPA provider to read the persistence.xml? Isn’t using the service loader sounds like an unnecessary indirection?

Thanks for the reply, kind regards,

	Peter Kriens




> On 5 okt. 2015, at 20:59, mark.reinhold at oracle.com wrote:
> 
> (combining several questions into one topic thread)
> 
> 2015/9/28 10:02 -0700, peter.kriens at aqute.biz:
>> The javadoc for getResource* says: 
>> 
>> 	‘This method does not find resources in named modules’.
>> 
>> Literally this implies that a class in a named module cannot read its
>> own resources. I assume that this is an oversight in the description?
> 
> There is a plethora of resource-lookup methods.  The current state of
> affairs is:
> 
>  - A class in a named module can read its own resources via the
>    Class::getResourceAsStream method, which returns an InputStream.  It
>    can get a URL to one of its own resources via the Class::getResource
>    method [1].  These methods will not locate resources in other named
>    modules.
> 
>  - The ClassLoader::getResource* methods do not locate resources in any
>    named modules.
> 
>  - All existing resource-lookup methods in Class and ClassLoader work as
>    they do today for resources on the class path.
> 
>  - The new java.lang.reflect.Module::getResourceAsStream method can be
>    used to read the resources of any named module, without restriction.
> 
> These choices are a first attempt to strike a balance between satisfying
> the "resource encapsulation" [2] and "readable artifact" requirements [3]
> while making it reasonably easy to migrate existing components into
> modules, but I don't think we're quite there yet.  At the very least, the
> Module::getResourceAsStream method needs to be restricted somehow so that
> only "suitably-privileged" code (for some definition of that term) can
> access resources in a named module other than its own.
> 
> 2015/9/28 10:03 -0700, peter.kriens at aqute.biz:
>> In Java Persistence Architecture (JPA) the persistence.xml resource
>> provides information about the persistence unit. This resource must be
>> read by the Persistence Provider which then does a lot of magic.
>> 
>> However, if nobody can read resources from a named module then how can
>> JPA perform its duties?
> 
> JPA will work exactly as it does today for code on the class path.
> 
> A future version of JPA that supports modules will, I assume, itself be
> a "suitably-privileged" module.  It can use the various reflection APIs
> (java.lang.reflect.Module, etc.) to locate run-time module objects and
> read their resources.
> 
> In the longer term, a better way for a module to publish configuration
> information for a framework such as JPA would be for it to supply a
> provider of a service type defined by the framework.  JPA could, e.g.,
> export and use a javax.persistence.Configuration service type, and then a
> client module could provide an instance of that type in order to convey
> its configuration information.
> 
> 2015/9/28 10:04 -0700, peter.kriens at aqute.biz:
>> Since resource loading is very restrictive I would expect that class
>> loading is also not possible unless a class is exported. Is this true?
> 
> The module system, as proposed, does not change the run-time visibility
> mechanism.  Methods such as Class::forName and ClassLoader::loadClass
> will work as they to today.  If a class loader queried by these methods
> finds a definition for the specified class then a Class object will be
> returned regardless of whether that class's package is exported by its
> defining module.  (Whether you can access members of the resulting class,
> or instances thereof, is a question of access control and hence is, now,
> dependent upon the module system.)
> 
> - Mark
> 
> 
> [1] This was enabled just last week: http://j.mp/1NgIVg7
> [2] http://openjdk.java.net/projects/jigsaw/spec/reqs/#resource-encapsulation
> [3] http://openjdk.java.net/projects/jigsaw/spec/reqs/#readable-artifacts