On 27/01/11 6:24 PM, Laird Nelson wrote:
> On Thu, Jan 27, 2011 at 3:44 AM, Kumar.Jayanti
> <Vbkumar.Jayanti_at_sun.com <mailto:Vbkumar.Jayanti_at_sun.com>> wrote:
>
> It depends on whether BigCo's EAR uses any security (using
> descriptors and/or annotations). If it did then GlassFish will
> ensure it will generate appropriate policy when the EAR was
> deployed to control its access.
>
>
> I understand how Glassfish works when either the default or in-memory
> JACC provider is selected. I am talking about the case where (a) I
> supply a new JACC provider and (b) unbeknownst to me BigCo has done
> the same. In such a case, it seems to me that Glassfish policy
> generation is beside the point, since the policy provider in question
> may not even read those files.
>
That's right. It is free to do whatever it wants.
> Again, what happens when I replace the BigCo-authored JACC policy
> provider that BigCo was relying upon?
>
JACC Provider is a domain-wide configuration and applies to all
Applications. So when you replace the BigCo-authored JACC policy
provider you know what you are doing....
One thing that you can do is that your new JACC Policy Provider
instantiate and use BigCo's implementation as a delegate. And there for
PolicyContext Id's that correspond to BigCo's App, you delegate the
calls to the delegate and otherwise use your implementation. And this
is doable even if you do not have source code of BigCo's JACC Provider.
The JavaEE Compatibility Test Suites do this kind of thing where they
wrap over the vendors provider.
HTH,
kumar
> Best,
> Laird