@dswitzer i’m not sure if i understand your point a 100%. But let me explain what exactly happening here.
The nature of OSGi is NOT to see everything, every OSGi bundle (the Lucee core is a OSGi bundle), defines the relation to other jars.
The Lucee core for example can only see what it defines in "import-package
and in require-bundle
This separation is essential for OSGi, let say “Bundle A” has this “require-bundle”
Require-Bundle: susi-sorglos;bundle-version=1.0.0,
and “Bundle B” has this “require-bundle”
Require-Bundle: susi-sorglos;bundle-version=2.0.0,
OSGi still allows me to use this bundle alongside no problem, even one uses the same bundle in a different version. This works because “B” does not see “A” and “A” does not see “B”.
So this is not a bug, this is what make OSGi work in the first place. Every bundles operates independent of each other.
So when you do this getPageContext().getClass().getClassLoader() you get the classloader from the Lucee core, that CL does not see “org.bouncycastle.mail.smime.util”, because that package is loaded only in the PDF and S3 Extension. So to get this class you need to start with a class from one of this extensions.
like
createObject("java","org.lucee.extension.pdf.function.IsPDFFile").init().loadClass("org.bouncycastle.mail.smime.util.CRLFOutputStream");
So in short, in an OSGI environment a BundleClassloader only does see the classes loaded in his context, it does NOT see classes loaded by other BundleClassloader.
CreateObject is a different story because it does not relay on a single classloader, it looks for a class in all bundleclassloader and more.
There is one classloader in Lucee that sees all classes, the EnvClassloader, this classloader is used for classic jars we convert to OSGi that use internally a simple classloader and expect it to work.
You can get that classloader as following:
getPageContext().getConfig().getClassLoaderEnv();