Hi Naci,
Thanks for your quick response to my question.
Let me explain my requirements a little more - I am not disputing that
runtime and server are required, it is a good separation. But I do see a
problem with the GenericServer implementation and serverdef extension.
Lets take an example of the serverdefinition extension point:
<extension point="org.eclipse.jst.server.generic.core.serverdefinition">
<serverdefinition id="com.foo.runtime.myRuntimeId"
definitionfile="myServerDef.serverdef">
</serverdefinition>
</extension>
The GenericServer server definition extension point uses the server runtime
id to point to a .serverdef file. As you've pointed out, the .serverdef file
defines properties and other configuration elements relating to both the
runtime and the server. For example, the serverdef file defines a start
configuration for starting the server.
I have 2 serverType defintions: one for a local server and one for a remote
server. Both of these server types are for the same runtime, the distinction
between them is that one is installed locally on the development machine,
and another is installed/running on a remote machine. So, to control both of
these types of server I need a different start (and stop etc.) configuration
in their associated .serverdef files. However, the .serverdef file is
retrieved using the runtime id, not the server type id, which means I cannot
use the same runtime for both server types. So I must currently have two
different runtimes defined, so that my local and remote server types can
have different serverdefs.
The problem with having a runtime for the local and a runtime for the remote
server types is that there is no difference between the runtimes, they are
the same runtime, the server instances just happen to be running locally or
running remotely - and I want to have a module that compiles against one
runtime, but can subsequently be deployed against either of these server
types (so I can deploy the module to an instance of the local server type,
or I can deploy the module remotely to an instance of the remote server
type). I do not want to have to change the runtime of the module in order to
deploy it to different server types, when in reality the server types are of
the same runtime type.
But, currently, because the serverdefinition is retrieved using the runtime
id, rather than the server type id, this is not possible. Logically, the
serverdef file represents the configuration of a server type and runtime
(tuple), therefore it should be associated with the serverType id and not
the runtime id.
As this is published API, what I'd like to suggest is this: a new extension
point (e.g. org.eclipse.jst.server.generic.core.serverdefinition2) whose id
is the serverType id, and modifications (or extensions of) the various
GenericServer classes that retrieve the ServerRuntime object.
thanks
David
-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Naci Dai
Sent: Wednesday, August 23, 2006 11:31 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Why is GenericServer serverdef tied to the
runtimerather than the server type?
David,
I cannot say I understand your question clearly: Are you saying that
server+runtime is needed or it is not needed. If I can understand your
needs further, I am sure we can define requirements to meet them.
In any case, generic server support and the core server adapters are
exactly the same when it comes to how they deal with servers and
runtime. A runtime is not smt you can run or deploy module to. It is a
description of the runtime environment (i.e. typically where the shared
software is installed etc.)
A server configuration is smt you can run, debug publish modules etc.
It needs to be associated with a runtime. It needs the runtime to get
libs, jars, etc. What is more, each server configuration is associated
with a particular set of modules, apps, etc. Only these applications
and modules will be deployed to that server when it is run.
Therefore, in this architecture runtimes and servers are needed and each
runtime must be associated with a runtime.
The generic Serverdef file is a simple reflection of the WTP server
architecture. It parameterizes the ımplementation classes for the
"servers" and "runtimes". It is better to look at as a metafile that
supports these impl classes. It contains two types of parameters:
servers and runtimes and bunch of definitions that are used by the
generic server & runtime classes. There is only one file for
runtime/servers tuples, because it is simpler. Just an implementation
issue.
Ofcourse (like all the other server adapters) You can define multiple
runtimes based on this template (i.e. different installations). Runtime
properties that correspond to each definition is persisted as a separate
instances with the workspace.
Also, when you define server configurations (i.e. "server" in wtp
terminology) for a particular runtime instance , these are persisted
separately in the workspace or if user chooses (i.e. store in CVS), with
the project itself.
Hi,
Can anyone tell me why the GenericServer server definition (.serverdef) is
tied to the server runtime rather than to the server?
The use case I have is this: A module is associated with a runtime. There
can be several different kinds of server (local, remote, clustered) - but
they have the same runtime i.e. they have the same capabilities, the same
classpath etc. It should be possible to target the module at the runtime,
and then deploy it to any of the server types (without having to change
the
runtime the module is targetted at).
I do not understand why, on the one hand the runtime and server type are
separate, but when using the GenericServer, the server definition is tied
back to the runtime, effectively requiring a 1:1 coupling between the
server
and the runtime.
It seems to me that this defeats the point of the server and runtime
separation. Would it be possible to consider enhancing the design to allow
for this (IMO) key use case?
thanks
David
-------------------------
David Black
Cape Clear Software
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
