Issue Details (XML | Word | Printable)

Key: GLASSFISH-18329
Type: Task Task
Status: Open Open
Priority: Major Major
Assignee: Hong Zhang
Reporter: Sanjeeb Sahoo
Votes: 0
Watchers: 0
Operations

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

Deployment/kernel cleanup - Phase 4: Misc Tasks

Created: 06/Feb/12 04:20 PM   Updated: 15/Jan/13 01:46 AM
Component/s: deployment
Affects Version/s: 4.0_b22
Fix Version/s: future release

Time Tracking:
Not Specified

Issue Links:
Related
 

Tags: spo
Participants: Hong Zhang and Sanjeeb Sahoo


 Description  « Hide

Hong,

I am creating this task to capture what we discussed the other day. As you might have noticed, I have cleaned up XModuleType which was a prerequisite for these items. Feel free to create subtasks if you wish. I am definitely hopeful doing all these will not only give us cleaner code, but also improve performance. Moreover, this will also help us getting closer to modular dol.

1) Move DeploymentUtils.isEJB/isWAR/isEAR/isRAR/isCAR to respective ArchiveDetector.handles(). Because cloud folks and admin gui introspects archive without deployment context, we need two methods: one that accepts DeploymentContext so that it could retrieve the information already computed in earlier stages of deployment and another one that just takes an Archive.

2) deployer sorting cleanup

3) Fix the following code which is in DeployCommand in nucleus: // done to disable versioning support for osgi
if ( name != null && !isUntagged && type != null && type.equals("osgi") ) {

4) Preselect certain sniffers to improve performance - especially for ejbjar. This is no longer a low priority, as this has to be fixed in order to address the osgi archive type support.

5) Remove List<Sniffer> prepareSniffersForOSGiDeployment(String type, DeploymentContext context) from Deployment; Its implementation in ApplicationLifecycle is incorrectly treating type as containerType instead of archiveType. The man page says it is archive type. Moreover, it seems to be created as a shortcut to address issues involved in OSGi archive type support. While doing this, make OSGiArchiveHandler a non-composite handler.

Optional:
6) It will be better to introduce an abstraction called DeploymentUnit with subclasses like Ear, EjbJar, War, Rar, Car, PlainJar, OSGiArchive, etc. It represents the structure of the bits getting deployed. Adding a new DeploymentUnit is a very expensive operation. It is like adding a new language in an extensible extensible compiler architecture. ArchiveHandler can be a producer of these objects with a source Archive as input. Since this is a stateful object, this can be set in DeploymentContext as opposed to storing a stateless object like ArchiveHandler. DeploymentUnit can have a method called getModuleType(): XModuleType. DeploymentUnit should also have a method called getSource(): ReadableArchive.

7) Remove all XXX_SNIFFER_TYPE constants from Application config bean. This will also require a change in ApplicationLifecycle which is using CONNECTOR_SNIFFER_TYPE to decide which applications to load first. We should separate that as a strategy and provide it from j2ee server distribution. Instead of looking for sniffer types, use archive type and define a loading order for each archive type. Allow the loading order to be overridden by application metadata during deployment: to be done

8) Add a method in ArchiveHandler called getEmbeddedClasses() which can be used by SnifferManagerImpl to iterate over while looking for annotations. This will avoid the hack we have in DeploymentUtils.getModuleLibraryJars() which being in nucleus knows about all the archive types and not at all extensible.

9) Why don't we call Sniffer.handles() first before looking for annotations in SnifferManagerImpl.getSniffers()?

Thanks,
Sahoo



Hong Zhang added a comment - 26/Apr/12 03:52 PM - edited

Some changes checked in this week related to the clean up tasks:

1. Remove javax.enterprise.deploy dependency from nucleus distribution (deployment-common module). Move various methods of getting archive types from DeploymentUtils to DOLUtils and update the classes referencing the methods.

2. Have the archive handlers be responsible for returning the associated class path URLs for the archive instead of having the DeploymentUtils class do it for them. Add an ArchiveHandler.getClassPathURIs API for each archive handler to return its corresponding class path URLs and move out the relevant logic from DeploymentUtils (deploymenmt-common module) and SnifferManagerImpl (core-kernel module).

2) here addressed item 8 in the task list.


Hong Zhang added a comment - 21/Jun/12 03:09 PM - edited

Add a new item in the clean up list:

10) We should be able to clean up CompositeSniffer interface now we have Sniffer.supportsArchiveType API


Hong Zhang added a comment - 26/Jul/12 03:30 PM

Addressed item 1 of the task list. Replace various isXXX methods with generic isArchiveOfType methods (one takes a DeploymentContext when it's applicable for optimization, and one does not for the case where DeploymentContext is not available from the calling code) to remove Java EE dependencies from DeploymentUtils. The container specific logic are moved to the corresponding container modules.
Committed svn version: svn 55221


Hong Zhang added a comment - 10/Aug/12 02:44 PM

Addressed item 10 of issue 18329: clean up CompositeSniffer interface now we have Sniffer.supportsArchiveType API.
Committed svn version: svn 55391


Hong Zhang added a comment - 14/Aug/12 02:49 PM

Addressed item 5 of the list. Removed special handling for OSGi archive type, removed Deployment.prepareSniffersForOSGiDeployment API, with the
Sniffer.supportsArchiveType API we no longer need this. Also removed the
SnifferManager.canBeIsolated API to remove the artificial restriction on
the type option.
Committed svn version: svn 55449


Hong Zhang added a comment - 15/Jan/13 01:46 AM

Scrub issues for Java EE 7 release.