commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: [proxy] Commons-Lang Dependency...
Date Thu, 08 Sep 2005 15:13:25 GMT
Thank you for the advice, guys!  I copied the getAllInterfaces() method over
to my ProxyUtils class and documented that I "borrowed" it from Jakarta
Commons Lang.  Then, I removed my dependency on Jakarta Commons Logging,
because all I was doing was printing out informational messages for
debugging purposes.  The only absolute runtime dependency that commons-proxy
has now is the AOP Alliance API, I believe (there are numerous optional
runtime dependencies and the unit tests depend on some other stuff).  That
one I think I'm stuck with, though.  I might try to come up with a way to
provide a "bridge" or "adapter" to the AOP Alliance API and come up with my
own interface for method interceptors.  I don't know how necessary that is,
though.  The AOP Alliance API is somewhat well accepted.

-----Original Message-----
From: Henning P. Schmiedehausen [] 
Sent: Thursday, September 08, 2005 10:52 AM
Subject: Re: [proxy] Commons-Lang Dependency...

robert burrell donkin <> writes:

>> And, the commons-email release was shot down because of its
>> dependence upon commons-lang.  The dependence in email, though, was
>> in the public API.  

>i'm not sure that it was shot down (there may have been enough votes to
>win the day) as much as people were persuaded that the change should be
>made. stephen did the right thing in submitting a patch,

No it wasn't shot down for this. We could've simply ignored Stephen,
because there were enough +1 votes and releases can't be vetoed
anyway. However, Stephens arguments were sensible and he was decent
enough to actually do the work so that there was no real argument
against it.

If you want to take c-e as an example, then I'd advise to do as
Stephen did: Create a package private class called YourCommonsLibUtils
or something and put all code that you copy out of -lang or
-collections in there and clearly label from where you took it. Put
some documentation into the class which clearly states that this is a
package private class, not to be used by end users.

>> I do have a runtime dependency
>> upon Commons Logging at this time also.

What are you logging? Are you doing debugging or info log messages? Or
will you log errors and failures? If you do the latter, throw
exceptions and let your caller log them. If you have just a bunch of
log.debug() statements, best is to keep them commented out.

>it's pretty hard to win when it comes to logging. JCL was created
>because (in the end) libraries need to log and a single dependency on a
>small bridging API seems better than the alternatives. 

I agree here. If you really _have_ to do logging, then at least use
c-l to allow the component users choice on which log framework they
want to use in the end.

	Best regards

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH        +49 9131 50 654 0

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

		      4 - 8 - 15 - 16 - 23 - 42

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message