Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » ECF recent progress
ECF recent progress [message #614870] Fri, 16 March 2007 04:03 Go to next message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
Hi Folks,

A quick update on recent ECF changes and additions:

1) The bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=176322
suggested moving away from using the classes in
org.eclipse.core.runtime. Main reason this makes sense to do now: once
we do this nearly all of the non-ui ECF plugins (the core + all
providers) can run on any/all of the various Equinox
runtimes...including Equinox-based servers, RCP configs, Eclipse (of
course), and in some cases eRCP runtimes. I've now gotten most of the
things listed in this bug taken care of now (in HEAD), and the remaining
changes are waiting on a change to equinox listed in bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=177224

2) I've added a new server plugin: org.eclipse.ecf.server.generic. As
the name implies, this is an ECF generic server. I also added an
extension point defined by this plugin that allows other plugins to
create/configure ECF generic server groups via extensions. So, for
example, to setup an ECF generic server on localhost, port 3333, with
group name 'foobar' (and id: ecftcp://localhost:3333/foobar) just put
this in plugin.xml:

<extension
point="org.eclipse.ecf.server.generic.configuration">
<connector
discovery="true"
hostname="localhost"
keepAlive="30000"
port="3333">
<group
name="foobar">
</group>
</connector>
</extension>

And when the org.eclipse.ecf.server.generic bundle is started the given
server and group will be setup via the extension. Further, if the
'discovery' attribute is set to true, the server will be published (with
zeroconf) for automatic service discovery (via ECF discovery API of course)!

3) New OSGi services. I added OSGi services for bundles/plugins to use.
There are now services for discovery, containerfactory, idfactory, and
retrieve file transfer. These can now be accessed via OSGi services
(e.g. with ServiceTracker) rather than via (e.g.)
ContainerFactory.getDefault(). See the test cases code for examples of
how to use. The last one (retrieve file transfer service) should be
particularly useful for the provisioning work.

4) *Lots* of cleanup of manifest.mf, plugin.xml, plugin.properties for
all ECF projects.

5) I put the slides from Ken's talk up on the ECF website with a link on
the ECF home page: http://www.eclipse.org/ecf My heartfelt thanks to
Ken for stepping in at the last second to give the talk in my
absence/illness. It's most appreciated. Also thanks to Chris A for
representing ECF interests at the ECF BOF and at the provisioning BOF.

Scott
Re: ECF recent progress [message #614877 is a reply to message #614870] Thu, 22 March 2007 00:02 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
Some more recent progress:

Up to now, the IOutgoingFileTransferContainerAdapter peer-to-peer file
transfer has not been complete. This bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=176578 basically
discovered that fact. But as of today the filetransfer API outgoing
file transfer is fully implemented using the xmpp peer-to-peer file
transfer. There is test code in the org.eclipse.ecf.tests.filetransfer
plugin, in the OutgoingFileTransferTest test case. Note that I added
some logic in the test case super class to support the passing of
usernames and passwords in as system properties for access to remote
accounts.

This also resulted in a new method for the filetransfer API:
1) to allow for the receiver of the file transfer to give an
OutputStream as a target (in addition to a File), and
2) optionally specify a listener (on the receiver) to be asynchronously
notified about the file transfer progress .
The new method is
IFileTransferRequestEvent.accept(OutputStream,IFileTransferL istener).

ASAP, will update roster view to add file send action.

Scott



