[JBoss Microcontainer Development POJO Server] - Re: Implementing a non-flat deployment for Weld Integration
2:42 p.m.
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/560324#560324
--------------------------------------------------------------
To keep you posted, Marius provided a fix for JBAS-8170 (the BeanManager JNDI issue) and
now the weld deployers tests are finally passing for me (with the WELDINT-1 stuff
enabled).
Unfortunately, though, if I run those tests several times in a row, I get an
OutOfMemoryError. I'm trying to figure out where is the memory leak.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560324#560324]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
3:58 p.m.
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/560327#560327
--------------------------------------------------------------
I'm attaching an updated patch to https://jira.jboss.org/browse/JBAS-8250 Jira. This
patch can be applied against JBoss AS trunk to enable the new non-flat Deployment in the
server.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560327#560327]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
1:34 p.m.
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/560663#560663
--------------------------------------------------------------
I have just committed the rest of JBAS-8250 to trunk.
As far as I can see, the non-flat DeploymentImpl is not causing the OutOfMemoryError.
Comparing DeploymentImpl vs FlatDeployment, I had to run the deployers/weld tests the same
number of times (16 times) to get a OutOfMemoryError.
Anyway, I profiled JBoss AS memory usage with those tests. A very high number of
HashMap$Entry instances called my attention, and most of them couldnt' be garbage
collected. JProfiler showed them as being held by org.jboss.logmanager.LogContext, so I
don't think I got to any useful results.
Going back to JBAS-8250, I see 4 pending issues:
- the library scanning that Ales is working on
- we need also a mechanism to scan for libs referenced from manifest files, creating BDAs
for any lib that contains META-INF/beans.xml
- a FIXME that I added to DeploymentImpl (regarding the undeployment of loaded BDAs)
- replace the slow Classpath implementation by the NoDuplicatesClasspath
The last two are pretty simple to do. The second one concerns me most. Any ideas on how
should we tackle that one?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560663#560663]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
7:28 p.m.
Ales Justin [http://community.jboss.org/people/alesj] created the discussion
"Re: Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/561066#561066
--------------------------------------------------------------
- we need also a mechanism to scan for libs referenced from manifest
files, creating BDAs for any lib that contains META-INF/beans.xml
How is this
different from what we're already doing?
Or, I think we're already covering this use case. Or not?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/561066#561066]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
3:46 a.m.
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/561243#561243
--------------------------------------------------------------
Ales Justin wrote:
> - we need also a mechanism to scan for libs referenced from manifest files, creating
BDAs for any lib that contains META-INF/beans.xml
How is this different from what we're already doing?
Or, I think we're already covering this use case. Or not?
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).
Ales Justin wrote:
Let me know when you're done, as I'm mostly done, but I have a few changes to
your code,
to make this integration easier / nicer.
You can feel free to commit when you're done. I don't think that the stuff that
you are doing, even if you refactor some of the BDA impl code, which you probably did,
will affect too much the work I mentioned above.
BTW, this is all that is left. The other two itens below are committed to trunk:
- a FIXME that I had previously added to DeploymentImpl (regarding the undeployment of
loaded BDAs)
- replace ClasspathImpl by NoDuplicatesClasspath
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/561243#561243]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
3:51 a.m.
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&...]
12:13 p.m.
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/561698#561698
--------------------------------------------------------------
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
https://community.jboss.org/thread/156508 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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/561698#561698]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
12:57 p.m.
Ales Justin [http://community.jboss.org/people/alesj] created the discussion
"Re: Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/563736#563736
--------------------------------------------------------------
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.
I think you're right -- the full classpath should be
considered.
Filtering was more of a brain dump from some old code, which actually needed this
filtering.
e.g. only valid classpath were the deployments paths, which is not the case here as your
example shows it
I'll remove the unneeded code.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/563736#563736]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
1:17 p.m.
Ales Justin [http://community.jboss.org/people/alesj] created the discussion
"Re: Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/563888#563888
--------------------------------------------------------------
- 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:
This test is actually semi-broken, as it
doesn't exactly/propery test what you had in mind.
The catch is in the way we handle sub-deployments in .ear.
Even though they are not referenced in application.xml, they are still considered to be
real ear contents; see EARStructure.
So, in your case, the SentenceParser bean could come or be refed (in Weld) from just
another sub-deployment,
hence not actually thru manifest reference.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/563888#563888]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
7:44 p.m.
Ales Justin [http://community.jboss.org/people/alesj] created the discussion
"Re: Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/561086#561086
--------------------------------------------------------------
- the library scanning that Ales is working on
Let me know when
you're done, as I'm mostly done, but I have a few changes to your code,
to make this integration easier / nicer.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/561086#561086]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4963
days inactive
4983
days old
jboss-dev-forums@lists.jboss.org
9 comments
2 participants
participants (2)
-
Ales Justin -
Flavia Rainone