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@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.
> > >>
> > >> 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]
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> 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]
