Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: [javagroups-users] JGroups URI for ECF

Sorry about the cross-post, but I wanted to notify both the ECF and JGroups communities about this.

For the moment and just as a starting place, I've implemented a jgroups URI with the syntax described below. This is changeable as time goes on, but I wanted to get something in place as quickly as possible...but would like to settle on a final for this fairly soon. Note this approach follows the URI standard syntax, and is therefore parsable by the class.

jgroups://[<ip address>:<port>]/<channelName>[?stackConfigURL=<url>&stackName=<name>]

So, here are some example URLs:

jgroups:///mychannelname (channelname=mychannelname, stackconfig=stacks.xml, stackname=udp, mcastip=same as in stacks.xml/udp, mcastport=same as in stacks.xml/udp)


(channelname=mychannelname, stackconfig=, stackname=tcp, mcastip=same as in, mcastport=same as in


(channelname=YourChaNnelname/foobar, stackconfig=stacks.xml, stackname=udp, mcastip=, mcastport=45589)


( channel name)

Some thinking still has to go into the handling of the stackConfigURL parameter in the query, as for relative file URLs it's not clear what it should be relative to (e.g. the org.eclipse.ecf.provider.jgroups plugin can't be modified by clients, so that's a poor choice. The default directory is probably a poor choice. The classpath is specific to the plugin, so that won't work. Also it would probably be useful to allow an extension/extension point to be defined/used to contribute configurations). In any event, it's still not clear to me so any suggestions appreciated.

Any comments appreciated.


Scott Lewis wrote:
Hi Bela,

Bela Ban wrote:

Scott Lewis wrote:
I don't think the multicast address and port should be part of the
URI, as they are defined in the stack config.

True, the *defaults* are specified in the stack config, but it seems to
me extremely likely that the ip address/port/channel name are to be
changed frequently on a per-group basis (so that they don't conflict).

But then you should accommodate other (frequently changing) parameters too, like the port for TCP stacks... Maybe you can come up with a generic schme to define these, e.g.

URI?par1=val1&par2=val2 etc where parameters and values would be for example the mcast_addr

Sure...I could/can/possibly will do this, but since the number of parameters is so large I'm a little concerned about the total length of the URI for this approach (I'm not sure if very long URIs are well supported in existing impls...I will check on that).

RE: accomodating other least traditionally, the ip address (mcast or not) and port (either) have been represented via...e.g.

jgroups://<ip address>:<port>

rather than as

jgroups://path?configFile=<whatever>&port=<whatever>, etc

So that's why I was suggesting the mcast IP and port were 'special'.

But I would like to find a simple/small way to encode all the information about config...that's why I was thinking about the stack name/stacks.xml file.

Maybe as an alternative?:


Why not


Well, this could be good, but it still seems a little strange to have the addr and port *not* in the form jgroups://<addr>:<port> since this is how the URI spec expects other sorts of address (although my reading is that any given scheme does not have to follow this parsing convention exactly).

I don't like the fact though that something as central as the config file is relegated to parameter status...

If you use stacks.xml, then you'd also need to define the <config name> to be used within stacks.xml.

True. Perhaps if the file is specified in the query segment, and the
stackName is specified via another 'stackName' variable?


As you can tell, I still sort of like the following because of the




So what about a TCP-based config then ?

I would expect something like:

jgroups:tcp://<tcp address>:<tcp port>/<channelName>

(with stackConfig implicitly assumed to be 'stacks.xml')


Back to the top