Description of problem: [business-central] Project which includes -- XLS table (which can't be built out of the box) -- dependency for a jar which includes the same XLS table, model classes, etc.. fails upon build & deploy. The problem here is not the failed build itself, but the fact that the build process *never* stops, it goes into infinite loop and will end by causing PermGen space error. Version-Release number of selected component (if applicable): BPM 6.0.1 BPM 6.0.2-er2 How reproducible: always Steps to Reproduce: 1. Import XLS file (attached) 2. Build&deploy 3. Upload jar (-SNAPSHOT.jar) to the artifact repository 4. Add it as a project dependency 5. build & deploy -- observe warnings and exceptions in the log (attached) and that they will continue to be displayed in the loop. Actual results: Process of project build never stops. Expected results: If the build of the process shall be not successful, it should simply failed and not go into infinite loop. Additional info: It seems that the process fails only when the dependency of the project is the jar created by the maven (mvn clean package). When I have added the jar to this project, which was exported via Eclipse, behavior was expected.
Created attachment 895834 [details] [1] XLS table - to be imported to the BC
Created attachment 895835 [details] [2] Jar with the same XLS - to be added as a project dependency
Created attachment 895836 [details] [3] eclipse jar - to be added as a project dependency instead of the [2]
Created attachment 895837 [details] [4] logs which are produced after project build when [2] is added
Created attachment 895840 [details] [5] whole process of reproducing the issue recorded on the video
Hi, With the latest build Community 6.2.0.CR3 (AFAIK to be Product 6.1.0.ER3) I followed your steps and the project built OK. IDK all of the classes in the dependencies of "jbpmexcel6-0.0.1-SNAPSHOT.jar" however if any have a circular dependency it would have caused the problem you report. This was fixed with https://issues.jboss.org/browse/GUVNOR-2140. It is probably not good practice both uploading the XLS file and including it in the dependency, but that said, the workbench should support anything users try. I suggest this is re-tested with the next Product offering. With kind regards, Mike
I cannot reproduce either the infinite loop or PermGen space error in project build. However, I believe these two are just possible symptoms of the root cause, which is too pedantic handling of transitive dependencies. Having a simple dependency on org.drools:drools-decisiontables either (A) in a project managed by Business Central or (B) in any uploaded artifact used as a dependency of such project (Anton's case), produces tons of warnings caused by java.lang.ClassNotFoundException and makes the build take too much time (which may possibly seem to take an infinite time or crash with PermGen space error on systems with not enough RAM). The reason why changing described project's dependency from jbpmexcel6-0.0.1-SNAPSHOT.jar to model.jar does not produce warnings is that model.jar does not have a valid pom.xml where it is expected and so does not declare dependency on drools-decision tables. However to have a KIE project with XLS decision tables that can be built purely with Maven, it is necessary to depend on drools-decisiontables. I believe this should be a valid use case. Unfortunately, there are artifacts around, often used transitively, that can have "optional" dependencies (see bug 1092839 comment 7), or do not declare all of their direct dependencies, which may be cause of the huge amount of ClassNotFoundException's. Validation of classes coming from project dependencies (including transitive ones) should be made less pedantic not to affect Business Central project by slowing down the build and producing warnings that cannot be resolved.
Created attachment 1004566 [details] Project with drools-decisiontables dependency Please use this GIT repository to reproduce the issue with building project inside Business Central. The repository contains a simple KIE project with XLS decision tables and has all necessary dependencies to be built with "mvn clean package". To reproduce, you can either: 1. Clone the repository into Business Central, open the project and build it. The build will take some time and print a few warnings into Messages console. server.log will contain much more warnings. 2. Upload the artifact obtained by running "mvn clean package" into Business Central and add it as a dependency of any project. Then build the project and observe warnings.
(In reply to Jiri Locker from comment #8) > Validation of classes coming from project dependencies (including transitive > ones) should be made less pedantic not to affect Business Central project by > slowing down the build and producing warnings that cannot be resolved. It's not the validation that is slow, it's the resolution of all the classes in the pom and dependencies in the first place using Eclipse Aether. See https://bugzilla.redhat.com/show_bug.cgi?id=1201853 for more information (yes, there are quite a few inter-related BZs about these WARNs!)
(In reply to manstis from comment #10) > It's not the validation that is slow, it's the resolution of all the classes > in the pom and dependencies in the first place using Eclipse Aether. See > https://bugzilla.redhat.com/show_bug.cgi?id=1201853 for more information > (yes, there are quite a few inter-related BZs about these WARNs!) Good point. I have re-tried with white list only allowing the domain class used by XLS DT. Although that didn't avoid the ClassNotFoundException warnings, the build was successful (even without package-names-white-list). Therefore I consider this ticket resolved. Lets track build warnings in bz 1201853.
Reproduced "java.lang.OutOfMemoryError:PermGen space" with JRE 6 and EAP 6.4.0.ER6 with default memory settings (-Xms1303m -Xmx1303m -XX:MaxPermSize=256m). The reason why I failed to reproduce previously is that I was testing with JRE 7. Java 7 started removal of PermGen memory space. Its size is no longer configurable via -XX:MaxPermSize and so probably behaves in a different way than in Java 6. Read more at http://javaeesupportpatterns.blogspot.com/2011/10/java-7-features-permgen-removal.html. After changing PermGen space size to 512m, I was not able to hit OOME anymore, even when building the project repeatedly (I will attach GC log). It still may be a good idea review memory usage and look for classloader leaks (http://frankkieviet.blogspot.com/2006/10/how-to-fix-dreaded-permgen-space.html). Anyway, this may at least deserve a mention in the documentation that "-XX:MaxPermSize=256m" is not a recommended setting for production environment. Mike, I will leave it up to you to decide if there is anything to be fixed/improved.
Created attachment 1006365 [details] GC log from JRE7 Garbage collection log showing how PermGen is cleaned up on full GC. The project described in steps to reproduced was being built repeatedly during that time.
Created attachment 1006366 [details] GC log from JRE6 Garbage collection log from JRE 6 with -XX:MaxPermSize=512m. The same scenario as for the previous attachment.