You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/03/17 03:52:46 UTC
[excalibur] deprecation and using Commons interfaces
Hi,
I've been trying to get my hands around the Excalibur stuff today because
well the thread manager I use depends on it. I really want to stop using
deprecated ThreadPool interfaces and the like.
Could we take a vote to work with the commons folks who already have a
thread pool package out there. I'm tired of having copies of commons stuff.
Granted some of it my have become redundant over time as API's matured.
For an example of what I'm talking about take a look at the ValuedEnum class
in both framework and ValuedEnum in the commons-lang project. The same
situation exists for many classes, CascadingExceptions Vs. NestedExceptions
to utilities like ExceptionUtil Vs. ExceptionUtils and the list goes on.
If no one has any objections I would like to start replacing these classes
with the commons equivalents for A5. There is no reason for us to duplicate
these classes when the commons does a nice job at it. I'm sure they would
work with us to migrate some of our functionality which really should be
commons code.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [excalibur] deprecation and using Commons interfaces
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
>
> Hi,
>
> I've been trying to get my hands around the Excalibur stuff
> today because well the thread manager I use depends on it. I
> really want to stop using deprecated ThreadPool interfaces
> and the like.
>
> Could we take a vote to work with the commons folks who
> already have a
> thread pool package out there. I'm tired of having copies of
> commons stuff.
>
> Granted some of it my have become redundant over time as
> API's matured.
> For an example of what I'm talking about take a look at the
> ValuedEnum class in both framework and ValuedEnum in the
> commons-lang project. The same
> situation exists for many classes, CascadingExceptions Vs.
> NestedExceptions
> to utilities like ExceptionUtil Vs. ExceptionUtils and the
> list goes on.
>
> If no one has any objections I would like to start replacing
> these classes with the commons equivalents for A5. There is
> no reason for us to duplicate these classes when the commons
> does a nice job at it. I'm sure they would work with us to
> migrate some of our functionality which really should be commons code.
Alex,
good idea - duplication isn't a good thing. But consider other
sources, since this is for A5 (which is a bit off still):
- CascadingException -> Java 1.4 Exceptions are cascading without
the need for any utility class:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Exception.html
- ThreadPool -> util.concurrent has a ThreadPoolExecutor that later
became the ThreadPool in java.util.concurrent in Java 1.5:
http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/Th
readPoolExecutor.html
Requiring JDK1.5 may be too much, but using the util.concurrent
version
would make for easier migration to 1.5 later.
Just a thought - if we're going to break back-compat, we might as well
clean up everythng we can.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [excalibur] deprecation and using Commons interfaces
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 17 March 2004 12:06, Noel J. Bergman wrote:
> I am all for using Commons code, and contributing to it where we have
> something better, but there is an issue that needs to be resolved. The
> issue, which I've encountered with DBCP, is that much Commons code is
> logging clueless. So we not only need to add an IoC adapter between the
> Avalon container and Commons component, but we need some way of integrating
> the component into a logging framework.
I agree with Alex, that Monitors are probably the best way for Commons, and
then Logger wrappers for 'conventional people'.
And I see no reason why such adapter is not in the commons project, as long as
we write and maintain them.
> I still think that working with Commons is the right way to go.
+1.
IMHO, someone from here should have (do have?) commit rights at Commons and
maintain that adaption.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [excalibur] deprecation and using Commons interfaces
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > we not only need to add an IoC adapter between the Avalon container
> > and Commons component, but we need some way of integrating the
> > component into a logging framework.
> Yep I realized this too. However the best approach is to use the Monitor
> concept for these components. I think James Strachan already did so with
> his ThreadPool implementation.
There are places in Commons classes where they use System.out.println rather
than a logger. In other cases, they have a PrintWriter, but that's it. No
concept of log level, for example. You don't know the context in which the
messages are being written, deep in the core of some Commons class. So the
addition of logging or monitoring still means making a change.
I'm not saying we shouldn't do it. I'm setting an expectation of something
that will need to be addressed in order to do it properly.
As for James' ThreadPool, (a) it is in sandbox; (b) it is in sandbox because
Doug Lea's util.concurrent is mature, useful and the basis for JSR 166; (c)
James' monitor is just an exception handler. It isn't really suitable in
the current form for other monitoring.
--- Noel
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [excalibur] deprecation and using Commons interfaces
Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel,
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> I am all for using Commons code, and contributing to it where we have
> something better, but there is an issue that needs to be resolved. The
> issue, which I've encountered with DBCP, is that much Commons code is
> logging clueless. So we not only need to add an IoC adapter between the
> Avalon container and Commons component, but we need some way of
> integrating
> the component into a logging framework.
Yep I realized this too. However the best approach is to use the Monitor
concept for these components. I think James Strachan already did so with
his ThreadPool implementation. The idea has been working well for me and
I got it from Paul Hammant and Leo Sutic (to give them credit).
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [excalibur] deprecation and using Commons interfaces
Posted by "Noel J. Bergman" <no...@devtech.com>.
> If no one has any objections I would like to start replacing these classes
> with the commons equivalents for A5. There is no reason for us to
duplicate
> these classes when the commons does a nice job at it. I'm sure they would
> work with us to migrate some of our functionality which really should be
> commons code.
I am all for using Commons code, and contributing to it where we have
something better, but there is an issue that needs to be resolved. The
issue, which I've encountered with DBCP, is that much Commons code is
logging clueless. So we not only need to add an IoC adapter between the
Avalon container and Commons component, but we need some way of integrating
the component into a logging framework.
I still think that working with Commons is the right way to go. If Commons
made consistent use of Commons Logging, we could probably tie in that way.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org