commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <>
Subject Re: [proxy] Commons-Lang Dependency...
Date Fri, 09 Sep 2005 06:55:39 GMT
"James Carman" <> 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,, 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.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

>-----Original Message-----
>From: Stephen Colebourne [] 
>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
>> 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
>> own interface for method interceptors.  I don't know how necessary that
>> 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.


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

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

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:

View raw message