RE: Discovery update
Meeraj,
I finally got JXTA working! The problem was that the message being sent
was null...
In JxtaDiscoverService.java the code for sending the message was:
public int sendMessage(final String runtimeId, final XMLStreamReader
content) throws DiscoveryException {
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
So, note that the StaxUtil.serialize(content) method is not assigning
the returned value to the message.
Besides that, remember that when you try to contribute the SCDL (via the
browser), there is an exception since it is trying to send the message
to the peer called slave and there is not such peer in the network.
Therefore, I did another modification to the sendMessage method in order
to send the message to all the peers (just to see if it works). So, the
working piece of code is:
public int sendMessage(String runtimeId, final XMLStreamReader content)
throws DiscoveryException {
runtimeId = null;
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
message = StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
Note that I removed the final keyword to the runtimeId parameter in
order to turn it to null in the first statement of the method (to allow
broadcast of the message).
In addition to that I just modified StaxUtil.serialize(content); for
message = StaxUtil.serialize(content);
And that is all I did and after pressing the Contribute SCDL button, I
saw in both slaves' console window a system.out I added to the
processQuery(ResolverQueryMsg queryMessage) method in
TuscanyQueryHandler.java.
So, now it is important to know why the runtimeId arrives with a value
equal to slave. I had already tried to figure it out and sent you an
email, remember? I am copying it here just in case:
Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Ok, I hope it is all useful and if you need any further help, please do
not hesitate to contact me.
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 25, 2007 5:52 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Thanks Mario. If you have any more queries, pls post to the list.
Ta
Meerj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Date: Sun, 25 Mar 2007 07:53:39 -0700
Meeraj,
You were right, it is not working yet. I am still struggling with it.
I'll come back to you as soon as I have any news about it.
Regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 8:16 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Mario,
By hard-coding the runtime id of the target peer, did the message
actually reached the intended peer? i.e. did you see any log messages
on
the console widow of slave1 or slave2?
Thanks
Meeraj
-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: 23 March 2007 21:02
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Meeraj,
I got the JXTA working for sending messages. However, what I
did was just finding the error and patching it, so I just
Re: Discovery update
On 3/27/07, Antollini, Mario [EMAIL PROTECTED] wrote:
Meeraj,
I finally got JXTA working! The problem was that the message being sent
was null...
In JxtaDiscoverService.java the code for sending the message was:
public int sendMessage(final String runtimeId, final XMLStreamReader
content) throws DiscoveryException {
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
So, note that the StaxUtil.serialize(content) method is not assigning
the returned value to the message.
Besides that, remember that when you try to contribute the SCDL (via the
browser), there is an exception since it is trying to send the message
to the peer called slave and there is not such peer in the network.
Therefore, I did another modification to the sendMessage method in order
to send the message to all the peers (just to see if it works). So, the
working piece of code is:
public int sendMessage(String runtimeId, final XMLStreamReader content)
throws DiscoveryException {
runtimeId = null;
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
message = StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
Note that I removed the final keyword to the runtimeId parameter in
order to turn it to null in the first statement of the method (to allow
broadcast of the message).
In addition to that I just modified StaxUtil.serialize(content); for
message = StaxUtil.serialize(content);
And that is all I did and after pressing the Contribute SCDL button, I
saw in both slaves' console window a system.out I added to the
processQuery(ResolverQueryMsg queryMessage) method in
TuscanyQueryHandler.java.
So, now it is important to know why the runtimeId arrives with a value
equal to slave. I had already tried to figure it out and sent you an
email, remember? I am copying it here just in case:
Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Ok, I hope it is all useful and if you need any further help, please do
not hesitate to contact me.
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 25, 2007 5:52 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Thanks Mario. If you have any more queries, pls post to the list.
Ta
Meerj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Date: Sun, 25 Mar 2007 07:53:39 -0700
Meeraj,
You were right, it is not working yet. I am still struggling with it.
I'll come back to you as soon as I have any news about it.
Regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 8:16 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Mario,
By hard-coding the runtime id of the target peer, did the message
actually reached the intended peer? i.e. did you see any log messages
on
the console widow of slave1 or slave2?
Thanks
Meeraj
-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: 23 March 2007 21:02
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Meeraj,
I got the JXTA working for sending messages. However, what I
did was just finding the error and patching it, so I just
RE: Discovery update
Simon,
I did not realize the problem was there :(
I tried it and you are right.
Thanks a lot for that!
Now it works w/o broadcasting the message.
Mario
-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 12:23 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
On 3/27/07, Antollini, Mario [EMAIL PROTECTED] wrote:
Meeraj,
I finally got JXTA working! The problem was that the message being
sent
was null...
In JxtaDiscoverService.java the code for sending the message was:
public int sendMessage(final String runtimeId, final XMLStreamReader
content) throws DiscoveryException {
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
So, note that the StaxUtil.serialize(content) method is not assigning
the returned value to the message.
Besides that, remember that when you try to contribute the SCDL (via
the
browser), there is an exception since it is trying to send the message
to the peer called slave and there is not such peer in the network.
Therefore, I did another modification to the sendMessage method in
order
to send the message to all the peers (just to see if it works). So,
the
working piece of code is:
public int sendMessage(String runtimeId, final XMLStreamReader
content)
throws DiscoveryException {
runtimeId = null;
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
message = StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
Note that I removed the final keyword to the runtimeId parameter in
order to turn it to null in the first statement of the method (to
allow
broadcast of the message).
In addition to that I just modified StaxUtil.serialize(content); for
message = StaxUtil.serialize(content);
And that is all I did and after pressing the Contribute SCDL button,
I
saw in both slaves' console window a system.out I added to the
processQuery(ResolverQueryMsg queryMessage) method in
TuscanyQueryHandler.java.
So, now it is important to know why the runtimeId arrives with a value
equal to slave. I had already tried to figure it out and sent you an
email, remember? I am copying it here just in case:
Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to
JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Ok, I hope it is all useful and if you need any further help, please
do
not hesitate to contact me.
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 25, 2007 5:52 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Thanks Mario. If you have any more queries, pls post to the list.
Ta
Meerj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Date: Sun, 25 Mar 2007 07:53:39 -0700
Meeraj,
You were right, it is not working yet. I am still struggling with it.
I'll come back to you as soon as I have any news about it.
Regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 8:16 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Mario,
By hard-coding the runtime id of the target peer, did
RE: Discovery update
Thanks Mario. That was indeed a silly error :) Anyway, Simon is right on the
runtime id, the error was in the SCDL that was posted.
Thaks for your help, we need to add some more functionality on the discovery
side of things. I will keep you posted, may be we can work together on some
of the stuff?
Ta
Meeraj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Date: Tue, 27 Mar 2007 08:30:55 -0700
Simon,
I did not realize the problem was there :(
I tried it and you are right.
Thanks a lot for that!
Now it works w/o broadcasting the message.
Mario
-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 12:23 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
On 3/27/07, Antollini, Mario [EMAIL PROTECTED] wrote:
Meeraj,
I finally got JXTA working! The problem was that the message being
sent
was null...
In JxtaDiscoverService.java the code for sending the message was:
public int sendMessage(final String runtimeId, final XMLStreamReader
content) throws DiscoveryException {
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
So, note that the StaxUtil.serialize(content) method is not assigning
the returned value to the message.
Besides that, remember that when you try to contribute the SCDL (via
the
browser), there is an exception since it is trying to send the message
to the peer called slave and there is not such peer in the network.
Therefore, I did another modification to the sendMessage method in
order
to send the message to all the peers (just to see if it works). So,
the
working piece of code is:
public int sendMessage(String runtimeId, final XMLStreamReader
content)
throws DiscoveryException {
runtimeId = null;
if(content == null) {
throw new IllegalArgumentException(Content id is null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime +
runtimeId);
}
}
String message = null;
try {
message = StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
Note that I removed the final keyword to the runtimeId parameter in
order to turn it to null in the first statement of the method (to
allow
broadcast of the message).
In addition to that I just modified StaxUtil.serialize(content); for
message = StaxUtil.serialize(content);
And that is all I did and after pressing the Contribute SCDL button,
I
saw in both slaves' console window a system.out I added to the
processQuery(ResolverQueryMsg queryMessage) method in
TuscanyQueryHandler.java.
So, now it is important to know why the runtimeId arrives with a value
equal to slave. I had already tried to figure it out and sent you an
email, remember? I am copying it here just in case:
Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to
JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Ok, I hope it is all useful and if you need any further help, please
do
not hesitate to contact me.
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 25, 2007 5:52 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Thanks Mario. If you have any more queries, pls post to the list.
Ta
Meerj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev
RE: Discovery update
Meeraj,
I am looking forward to working along with you in the discovery service.
Thanks for the invitation.
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 2:49 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Thanks Mario. That was indeed a silly error :) Anyway, Simon is right on
the
runtime id, the error was in the SCDL that was posted.
Thaks for your help, we need to add some more functionality on the
discovery
side of things. I will keep you posted, may be we can work together on
some
of the stuff?
Ta
Meeraj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Date: Tue, 27 Mar 2007 08:30:55 -0700
Simon,
I did not realize the problem was there :(
I tried it and you are right.
Thanks a lot for that!
Now it works w/o broadcasting the message.
Mario
-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 12:23 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
On 3/27/07, Antollini, Mario [EMAIL PROTECTED] wrote:
Meeraj,
I finally got JXTA working! The problem was that the message being
sent
was null...
In JxtaDiscoverService.java the code for sending the message was:
public int sendMessage(final String runtimeId, final XMLStreamReader
content) throws DiscoveryException {
if(content == null) {
throw new IllegalArgumentException(Content id is
null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime
+
runtimeId);
}
}
String message = null;
try {
StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
So, note that the StaxUtil.serialize(content) method is not
assigning
the returned value to the message.
Besides that, remember that when you try to contribute the SCDL (via
the
browser), there is an exception since it is trying to send the
message
to the peer called slave and there is not such peer in the
network.
Therefore, I did another modification to the sendMessage method in
order
to send the message to all the peers (just to see if it works). So,
the
working piece of code is:
public int sendMessage(String runtimeId, final XMLStreamReader
content)
throws DiscoveryException {
runtimeId = null;
if(content == null) {
throw new IllegalArgumentException(Content id is
null);
}
PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException(Unrecognized runtime
+
runtimeId);
}
}
String message = null;
try {
message = StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}
Note that I removed the final keyword to the runtimeId parameter in
order to turn it to null in the first statement of the method (to
allow
broadcast of the message).
In addition to that I just modified StaxUtil.serialize(content);
for
message = StaxUtil.serialize(content);
And that is all I did and after pressing the Contribute SCDL
button,
I
saw in both slaves' console window a system.out I added to the
processQuery(ResolverQueryMsg queryMessage) method in
TuscanyQueryHandler.java.
So, now it is important to know why the runtimeId arrives with a
value
equal to slave. I had already tried to figure it out and sent you
an
email, remember? I am copying it here just in case:
Now, I was trying to understand where the target name comes wrong
from
and I think the problem could be that the AssemblyServiceImpl class
is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to
JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Ok, I hope it is all useful and if you need any further help, please
do
not hesitate
RE: Discovery update
Meeraj,
You were right, it is not working yet. I am still struggling with it.
I'll come back to you as soon as I have any news about it.
Regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 8:16 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Mario,
By hard-coding the runtime id of the target peer, did the message
actually reached the intended peer? i.e. did you see any log messages on
the console widow of slave1 or slave2?
Thanks
Meeraj
-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: 23 March 2007 21:02
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Meeraj,
I got the JXTA working for sending messages. However, what I
did was just finding the error and patching it, so I just
modified a line of code and got to know that the problem was
not on the dissemination of messages by JXTA but on the peer
name being used to dispatch the name to.
So, I saw that the problem was that the sender of the
message was trying to send a msg to a peer called slave
(as seeing in the following exception that was being
displayed on the browser after pressing the Contribute
SCDL button):
org.apache.tuscany.spi.services.discovery.DiscoveryException:
Unrecognized runtime slave
What I did was just commenting a line of code out and
hardcoding the name of the runtime in the
JxtaDiscoveryService class (when the runtime is registering itself):
/**
* Configures the platform.
*
*/
private void configure() throws DiscoveryException {
try {
//String runtimeId = getRuntimeInfo().getRuntimeId();
String runtimeId = slave;
configurator.setName(runtimeId);
configurator.setHome(new File(runtimeId));
if (configurator.exists()) {
File pc = new File(configurator.getHome(),
PlatformConfig);
configurator.load(pc.toURI());
configurator.save();
} else {
configurator.save();
}
} catch (IOException ex) {
throw new DiscoveryException(ex);
} catch (CertificateException ex) {
throw new DiscoveryException(ex);
}
}
After doing that, the SCDL was successfully processed.
So, as you can see, the problem was not completely solved
(the runtimeId is hardcoded). But, at least I found why the
messages were not being delivered.
Now, I was trying to understand where the target name comes
wrong from and I think the problem could be that the
AssemblyServiceImpl class is setting the wrong id in the
include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context),
which in turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader)
method, which ends up in an invocation to
JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from
some place outside of the scope of JXTA and I am not
experienced enough to deal with such issue. Do you have any
idea where the slave id is being wrongly set?
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 12:39 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
Mario,
I will try to be as detailed as I can, if you need further
info, pls ask.
Tuscany code structure is roughly organized into kernel,
runtime, services and extensions. There are other modules
like plugins, console etc, which are not relavant in the
context of this discussion. There is also a contrib module,
where we keep artifacts that are not ready to go, it is
important in the context of this discussion because the JXTA
impl is currently in contrib, because of some issues we are
investigating with some patented code with BouncyCastle.
tuscany-spi in kernel, contains the key model classes and
service provider interfaces for Tuscany. Some of these are
implemented by core in kernel and some of them are
implemented outside kernel. DiscoveryService is an SPI
defined in tuscany-spi that is used by the runtime fabric
for enabling communication between multiple profiles
participating in a logical SCA domain. A profile is
basically a group of services, both system and user, that
are managed together. Multiple profiles make up a logical
SCA domain.
You can run profiles in the same VM or different VMs.
Discovery service provides basically one method,
1. Targeted delivery of a message to a given profile.
However, the JXTA
RE: Discovery update
Thanks Mario. If you have any more queries, pls post to the list.
Ta
Meerj
From: Antollini, Mario [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Date: Sun, 25 Mar 2007 07:53:39 -0700
Meeraj,
You were right, it is not working yet. I am still struggling with it.
I'll come back to you as soon as I have any news about it.
Regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 8:16 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Mario,
By hard-coding the runtime id of the target peer, did the message
actually reached the intended peer? i.e. did you see any log messages on
the console widow of slave1 or slave2?
Thanks
Meeraj
-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: 23 March 2007 21:02
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update
Meeraj,
I got the JXTA working for sending messages. However, what I
did was just finding the error and patching it, so I just
modified a line of code and got to know that the problem was
not on the dissemination of messages by JXTA but on the peer
name being used to dispatch the name to.
So, I saw that the problem was that the sender of the
message was trying to send a msg to a peer called slave
(as seeing in the following exception that was being
displayed on the browser after pressing the Contribute
SCDL button):
org.apache.tuscany.spi.services.discovery.DiscoveryException:
Unrecognized runtime slave
What I did was just commenting a line of code out and
hardcoding the name of the runtime in the
JxtaDiscoveryService class (when the runtime is registering itself):
/**
* Configures the platform.
*
*/
private void configure() throws DiscoveryException {
try {
//String runtimeId = getRuntimeInfo().getRuntimeId();
String runtimeId = slave;
configurator.setName(runtimeId);
configurator.setHome(new File(runtimeId));
if (configurator.exists()) {
File pc = new File(configurator.getHome(),
PlatformConfig);
configurator.load(pc.toURI());
configurator.save();
} else {
configurator.save();
}
} catch (IOException ex) {
throw new DiscoveryException(ex);
} catch (CertificateException ex) {
throw new DiscoveryException(ex);
}
}
After doing that, the SCDL was successfully processed.
So, as you can see, the problem was not completely solved
(the runtimeId is hardcoded). But, at least I found why the
messages were not being delivered.
Now, I was trying to understand where the target name comes
wrong from and I think the problem could be that the
AssemblyServiceImpl class is setting the wrong id in the
include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context),
which in turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader)
method, which ends up in an invocation to
JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from
some place outside of the scope of JXTA and I am not
experienced enough to deal with such issue. Do you have any
idea where the slave id is being wrongly set?
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 12:39 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
Mario,
I will try to be as detailed as I can, if you need further
info, pls ask.
Tuscany code structure is roughly organized into kernel,
runtime, services and extensions. There are other modules
like plugins, console etc, which are not relavant in the
context of this discussion. There is also a contrib module,
where we keep artifacts that are not ready to go, it is
important in the context of this discussion because the JXTA
impl is currently in contrib, because of some issues we are
investigating with some patented code with BouncyCastle.
tuscany-spi in kernel, contains the key model classes and
service provider interfaces for Tuscany. Some of these are
implemented by core in kernel and some of them are
implemented outside kernel. DiscoveryService is an SPI
defined in tuscany-spi that is used by the runtime fabric
for enabling communication between multiple profiles
participating in a logical SCA domain. A profile is
basically a group of services, both system and user, that
are managed together. Multiple profiles make up a logical
SCA domain.
You can run profiles in the same VM or different VMs
RE: Discovery update
Meeraj,
I got the JXTA working for sending messages. However, what I did was
just finding the error and patching it, so I just modified a line of
code and got to know that the problem was not on the dissemination of
messages by JXTA but on the peer name being used to dispatch the name
to.
So, I saw that the problem was that the sender of the message was trying
to send a msg to a peer called slave (as seeing in the following
exception that was being displayed on the browser after pressing the
Contribute SCDL button):
org.apache.tuscany.spi.services.discovery.DiscoveryException:
Unrecognized runtime slave
What I did was just commenting a line of code out and hardcoding the
name of the runtime in the JxtaDiscoveryService class (when the runtime
is registering itself):
/**
* Configures the platform.
*
*/
private void configure() throws DiscoveryException {
try {
//String runtimeId = getRuntimeInfo().getRuntimeId();
String runtimeId = slave;
configurator.setName(runtimeId);
configurator.setHome(new File(runtimeId));
if (configurator.exists()) {
File pc = new File(configurator.getHome(),
PlatformConfig);
configurator.load(pc.toURI());
configurator.save();
} else {
configurator.save();
}
} catch (IOException ex) {
throw new DiscoveryException(ex);
} catch (CertificateException ex) {
throw new DiscoveryException(ex);
}
}
After doing that, the SCDL was successfully processed.
So, as you can see, the problem was not completely solved (the runtimeId
is hardcoded). But, at least I found why the messages were not being
delivered.
Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition? child :
type.getDeclaredComponents().values()) {
URI id = child.getRuntimeId()
.
Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)
So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the slave id is being
wrongly set?
Best regards,
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 12:39 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Discovery update
Mario,
I will try to be as detailed as I can, if you need further info, pls
ask.
Tuscany code structure is roughly organized into kernel, runtime,
services
and extensions. There are other modules like plugins, console etc, which
are
not relavant in the context of this discussion. There is also a contrib
module, where we keep artifacts that are not ready to go, it is
important in
the context of this discussion because the JXTA impl is currently in
contrib, because of some issues we are investigating with some patented
code
with BouncyCastle.
tuscany-spi in kernel, contains the key model classes and service
provider
interfaces for Tuscany. Some of these are implemented by core in kernel
and
some of them are implemented outside kernel. DiscoveryService is an SPI
defined in tuscany-spi that is used by the runtime fabric for enabling
communication between multiple profiles participating in a logical SCA
domain. A profile is basically a group of services, both system and
user,
that are managed together. Multiple profiles make up a logical SCA
domain.
You can run profiles in the same VM or different VMs.
Discovery service provides basically one method,
1. Targeted delivery of a message to a given profile.
However, the JXTA impl, also provides a listener for receiving those
messages and so does the JMS impl. JMS is not a real option for us, as
long
term we want to enable multi-fabric profiles in the same domain, Java
and
C++ for example. This is where JXTA fits in nicely.
Profile names are important, as the JXTA implementation of the discovery
service uses the profile names as logical endpoints and use them to map
to
JXTA peer ids. The JXTA implementation uses a peer group specific to the
domain in which the profile is participating. The domain name is defined
in
/etc/runtime.properties of the profile. We do that to restrict
communication
between the profiles only in the same domain. We use PDP (Peer Discovery
Protocol), for maintaining a view of all profiles available in the
domain
and PRP (Peer Rsolver Protocol) for sending directed messages. PDP
Re: Discovery update
On Mar 20, 2007, at 7:26 AM, Antollini, Mario wrote: Meeraj, I am willing to help you. However, keep in mind that I am neither a Tuscany developer nor a committer. Therefore you must give me a task I can actually work on. In case you do write to me, please be very specific since I do not have much experience with Tuscany's code. Looking forward to your reply. I'll leave technical details to Meeraj as he's the one fighting the transport issue, but any contribution is welcome. For code changes, the best way is to send a patch generated with svn diff once you have the change working - either sent as a text attachment to this list, or for larger changes attached to a JIRA. Welcome aboard! Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discovery update
Mario, I will try to be as detailed as I can, if you need further info, pls ask. Tuscany code structure is roughly organized into kernel, runtime, services and extensions. There are other modules like plugins, console etc, which are not relavant in the context of this discussion. There is also a contrib module, where we keep artifacts that are not ready to go, it is important in the context of this discussion because the JXTA impl is currently in contrib, because of some issues we are investigating with some patented code with BouncyCastle. tuscany-spi in kernel, contains the key model classes and service provider interfaces for Tuscany. Some of these are implemented by core in kernel and some of them are implemented outside kernel. DiscoveryService is an SPI defined in tuscany-spi that is used by the runtime fabric for enabling communication between multiple profiles participating in a logical SCA domain. A profile is basically a group of services, both system and user, that are managed together. Multiple profiles make up a logical SCA domain. You can run profiles in the same VM or different VMs. Discovery service provides basically one method, 1. Targeted delivery of a message to a given profile. However, the JXTA impl, also provides a listener for receiving those messages and so does the JMS impl. JMS is not a real option for us, as long term we want to enable multi-fabric profiles in the same domain, Java and C++ for example. This is where JXTA fits in nicely. Profile names are important, as the JXTA implementation of the discovery service uses the profile names as logical endpoints and use them to map to JXTA peer ids. The JXTA implementation uses a peer group specific to the domain in which the profile is participating. The domain name is defined in /etc/runtime.properties of the profile. We do that to restrict communication between the profiles only in the same domain. We use PDP (Peer Discovery Protocol), for maintaining a view of all profiles available in the domain and PRP (Peer Rsolver Protocol) for sending directed messages. PDP seems to work fine, however, PRP is not delivering the messages. I have posted this on the JXTA list and I can forward you the emails if you want (I will forward it to this list) Here are the key areas you can look at, /java/sca/kernel/tuscany-spi: For the discovery service abstractions. /java/sca/kernel/core: Usage patterns for discovery service /java/sca/contrib/discovery/jxta: The JXTA impl of discovery /java/sca/runtime/standalone/server.start: The basic shell for starting a tuscany server standlone /java/sca/console: For a browser based console (it is pretty minimal now) /java/distribution/sca/demo: A maven assembly for creating an installation image for three feedrated profiles master, slave1 and slave2. In the src/profile directory you will find the teh different profiles and their system SCDLs. Currentlly, they use JMS, however, I have commented component definitions for JXTA. you can start all three profiles in one vm using java -jar server.start.jar master slave1 slave2 or java -Dtuscany.adminPort-2000 -jar server.start.jar master java -Dtuscany.adminPort-3000 -jar server.start.jar slave1 etc. You can access the console using http://server:7000/scdlForm. As I said it is pretty basic, I am sure it will evolve :) Once again, great to have you. You can send the patches to the list, I will test it and apply it. Ta Meeraj From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Discovery update Date: Tue, 20 Mar 2007 07:39:59 -0700 On Mar 20, 2007, at 7:26 AM, Antollini, Mario wrote: Meeraj, I am willing to help you. However, keep in mind that I am neither a Tuscany developer nor a committer. Therefore you must give me a task I can actually work on. In case you do write to me, please be very specific since I do not have much experience with Tuscany's code. Looking forward to your reply. I'll leave technical details to Meeraj as he's the one fighting the transport issue, but any contribution is welcome. For code changes, the best way is to send a patch generated with svn diff once you have the change working - either sent as a text attachment to this list, or for larger changes attached to a JIRA. Welcome aboard! Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Solve the Conspiracy and win fantastic prizes. http://www.theconspiracygame.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
