Hi BJ

I appreciate your reply.

I almost understand.




On Thu, 24 Mar 2011 10:49:45 -0400
BJ Hargrave <[email protected]> wrote:

BJ> Why does bundle H capture an ACC at the time a servlet is registered (and 
BJ> the assert it when calling the servlet)? That seems pointless and I do not 
BJ> see any correlation between the call stack at the time of servlet 
BJ> registration and the time of servlet execution.

The reason why bundle H capture an ACC at the time a servlet is registered
is that it is written in "102.8.2 Accessing Other Types of Resources" in
the spec:
-------
Therefore, the Http Service must capture
the AccessControlContext object of the bundle registering resources or a
servlet, and then use the captured AccessControlContext object when
accessing resources returned by the registered HttpContext object.
-------

However, the behaivior of BundleH that asserting the captured ACC when
calling the Servlet#service() is a bug. BundleH must asserting the
captured ACC is only for getting when accessing resource URL objects as
"102.8.2".

Is my understanding correct ?

BJ> For your question at the end, (b) is not correct and (a) is partially 
BJ> correct. Servlet B *must* use doPrivilege to exercise some permission it 
BJ> has been granted. 

>From spec point of view, let me clarify:

- Whether the default HttpContext is used or not, Servlet and
HttpContext objects must use a doPrivileged construct in 
their implementations when performing privileged operations.

- The reason of it is there is no guarantee that the permission is not
granted to the HttpService impl bundle.

Is it correct ?

Best regards,

=======
Ikuo YAMASAKI


BJ> But I fail to see why bundle H captures the ACC and 
BJ> asserts it when calling Servlet B.
BJ> -- 
BJ> 
BJ> BJ Hargrave
BJ> Senior Technical Staff Member, IBM
BJ> OSGi Fellow and CTO of the OSGi Alliance
BJ> [email protected]
BJ> 
BJ> office: +1 386 848 1781
BJ> mobile: +1 386 848 3788



_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to