[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ecf] Re: makeSharedObjectContainer & org.eclipse.ecf.containerFactory extension point 
Hi Li-Te and all,

I implemented and checked in the suggested additions to the containerFactory schema to allow optional 'defaultarguments' to be associated with the extension point as follows:

<extension
point="org.eclipse.ecf.containerFactory">
<containerFactory
class="org.eclipse.ecf.provider.generic.Server"
description="Generic Server Container Instantiator"
name="org.eclipse.ecf.provider.generic.Server">
<-- Here's the new stuff -->
<defaultargument type="java.lang.String" value="ecftcp://localhost:3282/server" name="url"/>
<defaultargument type="java.lang.Boolean" value="false" name="activeFlag"/>
</containerFactory>
</extension>

The defaultargument elements provide default arguments associated with the SharedObjectContainerDescription (see new getArgTypes(), getArgDefaults(), getArgNames() on SharedObjectContainerDescription). Also, the ISharedObjectContainerInstantiator.makeInstance method now has the following signature:

public ISharedObjectContainer makeInstance(SharedObjectContainerDescription description, Class[] argTypes, Object[] args)
throws SharedObjectContainerInstantiationException;

Note that at construction time, the SharedObjectContainerDescription is now passed to the implementing makeInstance method, and the implementation can use the default argument information as needed to setup/define the parameters to the construction of an ISharedObjectContainer instance.

So now, the caller can create ISharedObjectContainer instances as follows:

ISharedObjectContainer server = SharedObjectContainerFactory.makeSharedObjectContainer("org.eclipse.ecf.provider.generic.Server");

And the server instance will be automatically setup with the defaults as defined above (by the provider).

I also added some documentation about the use of the 'class' as the default if the 'name' is not specifically specified by the extension point.

Thanks for this suggestion Li-Te...it makes things much easier for the use of this 'extensible factory'.

Scott




Scott Lewis wrote: 
Hi Li-Te,

Li-Te wrote:

Hi,

Started to try out the initial provider implementation. Thanks for making it available so quickly! So far it works pretty well, and I'll probably have more comments later after digging into it some more...

Something that struck me immediately was the pattern to set up a server versus the pattern to set up a client, i.e.

Here is some example/test code that creates a client instance of this new provider:

client pattern:

ISharedObjectContainer clients[i] = SharedObjectContainerFactory.makeSharedObjectContainer("org.eclipse.ecf.provider.generic.ContainerInstantiator"); 


server pattern:

ID serverID = IDFactory.makeStringID("ecftcp://localhost:3282/server");
Object [] args = new Object [] { new Boolean(false), serverID };
server = SharedObjectContainerFactory.makeSharedObjectContainer("org.eclipse.ecf.provider.generic.ContainerInstantiator",args); 


1.  The documentation on makeSharedObjectContainer says

"@param descriptionName = the SharedObjectContainerDescription name to lookup"


It might be helpful to note the mapping between descriptionName and the "name" field in extension to org.eclipse.ecf.containerFactory in the plugin.xml. e.g. "SharedObjectContainerDescription names can be found in the 'name' field of any extension to the org.eclipse.ecf.containerFactory extension point. If there is no name field defined, the ContainerInstantiator class name is used." 


Yes...good point.  Will do.


2. The server pattern involves some extra "configuration" steps (setting up an ID, setting up arguments). It might be nice to ALSO allow alternate extensions to the org.eclipse.ecf.containerFactory extension point to provide default arguments. e.g. something like...

<extension
     point="org.eclipse.ecf.containerFactory">
  <containerFactory
          class="org.eclipse.ecf.provider.generic.ContainerInstantiator"
          description="Generic Container Instantiator"
       name="client"/>
  <containerFactory
          class="org.eclipse.ecf.provider.generic.ContainerInstantiator"
          description="Generic Container Instantiator"
       name="server">
       <arg type="boolean">false</arg>
       <arg type="stringID">ecftcp://localhost:3282/server</arg>
  </containerFactory>
</extension>

This way, the you can set up a server as quickly as a client:

server = SharedObjectContainerFactory.makeSharedObjectContainer("server",args);

Also, this pushes server configuration information into plugin.xml, so you can tweak this info without touching sourcecode.

Plus, others can extend org.eclipse.ecf.containerFactory with the same ContainerInstantiator class, use a different name, and define different default arguments.

This might also be useful for different client configurations as well.

Li-Te


Yes, I think you are right on about this. The current handling of params for the factories can be awkward. I was thinking of adding to the extension point (and the others as well), and your comments confirm/extend this. I will likely be able implement these enhancements to the extension point today (Thurs).

BTW, for your and others information, last night I checked into the org.eclipse.ecf.provider plugin two classes that provide java application wrappers for both the generic server and the generic client...meaning that this server and client can be started/tested/debugged/run as java applications rather than as plugins. This may be a desireable way for some to run the server (particularly)...in that things can be run as a straight java application rather than from an Eclipse plugin.

The two classes are:

org.eclipse.ecf.provider.app.ServerApplication
org.eclipse.ecf.provider.app.ClientApplication

See the javadocs or the source for the (opt) command line parameters.

I also put two run configs into the project as well (in launchconfigs), that start these applications via the eclipse run/debug.

Scott