Nuno Godinho de Matos created WFLY-9453: ------------------------------------------- Summary: JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers Key: WFLY-9453 URL: https://issues.jboss.org/browse/WFLY-9453 Project: WildFly Issue Type: Enhancement Components: EJB Affects Versions: 11.0.0.CR1 Reporter: Nuno Godinho de Matos Priority: Optional Currently, I am looking at an application whose deployment time I am trying to optimize. Not only Wildfly, but as well on Weblogic. One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization. Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase. I an exception takes place, the deployment fails. And they also cound like official deployment time of the WAR application. Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events. Now for this application, whose deployment time I am trying to optimize, two things are clear: (a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring. (b) They should however not break application deployment or even count as cost of application deployment time. Point (a) is something I will only attack at a later point in time, perhaps. But point (b) is something I have now addressed and that brings me to this enhancement request. In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic. More Application life cycle events should be offered. @Startup, @PostDeploy, @PreDeploy As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach. But back onto topic. For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic: - Scanning Jars - Preparing class loaders - Bind EJBs to the JNDI tree - Setup Managed Beans for the APP - Invoking @Startup ejbs that are OK to be part of the deployment phase - Initializing Mojarra The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases. In fact, it seems like there is an obvious need for this because. if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy. https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367 The documentation listed above, is not perfect. it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner. Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored. Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc... But you see the ground work of application deployment metadata, that is app server specific to support what I am saying. In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic. On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished. Then there are substancial differences on what happens on the Listener. In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment. On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached. On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed. The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things. And that they are highly application server specific. In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean. In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events. The @Startup @PreDestroy are clearly not enough, in my oppinion. And the way to do what I have done should be made much simpler in the future. It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml. And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this. Many thanks for considering this request. -- This message was sent by Atlassian JIRA (v7.5.0#75005)