Home » Archived » Eclipse Communications Framework (ECF) » Container/Adapter creation problem
| Container/Adapter creation problem [message #624205] |
Fri, 10 October 2008 15:26  |
 Neeraj Bhusare
Messages: 177
Registered: July 2009
Location: Canada |
Senior Member |
|
|
Hello All,
I am working on a RCP application based on ECF. I case of the RCP app, for
calls made to the generic container(ecf.generic.client), I get null value
for the IChannelContainerAdapter. Unlike that, if I use the same code in a
plug-in, things work fine and I get proper values for the containers and
adapters.
I would like to know the following.
1. Do I need to add additional plug-in's(apart from the ones present -
*.ecf,*.ecf.datashare, *.ecf.provider) as part of the dependency in case
of an RCP application.
- One difference that I noticed - in case of a plug-in things work fine,
even if I don't introduce org.eclipse.ecf.provider plug-in as part of the
dependency list, unlike that I had to add *.provider dependency in case of
the RCP application.
2. Do I need to make any changes in the code to get things working.
I am using:
Eclipse Ganymede release
org.eclipse.ecf - 2.0
*.datashare - 1.3.0
*.provider - 1.3.0
I am a bit new to the ECF world, so I may have missed something. I would
be happy to know more about the things I should be careful about while
writing RCP applications based on ECF.
Thanks in advance.
Twitter : @NeerajBhusare
Blog : https://nbhusare.github.io/
Best regards, Neeraj
|
|
|
| Re: Container/Adapter creation problem [message #624206 is a reply to message #624205] |
Fri, 10 October 2008 18:52  |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Neeraj,
Neeraj wrote:
> Hello All,
> I am working on a RCP application based on ECF. I case of the RCP app,
> for calls made to the generic container(ecf.generic.client), I get null
> value for the IChannelContainerAdapter. Unlike that, if I use the same
> code in a plug-in, things work fine and I get proper values for the
> containers and adapters.
>
> I would like to know the following.
> 1. Do I need to add additional plug-in's(apart from the ones present -
> *.ecf,*.ecf.datashare, *.ecf.provider) as part of the dependency in case
> of an RCP application.
It's not so much that it's an RCP app, but rather that it's trying to
get the IChannelContainerAdapter.
For the ECF generic provider, this adapter (IChannelContainerAdapter) is
actually implemented by the org.eclipse.ecf.provider.datashare plugin.
The reason this is done this way...i.e. having the adapters implemented
in different plugins...is so that consumers don't have to include things
they don't need/want. The cost of this approach is that consumers that
*do* want these capabilities need to include them in the dependencies
list explicitly (since clients don't generally refer to the impls
directly in their code, but rather to the API).
> - One difference that I noticed - in case of a plug-in things work fine,
> even if I don't introduce org.eclipse.ecf.provider plug-in as part of
> the dependency list, unlike that I had to add *.provider dependency in
> case of the RCP application.
>
> 2. Do I need to make any changes in the code to get things working.
I don't think to the code, but rather to the set of plugins that are
included in your application. I believe you should be able to add
org.eclipse.ecf.provider.datashare (and include its dependencies) and
then an IChannelContainerAdapter will be available for the ECF generic
client.
>
> I am using:
> Eclipse Ganymede release
> org.eclipse.ecf - 2.0
> *.datashare - 1.3.0
> *.provider - 1.3.0
>
> I am a bit new to the ECF world, so I may have missed something. I would
> be happy to know more about the things I should be careful about while
> writing RCP applications based on ECF.
Just so it's clear, this is a consequence of the design choice described
above...moving the generic client's datashare impl out of the
org.eclipse.ecf.provider bundle, and into a separate bundle. As
mentioned above, it's good when it means that you don't need to include
what you don't want, but it does result in some potential confusion when
you want to use the channel container adapter as you do. My apolologies
for that.
At some point it would be really nice to have for each provider
(starting with the ECF generic) a written description of where all of
its adapters are implemented (i.e. which plugins). This could be
presented as a table or something that people could refer to. If you
would like to open a doc enhancement request to this effect that would
be very helpful.
Thanks,
Scott
|
|
|
| Re: Container/Adapter creation problem [message #624207 is a reply to message #624206] |
Mon, 13 October 2008 05:25 |
Neeraj Bhusare
Messages: 177
Registered: July 2009
Location: Canada |
Senior Member |
|
|
Thanks Scott for the detailed reply. I am happy to know that I don't
really have to do things differently while writing an ECF base RCP
application, thanks for clearing out the confusion.
Secondly, I have created an example application - A RCP based browser with
real time capabilities. I don't know how helpful it could be to the ECF
community, but I would like to contribute it to the ECF examples section.
I would be happy if you could help me in the same.
As you had suggested, I have opened a doc enhancement request -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250597
Thanks again.
Regards,
Neeraj
Scott Lewis wrote:
> Hi Neeraj,
> Neeraj wrote:
>> Hello All,
>> I am working on a RCP application based on ECF. I case of the RCP app,
>> for calls made to the generic container(ecf.generic.client), I get null
>> value for the IChannelContainerAdapter. Unlike that, if I use the same
>> code in a plug-in, things work fine and I get proper values for the
>> containers and adapters.
>>
>> I would like to know the following.
>> 1. Do I need to add additional plug-in's(apart from the ones present -
>> *.ecf,*.ecf.datashare, *.ecf.provider) as part of the dependency in case
>> of an RCP application.
> It's not so much that it's an RCP app, but rather that it's trying to
> get the IChannelContainerAdapter.
> For the ECF generic provider, this adapter (IChannelContainerAdapter) is
> actually implemented by the org.eclipse.ecf.provider.datashare plugin.
> The reason this is done this way...i.e. having the adapters implemented
> in different plugins...is so that consumers don't have to include things
> they don't need/want. The cost of this approach is that consumers that
> *do* want these capabilities need to include them in the dependencies
> list explicitly (since clients don't generally refer to the impls
> directly in their code, but rather to the API).
>> - One difference that I noticed - in case of a plug-in things work fine,
>> even if I don't introduce org.eclipse.ecf.provider plug-in as part of
>> the dependency list, unlike that I had to add *.provider dependency in
>> case of the RCP application.
>>
>> 2. Do I need to make any changes in the code to get things working.
> I don't think to the code, but rather to the set of plugins that are
> included in your application. I believe you should be able to add
> org.eclipse.ecf.provider.datashare (and include its dependencies) and
> then an IChannelContainerAdapter will be available for the ECF generic
> client.
>>
>> I am using:
>> Eclipse Ganymede release
>> org.eclipse.ecf - 2.0
>> *.datashare - 1.3.0
>> *.provider - 1.3.0
>>
>> I am a bit new to the ECF world, so I may have missed something. I would
>> be happy to know more about the things I should be careful about while
>> writing RCP applications based on ECF.
> Just so it's clear, this is a consequence of the design choice described
> above...moving the generic client's datashare impl out of the
> org.eclipse.ecf.provider bundle, and into a separate bundle. As
> mentioned above, it's good when it means that you don't need to include
> what you don't want, but it does result in some potential confusion when
> you want to use the channel container adapter as you do. My apolologies
> for that.
> At some point it would be really nice to have for each provider
> (starting with the ECF generic) a written description of where all of
> its adapters are implemented (i.e. which plugins). This could be
> presented as a table or something that people could refer to. If you
> would like to open a doc enhancement request to this effect that would
> be very helpful.
> Thanks,
> Scott
Twitter : @NeerajBhusare
Blog : https://nbhusare.github.io/
Best regards, Neeraj
|
|
| |
| Re: Container/Adapter creation problem [message #624210 is a reply to message #624208] |
Tue, 14 October 2008 12:05 |
Neeraj Bhusare
Messages: 177
Registered: July 2009
Location: Canada |
Senior Member |
|
|
Scott Lewis wrote:
Hello Scott,
> Hi Neeraj,
> Neeraj wrote:
>> Thanks Scott for the detailed reply. I am happy to know that I don't
>> really have to do things differently while writing an ECF base RCP
>> application, thanks for clearing out the confusion. Secondly, I have
>> created an example application - A RCP based browser with real time
>> capabilities. I don't know how helpful it could be to the ECF community,
>> but I would like to contribute it to the ECF examples section. I would
>> be happy if you could help me in the same.
> Of course! Thanks for your contribution offer!
Thanks
> Probably the best way to go about this would be for you to post a short
> note describing the work in a little more technical detail to the
> ecf-dev mailing list (ecf-dev at eclipse.org). Then I will create an
> appropriate enhancement request based upon your description, and you can
> then attach the contribution as a patch (or zip, whichever is better for
> you) to that enhancement request. That way we can both look at it/play
> with it, as well as begin the process necessary for IP review.
> How does this sound to you? If you wish to contact me directly please
> do so at slewis at composent.com.
This sounds great. I'll drop an email to the ecf-dev mailing list with the
technical details about the application, ASAP.
>> As you had suggested, I have opened a doc enhancement request -
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250597
> Thanks very much!
> Scott
Thanks again
Neeraj
Twitter : @NeerajBhusare
Blog : https://nbhusare.github.io/
Best regards, Neeraj
|
|
|
| |
  |
Goto Forum:
Current Time: Fri Apr 19 14:13:19 GMT 2024
Powered by FUDForum. Page generated in 0.02486 seconds |
] 
Search
Help
Register
Login
Home
