Issue Details (XML | Word | Printable)

Key: GLASSFISH-17038
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: marina vatkina
Reporter: Hong Zhang
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

3.1.1 deployment performance - ejb container module get loaded for a pure web application

Created: 13/Jul/11 04:45 PM   Updated: 25/Mar/13 03:37 PM   Resolved: 25/Mar/13 03:37 PM
Component/s: ejb_container
Affects Version/s: 3.1.1
Fix Version/s:

Time Tracking:
Not Specified

File Attachments: 1. Text File started-208.log (6 kB) 13/Jul/11 08:32 PM - Hong Zhang

Issue Links:

Participants: Cheng Fang, Hong Zhang, marina vatkina and Shing Wai Chan

 Description  « Hide

Using the felix console to monitor which module get loaded for the web application deployment, noticed the ejb container module got active and the ejb security module got resolved

208|Active | 1|org.glassfish.ejb.ejb-container (3.1.1.SNAPSHOT)

94|Resolved | 1| (3.1.1.SNAPSHOT)

we need to figure out which dependency had triggered the ejb related modules get loaded/resolved, they should not be for a pure web application. I will attach the test web application in the issue next.

Hong Zhang added a comment - 13/Jul/11 04:58 PM

please see its parent issue for the test application

Hong Zhang added a comment - 13/Jul/11 08:30 PM

Further analysis showed the ejb-container jar was loaded as part of the web container initialization. And also ejb-container contains implementation classes of AnnotationHandler which will be brought in by dol module as well (SJSASFactory injects a list of AnnotationHandler classes)

Inhabitants / stack combination
Requested by LazyInhabitant-13768021(, active: null) called from metadata

{class: [] index: [com.sun.enterprise.container.common.spi.util.JavaEEIOUtils] }

Requested by ConstructorCreator-29633611(com.sun.enterprise.web.WebContainer) called from metadata

{class: [com.sun.enterprise.web.WebContainer] org.glassfish.api.container.Container: [com.sun.enterprise.web.WebContainer] index: [org.glassfish.api.container.Container:com.sun.enterprise.web.WebContainer] }

marina vatkina added a comment - 13/Jul/11 08:37 PM


As you can see, AnnotationHandler's everywhere cause corresponding modules to be loaded. Unless all of them are moved to the modules with Sniffers, there is not much that our modules can do.

Hong Zhang added a comment - 13/Jul/11 08:50 PM

yes, several areas have similar issue and I am looking for a uniformed solution. Moved to the connector module with sniffer is one possibility. I will keep you posted. I am keeping this issue under ejb-container for now as the code to be moved here will be ejb related.

Hong Zhang added a comment - 14/Jul/11 02:12 AM

Aside from the AnnotationHandler related issues, let's look at the first one (current one) to bring in the ejb-container module.

According to the HK2 traces (attached in the issue), the ejb-container is brought in as part of the web container initialization. And further look at the WebContainer code, there is this injection:
private JavaEEIOUtils javaEEIOUtils

This injection loads its impl class JavaEEIOUtilsImpl in the ejb-container module (ejb/ejb-container/src/main/java/com/sun/ejb/base/io/ which makes the ejb-container module loaded.

Assign to web container for initial evaluation on this issue, to see why the web container needs to use this class, and then how we can resolve the issue (maybe moving the to one of the common modules like container-common or common-utils).

Once we get this dependency removed, we can look at the annotation handlers related things.

Shing Wai Chan added a comment - 14/Jul/11 06:35 AM

Web container uses JavaEEIOUtils in order to serialize and deserialize the EJB references in HttpSession correctly.
Assign to ejb container to see whether this implementation can be moved to a common module.

marina vatkina added a comment - 14/Jul/11 06:03 PM

There are 2 issues reported here:

AnnotationHandlers location. This works as designed.

JavaEEIOUtils dependencies - there is already an RFE for moving them to the common location:

Hong Zhang added a comment - 14/Jul/11 06:17 PM

1. For annotation handlers issue, even though it's expected behavior with the current HK2 mechanism to find the impl classes from various modules. But this does not mean we should load the ejb-container module because of this. We need to move these handlers classes to another module to avoid loading ejb-container module as part of the web deployment.
2. For, I understand this is already a RFE filed it, but as we are now really looking for performance gain, we should continue looking into this:
a. can we verify the dynamic injection indeed does not work?
b. what about my suggestion of moving the relevant classes to ejb-connector module?

As the performance is the release priority now, I am re-opening the issue now to request further investigation. Thanks for your understanding.

marina vatkina added a comment - 14/Jul/11 06:26 PM


As the investigation for the Annotation handlers needs to be done at the GF level, I'll reassign this bug to you. When the decision is made on what is the approach to be taken GF-wide, feel free to reassign it back to us.

Hong Zhang added a comment - 14/Jul/11 06:34 PM

Marina: I had discussed with Jerome yesterday. Between the two options of moving the classes back to DOL versus creating a new glue module to hold the classes, he prefers to have a new module.

marina vatkina added a comment - 14/Jul/11 06:42 PM


Did you discuss this at asarch?

Hong Zhang added a comment - 14/Jul/11 06:52 PM

I am not sure that this change requires asarch discussion, we should just not load ejb-container module as part of the web deployment, right? But if you think it's necessary, you can start a thread with asarch and Cc me. Thanks.

marina vatkina added a comment - 18/Jul/11 10:25 PM

According to Scott it's no longer critical

Cheng Fang added a comment - 19/Aug/11 08:56 PM - edited

committed Rev: 48926 to 3.1.2 branch, moving annotation handler classes, archivist class, scanner class, and the related from ejb-container to ejb-connector.

committed revision 48934 to trunk.

Cheng Fang added a comment - 19/Aug/11 10:04 PM

With the above fix and when web container obtains JavaEEIOUtils lazily, or when web container uses a generic JavaEEIOUtils impl, ejb container will not be loaded when deploying servlet/jsp-based web app.

For jsf-based app, the lookup by jsf impl of "clientStateSavingPassword" will trigger the loading of global NamedNamingProxy, which includes EJBContext. As a result, ejb-container will be loaded. This naming proxy bootstrapping happens prior to the first lookup operation, and in this case jsf happens to perform the first lookup.

Cheng Fang added a comment - 16/Dec/11 05:07 AM

In 4.0 trunk only, ejb-related annotation handler classes are moved back to ejb-container. See issue (move ejb annotation handlers out of ejb-connector)

Hong Zhang added a comment - 25/Mar/13 03:37 PM

I just checked this for and ejb container is no longer loaded (in active state) after deployment.