[shrinkwrap-issues] [JBoss JIRA] Commented: (SHRINKWRAP-233) addClass with DefaultPackage opens addPackage to null arguments
[
https://issues.jboss.org/browse/SHRINKWRAP-233?page=com.atlassian.jira.pl...
]
Ivan Pazmino commented on SHRINKWRAP-233:
-----------------------------------------
Hello, I've been checking this issue and believe the problem starts in
Package.getPackage(String packageName) not making any difference between the default
package and a non existent package. So it's necessary to make this difference in the
base class-container implementation.
So, I set non existent package to null and default package to empty string. The external
method you mention I labeled it as addDefaultPackage, so a null package outside this
method is taken as a non existent package.
I've commited the changes to this branch
https://github.com/iapazmino/shrinkwrap/tree/SHRINKWRAP-233 so you may take a look. Any
changes you need just let me know.
addClass with DefaultPackage opens addPackage to null arguments
---------------------------------------------------------------
Key: SHRINKWRAP-233
URL: https://issues.jboss.org/browse/SHRINKWRAP-233
Project: ShrinkWrap
Issue Type: Bug
Reporter: Aslak Knutsen
When adding a Class in addClass, we do a addPackage with a Filter to match inner classes
of that class.
When adding a Class in Default package, the Package we padd to addPackage is null.
Meaning addPackage can't verify non null values.
The downside is, if someone happens to add, e.g.
addPakcage(true, Package.get("some-missing-package")), addPackage will be
called with null, and null means /, which means all found packages are added.
We need to split addPackage(boolean, Filter, Package...) into two methods, one external
which does the null checks from the user and one internal that does not check for null(to
support Class in default package).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira