Flavia Rainone [
http://community.jboss.org/people/flavia.rainone%40jboss.com] created the
discussion
"Re: Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit:
http://community.jboss.org/message/561400#561400
--------------------------------------------------------------
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)
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/561400#561400]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]