GFv2DeploymentPlan

Skip to end of metadata
Go to start of metadata

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<title>Glassfish Deployment v2 plan</title>
</head>
<body>
<big><big>Draft: Glassfish Deployment v2 Plan<br>
<br>
<small>Please send any comments to <a
href="mailto:s1as-deployment-dev@sun.com">s1as-deployment-dev@sun.com</a></small><br>
</big></big>

<ul>
<li><big>Performance is still one of our top priorities (time
estimate: 6 man
weeks) </big></li>
</ul>
<div style="margin-left: 40px;">a. We will collect and analyze
profiles for deployment process and
figure out potential improvements based on the analysis. (time
estimate: 3 man weeks)
<br>
We also plan to collect a set of profiles for
applications with
different characteristics. This
will help us to understand how different type of application deployment
behaves and then target the improvements for the most commonly used
application types.
<br>
<br>
b. Optimize redeployment performance especially for directory
deployment. (time estimate: 3 man weeks)
<br>
In the developer world, the most common
scenario is incremental
deployment: developer add components to the applications gradually and
redeploy the application after each change.
<br>
So it would be good to only update the part that's
changed
since last
deployment and not all of it. So one thing we will investigate is
whether we could compare the contents versus last deployment and only
update the contents as needed. There is also the possibility here to
act on "hints" from the IDE. We are talking with netbeans team to
see
whether NetBeans could make available to us about what has or has not
changed. <br>
It might be hard to just re-load one class,
but we could start with
looking at jsp files and deployment descriptor files. Both jsp
compilation and deployment descriptor loading are expensive.
<br>
<br>
</div>
<ul>
<li><big>Improve error messages (time estimate: 5 man weeks) </big></li>

</ul>
<div style="margin-left: 40px;"> a. Examine error handling
framework and make sure error is propagated
back to the user properly (2 man weeks)
<br>
i) examine various deployment clients
(jsr88/netbeans, admin gui, admin cli, autodeploy) and make sure in all
cases the status is reported to the user properly. <br>
ii) make sure the exceptions are chained
and propagated back properly and no information get lost. <br>
<br>

b. Improve the quality of error messages (3 man weeks)
<br>
i) users don't see stack trace
<br>
ii) for the most common use cases, improve
error message to be

more diagnostic so it can help users to figure things out themselves.
<br>
<br>
</div>
<ul>
<li><big>Support for integrating OpenESB with Glassfish (time
estimate: 3
man weeks)</big><br>
</li>
</ul>
<div style="margin-left: 40px;">
a. Provide deployment support for packaging/deploying JavaEE service
units as part of composite application. (2 man weeks)
<br>
<br>
b. Others (1 man week)
<br>
</div>
<br>
<ul>
<li><big>Provide a framework to support
non-JavaEE module type deployment (time estimate: TBD)</big> </li>
</ul>
<ul>
<li><big>Various bug fixes. (time estimate: TBD)</big> </li>
</ul>

<ul>
<li><big>Some of other things we will also be looking into (time
estimate: TBD)</big><small><big></big></small><br>
</li>
</ul>
<div style="margin-left: 40px;">
a. Handle file locking problem even
when it's code outside of appserver
that's is opening jar files (<a
href="https://glassfish.dev.java.net/issues/show_bug.cgi?id=539">Glassfish
issue 539</a>).<br>
<br>
b. Write a JSR88 sample to explain how to use JSR88 API. <br>
<br>
c. The enhancements filed in the issue tracker.

<br>
</div>
</body>
</html>


Old URL (read-only): http://wiki.glassfish.java.net/Wiki.jsp?page=GFv2DeploymentPlan
New Page: https://wikis.sun.com/display/glassfish/GFv2DeploymentPlan

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.