frjaeger220 / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
0 stars 0 forks source link

inSubpackage Matcher #75

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I can't figure out how to make these issues not show up as defects...  This is 
meant to be an 
enhancement.

It might be convenient to add an inSubpackage matcher to go along with the 
inPackage matcher in 
the Matchers class.  I think it would be pretty common to want to match all 
classes in a package and 
all of its subpackages without having to specify each one individually.  My use 
case was that I 
wanted to apply a MethodInterceptor to all of the classes in my project.

I've attached my implementation along with two TestNG test cases.  It does the 
matching using 
getName() and startsWith().  The whole thing's pretty simple, but it seems like 
it could be useful for 
a lot of people.  Take it or leave it.  :-)

Original issue reported on code.google.com by gk5...@gmail.com on 18 Mar 2007 at 9:21

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks. We'll get this into 1.1.

Original comment by crazybob...@gmail.com on 19 Mar 2007 at 2:23

GoogleCodeExporter commented 9 years ago

Original comment by kevin...@gmail.com on 19 Mar 2007 at 7:33

GoogleCodeExporter commented 9 years ago

Original comment by kevin...@gmail.com on 19 Mar 2007 at 7:33

GoogleCodeExporter commented 9 years ago

Original comment by limpbizkit on 30 May 2008 at 6:55

GoogleCodeExporter commented 9 years ago
Mike Ward wrote a patch that we've submitted. The fix was a bit more 
complicated in order to make sure that
   inSubpackage("com.go") 
doesn't match classes in com.google.inject, for example.

He also did due diligence on the package/classloader issues that come up for 
the java.lang.reflect.Package class. 
In particular, he made our inPackage matcher not respect classloaders, unlike 
our inPackage matcher.

Original comment by limpbizkit on 19 Jun 2008 at 11:28