meeting notes and documents discussed
diff --git a/development/meetingnotes/20041104.txt b/development/meetingnotes/20041104.txt index 4c6e33e..9bc30c1 100644 --- a/development/meetingnotes/20041104.txt +++ b/development/meetingnotes/20041104.txt
@@ -1,6 +1,10 @@ 20041104 Agenda - Discuss Jim and Tim's concept document. + Discuss Jim and Tim's concept document (work in progress) + see + modules_and_servers.html, and + web_tools_server_api_concepts.html + (both in /jst/components/server/development/miscdocuments/ ) Process for rolling out API changes.
diff --git a/development/miscdocuments/modules_and_servers.html b/development/miscdocuments/modules_and_servers.html new file mode 100644 index 0000000..d42b563 --- /dev/null +++ b/development/miscdocuments/modules_and_servers.html
@@ -0,0 +1,325 @@ +<!-- saved from url=(0022)http://internet.e-mail --> +<html> + +<head> +<meta http-equiv="Content-Language" content="en-us"> +<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +<meta name="ProgId" content="FrontPage.Editor.Document"> +<title>Modules and Servers</title> +</head> + +<body> + +<h1>WTP Server Tools API<br> +Modules and Servers</h1> +<p>Last modified Nov. 3, 2004</p> +<p>These design notes grew out of discussions between Jim des Rivieres and Tim +Deboer the week of Oct. 25-27. The question is how to think of the +"modules" as they appear in the Server Core API, and how best to allow +for flexible modules layouts in the workspace.</p> +<h2>Who owns the notion of module?</h2> +<p>A module consists of some content - typically some files in the workspace. +Each different module type will have its own rules for the structure and meaning +of its content. For example, a simple web module might consist of a simple tree +of HTML files. When the module is published to a server, these files will be +copied to the real server.</p> +<p>However, it's funny to think of the module as something that exists solely +for the purpose of being published. A module in the workspace should be viewed +as something rich and multi-faceted. Most of the interesting aspects of a module +will be left up to the parties that actually defines real modules. It's like the +difference between the notions of employee and person. An employee is a limited +notion suitable for the limited purposes of describing an organization or a +payroll; a person is a more general notion.</p> +<p>As discussed in the JST content, there needs to flexibility on how J2EE +modules get laid out in the workspace. The complexities include:</p> +<ol> + <li>Single or multiple modules per workspace project.</li> + <li>Files, like Java source code, that are ordinarily considered part of that + module's content, but not for the purposes of publishing to the server.</li> + <li>Modules with files residing in JAR archives rather than directly in the + file system.</li> + <li>J2EE parent-child relationships between modules that may or may not be + represented with directory containment.</li> +</ol> +<p>Given the high degree of variability (and current uncertainty) on the module +side, one effective strategy is to separate module-related concerns as much as +possible from the server-related concerns, and to place only minimal +requirements what the module side needs to be like.</p> +<p>In other words, the Server Core API should only attempt to capture a limited +notion of module-as-something-to-publish. (IPublishableModule would be a more +suggestive name than the current IModule.)</p> +<h2>What does a server need to know about a module?</h2> +<p>Here are the high-level API operations that involve both modules and servers:</p> +<ul> + <li>Associating a module with a server + <ul> + <li>Add a module to a server.</li> + <li>Remove a module from a server.</li> + <li>Obtain a list of modules associated with a server.</li> + </ul> + </li> + <li>Publishing a module to a server + <ul> + <li>A server publishes the content of one of its modules to the real + server.</li> + </ul> + </li> + <li>Monitoring sync of module contents + <ul> + <li>A server determines whether the content of one of its modules is in + sync.</li> + <li>A server registers interest in being notified of future changes to the + contents of one of its modules.</li> + </ul> + </li> +</ul> +<p>The first group of operations for managing associations between modules and +servers could, in principle, be done using module ids alone; the actual modules +content (or even the module's existence) need not enter into it; the +implementation of these operations can be entirely generic. In practice, there +are additional validation checks that would be server-type-specific. The add +operations is necessarily initiated by a client in possession of both a module +and a server.</p> +<p>The second group of operations for actual publishing a module's content +requires discovering and accessing that content. Several things to observe:</p> +<ul> + <li>The code that publishes a module is server-type-specific and can be + specialized for each particular module type that the server supports. E.g., + Tomcat-specific code for publishing an EJB module; JBoss-specific code for + publishing an EJB module.</li> + <li>The module's content can be presented to servers in a module-type-specific + way. E.g., a a simple static web module can look like a "virtual" + tree of HTML files; a database module could present its content as something + suitable for databases. (The current approach uses a tree of files for + everything.)</li> + <li>The module-type-specific scheme could also include inter-module + relationships where appropriate. E.g., parent-child relationships for J2EE + module types.</li> + <li>The module-type-specific scheme for presenting module content to servers + can build in support for various alternatives. For example, EJB module + content could be presented variously as a deployment descriptor plus + "virtual" files with standard names; or as a "virtual" + EAR file; or as a java.io.File path to an EAR file; or as a java.io.File + directory containing an unzipped EAR.</li> + <li>The modules contents are revealed to the server only for a limited-time + interaction. This means that the objects are short-lived. There is no + requirement for events to report changes to content <i>during</i> a publish + operation.</li> + <li>For modules that really are based on files in the workspace, the module + contents that get presented for publication need not betray that fact.</li> +</ul> +<p>The third group of operations, for monitoring sync of module contents, are +very much like the second.</p> +<ul> + <li>The module-type-specific scheme for presenting module content to servers + could include a timestamp. If the server maintains an internal record of + what is on the real server along with the timestamp, the server can + determine whether the module contents need to be republished.</li> + <li>For module-type-specific schemes involving files, each file could carry + timestamp information. For some server types, this would allow just the + subset of changed files to be recopied to the server in some cases.</li> + <li>When the files of a module are stored in the workspace (or somewhere else + that can be tightly monitored), it is also practical to report change events + affecting a module to interested servers, instead of having the servers poll + for such changes.</li> +</ul> +<p>Here's an API sketch (it differs in a number of way from what is currently +released):</p> +<ul> + <li>Extension point for defining a new module type. + <ul> + <li>Define module type id, module type name.</li> + <li>Provide interface for accessing publishable content.</li> + </ul> + </li> + <li>Extension point for defining a new server type. + <ul> + <li>Define server type id, server type name.</li> + <li>Give list of supported module types.</li> + <li>Provide mechanism for publishing supported module types to real + server. (Server-type-specific and module-type-specific, but ignorant of + how and where module's content is actually stored.) </li> + <li>Provide mechanism for launching and talking to real server.</li> + </ul> + </li> + <li>Extension point for defining a new module factory. + <ul> + <li>Supply module factory id, module factory name.</li> + <li>Give list of module types that this factory is capable of creating.</li> + <li>Provide mechanism for creating/discovering module instances, and for + tracking its module instances.</li> + <li>Provide mechanism for providing publishable module content for its + module instances. (Server-type-independent, module-type-specific, and + cognizant of how and where a module's publishable content is actually + stored.)</li> + <li>Provide mechanism, where feasible, for notifying a server of changes + affecting publishable module content for its module instances.</li> + </ul> + </li> + <li>Module handle represent a unique module instance. + <ul> + <li>Module has a unique module id.</li> + <li>Module has a module type (represented by a module type id - module + types might not exist)</li> + <li>Module has a module factory (represented by a module factory id + - module factory might not exist). This is the module factory + responsible for module instance.</li> + <li>Module is just a handle (passive key). Module might not exist.</li> + <li>Used in server API for adding/removing a module to/from a server; for + obtaining a list of modules associated with a server; for obtaining a + list of modules associated with a module factory.</li> + <li>Interface is client API; clients do not implement.</li> + <li>Implementation is internal.</li> + <li> + <pre>public interface IModuleHandle { + public String getId(); + public String getModuleTypeId(); + public String getModuleFactoryId(); + } +[somewhere on SPI where it is available to servers and module factories] + public IModuleHandle createModuleHandle(String moduleId, String moduleTypeId, String moduleFactoryId);</pre> + </li> + </ul> + </li> + <li>Publishable module used by server for limited-purpose of publishing a + module's contents. + <ul> + <li>"Marker" interface - no methods.</li> + <li>Each module type defines its own specialized public subinterface for + obtaining the module's content.</li> + <li>Subinterface is API for parties supplying module factories and server + delegates (both SPI side)</li> + <li>Subinterface can spec whatever contract works for making the module's + publishable content available to any type of server that wishes to + support that module type.</li> + <li>Module-type-specific subinterface is used by server delegate for + publishing purposes.</li> + <li>Module-type-specific subinterface is implemented differently by each + module factory that can create instances of the module type.</li> + <li>These object only needs to be useful for the limited duration of + publishing (or resyncing).</li> + <li>The method should not be available to other parties.</li> + </ul> + </li> + <ul> + <li> + <pre>[somewhere available to server delegate (only)] + public IPublishableModule resolveForPublish(IModuleHandle moduleHandle); +public interface IPublishableModule {}</pre> + </li> + </ul> + <li>Module factories are things that create and modules. + <ul> + <li>Client API provides global list of module factories.</li> + <li>Each module factory can support any number of different module types.</li> + <li>Each module factory is responsible for creating and managing a global, + persistent, list of its module instances. (It would be even better if a + factory could keep .)</li> + <li>Module factory client API.</li> + </ul> + <ul> + <li> + <pre>ServerCore + public IModuleFactory[] getModuleFactories(); +public interface IModuleFactory { + public String getId(); + public supportsModuleType(IModuleType moduleType); + public IModuleHandle[] getModules(); + public IModuleHandle createModule(String moduleId, String moduleTypeId, Object data); + public void deleteModule(IModuleHandle); + public void addModuleFactoryListener(IModuleFactoryListener); + public void removeModuleFactoryListener(IModuleFactoryListener); +}</pre> + </li> + </ul> + <ul> + <li>Module factory SPI.</li> + </ul> + </li> + <ul> + <li> + <pre>public abstract class AbstractModuleFactoryDelegate { + public AbstractModuleFactoryDelegate(IModuleFactory factory) {...} + public final IModuleFactory getFactory() {...} + public abstract IModuleHandle[] getModules(); + public abstract IModuleHandle createModule(String moduleId, String moduleTypeId, Object data); + public abstract deleteModule(IModuleHandle); + public abstract IPublishableModule resolveForPublish(IModuleHandle moduleHandle); +}</pre> + </li> + </ul> + <li>Example + <ul> + <li>Declaration of module type: simple static web</li> + <li>Include module-type-specific subinterface for publishing module + expressed as a tree of files with timestamps.</li> + <li> + <pre>public interface IWebModule extends IPublishableModule { + public interface IModuleResource { + public String getName(); + public IPath getModuleRelativePath(); + } + public interface IModuleFile extends IModuleResource { + public long getTimeStamp(); + public InputStream getContents(); + } + public interface IModuleFolder extends IModuleResource { + public IModuleResource[] members(); + } + public IModuleResource[] members(); +}</pre> + </li> + <li>IWebModule is used in servers that support simple static web modules + <ul> + <li>Example server type: simple web server</li> + <li>Server delegate uses resolveForPublish(moduleHandle) to get an + IPublishableModule</li> + <li>Downcasts IPublishableModule to IWebModule</li> + <li>Calls methods on IWebModule to discover files comprising content.</li> + </ul> + </li> + <li>IWebModule is implemented by module factories that support simple + static web modules + <ul> + <li>Example module factory 1: static web modules kept in workspace + folders + <ul> + <li>Publishable content lives in workspace</li> + <li>Each module has a root folder.</li> + <li>Files and folders under root folder are isomorphic to + IWebModule layout. + <ul> + <li>All files and folders under root folder are publishable.</li> + <li>File and folder names are as published.</li> + <li>File contents and timestamps are as published.</li> + </ul> + </li> + <li>"data" object passed to IModuleFactory.createModule + is IContainer for module's root folder.</li> + <li>Factory maintains global list of modules in private plug-in + state.</li> + </ul> + </li> + <li>Example module factory 2: static web modules kept in zip file + <ul> + <li>Publishable content lives in zip files outside workspace</li> + <li>Each module has a single zip file.</li> + <li>"data" object passed to IModuleFactory.createModule + is java.io.File (or IPath) for module's zip file.</li> + <li>Files and folders within zip file are isomorphic to IWebModule + layout.</li> + <li>Factory maintains global list of its modules in private + plug-in state.</li> + </ul> + </li> + </ul> + </li> + </ul> + </li> +</ul> +<p> </p> + +</body> + +</html>
diff --git a/development/miscdocuments/web_tools_server_api_concepts.html b/development/miscdocuments/web_tools_server_api_concepts.html new file mode 100644 index 0000000..8b4b23f --- /dev/null +++ b/development/miscdocuments/web_tools_server_api_concepts.html
@@ -0,0 +1,260 @@ +<html> + +<head> +<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +<meta name="ProgId" content="FrontPage.Editor.Document"> +<title>API Concepts and Roles</title> +</head> + +<body> + +<h1>WTP Server Tools<br> +API Concepts and Roles</h1> +<p>Last modified Nov. 2, 2004</p> +<p>[<i>This document is a work in progress. The document is an attempt to +capture the key concepts required for understanding and working with the WTP +Server Core API. Note that the concepts may differ subtly from what is currently +found in the currently released <a href="http://dev.eclipse.org/viewcvs/index.cgi/wst/components/server/plugins/org.eclipse.wst.server.core/?cvsroot=WebTools_Project">org.eclipse.wst.server.core +plug-in</a>. Once this document is finalized, our intent is to bring the code +and specs into line with this document.]</i></p> +<p>The key concepts for understanding the API (and SPI) are servers and modules. +The notions of server runtimes and server configurations play an important, but +secondary role.</p> +<p>Not surprisingly, the notion of <b>server</b> is central in the web tools +server infrastructure. In this context we are to understand that the server is a +web server of some ilk (a more exact definition is not required for our +purposes). From a tool-centric point of view, a server is something that the +developer is writing "content" for. (In a sense, the server exists, +but lacks useful content. The development task is to provide that content.) The +content can include anything from simple, static HTML web pages to complex, +highly dynamic web applications. In the course of writing and debugging this +content, they will want to test their content on a web server, to see how it +gets served up. For this they will need to launch a server process running on +some host machine (often the local host on which the Eclipse IDE is running), or +attach to a server that's already running. And we must arrange that the newly +developed content sitting in the developer's workspace ends up in a location and +format that a running server can use for its serving purposes.</p> +<p>(The server objects in the API are in fact intermediary "proxy" +objects that mediate between the tools running in Eclipse and the real server. A +server proxy object has a somewhat independent life from that of a real server. +In cases where the server process must be launched, the proxy object exists in +advance of the server process, and lives past the termination of the server +process. The same server proxy may be serially reused to relaunch server +processes. In cases where we are connecting to a server process running on a +remote host, the server process may well outlive the proxy.)</p> +<p>Servers have a <b>server runtime</b>. The server runtime corresponds to the +installed code base for the server. The main role played by the server runtime +is in identifying code libraries to compile or build against. In the case of +local servers, the server runtime may play a secondary role of being used to +launch the server for testing. Having the server runtimes identified as an +entity separate from the server itself facilitates sharing server runtimes +between several servers.</p> +<p>Servers have an optional <b>server configuration</b>. The server +configuration is information used to configure a running server. Simple types of +servers might not require any configuration, whereas full-featured web server +have an extensive set of parameters for adjusting the server's behavior. Even +though server configuration information usually takes the form of one or more +files, configuration information is treated separately from actual content. +Actual web content can be deployed on different servers without change, whereas +server configuration information is usually highly dependent on the particulars +of the server. Having the server configuration identified as an entity separate +from the server itself facilitates switching an existing server between +configurations, and sharing server configurations between several servers (e.g., +a local test server and a remote server running on another host).</p> +<p>The web content that is developed for a web server comes in <b>modules</b>. A +module usually consists of a tree of files; a static HTML web is one simple +example. Different types of modules consist of possibly constrained arrangements +files of certain file types. The files making up a module under development +reside in the Eclipse workspace. In order for a server to use access the content +within a module, the module in the workspace must be <b>published </b>to the +server (we use the term <i>publish</i> rather than <i>deploy</i> which is +overused in J2EE). The module is the unit of content that is published to a +server. In the case of J2EE servers, the notion of module aligns with the J2EE +notion of a module (a server concept). But that needn't be the case; some +types of servers, such as a simple HTTP server, don't have a notion of module. +Either way, publishing a module to the server entails whatever it takes to get +the publishable content from the workspace to the server in a form that the +server can access it. Different types of server runtimes are capable of support +various module types.</p> +<p>At any given time, the developer may be working with any number of servers. +Each server has a server configuration and a set of modules. From the complete +set of modules in the workspace, any particular server may see only a subset, +although it is also common for all servers to see all available modules. After +the developer makes changes to the modules in the workspace and now wants to +test their modification, they republish the modules to the server. Depending on +the type of server, republishing a module may entail stopping and restarting the +server.</p> +<p>Some types of modules can have other modules as children. The standard +example of this is a J2EE Enterprise Application (EA) module, whose children are +simple J2EE modules like Enterprise Java Beans and Web Applications. The +parent-child relationship is weak: two parent modules can share the same child +module, and the same child can be parented by several modules (on the same or on +different servers). The file trees for modules are normally mutually disjoint. +Module containment is not reflected by any sort of directory nesting. Parent and +child modules map to non-overlapping file trees.</p> +<p>Modules reside in the workspace. The typical arrangement is that each module +has its own project, termed a <b>module project</b>. The module content usually +corresponds to a particular folder within a project rather than the root of the +project; this allows the project to contain other files (e.g., .project, .classpath, +source code) that are not considered part of the module content proper. Each +different type of module has its own rules for how the content files within it +are laid out. For instance, a J2EE web module has the same structure as an +unzipped WAR file. (Note that the module structure rules are largely implicit +and not reflected directly in the APIs.) It is possible for a project to +contains more than one module (although this arrangement is less common, and not +as well supported).</p> +<p>During development, projects containing modules can be <b>targeted</b> to a +particular server runtime. Targeting allows the IDE to set up various +development time properties of the project (such as the backbone of the Java +build path) appropriately. The most common scenario is where the project is +targeted to the server runtime for the server to which the module is being +published. However, it is also possible to target one server runtime (e.g., a +generic J2EE 1.3 server runtime) while publishing to a server with a different +server runtime (e.g., a Tomcat v5.0 server). Targeting a project to a particular +server runtime typically establishes the Java build classpath of the project to +include the libraries containing the Java APIs for that server runtime (e.g., +the appropriate J2EE class libraries). The Java build classpath also needs to +reflect inter-module dependencies; for J2EE module types, the appropriate +entries are typically derived from the module's manifest.</p> +<p>A <b>server project</b> is a project used to hold serialized server (server +runtime, server configuration) instances. The project is tagged with a special +Eclipse server nature. The main reason behind server projects was as an +efficient means of making these serialized files visible in the resource +navigator and monitoring changes to them.</p> +<p>The main goals of the Server Core client APIs are to allow clients to create, +configure, and launch instances of particular server types. Due to differences +in the behavior (and APIs) of different server types, a client must generally be +knowledgeable of rules for a particular server type. Clients that have no +knowledge of any specific server type are limited to doing things like starting, +stopping, and relaunching existing servers. In other words, the clients APIs are +generally server-type-specific, rather than sever-type-generic.</p> +<p>The web tools server architecture allows for an open-ended set of server +types, server runtime types, server configuration types, and module types. New +types are declared via extension points in the Server Core plug-in (org.eclipse.wtp.server.core). +Server types are declared by the serverTypes extension point; server runtime +types, by runtimeTypes; server configuration types, by serverConfigurationTypes; +and module types, by moduleKinds. (Additional extension points are discussed +below.) Associated with these extension points are code APIs designed for use by +clients contributing to the Server Core extension points; these are more +correctly called SPIs (service provider interfaces) to distinguish them from the +code designed to be used by other clients (which we refer to here as client +APIs).</p> +<p>Many of the extension points provide for a dynamic code component in addition +to the static information supplied in the extension declaration. These are +termed <i>delegates</i>. For instance, all communication with the running server +is handled by a <b>server delegate</b> contributed via the server type extension +point. Clients generally deal directly with a layer of objects exposed by the +API expressly for client use. In the case of server, clients deal with an +IServer. IServer has a fixed, hidden implementation (the internal class Server), +which hangs on to a lazily-created server delegate of type IServerDelegate. The +IServerDelegate implementation is a server-type-specific object. The more +interesting IServer methods (e.g., getServerState()) are handled by the +delegate. There are also getDelegate() methods that bridge API to SPI, allowing +clients to call methods on the delegate directly. Service providers may also +choose to expose their delegate implementation as API. This allows, for example, +the provider of a server type to offer additional API that is +server-type-specific.</p> +<p>A <b>module factory</b> is responsible for creating modules. There can be any +number of registered module factories, declared via the +org.eclipse.wtp.server.core.moduleFactory extension point. A module factory may +create one or more types of modules (also declared in the extension point). The +module factory API does not prescribe a way to create modules; it does, however, +provide methods for retrieving extant modules that it was responsible for +creating (IModuleFactoryDelegate.getModules() and +IModuleFactoryDelegate.getModule(String memento)).</p> +<p>A <b>publish manager</b> is responsible for deciding whether a file resource +will be published or not (note: publishing includes file deletions as well as +file creations and modifications). Publish managers are declared via the +org.eclipse.wtp.server.core.publish extension point. +ServerCore.getPublishManagers() returns list of know publish managers. There are +two build-in headless publish managers. The Full Publish Manager is dumb, and +publishes all of the module's resource from workspace to server. The Smart +Publish Manager only publishes module resources that have been created, changed, +or deleted in the workspace, or ones that have been changed (somehow) on the +server. A publish operation initiated by IServer.publish(IProgressMonitor +monitor) uses the system-wide default publish manager, which defaults to the +Smart Publish Manager. (There's also a Visual Publish Manager that lets the user +pick and choose which files to publish.)</p> +<p>A <b>publisher</b> (IPublisher) is an object that actually publishes the file +of a particular module to a particular server. Each server type implements its +own publishers. On a particular occasion, the IServerDelegate.getPublisher(List +parents, IModule module) returns the publisher to use to publish the files of +the given module. IPublisher.publish(IModuleResource[] resource, +IProgressMonitor monitor) and IPublisher.delete(IRemoteResource[] resource, +IProgressMonitor monitor) do the heavy lifting.</p> +<p>The client API exposes:</p> +<ul> + <li>Server runtime types as IRuntimeType. ServerCore.getRuntimeTypes() returns + all known server runtime types.</li> + <li>Server types as IServerType. ServerCore.getServerTypes() returns all known + server types. </li> + <li>Server configuration types as IServerConfigurationType. + ServerCore.getServerConfigurationTypes() returns all known server + configuration types.</li> + <li>Module types as IModuleKind. ServerCore.getModuleKinds() returns all known + module kinds.</li> +</ul> +<p>The type-level relationships are:</p> +<ul> + <li>a server type has a server runtime type; this is the type of server + runtime required to run the server; exposed as IServerType.getRuntimeType()</li> + <li>a server type has an optional server configuration type; this is the type + of server configuration required to configure the server; exposed as + IServerType.getServerConfigurationType()</li> + <li>a server runtime type supports 0 or more module types; exposed as + IRuntimeType.getModuleTypes()</li> +</ul> +<p>The API exposes server runtime instances as IRuntime. +ServerCore.getResourceManager().getRuntimes() returns all known server runtime +instances. Server runtime instances are created (only) from server runtime types +by IRuntimeType.createRuntime(String id), which returns an IRuntimeWorkingCopy. +Any number of aspects of the server runtime instance (including location in the +file system) can be established or adjusted from their defaults. When editing is +complete, IRuntimeWorkingCopy.save(IProgressMonitor monitor) creates, registers, +returns a server runtime instance (IRuntime) capturing the desired settings (the +working copy is disposed of).</p> +<p>The API exposes server configuration instances as IServerConfiguration. +ServerCore.getResourceManager().getServerConfigurations() returns all known +server configuration instances. Server configuration instances are created +(only) from server types by +IServerConfigurationType.createServerConfiguration(String id, IFile file, +IProgressMonitor monitor) or IServerConfigurationType.importFromPath(String id, +IFile file, IPath path, IProgressMonitor monitor) or +IServerConfigurationType.importFromRuntime(String id, IFile file, IRuntime +runtime, IProgressMonitor monitor). The file parameter is used to control where +the server configuration instance is serialized. All 3 return an +IServerConfigurationWorkingCopy. (There are no aspects of the server +configuration instance to adjust.) +IServerConfigurationWorkingCopy.save(IProgressMonitor monitor) creates, +registers, returns a server configuration instance (IServerConfiguration) +capturing the desired settings (the working copy is disposed of). </p> +<p>The API exposes server instances as IServer. +ServerCore.getResourceManager().getServers() returns all known server instances. +Server instances are created (only) from server types by +IServerType.createServer(String id, IFile file, IRuntime runtime, +IProgressMonitor monitor) or IServerType.createServer(String id, IFile file, +IRuntime runtime, IProgressMonitor monitor). The file parameter is used to +control where the server instance is serialized. Both return an +IServerWorkingCopy. Any number of aspects of the server instance (host name, +server runtime, server configuration, modules, ...) can be established or +adjusted from their defaults. When editing is complete, +IServerWorkingCopy.save(IProgressMonitor monitor) creates, registers, returns a +server instance (IServer) capturing the desired settings (the working copy is +disposed of). </p> +<p>The instance-level relationship between servers and server runtimes and +server configurations is exposed at the API: for a given server, +IServer.getRuntime() returns the server runtime (IRuntime), +IServer.getServerConfiguration() returns the server configuration (IServerConfiguration).</p> +<p>IServer.start(String mode, IProgressMonitor monitor), stop(), and +restart(String mode) are used to start, stop, and restart a server, respectively +(there are also synchronous methods for starting and stopping). The predicates +IServer.canStart(String mode), canRestart(String mode), and canStop() indicate +whether the server is receptive to being controlled. IServer.getServerState() +can be used to query the overall state of the server (one of starting, started, +stopping, stopped, or unknown), and IServer.getModuleState(IModule module) can +be used to query the state of any of its modules.</p> + +</body> + +</html>