jboss-as 7 类加载与 ApplicationScoped eager ManagedBean 的战争
我的 Maven 项目中有这样的结构:
WEB-INF/lib
- a.jar
- Registry.class (@ApplicationScoped, @ManagedBean(eager=true)
- b.jar
- Module.class (@ApplicationScoped, @ManagedBean(eager=true)
我在两个类的 @PostConstruct 带注释的方法处放置了一个记录器,以确定首先调用哪一个,在 JBossAS7 服务器上进行多次部署后,我注意到加载这些类似乎没有特定的顺序 。我的目的是始终在 Module.class 之前加载Registry.class。但对于这种类加载行为,我不知道如何实现它。
在某些情况下,Registry.class 首先被加载,但在其他情况下,Module.class 首先被加载即使我刚刚重新启动应用程序服务器并且没有对代码进行任何更改。
现在我的问题是,我可以做些什么来定义 WEB-INF/lib 中加载 jar 的顺序吗?
不同的观点:
是否也有可能问题不在于类加载,而在于 ApplicationScoped eager ManagedBean?我在a.jar上添加了一个类:
- RegistryTwo.class (@ApplicationScoped, @ManagedBean(eager=true)
这样a.jar现在包含Registry.class和RegistryTwo.class。有了这个,我期待类似的东西:(
期望的输出)
Registry.class is invoked.
RegistryTwo.class is invoked.
Module.class is invoked.
或(我将遇到这个问题。)
Module.class is invoked.
Registry.class is invoked.
RegistryTwo.class is invoked.
但是在某些情况下,我得到这个:
RegistryTwo.class is invoked.
Module.class is invoked.
... (Other Processing logs.)
Registry.class is invoked.
根据@BalusC,ApplicationScoped eager ManagedBean将在应用程序启动时自动实例化( 如何强制在应用程序启动时实例化一个应用程序范围的 bean?),这发生在我的代码中。
我只是想知道:
- JSF 如何加载/创建 ApplicationScoped eager ManagedBeans?是否有某种规则可以定义顺序?
- 当Registry.class位于同一个jar文件下并且都是ApplicationScoped时,为什么Registry.class没有在RegistryTwo.class之前/之后实例化?
I have this kind of structure in my Maven project:
WEB-INF/lib
- a.jar
- Registry.class (@ApplicationScoped, @ManagedBean(eager=true)
- b.jar
- Module.class (@ApplicationScoped, @ManagedBean(eager=true)
I placed a logger at the @PostConstruct annotated method on the two classes to determine which is invoked first and after several deployments on the JBossAS7 server, I noticed that there SEEMS to be no specific order in loading these classes. My intention is to ALWAYS have Registry.class loaded before Module.class. But with this class loading behavior, I don't know how to achieve it.
In some instances, Registry.class is being loaded first but in other instances, Module.class gets loaded first even if I just restarted the application server and did no changes on the code.
Now my question is, is there something that I can do to define the order of loading jars within the WEB-INF/lib?
A different perspective:
Can it also be possible that the problem is not within the class loading but with the ApplicationScoped eager ManagedBean? I added a class on a.jar:
- RegistryTwo.class (@ApplicationScoped, @ManagedBean(eager=true)
so that a.jar now contains Registry.class and RegistryTwo.class. With this, I am expecting something like:
(Desired output)
Registry.class is invoked.
RegistryTwo.class is invoked.
Module.class is invoked.
or (I have will have a problem with this.)
Module.class is invoked.
Registry.class is invoked.
RegistryTwo.class is invoked.
BUT in some instances, I am getting this:
RegistryTwo.class is invoked.
Module.class is invoked.
... (Other Processing logs.)
Registry.class is invoked.
According to @BalusC, an ApplicationScoped eager ManagedBean will be auto-instantiated upon application startup (
How do I force an application-scoped bean to instantiate at application startup?) and that happens in my code.
I just wonder:
- How does JSF load/create ApplicationScoped eager ManagedBeans? Is there some sort of rule wherein the order is/can be defined?
- Why was Registry.class not instantiated before/right after RegistryTwo.class when they are both under the same jar file and they are both ApplicationScoped?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
绝对没有顺序规则。
我建议让
Registry
实现ServletContextListener
或ServletContainerInitializer
代替。两者都保证在 JSF 应用程序范围的 bean 构造之前运行。对于
ServletContextListener
,您可以让Registry
将自身放入应用程序范围,如下所示:它将在 JSF/EL 中以通常的方式使用
#{注册表}
。There is absolutely no ordering rule.
I suggest to let
Registry
implementServletContextListener
or maybeServletContainerInitializer
instead. Both are guaranteed to run before before JSF application scoped bean constructions.In case of
ServletContextListener
, you could letRegistry
put itself in the application scope as follows:It'll be available in JSF/EL the usual way by
#{registry}
.