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]
