本文介绍了为什么mojarra 2.1会在每个模块启动时扫描所有其他战争?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有一个庞大的EAR应用程序,包含大约20个ejb-jar和war模块。

We have a huge EAR application with about 20 ejb-jar and war modules.

对于Mojarra启动的每个war模块,似乎它正在尝试扫描注释在每一场战争中。其他战争对于类加载器是不可用的,所以我有很多例外。无论如何它最终都会启动,但它会在警告的情况下使我的日志变得混乱,如果没有这个(+100秒),我猜应​​用程序的启动时间会少得多。

For each war module that Mojarra starts, it seems it is trying to scan annotation on every other war. Other wars are unavailable to the classloader, so I get lot of exceptions. It eventually starts anyway, but it clutters my logs with warnings, and I guess application startup time could be much less without this (+100 seconds).

要清楚,我有以下结构:

To make it clear, I have following structure:

EAR
+- ejb1
+- ejb2
+- war1
+- war2

当Mojarra开始war1时,它抱怨war2缺少类(ClassNotFoundException)。

When Mojarra starts war1, it complains about missing classes from war2 (ClassNotFoundException).

我在升级到Glassfish 3.1时看到了这一点(因此,Mojarra 2.1)。

I saw this when upgrading to Glassfish 3.1 (and thus, Mojarra 2.1).

推荐答案

我找到了原因,并找到了一些解决方法。

I found the reason, and some workaround.

在Glassfish 3.1上,随Mojarra 2.1一起提供,类路径扫描被委托给Glassfish 。现在,Glassfish似乎给了所有类别的耳朵文件而不是战争。我为此打开了 (但它确实似乎是一个Glassfish错误,而不是JSF / Mojarra)。

On Glassfish 3.1, which ships with Mojarra 2.1, classpath scanning is delegated to Glassfish. Now, Glassfish seems to give all classes of ear file instead of war. I opened http://java.net/jira/browse/JAVASERVERFACES-1995 for that (but it really seems to be a Glassfish bug, not JSF/Mojarra).

在等待修复时,我修改了Mojarra,如下所示:在com.sun.faces中.config.ConfigManager.java,在第834行附近,我注释掉了一些行:

While waiting for a fix, I patched Mojarra like this : in com.sun.faces.config.ConfigManager.java, around line 834, I commented out some lines:

//            if (provider instanceof DelegatingAnnotationProvider &&
//                null != annotationScanner) {
//                // This InjectionProvider is capable of annotation scanning *and*
//                // injection.
//                ((DelegatingAnnotationProvider)provider).setAnnotationScanner(annotationScanner,
//                        metadataGetter.getJarNames());
//                scanUris = Collections.emptySet();
//            } else {
                // This InjectionProvider is capable of annotation scanning only
                scanUris = metadataGetter.getAnnotationScanURIs();
//            }

日志现在更加冗长。似乎Glassfish仍在扫描每个类,所以我仍然收到这样的警告:

The logs are now much less verbose. It seems Glassfish is still scanning every classes, so I still get warnings like this:

[#|2011-03-18T13:47:05.019+0100|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=57;_ThreadName=Thread-1;|WEB9052: Unable to load class org.apache.myfaces.custom.inputTextHelp.HtmlTextHelpRenderer, reason: java.lang.ClassNotFoundException: org.apache.myfaces.custom.inputTextHelp.HtmlTextHelpRenderer|#]

但没有来自Mojarra的堆栈跟踪,这已经非常简洁了。

But no stacktrace from Mojarra, which is already quite less verbose.

这篇关于为什么mojarra 2.1会在每个模块启动时扫描所有其他战争?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-09 12:21