Rainer Jung wrote:
> I added a comment concerning a little experiment I did to
>
> https://issues.apache.org/jira/browse/VELTOOLS-66
>
> Regards,
>
> Rainer
Thanks for this. I was planning to do this tonight but you saved me
the effort. On this basis, I am going to close the Tomcat bug as
inval
On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Yoav Shapira wrote:
> On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>> > Because these are internal implementations, if the user is whack
>> > enough to try and access the real object behind the facade, I'd say
>> > they're at their
I added a comment concerning a little experiment I did to
https://issues.apache.org/jira/browse/VELTOOLS-66
Regards,
Rainer
Darryl Miles schrieb:
> Remy Maucherat wrote:
>> I disagree: if the security manager is there, then there should be no
>> way to get the internal object.
>
> Yes. Maybe
Remy Maucherat wrote:
I disagree: if the security manager is there, then there should be no
way to get the internal object.
Yes. Maybe the framework is broken for not trying to reflect on the
available interfaces for the subject instance. Maybe by default it
should only fail terminally if i
Yoav Shapira wrote:
Hi,
On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Because these are internal implementations, if the user is whack
> enough to try and access the real object behind the facade, I'd say
> they're at their own risk.
I disagree: if the security manager is there, the
Hi,
On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Because these are internal implementations, if the user is whack
> enough to try and access the real object behind the facade, I'd say
> they're at their own risk.
I disagree: if the security manager is there, then there should be no
Yoav Shapira wrote:
Hi,
On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Mark Thomas wrote:
> Thoughts? Comments? Objections?
On second thought, I'm not sure it's a good idea to do it without some
verifications. For example, if reflection is allowed on the facades,
then it will probably
Hi,
On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Mark Thomas wrote:
> Thoughts? Comments? Objections?
On second thought, I'm not sure it's a good idea to do it without some
verifications. For example, if reflection is allowed on the facades,
then it will probably allow getting the ref
While we're discuss about change in TC 5.5, what about using the TC 6
JMX modeler in TC 5.5 ?
the JMX modeler used in Tomcat (4.1/5/5.5) use too many memory when
the Tomcat is hosting many webapps each of with many Servlets/JSPs.
We switch from TC 3.3 to 5.5 and see a memory consumption multipli
Mark Thomas wrote:
Thoughts? Comments? Objections?
On second thought, I'm not sure it's a good idea to do it without some
verifications. For example, if reflection is allowed on the facades,
then it will probably allow getting the reference to the real object,
which should not be allowed.
Mark Thomas wrote:
This move will allow the permissions in catalina.policy to be set to
allow reflection on this package. The impact on spec compliant web
applications should be zero. Web applications that depend on Tomcat
internals may have issues.
My intention would be to make this change in 5
All,
The root cause of bug 40770[1] is that the default catalina.policy
file does not permit reflection on the Tomcat facade classes which are
exposed to applications as HttpServletRequest, HttpSession etc.
The necessary permissions to enable reflection can only be granted per
package. Granting t
12 matches
Mail list logo