Scott Lewis wrote:
> Hi Folks,
>
> A quick update on recent ECF changes and additions:
>
> 1) The bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=176322
> suggested moving away from using the classes in
> org.eclipse.core.runtime. Main reason this makes sense to do now: once
> we do this nearly all of the non-ui ECF plugins (the core + all
> providers) can run on any/all of the various Equinox
> runtimes...including Equinox-based servers, RCP configs, Eclipse (of
> course), and in some cases eRCP runtimes. I've now gotten most of the
> things listed in this bug taken care of now (in HEAD), and the remaining
> changes are waiting on a change to equinox listed in bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=177224
>
> 2) I've added a new server plugin: org.eclipse.ecf.server.generic. As
> the name implies, this is an ECF generic server. I also added an
> extension point defined by this plugin that allows other plugins to
> create/configure ECF generic server groups via extensions. So, for
> example, to setup an ECF generic server on localhost, port 3333, with
> group name 'foobar' (and id: ecftcp://localhost:3333/foobar) just put
> this in plugin.xml:
>
> <extension
> point="org.eclipse.ecf.server.generic.configuration">
> <connector
> discovery="true"
> hostname="localhost"
> keepAlive="30000"
> port="3333">
> <group
> name="foobar">
> </group>
> </connector>
> </extension>
>
> And when the org.eclipse.ecf.server.generic bundle is started the given
> server and group will be setup via the extension. Further, if the
> 'discovery' attribute is set to true, the server will be published (with
> zeroconf) for automatic service discovery (via ECF discovery API of
> course)!
>
> 3) New OSGi services. I added OSGi services for bundles/plugins to use.
> There are now services for discovery, containerfactory, idfactory, and
> retrieve file transfer. These can now be accessed via OSGi services
> (e.g. with ServiceTracker) rather than via (e.g.)
> ContainerFactory.getDefault(). See the test cases code for examples of
> how to use. The last one (retrieve file transfer service) should be
> particularly useful for the provisioning work.
>
> 4) *Lots* of cleanup of manifest.mf, plugin.xml, plugin.properties for
> all ECF projects.
>
> 5) I put the slides from Ken's talk up on the ECF website with a link on
> the ECF home page: http://www.eclipse.org/ecf My heartfelt thanks to
> Ken for stepping in at the last second to give the talk in my
> absence/illness. It's most appreciated. Also thanks to Chris A for
> representing ECF interests at the ECF BOF and at the provisioning BOF.
>
> Scott
Re: ECF recent progress [message #614878 is a reply to message #614877] Mon, 26 March 2007 04:12 Go to previous messageGo to next message
czhcc is currently offline czhcc
Messages: 11
Registered: July 2009
Junior Member
Hi Scott:
I use the OutgoingFileTransferTest test case.The system properties like
-Dusername0=user0@hostname:5222 -Dpassword0=user0 -Dusername1=user1@hostname:5222
-Dpassword1=user1
But the resourcename of XMPPID is null call getServerConnectID.
Then in org.jivesoftware.smackx.filetransfer.FileTransferNegotiator line
386:
si.setFrom(connection.getUser()); <== user1@hostname/ECF_XMPP
si.setTo(userID); <== user0@hostname/null
Is this a bug?

"Scott Lewis" <slewis@composent.com> ????
news:etsh3n$8ti$1@utils.eclipse.org...
> Some more recent progress:
>
> Up to now, the IOutgoingFileTransferContainerAdapter peer-to-peer file
> transfer has not been complete. This bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176578 basically discovered
> that fact. But as of today the filetransfer API outgoing file transfer is
> fully implemented using the xmpp peer-to-peer file transfer. There is
> test code in the org.eclipse.ecf.tests.filetransfer plugin, in the
> OutgoingFileTransferTest test case. Note that I added some logic in the
> test case super class to support the passing of usernames and passwords in
> as system properties for access to remote accounts.
>
> This also resulted in a new method for the filetransfer API:
> 1) to allow for the receiver of the file transfer to give an OutputStream
> as a target (in addition to a File), and
> 2) optionally specify a listener (on the receiver) to be asynchronously
> notified about the file transfer progress .
> The new method is
> IFileTransferRequestEvent.accept(OutputStream,IFileTransferL istener).
>
> ASAP, will update roster view to add file send action.
>
> Scott
>
>
>
> Scott Lewis wrote:
>> Hi Folks,
>>
>> A quick update on recent ECF changes and additions:
>>
>> 1) The bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=176322 suggested
>> moving away from using the classes in org.eclipse.core.runtime. Main
>> reason this makes sense to do now: once we do this nearly all of the
>> non-ui ECF plugins (the core + all providers) can run on any/all of the
>> various Equinox runtimes...including Equinox-based servers, RCP configs,
>> Eclipse (of course), and in some cases eRCP runtimes. I've now gotten
>> most of the things listed in this bug taken care of now (in HEAD), and
>> the remaining changes are waiting on a change to equinox listed in bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=177224
>>
>> 2) I've added a new server plugin: org.eclipse.ecf.server.generic. As
>> the name implies, this is an ECF generic server. I also added an
>> extension point defined by this plugin that allows other plugins to
>> create/configure ECF generic server groups via extensions. So, for
>> example, to setup an ECF generic server on localhost, port 3333, with
>> group name 'foobar' (and id: ecftcp://localhost:3333/foobar) just put
>> this in plugin.xml:
>>
>> <extension
>> point="org.eclipse.ecf.server.generic.configuration">
>> <connector
>> discovery="true"
>> hostname="localhost"
>> keepAlive="30000"
>> port="3333">
>> <group
>> name="foobar">
>> </group>
>> </connector>
>> </extension>
>>
>> And when the org.eclipse.ecf.server.generic bundle is started the given
>> server and group will be setup via the extension. Further, if the
>> 'discovery' attribute is set to true, the server will be published (with
>> zeroconf) for automatic service discovery (via ECF discovery API of
>> course)!
>>
>> 3) New OSGi services. I added OSGi services for bundles/plugins to use.
>> There are now services for discovery, containerfactory, idfactory, and
>> retrieve file transfer. These can now be accessed via OSGi services
>> (e.g. with ServiceTracker) rather than via (e.g.)
>> ContainerFactory.getDefault(). See the test cases code for examples of
>> how to use. The last one (retrieve file transfer service) should be
>> particularly useful for the provisioning work.
>>
>> 4) *Lots* of cleanup of manifest.mf, plugin.xml, plugin.properties for
>> all ECF projects.
>>
>> 5) I put the slides from Ken's talk up on the ECF website with a link on
>> the ECF home page: http://www.eclipse.org/ecf My heartfelt thanks to
>> Ken for stepping in at the last second to give the talk in my
>> absence/illness. It's most appreciated. Also thanks to Chris A for
>> representing ECF interests at the ECF BOF and at the provisioning BOF.
>>
>> Scott
Re: ECF recent progress [message #614880 is a reply to message #614878] Mon, 26 March 2007 22:06 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
Hi Cui,

I don't think what you describe is a bug as it's OK to have resourcename
of XMPPID as null.

With latest code I can't reproduce the problem you are having (with

> -Dusername0=user0@hostname:5222 -Dpassword0=user0
-Dusername1=user1@hostname:5222
> -Dpassword1=user1

The test works for two accounts on ecf.eclipse.org.

What failure are you getting? Is an exception thrown? If so, what is
it? If not, is it simply that the receiver never seems to get the
initial request? This may be a jabber server that is not sending the
initial request through properly (which I did find was the case for
Google Talk). I don't know whether this problem is with Google Talk or
with Smack lib, but I've posted a question to Jive forums here:

http://www.igniterealtime.org/forum/thread.jspa?messageID=14 2716&

Please do file a bug report if you are still seeing a problem.

Thanks,

Scott


cui zihui wrote:
> Hi Scott:
> I use the OutgoingFileTransferTest test case.The system properties like
> -Dusername0=user0@hostname:5222 -Dpassword0=user0 -Dusername1=user1@hostname:5222
> -Dpassword1=user1
> But the resourcename of XMPPID is null call getServerConnectID.
> Then in org.jivesoftware.smackx.filetransfer.FileTransferNegotiator line
> 386:
> si.setFrom(connection.getUser()); <== user1@hostname/ECF_XMPP
> si.setTo(userID); <== user0@hostname/null
> Is this a bug?
>
> "Scott Lewis" <slewis@composent.com> ????
> news:etsh3n$8ti$1@utils.eclipse.org...
>> Some more recent progress:
>>
>> Up to now, the IOutgoingFileTransferContainerAdapter peer-to-peer file
>> transfer has not been complete. This bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176578 basically discovered
>> that fact. But as of today the filetransfer API outgoing file transfer is
>> fully implemented using the xmpp peer-to-peer file transfer. There is
>> test code in the org.eclipse.ecf.tests.filetransfer plugin, in the
>> OutgoingFileTransferTest test case. Note that I added some logic in the
>> test case super class to support the passing of usernames and passwords in
>> as system properties for access to remote accounts.
>>
>> This also resulted in a new method for the filetransfer API:
>> 1) to allow for the receiver of the file transfer to give an OutputStream
>> as a target (in addition to a File), and
>> 2) optionally specify a listener (on the receiver) to be asynchronously
>> notified about the file transfer progress .
>> The new method is
>> IFileTransferRequestEvent.accept(OutputStream,IFileTransferL istener).
>>
>> ASAP, will update roster view to add file send action.
>>
>> Scott
>>
>>
>>
>> Scott Lewis wrote:
>>> Hi Folks,
>>>
>>> A quick update on recent ECF changes and additions:
>>>
>>> 1) The bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=176322 suggested
>>> moving away from using the classes in org.eclipse.core.runtime. Main
>>> reason this makes sense to do now: once we do this nearly all of the
>>> non-ui ECF plugins (the core + all providers) can run on any/all of the
>>> various Equinox runtimes...including Equinox-based servers, RCP configs,
>>> Eclipse (of course), and in some cases eRCP runtimes. I've now gotten
>>> most of the things listed in this bug taken care of now (in HEAD), and
>>> the remaining changes are waiting on a change to equinox listed in bug
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=177224
>>>
>>> 2) I've added a new server plugin: org.eclipse.ecf.server.generic. As
>>> the name implies, this is an ECF generic server. I also added an
>>> extension point defined by this plugin that allows other plugins to
>>> create/configure ECF generic server groups via extensions. So, for
>>> example, to setup an ECF generic server on localhost, port 3333, with
>>> group name 'foobar' (and id: ecftcp://localhost:3333/foobar) just put
>>> this in plugin.xml:
>>>
>>> <extension
>>> point="org.eclipse.ecf.server.generic.configuration">
>>> <connector
>>> discovery="true"
>>> hostname="localhost"
>>> keepAlive="30000"
>>> port="3333">
>>> <group
>>> name="foobar">
>>> </group>
>>> </connector>
>>> </extension>
>>>
>>> And when the org.eclipse.ecf.server.generic bundle is started the given
>>> server and group will be setup via the extension. Further, if the
>>> 'discovery' attribute is set to true, the server will be published (with
>>> zeroconf) for automatic service discovery (via ECF discovery API of
>>> course)!
>>>
>>> 3) New OSGi services. I added OSGi services for bundles/plugins to use.
>>> There are now services for discovery, containerfactory, idfactory, and
>>> retrieve file transfer. These can now be accessed via OSGi services
>>> (e.g. with ServiceTracker) rather than via (e.g.)
>>> ContainerFactory.getDefault(). See the test cases code for examples of
>>> how to use. The last one (retrieve file transfer service) should be
>>> particularly useful for the provisioning work.
>>>
>>> 4) *Lots* of cleanup of manifest.mf, plugin.xml, plugin.properties for
>>> all ECF projects.
>>>
>>> 5) I put the slides from Ken's talk up on the ECF website with a link on
>>> the ECF home page: http://www.eclipse.org/ecf My heartfelt thanks to
>>> Ken for stepping in at the last second to give the talk in my
>>> absence/illness. It's most appreciated. Also thanks to Chris A for
>>> representing ECF interests at the ECF BOF and at the provisioning BOF.
>>>
>>> Scott
>
>
Previous Topic:XMPP SO -> Gmail Woes
Next Topic:m6
Goto Forum:
  


Current Time: Wed Sep 17 09:48:08 GMT 2014

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

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