"Package in not valid" Exception for non-existing package when calling PojoClassFactory.getPojoClassesRecursively

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have a package name that as prefix has a package name that appears earlier 
in the package full name
Example: com.xxx.yyy.zzz and com.xxx.yyy.zzz.zzzconfig both exists.
2. Call PojoClassFactory.getPojoClassesRecursively(packageName, null);
Example: Above call with packageName set to com.xxx.yyy

What is the expected output? What do you see instead?
Expect to get a list of classes. Instead I get an expection
com.openpojo.reflection.exception.ReflectionException: Package 
[xxx.yyy.zzz.onfig] is not valid

What version of the product are you using? On what operating system?
Version: 0.4.2
OS: Windows Vista Enterprise (32 bits) SP 2

Please provide any additional information below.

The problem has been located to 
com.openpojo.reflection.java.packageloader.impl.JARPackageLoader
In the method getDirectSubPackageName is the following check:
        if (subPackageName.startsWith(packageName) && !packageName.equals(subPackageName))
This check means that incorrect matching of subpackages occur due to prefix of 
name matching. The if-clause need improvement.

Have run the same code on a Jenkins node, running Windows 7, and the problem 
does not occur?!?

Here is part of the innermost part of the stack trace when this situation occur:
Caused by: com.openpojo.reflection.exception.ReflectionException: Package 
[com.ericsson.tt.uecontrol.uehandler.onfig] is not valid
   com.openpojo.reflection.exception.ReflectionException.getInstance(ReflectionException.java:38)
        com.openpojo.reflection.impl.PojoPackageImpl.<init>(PojoPackageImpl.java:57)
        com.openpojo.reflection.impl.PojoPackageImpl.getPojoSubPackages(PojoPackageImpl.java:95)
        com.openpojo.reflection.service.impl.DefaultPojoClassLookupService.getPojoClassesRecursively(DefaultPojoClassLookupService.java:86)
        com.openpojo.reflection.impl.PojoClassFactory.getPojoClassesRecursively(PojoClassFactory.java:81)

Original issue reported on code.google.com by LHCper on 15 Jan 2013 at 8:55

[GoogleCodeExporter]

Made the follwing simple change to the if-clause and after that the problem 
disappeared.
        if (subPackageName.startsWith(packageName + ".") && !packageName.equals(subPackageName))

I will try to make a patch for this and add this to the project later this week.

Original comment by LHCper on 15 Jan 2013 at 9:48

[GoogleCodeExporter]

This is a very interesting issue, and appears to be something related to the 
underlying jvm.

I saw something similar a while back that I was unable to reproduce reliably 
when package names started with capital letters and I was wondering if "onfig" 
is a package sub from com.ericsson.tt.uecontrol.uehandler or was it defined as 
"Config"?

Original comment by oshou...@gmail.com on 18 Jan 2013 at 5:30

[GoogleCodeExporter]

also can you let me know what version of the JVM are you using when it fails, 
and which version of the JVM does Jenkins use?

Original comment by oshou...@gmail.com on 18 Jan 2013 at 5:31

[GoogleCodeExporter]

My observation about Jenkins was incorrect - it was not run at all.

The package name that caused the problem was probably 
com.ericsson.tt.uecontrol.uehandlerconfig
There is a package called com.ericsson.tt.uecontrol.uehandler which is the one 
subpackages are looked for. So it seems it thinks that 
com.ericsson.tt.uecontrol.uehandlerconfig is a subpackage to 
com.ericsson.tt.uecontrol.uehandler as it starts with this. It does skip next 
character and use the rest ("onfig") as a package name...

The JDK version used to build and execute this (under Vista) is
jdk1.7.0_09.  Have not tried other versions.  (And we use Java 7 functionality 
so I have not tried older versions.) 

I think that this is not connected to which version you use, but an effect of 
the names used for the packages. (i.e. bad luck)  
Comment #1 shows a suggested change that will fix the problem. 
We have patched our 0.4.2 version of POJO which we have uploaded in our local 
Nexus. It seems to work fine.

Original comment by LHCper on 22 Jan 2013 at 11:53

[GoogleCodeExporter]

Awesome find, thank you for logging the issue, next release will incorporate 
the fix for this.

Original comment by oshou...@gmail.com on 25 Jan 2013 at 9:19

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by oshou...@gmail.com on 25 Jan 2013 at 9:19

[GoogleCodeExporter]

Fixed and will be part of release 0.4.3.

Original comment by oshou...@gmail.com on 11 Feb 2013 at 3:25

• Changed state: Verified