I think there's a lot of history there and that we could do with a
good cleanup. In particular I think the Launcher version should
disappear all together. Also getApplicationDirectory is only there to
support something in the Spring container and can probably be
replaced as well. I've been trying to clean this up for a while and
there are quite a few zombie methods (that throw UnsupportedOperation).
Rather than a client/server distinction though, my thinking here has
been that the info would apply to an installation environment (such
as "standalone" for "installed on disk" and "webapp" for "contained
in a war"). Each environment would support client, server and other
usage patterns. For example, a webapp may be a server application for
users but to SCA it may be a pure client for business services. Or a
client application may offer addressable services that are invoked
when it is connected (via some async protocol).
The approach I took was to have a high level abstraction in
RuntimeInfo for things that applied to every environment, with
specializations for each installation environment for things that
applied just to them. So, for example, every environment would
support a baseURL for its installation for locating installation
resources but it should not assume that mapped to a local directory;
however, in the standlalone environment getProfileDirectory or
getInstallDirectory would definitely map to local files.
--
Jeremy
On Jan 20, 2007, at 12:25 AM, Meeraj Kunnumpurath wrote:
Hi,
I have been looking at adding runtime id to RuntimeInfo. I think there
may be some scope for refactoring the current classes and interfaces
used for realising runtime info. The core abstraction is the
RuntimeInfo
interface in host-api with a specialized interface
StandaloneRuntimeInfo
in standalone-host-api. The implementations include Standalone,
Launcher
and Web runtime infos in addition to some of the mock ones used in
testing. Some of the methods defined in the RuntimeInfo interface
is not
supported by the launcher and webapp runtime infos. Also, some of the
operations in the core abstractions like getInstallDirectory,
getBaseUrl, getApplicationDirectory can be refined further, I guess.
I think there are two broad categories of runtime info, client runtime
infos and server runtime infos. The server ones include any runtime
that
stays up running and participate in a standalone or federated logical
assembly. These will include webapp, standalone tuscany server etc.
Properties like domain, runtime id etc are relavant to them. However,
for client runtimes like launcher that runs a specific application and
exits, some of these properties may not be relavant. However, there
may
be common abstractions like profiles etc that are relavant for both
client and server runtimes.
I am planning to do some work around this area in conjunction with the
stuff I am doing on federation and discovery. It would be great to
know
if others have any thoughts on refining the runtime info abstractions.
Many thanks
Meeraj
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
