> Remy Maucherat wrote:
> >
> > > grant codeBase="jar:file:{path-to-webapp}/WEB-INF/lib/some.jar" {
> > > // Some permissions for this jar
> > > };
> > >
> > > grant codeBase="jar:file:{path-to-webapp}/WEB-INF/lib/-" {
> > > // Some permissions for this jar
> > > };
> >
> > No, after the fix, it would be the same as for the URLClassLoader:
> >
> > grant codeBase="file:{path-to-webapp}/WEB-INF/lib/some.jar" {
> > // Some permissions for this jar
> > };
> >
> > grant codeBase="file:{path-to-webapp}/WEB-INF/lib/-" {
> > // Some permissions for the jars
> > };
> >
>
> I would prefer it if the difference in codeBase were left in
> WebappClassLoader.
I'm quite sure the StandardClassLoader which was used before was generating
the second type of source location URLs
(file:{path-to-webapp}/WEB-INF/lib/some.jar).
> Here is the reason. The root context is the
> codeBase for JSP pages. The JSP pages require all permissions that
> any unerlying jar's need. Yet you may not want to grant all of the
> jar files all the permissions a JSP page has. If the web app root
> and the jars have the same codeBase there is no way to fine tune
> your security policies.
By "The root context is the codeBase for JSP pages", do you mean that the
source code URL is "file:{path-to-webapp}/" ?
> Of course this will be moot when my SecurityManager proposal is
> implemented.
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
