Flavia Rainone wrote:
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
I found the cause of that if statement failure and opened a new thread discussion for that.
With the fix I wrote, the scenarios above work ok, with one exception: if weld-translator-lib.jar is in the deploy dir as well, I'm afraid a double deployment takes place (notice I'm not sure if this is the cause) and I get this deployment exception:
00:45:26,056 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.jar_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [SentenceParser] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject org.jboss.test.deployers.weld.translator.ejb.TextTranslator(SentenceParser)]. Possible dependencies [[Managed Bean [class org.jboss.test.deployers.weld.translator.ejb.SentenceParser] with qualifiers [@Any @Default], Managed Bean [class org.jboss.test.deployers.weld.translator.ejb.SentenceParser] with qualifiers [@Any @Default]]]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:298) [:2010-08-30 15:40]
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:132) [:2010-08-30 15:40]
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:151) [:2010-08-30 15:40]
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:366) [:2010-08-30 15:40]
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:352) [:2010-08-30 15:40]
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:436) [:2010-08-30 15:40]
Is it correct to assume that this scenario is not feasible and move on? I'm not sure if the test I'm performing is correct in this case.
Flavia Rainone wrote:
- 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)
The problem here is that WeldFilesDeployer.getClasspaths filters out the manifest referenced classpath, just because it is not contained inside the weld-translator.ear/weld-translator.jar archive. I commented out the filtering and no tests were broken.
That "fix" is committed along with a new testsuite test that reproduces the scenario above. Ales, do you remember for what reason WeldFilesDeployer was filtering the classpath entries? I need to know if I can delete that method or if it is needed for some specific scenario.