Flavia Rainone [
http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to
the discussion
"Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit:
http://community.jboss.org/message/546199#546199
--------------------------------------------------------------
Flavia Rainone wrote:
Finally, the tests are very poor. I just ported the already existing ones to test the
new deployers. So writing real tests is what I'll be doing next, and I'm sure I
have quite a few bugs to catch ;-)
I stumbled upon some issue here.
The problem is located in WeldFilesDeployer:
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);
}
}
This deployer deploys the cpFiles of the current unit only if it has the
META-INF/beans.xml file.
The problem with this is that this results in an ArchiveInfo without any classes in it if
we deploy an ejb-jar without META-INF/beans.xml. In the future, if Weld request for a BDA
associated with the ejb-jar by calling Deployment.loadBeanDeploymentArchive, it will get a
BDA that has no classes in it.
So, I tried to "fix" it:
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);
}
This resulted in a series of test failures. All related with the criteria that we use to
decide whether to put a class in a BDA.
Overall, these are the scenarios that are broken:
- if one or more lib jars in an ear happen to not have a META-INF/beans.xml file, the lib
classes were not part of the BDA that represents the ear (note that currently I'm
creating a BDA for every classLoader. So, for an ear, there is a single BDA that contains
all the info regarding lib jars and ejb-jars in it).
- if one ore more ejb-jars in an ear happen to not have a META-INF/beans.xml file, the
classes of those non-CDI ejb-jars were not part of the resulting BDA
- if in a war that contains a WEB-INF/beans.xml we have one ore more lib jars that
don't have a META-INF/beans.xml, the classes of those libs are not part of the
resulting BDA (we currently create a single BDA for every war; this BDA represents both
the classes and the libs of the war)
- if, in a war that lacks a WEB-INF/beans.xml, we have one ore more lib jars that have the
META-INF/beans.xml, the classes of the war (WEB-INF/classes) are not part of the resulting
BDA.
In all the scenarios I described, the classes that were not part of the resulting BDA
became part of the BDA with my "fix".
Notice that, interestingly, in the way things are implemented today, if you pass one of
the missing classes as a parameter to a Deployment.loadBeanDeploymentArchive, my
implementation will return the requested BDA correctly, but still the BDA wil lack the
requested class!
So, we clearly have made some mistaken assumption here:
- either the classes that were not part of the BDAs in the previously described scenarios
were supposed to be in the BDA and I fixed the bug. Now, all I have left to do is fixing
the tests as well.
- or we should not create a BDA for every ClassLoader. We should be creating a BDA for
every classpath entry (i.e., there should be a BDA for the WEB-INF/classes war; and
another BDA for every lib in the war; simillarly, there should be a BDA for every distinct
jar in the ear archive). As a result, we have one ore more BDAs that can see each other
simultaneously because they all happen to belong to the same ClassLoader. Also, in a
single AS instace, we will have a larger number of BDAs when compared to my current
implementation.
Which way should I go now?
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/546199#546199]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]