dev@glassfish.java.net

Re: OSGi Services in GlassFish 3.1

From: Michael Hollatz <michael.hollatz_at_profitbricks.com>
Date: Thu, 17 Feb 2011 23:27:50 +0100

On 02/17/2011 04:09 PM, Richard S. Hall wrote:
> On 2/16/11 18:56, PostMasteR wrote:
>> I just took another look inside the spec and found the ServicePermission
>> (Core R4.2 - 5.10.1) very useful, but I didn't see any mention of the
>> reverse direction that I would like to use.
>>
>> The basic use case I have here is simply that I have some application
>> modules which itself are split up into several bundles, e.g.:
>>
>> User module:
>> * API
>> * EJB impl
>> * JPA impl
>> * Client model
>> * WebService
>>
>> 1.) only the EJB Impl is allowed to consume the service exported by the
>> JPA impl bundle
>> 2.) The JPA impl is not allowed to consume any of our application level
>> services (of course, it is the lowest level)
>> 3.) The WebService is only allowed to consume the service exported by
>> the EJB impl bundle by using the interfaces from the API bundle and the
>> client model implementation classes from the "Client model" bundle
>>
>> That are the basics that I would like to start with. I hope that such a
>> setup doesn't sound too strange. :)
>
> You should be able to use ServicePermission to grant bundles the right
> (or deny the right) to only use services from bundles with a given
> symbolic name or signed by a given bundle signer. I think this should do
> what you want.
>
> For example, you could grant EJB Impl the right to consume services from
> JPA Impl. As long as you grant it no other rights, then it can only see
> services offered by JPA Impl (or you can limit it to specific service
> types from the JPA Impl).

Well, and that's the part what I would like to reverse. For example I
would like to specify inside bundle "JPA Impl" that only the
corresponding "EJB Impl" (maybe based on the bundles symbolic name) may
consume the service it exports. So exactly the other way round the
specification does.

This is more or less an idea to enforce some design/architectural
considerations and to prevent any third-party implementation to break it
just because it has specified some additional permission by itself.

>
> -> richard
>
>>> -> richard
>>>
>>>> Thanx
>>>>