The only simple solution I can see to the local tmp/deploy
copy name problem as it relates to being able to specify
Java2 codebase permissions is to replicate the original
url path under the tmp/deploy directory. So:
path1/lib => ${jboss.home}/tmp/deploy/path1/lib
path1/lib/ext => ${jboss.home}/tmp/deploy/path1/lib/ext
path2/deploy => ${jboss.home}/tmp/deploy/path2/deploy
path3/deploy => ${jboss.home}/tmp/deploy/path3/deploy
httpPath1/lib/a.jar => ${jboss.home}/tmp/deploy/http/host/path1/lib
httpPath1/lib/ext/b.jar => ${jboss.home}/tmp/deploy/http/host/path1/lib/ext
Which allows for a simple transformation from the original permission
specification to the reployment location:
grant codeBase "file:/path1/lib/ext/*" {
permission java.lang.RuntimePermission "setPrincipalInfo";
};
becomes:
grant codeBase "file:/${jboss.home}/tmp/deploy/path1/lib/ext/*" {
permission java.lang.RuntimePermission "setPrincipalInfo";
};
grant codeBase "http://installhost/path1/lib/ext/*"; {
permission java.lang.RuntimePermission "setPrincipalInfo";
};
becomes:
grant codeBase
"file:/${jboss.home}/tmp/deploy/http/installhost/path1/lib/ext/*" {
permission java.lang.RuntimePermission "setPrincipalInfo";
};
since the PolicyFile implementation does allow property references.
You won't be able to assign permissions to individual jars or
subcomponents of ears, wars, sars, etc., but I think we can live
with that. Any better ideas?
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
