Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
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]
portal project deployment in WEB-INF/classes vs. WEB-INF/lib
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
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
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; -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773 4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
David, 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) Really? Wow. I have never used WEB-INF/classes for anything other than properties files. Ok, I'll look into it more carefully. 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; The issue is that RdbmsPolicy.getPermissions() gets called many times for a single checkPermission() invocation, (once per CodeSource/PermissionDomain). In the AbstractPageManager case, it is called 4-6 instead of perhaps 2-3 times per unique checkPermission() per user session. Each time, it invokes PermissionManager.getPermissions() which hits the DB, (or look like it does anyway). Worse case, we might consider caching in the principal impls to eliminate redundant lookup. Ideally, I'd like to get it down to just one access RdbmsPolicy.getPermissions(), but I do not know how to use the Subject.doAs*() methods to accomplish that yet. DLS? Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
Randy Watler wrote: David, 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) Really? Wow. I have never used WEB-INF/classes for anything other than properties files. Ok, I'll look into it more carefully. try this: mkdir someproject cd someproject maven genapp (use the default template) maven war With the default template, it seems to put your classes in the classes directory. The servlet spec clearly allows you to put classes there, its a matter of best practices and preferences. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773 4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
