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: [email protected] 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: [email protected] > 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: [email protected] > >To: <[email protected]> > >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: [email protected] > >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: [email protected] > > >> 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: [email protected] > > >> 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 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: [email protected] > > >> >To: [email protected] > > >> >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] > > >> > > >> > --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > >> This message has been checked for all email viruses by MessageLabs > > > >***************************************************** > > > > You can find us at www.voca.com > > > >***************************************************** > >This communication is confidential and intended for > >the exclusive use of the addressee only. You should > >not disclose its contents to any other person. > >If you are not the intended recipient please notify > >the sender named above immediately. > > > >Registered in England, No 1023742, > >Registered Office: Voca Limited > >Drake House, Three Rivers Court, > >Homestead Road, Rickmansworth, > >Hertfordshire, WD3 1FX. United Kingdom > > > >VAT No. 226 6112 87 > > > > > >This message has been checked for all email viruses by MessageLabs. > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > _________________________________________________________________ > Match.com - Click Here To Find Singles In Your Area Today! > http://msnuk.match.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Hi Mario Looking back at Meeraj's SCDL posted last week he set all the runtimeIds to "slave", e.g. <component runtimeId="slave" name="AddServiceComponent"> <implementation.java class="calculator.AddServiceImpl"/> </component> Is this why your test is trying to send messages to slave rather than slave1. To get mine to work I went in an edited the SCDL and changed slave to slave1. Regards Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
