You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Costin Manolache <cm...@yahoo.com> on 2002/12/06 16:45:52 UTC
Re: [digester] collections and default for useThreadClassLoader
In addition to the threadClassLoader: is there any reason for
digester to depend on collections ? I see that it is using FastHashmap
and ArrayStack, but given that it is _parsing_ a file and does a lot
of super-expensive operations, the performance gains from this use are
not significant.
The reason I'm looking into this - I have a lot of problems with tomcat
in JMX mode, some jars need to get into the parent loader and that
brakes a lot of stuff. Modeler depends on digester so I need it in
the top loader - but this drags the whole jakarta-commons.
Same for beanutils ( which is used quite extensively in digester,
and may be needed in modeler as well ).
Costin
> Is there any reason for having 'false' for useThreadClassLoader ?
>
> I have a number of failures with tomcat if digester is in the
> parent loader, since a lot of code doesn't set this. And
> IMO the correct behavior for any utility designed to work in
> a server side environment is to check the thread class loader first.
>
> Comments ? Can I change it ?
>
> Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] statics
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 05:11 PM, Craig R. McClanahan wrote:
>
>
> On Sat, 7 Dec 2002, robert burrell donkin wrote:
>
>> Date: Sat, 7 Dec 2002 09:10:47 +0000
>> From: robert burrell donkin <ro...@blueyonder.co.uk>
>> Reply-To: Jakarta Commons Developers List <commons-
>> dev@jakarta.apache.org>
>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>> Subject: [beanutils] statics [WAS Re: [digester] collections and default
>> for useThreadClassLoader]
>>
>> On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote:
>>
>> <snip>
>>
>>> There is also the issue of statics ( which become very visible when
>>> you move stuff to the top loader), and the issue of security - which is
>>> particularily important for beanutil and probably in collections
>>> ( i.e. - if things are cached - can an application access other
>>> application's data ? Is there any thread that may change the
>>> security context ? )
>>
>> (now is probably a good time to raise something that's been in the air
>> for
>> a little while.)
>>
>> at the moment, beanutils is composed of static methods. the caching is
>> also static.
>>
>> one effect of this is that there is only one global set of converters.
>> another is that the cached data has to be shared globally.
>>
>> it might make more sense to have concrete objects. caches and other data
>> would be stored with each instance. the current static methods would then
>> call a static instance.
>>
>> users would then be free to continue to use the convenient static methods
>> or they could create an instance and use that instead.
>>
>
> +1 on exploring this, with appropriate factory methods and such. It might
> also be interesting to support a mode that maintains a "static"-ish cache
> per context class loader via the existing call signatures, because that's
> a very useful scenario in things like a servlet container.
that sounds good.
the classes in beanutils depend on each other. ao we'll need to make sure
that the instances are linked consistently together. probably the
delegated instances should be exposed as read-only properties.
a single per context class loader cache for the whole of beanutils (rather
than per class) seems like a good idea. that way, we can easily make sure
that a consistent set of all beanutils objects will be created every time.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] statics [WAS Re: [digester] collections and default
for useThreadClassLoader]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 7 Dec 2002, robert burrell donkin wrote:
> Date: Sat, 7 Dec 2002 09:10:47 +0000
> From: robert burrell donkin <ro...@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [beanutils] statics [WAS Re: [digester] collections and default
> for useThreadClassLoader]
>
> On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote:
>
> <snip>
>
> > There is also the issue of statics ( which become very visible when
> > you move stuff to the top loader), and the issue of security - which is
> > particularily important for beanutil and probably in collections
> > ( i.e. - if things are cached - can an application access other
> > application's data ? Is there any thread that may change the
> > security context ? )
>
> (now is probably a good time to raise something that's been in the air for
> a little while.)
>
> at the moment, beanutils is composed of static methods. the caching is
> also static.
>
> one effect of this is that there is only one global set of converters.
> another is that the cached data has to be shared globally.
>
> it might make more sense to have concrete objects. caches and other data
> would be stored with each instance. the current static methods would then
> call a static instance.
>
> users would then be free to continue to use the convenient static methods
> or they could create an instance and use that instead.
>
+1 on exploring this, with appropriate factory methods and such. It might
also be interesting to support a mode that maintains a "static"-ish cache
per context class loader via the existing call signatures, because that's
a very useful scenario in things like a servlet container.
> - robert
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[beanutils] statics [WAS Re: [digester] collections and default for useThreadClassLoader]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote:
<snip>
> There is also the issue of statics ( which become very visible when
> you move stuff to the top loader), and the issue of security - which is
> particularily important for beanutil and probably in collections
> ( i.e. - if things are cached - can an application access other
> application's data ? Is there any thread that may change the
> security context ? )
(now is probably a good time to raise something that's been in the air for
a little while.)
at the moment, beanutils is composed of static methods. the caching is
also static.
one effect of this is that there is only one global set of converters.
another is that the cached data has to be shared globally.
it might make more sense to have concrete objects. caches and other data
would be stored with each instance. the current static methods would then
call a static instance.
users would then be free to continue to use the convenient static methods
or they could create an instance and use that instead.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [digester] collections and default for useThreadClassLoader
Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:
>> In addition to the threadClassLoader:
>
> +1 on changing this default, by the way ... forgot to say that yesterday.
Thanks. That was the major issue.
>> Same for beanutils ( which is used quite extensively in digester,
>> and may be needed in modeler as well ).
>>
>
> In [beanutils] it looks like the only use of [collections] is for
> FastHashMap, which is used to cache things that can still be read with no
> synchronization locks. I suspect the performance impacts here would be
> more substantial and relevant than the [digester] direct dependencies; it
> probably needs more performance analysis before a decision.
What worries me more is the dependency on the Comparator in a public API.
That would make it impossible to remove beanutils->collection without
one backward incompatibility ( at least at source level - at runtime
it won't have any effect ).
Regarding FastHashMap - most my tests on JDK1.4 show absolutely no
difference. The cost for a lock that is allways unlocked is extremely
small. On the other side - if beanutils is in the top loader and
gets accessed concurently by many apps - we may find some strange
errors if some of the locks are actually needed.
I can add some code to check if FastHashMap is available and fallback.
I need to look a bit more at the code in beanutils.
There is also the issue of statics ( which become very visible when
you move stuff to the top loader), and the issue of security - which is
particularily important for beanutil and probably in collections
( i.e. - if things are cached - can an application access other
application's data ? Is there any thread that may change the
security context ? )
And of course - Class.forName and things like that would create
yet another set of problems ( is all the code using the
thread loader ? ). Pluse the difficulties to override some classes,
possible linkage errors on reverse loaders, etc.
( well, I know you know all this :-)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [digester] collections and default for useThreadClassLoader
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Date: Fri, 06 Dec 2002 07:45:52 -0800
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: Re: [digester] collections and default for useThreadClassLoader
>
> In addition to the threadClassLoader:
+1 on changing this default, by the way ... forgot to say that yesterday.
> is there any reason for
> digester to depend on collections ? I see that it is using FastHashmap
> and ArrayStack, but given that it is _parsing_ a file and does a lot
> of super-expensive operations, the performance gains from this use are
> not significant.
>
I'd be OK with removing this dependency, especially if it could be shown
that the performance difference is insignificant (on which you're probably
right).
> The reason I'm looking into this - I have a lot of problems with tomcat
> in JMX mode, some jars need to get into the parent loader and that
> brakes a lot of stuff. Modeler depends on digester so I need it in
> the top loader - but this drags the whole jakarta-commons.
>
> Same for beanutils ( which is used quite extensively in digester,
> and may be needed in modeler as well ).
>
In [beanutils] it looks like the only use of [collections] is for
FastHashMap, which is used to cache things that can still be read with no
synchronization locks. I suspect the performance impacts here would be
more substantial and relevant than the [digester] direct dependencies; it
probably needs more performance analysis before a decision.
> Costin
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>