[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,

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