You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Meeraj Kunnumpurath <m....@hotmail.co.uk> on 2006/12/27 01:02:31 UTC
Standalone server
Hi,
I have added server.start and server.shutdown modules in standalone to run
an instance of tuscany as a server. This is an extension of the existing
launcher. Rather tha running the specified application on the cli and
exiting, the server stays up running and listens on a JMX port for shutdown
requests. It boots up the standalone runtime as the launcher, however,
doesn't deploy any app scdls. I would assume the runtime will use something
like a directory scanner to search a specified location for the applications
to be deployed and deploy them using the deployment API.
Both server.start and server.shutdown produces executable JAR files.
Currently all configurable parameters are specified as system properties.
These include,
1. Install directory
2. Boot directory
3. System SCDL path
All these use the existing system props and defaults as with the launcher.
The default JMX remote connector port is 1099. This may be overridden using
the system property tuscany.adminPort.
Ta
Meeraj
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Standalone server
Posted by Jeremy Boynes <jb...@apache.org>.
On Dec 27, 2006, at 4:56 PM, Meeraj Kunnumpurath wrote:
> Hi,
>
> I have updated standalone server to support multiple runtimes. Now,
> when the server is started, it doesn't start any runtime. However,
> the server has a management op called startRuntime(String bootPath)
> to start a runtime. Boot path for the runtime is resolved relative
> to the installation path. It is expected to have a file called
> runtime.properties in a directory named etc.
>
> The file contains the JMX domain name under which the runtime
> instance is registered. Once started the runtime instance is
> available for management. Only management ops currently available
> are initialize and destroy.
>
> This allows any number of runtimes to be started within a server
> environment.
>
Good stuff.
This got me thinking about registering Components with JMX so that
they too can be managed.
One thought was about generating an ObjectName for each component
that we know will be unique whilst sticking with some of the
recommendations for naming here:
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/
best-practices.jsp
I think allowing the user to determine the JMX domain name makes
sense - that allows them to know for sure which TuscanyRuntime they
are dealing with. If we go this way, we only need to set naming
conventions for the keys.
In SCA every component has a unique QName comprising of the URI of
its containing composite and the local name within. Therefore we can
create a unique name for the MBean of the form:
${userDomain} : type = SCAComponent, composite = "${compositeURI}" ,
name = ${componentName}
We also have Tuscany-specific system components and I'd suggest for
those we use type = TuscanySystem
Rather than use hierarchical type values, this uses the natural
hierarchy of the composite URI to express containment. Because the
URI is likely to contain a scheme the value needs to be quoted to
escape the ':'
The other thought was about how a component could expose a management
interface. One option would be to support <binding.jmx> for
attachment to a service; however, this would require a componentType
sidefile. Another would be to support an @Management annotation on a
service interface. With both of these the selected service would be
registered as a Dynamic MBean. A fallback option would also be to
recognize the component as a Standard MBean (i.e. it would have a
*MBean interface).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Standalone server
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Hi,
I have updated standalone server to support multiple runtimes. Now, when the
server is started, it doesn't start any runtime. However, the server has a
management op called startRuntime(String bootPath) to start a runtime. Boot
path for the runtime is resolved relative to the installation path. It is
expected to have a file called runtime.properties in a directory named etc.
The file contains the JMX domain name under which the runtime instance is
registered. Once started the runtime instance is available for management.
Only management ops currently available are initialize and destroy.
This allows any number of runtimes to be started within a server
environment.
Ta
Meeraj
>From: "Meeraj Kunnumpurath" <m....@hotmail.co.uk>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Standalone server
>Date: Wed, 27 Dec 2006 00:02:31 +0000
>
>Hi,
>
>I have added server.start and server.shutdown modules in standalone to run
>an instance of tuscany as a server. This is an extension of the existing
>launcher. Rather tha running the specified application on the cli and
>exiting, the server stays up running and listens on a JMX port for shutdown
>requests. It boots up the standalone runtime as the launcher, however,
>doesn't deploy any app scdls. I would assume the runtime will use something
>like a directory scanner to search a specified location for the
>applications to be deployed and deploy them using the deployment API.
>
>Both server.start and server.shutdown produces executable JAR files.
>Currently all configurable parameters are specified as system properties.
>These include,
>
>1. Install directory
>2. Boot directory
>3. System SCDL path
>
>All these use the existing system props and defaults as with the launcher.
>The default JMX remote connector port is 1099. This may be overridden using
>the system property tuscany.adminPort.
>
>Ta
>Meeraj
>
>_________________________________________________________________
>MSN Hotmail is evolving check out the new Windows Live Mail
>http://ideas.live.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org