You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2005/09/08 13:58:57 UTC
[proxy] Commons-Lang Dependency...
What is our policy on inter-project dependencies? I just had to copy a
method from commons-lang, because I didn't want to introduce a runtime
dependency
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200509.mbox/%3
cdf9h71$c9j$2@tangens.hometree.net%3e). That seems, as Henning pointed out,
silly to me. And, the commons-email release was shot down because of its
dependence upon commons-lang. The dependence in email, though, was exposed
in the public API. In proxy, the dependence is upon the
ClassUtils.getAllInterfaces() method inside a couple of class'
implementations. Is this okay? Or, should I strive (as I already have
done) to keep the dependencies to a minimum? I do have a runtime dependency
upon Commons Logging at this time also.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [proxy] Commons-Lang Dependency...
Posted by James Carman <ja...@carmanconsulting.com>.
What good would a runtime exception do me at that point? The method
interceptor which contains that code is executing the method invocation in
another thread using an Executor (JDK5). So, the runtime exception wouldn't
get back to the caller. At best it would probably just get printed to
standard error or something. That's why I chose to actually log the error
in the first place.
-----Original Message-----
From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
Sent: Friday, September 09, 2005 2:49 AM
To: commons-dev@jakarta.apache.org
Subject: Re: [proxy] Commons-Lang Dependency...
Rahul Akolkar <ra...@gmail.com> writes:
><snap/>
>- getLog().error( "Method invocation threw an exception.", t );
>+ // What to do here? I can't convey the failure back to the caller.
><snip/>
throw new RuntimeException(t) if you aim for JDK 1.4+
throw new RuntimeException(t.getMessage()) if you need 1.3 compatibility.
should be possible everywhere.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Rahul Akolkar <ra...@gmail.com> writes:
><snap/>
>- getLog().error( "Method invocation threw an exception.", t );
>+ // What to do here? I can't convey the failure back to the caller.
><snip/>
throw new RuntimeException(t) if you aim for JDK 1.4+
throw new RuntimeException(t.getMessage()) if you need 1.3 compatibility.
should be possible everywhere.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [proxy] Commons-Lang Dependency...
Posted by James Carman <ja...@carmanconsulting.com>.
That particular class (ExecutorMethodInterceptor) could depend upon JCL,
since it really does need to be able to indicate that failure (a void method
executed in another thread threw an exception) somehow. I don't mind
including classes in proxy that would require a runtime dependency, but the
core API shouldn't cause too many. So, I really could re-introduce that
code back into ExecutorMethodInterceptor and I very well may do that.
Again, I'm glad proxy is still in the sandbox! :-)
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Thursday, September 08, 2005 8:53 PM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Commons-Lang Dependency...
On 9/8/05, James Carman <ja...@carmanconsulting.com> wrote:
> 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.
<snip/>
I'm sure you gave enough thought before removing the JCL bits, but my
2c -- the larger the black boxes of magic, the more chances are that
users will be bitten by the absence of logging. If proxy is broad and
shallow (Stephen's term from another thread), you can probably get
away with it.
Just saw this in r279571:
<snap/>
- getLog().error( "Method invocation threw an exception.", t );
+ // What to do here? I can't convey the failure back to the caller.
<snip/>
which prompted me to participate here. For completion, I have no
understanding (yet) of that piece of code, but this remark is meant to
transcend that ;-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by Rahul Akolkar <ra...@gmail.com>.
On 9/8/05, James Carman <ja...@carmanconsulting.com> wrote:
> 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.
<snip/>
I'm sure you gave enough thought before removing the JCL bits, but my
2c -- the larger the black boxes of magic, the more chances are that
users will be bitten by the absence of logging. If proxy is broad and
shallow (Stephen's term from another thread), you can probably get
away with it.
Just saw this in r279571:
<snap/>
- getLog().error( "Method invocation threw an exception.", t );
+ // What to do here? I can't convey the failure back to the caller.
<snip/>
which prompted me to participate here. For completion, I have no
understanding (yet) of that piece of code, but this remark is meant to
transcend that ;-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Andrei Polushin <a-...@yandex.ru> writes:
>Henning P. Schmiedehausen writes:
>> One of the quirks in the Java language is, that the package names
>> (foo, foo.bar, foo.bar.baz) imply a hierarchy which in fact does not
>> exist. There is no "visible in package and sub-packages" modifier. So
>> if you want to use an utility class in foo, foo.bar, foo.baz, you have
>> to make it public (Sun, are you listening? Here is a chance for
>> another cool new scope that C# probably doesn't have yet. ;-) )
Thanks for the pointer. I wasn't aware of that. However, my C#
experience doesn't stretch much beyond "hello, world". :-)
>It's off-topic, but C# does provide the desired meaning with its
>'internal' access modifier keyword, and there is no 'package private'
>classes there, see
>http://msdn.microsoft.com/library/en-us/csref/html/vclrfInternalPG.asp
That shows that C# derives from C. :-) This is the same thing as a
global "static" in a C program. The symbol is not visible through the
linker/whatever it is called for Assemblies these days.
>The possible Java pattern is to provide 'private' package(s), and
>prohibit their usage, like Sun did with sun.* packages:
>http://java.sun.com/products/jdk/faq/faq-sun-packages.html
But that is a usage pattern, not a compiler enforced restriction. That
is what we do all the time by putting "don't use this class in your
programs" comments in the classes.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[OT] sub-package private (was: [proxy] Commons-Lang Dependency...)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> The possible Java pattern is to provide 'private' package(s), and
> prohibit their usage, like Sun did with sun.* packages:
> http://java.sun.com/products/jdk/faq/faq-sun-packages.html
This is a contract, not less, not more. You cant ensure that these
packages are really private, so you can use them, its just on your own risk.
What would be nice is to have a real modifier keyword, e.g:
package org.apache.any;
private package class ABC
{
}
Like private this enforces to be really private for the package, but can
be used in sub-package too.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by Andrei Polushin <a-...@yandex.ru>.
Henning P. Schmiedehausen writes:
> One of the quirks in the Java language is, that the package names
> (foo, foo.bar, foo.bar.baz) imply a hierarchy which in fact does not
> exist. There is no "visible in package and sub-packages" modifier. So
> if you want to use an utility class in foo, foo.bar, foo.baz, you have
> to make it public (Sun, are you listening? Here is a chance for
> another cool new scope that C# probably doesn't have yet. ;-) )
It's off-topic, but C# does provide the desired meaning with its
'internal' access modifier keyword, and there is no 'package private'
classes there, see
http://msdn.microsoft.com/library/en-us/csref/html/vclrfInternalPG.asp
The possible Java pattern is to provide 'private' package(s), and
prohibit their usage, like Sun did with sun.* packages:
http://java.sun.com/products/jdk/faq/faq-sun-packages.html
--Andrei Polushin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by Mario Ivankovits <ma...@ops.co.at>.
>One of the quirks in the Java language is, that the package names
>(foo, foo.bar, foo.bar.baz) imply a hierarchy which in fact does not
>exist. There is no "visible in package and sub-packages" modifier. So
>if you want to use an utility class in foo, foo.bar, foo.baz, you have
>to make it public (Sun, are you listening? Here is a chance for
>another cool new scope that C# probably doesn't have yet. ;-) )
>
+10^9999999999
Sometimes it is possible to do some tricks with abstract classes, but
having such a scope would be really nice. I wished it myself already
many times.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"James Carman" <ja...@carmanconsulting.com> writes:
BTW: proxy is 1.5+ only? At least the ProxyUtils are.
>"Make sure your class is package scoped"
>Well, it's public, and so is the getAllInterfaces() method, but it doesn't
>have the same signature as the one from commons-lang (it returns a Class[]
>as opposed to a List). I have a private implementation method that I call
>in my array-based version that I copied from commons-lang.
One of the quirks in the Java language is, that the package names
(foo, foo.bar, foo.bar.baz) imply a hierarchy which in fact does not
exist. There is no "visible in package and sub-packages" modifier. So
if you want to use an utility class in foo, foo.bar, foo.baz, you have
to make it public (Sun, are you listening? Here is a chance for
another cool new scope that C# probably doesn't have yet. ;-) )
Best regards
Henning
>-----Original Message-----
>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>Sent: Thursday, September 08, 2005 6:11 PM
>To: Jakarta Commons Developers List
>Subject: Re: [proxy] Commons-Lang Dependency...
>James Carman wrote:
>> 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.
>By approaching it this way, you will find that you can monitor your
>usage of these routines, and can thus add a dependency later if it seems
>justified. Make sure your class is package scoped.
> > The only absolute runtime dependency that commons-proxy
>> has now is the AOP Alliance API, ....... 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.
>This is similar to [email] depending on JavaMail API. It is (probably)
>the reason why your component exists, so it is only reasonable to have
>the dependency.
>Stephen
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [proxy] Commons-Lang Dependency...
Posted by James Carman <ja...@carmanconsulting.com>.
"Make sure your class is package scoped"
Well, it's public, and so is the getAllInterfaces() method, but it doesn't
have the same signature as the one from commons-lang (it returns a Class[]
as opposed to a List). I have a private implementation method that I call
in my array-based version that I copied from commons-lang.
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Thursday, September 08, 2005 6:11 PM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Commons-Lang Dependency...
James Carman wrote:
> 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.
By approaching it this way, you will find that you can monitor your
usage of these routines, and can thus add a dependency later if it seems
justified. Make sure your class is package scoped.
> The only absolute runtime dependency that commons-proxy
> has now is the AOP Alliance API, ....... 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.
This is similar to [email] depending on JavaMail API. It is (probably)
the reason why your component exists, so it is only reasonable to have
the dependency.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by Stephen Colebourne <sc...@btopenworld.com>.
James Carman wrote:
> 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.
By approaching it this way, you will find that you can monitor your
usage of these routines, and can thus add a dependency later if it seems
justified. Make sure your class is package scoped.
> The only absolute runtime dependency that commons-proxy
> has now is the AOP Alliance API, ....... 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.
This is similar to [email] depending on JavaMail API. It is (probably)
the reason why your component exists, so it is only reasonable to have
the dependency.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [proxy] Commons-Lang Dependency...
Posted by James Carman <ja...@carmanconsulting.com>.
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 [mailto:hps@intermeta.de]
Sent: Thursday, September 08, 2005 10:52 AM
To: commons-dev@jakarta.apache.org
Subject: Re: [proxy] Commons-Lang Dependency...
robert burrell donkin <ro...@blueyonder.co.uk> writes:
>> And, the commons-email release was shot down because of its
>> dependence upon commons-lang. The dependence in email, though, was
exposed
>> 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
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [proxy] Commons-Lang Dependency...
Posted by James Carman <ja...@carmanconsulting.com>.
I guess I didn't really mean "shot down." I meant something more along the
lines of "poo pooed." :-)
-----Original Message-----
From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
Sent: Thursday, September 08, 2005 10:52 AM
To: commons-dev@jakarta.apache.org
Subject: Re: [proxy] Commons-Lang Dependency...
robert burrell donkin <ro...@blueyonder.co.uk> writes:
>> And, the commons-email release was shot down because of its
>> dependence upon commons-lang. The dependence in email, though, was
exposed
>> 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
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
robert burrell donkin <ro...@blueyonder.co.uk> writes:
>> And, the commons-email release was shot down because of its
>> dependence upon commons-lang. The dependence in email, though, was exposed
>> 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
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proxy] Commons-Lang Dependency...
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2005-09-08 at 07:58 -0400, James Carman wrote:
> What is our policy on inter-project dependencies?
i'm not sure that we have anything as grand as a policy: just a lot of
experience of creating long lived micro libraries. a lot of bitter
lessons have been learnt over the years.
> I just had to copy a
> method from commons-lang, because I didn't want to introduce a runtime
> dependency
> (http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200509.mbox/%3
> cdf9h71$c9j$2@tangens.hometree.net%3e). That seems, as Henning pointed out,
> silly to me.
copying a single method may seem silly now but it feels a lot worse when
(three years down the line) seemingly the whole java blogosphere is
shouting about how stupid you are because (for the sake of a single
method) you added a dependency (three years ago) and now a
thousand-and-one applications are now experiencing dependency hell...
IMHO it would be much better to have good way of doing this (maybe some
variation on jarjar) but at the moment, we're stuck with copying code.
> And, the commons-email release was shot down because of its
> dependence upon commons-lang. The dependence in email, though, was exposed
> 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,
> In proxy, the dependence is upon the
> ClassUtils.getAllInterfaces() method inside a couple of class'
> implementations. Is this okay? Or, should I strive (as I already have
> done) to keep the dependencies to a minimum?
when creating bricks, it's always best to keep the dependency graph as
small as possible. i prefer optional jars for non-core dependencies but
this is debated (some don't see the point of half a dozen 1k jars).
> I do have a runtime dependency
> upon Commons Logging at this time also.
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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org