1:42 a.m.
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)