GlassfishV3Notes
Ramblings about the V3 Server module architecture and implementation
These are (very) rough notes I've been making while building a prototype of the V3 Common module described below. It currently implements the existing common server API and I'm bashing out the runtime node structure as well as server API design and placement (within architecture / lookup)
Architectural Runtime Requirements
- V3 server supports multiple application types through containers. Any given V3 install could support a combination of containers such as Web, JavaEE, Ruby, PHP, Phobos, etc.
- Plugins must be loadable in all appropriate NetBeans distribution -- e.g Ruby IDE should be able load a plugin (group of modules), as should PHP IDE, JavaEE IDE, or full NetBeans distribution, or any combination thereof.
- Update center requirements suggest a specific organization.
Module layout
- V3 Common module (may have own depending modules, ala appsrv-bridge or appsrv-common for the V2 plugin)
- Type specific V3 module to manage processes and data of specific interest to that type. e.g.
- V3 JavaEE module to handle j2eeserver requirements
- V3 Ruby module to handle RailsProject requirements
- V3 PHP module to handle PHP requirements (this one probably post 6.1).
V3 Common Server Module
- Implement ServerWizardProvider & Add correct wizard pages.
- Implement ServerInstanceProvider to iterate installed ServerInstances.
- Implement persistence for server instances (fields:)
- Name of Server Instance.
- Home folder of server instance.
- (Installed capabilities?)
- Check server for supported API's (JRuby, Web, JavaEE, etc.), add as needed (should this be lazy?)
- For each supported API, create API instance by finding instance element in layer. If element is not found, should not be created (e.g. V3 supporting JavaEE, but JavaEE module not installed).
- Allows V3 JavaEE module to make JavaEE API instance accessible via V3 Common's ServerInstance Lookup only when both (a) V3 instance has JavaEE module enabled and (b) V3 JavaEE module is enabled. Ditto for all other Server API's (PHP, Ruby, etc.)
- Implement ServerInstance interface
- Creates server instance node.
- Server Instance Node Actions
- Start Server (I think server should always start in JDK debug mode. Scripting debugging mode is probably doable on demand w/o server restart -- e.g. JRuby Container is started w/ Debug script on cmd line preceding rails/server script).
- Stop Server
- Restart Server
- Refresh (child nodes)
- Remove (instance)
- Customize (pops up instance customizer dialog - admin passwords, JavaEE jars & doc, one page per module container type found on install?)
- Properties (May be obsolete - For JavaEE, opens up browsable tree of customizer pages (above action) for each server instance)
- Running status indicated by badge and tooltip.
- ?? Provide Status action that merely displays tooltip w/ possible additional detail?
- Manages children of server instance node.
- Uses "lookup_applications" REST API command to determine application nodes (all types).
- ?? Any reason to filter types that are deployed but not supported by attached IDE? (e.g. Show web apps in Ruby IDE or not?) Probably not. Rare case anyway.
- Applications node needed? Maybe not, migrate actions to Server Instance node in that case.
- Applications Node Actions
- Refresh (child nodes - the deployed applications - sort by type)
- Deploy Directory... (sends deploy command to server - must be running)
- Application Nodes should have badge or own icon indicating type.
- Per-Application Node Actions
- Open in Browser (all app types - implement in V3 Common)
- Undeploy (all app types - implement in V3 Common)
- Application Node Children, if any, implement in V3 submodule of appropriate type (Ruby, JavaEE).
- e.g. Ear nodes show member modules as child nodes.
- How exactly is this implemented?
RailsProject
RailsProject will need to find Ruby capable servers and either manage them directly or manage them via the common server api.
We could have GEM embedded servers such as Mongrel, WebBrick managed by code within RailsProject that exposed those servers via Common Server API - it'd be less of a move from where things are now.
Requirements
- Find Server Instance (Create Project, Open Project, Change Server on Project)
Options
A. Iterate RubyServerInstanceProviders, and iterate available Ruby Instances registered therein.
B. Iterate ServerInstanceProviders, query the Lookup in the ServerInstance for the RubyServerInstance API. ServerInstance will need getLookup() method (or just lookup(Class<?> ...) method)
Implementation
Common Server API can implement
- List<RubyServerInstance> getRubyServerInstances()
- RubyServerInstance findRubyServerInstance(String serverInstanceId)
to centralize choice of either A or B and make usage easy on users (RailsProject)
RubyServerInstance actions (called from RailsProject popup menu)
- Start Server
- Stop Server
- Deploy Directory (Deploy Project?)
- Run Project / Controller?
- Debug Project
