You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Randy Watler <rw...@finali.com> on 2004/11/12 18:58:51 UTC
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
Download a dynamic file from a portlet
Posted by Xiaobo Yang <xy...@hotmail.com>.
I have a question which is how to download a dynamic file from a portlet. In
the portlet, the dynamic file is retrieved and stored in a stream. Now I
hope to let the client download the dynamic file. How can I do it since I
can not get output stream within the portlet?
Also I wonder how to invoke a servlet from a portlet. I am working on
Jetspeed 1.3/4. Thanks.
X. Yang
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
david@bluesunrise.com
[office] +01 707 773 4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
Posted by Randy Watler <rw...@finali.com>.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
Posted by Serge Huber <sh...@jahia.com>.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
david@bluesunrise.com
[office] +01 707 773 4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org