Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » makeSharedObjectContainer & org.eclipse.ecf.containerFactory extension point
makeSharedObjectContainer & org.eclipse.ecf.containerFactory extension point [message #574185] Thu, 06 January 2005 11:50 Go to next message
Li-Te Cheng is currently offline Li-Te Cheng
Messages: 16
Registered: July 2009
Junior Member
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."

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
Re: makeSharedObjectContainer & org.eclipse.ecf.containerFactory extension point [message #574206 is a reply to message #574185] Thu, 06 January 2005 15:58 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
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
Re: makeSharedObjectContainer & org.eclipse.ecf.containerFactory extension point [message #574221 is a reply to message #574206] Fri, 07 January 2005 16:30 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
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
>
Previous Topic:Initial provider implementation complete and available
Next Topic:ECF Revised Plan
Goto Forum:
  


Current Time: Sat Sep 20 08:18:15 GMT 2014

Powered by FUDForum. Page generated in 0.03728 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software