This content has been marked as final.
Show 3 replies
-
1. Re: Should BundleStructureDeployer add embedded archives ?
alesj Oct 8, 2009 5:17 AM (in response to thomas.diesler)"thomas.diesler@jboss.com" wrote:
Should the structure deployer also be Bundle-ClassPath aware or should it perhaps not handle embedded jars at all?
Yes, it should be the structure deployer to handle this, not policy creation code.
See JARStructure and its addClassPath call, where includeRootManifestCP == true.// Add the manifest locations if (includeRootManifestCP && isLeaf(entry) == false) { try { VFSUtils.addManifestLocations(entry, paths); } catch(Exception e) { if (trace) log.trace("Failed to add manifest locations", e); } } ...
-
2. Re: Should BundleStructureDeployer add embedded archives ?
alesj Oct 8, 2009 5:49 AM (in response to thomas.diesler)"alesj" wrote:
Yes, it should be the structure deployer to handle this, not policy creation code.
In this case it could also be some real deployer (pre CL stage),
similar to what we do in InMemoryClassesDeployer.
But since you're already parsing manifest for symbolic name in structure deployer,
I guess you don't gain that much by moving this code on top of existing OSGiMetaData in some real deployer.
e.g. it would make sense to move it to real deployer and work on existing OSGiMetaData, hence not reading manifest headers twice
But like I said, this is not the case here, as you *must* already read it in structure deployer -
3. Re: Should BundleStructureDeployer add embedded archives ?
thomas.diesler Oct 8, 2009 8:44 AM (in response to thomas.diesler)ok, I moved the Bundle-ClassPath handling to the bundle structore deployer. The OSGiClassLoaderFacory picks up the classpath from the structure