| Feature-ID |
Desired Improvement |
Priority |
Comments |
Issue Link |
Eng Response |
| CoreInfra-000 |
Scale a cluster of application server instances to 100. |
P1 |
Admin server should be certified with large cluster sizes. Note, this requirement applies to a SCALABLE cluster (single point of management/deployment) and not an HA cluster. |
4357 |
Yes for 50. Stretch goal 75. Need to define # of clusters in the domain and the perf criteria for startup, etc. Also, what is the expectation from HA side? We should have these two numbers in synch. |
| CoreInfra-001 |
Removed |
|
|
|
N/A |
| CoreInfra-002 |
Provide a way to fully customize the domain creation process. |
P3 |
Allow user code to be run during it. If possible create a user interface to do this. This is the extension of GlassFish V2 Profiles, where only domain.xml is customizable, using style sheets. |
|
No |
| CoreInfra-003 |
Provide admin server High Availability. |
P2 |
It should be possible to create a configuration where all configuration changes are saved redundantly. Introduction of primary-secondary admin server is acceptable. The idea is an admin server fails over to another incarnation of it automatically. |
4359 |
Yes. Many customers requested for this feature. This is probably a P2. |
| CoreInfra-004 |
Provide role based access control for administration. |
P1 |
Fine grained access control and configurable roles. Visual cues should be given through the administration console (eg: only show manageable items based on role/rights). |
4361 |
Yes. |
| CoreInfra-005 |
Multi-homing Readiness. |
P2 |
It should be possible to provide one configuration hook that configures the entire server to listen on a given network interface. This should be thoroughly tested. It is required for a number of cases where deployments occur with private and public interfaces on the same hosts. This is a problem for many users on the GlassFish users alias. |
4362 |
Yes. |
| CoreInfra-006 |
Provide an admin interface for all of the configuration files. |
P1 |
An API for updating domain.xml is required by Sailfin, potentially other products as well. Extending API configuration to the remaining configuration files would be beneficial (P3) |
4365 |
No. Stretch goal for default web.xml. |
| CoreInfra-007 |
Improve the Reliability of status determination of the server instances. |
P1 |
In an enterprise deployment, there are cases where the status is determined incorrectly. |
4366 |
Yes. |
| CoreInfra-008 |
Moved to HA-4/HA-5 |
- |
- |
- |
N/A |
| CoreInfra-009 |
Make the product firewall-friendly. |
P1 |
In other words, remove use of RMI from infrastructure. Consider using Grizzly in Node Agent. This enables a configuration where admin server is deployed inside firewall and application server nodes are available outside. Likely required to support HA-4/HA-5 . |
4367 |
Yes for removing RMI connector. |
| CoreInfra-010 |
Moved to DEVEX-11 |
- |
- |
4369 |
Yes. |
| CoreInfra-011 |
Provide a way to do post-deployment configuration of applications. |
P1 |
This may sound like building IDE, but this is essential, because we don't have a concept of deploying the application's configuration today. For example, a user just wants to stop the application, add a security role mapping for another principal that was just created. This requires application redeployment today, which is a heavy-weight operation. The modus operandi should be: 1. Stop the Application. 2. Change the Configuration. 3. Start the Application. This assumes that all the deployment descriptors are available post deployment. (The annotations are processed and they don't change). This is a must for changing the environment parameters used by web applications. Currently, there is no way to do this. Think of it as an override of what is available in standard deployment descriptors (e.g. web.xml). Much has been said about how unsatisfied users are , with our treatment of this problem. Also a community request . |
4371 |
Partial yes. Will take this up step-by-step. The original deployment descriptors need to be saved. Impact on Application versioning needs to be thought through. |
| CoreInfra-012 |
Applications server needs a documented, supported, safe way to back up domain in a live system |
P2 |
|
|
Stretch goal. |
| CoreInfra-013 |
Interface with Operating Platforms better. |
P2 |
This includes the system-tray icons, platform services,showing the server.log from desktops, etc. Ease of use requirement. |
|
Will address some of this in installer. |
| CoreInfra-014 |
Provide the so-called offline support for configuration management. It should be possible to programmatically modify the configuration of the server without having to start the domain administration server. This is particularly useful from the update-center perspective. |
P3 |
This notion might change if we made it explicit that the admin server need not be a J2EE process. The admin server, for reasons of reliability, startup time and "footprint" ought to be a bare-bones MBeanServer which exposes the configuration. Making this possible would mean that it could be brought up in any process. The key point is that the so-called "offline" mode could then use the same interfaces; a client would bring up the admin server in its own JVM, then simply operate on it as if it were remote. Much more powerful, and one code path to implement. |
|
Stretch goal. |
| CoreInfra-015 |
From an architectural perspective, there should be no limit to the number of instances (standalone or part of a cluster) a user can manage through a single user interface. This should be tested to 150 instances. |
P1 |
Large deployments are a primary goal of GlassFish V3. Customers do not want to log in to multiple admin consoles to manage a large deployment. For example, which console owns "instances 173"? This is related to CoreInfra-000, but requires testing to a higher number of total instances. |
|
Quality team needs to look at this. Same as CoreInfra-000. |
| CoreInfra-016 |
Support for multiple versions of an application running simultaneously |
P1 |
Simplifies application upgrades and a Dev/Test/QA/Production scenario on same instance. Community request (here ). (here ) (here ) (Sailfin Requirement Deploy-009 ) |
|
Container teams needs to review this. |
| CoreInfra-014 |
It should be possible to version the backed up images and their effective restoration. |
P3 |
Would add to ease of use of the application server. Currently external version control systems can be used so a solution exists, albeit less than ideal. |
|
Stretch goal. |
| CoreInfra-017 |
Configuration Extensibility |
P1 |
This is the ability to extend domain.xml to add any additional component configuration. Want this at a cluster level and instance level. While this is a SailFin requirement, it is generally applicable for modules that are (or become) a core part of the GlassFish. |
|
Yes. |
| CoreInfra-018 |
Ability to to add a container at the cluster level |
P2 |
The current addon support for cluster profile is very limited. Assuming there will be an equivalent mechanism in V3 for addons, we need the extension to be at the cluster level. Hooks for module developers. |
4191 |
Yes. |
| CoreInfra-019 |
Changing log rotation settings should not require a server reboot |
P2 |
Scheduler based log rotation requires a server restart. |
|
Partial yes. Dynamic reconfiguration infrastructure will be in place. We container team needs to look at this. |
| CoreInfra-020 |
Delegated administration |
P3 |
Enable application server administrators to delegate a subset of tasks to other users or groups. Useful in an IT, outsourced or hosting environment. |
|
No. |
| CoreInfra-021 |
Improved and light-weight provisioning that's built-in |
P2 |
The V2-way of creating clusters and instances across machines requires every machine (Box, as enterprises call them, lovingly  ) to have the full installation of a given release of GlassFish. It would be more than desirable if this requirement is hugely relaxed such that it requires a very light-weight process to be started on the box and the required bits are downloaded from the admin-server. There are interesting issues to solve here, but this will make the install and user experience of enterprise GlassFish deployment very favorable. |
4372 |
Yes. |
