Home » Archived » Eclipse Communications Framework (ECF) » ECF 1.1 available
| ECF 1.1 available [message #619565] |
Sun, 09 September 2007 02:41  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Folks,
ECF 1.1 now available at normal locations. See below for links.
The New and Noteworthy is not done yet, so committers please send any
additions to ecf-dev@eclipse.org i.e. if the placeholders that are there
have missed something that you feel the N&N should include.
Particularly noteworthy was the work of Google SOC 2007 student Moritz
Post on the Jingle VOIP protocol:
http://wiki.eclipse.org/VoIP_via_the_ECF_Call_API_and_the_Ji ngle_Protocol
ECF was also the beneficiary of some great contributions for the Eclipse
BugDay. Thanks to all who participated and the committers who
supported/reviewed.
See also the ECF OSU Open Source Lab site...for significant additions
for JMS-based communications: a new Websphere CE provider, as a new BEA
Weblogic-based JMS provider, and a JGroups (reliable multicast) based
provider. Along with JXTA, JGroups is a 'true' peer-to-peer provider.
It's not done yet, but is working. Further, all of these new providers
implement ECF datashare, the remote OSGI services API, and the ECF
shared object API.
Thanks,
Scott
Download and Update Site info: http://www.eclipse.org/ecf/downloads.php
New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html
OSU OSL: http://ecf1.osuosl.org
CVS tag for release: v20070908-1720
|
|
|
| Re: ECF 1.1 available [message #619566 is a reply to message #619565] |
Sun, 09 September 2007 20:30  |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Scott, I took a look at the source code for the connection logic in the
JGroups implementation. I realize it is not done, but thought I would bring
up the following issues that I noticed.
One is that it uses the default stacks.xml file provided with JGroups to
define the protocol. A plugin should be able to provide its own protocol
definitions when initializing a JChannel.
Another issue is that the implementation seems only to support Eclipse
peers. I'd like to see an option so a plugin can create its own
PullPushAdapter to send/receive messages. Currently the JChannel is
not exposed which prevents accessing this API.
"Scott Lewis" <slewis@composent.com> wrote in message
news:46E35D3E.4020106@composent.com...
> Hi Folks,
>
> ECF 1.1 now available at normal locations. See below for links.
>
> The New and Noteworthy is not done yet, so committers please send any
> additions to ecf-dev@eclipse.org i.e. if the placeholders that are there
> have missed something that you feel the N&N should include.
>
> Particularly noteworthy was the work of Google SOC 2007 student Moritz
> Post on the Jingle VOIP protocol:
> http://wiki.eclipse.org/VoIP_via_the_ECF_Call_API_and_the_Ji ngle_Protocol
>
> ECF was also the beneficiary of some great contributions for the Eclipse
> BugDay. Thanks to all who participated and the committers who
> supported/reviewed.
>
> See also the ECF OSU Open Source Lab site...for significant additions for
> JMS-based communications: a new Websphere CE provider, as a new BEA
> Weblogic-based JMS provider, and a JGroups (reliable multicast) based
> provider. Along with JXTA, JGroups is a 'true' peer-to-peer provider.
> It's not done yet, but is working. Further, all of these new providers
> implement ECF datashare, the remote OSGI services API, and the ECF shared
> object API.
>
> Thanks,
>
> Scott
>
> Download and Update Site info: http://www.eclipse.org/ecf/downloads.php
> New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html
> OSU OSL: http://ecf1.osuosl.org
> CVS tag for release: v20070908-1720
>
|
|
|
| Re: ECF 1.1 available [message #619567 is a reply to message #619566] |
Mon, 10 September 2007 00:03 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Thanks for the comments...just to let you know a couple of things we're
doing:
Bill Joy wrote:
> Scott, I took a look at the source code for the connection logic in the
> JGroups implementation. I realize it is not done, but thought I would bring
> up the following issues that I noticed.
>
> One is that it uses the default stacks.xml file provided with JGroups to
> define the protocol. A plugin should be able to provide its own protocol
> definitions when initializing a JChannel.
Very true. I'm working on a URI/ID spec for the ECF jgroups provider
that will allow custom protocol definitions along with using those in
stacks.xml. There doesn't seem to be an exiting URI spec for jgroups
currently...I'm thinking something like this:
jgroups:<stackname>://<mcastip>:<mcastport>/<channelName >&stackConfig=<config
url>
Where stackname (if omitted) has a default of 'udp', stackConfig has a
default of 'stacks.xml'.
I'm actually engaged in a dialog with Bela Ban about what a jgroups ID
syntax would be on the javagroups users/dev mailing list. I would be
very interested in your and other's thoughts about this:
https://lists.sourceforge.net/lists/listinfo/javagroups-user s
See the archive and please participate in discussion and I will
implement something that works.
>
> Another issue is that the implementation seems only to support Eclipse
> peers. I'd like to see an option so a plugin can create its own
> PullPushAdapter to send/receive messages. Currently the JChannel is
> not exposed which prevents accessing this API.
Not sure I understand your request Bill.
I *think* that as long as the JChannel has access to the same stack
configuration/same channel name/and same low-level classes (i.e. those
in org.eclipse.ecf.provider.jgroups.connection...which are public), then
it should be able to connect to/send/receive messages on that
channel...even interact with Equinox-based (Eclipse is not required BTW).
The ECF provider should ignore messages which are not of a relevant
type...I haven't tested this yet, but if this doesn't work then I would
consider it a bug. I don't *think* it's necessary to expose the
JChannel instance directly. It would only be necessary if the
application wanted to use the ECF authentication and group membership
APIs...and at that point it pretty much becomes an IContainer.
In any event (so to speak), let me know if I'm misinterpreting your
desire or needs here.
BTW Bill...any chance that your company (Borland) could be convinced to
officially participate in ECF...especially given the recent directions
in Eclipse-based collaboration:
http://www.borland.com/us/company/news/press_releases/2005/0 5_31_05_borland_announces_jbuilder_product_roadmap.html
For example, we'd love to have a provider based upon Borland's
server/protocol for ECF...and even better would love to have Borland's
participation, support, and even perhaps contributions for ECF, Mylar
integration, etc.
Thanks,
Scott
>
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:46E35D3E.4020106@composent.com...
>> Hi Folks,
>>
>> ECF 1.1 now available at normal locations. See below for links.
>>
>> The New and Noteworthy is not done yet, so committers please send any
>> additions to ecf-dev@eclipse.org i.e. if the placeholders that are there
>> have missed something that you feel the N&N should include.
>>
>> Particularly noteworthy was the work of Google SOC 2007 student Moritz
>> Post on the Jingle VOIP protocol:
>> http://wiki.eclipse.org/VoIP_via_the_ECF_Call_API_and_the_Ji ngle_Protocol
>>
>> ECF was also the beneficiary of some great contributions for the Eclipse
>> BugDay. Thanks to all who participated and the committers who
>> supported/reviewed.
>>
>> See also the ECF OSU Open Source Lab site...for significant additions for
>> JMS-based communications: a new Websphere CE provider, as a new BEA
>> Weblogic-based JMS provider, and a JGroups (reliable multicast) based
>> provider. Along with JXTA, JGroups is a 'true' peer-to-peer provider.
>> It's not done yet, but is working. Further, all of these new providers
>> implement ECF datashare, the remote OSGI services API, and the ECF shared
>> object API.
>>
>> Thanks,
>>
>> Scott
>>
>> Download and Update Site info: http://www.eclipse.org/ecf/downloads.php
>> New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html
>> OSU OSL: http://ecf1.osuosl.org
>> CVS tag for release: v20070908-1720
>>
>
>
>
>
>
>
>
>
>
>
|
|
|
| Re: ECF 1.1 available [message #619568 is a reply to message #619567] |
Mon, 10 September 2007 02:40 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Hi Scott, thanks for the response.
You might want to consider in your spec that JGroups also supports unicast
messages.
Regarding the request for access to JChannel, I have an legacy application
to maintain and not all peers are running on Eclipse. In that
implementation, "services" are registered with a peer manager and each has
its own unique string identifier and PullPushAdapter to send/receive
messages via the JChannel to/from the identical service running on other
peers.
It looks to me like the ECF implementation for this type of connection is
only intended to provide the equivalent of a single "service" (apparently
one that supports group chat). I need access to the JChannel to create an
PullPushAdapter instance for each of the legacy services.
Note that Borland/CodeGear has already made a contribution to Mylar (now
Mylyn) of an XPlanner connector and is also maintaining that codebase.
http://blogs.codegear.com/ravi/archive/2007/03/07/32778.aspx
http://jroller.com/eu/entry/xplanner_connector_for_mylyn
Regarding ECF participation, I'll send an email around again (this time we
are under CodeGear management) and see what comes up. I'll contact you
privately when I get some answers.
"Scott Lewis" <slewis@composent.com> wrote in message
news:46E489BC.2010401@composent.com...
> Hi Bill,
>
> Thanks for the comments...just to let you know a couple of things we're
> doing:
>
> Bill Joy wrote:
>> Scott, I took a look at the source code for the connection logic in the
>> JGroups implementation. I realize it is not done, but thought I would
>> bring
>> up the following issues that I noticed.
>>
>> One is that it uses the default stacks.xml file provided with JGroups to
>> define the protocol. A plugin should be able to provide its own protocol
>> definitions when initializing a JChannel.
>
> Very true. I'm working on a URI/ID spec for the ECF jgroups provider that
> will allow custom protocol definitions along with using those in
> stacks.xml. There doesn't seem to be an exiting URI spec for jgroups
> currently...I'm thinking something like this:
>
> jgroups:<stackname>://<mcastip>:<mcastport>/<channelName >&stackConfig=<config
> url>
>
> Where stackname (if omitted) has a default of 'udp', stackConfig has a
> default of 'stacks.xml'.
>
> I'm actually engaged in a dialog with Bela Ban about what a jgroups ID
> syntax would be on the javagroups users/dev mailing list. I would be very
> interested in your and other's thoughts about this:
>
> https://lists.sourceforge.net/lists/listinfo/javagroups-user s
>
> See the archive and please participate in discussion and I will implement
> something that works.
>
>>
>> Another issue is that the implementation seems only to support Eclipse
>> peers. I'd like to see an option so a plugin can create its own
>> PullPushAdapter to send/receive messages. Currently the JChannel is
>> not exposed which prevents accessing this API.
>
> Not sure I understand your request Bill.
>
> I *think* that as long as the JChannel has access to the same stack
> configuration/same channel name/and same low-level classes (i.e. those in
> org.eclipse.ecf.provider.jgroups.connection...which are public), then it
> should be able to connect to/send/receive messages on that channel...even
> interact with Equinox-based (Eclipse is not required BTW).
>
> The ECF provider should ignore messages which are not of a relevant
> type...I haven't tested this yet, but if this doesn't work then I would
> consider it a bug. I don't *think* it's necessary to expose the JChannel
> instance directly. It would only be necessary if the application wanted
> to use the ECF authentication and group membership APIs...and at that
> point it pretty much becomes an IContainer.
>
> In any event (so to speak), let me know if I'm misinterpreting your desire
> or needs here.
>
> BTW Bill...any chance that your company (Borland) could be convinced to
> officially participate in ECF...especially given the recent directions in
> Eclipse-based collaboration:
> http://www.borland.com/us/company/news/press_releases/2005/0 5_31_05_borland_announces_jbuilder_product_roadmap.html
>
> For example, we'd love to have a provider based upon Borland's
> server/protocol for ECF...and even better would love to have Borland's
> participation, support, and even perhaps contributions for ECF, Mylar
> integration, etc.
>
> Thanks,
>
> Scott
>
>
>>
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:46E35D3E.4020106@composent.com...
>>> Hi Folks,
>>>
>>> ECF 1.1 now available at normal locations. See below for links.
>>>
>>> The New and Noteworthy is not done yet, so committers please send any
>>> additions to ecf-dev@eclipse.org i.e. if the placeholders that are there
>>> have missed something that you feel the N&N should include.
>>>
>>> Particularly noteworthy was the work of Google SOC 2007 student Moritz
>>> Post on the Jingle VOIP protocol:
>>> http://wiki.eclipse.org/VoIP_via_the_ECF_Call_API_and_the_Ji ngle_Protocol
>>>
>>> ECF was also the beneficiary of some great contributions for the Eclipse
>>> BugDay. Thanks to all who participated and the committers who
>>> supported/reviewed.
>>>
>>> See also the ECF OSU Open Source Lab site...for significant additions
>>> for
>>> JMS-based communications: a new Websphere CE provider, as a new BEA
>>> Weblogic-based JMS provider, and a JGroups (reliable multicast) based
>>> provider. Along with JXTA, JGroups is a 'true' peer-to-peer provider.
>>> It's not done yet, but is working. Further, all of these new providers
>>> implement ECF datashare, the remote OSGI services API, and the ECF
>>> shared
>>> object API.
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>> Download and Update Site info: http://www.eclipse.org/ecf/downloads.php
>>> New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html
>>> OSU OSL: http://ecf1.osuosl.org
>>> CVS tag for release: v20070908-1720
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
|
|
|
| Re: ECF 1.1 available [message #619569 is a reply to message #619568] |
Mon, 10 September 2007 03:06 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> Hi Scott, thanks for the response.
>
> You might want to consider in your spec that JGroups also supports unicast
> messages.
Yeah, I want the ID/URI spec to support any transport jgroups support.
Please anyone that has any comments/thoughts about the format of the
URI/ID participate in the discussion on the javagroups-users mailing list.
>
> Regarding the request for access to JChannel, I have an legacy application
> to maintain and not all peers are running on Eclipse. In that
> implementation, "services" are registered with a peer manager and each has
> its own unique string identifier and PullPushAdapter to send/receive
> messages via the JChannel to/from the identical service running on other
> peers.
>
> It looks to me like the ECF implementation for this type of connection is
> only intended to provide the equivalent of a single "service" (apparently
> one that supports group chat). I need access to the JChannel to create an
> PullPushAdapter instance for each of the legacy services.
I would be happy to expose a public accessor for the JChannel (in the
AbstractJGroupsConnection in the JGroupsClient/ManagerContainer. But of
course, your code will have to have knowledge of the type of IContainer
(JGroupsContainer) and cast to that type. Work for you?
BTW, you and others might be interested in the ECF 'remoteservices' API
for registering/finding and invoking (asynch or synch) OSGI services.
The API 'looks' a lot like the normal OSGi services API (i.e.
IRemoteServicesContainerAdapter vs. BundleContext, and
IRemoteServiceReference vs ServiceReference) and also includes both
proxy-based and message based remote invocation styles (see
IRemoteService interface). It's got javadocs here:
http://wiki.eclipse.org/ECF_API_Docs#Remote_Services_API
Note that ECF makes this API completely transport independent, and we
now have the following impls that support it:
ECF Generic (ecftcp)
Websphere CE/ActiveMQ JMS
Weblogic JMS
JGroups
XMPP
Also, it's small in code size, and supports CDC 1.0/Foundation 1.0 EEs.
There's also a test plugin that includes the remoteservices API
testing for jgroups provider in <ecf osuosl anon CVS
module>/tests/org.eclipse.ecf.tests.provider.jgroups.
I'm also persuing interating with the OSGI enterprise experts groups, as
a lot of thinking is now going on for remote OSGi, and I think ECF's
remoteservices API could provide some value for those efforts (e.g. real
transport independence).
>
> Note that Borland/CodeGear has already made a contribution to Mylar (now
> Mylyn) of an XPlanner connector and is also maintaining that codebase.
>
> http://blogs.codegear.com/ravi/archive/2007/03/07/32778.aspx
>
> http://jroller.com/eu/entry/xplanner_connector_for_mylyn
Yeah I've seen that. It's one reason why I think it would be in
Borland's interests to support ECF as well :).
>
> Regarding ECF participation, I'll send an email around again (this time we
> are under CodeGear management) and see what comes up. I'll contact you
> privately when I get some answers.
OK, thanks!
Scott
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:46E489BC.2010401@composent.com...
>> Hi Bill,
>>
>> Thanks for the comments...just to let you know a couple of things we're
>> doing:
>>
>> Bill Joy wrote:
>>> Scott, I took a look at the source code for the connection logic in the
>>> JGroups implementation. I realize it is not done, but thought I would
>>> bring
>>> up the following issues that I noticed.
>>>
>>> One is that it uses the default stacks.xml file provided with JGroups to
>>> define the protocol. A plugin should be able to provide its own protocol
>>> definitions when initializing a JChannel.
>> Very true. I'm working on a URI/ID spec for the ECF jgroups provider that
>> will allow custom protocol definitions along with using those in
>> stacks.xml. There doesn't seem to be an exiting URI spec for jgroups
>> currently...I'm thinking something like this:
>>
>> jgroups:<stackname>://<mcastip>:<mcastport>/<channelName >&stackConfig=<config
>> url>
>>
>> Where stackname (if omitted) has a default of 'udp', stackConfig has a
>> default of 'stacks.xml'.
>>
>> I'm actually engaged in a dialog with Bela Ban about what a jgroups ID
>> syntax would be on the javagroups users/dev mailing list. I would be very
>> interested in your and other's thoughts about this:
>>
>> https://lists.sourceforge.net/lists/listinfo/javagroups-user s
>>
>> See the archive and please participate in discussion and I will implement
>> something that works.
>>
>>> Another issue is that the implementation seems only to support Eclipse
>>> peers. I'd like to see an option so a plugin can create its own
>>> PullPushAdapter to send/receive messages. Currently the JChannel is
>>> not exposed which prevents accessing this API.
>> Not sure I understand your request Bill.
>>
>> I *think* that as long as the JChannel has access to the same stack
>> configuration/same channel name/and same low-level classes (i.e. those in
>> org.eclipse.ecf.provider.jgroups.connection...which are public), then it
>> should be able to connect to/send/receive messages on that channel...even
>> interact with Equinox-based (Eclipse is not required BTW).
>>
>> The ECF provider should ignore messages which are not of a relevant
>> type...I haven't tested this yet, but if this doesn't work then I would
>> consider it a bug. I don't *think* it's necessary to expose the JChannel
>> instance directly. It would only be necessary if the application wanted
>> to use the ECF authentication and group membership APIs...and at that
>> point it pretty much becomes an IContainer.
>>
>> In any event (so to speak), let me know if I'm misinterpreting your desire
>> or needs here.
>>
>> BTW Bill...any chance that your company (Borland) could be convinced to
>> officially participate in ECF...especially given the recent directions in
>> Eclipse-based collaboration:
>> http://www.borland.com/us/company/news/press_releases/2005/0 5_31_05_borland_announces_jbuilder_product_roadmap.html
>>
>> For example, we'd love to have a provider based upon Borland's
>> server/protocol for ECF...and even better would love to have Borland's
>> participation, support, and even perhaps contributions for ECF, Mylar
>> integration, etc.
>>
>> Thanks,
>>
>> Scott
>>
>>
>>>
>>>
>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>> news:46E35D3E.4020106@composent.com...
>>>> Hi Folks,
>>>>
>>>> ECF 1.1 now available at normal locations. See below for links.
>>>>
>>>> The New and Noteworthy is not done yet, so committers please send any
>>>> additions to ecf-dev@eclipse.org i.e. if the placeholders that are there
>>>> have missed something that you feel the N&N should include.
>>>>
>>>> Particularly noteworthy was the work of Google SOC 2007 student Moritz
>>>> Post on the Jingle VOIP protocol:
>>>> http://wiki.eclipse.org/VoIP_via_the_ECF_Call_API_and_the_Ji ngle_Protocol
>>>>
>>>> ECF was also the beneficiary of some great contributions for the Eclipse
>>>> BugDay. Thanks to all who participated and the committers who
>>>> supported/reviewed.
>>>>
>>>> See also the ECF OSU Open Source Lab site...for significant additions
>>>> for
>>>> JMS-based communications: a new Websphere CE provider, as a new BEA
>>>> Weblogic-based JMS provider, and a JGroups (reliable multicast) based
>>>> provider. Along with JXTA, JGroups is a 'true' peer-to-peer provider.
>>>> It's not done yet, but is working. Further, all of these new providers
>>>> implement ECF datashare, the remote OSGI services API, and the ECF
>>>> shared
>>>> object API.
>>>>
>>>> Thanks,
>>>>
>>>> Scott
>>>>
>>>> Download and Update Site info: http://www.eclipse.org/ecf/downloads.php
>>>> New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html
>>>> OSU OSL: http://ecf1.osuosl.org
>>>> CVS tag for release: v20070908-1720
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
|
|
| | |
| Re: ECF 1.1 available [message #619572 is a reply to message #619571] |
Mon, 10 September 2007 03:52 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> I did not realize that class would be accessible to me. Maybe instead you
> could fill in the empty implementation for IAdaptable.getAdapter() so you
> don't have to add a new accessor?
Since the interface class that would be used for IAdaptable (call it
IChannelRetriever), would have to be declared in
org.eclipse.ecf.provider.jgroups (it wouldn't make sense to make it part
of one of the abstract ECF APIs)...it's probably easier to just leave it
as an accessor on JGroupsClient/ManagerContainer. Your code can just
have something that goes
if (container instanceof JGroupsClientContainer) {
// cast and go
Channel c = ((JGroupsClientContainer) container).getJChannel();
} else { //not JGroups
Rather than
IChannelRetriever cr = (IChannelRetriever)
container.getAdapter(IChannelRetriever.class);
if (cr != null) {
// call it
Channel c = cr.getJChannel();
}
In either case, a class (JGroupsClientContainer or IChannelRetriever)
has to be accessed in the org.eclipse.ecf.provider.jgroups plugin, and
therefore your code will have a direct (compile time) dependency on that
plugin. Which is undesirable for building clients that may run on other
IContainer types, but for a legacy client that uses JGroups already it
shouldn't be a problem.
Of course there's also the risk that the jgroups provider (or jgroups
itself) would be more likely to change and break such code...but you run
that risk with any jgroups-specific code anyway.
Scott
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:46E4B797.2030805@composent.com...
>> Hi Bill,
>>
>> Scott Lewis wrote:
>>> Hi Bill,
>>>
>> <stuff deleted>
>>
>>> I would be happy to expose a public accessor for the JChannel (in the
>>> AbstractJGroupsConnection in the JGroupsClient/ManagerContainer. But of
>>> course, your code will have to have knowledge of the type of IContainer
>>> (JGroupsContainer) and cast to that type. Work for you?
>> I've implemented a 'getJChannel()' method on AbstractJGroupsConnection,
>> JGroupsClientContainer, and JGroupsManagerContainer. See the src on
>> ecf1.osuosl.org if you want to look at right away.
>>
>> Scott
>
>
|
|
|
| Re: ECF 1.1 available [message #619578 is a reply to message #619566] |
Mon, 17 September 2007 05:55 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> Scott, I took a look at the source code for the connection logic in the
> JGroups implementation. I realize it is not done, but thought I would bring
> up the following issues that I noticed.
>
> One is that it uses the default stacks.xml file provided with JGroups to
> define the protocol. A plugin should be able to provide its own protocol
> definitions when initializing a JChannel.
Over the past few days, I've added a 'stackConfig' extension point to
the org.eclipse.ecf.provider.jgroups plugin. This ep allows plugins to
define a stack configuration file by pointing to a valid config file.
The stack config can then be referred to in the jgroups URI (e.g. if the
id in the stackConfig extension is org.foobar.mystackconfig):
jgroups:///channelName?stackName=myname&stackConfigID=or g.foobar.mystackconfig
Scott
>
> Another issue is that the implementation seems only to support Eclipse
> peers. I'd like to see an option so a plugin can create its own
> PullPushAdapter to send/receive messages. Currently the JChannel is
> not exposed which prevents accessing this API.
>
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:46E35D3E.4020106@composent.com...
>> Hi Folks,
>>
>> ECF 1.1 now available at normal locations. See below for links.
>>
>> The New and Noteworthy is not done yet, so committers please send any
>> additions to ecf-dev@eclipse.org i.e. if the placeholders that are there
>> have missed something that you feel the N&N should include.
>>
>> Particularly noteworthy was the work of Google SOC 2007 student Moritz
>> Post on the Jingle VOIP protocol:
>> http://wiki.eclipse.org/VoIP_via_the_ECF_Call_API_and_the_Ji ngle_Protocol
>>
>> ECF was also the beneficiary of some great contributions for the Eclipse
>> BugDay. Thanks to all who participated and the committers who
>> supported/reviewed.
>>
>> See also the ECF OSU Open Source Lab site...for significant additions for
>> JMS-based communications: a new Websphere CE provider, as a new BEA
>> Weblogic-based JMS provider, and a JGroups (reliable multicast) based
>> provider. Along with JXTA, JGroups is a 'true' peer-to-peer provider.
>> It's not done yet, but is working. Further, all of these new providers
>> implement ECF datashare, the remote OSGI services API, and the ECF shared
>> object API.
>>
>> Thanks,
>>
>> Scott
>>
>> Download and Update Site info: http://www.eclipse.org/ecf/downloads.php
>> New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html
>> OSU OSL: http://ecf1.osuosl.org
>> CVS tag for release: v20070908-1720
>>
>
>
>
>
>
>
>
>
>
>
|
|
|
| Re: ECF 1.1 available [message #619597 is a reply to message #619565] |
Mon, 01 October 2007 20:14 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Scott, I am trying to get my JMDNS implementation working on ECF 1.1 and
having problems. I see that build has been revoked for administrative
reasons but it was still present Friday on the Europa update site when our
integration team pulled it in.
After fixing some compile errors and new deprecation warnings due to 1.1
changes, I noticed that the JMDNS namespace name was changed so I updated
that.
Now I try my IDFactory.getDefault().createID(String, Object[]) and get an
exception thrown because the namespace name "ecf.namespace.jmdns" is not in
the hash table.
I dumped the hash table and see these entries (the ones that were not null):
ecf.xmpps=Namespace[name=ecf.xmpps;scheme=xmpps;description= ],
ecf.bittorrent=Namespace[name=ecf.bittorrent;scheme=torrent; description=],
ecfircid=Namespace[name=ecfircid;scheme=irc;description=],
org.eclipse.ecf.core.identity.StringID=Namespace[name=org.ec lipse.ecf.core.identity.StringID;scheme=org.eclipse.ecf.core .identity.StringID;description=],
org.eclipse.ecf.core.identity.LongID=Namespace[name=org.ecli pse.ecf.core.identity.LongID;scheme=class
org.eclipse.ecf.core.identity.LongID;description=],
ecf.xmpp=Namespace[name=ecf.xmpp;scheme=xmpp;description=],
xmpp.room.jive=Namespace[name=xmpp.room.jive;scheme=xmpp.muc ;description=],
org.eclipse.ecf.core.identity.GUID=Namespace[name=org.eclips e.ecf.core.identity.GUID;scheme=org.eclipse.ecf.core.identit y.GUID;description=],
ecf.msn.msnp=Namespace[name=ecf.msn.msnp;scheme=msn;descript ion=]
No JMDNS entry with either the old or new name. I looked at the jmdns
plugin and see
org.eclipse.ecf.provider.jmdns_1.0.500.v20070908-1720.jar
Why isn't the JMDNS plugin getting loaded? Is there some additional thing I
have to do now that I missed?
|
|
|
| Re: ECF 1.1 available [message #619598 is a reply to message #619597] |
Mon, 01 October 2007 22:14 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> Scott, I am trying to get my JMDNS implementation working on ECF 1.1 and
> having problems. I see that build has been revoked for administrative
> reasons but it was still present Friday on the Europa update site when our
> integration team pulled it in.
>
> After fixing some compile errors and new deprecation warnings due to 1.1
> changes, I noticed that the JMDNS namespace name was changed so I updated
> that.
>
> Now I try my IDFactory.getDefault().createID(String, Object[]) and get an
> exception thrown because the namespace name "ecf.namespace.jmdns" is not in
> the hash table.
Hmmm. Very strange. I just installed a fresh copy of eclipse 3.4m2 and
then used the ECF europa update to install all of ECF from here:
http://download.eclipse.org/technology/ecf/europa-update
(this is the source of the ECF project update site contributions for
Europa).
Then in this new installation I created a new plugin project with deps
on org.eclipse.ecf, org.eclipse.ecf.discovery bundles and wrote this code:
try {
ID newID =
IDFactory.getDefault().createID(IDFactory.getDefault().getNa mespaceByName( "ecf.namespace.jmdns"),"_ecftcp._tcp.local.");
System.out.println("id="+newID);
System.out.println("namespaces="+IDFactory.getDefault().getNamespaces());
} catch (IDCreateException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (SecurityException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
And this works just fine i.e. when run produces console output:
id=ServiceID[type=_ecftcp._tcp.local.;name=null;full=_ecftcp ._tcp.local.]
namespaces=[Namespace[name=ecf.msn.msnp;scheme=msn;descripti on=],
Namespace[name=org.eclipse.ecf.core.identity.GUID;scheme=org .eclipse.ecf.core.identity.GUID;description=],
Namespace[name=xmpp.room.jive;scheme=xmpp.muc;description=],
Namespace[name=ecf.xmpp;scheme=xmpp;description=],
Namespace[name=org.eclipse.ecf.core.identity.LongID;scheme=c lass
org.eclipse.ecf.core.identity.LongID;description=],
Namespace[name=ecf.namespace.jmdns;scheme=jmdns;description= ],
Namespace[name=org.eclipse.ecf.core.identity.StringID;scheme =org.eclipse.ecf.core.identity.StringID;description=],
Namespace[name=ecf.provider.filetransfer;scheme=ecf.provider .filetransfer;description=],
Namespace[name=ecfircid;scheme=irc;description=],
Namespace[name=ecf.bittorrent;scheme=torrent;description=],
Namespace[name=ecf.xmpps;scheme=xmpps;description=]]
>
> I dumped the hash table and see these entries (the ones that were not null):
>
> ecf.xmpps=Namespace[name=ecf.xmpps;scheme=xmpps;description= ],
> ecf.bittorrent=Namespace[name=ecf.bittorrent;scheme=torrent; description=],
> ecfircid=Namespace[name=ecfircid;scheme=irc;description=],
> org.eclipse.ecf.core.identity.StringID=Namespace[name=org.ec lipse.ecf.core.identity.StringID;scheme=org.eclipse.ecf.core .identity.StringID;description=],
> org.eclipse.ecf.core.identity.LongID=Namespace[name=org.ecli pse.ecf.core.identity.LongID;scheme=class
> org.eclipse.ecf.core.identity.LongID;description=],
> ecf.xmpp=Namespace[name=ecf.xmpp;scheme=xmpp;description=],
> xmpp.room.jive=Namespace[name=xmpp.room.jive;scheme=xmpp.muc ;description=],
> org.eclipse.ecf.core.identity.GUID=Namespace[name=org.eclips e.ecf.core.identity.GUID;scheme=org.eclipse.ecf.core.identit y.GUID;description=],
> ecf.msn.msnp=Namespace[name=ecf.msn.msnp;scheme=msn;descript ion=]
>
> No JMDNS entry with either the old or new name. I looked at the jmdns
> plugin and see
>
> org.eclipse.ecf.provider.jmdns_1.0.500.v20070908-1720.jar
I also see the plugin in the Eclipse plugin list (i.e. Help->About
Eclipse SDK->Plugin Details. Is this where you are seeing it also?
Perhaps you could also look at the console try to see what state the
jmdns provider plugin is in there (i.e. resolved, installed, etc).
>
> Why isn't the JMDNS plugin getting loaded? Is there some additional thing I
> have to do now that I missed?
I don't think so...I'm currently puzzled (since I can't reproduce).
Is it possible that you have a conflicting/more recent version of the
jmdns plugin in your workspace?
Please let me know, and we'll figure out.
BTW, there are additional discovery API additions and changes coming
(not large ones, but significant). See following bugs for info or to
comment/critique (please!):
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204423
https://bugs.eclipse.org/bugs/show_bug.cgi?id=200804
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204433
Scott
|
|
|
| Re: ECF 1.1 available [message #619600 is a reply to message #619598] |
Tue, 02 October 2007 14:46 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
I am running an Eclipse 3.3 refreshed from the Europa site.
The ECF plugins including JMDNS appear in Help | About | Plug-in Details
with no indications of problems. I don't see any pertinent errors or
warnings in the error log.
As an experiment I tried adding the following code to my plugin:
JMDNSNamespace namespace = new JMDNSNamespace();
namespace.initialize("ecf.namespace.jmdns", "jmdns");
IDFactory.getDefault().addNamespace(namespace);
and this did get around the namespace problem. However there was
an NPE in a thread running JmDNS.SocketListener and I was unable to start
a session with an older version of Eclipse.
Exception in thread "JmDNS.SocketListener" java.lang.NullPointerException
at javax.jmdns.JmDNS.incrementName(JmDNS.java:819)
at javax.jmdns.DNSRecord$Service.handleQuery(DNSRecord.java:609 )
at javax.jmdns.JmDNS.handleQuery(JmDNS.java:1034)
at javax.jmdns.JmDNS.access$4(JmDNS.java:1019)
at javax.jmdns.JmDNS$SocketListener.run(JmDNS.java:1146)
at java.lang.Thread.run(Thread.java:595)
"Scott Lewis" <slewis@composent.com> wrote in message
news:4701713D.3050008@composent.com...
> Hi Bill,
>
> Bill Joy wrote:
>> Scott, I am trying to get my JMDNS implementation working on ECF 1.1 and
>> having problems. I see that build has been revoked for administrative
>> reasons but it was still present Friday on the Europa update site when
>> our integration team pulled it in.
>>
>> After fixing some compile errors and new deprecation warnings due to 1.1
>> changes, I noticed that the JMDNS namespace name was changed so I
>> updated that.
>>
>> Now I try my IDFactory.getDefault().createID(String, Object[]) and get an
>> exception thrown because the namespace name "ecf.namespace.jmdns" is not
>> in the hash table.
>
>
> Hmmm. Very strange. I just installed a fresh copy of eclipse 3.4m2 and
> then used the ECF europa update to install all of ECF from here:
>
> http://download.eclipse.org/technology/ecf/europa-update
>
> (this is the source of the ECF project update site contributions for
> Europa).
>
> Then in this new installation I created a new plugin project with deps on
> org.eclipse.ecf, org.eclipse.ecf.discovery bundles and wrote this code:
>
> try {
> ID newID =
> IDFactory.getDefault().createID(IDFactory.getDefault().getNa mespaceByName( "ecf.namespace.jmdns"),"_ecftcp._tcp.local.");
> System.out.println("id="+newID);
> System.out.println("namespaces="+IDFactory.getDefault().getNamespaces());
> } catch (IDCreateException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (SecurityException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> And this works just fine i.e. when run produces console output:
>
> id=ServiceID[type=_ecftcp._tcp.local.;name=null;full=_ecftcp ._tcp.local.]
> namespaces=[Namespace[name=ecf.msn.msnp;scheme=msn;descripti on=],
> Namespace[name=org.eclipse.ecf.core.identity.GUID;scheme=org .eclipse.ecf.core.identity.GUID;description=],
> Namespace[name=xmpp.room.jive;scheme=xmpp.muc;description=],
> Namespace[name=ecf.xmpp;scheme=xmpp;description=],
> Namespace[name=org.eclipse.ecf.core.identity.LongID;scheme=c lass
> org.eclipse.ecf.core.identity.LongID;description=],
> Namespace[name=ecf.namespace.jmdns;scheme=jmdns;description= ],
> Namespace[name=org.eclipse.ecf.core.identity.StringID;scheme =org.eclipse.ecf.core.identity.StringID;description=],
> Namespace[name=ecf.provider.filetransfer;scheme=ecf.provider .filetransfer;description=],
> Namespace[name=ecfircid;scheme=irc;description=],
> Namespace[name=ecf.bittorrent;scheme=torrent;description=],
> Namespace[name=ecf.xmpps;scheme=xmpps;description=]]
>
>
>>
>> I dumped the hash table and see these entries (the ones that were not
>> null):
>>
>> ecf.xmpps=Namespace[name=ecf.xmpps;scheme=xmpps;description= ],
>> ecf.bittorrent=Namespace[name=ecf.bittorrent;scheme=torrent; description=],
>> ecfircid=Namespace[name=ecfircid;scheme=irc;description=],
>> org.eclipse.ecf.core.identity.StringID=Namespace[name=org.ec lipse.ecf.core.identity.StringID;scheme=org.eclipse.ecf.core .identity.StringID;description=],
>> org.eclipse.ecf.core.identity.LongID=Namespace[name=org.ecli pse.ecf.core.identity.LongID;scheme=class
>> org.eclipse.ecf.core.identity.LongID;description=],
>> ecf.xmpp=Namespace[name=ecf.xmpp;scheme=xmpp;description=],
>> xmpp.room.jive=Namespace[name=xmpp.room.jive;scheme=xmpp.muc ;description=],
>> org.eclipse.ecf.core.identity.GUID=Namespace[name=org.eclips e.ecf.core.identity.GUID;scheme=org.eclipse.ecf.core.identit y.GUID;description=],
>> ecf.msn.msnp=Namespace[name=ecf.msn.msnp;scheme=msn;descript ion=]
>>
>> No JMDNS entry with either the old or new name. I looked at the jmdns
>> plugin and see
>>
>> org.eclipse.ecf.provider.jmdns_1.0.500.v20070908-1720.jar
>
>
> I also see the plugin in the Eclipse plugin list (i.e. Help->About Eclipse
> SDK->Plugin Details. Is this where you are seeing it also?
>
> Perhaps you could also look at the console try to see what state the jmdns
> provider plugin is in there (i.e. resolved, installed, etc).
>
>>
>> Why isn't the JMDNS plugin getting loaded? Is there some additional
>> thing I have to do now that I missed?
>
> I don't think so...I'm currently puzzled (since I can't reproduce).
>
> Is it possible that you have a conflicting/more recent version of the
> jmdns plugin in your workspace?
>
> Please let me know, and we'll figure out.
>
> BTW, there are additional discovery API additions and changes coming (not
> large ones, but significant). See following bugs for info or to
> comment/critique (please!):
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204423
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=200804
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204433
>
> Scott
|
|
|
| Re: ECF 1.1 available [message #619601 is a reply to message #619600] |
Tue, 02 October 2007 15:17 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
This is (unfortunately) mystifying for me, as I can't seem to reproduce.
Do you have an old (or any other) version of ECF installed in Eclipse?
Any ECF plugins in your workspace?
Could you start eclipse with the console ( -console on command line) and
in the console check the state of all plugins with
osgi> ss
<produces lots of output>
osgi> bundle org.eclipse.ecf.provider.jmdns
<produces lots of output>
osgi> headers org.eclipse.ecf.provider.jmdns
<produces headers for that bundle>
osgi> status org.eclipse.ecf.provider.jmdns
<produces status info for that bundle>
Also if you could run your test code and then give the console commands
above as well that might tell us something to go on.
Thanks,
Scott
Bill Joy wrote:
> I am running an Eclipse 3.3 refreshed from the Europa site.
>
> The ECF plugins including JMDNS appear in Help | About | Plug-in Details
> with no indications of problems. I don't see any pertinent errors or
> warnings in the error log.
>
> As an experiment I tried adding the following code to my plugin:
>
> JMDNSNamespace namespace = new JMDNSNamespace();
> namespace.initialize("ecf.namespace.jmdns", "jmdns");
> IDFactory.getDefault().addNamespace(namespace);
>
> and this did get around the namespace problem. However there was
> an NPE in a thread running JmDNS.SocketListener and I was unable to start
> a session with an older version of Eclipse.
>
> Exception in thread "JmDNS.SocketListener" java.lang.NullPointerException
> at javax.jmdns.JmDNS.incrementName(JmDNS.java:819)
> at javax.jmdns.DNSRecord$Service.handleQuery(DNSRecord.java:609 )
> at javax.jmdns.JmDNS.handleQuery(JmDNS.java:1034)
> at javax.jmdns.JmDNS.access$4(JmDNS.java:1019)
> at javax.jmdns.JmDNS$SocketListener.run(JmDNS.java:1146)
> at java.lang.Thread.run(Thread.java:595)
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:4701713D.3050008@composent.com...
>> Hi Bill,
>>
>> Bill Joy wrote:
>>> Scott, I am trying to get my JMDNS implementation working on ECF 1.1 and
>>> having problems. I see that build has been revoked for administrative
>>> reasons but it was still present Friday on the Europa update site when
>>> our integration team pulled it in.
>>>
>>> After fixing some compile errors and new deprecation warnings due to 1.1
>>> changes, I noticed that the JMDNS namespace name was changed so I
>>> updated that.
>>>
>>> Now I try my IDFactory.getDefault().createID(String, Object[]) and get an
>>> exception thrown because the namespace name "ecf.namespace.jmdns" is not
>>> in the hash table.
>>
>> Hmmm. Very strange. I just installed a fresh copy of eclipse 3.4m2 and
>> then used the ECF europa update to install all of ECF from here:
>>
>> http://download.eclipse.org/technology/ecf/europa-update
>>
>> (this is the source of the ECF project update site contributions for
>> Europa).
>>
>> Then in this new installation I created a new plugin project with deps on
>> org.eclipse.ecf, org.eclipse.ecf.discovery bundles and wrote this code:
>>
>> try {
>> ID newID =
>> IDFactory.getDefault().createID(IDFactory.getDefault().getNa mespaceByName( "ecf.namespace.jmdns"),"_ecftcp._tcp.local.");
>> System.out.println("id="+newID);
>> System.out.println("namespaces="+IDFactory.getDefault().getNamespaces());
>> } catch (IDCreateException e) {
>> // TODO Auto-generated catch block
>> e.printStackTrace();
>> } catch (SecurityException e) {
>> // TODO Auto-generated catch block
>> e.printStackTrace();
>> }
>>
>> And this works just fine i.e. when run produces console output:
>>
>> id=ServiceID[type=_ecftcp._tcp.local.;name=null;full=_ecftcp ._tcp.local.]
>> namespaces=[Namespace[name=ecf.msn.msnp;scheme=msn;descripti on=],
>> Namespace[name=org.eclipse.ecf.core.identity.GUID;scheme=org .eclipse.ecf.core.identity.GUID;description=],
>> Namespace[name=xmpp.room.jive;scheme=xmpp.muc;description=],
>> Namespace[name=ecf.xmpp;scheme=xmpp;description=],
>> Namespace[name=org.eclipse.ecf.core.identity.LongID;scheme=c lass
>> org.eclipse.ecf.core.identity.LongID;description=],
>> Namespace[name=ecf.namespace.jmdns;scheme=jmdns;description= ],
>> Namespace[name=org.eclipse.ecf.core.identity.StringID;scheme =org.eclipse.ecf.core.identity.StringID;description=],
>> Namespace[name=ecf.provider.filetransfer;scheme=ecf.provider .filetransfer;description=],
>> Namespace[name=ecfircid;scheme=irc;description=],
>> Namespace[name=ecf.bittorrent;scheme=torrent;description=],
>> Namespace[name=ecf.xmpps;scheme=xmpps;description=]]
>>
>>
>>> I dumped the hash table and see these entries (the ones that were not
>>> null):
>>>
>>> ecf.xmpps=Namespace[name=ecf.xmpps;scheme=xmpps;description= ],
>>> ecf.bittorrent=Namespace[name=ecf.bittorrent;scheme=torrent; description=],
>>> ecfircid=Namespace[name=ecfircid;scheme=irc;description=],
>>> org.eclipse.ecf.core.identity.StringID=Namespace[name=org.ec lipse.ecf.core.identity.StringID;scheme=org.eclipse.ecf.core .identity.StringID;description=],
>>> org.eclipse.ecf.core.identity.LongID=Namespace[name=org.ecli pse.ecf.core.identity.LongID;scheme=class
>>> org.eclipse.ecf.core.identity.LongID;description=],
>>> ecf.xmpp=Namespace[name=ecf.xmpp;scheme=xmpp;description=],
>>> xmpp.room.jive=Namespace[name=xmpp.room.jive;scheme=xmpp.muc ;description=],
>>> org.eclipse.ecf.core.identity.GUID=Namespace[name=org.eclips e.ecf.core.identity.GUID;scheme=org.eclipse.ecf.core.identit y.GUID;description=],
>>> ecf.msn.msnp=Namespace[name=ecf.msn.msnp;scheme=msn;descript ion=]
>>>
>>> No JMDNS entry with either the old or new name. I looked at the jmdns
>>> plugin and see
>>>
>>> org.eclipse.ecf.provider.jmdns_1.0.500.v20070908-1720.jar
>>
>> I also see the plugin in the Eclipse plugin list (i.e. Help->About Eclipse
>> SDK->Plugin Details. Is this where you are seeing it also?
>>
>> Perhaps you could also look at the console try to see what state the jmdns
>> provider plugin is in there (i.e. resolved, installed, etc).
>>
>>> Why isn't the JMDNS plugin getting loaded? Is there some additional
>>> thing I have to do now that I missed?
>> I don't think so...I'm currently puzzled (since I can't reproduce).
>>
>> Is it possible that you have a conflicting/more recent version of the
>> jmdns plugin in your workspace?
>>
>> Please let me know, and we'll figure out.
>>
>> BTW, there are additional discovery API additions and changes coming (not
>> large ones, but significant). See following bugs for info or to
>> comment/critique (please!):
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204423
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=200804
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204433
>>
>> Scott
>
>
>
|
|
|
| Re: ECF 1.1 available [message #619602 is a reply to message #619601] |
Tue, 02 October 2007 16:22 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
I sent this output to you directly.
"Scott Lewis" <slewis@composent.com> wrote in message
news:47026124.1010400@composent.com...
> Hi Bill,
>
> This is (unfortunately) mystifying for me, as I can't seem to reproduce.
>
> Do you have an old (or any other) version of ECF installed in Eclipse?
> Any ECF plugins in your workspace?
>
> Could you start eclipse with the console ( -console on command line) and
> in the console check the state of all plugins with
>
> osgi> ss
> <produces lots of output>
>
> osgi> bundle org.eclipse.ecf.provider.jmdns
> <produces lots of output>
>
> osgi> headers org.eclipse.ecf.provider.jmdns
> <produces headers for that bundle>
>
> osgi> status org.eclipse.ecf.provider.jmdns
> <produces status info for that bundle>
>
> Also if you could run your test code and then give the console commands
> above as well that might tell us something to go on.
>
> Thanks,
>
> Scott
>
>
> Bill Joy wrote:
>> I am running an Eclipse 3.3 refreshed from the Europa site.
>>
>> The ECF plugins including JMDNS appear in Help | About | Plug-in Details
>> with no indications of problems. I don't see any pertinent errors or
>> warnings in the error log.
>>
>> As an experiment I tried adding the following code to my plugin:
>>
>> JMDNSNamespace namespace = new JMDNSNamespace();
>> namespace.initialize("ecf.namespace.jmdns", "jmdns");
>> IDFactory.getDefault().addNamespace(namespace);
>>
>> and this did get around the namespace problem. However there was
>> an NPE in a thread running JmDNS.SocketListener and I was unable to start
>> a session with an older version of Eclipse.
>>
>> Exception in thread "JmDNS.SocketListener" java.lang.NullPointerException
>> at javax.jmdns.JmDNS.incrementName(JmDNS.java:819)
>> at javax.jmdns.DNSRecord$Service.handleQuery(DNSRecord.java:609 )
>> at javax.jmdns.JmDNS.handleQuery(JmDNS.java:1034)
>> at javax.jmdns.JmDNS.access$4(JmDNS.java:1019)
>> at javax.jmdns.JmDNS$SocketListener.run(JmDNS.java:1146)
>> at java.lang.Thread.run(Thread.java:595)
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:4701713D.3050008@composent.com...
>>> Hi Bill,
>>>
>>> Bill Joy wrote:
>>>> Scott, I am trying to get my JMDNS implementation working on ECF 1.1
>>>> and
>>>> having problems. I see that build has been revoked for administrative
>>>> reasons but it was still present Friday on the Europa update site when
>>>> our integration team pulled it in.
>>>>
>>>> After fixing some compile errors and new deprecation warnings due to
>>>> 1.1
>>>> changes, I noticed that the JMDNS namespace name was changed so I
>>>> updated that.
>>>>
>>>> Now I try my IDFactory.getDefault().createID(String, Object[]) and get
>>>> an
>>>> exception thrown because the namespace name "ecf.namespace.jmdns" is
>>>> not
>>>> in the hash table.
>>>
>>> Hmmm. Very strange. I just installed a fresh copy of eclipse 3.4m2 and
>>> then used the ECF europa update to install all of ECF from here:
>>>
>>> http://download.eclipse.org/technology/ecf/europa-update
>>>
>>> (this is the source of the ECF project update site contributions for
>>> Europa).
>>>
>>> Then in this new installation I created a new plugin project with deps
>>> on
>>> org.eclipse.ecf, org.eclipse.ecf.discovery bundles and wrote this code:
>>>
>>> try {
>>> ID newID =
>>> IDFactory.getDefault().createID(IDFactory.getDefault().getNa mespaceByName( "ecf.namespace.jmdns"),"_ecftcp._tcp.local.");
>>> System.out.println("id="+newID);
>>> System.out.println("namespaces="+IDFactory.getDefault().getNamespaces());
>>> } catch (IDCreateException e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> } catch (SecurityException e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> And this works just fine i.e. when run produces console output:
>>>
>>> id=ServiceID[type=_ecftcp._tcp.local.;name=null;full=_ecftcp ._tcp.local.]
>>> namespaces=[Namespace[name=ecf.msn.msnp;scheme=msn;descripti on=],
>>> Namespace[name=org.eclipse.ecf.core.identity.GUID;scheme=org .eclipse.ecf.core.identity.GUID;description=],
>>> Namespace[name=xmpp.room.jive;scheme=xmpp.muc;description=],
>>> Namespace[name=ecf.xmpp;scheme=xmpp;description=],
>>> Namespace[name=org.eclipse.ecf.core.identity.LongID;scheme=c lass
>>> org.eclipse.ecf.core.identity.LongID;description=],
>>> Namespace[name=ecf.namespace.jmdns;scheme=jmdns;description= ],
>>> Namespace[name=org.eclipse.ecf.core.identity.StringID;scheme =org.eclipse.ecf.core.identity.StringID;description=],
>>> Namespace[name=ecf.provider.filetransfer;scheme=ecf.provider .filetransfer;description=],
>>> Namespace[name=ecfircid;scheme=irc;description=],
>>> Namespace[name=ecf.bittorrent;scheme=torrent;description=],
>>> Namespace[name=ecf.xmpps;scheme=xmpps;description=]]
>>>
>>>
>>>> I dumped the hash table and see these entries (the ones that were not
>>>> null):
>>>>
>>>> ecf.xmpps=Namespace[name=ecf.xmpps;scheme=xmpps;description= ],
>>>> ecf.bittorrent=Namespace[name=ecf.bittorrent;scheme=torrent; description=],
>>>> ecfircid=Namespace[name=ecfircid;scheme=irc;description=],
>>>> org.eclipse.ecf.core.identity.StringID=Namespace[name=org.ec lipse.ecf.core.identity.StringID;scheme=org.eclipse.ecf.core .identity.StringID;description=],
>>>> org.eclipse.ecf.core.identity.LongID=Namespace[name=org.ecli pse.ecf.core.identity.LongID;scheme=class
>>>> org.eclipse.ecf.core.identity.LongID;description=],
>>>> ecf.xmpp=Namespace[name=ecf.xmpp;scheme=xmpp;description=],
>>>> xmpp.room.jive=Namespace[name=xmpp.room.jive;scheme=xmpp.muc ;description=],
>>>> org.eclipse.ecf.core.identity.GUID=Namespace[name=org.eclips e.ecf.core.identity.GUID;scheme=org.eclipse.ecf.core.identit y.GUID;description=],
>>>> ecf.msn.msnp=Namespace[name=ecf.msn.msnp;scheme=msn;descript ion=]
>>>>
>>>> No JMDNS entry with either the old or new name. I looked at the jmdns
>>>> plugin and see
>>>>
>>>> org.eclipse.ecf.provider.jmdns_1.0.500.v20070908-1720.jar
>>>
>>> I also see the plugin in the Eclipse plugin list (i.e. Help->About
>>> Eclipse
>>> SDK->Plugin Details. Is this where you are seeing it also?
>>>
>>> Perhaps you could also look at the console try to see what state the
>>> jmdns
>>> provider plugin is in there (i.e. resolved, installed, etc).
>>>
>>>> Why isn't the JMDNS plugin getting loaded? Is there some additional
>>>> thing I have to do now that I missed?
>>> I don't think so...I'm currently puzzled (since I can't reproduce).
>>>
>>> Is it possible that you have a conflicting/more recent version of the
>>> jmdns plugin in your workspace?
>>>
>>> Please let me know, and we'll figure out.
>>>
>>> BTW, there are additional discovery API additions and changes coming
>>> (not
>>> large ones, but significant). See following bugs for info or to
>>> comment/critique (please!):
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204423
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=200804
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204433
>>>
>>> Scott
>>
>>
|
|
|
| |
  |
Goto Forum:
Current Time: Tue Apr 16 10:02:40 GMT 2024
Powered by FUDForum. Page generated in 0.13274 seconds |
] 
Search
Help
Register
Login
Home
