[
https://issues.apache.org/jira/browse/RIVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970847#action_12970847
]
Gregg Wonderly commented on RIVER-379:
--------------------------------------
Here's how I have been thinking about this.
Existing containers would probably be better off being told about a service
instance that wants to be managed in the container, and then being able to
query them for information so that "order of operations" could be continued to
be managed by those containers, rather than having some thread calling into
them to tell them what to do.
Also, com.sun.jini.start.ServiceStarter Configuration data should be useful for
deploying services into a container in its raw form.
I think that the java.util.ServiceLoader mechanisms might provide some
mechanics in how containers would advertise their services within a JVM. So,
defining some classes and interfaces in that direction, something like the
following would encapsulate what I've been thinking about.
For the ServiceLoader SPI we might define a simple interface such as:
public interface JiniServiceStarter {
public void addInstance( JiniService inst );
}
For the service instances themselves, I think it is important to make sure that
the containers control the order of operations how they want so that they can
use calls into the users code to tell the user what is happening next, or to
ask for information needed for deployment.
public interface JiniService {
public ServiceControl getDefinition( JiniService svc );
}
This definition allows a single class, such as
com.sun.jini.start.ServiceStarter, to be the gateway to information about
multiple service instances.
public interface ServiceControl {
// Get the Configuration for the service
public Configuration getConfiguration();
// Get the unexported object so that the container to "export" how needed.
public Remote getExportableServiceObject();
// get the list of classes that should be used as the class path for the
service.
public List<String> getClassPath();
// get the codebase annotations to use for the created classloader(s)
public List<String> getCodeBase();
// tell the service it is starting with this information. The args[]
// provides access to command line options, the Configuration
// is a Configuration provided by the container. This configuration
// should be used by the service for all of its activities. This allows
// dynamic configuration editing to be provided by the container.
// it might, for example actually allow editing of the getConfiguration()
// data and just provide that again, or it might amend the configuration
// and provide that in this call.
public void serivceStarting( String args[], Configuration config );
// The service is not advertized and running with the indicated classloader
// and service instance. Remote is used at a minimum instead of
// Object to allow other activities to be performed by the service with
// the Remote Object.
public void serviceRunning( ClassLoader cl, Remote instance );
// The service instance was stopped and unloaded and the ServiceControl
// instance should drop all references to the service so it can be GC'd
public void serviceStopped();
}
There are all kinds of scenarios running around in my head that make the
arguments to the above methods interesting. Would any of these things be
problematic to containers today?
Feel free to counter and change around these things how you see it so that we
can find out what makes the most sense.
> Standard Deployment Descriptors and Definitions
> -----------------------------------------------
>
> Key: RIVER-379
> URL: https://issues.apache.org/jira/browse/RIVER-379
> Project: River
> Issue Type: Brainstorming
> Components: com_sun_jini_start
> Affects Versions: AR4
> Environment: All
> Reporter: Peter Firmstone
> Priority: Minor
>
> Common standards for deployment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
