Home » Archived » 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  |
 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  |
Scott Lewis
Messages: 1038
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 |
Scott Lewis
Messages: 1038
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
>
|
|
|
| |
  |
Goto Forum:
Current Time: Fri Apr 26 07:38:54 GMT 2024
Powered by FUDForum. Page generated in 0.03360 seconds |
] 
Search
Help
Register
Login
Home
