Flavia Rainone wrote:
We are not. I need to enable scanning of libs referenced by the manifest of deployed jars. The same goes for libs referenced by the manifest of lib jars (if any).
With the help of Ales, I learned that ArchiveFilesDeployer should already receive the manifest referenced classpath of deployed jars in the line flagged below:
public void deploy(VFSDeploymentUnit unit, JBossWeldMetaData deployment) throws DeploymentException
{
>>>>> Iterable<VirtualFile> classpaths = getClassPaths(unit);
for (VirtualFile cp : classpaths)
{
VirtualFile wbXml = cp.getChild("META-INF/beans.xml");
if (wbXml.exists())
{
// add url
wbFiles.add(wbXml);
// add classes
cpFiles.add(cp);
}
}
That means that we shouldn't have to do any work on the weld-int side to make it work. Despite that, I didn't manage to make a 100% working example.
I removed SentenceParser class from weld-translator.jar (the same used by testsuite deployers/weld) and added that class to a weld-translator-lib.jar. Then, I tried the following alternatives:
- I first put weld-translator-lib.jar in /home/fla and referenced that jar from weld-translator.jar manifest file, with a series of ../:
Class-Path: ../../../weld-translator-lib.jar
VFSUtils.addManifestLocations correctly recognizes the jar, but WeldFilesDeployer receives a classpath like $JBOSS_HOME/server/all/deploy/weld-translator.jar/home/fla/weld-translator-lib.jar, which does not exist
- I decided to get rid of the .. in the classpath and added weld-translator-lib.jar to server/all/deploy. The weld-translator.jar manifest classpath refers now to weld-translator-lib.jar, as in the attached file
That one works (i.e., no deployment errors). However, it does not work 100% correctly, because the
if (wbXml.exists())
statement above (when checking for weld-translator-lib.jar/META-INF/beans.xml) returns false, when it should return true
- finally, I tested the attached weld-translator.ear file, that contains weld-translator-lib.jar, and whose weld-translator.jar archive references that lib jar from its manifest. It doesn't work either. This time, VFSUtils.addManifestLocations recognizes the referenced jar, but the WeldFilesDeployer piece of code I pasted above does not get the extra classpath entry $JBOSS_HOME/server/all/deploy/weld-translator.ear/weld-translator-lib.jar. The outcome is the following deployment exception:
15:50:42,482 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to
Start: name=vfs:///home/fla/Development/projects/jbossas-trunkLATEST/build/target/jboss-6.0.0-SNAPSHOT/
server/all/deploy/weld-translator.ear_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DeploymentException:
WELD-001408 Unsatisfied dependencies for type [SentenceParser] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject org.jboss.test.deployers.weld.translator.ejb.TextTranslator(SentenceParser)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:294)