Witold,
He pretty much means what you think he means.
Recall that EJB is a COMPONENT spec. Today, in EJB3 we pretty much have 3 major component types: Stateless Session Beans, Stateful Session Beans, and Message Drive Beans.
Each of those beans are individual components, each with their own little view of the world. That's why each one is effectively required to "maintain" their own resources. Now, obviously, most leverage container supplied resources (notably data pools and what not).
But the beans themselves have their own lifecycle within the container itself. They can be created, passivated, destroyed, etc, all at a different rate than the overall container.
For example, just because the app server is started doesn't mean the actuall application is started (it could be disabled for example). And even if the application is started, a Session bean may not be initialized simply because it has never been called.
And, finally, session beans are a portable construct within EJB. In theory you should be able to take a properly written Session Bean and drop it in to another application by doing little more than tweaking the XML descriptor.
All that said, I agree there should be lifecycle methods around the EAR, it would be nice if there were some way to specify module dependencies (like even tho I have a separately deployed WAR, I don't want it started before this EAR is started) etc.
Of course, it can all be lazy chained together -- simply the fact that a ContextListener in my WAR calls upon the EAR initializes the EAR, so it's effectively the same thing.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=260517