I don't know if this can be useful but I developped a Maven plugin that uses a war preGoal to achieve classes packaging as a JAR. The site is here : http://projects.jahia.org/maven-jahiawar-plugin/ and please feel free to use as little or as much as you want from it.
This plugin also offers JSP precompilation for Tomcat, but you don't have to activate that.
Regards, Serge Huber.
David Sean Taylor wrote:
Randy Watler wrote:
Gang,
The deployment of individual class files from the portal project in
WEB-INF/classes instead of packaging as a jar and deploying in WEB-INF/lib
is causing java Permission checks to be significantly slower than they could
be.
The reason for this is that each individual *.class file is being treated as
a separate CodeSource/PermissionDomain and must be tested individually when
AccessController.checkPermission() is invoked. All classes deployed in a jar
file reuse a single CodeSource/PermissionDomain. Minimizing the number of
CodeSources/PermissionDomains will limit the number of access to
RdbmsPolicy.getPolicies(), because each unique CodeSource on the call stack
between the SecurityValveImpl.invoke() and
AccessController.checkPermission() invocations will result in an additional
RdbmsPolicy.getPolicies() hit, (per each user/unique call stack).
Do any of you have a problem with me modifying the maven build to package
the class files into a single jar? Was there a reason to deploy in
WEB-INF/classes instead of WEB-INF/lib in the first place?
Any input or comments are appreciated. Thanks,
Randy
I think this is (or was) Maven's standard way of packaging a war file.
Im not opposed to changing it, but if you do, please make sure nothing else breaks (such as the hotdeploy goal)
Looking at RdbmsPolicy.getDefaultPolicy():
I private static String defaultPolicy = "sun.security.provider.PolicyFile";
then
Class policyClass = Class.forName(RdbmsPolicy.defaultPolicy); return (Policy) policyClass.newInstance();
Is that where the performance hit is?
Or is it in getPermissons(). This code also looks suspect to me, especially the policy.refresh():
// TODO Is there a better way to do this?
// If the permission is not found here then delegate it
// to the standard java Policy class instance.
Policy.setPolicy(RdbmsPolicy.getDefaultPolicy());
Policy policy = Policy.getPolicy();
policy.refresh();
PermissionCollection defaultPerms = policy.getPermissions(codeSource);
// Revert back to the current policy.
Policy.setPolicy(this);
// Return the default permission collection.
return defaultPerms;
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
