[shrinkwrap-issues] [JBoss JIRA] Commented: (SHRINKWRAP-244) When calling JavaArchiveImpl.addClass(String, ClassLoader) the TCCL gets used instead
[
https://issues.jboss.org/browse/SHRINKWRAP-244?page=com.atlassian.jira.pl...
]
Davide D'Alto commented on SHRINKWRAP-244:
------------------------------------------
Hi David,
following your suggestion I've added this test:
https://github.com/DavideD/shrinkwrap/blob/SHRINKWRAP-244/impl-base/src/t...
I've created a JAR that contains a class with an inner class and I check that in the
generated archive the inner class is present.
Is it correct?
The problem that I have now is that the class is included in the archive without the inner
class.
It seems that the URLPackageScanner cannot see the inner class in my custom ClassLoader
(even if I load the class in the classloader before adding the class to the archive).
This is where the URLPackageScanner is called to include the inner classes in the
archive:
https://github.com/DavideD/shrinkwrap/blob/SHRINKWRAP-244/impl-base/src/m...
Thanks,
Davide
When calling JavaArchiveImpl.addClass(String, ClassLoader) the TCCL
gets used instead
-------------------------------------------------------------------------------------
Key: SHRINKWRAP-244
URL: https://issues.jboss.org/browse/SHRINKWRAP-244
Project: ShrinkWrap
Issue Type: Bug
Components: impl-base
Affects Versions: 1.0.0-alpha-12
Reporter: David Bosschaert
When I call JavaArchiveImpl.addClass(String fqcn, ClassLoader cl) the cl gets used to
load fqcn, but then further down the line, I find myself in ContainerBase.addPackages(),
which is called indirectly from the previous addClass method. The addPackages still uses
the TCCL while it should really use the cl passed in to the addClass method.
This also applies to JavaArchiveImpl.addClass(Class cls) where the classloader to be used
could be inferred from the cls argument, but instead the TCCL gets used...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira