Re: Moving on
Hi guys, Just want to send a quick note to say I have decided to move on. I would like to wish you guys all the best. Thanks Meeraj From: Jean-Sebastien Delfino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Moving on Date: Mon, 02 Apr 2007 09:33:27 -0700 Davanum Srinivas wrote: Team, FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. http://code.google.com/p/fabric3/ Please wish them best of luck. thanks, dims Best of luck guys. I hope that the two projects can cooperate in the future. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving - check out the new Windows Live Mail http://ideas.live.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Dims, Sorry, I can't speak on behalf of Jim or Jeremy. As for me, this is only the second time I have voted -1, the other one being the one on interfaced based models, which has been withdrawn since then. On this particular vote, I am ok to go with -0, it was a misunderstaning on my part on how voting worked. I thought, the rule was there should be more +1s than -1s and at least three +1s. As Jim mentioned in one of the previous emails, there is a fundamental difference that has been evolving between two groups of people, in terms of what technical direction we should take. There have been laudable efforts from both sides (especially from the likes of Raymond, Sebastien, Simon, Jim and Jeremy) to reconcile the differences and move on. However, the plain fact is that those diffeerences have not been resolved yet and I am not sure whether they would, given they are quite fundamental. On your point on projects being thrown out of the incubator, I wouldn't want that to happen to Tuscany. Lot of people have put in a lot of effort on this. I am willing to keep the discussions going. At the end of the day, if I personally can't resolve the technical differences, I would maintain my dignity and step out of the way and let the community carry on. However, that would be a last resort for me, I would continue to work with the guys here and try to reconcile the differences. On your point on the "Be Nice" vote, I have been thinking hard on the actual motivation of that vote. I don't think anyone has been disrespectful to anyone on the list so far. We have had our differences, and we have tried to discuss them as grown up individuals. Hence, I didn't really understand the purpose of that vote. Ta Meeraj From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Thu 3/29/2007 5:09 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together Meeraj, well go over the archives and count how many times you, jim and jeremy have -1'ed something. The correct vote for "I am happy to go with the majority view, if that is what the community wants." is -0 *NOT* -1. When you do a -1 you are supposed to work hard to come up with a refined proposal that takes in your viewpoint or help come up with a proposal that evertone can rally around. I see no effort in consensus building in any of the threads i reviewed after a -1. This is an open source project, you can have the best goddamn architecture in the whole wide world. If there is no community to back the work. It will get thrown out of the incubator. Sorry, that's the way Apache works. Incubator is not only for legal purposes but also to help build communities. This is not the way an open source project should work. Forget about incubator projects, we have closed Top level project (example Avalon) too because everyone was at cross purposes and no one was cooperating with any one else. Yes, a few of the people who started the fracas did say exactly what you said.."I disagree fundamnetally from a technical perspective". See this email and check if it is the same situation you all are in. Finally did the three of you VOTE in the "Be Nice" thread? That just tells me a lot of things. thanks, dims [1] http://mail-archives.apache.org/mod_mbox/avalon-dev/200211.mbox/[EMAIL PROTECTED] On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > Dims, > > I don't think there is a stream of -1s. This is an issue on which, > unfortunately, I disagree fundamnetally from a technical perspective, with > the percieved majority view. It will be hypocritical of me to +1, if I don't > agree with it. > > However, I am happy to go with the majority view, if that is what the > community wants. > > Ta > Meeraj > > > > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > Sent: Wed 3/28/2007 11:24 PM > To: tuscany-dev@ws.apache.org > Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable > building all modules together > > > > Jim, Meeraj, > > If the stream of -1's contnue, am afraid there isn't going to be a > single release at all. > > thx, > dims > > On 3/28/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > > > On Mar 28, 2007, at 12:51 AM, ant elder wrote: > > > > > Here's the vote on this I said [1] I'd start to get closure on this > > > issue. > > > > > > The proposal is to have top-level pom for the Java SCA project that > > > enables > > > building all the modules together - kernel, services, runtimes, > > > extensions > > > etc, and for that to work all those modules need to use the same > > &g
RE: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
Dims, I don't think there is a stream of -1s. This is an issue on which, unfortunately, I disagree fundamnetally from a technical perspective, with the percieved majority view. It will be hypocritical of me to +1, if I don't agree with it. However, I am happy to go with the majority view, if that is what the community wants. Ta Meeraj From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wed 3/28/2007 11:24 PM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together Jim, Meeraj, If the stream of -1's contnue, am afraid there isn't going to be a single release at all. thx, dims On 3/28/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > On Mar 28, 2007, at 12:51 AM, ant elder wrote: > > > Here's the vote on this I said [1] I'd start to get closure on this > > issue. > > > > The proposal is to have top-level pom for the Java SCA project that > > enables > > building all the modules together - kernel, services, runtimes, > > extensions > > etc, and for that to work all those modules need to use the same > > version > > name. > > > > Here's my +1. > > > > ...ant > > > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ > > msg16024.html > > > > There has been no proposal for how to resolve the issue about > building extensions using multiple versions of kernel and how modules > on different release schedules requiring different levels of kernel > or plugins will be handled. > > Until we can come up with a solution for these issues, I feel I have > to vote against the proposal. > > -1 > > Jim > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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]
RE: JXTA is working now - JMX question
The work around JMX is still half-baked. Though it does register all the available components and provides a read-only view of properties. The server currently use the RMI agent adaptor. So you should be able to connet through a clinet like jconsole and view the registered components. Ta Meeraj From: "Antollini, Mario" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: Subject: RE: JXTA is working now - JMX question Date: Wed, 28 Mar 2007 09:15:53 -0700 Meeraj, As you posted in this email, I wanted to play around with Tuscany's JMX capabilities a little bit. However I only had access to information delivered by the JVM itself, but nothing related to the runtime. I started the runtime this way: java -Dcom.sun.management.jmxremote -Dtuscany.adminPort=2000 -jar server.start.jar master (NB: if -Dcom.sun.management.jmxremote is not added, I cannot connect via jconnect) Is there anything else I need to do, or Tuscany's JMX is not working yet? Thanks and regards, Mario -Original Message- From: Fiorentino, Cristian Sent: Monday, March 19, 2007 11:20 AM To: Ganame, Sebastian; Antollini, Mario; Cilia, Mariano; Palmisano, Diego; Salvucci, Sebastian; Maniasi, Sebastian; Voos, Javier A; Morin, Ricardo A Subject: FW: JXTA is working now FYI Cristian G. Fiorentino Intel Corporation - ASDC - Eng. Argentina Software Development Center +54-351-414-5595 [EMAIL PROTECTED] -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: Sunday, March 18, 2007 9:03 AM To: tuscany-dev@ws.apache.org Subject: JXTA is working now Hi, I am able to start three servers (master, slave1 and slave2 profiles in the java/distribution/sca/demo directory), all in the same logical SCA domain, in different VMs and maintain the federation topology across the servers. You need to specify different JMX admin port with the system property -Dtuscany.adminPort. For example, java -Dtuscany.adminPort=2000 -jar server.start.jar master java -Dtuscany.adminPort=3000 -jar server.start.jar slave1 java -Dtuscany.adminPort=4000 -jar server.start.jar slave2 Alternatively, you can start all the profiles in one VM. java -jar server.start.jar master slave1 slave2. This will use the default RMI port 1099. I have attached a screenshot of the three profiles running in multiple VMs ;-) Ta Meeraj _ Txt a lot? Get Messenger FREE on your mobile. https://livemessenger.mobile.uk.msn.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving - check out the new Windows Live Mail. http://ideas.live.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together
I have expressed my views on all modules sharing the same version and a top down build in quite a bit of detail in my previous emails on the same subject. Unfortunately, I will have to vote -1 on this. Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together Date: Wed, 28 Mar 2007 12:19:53 -0700 On Mar 28, 2007, at 12:51 AM, ant elder wrote: Here's the vote on this I said [1] I'd start to get closure on this issue. The proposal is to have top-level pom for the Java SCA project that enables building all the modules together - kernel, services, runtimes, extensions etc, and for that to work all those modules need to use the same version name. Here's my +1. ...ant [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg16024.html There has been no proposal for how to resolve the issue about building extensions using multiple versions of kernel and how modules on different release schedules requiring different levels of kernel or plugins will be handled. Until we can come up with a solution for these issues, I feel I have to vote against the proposal. -1 Jim - 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]
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:
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
Re: Tag for TSSS demo code
Sorry for late replies Simon, I am offsite in India for the next two weeks. Regarding the SCDL, there was a post earlier in the list with the SCDL (from me). You can use the calculator scdl in core-samples and remove the client component, also each component needs to be targeted with a runtimeId attribute. Obviously, you will have to start the targeted node on a different JMX port, before you deploy the SCDL. On the execption, IIRC, you can register a formatter that will print the required information. HTH Meeraj From: "Simon Laws" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Tag for TSSS demo code Date: Mon, 26 Mar 2007 22:54:43 +0100 On 3/26/07, Antollini, Mario <[EMAIL PROTECTED]> wrote: Simon, I had had the same problem than you. I solved it starting ActiveMQ first. The final steps are: 1 - Donwload ActiveMQ: http://people.apache.org/repo/m2-incubating-repository/org/apache/active mq/apache-activemq/4.1.0-incubator/apache-activemq-4.1.0-incubator.zip 2 - uncompress it somewhere and start it (...\bin\ activemq.bat) 3 - compile the TSSS demo 4 - uncompress ...\tuscany\java\distribution\sca\demo\target\demo-2.0-alpha2-incubating -SNAPSHOT-bin.zip 5 - go to the bin directory of the uncompressed file and run "java -Dtuscany.adminPort=2000 -jra start.server.jar master" Mario -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 2:41 PM To: tuscany-dev@ws.apache.org Subject: Re: Tag for TSSS demo code On 3/26/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 3/26/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > > > > Simon, > > > > Did you start ActiveMQ before you started the master? > > > > Ta > > Meeraj > > > > > > >From: "Simon Laws" <[EMAIL PROTECTED]> > > >Reply-To: tuscany-dev@ws.apache.org > > >To: tuscany-dev@ws.apache.org > > >Subject: Re: Tag for TSSS demo code > > >Date: Mon, 26 Mar 2007 17:35:24 +0100 > > > > > >On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > >> > > >>I've created a tag corresponding to the code used to build the demo > > >>(r520715) and added a trivial pom to build the lot. To build: > > >>$ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/ > > >>java/tsss-demo > > >>$ mvn install > > >> > > >>I did not change the versions in the poms so they are using the same > > >>ones as trunk. To avoid conflict in the snapshot repo we should not > > >>deploy jars built from this. > > >> > > >>-- > > >>Jeremy > > >> > > >>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote: > > >> > > >> > Jeremy, > > >> > > > >> > This is the definitve list, thanks to Mario. > > >> > > > >> > java/spec/commonj/ > > >> > java/spec/sca-api-r1.0/ > > >> > java/sca/kernel/ > > >> > java/sca/runtime/ > > >> > java/sca/services/ > > >> > java/sca/contrib/discovery/ > > >> > java/sca/contrib/discovery/jms > > >> > java/sca/console/ > > >> > java/sca/core-samples/ > > >> > java/distribution/sca/demo.app > > >> > java/distribution/sca/demo/ > > >> > > > >> > Ta > > >> > Meeraj > > >> > > > >> > -Original Message- > > >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > > >> > Sent: Thursday, March 22, 2007 1:52 PM > > >> > To: tuscany-dev@ws.apache.org > > >> > Subject: Re: Compilation status > > >> > > > >> > I think we should tag and deploy SNAPSHOTs of the revision used for > > > > >> > the > > >> > demo - that way people can build as much or as little as they wish. > > If > > >> > you can post the list, I get those modules tagged and deployed > > later > > >> > today. > > >> > > > >> > -- > > >> > Jeremy > > >> > > > >> > On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote: > > >> > > > >> >> Mario, > > >> >> > > >> >> AFAIK extensions in trunk is still in a bit of a flux. If you want > > to > > >> >> run the demo, you don't need to run the extensions (the demo uses > > >> >> Java > > >> > &
Re: Tag for TSSS demo code
Simon, You get this error, when one or more of the eager init web services fail to start. If you debug the exception thrown, will include the causes for the eager init failure. Ta Meeraj From: "Simon Laws" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Tag for TSSS demo code Date: Mon, 26 Mar 2007 18:08:35 +0100 On 3/26/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Simon, Did you start ActiveMQ before you started the master? Ta Meeraj >From: "Simon Laws" <[EMAIL PROTECTED]> >Reply-To: tuscany-dev@ws.apache.org >To: tuscany-dev@ws.apache.org >Subject: Re: Tag for TSSS demo code >Date: Mon, 26 Mar 2007 17:35:24 +0100 > >On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >>I've created a tag corresponding to the code used to build the demo >>(r520715) and added a trivial pom to build the lot. To build: >>$ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/ >>java/tsss-demo >>$ mvn install >> >>I did not change the versions in the poms so they are using the same >>ones as trunk. To avoid conflict in the snapshot repo we should not >>deploy jars built from this. >> >>-- >>Jeremy >> >>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote: >> >> > Jeremy, >> > >> > This is the definitve list, thanks to Mario. >> > >> > java/spec/commonj/ >> > java/spec/sca-api-r1.0/ >> > java/sca/kernel/ >> > java/sca/runtime/ >> > java/sca/services/ >> > java/sca/contrib/discovery/ >> > java/sca/contrib/discovery/jms >> > java/sca/console/ >> > java/sca/core-samples/ >> > java/distribution/sca/demo.app >> > java/distribution/sca/demo/ >> > >> > Ta >> > Meeraj >> > >> > -Original Message- >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, March 22, 2007 1:52 PM >> > To: tuscany-dev@ws.apache.org >> > Subject: Re: Compilation status >> > >> > I think we should tag and deploy SNAPSHOTs of the revision used for >> > the >> > demo - that way people can build as much or as little as they wish. If >> > you can post the list, I get those modules tagged and deployed later >> > today. >> > >> > -- >> > Jeremy >> > >> > On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote: >> > >> >> Mario, >> >> >> >> AFAIK extensions in trunk is still in a bit of a flux. If you want to >> >> run the demo, you don't need to run the extensions (the demo uses >> >> Java >> > >> >> container with local bindings), I will try to post a dfeinitive list >> >> of tasks to build and run the demo later in the day, which will be >> >> useful to Simon as well. >> >> >> >> Ta >> >> Meeraj >> >> >> >> -Original Message- >> >> From: Antollini, Mario [mailto:[EMAIL PROTECTED] >> >> Sent: Thursday, March 22, 2007 12:29 PM >> >> To: tuscany-dev@ws.apache.org >> >> Subject: Compilation status >> >> >> >> Meeraj, >> >> >> >> >> >> >> >> I just wanted you to know that I am still not able to compile the >> >> code >> > >> >> I checked out from SVN. The main problem is located in the >> >> *extensions* project. I have been modifying the pom files within this >> >> project but I did not manage to get it compiled yet. >> >> >> >> >> >> >> >> Basically, the main problems are related to inconsistencies between >> >> parent references (e.g.; axis2's root project is using groupId >> >> *org.apache.tuscany.sca.axis2* while the plugin subproject states >> >> that >> > >> >> its parent is *org.apache.tuscany.sca.extensions.axis2*). >> >> >> >> >> >> >> >> Any tips about this? >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Mario >> >> >> >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> >> >> >> >> * >> >> >> >> You can find us at www.voca.com >> >> >> >>
Re: Tag for TSSS demo code
Simon, Did you start ActiveMQ before you started the master? Ta Meeraj From: "Simon Laws" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Tag for TSSS demo code Date: Mon, 26 Mar 2007 17:35:24 +0100 On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I've created a tag corresponding to the code used to build the demo (r520715) and added a trivial pom to build the lot. To build: $ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/tsss-demo $ mvn install I did not change the versions in the poms so they are using the same ones as trunk. To avoid conflict in the snapshot repo we should not deploy jars built from this. -- Jeremy On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote: > Jeremy, > > This is the definitve list, thanks to Mario. > > java/spec/commonj/ > java/spec/sca-api-r1.0/ > java/sca/kernel/ > java/sca/runtime/ > java/sca/services/ > java/sca/contrib/discovery/ > java/sca/contrib/discovery/jms > java/sca/console/ > java/sca/core-samples/ > java/distribution/sca/demo.app > java/distribution/sca/demo/ > > Ta > Meeraj > > -Original Message- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 22, 2007 1:52 PM > To: tuscany-dev@ws.apache.org > Subject: Re: Compilation status > > I think we should tag and deploy SNAPSHOTs of the revision used for > the > demo - that way people can build as much or as little as they wish. If > you can post the list, I get those modules tagged and deployed later > today. > > -- > Jeremy > > On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote: > >> Mario, >> >> AFAIK extensions in trunk is still in a bit of a flux. If you want to >> run the demo, you don't need to run the extensions (the demo uses >> Java > >> container with local bindings), I will try to post a dfeinitive list >> of tasks to build and run the demo later in the day, which will be >> useful to Simon as well. >> >> Ta >> Meeraj >> >> -Original Message- >> From: Antollini, Mario [mailto:[EMAIL PROTECTED] >> Sent: Thursday, March 22, 2007 12:29 PM >> To: tuscany-dev@ws.apache.org >> Subject: Compilation status >> >> Meeraj, >> >> >> >> I just wanted you to know that I am still not able to compile the >> code > >> I checked out from SVN. The main problem is located in the >> *extensions* project. I have been modifying the pom files within this >> project but I did not manage to get it compiled yet. >> >> >> >> Basically, the main problems are related to inconsistencies between >> parent references (e.g.; axis2's root project is using groupId >> *org.apache.tuscany.sca.axis2* while the plugin subproject states >> that > >> its parent is *org.apache.tuscany.sca.extensions.axis2*). >> >> >> >> Any tips about this? >> >> >> >> Thanks, >> >> Mario >> >> >> 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] > > > This message has been checked for all email viruses by MessageLabs. > > This message has been checked for all email viruses by MessageLabs. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
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:
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 relava
Ways of working together [was - RE: Build structure - having cake and still eating]
Dims, I am more than happy to find a middle ground where everyone can work together. I was just pointing out the technical issues with a top down pom. Worst case as a compromise, I may even agree to a top-down pom, even though I don't agree with it from a technical perspective, so that we can work together. On a side note what I suggested on the thread "Objective of the following sandbox", is that there had been lot of discussion and work in the last two months on stuff around the kernel. As I said, I am happy to discuss Sebastien's proposal. However, that should not be done in isolation. We should also take into consideration, the work we have done so far and why we want to start from scratch rather than improve the kernel incrementally. I am all for modularizing the kernel, this is something we all agree on. However, that doesn't mean we start from scratch. Some of the issues Sebastien has raised were discussed on the list more than ten moths ago, and we as a community took a decision to take the direction we now have in kernel. In my opinion that is water under bridge. However, if we need to go back and discuss those things again, I am happy to do it. But as I said, these discussions shouldn't be done in isolation, there should also be a strong rationale on what is so wrong with the current kernel, that it needs to be changed so drastically. Thanks Meeraj >> -Original Message- >> From: Davanum Srinivas [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 13:31 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Build structure - having cake and still eating >> >> Meeraj, >> >> Using assemblies is ok. It does not have to be published. >> Once everyone is in the same bandwagon, then it's ok to >> publish. Till then, please find a way to work with >> assemblies w/o having to rely on published artifacts. If >> this is a maven problem, then find another way to solve the >> problem or ask at least raise an issue with maven folks. >> As for myself, am putting my foot down on publishing till >> everyone shares. This is getting more and more like 3-4 year >> olds in the sandbox not sharing their toys and saying hey >> you did not talk to me when i talked to you. So shut up now. >> Everyone has a life, everyone has priorities. When folks >> come to the table, the conversation should begin again. >> Again, Please figure out a way everyone can work. >> >> thanks, >> dims >> >> On 3/23/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: >> > Luciano, >> > >> > Your hijacked version of pom portrays all the issues >> associated with a >> > top down pom with a single version in a complex project. You have >> > included the modules you want to build. It may not be of >> any use to >> > me, if I want to build a separate set of modules. So what >> is the point >> > in committing your pom to the source tree, if it is of use to only >> > yourself? >> > >> > Then the solution would be to build the whole thing. That >> would never >> > scale for complexity. Why would I want to build the whole kitchen >> > sink, if I am interested in building only a subset that is >> pertinent >> > to the task I am working on? A single version and top down >> build that >> > builds everything, IMHO, would create unnecessary coupling >> in complex projects. >> > >> > >> > If we rely on a top down build that builds everything, >> regardless of >> > area of the project we are working on, I would say we lack >> clarity in >> > terms of how the project is architecturally modularized. >> > >> > And for new comers to build samples, I agree with Jeremy >> that the best >> > thing to do is use mvn assemblies based on published artifacts. >> > >> > On a side note, I think you should never give up :) IMHO we should >> > have these constructive discussions, as long as they are >> in the best >> > interest of the community and the project. >> > >> > ta >> > Meeraj >> > >> > >> -Original Message- >> > >> From: Luciano Resende [mailto:[EMAIL PROTECTED] >> > >> Sent: 24 March 2007 00:05 >> > >> To: tuscany-dev@ws.apache.org >> > >> Subject: Re: Build structure - having cake and still eating >> > >> >> > >> OK, I give up on this, and I'll try not bring this subject up >> > >> anymore !!! >> > >> >> > >> I'll conti
RE: Objective of the following sandbox - tuscany/sandbox/sebastien/java
>> -Original Message- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 07:34 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Objective of the following sandbox - >> tuscany/sandbox/sebastien/java >> >> >> On Mar 23, 2007, at 8:52 PM, Jean-Sebastien Delfino wrote: >> >> > Davanum Srinivas wrote: >> >> Sebastien, >> >> >> >> Can you please explain to everyone the purpose of this >> svn area and >> >> what you are planning to do here? >> >> >> >> thanks, >> >> dims >> >> >> > >> > Dims, >> > >> > In the sandbox, I am trying to demonstrate a modular >> Tuscany kernel >> > that can support what I described in this thread: >> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15782.html >> > >> > I'm working on this in sandbox/sebastien/java/sca/modules. >> > >> > Basically I'm trying to come up with a set of black-box >> modules, with >> > minimum SPIs, minimum inter-dependencies, covering the following >> > aspects: >> > - modules/assembly - SCA core assembly model >> > - modules/policy - SCA Policy model >> > - modules/scdl - SCDL support (reading/writing the model >> from/to SCDL) >> > - modules/builder - A prototype of a different API to the assembly >> > model (showing how the same model can implement multiple >> interfaces) >> > - modules/java and java-scdl - SCA Java model and SCDL >> support for it >> > - modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL >> support for it >> > - modules/crud and crud-scdl - a prototype of a simplistic SCA >> > component implementation type, to help validate the >> pluggability into >> > the model and the SCDL support >> > - modules/http http-tomcat and http-jetty - embedded >> Tomcat and Jetty, >> > I want to experiment with a binding (probably based on >> HTTP) and I'm >> > not sure which to pick between Tomcat and Jetty for that >> so I pulled >> > these two modules in as well and put in modules/http a small >> > ServletHost interface that will help integrate them. >> > >> > I'm also just starting to prototype a variant >> implementation of the >> > assembly model, to see how a fairly different model >> implementation can >> > be swapped without breaking the other pieces (using the >> assembly model >> > API interfaces). >> > >> > So this first set of modules covers part of the SCA metadata/model >> > story. Next I'd like to start looking at the execution >> runtime and see >> > how the execution part of kernel/core can be split in >> multiple modules >> > as well. I'd like to see how the SCA Java component support can be >> > extracted as a separate module for example. >> > >> > I also copied to my sandbox a top-down build structure >> including end >> > to end samples and integration tests, which I'd like to use to >> > validate that these ideas and this assembly of modules >> hold together. >> > >> > So, as I said in the above thread, I'd like feedback, >> ideas or help >> > with this work. People have asked for a more concrete proposal and >> > more details, the proposal is starting to take shape, and >> I'm happy to >> > continue to work on it wherever the community feel it >> should be done. >> >> From looking at the above description and the commit >> history it seems you have forked the code. For example, the >> "variant implementation of the assembly model" has a number >> of changes that coupled with what you describe above will >> basically require a re- write of kernel. What are the >> reasons for these changes? Couldn't trunk be incrementally >> improved? Are there any plans for merging this with trunk? >> Is this a revolution? >> >> Jim >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> This message has been checked for all email viruses by MessageLabs. >> I would like to know how this would impact all the work we have done in the last couple of months on trunk in terms of separating the logical and physical. From, a technical perspective, Sebastien's proposal is drastically different from what we have now in trunk. So a merge into the trunk is not going to be practical. Which means, if we decide to go with Sebastien's proposal, we will be starting from scratch and throwing away a lot of work that has been done in the last two months. I am willing to go with it, if I am some convinces me about what is wrong with what we currently have in trunk, rather than what is good about Sebastien's proposal. It is laudable, Sebastien wants to discuss his proposal within the community. However, when there were discussion threads on federation, logical/physical separation, management etc, the only two people who actively participated in the discussions were Jeremy, Jim and myself. Now we have a proposal that is going to throw away a lot of the work some of us have put in, without even taking into consideration what has
RE: Build structure - having cake and still eating
Luciano, Your hijacked version of pom portrays all the issues associated with a top down pom with a single version in a complex project. You have included the modules you want to build. It may not be of any use to me, if I want to build a separate set of modules. So what is the point in committing your pom to the source tree, if it is of use to only yourself? Then the solution would be to build the whole thing. That would never scale for complexity. Why would I want to build the whole kitchen sink, if I am interested in building only a subset that is pertinent to the task I am working on? A single version and top down build that builds everything, IMHO, would create unnecessary coupling in complex projects. If we rely on a top down build that builds everything, regardless of area of the project we are working on, I would say we lack clarity in terms of how the project is architecturally modularized. And for new comers to build samples, I agree with Jeremy that the best thing to do is use mvn assemblies based on published artifacts. On a side note, I think you should never give up :) IMHO we should have these constructive discussions, as long as they are in the best interest of the community and the project. ta Meeraj >> -Original Message- >> From: Luciano Resende [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 00:05 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Build structure - having cake and still eating >> >> OK, I give up on this, and I'll try not bring this subject >> up anymore !!! >> >> I'll continue with my hijacked java/pom.xml and update it as >> needed, I just feel sorry for the new people that will come >> to the Tuscany community and will fill the same pain as >> Mario and others. >> >> Just in case others might benefit from this, here are the >> profiles I have in my hijacked java/pom.xml that is working >> at the moment and building sca or sdo or das. >> >> >> >> >> sdo >> >> sdo >> >> >> >> >> >> das >> >> das >> >> >> >> >> >> sca >> >> >> pom/parent >> pom/sca >> buildtools >> >> >> spec/sca-api-r1.0 >> >> >> sca/kernel >> sca/runtime >> sca/services >> sca/console >> sca/jms-discovery >> sca/http.jetty >> >> >> sca/core-samples >> >> sca/core-samples/standalone/calculator >> >> sca/core-samples/standalone/loanapplication >> >> >> >> sca/integration-test >> >> >> >> >> >> >> >> -- >> Luciano Resende >> http://people.apache.org/~lresende >> >> On 3/23/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> > >> > >> > On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote: >> > >> > > Jeremy >> > > >> > > So, having these assemblies modules sounded interesting to me >> > > until the moment you said you want to base them on deployed >> > > artifacts... we have never had a habit of publishing >> SNAPSHOTS for >> > > all possible artifacts, and even the members of the >> community that >> > > are proposing this approach are failing to deploy the SNAPSHOTS >> > > artifacts and Mario's pain is a prove of this. >> > >> > Ideally the deployed artifacts they would depend on would >> be stable >> > released ones - this is directly inline with the stability goals >> > expressed by the likes of Dave Booz. In general, >> aggregations should >> > not depend on SNAPSHOTs or a head revision except where absolutely >> > necessary. >> > >> > Mario's pain was caused because we had not put together an >> assembly of >> > the modules needed for the demo. It was the wee hours of >> the morning, >> > I hope you understand. Once the dust settled, the modular, >> independent >> > nature of what we had allowed us to put together a very simple >> > assembly for building exactly that (independent of any >> other activity >> > in trunk). You can see this here: >> > >> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- >> > demo >> > >> > > >> > > You also mentioned before that we have M2 experience >> of a top down >> > > build not working, I'm not sure about all the details >> that comes to >> > > your mind when you say that, but I remember some build >> brakes (and I >> > > think this is acceptable in trunk, right ?) >> > >> > No, not really. >> > >> > > and we could set some conventions like, modules that are >> "unstable >> > > at the moment" would be removed from the maven profile >> (and maybe a >> > > JIRA would be created)... later on, when the module is >> back to it's >> > > stability, wh
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 Tusc
RE: Planning kernel release 2.0
Hi, I think most of the stuff here are from the original list Jim posted. What I would suggest is to the collate the two lists and publish that as a roadmap for the 2.0 release. Ta Meeraj -Original Message- From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 11:15 PM To: tuscany-dev@ws.apache.org Subject: Re: Planning kernel release 2.0 What happened to the Kernel Alpha 2 release discussion thread that Jim started on March 13th. It looks like we are restarting. On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > I have some cleanup work to do on work and on scopes but I would > expect to get that done in the next day or so (ready for the next > alpha). > > On the physical model, I would like to get the bytecode based IFP > going to simplify the PCD message. We also need to get complex > properties working. > > From the end-user experience, we need to finish implementing the Java > C&I APIs - stuff like support for the Conversation interface and > casting for ServiceReference etc. We should also look at the JavaEE > integration spec. I think our impl type may be close. > > We also need to beef up the console with more management function, > support for displaying the state of the assembly and federation, and > support for contributing artifacts and managing them afterwards. > > Plus all the stuff you mention of course :-) > > I don't think the SPI is quite as stable as Dave would like but we > should be able to improve things after alpha2. I think we should > target an SPI freeze for the beta (June you were suggesting), at least > for incompatible changes. To do that we need to have built a couple of > bindings/containers on top of it. > > -- > Jeremy > > On Mar 22, 2007, at 4:01 AM, Meeraj Kunnumpurath wrote: > > > Hi, > > > > Now that the SPI is getting stable and we have the initial > > end-to-end story for federation working, I would suggest we plan for > > the final release for kernel 2.0, with emphasis on federation and > > user experience. > > I was thinking about aiming for a beta in June in time for TSSJS > > Barcelona and the final release for August. Maybe we can have couple > > of alpha releases from now and June as well. These are the features, > > I would like to see in 2.0. > > > > 1. Tidy up anything required in physical model, now that it is > > starting to take good shape. > > 2. Tidy up generators from logical to physical model. > > 3. Fix the JXTA discovery issues, also investigate other discovery > > protocols. > > 4. Federation end-to-end fully completed, this would include, maybe, > > profiles advertising their capabilities and the information being > > used in intent-based autowiring etc. > > 5. Intent-based auto wiring > > 6. Emphasis on end user experience in terms of ease of use. > > 7. Assembly service, this kind of now related to the generators that > > have been introduced in the last week or so 8. Artifact management, > > especially mobile code when we target components to remote profiles. > > > > Also, now the SPI has started settling in, we need to start looking > > at binding and container extensions as well. Some of the bindings I > > would be interested in are, > > > > 1. JMS > > 2. AMQP > > 3. Hessian > > > > Ta > > Meeraj > > > > > > * > > > > 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] > > This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ServerSide Presentation and Demo
Ta, Actually Jeremy and Jim did most of it. >> -Original Message- >> From: Kevin Williams [mailto:[EMAIL PROTECTED] >> Sent: 22 March 2007 20:44 >> To: tuscany-dev@ws.apache.org >> Subject: Re: ServerSide Presentation and Demo >> >> Jim and Meeraj, >> Congratulations! Any chance the presentation was taped? >> --Kevin >> >> >> Jim Marino wrote: >> >> > Hi, >> > >> > We just finished the ServerSide demo and I figured I send >> a mail to >> > the list outlining how it went... >> > >> > We had the slot following the opening keynote and were up >> against Rod >> > (Spring) and Patrick (OpenJPA) as the other two talks. I was >> > surprised to find that the ballroom was pretty full. I >> gave the talk >> > and the demo showing end-to-end federated deployment and reaction >> > seemed very positive. Meeraj gets the "hero" award for >> staying up to >> > an obscene hour in the morning to implement a JMS-based discovery >> > service as we encountered last-minute hiccups with JXTA. >> > >> > My observations are: >> > >> > - After speaking with people after the presentation, >> feedback on the >> > value of SCA was consistent. Specifically, they thought the >> > programming model was nice but not a differentiator. What >> people got >> > excited about was being able to dynamically provision services to >> > remote nodes and have a representation of their service >> network. In >> > this respect, I think the demo worked well. Two people >> said they need >> > what the demo showed for projects they currently have underway. >> > >> > - People asked how SCA is different than Spring. They reacted >> > positively when I said "federation" and "distributed >> wiring". Related >> > to this, people get dependency injection (i.e. it's >> old-hat) and just >> > seem to assume that is the way local components obtain references. >> > >> > - People seemed to react positively when I compared SCA to >> Microsoft >> > WCF >> > >> > - People liked the idea of heterogeneous service networks >> and support >> > for components written in different languages, particularly C++. >> > >> > - People didn't ask about web services. People were nodding their >> > heads (in agreement) when I talked about having the runtime select >> > alternative bindings such as AMQP and JMS. >> > >> > - People want modularity and choice. Two areas they wanted >> choice in >> > was databinding and persistence. They liked the fact that >> we are not >> > locked into one databinding solution and that we have JPA >> integration. >> > (as an aside, they also liked that SDO can be used without SCA). >> > Spring integration was also popular. >> > >> > - People also liked the idea of a 2MB kernel download. One person >> > mentioned they only want to download what they intend to >> use and not a >> > lot of extra "clutter". >> > >> > - People wanted to know how SCA is different than an ESB. >> I basically >> > described it using the switch vs. router metaphor and how >> a component >> > implementation type can be a proxy for an ESB. Related to this and >> > point-to-point wires, people thought wire optimization by the >> > Controller was cool. >> > >> > - People seemed to be more interested in running Tuscany as a >> > standalone edge server or embedded in an OSGi container. I >> didn't get >> > any questions about running Tuscany in a Servlet container or J2EE >> > application server. This seems to be consistent with there being a >> > number of talks on server-side OSGi. >> > >> > My big takeway is that we need to make the demo a reality. >> > >> > Jim >> > >> > >> > >> > >> > >> > >> > >> - >> > 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]
RE: Compilation status
Ant, I would like to understand more about what we mean by top down build here. We didn't use to build SCA and SDO in one go, even when we had a "top down" build. Now the SCA project is growing in complexity with better modularization, in terms of of how various functional areas are modularized and new extensions being added. We are having more abstractions in the SPI, and more than one pluggable implementations. For example, discovery in SPI currently have a JXTA and JMS implementation. Soon there will be a JINI one. Management in SPI has a JMX implementation, someone may want to add a WSDM one later. I can understand having the ability to build related modules together. However, why would I want the top-down build to build everything, when for example, I am only interested in JMS binding and not Axis binding? When the project goes in complexity, IMHO, it would be easier to treat these functionally different areas separately, rather than building the whole thing together. However, if everyone else is finding this difficult, I am open to discussions on discussing other mechanisms like using different mvn profiles. For me, I haven't found the lack of a "mother of all build" an inhibiting factor. Thanks Meeraj -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 4:26 PM To: tuscany-dev@ws.apache.org Subject: Re: Compilation status On 3/22/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > I hate to bring up this issue again, but I really share the pain that > Mario just went through. Don't we think we have room for improvements > to build the stuff in a much simpler fashion? To me, to have a build > for a bundle which consists of a set of the modules working together > at the same level would be really helpful for the poor guys. It's very > difficult to manually coordinate the build across modules even with > published SNAPSHOTs (which I don't see it happens frequently and it's > also very hard because a collection of SNAPSHOTs don't really > establish a baseline for those who want to try the latest code). > > I (assume that I) understand all the rationales and pricinples for > modulization. But I'm really scared by the user experiences. Where is > the reasonable middle ground? > > Thanks, > Raymond +1, I agree with all said here. Not being able to do a top down build is +a real turn off. Its fine if some don't want to use it but i don't think that should prevent us having this facility for those who do think it is useful. ...ant 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]
RE: Compilation status
Raymond, I think in this specific scenario, we were trying to build an assembly from different components. This included the kernel, standalone server, a discovery implementation, amanagement implementation, one of the sample applications etc. I don't think having a single maven POM that included all the modules for all the artifacts being assembled would have been practically feasible. In such scenarios, IMO, an assembly is exactly what we need. It is assembling a distribution from a set of components that have already been built. We can't expect the assembly to build all the components it assembles. Howabout, the transitive dependencies for those components? Would we get the assembly build to build them as well? From, my experience in the last two months, I haven't found the lack of a pom that included all the modules to be built, an inhibiting factor. Rather, I had a clear picture of what artifacts I wanted for the task I was doing and built them individually or depended on published snapshots. As the system grows in complexity it is difficult to have everything built in one go. That would be introducing unnecessary coupling. My personal view would be to build related components together, like the kernel pom including SPI, core, host-api etc and runtime building standalone, runtime services etc. Thanks Meeraj -Original Message- From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 3:50 PM To: tuscany-dev@ws.apache.org Subject: Re: Compilation status Hi, I hate to bring up this issue again, but I really share the pain that Mario just went through. Don't we think we have room for improvements to build the stuff in a much simpler fashion? To me, to have a build for a bundle which consists of a set of the modules working together at the same level would be really helpful for the poor guys. It's very difficult to manually coordinate the build across modules even with published SNAPSHOTs (which I don't see it happens frequently and it's also very hard because a collection of SNAPSHOTs don't really establish a baseline for those who want to try the latest code). I (assume that I) understand all the rationales and pricinples for modulization. But I'm really scared by the user experiences. Where is the reasonable middle ground? Thanks, Raymond - Original Message - From: "Antollini, Mario" <[EMAIL PROTECTED]> To: Sent: Thursday, March 22, 2007 6:57 AM Subject: RE: Compilation status Meeraj, Finally, I was able to generate the server.star.jar file. This is compilation order that worked for me: java/spec/commonj/ java/spec/sca-api-r1.0/ java/sca/kernel/ java/sca/runtime/ java/sca/services/ java/sca/contrib/discovery/ java/sca/contrib/discovery/jms java/sca/console/ java/sca/core-samples/ java/distribution/sca/demo.app java/distribution/sca/demo/ Disclaimer: I have been struggling with the compilation for two days, I cannot fully assure that the order of the above list is the actual order. If anyone is able to compile this exact way, please let us know. BTW, java/sca/extensions/ cannot be compiled for now. Besides the good news, I was not able to start the servers (take a look at the attachment to see the errors) Do you have any idea what could be happening? Thanks and regards, Mario -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 10:13 AM To: tuscany-dev@ws.apache.org Subject: RE: Compilation status Mario, AFAIK extensions in trunk is still in a bit of a flux. If you want to run the demo, you don't need to run the extensions (the demo uses Java container with local bindings), I will try to post a dfeinitive list of tasks to build and run the demo later in the day, which will be useful to Simon as well. Ta Meeraj -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:29 PM To: tuscany-dev@ws.apache.org Subject: Compilation status Meeraj, I just wanted you to know that I am still not able to compile the code I checked out from SVN. The main problem is located in the *extensions* project. I have been modifying the pom files within this project but I did not manage to get it compiled yet. Basically, the main problems are related to inconsistencies between parent references (e.g.; axis2's root project is using groupId *org.apache.tuscany.sca.axis2* while the plugin subproject states that its parent is *org.apache.tuscany.sca.extensions.axis2*). Any tips about this? Thanks, Mario 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
RE: A question of federation - was: Planning kernel release 2.0
Simon, As Jim mentioned in an earler email, A single-VM or runtime physical topology is just a degenerate case of a multi-VM model. In a single-VM scenario there is only one profile that runs the master and the slave. With some minor modifications, we should be able to run the TSS demo in a single VM mode from deploying the SCDL within the admin console, through to invoking the application. That has been one of the key drivers for separating logical and physical aspects of the model. Physical model is generated from the logical model based on the targeted runtimes for the components included in the composite that is being contributed. In a single-VM model, all the physical components will be targeted onto the same runtime. In fact, though the demo showed the federation aspects of Tuscany, the actual application after deployment onto the slave ran in single-VM mode using local bindings. HTH Ta Meeraj -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:22 PM To: tuscany-dev@ws.apache.org Subject: A question of federation - was: Planning kernel release 2.0 On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > > Hi, > > Now that the SPI is getting stable and we have the initial end-to-end > story for federation working, I would suggest we plan for the final > release for kernel 2.0, with emphasis on federation and user experience. > I was thinking about aiming for a beta in June in time for TSSJS > Barcelona and the final release for August. Maybe we can have couple > of alpha releases from now and June as well. These are the features, I > would like to see in 2.0. > > 1. Tidy up anything required in physical model, now that it is > starting to take good shape. > 2. Tidy up generators from logical to physical model. > 3. Fix the JXTA discovery issues, also investigate other discovery > protocols. > 4. Federation end-to-end fully completed, this would include, maybe, > profiles advertising their capabilities and the information being used > in intent-based autowiring etc. > 5. Intent-based auto wiring > 6. Emphasis on end user experience in terms of ease of use. > 7. Assembly service, this kind of now related to the generators that > have been introduced in the last week or so 8. Artifact management, > especially mobile code when we target components to remote profiles. > > Also, now the SPI has started settling in, we need to start looking at > binding and container extensions as well. Some of the bindings I would > be interested in are, > > 1. JMS > 2. AMQP > 3. Hessian > > Ta > Meeraj > > > * > > 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] > > Hi Meeraj From my perspective having demonstrable code in June would be spot on as I have to speak on SCA then and would consider a demo if we could do it. I don't have the knowledge yet to comment on the details of your proposal just yet (hence the new subject) but a question. From a future demo point of view I would like to show various runtime options some of which are not federated examples some of which are. Can I miss out the federation bit if I want to? For example, I would potentially like to show a variety of scenarios - Hello world. the simplest possible single process example to get people into how SCA works - Standalone domain (a single VM) service provision (perhaps an AJAX style example where an SCA composite provides services to the browser) service consumption (backend service access providing content to my AJAX service) - Federated domain (multiple VM) How SCA describes many connected composites. I'm just starting now to look at how all the kernel stuff works so I expect all this will become clear soon enough (I found your previous posts giving explantion b.t.w - so am starting from there) Regards Simon This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ServerSide Presentation and Demo
Simon, My reply to Mario has all the detail to run the demo. Ta Meeraj -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:00 PM To: tuscany-dev@ws.apache.org Subject: Re: ServerSide Presentation and Demo On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > > Simon, > > All the work that was done for the demo has been committed. I posted a > set of build instructions to get the demo running for Mario. However, > the information is scattered across multiple emails. I can collate > them and repost it to the list, if that helps. > > Thanks > Meeraj > > -Original Message- > From: Simon Laws [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 22, 2007 11:31 AM > To: tuscany-dev@ws.apache.org > Subject: Re: ServerSide Presentation and Demo > > On 3/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > Hi Jim, > > > > Thanks for sharing this information - its really useful. > > > > - Venkat > > > > On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > We just finished the ServerSide demo and I figured I send a mail > > > to the list outlining how it went... > > > > > > We had the slot following the opening keynote and were up against > > > Rod > > > (Spring) and Patrick (OpenJPA) as the other two talks. I was > > > surprised to find that the ballroom was pretty full. I gave the > > > talk > > > > and the demo showing end-to-end federated deployment and reaction > > > seemed very positive. Meeraj gets the "hero" award for staying up > > > to an obscene hour in the morning to implement a JMS-based > > > discovery > > > > service as we encountered last-minute hiccups with JXTA. > > > > > > My observations are: > > > > > > - After speaking with people after the presentation, feedback on > > > the > > > > value of SCA was consistent. Specifically, they thought the > > > programming model was nice but not a differentiator. What people > > > got > > > > excited about was being able to dynamically provision services to > > > remote nodes and have a representation of their service network. > > > In > > > > this respect, I think the demo worked well. Two people said they > > > need what the demo showed for projects they currently have underway. > > > > > > - People asked how SCA is different than Spring. They reacted > > > positively when I said "federation" and "distributed wiring". > > > Related to this, people get dependency injection (i.e. it's > > > old-hat) > > > > and just seem to assume that is the way local components obtain > references. > > > > > > - People seemed to react positively when I compared SCA to > > > Microsoft > > > > WCF > > > > > > - People liked the idea of heterogeneous service networks and > > > support for components written in different languages, > > > particularly > C++. > > > > > > - People didn't ask about web services. People were nodding their > > > heads (in agreement) when I talked about having the runtime select > > > alternative bindings such as AMQP and JMS. > > > > > > - People want modularity and choice. Two areas they wanted choice > > > in > > > > was databinding and persistence. They liked the fact that we are > > > not > > > > locked into one databinding solution and that we have JPA > > > integration. (as an aside, they also liked that SDO can be used > > > without SCA). Spring integration was also popular. > > > > > > - People also liked the idea of a 2MB kernel download. One person > > > mentioned they only want to download what they intend to use and > > > not > > > > a lot of extra "clutter". > > > > > > - People wanted to know how SCA is different than an ESB. I > > > basically described it using the switch vs. router metaphor and > > > how a component implementation type can be a proxy for an ESB. > > > Related to this and point-to-point wires, people thought wire > > > optimization by the Controller was cool. > > > > > > - People seemed to be more interested in running Tuscany as a > > > standalone edge server or embedded in an OSGi container. I didn't > > > get any questions about running Tuscany in a Se
RE: Compilation status
Jeremy, This is the definitve list, thanks to Mario. java/spec/commonj/ java/spec/sca-api-r1.0/ java/sca/kernel/ java/sca/runtime/ java/sca/services/ java/sca/contrib/discovery/ java/sca/contrib/discovery/jms java/sca/console/ java/sca/core-samples/ java/distribution/sca/demo.app java/distribution/sca/demo/ Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 1:52 PM To: tuscany-dev@ws.apache.org Subject: Re: Compilation status I think we should tag and deploy SNAPSHOTs of the revision used for the demo - that way people can build as much or as little as they wish. If you can post the list, I get those modules tagged and deployed later today. -- Jeremy On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote: > Mario, > > AFAIK extensions in trunk is still in a bit of a flux. If you want to > run the demo, you don't need to run the extensions (the demo uses Java > container with local bindings), I will try to post a dfeinitive list > of tasks to build and run the demo later in the day, which will be > useful to Simon as well. > > Ta > Meeraj > > -Original Message- > From: Antollini, Mario [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 22, 2007 12:29 PM > To: tuscany-dev@ws.apache.org > Subject: Compilation status > > Meeraj, > > > > I just wanted you to know that I am still not able to compile the code > I checked out from SVN. The main problem is located in the > *extensions* project. I have been modifying the pom files within this > project but I did not manage to get it compiled yet. > > > > Basically, the main problems are related to inconsistencies between > parent references (e.g.; axis2's root project is using groupId > *org.apache.tuscany.sca.axis2* while the plugin subproject states that > its parent is *org.apache.tuscany.sca.extensions.axis2*). > > > > Any tips about this? > > > > Thanks, > > Mario > > > 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] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compilation status
Mario, That is great. What you have is the definitive list. If you are going to look at the JXTA problem, you will have to use discovery/jxta instead of discovery/jms. Also, you will have to change the master|slave1|slave2/system.scdl, demo.xml and pom.xml in the demo project to use JXTA instead of JMS. This is how you start the servers (Please make sure you start ActiveMQ before you start the servers) . Master: java -Dtuscany.adminPort=2000 -jar server.start.jar master Slave1: java -Dtuscany.adminPort=3000 -jar server.start.jar slave1 Slave2: java -Dtuscany.adminPort=4000 -jar server.start.jar slave2 You can access the admin console from http://localhost:7000/scdlForm and if you target the deployed SCDL to slave1, access the demo appilcation from http://localhsot:8000/calculatorForm. The test scdl is as follows (this is what you submit from the admin console to target a deployment to a slave), http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/2.0-alpha"; name="CalculatorComposite"> BTW, I didn't get your attachment, if you still get any isues pls open a JIRA. Ta Meeraj -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 1:58 PM To: tuscany-dev@ws.apache.org Subject: RE: Compilation status Meeraj, Finally, I was able to generate the server.star.jar file. This is compilation order that worked for me: java/spec/commonj/ java/spec/sca-api-r1.0/ java/sca/kernel/ java/sca/runtime/ java/sca/services/ java/sca/contrib/discovery/ java/sca/contrib/discovery/jms java/sca/console/ java/sca/core-samples/ java/distribution/sca/demo.app java/distribution/sca/demo/ Disclaimer: I have been struggling with the compilation for two days, I cannot fully assure that the order of the above list is the actual order. If anyone is able to compile this exact way, please let us know. BTW, java/sca/extensions/ cannot be compiled for now. Besides the good news, I was not able to start the servers (take a look at the attachment to see the errors) Do you have any idea what could be happening? Thanks and regards, Mario -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 10:13 AM To: tuscany-dev@ws.apache.org Subject: RE: Compilation status Mario, AFAIK extensions in trunk is still in a bit of a flux. If you want to run the demo, you don't need to run the extensions (the demo uses Java container with local bindings), I will try to post a dfeinitive list of tasks to build and run the demo later in the day, which will be useful to Simon as well. Ta Meeraj -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:29 PM To: tuscany-dev@ws.apache.org Subject: Compilation status Meeraj, I just wanted you to know that I am still not able to compile the code I checked out from SVN. The main problem is located in the *extensions* project. I have been modifying the pom files within this project but I did not manage to get it compiled yet. Basically, the main problems are related to inconsistencies between parent references (e.g.; axis2's root project is using groupId *org.apache.tuscany.sca.axis2* while the plugin subproject states that its parent is *org.apache.tuscany.sca.extensions.axis2*). Any tips about this? Thanks, Mario 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] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compilation status
Mario, AFAIK extensions in trunk is still in a bit of a flux. If you want to run the demo, you don't need to run the extensions (the demo uses Java container with local bindings), I will try to post a dfeinitive list of tasks to build and run the demo later in the day, which will be useful to Simon as well. Ta Meeraj -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:29 PM To: tuscany-dev@ws.apache.org Subject: Compilation status Meeraj, I just wanted you to know that I am still not able to compile the code I checked out from SVN. The main problem is located in the *extensions* project. I have been modifying the pom files within this project but I did not manage to get it compiled yet. Basically, the main problems are related to inconsistencies between parent references (e.g.; axis2's root project is using groupId *org.apache.tuscany.sca.axis2* while the plugin subproject states that its parent is *org.apache.tuscany.sca.extensions.axis2*). Any tips about this? Thanks, Mario 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]
RE: ServerSide Presentation and Demo
Simon, All the work that was done for the demo has been committed. I posted a set of build instructions to get the demo running for Mario. However, the information is scattered across multiple emails. I can collate them and repost it to the list, if that helps. Thanks Meeraj -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 11:31 AM To: tuscany-dev@ws.apache.org Subject: Re: ServerSide Presentation and Demo On 3/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi Jim, > > Thanks for sharing this information - its really useful. > > - Venkat > > On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > We just finished the ServerSide demo and I figured I send a mail to > > the list outlining how it went... > > > > We had the slot following the opening keynote and were up against > > Rod > > (Spring) and Patrick (OpenJPA) as the other two talks. I was > > surprised to find that the ballroom was pretty full. I gave the talk > > and the demo showing end-to-end federated deployment and reaction > > seemed very positive. Meeraj gets the "hero" award for staying up > > to an obscene hour in the morning to implement a JMS-based discovery > > service as we encountered last-minute hiccups with JXTA. > > > > My observations are: > > > > - After speaking with people after the presentation, feedback on the > > value of SCA was consistent. Specifically, they thought the > > programming model was nice but not a differentiator. What people got > > excited about was being able to dynamically provision services to > > remote nodes and have a representation of their service network. In > > this respect, I think the demo worked well. Two people said they > > need what the demo showed for projects they currently have underway. > > > > - People asked how SCA is different than Spring. They reacted > > positively when I said "federation" and "distributed wiring". > > Related to this, people get dependency injection (i.e. it's old-hat) > > and just seem to assume that is the way local components obtain references. > > > > - People seemed to react positively when I compared SCA to Microsoft > > WCF > > > > - People liked the idea of heterogeneous service networks and > > support for components written in different languages, particularly C++. > > > > - People didn't ask about web services. People were nodding their > > heads (in agreement) when I talked about having the runtime select > > alternative bindings such as AMQP and JMS. > > > > - People want modularity and choice. Two areas they wanted choice in > > was databinding and persistence. They liked the fact that we are not > > locked into one databinding solution and that we have JPA > > integration. (as an aside, they also liked that SDO can be used > > without SCA). Spring integration was also popular. > > > > - People also liked the idea of a 2MB kernel download. One person > > mentioned they only want to download what they intend to use and not > > a lot of extra "clutter". > > > > - People wanted to know how SCA is different than an ESB. I > > basically described it using the switch vs. router metaphor and how > > a component implementation type can be a proxy for an ESB. Related > > to this and point-to-point wires, people thought wire optimization > > by the Controller was cool. > > > > - People seemed to be more interested in running Tuscany as a > > standalone edge server or embedded in an OSGi container. I didn't > > get any questions about running Tuscany in a Servlet container or > > J2EE application server. This seems to be consistent with there > > being a number of talks on server-side OSGi. > > > > My big takeway is that we need to make the demo a reality. > > > > Jim > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > Jim, Nice one. Thanks for the summary. Did the conference record the talk? Would be good to see it. Noting your comment and recent mails about the last minute changes to get JMS working in short order, is everything checked in that's needed to run the demo? Looking back I see several notes on build instructions and it would be pretty cool to give it a spin. Can I ask a question about support for components written in different languages? Did people specifically say they were interested in C++? Did they mention other languages (and, if so, which ones)? Presumably the sweet spot is the ability to show components implemented in various languages all acting as part of a single SCA Domain. How big a deal do you think this ability to be able to draw a "picture" of you heterogeneous service network (in SCDL) vs some of the other things you mention like "standalone edge server" or "selectable bindings". I'm asking this question because, as you know, I like the idea and from your notes
Planning kernel release 2.0
Hi, Now that the SPI is getting stable and we have the initial end-to-end story for federation working, I would suggest we plan for the final release for kernel 2.0, with emphasis on federation and user experience. I was thinking about aiming for a beta in June in time for TSSJS Barcelona and the final release for August. Maybe we can have couple of alpha releases from now and June as well. These are the features, I would like to see in 2.0. 1. Tidy up anything required in physical model, now that it is starting to take good shape. 2. Tidy up generators from logical to physical model. 3. Fix the JXTA discovery issues, also investigate other discovery protocols. 4. Federation end-to-end fully completed, this would include, maybe, profiles advertising their capabilities and the information being used in intent-based autowiring etc. 5. Intent-based auto wiring 6. Emphasis on end user experience in terms of ease of use. 7. Assembly service, this kind of now related to the generators that have been introduced in the last week or so 8. Artifact management, especially mobile code when we target components to remote profiles. Also, now the SPI has started settling in, we need to start looking at binding and container extensions as well. Some of the bindings I would be interested in are, 1. JMS 2. AMQP 3. Hessian Ta Meeraj * 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]
RE: Demo Build error
Also did you build /java/sca/runtime? That is where server.start, standalone-host etc are located. Since our last communication I have also added /java/distribution/demo.app, which needs to be built as well. Ta Meeraj -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 5:30 PM To: tuscany-dev@ws.apache.org Subject: Demo Build error Hi Meeraj, There is an error while building demo, therefore I cannot get the server.start.jar generated. This is the output of maven: Missing: -- 1) org.apache.tuscany.sca.core-samples.common:calculator:jar:2.0-alpha2-inc ubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.core-samples.common -DartifactId=calculator \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.core-samples.common:calculator:jar:2.0-alpha2-inc ubating-SNAPSHOT 2) org.apache.tuscany.sca.runtime.standalone:server.start:jar:2.0-alpha2-in cubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.runtime.standalone -DartifactId=server.start \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.runtime.standalone:server.start:jar:2.0-alpha2-in cubating-SNAPSHOT 3) org.apache.tuscany.sca.runtime.standalone:standalone-host:jar:2.0-alpha2 -incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.runtime.standalone -DartifactId=standalone-host \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.runtime.standalone:standalone-host:jar:2.0-alpha2 -incubating-SNAPSHOT 4) org.apache.tuscany.sca.runtime.services.discovery:discovery-jms:jar:2.0- alpha2-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.runtime.services.discovery -DartifactId=discovery-jms \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.runtime.services.discovery:discovery-jms:jar:2.0- alpha2-incubating-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 minutes 6 seconds [INFO] Finished at: Wed Mar 21 14:25:36 ART 2007 [INFO] Final Memory: 8M/15M [INFO] All the missing artifacts are referenced from the pom fle in DEMO project. Is there something missing in the svn? Thanks, Mario Antollini 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: [EM
RE: Demo Build error
Sorry, I missed one. You need to build /java/sca/core-samples/common as well. HTH Meeraj -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 5:30 PM To: tuscany-dev@ws.apache.org Subject: Demo Build error Hi Meeraj, There is an error while building demo, therefore I cannot get the server.start.jar generated. This is the output of maven: Missing: -- 1) org.apache.tuscany.sca.core-samples.common:calculator:jar:2.0-alpha2-inc ubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.core-samples.common -DartifactId=calculator \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.core-samples.common:calculator:jar:2.0-alpha2-inc ubating-SNAPSHOT 2) org.apache.tuscany.sca.runtime.standalone:server.start:jar:2.0-alpha2-in cubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.runtime.standalone -DartifactId=server.start \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.runtime.standalone:server.start:jar:2.0-alpha2-in cubating-SNAPSHOT 3) org.apache.tuscany.sca.runtime.standalone:standalone-host:jar:2.0-alpha2 -incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.runtime.standalone -DartifactId=standalone-host \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.runtime.standalone:standalone-host:jar:2.0-alpha2 -incubating-SNAPSHOT 4) org.apache.tuscany.sca.runtime.services.discovery:discovery-jms:jar:2.0- alpha2-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca.runtime.services.discovery -DartifactId=discovery-jms \ -Dversion=2.0-alpha2-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT 2) org.apache.tuscany.sca.runtime.services.discovery:discovery-jms:jar:2.0- alpha2-incubating-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.tuscany.distribution.sca:demo:pom:2.0-alpha2-incubating-SNAPS HOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 minutes 6 seconds [INFO] Finished at: Wed Mar 21 14:25:36 ART 2007 [INFO] Final Memory: 8M/15M [INFO] All the missing artifacts are referenced from the pom fle in DEMO project. Is there something missing in the svn? Thanks, Mario Antollini 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]
RE: Revolutions or a Mess!!
Hi, I am glad you brought this point up. You mentioned about constant confrontation between two sets of people. I would say, unfortunately, this has been caused by a lack of diversity in the community. I hope most of these confrontations are based on technical differences. For the first group, who I understand all work for a specific vendor, the push has always been just on simple spec compliance, with no emphasis on value adds, end user experience etc. I am not saying that spec compliance is an inconsequential issue; however, there are other issues that are as important. To give an example, some of the work that has been happening on distributed heterogeneous federation is something which I think is a key differentiator for Tuscany. This has been discussed heavily on the list, and unfortunately only three of the committers, who don't work for a specific vendor, that took any interest in this discussion. I sincerely hope the technical direction within Tuscany is not purely shaped by a given vendor's aspirations for getting their product suite SCA-compliant. Otherwise, independent committers like me would be wasting our time on this. I would say we need to generate better community interest and bring in more independent committers, so that there is a better balance on technical debates. Unfortunately, these constant conflicts have been putting people off. I don't think the differences are irreconcilable; however, there should be a willingness from both sides to have an open discussion, leaving other vested interests out, purely based on what is best for us as a community to build Tuscany. Thanks Meeraj -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 1:31 PM To: tuscany-dev@ws.apache.org Subject: Revolutions or a Mess!! Folks, I don't really like what's going on. Too much conflicts between people. Whatever be the issue of the day, I see 2 sets of people in constant confrontation. The constant branching/merging is not healthy or productive. Is there any effort or hope of reconciliation or should we start looking at other options? Thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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]
RE: Working in trunk, was: Componentizing our SCA runtime kernel
I think this was the final email, in the thread of discussion we had on different ways of doing the model. Ta Meeraj -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:54 AM To: tuscany-dev@ws.apache.org Subject: Re: Working in trunk, was: Componentizing our SCA runtime kernel "we decided to abandon"...was there a VOTE? Please refresh my memory. thanks, dims On 3/21/07, Jim Marino <[EMAIL PROTECTED]> wrote: > > On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote: > > > Hi Sebastien > > > > My understanding is that these are separate modules that are not > > going to destabelize the trunk at the moment. My personal opinion is > > that it would be OK to have this work done in the trunk as most of > > new work is being developed. > > The proposed model changes will require a significant re-write of the > kernel and re-introduce an old design that we decided to abandon about > a year ago. > > Is that what people want to do? > > Jim > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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.--- Begin Message --- With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. --- End Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
I can't see how kernel modularization is related to interface based models. Model is only part of the SPI, SPI also provides a set os services, which all have well-defined contracts. I am not sure what extra benefits we have by supporting different data binding mechanisms for the model objects. If I remember right, we had this discussion a long while ago and we decided to go with Java based model objects. I have never found a need to mock model objects in the tests, as the model objects, as I said earlier, don't have any behaviour. We often mock, service objects that do have behaviour. If this about modularizing SPI, I would say it is an affort worth discussing. However, the model changes, I can't see any visible benefit in doing that. Since we have already had discussion on this during M1 and we decided to go with Java based POJO model classes, I believe it is water under bridge and can't see the point in bringing this up again. Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces Date: Tue, 20 Mar 2007 08:56:40 -0700 On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X ] -1 keep things as they are -1 from me. This is an alternative implementation of what we have with kernel and not just a simple "model refactor" or "modularization". Many of the changes include rolling back directions we decided to take following the issues encountered with M1. For example, the move away from pure POJOs and the reintroduction of AssemblyFactory, the renaming of model objects (e.g. ComponentDefinition to Component) which will clash with the current runtime extension model, and the way model references are maintained. It's unclear how these changes will impact the rest of kernel or why they were necessary. I understand we need to have a model that more accurately reflects SCA 1.0. We've been doing this incrementally to date. Why can't they existing model be evolved? If someone wants to take the model design in a radically new direction, I'm fine with doing so but I don't think it should be done in trunk at this point. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Txt a lot? Get Messenger FREE on your mobile. https://livemessenger.mobile.uk.msn.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Hi, I would like a more elaborate explanation on what is meant in this context by interfaces, factory classes and separate implementations. As we are now, our model classes just encapsulate state, with hardly any behaviour. We quite nicely separate model from the runtime artifacts by moving behaviour to controller classes that translate the model to runtime artifacts. So, if the model classes are just state, why would we want to define interfaces for them and separate implementations, as there is no behaviour to be abstracted. Also, there have been a lot of work that has happened in trunk in the last month or so, in terms of seprarating the physical and logical aspects of the model. We need to take into consideration the impact of this approach on the physical model work, which is very much nearing completion now with the federated deployment story. At this stage by inclination would be to go -1, as I can't see a compelling reason for changing the current design. Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces Date: Tue, 20 Mar 2007 07:25:15 -0700 On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X] -1 keep things as they are My opinion. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - 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://: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]
Discovery update
Hi, I have temporarily replaced the JXTA discovery service with JMS (Jim, this is important you for tomorrow's demo). We have been using JXTA so far for discovery. We use PDP (Peer Discovery Protocol) for maintaining the federated runtime topology adn PRP (Peer Resolver Protocol) for sending arbitrary messages (in our case marshalled PCSs) between peers. PDP has been working fine, but I started running into issues with PRP, with both broadcast and directed delivery not reacing the recipient peers. I have posted the query to the JXTA user list. In the meanwhile, with a view on tomorrow's demo, I have added a new implementation using JMS. I have updated the demo distribution SCDLs to use JMS instead of JXTA. I am using ActiveMQ, you need to download the broker and run it centrally. Please use -dtuscany.adminPort to use a port other than 1099 for the profiles, as it is used by ActiveMQ. so for example master: java -Dtuscany.adminPort=2000 -jra start.server.jar master slave1: java -Dtuscany.adminPort=3000 -jra start.server.jar slave1 slave2: java -Dtuscany.adminPort=4000 -jra start.server.jar slave2 Otherwise, ActiveMQ out-of-the-box configuration should work. I am going to look at the JXTA issue post Wednesday. In the meanwhile, if anyone would like to help with the JXTA issue, please send a note, I will give the details. Thanks Meeraj _ 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]
Component group
Hi, I have been looking at the type parameter GROUP that has been added to PCD, which is not formalized anywhere down the inheritance tree. This means, the marshallers and unmarshallers won't be able to work against a static type that can be reflectively introspected at runtime, becuase of erasure. I was thinking if it is just an idenifier for the group to which a component belongs, can we just define it as a URI rather than a type parameter? Ta Meeraj _ Txt a lot? Get Messenger FREE on your mobile. https://livemessenger.mobile.uk.msn.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Federation - Update
Hi, I have got the JXTA discovery and Jetty service integrated into the demo distribution. I am able to start the master and two slaves from the installation image each communicating with JXTA and the Jetty service is also starting up from different ports. Next, I am going to llok at servlet mappings for the Jetty service. I was thinking about adding a web based interface for the master for submitting SCDL contributions as well as an interface for the slave 1, to start the demo invocation chain. Hash anyone got any thoughts on where these servlets should go in the source tree? Ta Meeraj _ 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]
Primodial services
Hi, Following on from the realier discussion thread, services that are included in runtime/services are considered as promodial services. What are the implications of a service being a primodial service, in terms of which cl loads the service? Any service implementation that has its service interface defined in SPI (based on what we have in SPI), host-api etc need to be loaded by the parent of the runtime cl, otherwise we will get a NCDFE. I had run into this problem with the JMX service earlier, now the same with the Jetty service. For the timebeing, I am fiddling the assembly descriptor, and the the server.start pom, to get the Jetty service loaded from the manifest classpath fo the jar with the main class. However, I think it may be worth looking at SPI to extract some of the primodial services out, so that we don't need to include the whole SPI in the manifest classpath. For the time being, is it ok to move jetty service from sca/services to sca/runtime/services? Ta Meeraj _ 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]
Re: Understanding Service Discovery
Thanks Jeremy. Mario, I think Jeremy has covered most of your points. If you need any more clarifications or have further queries, please feel free to ask. As Jeremy said, any help in these areas, ongoing and/or especially in the next two days :) will be highly appreciated. Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Understanding Service Discovery Date: Fri, 16 Mar 2007 18:53:14 -0700 On Mar 16, 2007, at 2:03 PM, Antollini, Mario wrote: Hello Meeraj, I have read several emails and I got to know that you are working on the Discovery service. I am very interested in this topic and I will like to get a better understanding about it. Great to have you involved. I have seen that you have also mentioned the Federated Deployer, Federated Assembly and Marshaling Framework throughout your posts. I think all these components are somewhat connected to the Service Discovery mechanism, aren't they? I will really appreciate if you can give me some details on how they all interact, if they do so at all. And, I will also like to understand the big picture here; i.e. what is the main goal you are trying to achieve with all that. In addition to that I will like to understand the role JXTA plays here and how it also interacts with these components. Their interaction is only indirect - they are more just using it as a transport. The discovery layer is responsible for determining which runtime processes are participating in the federation at any time. We're using JXTA for that as it is a standard peer-to-peer protocol and is available in many different languages, specifically both Java and C++ which are the two runtime implementations we have in Tuscany. We also want other protocols to work as well (for example, Bonjour or JINI) but want to get one working first. As well as tracking the available processes it also provides a mechanism for allowing those processes to exchange messages and we are using that to send management operations across the system fabric. Some of those management operations are associated with federated deployment. SCA's deployment model is based on the concept of changes to the domain assembly (e.g. include composite). Our implementation of that routes those changes to the controller nodes (at first one, next replicated, finally distributed) which take those logical changes and convert them to the physical ones that need to be made on participating runtimes. With the JXTA-based fabric, those are XML encoded JXTA messages; the marshalling framework is all about converting between those messages and the internal data structures (physical model) used by the Java runtime (C++ does not support this yet). The federated deployer is a runtime node service that receives demarshalled change set messages from the fabric and applies the changes they contain to the local runtime - basically creating, removing resources, components and wires. At the moment there's no interaction between JXTA and user components but if that was useful then we would just need to create a transport component implementation and wire attacher on the physical side and the binding support on the controller side. Finally, I would like to know which is its is (i.e.; what it is already able to do, what parts are missing, if you are willing to receive any help, you are planning to get it ready for M3, etc). We are in heavy development right now planning to show it working next week at TSSS - any help would be appreciated, both now and ongoing. All of this is happening in trunk for the 2.0-alpha2 release. As you saw I am asking way too many things, however I will be really glad if you can answer at least some of these questions. Hope I covered the key points. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving - check out the new Windows Live Mail. http://ideas.live.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Kernel Alpha2 Release
From: Jean-Sebastien Delfino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Kernel Alpha2 Release Date: Fri, 16 Mar 2007 12:35:56 -0700 [snip] Jeremy Boynes wrote: I like the timing - about a month, 6 weeks at the most is a good window between releases in early stages like we are. +1 from me I agree federation is the big delta between now and then - we should have by then * federated classloading (with multi-classloader support) * federated scope * the changes done for separating controller and physical runtime * contribution store and artifact redistribution It would be good to increase the spec coverage e.g. * support for casting between proxies and service references * support the new Conversation API * clean up around complex properties - specifically being able to use an external file to configure the server runtime * some more integration tests Yes it will be good to increase the spec coverage. Adding to your list, I'd also like to support things like: - Ability to override service/reference/property configuration at the componentType/component/composite level. - More coverage of the SCDL 1.0 syntax with things like qnames on composites, or composite resolution without requiring a scdlLocation attribute for example, I think we need to do some work to bring our SCDL model in sync with the latest revision of the spec. - Complex and multi-valued properties (I think Venkat has done some work in that area that could be included too) - Support for both WSDL and java interfaces and mapping between the two I can also help bring over some of the integration tests from the integration branch. Also, user support such as: * the composite plugin (i.e. pick an archive type) * JUnit4/TestNG support in the itest plugin * contribution tool (command line and plugin?) * a start on some form of console * some more samples * doco for all the above This looks good to me, I also want to have a very minimal runtime that will work without a Tuscany launcher. There is already support in the runtime for standlone server other than the laucher with some basic JMX management. The Guice idea is intriguing - support for their PM and annotations would be good. I also would like to take a look at using their EDSL for assembly - perhaps for hooking up the runtime as an alternative to SCDL. Yes, this is an interesting idea. I like the idea of trying to use an alternative to SCDL to hook up the runtime. Finally, I'd like to see if we could turn kernel/core into a few smaller modules for this release. -- Jeremy -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving - check out the new Windows Live Mail http://ideas.live.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Federation outstanding work
Hi, I have been trying to list the outstanding tasks to get federation done and have the demo working for TSS. These are the things I have in my list, 1. Contribution service on the controller 2. Assembly service on the controller 3. Generation of physical definitions from the model (may be part of assembly) 4. Marshaller/discovery integration on the controller side 5. Jetty service integration (we can use this to drive UI, for example starting point for the invocation chain on the slave, SCDL contribution on the master etc). 6. Bindings, to start with try Hessian 7. Maven distribution assembly We also need to update the slides to illustrate the multi-VM story in detail and the demo example. I can do 4, 5, 6 and 7. I can do _ 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]
RE: more changes for physical definitions
K, Jim that is done. Ta From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: more changes for physical definitions Date: Thu, 15 Mar 2007 00:05:39 -0700 I've go most of the Wire, InvocationChain, ProxyService, and InvocationChain infrastructure working using the new federated/ physical model (r518500). I had to add the following additional metadata: PhysicalWireSourceDefinition#conversational PhysicalOperationDefinition#conversationSequence Meeraj, when you get a chance, can you have the marshalling logic propagate this information? One of the next steps is we need to get the Controller and Allocator up and running. Once we have this in place, we should be able to have end-to-end federation in place and be able to get rid of a ton of excess code and deprecated methods from kernel. I suspect the code base will be substantially smaller (and simpler). Thanks, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Txt a lot? Get Messenger FREE on your mobile. https://livemessenger.mobile.uk.msn.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Kernel Alpha2 Release
+1 We should get the federation story implemented for the next kernel release. I think the development for federation is looking in good shape, and we should most probably have an end to end story, for the TSSS demo with couple of transports. In terms of extensions we also need to look at porting some of the existing extensions to the new model in addition to adding new ones like Hessian. Also, we need to to look at the management side of things. I started on it a while ago, it currently supports only read-only props on components. We need to start thinking about how to take it further forward. Some of the other things we can look at (maybe not in this release) is support for non-XML wiring, maybe start looking at things like Guice? Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 8:54 PM To: tuscany-dev@ws.apache.org Subject: Kernel Alpha2 Release I would like to start thinking about the next release of kernel. Based on the work being done around federation, it seems that multi- VM support is the key feature we should look to enable. This will allow us to demonstrate the high-value areas of SCA, particularly around distributed assembly. In addition, we should have a simplified extension model and classloader isolation in place. In terms of timing, I thought sometime around the first or second week in April would be ideal, as a few of us will be demonstrating these features at the ServerSide Symposium next week. I think we may also be able to get some bindings and extensions out around the same time or shortly after. I was thinking: Spring, Groovy, JPA, and Hessian to start. Thoughts? Jim - 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]
RE: handling of callbacks with physical wires
Sure, I will do that. Cuurently attach method is agnostic to whether it is forward or callback. If we have specific ones, would the signature change? Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 11:55 AM To: tuscany-dev@ws.apache.org Subject: handling of callbacks with physical wires Hi Meeraj, I've been working on getting the WireAttachers going for PhysicalComponentDefinitions. On PhysicalWireDefinition, I've added PhysicalWireSourcetDefinition and PhysicalWireTargetDefinition for callbacks, as they will be used to attach the callback side of a wire. Can you have the marshallers propagate this info as well? While we are on the subject, right now I just have the callbacks attached using the same WA.attach(..) methods as for forward invocations (.cf ConnectorImpl). I'm wondering if we want to add explicit methods for callback attachment as the builders may need to know this specific information to inject the right type of proxy. For example, JDKCallbackInvocationHandler. Thoughts? Jim - 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]
RE: Intermittent hangs in SmokeTestAssemblyContent
Ant, I don't get it either, I use dual core as well. The smoke test laucher uses a process drainer on a different thread that drains the System.out and System.err, for the spawned process. I can have a look when I get home in the evening (sorry I can't access the SVN server from work). Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 10:19 AM To: tuscany-dev@ws.apache.org Subject: Re: Intermittent hangs in SmokeTestAssemblyContent I don't but I'm on an Intel dual core so it may be a race condition. What type of CPU are you using? Jim On Mar 13, 2007, at 3:12 AM, ant elder wrote: > When building the standalone module in trunk I get intermittently get > an InterruptedException which causes the test to hang. I've not been > able to track down whats happening yet, does anyone else get this? > > Running > org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyC > ontent > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.031 sec > Running > org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher > Exception in thread "pool-1-thread-2" java.lang.InterruptedException >at > java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor( > AbstractQueuedSynchronizer.java:599) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer.release( > AbstractQueuedSynchronizer.java:1105) >at java.util.concurrent.locks.ReentrantLock.unlock( > ReentrantLock.java:431) >at java.util.concurrent.ThreadPoolExecutor.workerDone( > ThreadPoolExecutor.java:568) >at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:681) >at java.lang.Thread.run(Thread.java:595) - 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]
RE: Federated deployer, connector and simplifying the kernel
Jim, Some of this is already implemented in the federated deployer. Ta Meeraj >> -Original Message- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: 12 March 2007 20:02 >> To: tuscany-dev@ws.apache.org >> Subject: Federated deployer, connector and simplifying the kernel >> >> I'm starting to get stuck into the final pieces for having >> the Connector support federated deployment. I plan to >> implement the following algorithm in the FederatedDeployer >> to deploy a >> PhysicalChangeSet: >> >> 1. For each resource definition, build resource 2. For each >> PhysicalComponentDefinition build the component 3. Register >> built components with the ComponentManager 4. For each >> PhysicalWireDefinition, cakk connect >> - Build interceptors >> - Attach the wire to target Component >> - Attach the wire to source Component >> 5. Start the components >> >> If we do this, we can also get rid of ServiceBinding and >> ReferenceBinding from the runtime and instead just use >> Components to connect wires from and to physical transports. >> For example, a binding would be implemented as a Component >> instead of a ServiceBinding and ReferenceBinding. This will >> mean the only extension type we need to support is a >> Component. When the Connector attaches the Wire to the >> source and target Components, it will pass the >> PhysicalSource/ TargetDefinition part of the >> PhysicalWireDefinition. This will be extensible by binding >> type and will contain information necessary to expose or >> consume services over a binding. The PhysicalSource/ >> TargetDefinition will be created on the master and >> marshalled as part of the PhysicalWireDefinition. >> >> Jim >> >> - >> 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]
RE: Hessian binding, r516584
I can start on the RMI. Also, one of my colleagues at work at written an abstract framework for Hessian binding. It is mainly used for a Hessian Mule connector, however much of the code is pretty agnostic to Mule. Ta Meeraj >> -Original Message- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: 09 March 2007 22:29 >> To: tuscany-dev@ws.apache.org >> Subject: Hessian binding, r516584 >> >> FYI, >> >> I've added a project to start work on the Hessian binding. >> Getting RMI in or a WS binding would also be good if someone >> is interested in starting that. >> >> Jim >> >> >> - >> 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Federation and TSS Demo
That's great, Jim. I will try to finish of te marshallers by the weekend, and start on an extension container (maybe Groovy, if you don't have any other preference). We also need to look at bindings, I was thinking about what we have with RMI and maybe look at something else, maybe Hessian for example. I think Jeremy is looking at the contribution and assembly on the master from the previous emails on the topic. I am trying to aim for getting the slave working with a mocked master sending manually generated physical set for Java and groovy component types by this weekend, any help would be great. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 5:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Federation and TSS Demo On Mar 8, 2007, at 3:08 PM, Meeraj Kunnumpurath wrote: > Hi, > > I have been working on the framework to enable federated heterogeneous > deployment of a logical assembly across one or more physical runtimes. > I was wondering whether we can get an end-to-end story working that > demonstrates the assembly, contribution, artifact resolution and > heterogenoeus federation for the upcoming TSSS sessions at Vegas and > Barcelona. > +1 > What I am thinking is having three runtimes, one master and two > slaves, deploy a logical assembly with two components (one Java and > say the other Groovy), each allocated to different slave runtimes and > getting them to talk to each other through a couple of switchable > remote bindings. > > So far I have committed the following, > > 1. Abstractions for physical model which includes physical change set, > component and wire definitions, reference and service definitions, > operation and intereceptor definitions etc. > 2. Part of the Java physical model implementation 3. Framework > abstractions for marshalling and unmarshalling the physical model > objects 4. Java component definition marshaller implementation 5. New > builder framework that understands the physical component model 6. > Implementation for the Java physical component builder 7. Federated > deployer that integrates the marshallers and the builders with the > component manager and connector 8. Discovery service abstraction for > the communication fabric between the master and slaves 9. JXTA > implementation of the discovery service > > This is what I think we will have to do to get an end-to-end working, > > 1. Assembly and allocation on the master 2. Contribution to make > resources available on target runtimes 3. Finish the Java container on > the slave for the connector integration I can sign up to help here > 4. Artifact repository > 5. An extension container (may be something like Groovy) to > demonstrate heterogeonous federation across different component types. > 6. Couple of remote bindings (RMI, AXIS, XFire, Hessian etc) to > demonstrate switchable transport bindings Happy to help here as well. I've started work on a CXF binding, maybe we should think about that as well? > 7. And anything else I have missed > > It is definitely a lot of work for the next two weeks (our session at > Vegas is on the 21st). However, if we divide the work up and push > hard, I am quite positive we can achieve this. I think it will be an > excellent publicity boost for us to have a live application > demonstrating the SCA concepts and heterogeneous federation aspects of > Tuscany, than having just slideware. Good summary. I'll get stuck into the wiring tomorrow - hopefully we'll get this all rigged up with the contribution service running across multiple-VMs. Jim - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Federation and TSS Demo
Hi, I have been working on the framework to enable federated heterogeneous deployment of a logical assembly across one or more physical runtimes. I was wondering whether we can get an end-to-end story working that demonstrates the assembly, contribution, artifact resolution and heterogenoeus federation for the upcoming TSSS sessions at Vegas and Barcelona. What I am thinking is having three runtimes, one master and two slaves, deploy a logical assembly with two components (one Java and say the other Groovy), each allocated to different slave runtimes and getting them to talk to each other through a couple of switchable remote bindings. So far I have committed the following, 1. Abstractions for physical model which includes physical change set, component and wire definitions, reference and service definitions, operation and intereceptor definitions etc. 2. Part of the Java physical model implementation 3. Framework abstractions for marshalling and unmarshalling the physical model objects 4. Java component definition marshaller implementation 5. New builder framework that understands the physical component model 6. Implementation for the Java physical component builder 7. Federated deployer that integrates the marshallers and the builders with the component manager and connector 8. Discovery service abstraction for the communication fabric between the master and slaves 9. JXTA implementation of the discovery service This is what I think we will have to do to get an end-to-end working, 1. Assembly and allocation on the master 2. Contribution to make resources available on target runtimes 3. Finish the Java container on the slave for the connector integration 4. Artifact repository 5. An extension container (may be something like Groovy) to demonstrate heterogeonous federation across different component types. 6. Couple of remote bindings (RMI, AXIS, XFire, Hessian etc) to demonstrate switchable transport bindings 7. And anything else I have missed It is definitely a lot of work for the next two weeks (our session at Vegas is on the 21st). However, if we divide the work up and push hard, I am quite positive we can achieve this. I think it will be an excellent publicity boost for us to have a live application demonstrating the SCA concepts and heterogeneous federation aspects of Tuscany, than having just slideware. Ta Meeraj _ Exclusive Ed Byrne daily comedy clips on MSN Video http://specials.uk.msn.com/edbyrne/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting rid of AtomicComponent
A related question I had was, wouldn't most of the logic in JavaComponent etc for handling properties, introspection etc go into the generated instance factory bytecode? Meeraj >> -Original Message- >> From: Jeremy Boynes [mailto:[EMAIL PROTECTED] >> Sent: 08 March 2007 04:08 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Getting rid of AtomicComponent >> >> On Mar 7, 2007, at 6:42 PM, Jim Marino wrote: >> >> > When we convert over to the federated marhsallers, I think >> we can get >> > rid of AtomicComponent and just have Component. To do >> this, we would >> > need to move some of the lifecycle getters such as conversational >> > lifetime, etc. to Component. The other change we would >> need to do is >> > have InstanceWrapper handle init() and destroy >> > () callbacks. I think we can do this by having the wrapper >> generated >> > on the controller and serialized across. This would allow us to >> > eliminate reflection. Finally, JavaTargetInvoker (should be >> > renamed) would then deal with InstanceWrappers which it >> obtained from >> > the ScopeContainer, as opposed to AtomicComponent. >> > >> > What do people think? >> >> I started down that route a while ago refactoring >> InstanceWrapperImpl to be one specialization of >> InstanceWrapperBase that used the current mechanism of >> delegating back to the component (at least until we could >> clean that up). >> >> Have a look at PhysicalComponentTestCase for an example of >> what a generated alternative would look like. >> -- >> Jeremy >> >> >> - >> 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaComponent and PhysicalOperationDefinition changes, r515719
Jim, Is the MPL available in the registry. Or is it going to be the app CL looked up from the registry and the MPCL created from the looked up app CL and the system CL? Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: JavaComponent and PhysicalOperationDefinition changes, r515719 Date: Wed, 7 Mar 2007 12:10:11 -0800 Type below... On Mar 7, 2007, at 11:55 AM, Jim Marino wrote: I've been working on getting the Physical marshalling and build infrastructure integrated with the connector. In order to do this, I changed the way types are being tracked on PhysicalOperationDefinition. Instead of directly referencing the type's class, I changed it to track the fully qualified name as a String. When the TargetInvoker is created on JavaComponent, it will load the types using the classloader that loaded the implementation class and map to the appropriate method using getMethods(). Should be "getMethod(..)" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release 2.0-alpha of SCA Java kernel
+1 -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 7:12 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Release 2.0-alpha of SCA Java kernel On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote: > I have posted release candidates of the 2.0-alpha kernel release on my > home directory at people.apache.org and uploaded the artifacts to the > maven repo for: > SCA Parent POM 1.0-incubating > SCA Composite Plugin 1.0-incubating > SCA Kernel 2.0-alpha > SCA Runtime 2.0-alpha > SCA Core Samples 2.0-alpha > > Please review and then vote on whether we should release them. > > These are dependent on the vote for the sca-api's. Also, the JXTA > module which had a problematic dependency on Bouncy Castle is not > included in these releases. > > Thanks > -- +1 I've also added a 5-minute Jumpstart guide to getting the samples going here, linked off the Java SCA page: http://cwiki.apache.org/ confluence/display/TUSCANY/SCA+Jumpstart. I'll update it to include the download links when we have them ready to go. Jim - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sourcecheck failures in core
Sorry, I will do that this afternoon. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 1:37 AM To: tuscany-dev@ws.apache.org Subject: Sourcecheck failures in core I get a a bunch of sourcecheck failures in core (including PMD failures) - many of these relate to the marshallers and contribution service so Meeraj, Luciano, please could you clean them up. Thanks -- Jeremy - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0
+1 From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0 Date: Sun, 4 Mar 2007 09:41:44 -0800 +1 Jim On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote: Please vote to approve the release of the sca-api's for r1.0 of the specification. This is the API code that we recently reviewed but please vote again to confirm the release. [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/spec/sca-api-r1.0/1.0-incubating [src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating-src.tgz http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating-src.zip [rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating.rat [pom] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom [binary] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar [javadoc] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating- javadoc.jar Thanks -- Jeremy - 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] _ Exclusive Ed Byrne daily comedy clips on MSN Video http://specials.uk.msn.com/edbyrne/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving modules to contrib for this release
+1 From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Moving modules to contrib for this release Date: Thu, 1 Mar 2007 13:47:10 -0800 There are a few modules in the runtime that I don't think should be included in this release: * jxta due to the Bouncy Castle issue * osgi (not ready) * equinox (not ready) For now I am going to move them to a "contrib" directory under sca as this makes it easier to package "runtime" as a source distribution. -- 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]
RE: [JXTA user] Bouncycastle export notice
Thanks Mike. Gernimo has already ported the functionality you mentioned into geronimo-utils. Is there any chance you could look at using geronimo-utils instead of Bouncy Castle? Kind Regards Meeraj -Original Message- From: Mike [bondolo] Duigou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 11:21 PM To: [EMAIL PROTECTED] Subject: Re: [JXTA user] Bouncycastle export notice Export notices for distributing JXTA including Bouncy Castle have been filed by a number of organizations. Unfortunately each "exporter" must file their own notices. JXTA's use of Bouncy Castle is non-crytographic, specifically, BC is used only for generating PKCS#1 certificates from already generated key pairs and for formatting PKCS#10 certificate signing requests. Mike Meeraj Kunnumpurath wrote: > Hi, > > We are shipping the JXTA RI with the next release of Tuscany > (http://incubator.apache.org/tuscany/). Have you filed an export notice > for distributing Bouncycastle with the JXTA release? > > Thanks > Meeraj > > > * > > 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 > > This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Marshalling WireDefinitions for federated deployment
Hi, Just wanted to confirm a few things before I hack on .. 1. The unit of transmission between the master and slave is always going to be a PCS. 2. The PCS will contain collections of PWDs and PCDs 3. I am assuming we will use different namespaces for different types of PCDs (Java PCD for example) and have corersponding strong-typed sub-classes for PCD. 4. A PCD will have a collection of RD (Reference Definitions) and SD (Srevice Definiions), which will again use namespaces and concrete sub-types for supporting extensions. 5. WDs will contains a set of Ods (Operation Definitions), which will in turn contain a set of Ids (Interceptor Definitions). Ids will use namespaces and concrete sub-types for supporting extensions. 6. PhysicalChangeSet, PhysicalWireDefinition and OperationDefinition will be generic, whereas PhysicalComponentDefinition, ReferenceDefinition, ServiceDefinition and InterceptorDefinition will support extensions using namespaces and strong typed sub-classes for the extensions. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 1:30 AM To: tuscany-dev@ws.apache.org Subject: Re: Marshalling WireDefinitions for federated deployment For all of these: > On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote: > >> I'm little confused by this one. AIUI we have two configurations in >> the physical world: >> 1) two co-located components connected by a wire >>the PCS would contain two PCDs and a PWD for the connection >> >> 2) a component connected to the network via a binding >>the PCD would contain a PCD with binding configuration for the >> remote service/reference >> >> These could actually be mixed (a PCD may have one service/ reference >> bound to the network and another wired to a different co- located >> component). >> >> With that in mind, I don't see why we would have 'bindingType' on a >> PWD. In the optimal case, the controller would have reduced that >> to: >> >> >> In the non-optimal case, we would need to define interceptor chains >> for each of the source/callback operations, something like: >> >> >>* >> 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Marshalling WireDefinitions for federated deployment
Jim, As it is now, the marshaller framework only deals with marshalling and unmarshalling physical change sets (PhysicalChangeSet class in SPI). A physical change set is composed of zero or more physical component definitions (sub types of PhysicalComponentDefinition in SPI) and zero or more wide definitions (PhysicalWireDefinition in SPI). Physical wire definition currently has source and target URIs, binding type and zero or more interceptor definitions (PhysicalInterceptorDefinition in SPI). The interceptor definition currently has only the qname of the builder defined against them. The creation of the wires themselves from the wire definitions, I assume is done by the connector. However, as I gather from your note, the connector may need additional metadata on top of the source and target URIs, binding types and the interceptor builders to create the wires. This includes metadata for individual operations, extesibility elements for the wires themselves and extensibility elements for the interceptors. I have two questions on this, 1. Do we currently have classes that represent operations in our model? Operation in SPI looks to me as having more information than we need. Is it worth defining PhysicalOperationDefinition in the SPI physical model? 2. What kind of information is expected in the extsnsibility elements for wire and intereceptor definitions? Also what does extensibility information entail to? Is it enough to have some generic mechanism for attaching extension information within PhysicalWireDefinition and PhysicalInterceptorDefinition classes or is it worth having specific sub-types for different types of extensions. I should be up late tonight, if you could pls respond tonight I can continue hacking the marshaller framework. Also, it would be great to know your thoughts (and others as well) on marshalling physical component definitions. Currently, we have one sub-type for PCD, which is Java PCD that uses instance factory byte code. PCDs are mainly used by the new physical component builders. Thanks Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Marshalling WireDefinitions for federated deployment Date: Sun, 25 Feb 2007 12:32:30 -0800 We need to settle on a marshalling format for WireDefinitions as they are propagated from the Controller/Master to a slave where they will be constituted as Wires. Meeraj has been doing work on the Marshallers and I started to implement part of the ConnectorImpl.connect(PhysicalWireDefinition definition) method which will do the actual Wire creation and attach steps. The issue is we need additional metadata about each invocation chain in the wire to be created. We will also need to be able to pass extensibility elements as part of an InterceptorDefinition for InterceptorBuilders to use. I think we need the following operation metadata: - whether it is a forward or callback operation - operation name and param types, the return type, and exception types. We also need the an extensible metadata about the wire. For (at least) service contracts defined using Java, we need the FQN of the forward and callback services. We have a couple of options for serializing this across. Since we need to support operation overloading, it may be easiest to do something similar to the following: On the master, we also have the issue related to implementation- specific meta-data, e.g. data binding type information and @AllowsPassByReference. I don't think we should pollute ServiceContract or Operation with that metadata since they may be reused across implementations, which will wreak havoc with the contribution subsystem. For components, perhaps we need to add this information to the ComponentType (we could subclass where extensible elements only apply to specific implementation types)? For references and services, perhaps we add this information to BindingDefinition? Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spring extension release
Cool. Once I get the work I am doing on the slave side of federation out of way, I can port the groovy component type to 1.0 and also look at a JXTA binding based on the stuff we have been working on for discovery. Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Spring extension release Date: Fri, 23 Feb 2007 18:38:05 -0800 I've just checked in an update to the Spring extension that supports the latest kernel. As there are only a few odds and ends to clean up before I think it supports most of the Spring SCA 1.0 spec, I would like to start preparing for a release of the extension. I think we can do this following on the kernel alpha release. One thing that would help is if the contribution subsystem can be in place by then. Could people working on that give a brief description where that stands? It's not a pre-req since the standalone runtime will accommodate the extension, but it would be a nice-to-have capability. I think we should also consider releasing several other extensions (separately, but following on the alpha release) including potentially the JPA extension and the journal-based conversational store. What do people think? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: [JXTA user] Bouncycastle export notice
-Original Message- From: Mike [bondolo] Duigou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 11:21 PM To: [EMAIL PROTECTED] Subject: Re: [JXTA user] Bouncycastle export notice Export notices for distributing JXTA including Bouncy Castle have been filed by a number of organizations. Unfortunately each "exporter" must file their own notices. JXTA's use of Bouncy Castle is non-crytographic, specifically, BC is used only for generating PKCS#1 certificates from already generated key pairs and for formatting PKCS#10 certificate signing requests. Mike Meeraj Kunnumpurath wrote: > Hi, > > We are shipping the JXTA RI with the next release of Tuscany > (http://incubator.apache.org/tuscany/). Have you filed an export notice > for distributing Bouncycastle with the JXTA release? > > Thanks > Meeraj > > > * > > 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 > > This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: BouncyCastle IDEA patent
Hi, Apparently bouncycastle uses a patented algorithm in their distribution. Could someone from the dev team kindly let me know whether the RI uses any of the patented code? Thanks Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 8:39 PM To: tuscany-dev@ws.apache.org Cc: general@incubator.apache.org Subject: Re: BouncyCastle IDEA patent On Feb 21, 2007, at 12:05 PM, Matt Hogstrom wrote: > Regarding Bouncy Castle, IIRC they used to include the IDEA algorithm > in their distribution and provided a one-off for Geronimo to use to > bypass the patent issue. Not sure if that is an issue or not for > Tuscany but just a heads up. Thanks for the heads up. We'll check with the jxta folks and see if they use/expose the patented code. We should move this discussion to tuscany-dev and report back to the IPMC when its resolved. -- Jeremy - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Bouncycastle export notice
From: Meeraj Kunnumpurath Sent: Wednesday, February 21, 2007 12:29 PM To: '[EMAIL PROTECTED]' Subject: Bouncycastle export notice Hi, We are shipping the JXTA RI with the next release of Tuscany (http://incubator.apache.org/tuscany/). Have you filed an export notice for distributing Bouncycastle with the JXTA release? Thanks Meeraj * 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 This message has been checked for all email viruses by MessageLabs.
RE: JXTA module, bouncycastle and encryption export
Jeremy, Does that mean, we need to state on the page below that Tuscany uses Bouncycastle? Also (just out of interest), aren't the export restrictions applicable against certain crypto operations rather than a library? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 20, 2007 3:27 AM To: tuscany-dev@ws.apache.org Subject: JXTA module, bouncycastle and encryption export Going through the POMs for the release, I noticed that the JXTA module has a dependency on bouncycastle which I believe is subject to US export control. AIUI the ASF is allowed to export this under open source provisions but we need to document it; there's an ASF page on this here: http://www.apache.org/licenses/exports/ -- Jeremy - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java Kernel Release
Jim, I think, it is a good idea to a have a set of iterative alpha releases gearing towards a final 1.0 release. These are the features I see in the 1.0 final release .. 1. Full support for heterogeneous federation 2. Distributed assembly and deployment 3. Contribution mechanisms 4. Support for the 1.0 dpec changes 5. Standlone server and support for JMX-based management 6. The itest framework 7. And anything I have missed :) I think for the first alpha release, I would suggest we include spec 1.0 changes with ability to run with the laucher, itest and webapp runtimes. We need to discuss how we want to take the standalone server forward with JMX support. This may have some dependency on the federation stuff we have been working on. That means the standalone server with JMX and support for simple scenarios with federated deployment can go together in the second alpha release. We can plan for rest of the features in the next two releases or the ones after that. My view is to get the first alpha release out as early as we can with 1.0 programming model and support for laucher, webapp and itest runtimes. Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Java Kernel Release Date: Mon, 19 Feb 2007 09:45:38 -0800 There has been quite a bit of activity over the last month-and-a-half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release "1.0 alpha". I see this "alpha" as evolving into a series of iterative releases over the next month where we introduce some of the more "compelling" features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with "big" features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Upload 500 photos a month & blog with your Messenger buddies on Windows Live Spaces. Get yours now, FREE! http://specials.uk.msn.com/spaces/default.aspx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standalone build problem
Hi, Jeremy fixed it last night. Ta Meeraj -Original Message- From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: Monday, February 19, 2007 6:17 AM To: tuscany-dev@ws.apache.org Subject: Re: Standalone build problem Hi, I don't see this problem on Windows XP with IBM or SUN JDK 5.0. Thanks, Raymond - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Saturday, February 17, 2007 9:47 PM Subject: Re: Standalone build problem > It's happening to me. > > Jim > > On Feb 17, 2007, at 8:46 PM, Jeremy Boynes wrote: > >> Meeraj >> >> I probably broke the standalone runtime this afternoon as I still >> had it commented out of the build due to a compile problem: >> >> [INFO] Compilation failure >> /Users/jboynes/tuscany/java/sca/runtime/standalone/standalone-host/ >> src/main/java/org/apache/tuscany/runtime/standalone/host/ >> StandaloneRuntimeImpl.java:[105,47] createTargetInvoker >> (java.lang.String,org.apache.tuscany.spi.model.Operation) in >> org.apache.tuscany.spi.component.Invocable cannot be applied to >> (java.lang.String,org.apache.tuscany.spi.model.Operation> of ?>,) >> >> I made a local fix for that, but then ran into a problem with the >> smoketest hanging. >> >> Does this happen for you? If not, can you confirm that it runs and >> then I'll dig into platform-specific things. >> >> Thanks >> -- >> Jeremy >> >> >> - >> 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] > - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: wire post processing and implementation vs. contract metadata
Jim, I have been working on some of the stuff you have outlined below. Please see comments inline. Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: wire post processing and implementation vs. contract metadata Date: Fri, 16 Feb 2007 12:41:21 -0800 In doing the wiring refactor to support distribution, it struck me that we need to modify how and when wire post processing takes place, as well as how related metadata is tracked in the runtime. In terms of wire post processing in general, I think we need to move it to the master. Here is how I see that process working: - On the master, the logical assembly model is processed in multiple stages (I'm leaving details out in order to focus on wire post processing). When the model is processed, PhysicalComponentDefinitions and WireDefinitions will be created. A WireDefinition contains a list of InterceptorDefinitions that constitute a Wire. I propose we move the existing wire post processor implementations (DataBinding and AllowsPassByValue) to the phase where WireDefinitions are created since they deal with defining a wire and not post-processing it. They will deal with logical model objects and produce an InterceptorDefinition, something to the effect of: buildWireDefinition(WireDefinition definition, ModelObject source, ModelObject target) There may be a post-process step along the way but it will not be to add new InterceptorDefinitions. - WireDefinitions will be marshalled to a slave (potentially along with PhysicalComponentDefinitions) We already have the framework for marshalling and unmarshalling physical component definitions. I will extend this to support wire definitions. Basically, the unit of information that is passed from the master to slave is an instance of PhysicalChangeSet which contains a set of PCDs and WDs. - On the slave, the WireDefinitions will be reconstituted. They will then be passed to the Connector which will have one method: The marshaller framework also supports unmarshalling physical change sets. I am assuming the new builder framework will be used to build all the physical components corresponding to the PCDs and they are started and registered with the component manager, before the conenctor is called. Connector.connect(WireDefinition wd) throws WiringException - The connector will create a Wire (WireService will no longer exist and it's proxy creation functions will be moved to a ProxyService) - The connector will dispatch to InterceptorBuilders to add interceptors to the wire and then will attach the Wire to its source. The above process will mean that the existing WireProcessors will need to be moved to the master as part of a InterceptorDefinitionBuilder (we can change the name) and that PolicyBuilders will go away. We will also need to add InterceptorBuilders which run on the slave and create interceptors based on InterceptorDefinitions created by the InterceptorDefinitionBuilder. I am assuming some of this will be done within the assembly service that Jeremy was working on. In regards to the second issue, how wire-related metadata is tracked, I believe we may be conflating service contract vs. implementation metadata, and that we need to make a distinction. Specifically: - Databinding technology is not reflected in the service contract but in the implementation contract. For example, different component implementations may choose different databinding technologies. Currently, we pass this information as part of Operation, which is part of the ServiceContract. - AllowsPassByReference is set on AtomicComponentExtension but should be per-operation and not on the extension class. Again, it should be in an implementation contract. I propose we introduce metadata on the ComponentType for the purpose of tracking this component implementation-related metadata for operations offered by a component implementation. For composite services and references, we can add the metadata to BindingDefinition. For the latter, it would be the job of the Binding implementation (e.g. Axis, CXF, etc.) to add the metadata based on its capabilities or configuration. This will allow us to move databinding information out of SCDL. I'm in the process of making the Wiring changes to kernel now. After that, I'd like to tackle the problems I outlined above. Is anyone interested in working on this and/or have suggestions or alternatives in mind? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - To unsubsc
Re: Physical Component Defintion
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Physical Component Defintion
Date: Thu, 8 Feb 2007 20:13:10 -0800
On Feb 8, 2007, at 4:42 PM, Jeremy Boynes wrote:
On Feb 8, 2007, at 3:26 PM, Meeraj Kunnumpurath wrote:
Also, for the JavaAtomicComponent, I am planning to pass in the instance
factory into the component from the builder, so that it can be used
later when createInstance is called. I am also wondering with all these
changes, is it worth simplifying the PojoAtomicComponent and
JavaAtomicComponent , since most of the stuff in PojoConfiguration is
going to be encapsulated in the dynamically generated byte code for the
instance factory. Maybe, Jeremy has a view on this as well.
On the last note, it might be easier for now to add a new Component
implementation that was created by the PCB rather than trying to retrofit
PojoAtomicComponent.
I need something like this for the launched implementation type in the
client environment. I'll add a new implementation as a peer to PAC and we
can work out the builder for creating that.
Cool. Also, on the definition side I was thinking about creating classes
that encapsulate information on portable wire definitions etc. For example
..
public class PhycicalComponentDefinition extends ModelObject {
private URI componentId;
private Set inboundWires;
private Set outboundWires;
}
public class WireDefinition {
private URI wireUri;
private Set interceptors;
anything eles needed to create the wire on the slave
}
I will start on this before I go on holidays today. I am back Monday
morning. I can carry on the federated model when I come back, also, I can
give a hand with stabilizing the runtime.
Ta
Meeraj
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Physical Component Defintion
Thanks Jim. Based on what you said, this is how plan to have the on the wire XML representation of the Java Physical component definition. xmlns="http://tuscany.apache.org/xmlns/1.0-SNAPSHOT";> Base 64 Encoded byte code The wire and policy metadata will be defined in the base class PhysicalComponentDefinition, since they are applicable for all component types and not just the Java component type. This will get unmarshalled on the slave and passed into the builder. The builder would create the InboundWireImpl and OutboundWireImpl instances and add them to the component. Would we need anything more than the URI when the wire instances are created by the builder. If yes, would that be part of the physical component definition as well? Also, for the JavaAtomicComponent, I am planning to pass in the instance factory into the component from the builder, so that it can be used later when createInstance is called. I am also wondering with all these changes, is it worth simplifying the PojoAtomicComponent and JavaAtomicComponent , since most of the stuff in PojoConfiguration is going to be encapsulated in the dynamically generated byte code for the instance factory. Maybe, Jeremy has a view on this as well. Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Physical Component Defintion Date: Thu, 8 Feb 2007 14:43:40 -0800 On Feb 7, 2007, at 2:49 PM, Meeraj Kunnumpurath wrote: Jim, I have been looking at the work you have been doing with component manager and URIs and figuring out how this would fit in with federated deployment model I have been working on. Currently, the master creates the physical component defintion to get the component running on the slave. This gets marshalled and sent to the slave through the discovery service. On the slave this is picked up by the federated deployer to be umarshalled using the marshaller framework. The component gets built from the physical component definition by the new builder framework. The XML fragment for Java components looks as follows, http://tuscany.apache.org/ xmlns/1.0-SNAPSHOT"> Base 64 Encoded byte codeinstanceFactoryByteCode> I was thinking about wrapping the loaded instance factory into the JavaAtomicComponent in the javaPhysicalComponentBuilder and expect the wires to be resolved when createInstance is called on the component. Would you need any additional information on top of the instance factory to create the wires, interceptors, policies etc on the slave. Yes, I think we will eventually need information to constitute interceptor chains on the slave. I was thinking the policy builders would be run on the master and serialize wire information as part of the portable component definition. On the slave, a series of interceptor builders would be used to add interceptors to a wire as it is created by the WireService on a slave. This would effectively split our single-VM wire construction process across VMs and enable our federated design. All of the wire processing, normalization, and optimization would be done on the master. On the slave, the interceptor builders could be dispatched to based on a QName and would just be responsible for providing portable interceptors. We will also need to allow for extensible interceptor information but the serialization/deserialization process should work similar to the way Marshallers work. Wires could then be handed to the instance factory for use in injection. This give us a completely distributed wiring engine that is very fast :-) Also, where do you expect the autowire aspects resolved? I would expect autowire to be resolved as the model is processed on the master. This will allow us to remove autowire specializations from the slave. I plan to do this in steps. First, move autowire from CompositeComponent to ComponentManager. Then, move it from ComponentManager to the resolve step during loading. As we move it to loading, I also plan to implement it according to the recent 1.0 spec changes. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Physical Component Defintion
Jim, I have been looking at the work you have been doing with component manager and URIs and figuring out how this would fit in with federated deployment model I have been working on. Currently, the master creates the physical component defintion to get the component running on the slave. This gets marshalled and sent to the slave through the discovery service. On the slave this is picked up by the federated deployer to be umarshalled using the marshaller framework. The component gets built from the physical component definition by the new builder framework. The XML fragment for Java components looks as follows, xmlns="http://tuscany.apache.org/xmlns/1.0-SNAPSHOT";> Base 64 Encoded byte code I was thinking about wrapping the loaded instance factory into the JavaAtomicComponent in the javaPhysicalComponentBuilder and expect the wires to be resolved when createInstance is called on the component. Would you need any additional information on top of the instance factory to create the wires, interceptors, policies etc on the slave. Also, where do you expect the autowire aspects resolved? Many thanks Meeraj _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Jeremy,
I have been working on the marshallers for the physical model, so that they
can be transported from master to slave runtimes in a federated model. I
think what you suggested is closely related to what I am working on. If I
understand you right,
1. The assembly service on the master will create the physical model from
the logical model
2. The Java physical model could be as simple as having the runtime
generated byte code for the instance factory, with your second option
3. The marshaller framework will marshal the physical model and send it to
the target slave through the discovery service
4. On the slave, the federated deployer will unmarshall the physical
component model and use the builder to create the live component
5. This would require changes to the current builder framework and I can see
this should simplify the current builders quite a bit.
6. What I would suggest is to start a new builder framework in parallel and
deprecate the old one. The current deployer can continue to use the old
builder framework and the federted one will use the new one. Once we have
the builders for all the current component types, we can get rid of the old
ones.
7. The builder will use the instance factory to create the component and
wire all the properties and references.
8. I don't know whether this fits in with the component manager stuff Jim is
working on, I would assume the federated deployer will have to call the
component manager to register the component.
I have already started on the physical model. Since, this fits in closely
with the physical model and federated deployment, I can include the new
builder framwork in the work I am doing currently.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
Date: Sat, 3 Feb 2007 12:38:38 -0800
On Jan 29, 2007, at 6:50 PM, Jeremy Boynes wrote:
Instead, I think the data sent should define the configuration data
needed by the JavaComponentBuilder, something like:
http://tuscany.apache.org/xmlns/java/ 1.0"
uri="http://www.example.com/D1/Component1";
scope="Composite"
eagerInit='true'>
http://tuscany.apache.org/xmlns/
rmi/1.0" uri="http://m2:1099/D1/Component2"/>
fooValue
The XML is meant to be illustrative. It's also meant to be internal to
the runtime and not editable by users :-)
I was thinking about this and about the number of XML entities needed to
define the input for the builder. We don't need all the flexibility here
as the generator and the builder are very closely coupled (down to the
version level). In light of that, we can simplify the generator and
builder implementation simply by hard wiring this to bytecode. This has
other advantages as well in terms of runtime simplicity and performance,
it would also allow users willing to dig into the Tuscany SPIs to provide
their own factory.
The basic change here would be to define an InstanceFactory that returns a
fully initialized instance for the target component:
class InstanceFactory {
InstanceWrapper createInstance();
}
The implementation of this can be provided by the user (which allows
codegen at development time), generated during contribution, or generated
during logical->physical mapping. The resulting physical component
definition would be:
http://tuscany.apache.org/xmlns/java/ 1.0"
uri="http://www.example.com/D1/Component1";
scope="Composite"
eagerInit='true'>
class="sample.Component1Factory"/>
or
http://tuscany.apache.org/xmlns/java/ 1.0"
uri="http://www.example.com/D1/Component1";
scope="Composite"
eagerInit='true'>
$
{base64EncodedBytecodeForTheFactory}
depending on where the generation was done (i.e. is the factory already in
the MyApp classloader or not).
All property and physical binding configuration can be handled by the
implementation of this factory. The builder though would still need to be
involved to ensure all the local wires in and out of the component were
connected. It could pass the outbound reference factories to the
InstanceFactory implementation during construction.
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r503232 - in /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/model/physical: ./ PhysicalComponentDefinition.java
Thanks, I was thinking about adding that in :)
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: svn commit: r503232 - in
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/model/physical:
./ PhysicalComponentDefinition.java
Date: Sat, 3 Feb 2007 11:49:42 -0800
On Feb 3, 2007, at 8:39 AM, [EMAIL PROTECTED] wrote:
Author: meerajk
Date: Sat Feb 3 08:39:15 2007
New Revision: 503232
URL: http://svn.apache.org/viewvc?view=rev&rev=503232
Log:
Physical component model.
Added:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/model/physical/
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/model/physical/PhysicalComponentDefinition.java (with
props)
In light of Jim's URI change, we probably need that in the physical model
as well:
Index: spi/src/main/java/org/apache/tuscany/spi/model/physical/
PhysicalComponentDefinition.java
===
--- spi/src/main/java/org/apache/tuscany/spi/model/physical/
PhysicalComponentDefinition.java(revision 503292)
+++ spi/src/main/java/org/apache/tuscany/spi/model/physical/
PhysicalComponentDefinition.java(working copy)
@@ -18,6 +18,8 @@
*/
package org.apache.tuscany.spi.model.physical;
+import java.net.URI;
+
/**
* Represents a physical component model.
*
@@ -25,5 +27,21 @@
*
*/
public abstract class PhysicalComponentDefinition {
+private URI componentId;
+/**
+ * Returns the absolute id for the phyiscal component.
+ * @return the absolute id for the phyiscal component
+ */
+public URI getComponentId() {
+return componentId;
+}
+
+/**
+ * Sets the absolute id for the phyiscal component.
+ * @param componentId the absolute id for the phyiscal component
+ */
+public void setComponentId(URI componentId) {
+this.componentId = componentId;
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving modules around in trunk
Ant, Discovery is used for the federated assembly stuff. The abstractions are defined in SPI. The JXTA and bonjour implementations used to be under services, which I moved to runtime/services, in line with moving the core services like maven from services to runtime/services. They don't get loaded in the way other extensions like AXIS get loaded on demand. Rather, the discovery service is eagerly auto-wired into other core services like assembly service and federated deployer. Thanks Meeraj -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Friday, February 02, 2007 11:41 AM To: tuscany-dev@ws.apache.org Subject: Re: Moving modules around in trunk I haven't been paying really close attention to whats been going on with the discovery stuff so could you explain that a bit more? I'm not suggesting keeping it in services is wrong I'd just like to understand why this is more a core thing than say a WS extension? I guess i'd assumed the discovery SPIs and any helpers etc would be in the kernel and actual impls like JXTA would be an extension. ...ant On 2/2/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > > Hi, > > The JPA stuff vcan definitely move to extensions, I can move it > tomorrow. The JXTA stuff is core runtime service, though, the actual > abstraction is in SPI. I am not sure whether it should stay in > runtime/services or move to extensions. My first inkling would be to > leave it in runtime/services. > > Ta > Meeraj > > -Original Message- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: Friday, February 02, 2007 9:06 AM > To: tuscany-dev@ws.apache.org > Subject: Re: Moving modules around in trunk > > > On Feb 2, 2007, at 12:49 AM, ant elder wrote: > > > OK I'm going to start doing all these things, I'm away for a week > > after today so it wont all happen immediately...feel free to help > > while I'm out :) > > > > Another thing I wondered about is if some of the things like JPA and > > JXTA should also be moved out into the extensions folder? > I think the JPA stuff should be moved out. Not sure about JXTA - > Meeraj what do you think? If you don't have time to move JPA I can > deal with it in a few days after I finish my core refactors. > > Jim > > > > > > > > > - > 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 > > > This message has been checked for all email viruses by MessageLabs. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving modules around in trunk
Hi, The JPA stuff vcan definitely move to extensions, I can move it tomorrow. The JXTA stuff is core runtime service, though, the actual abstraction is in SPI. I am not sure whether it should stay in runtime/services or move to extensions. My first inkling would be to leave it in runtime/services. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Friday, February 02, 2007 9:06 AM To: tuscany-dev@ws.apache.org Subject: Re: Moving modules around in trunk On Feb 2, 2007, at 12:49 AM, ant elder wrote: > OK I'm going to start doing all these things, I'm away for a week > after today so it wont all happen immediately...feel free to help > while I'm out :) > > Another thing I wondered about is if some of the things like JPA and > JXTA should also be moved out into the extensions folder? I think the JPA stuff should be moved out. Not sure about JXTA - Meeraj what do you think? If you don't have time to move JPA I can deal with it in a few days after I finish my core refactors. Jim - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Federated assembly -> Work so far
Hi, I have been working on the stuff around federated assembly and enabling distributed SCA domains. Here is a quick summary of what has been done so far, Work in progress * Discovery Service * Provides the low-level communication abstraction for enabling runtimes participating in the domain to exchange information * The abstraction supports directed message delivery to a given runtime, asynchronous message reception and broadcast to all runtimes participating in the domain * To start with we are following a model, where one runtime in the domain assumes the master role and is responsible for managing the logical assembly * This runtime creates the physical artifacts and trensport them to the target slave runtimes * The discovery abstraction is defined in SPI * There are two implementations in runtime/services - JXTA and Bonjour * JXTA implementaion is getting pretty much there, it mainly uses the JXTA Peer Discovery protocol (PDP) and Peer Resolver Protocol (PRP) * Marshalling Framework * This is similar to our loader framework, however supports bi-directional marshalling and unmarshalling of physical model objects * This framework is used by the assembly service to serialize and transport physical model information to slave runtimes using the discovery services * On the receiving end the serialized information is unmarshalled by the federated deployer for being applied to the slave runtime * The abstraction is defined in SPI * I am working on an implementation in core * The framework supports versioning of physicla model objects if the participating runtimes are at different versions * Federated Deployer * This is similar to the local deployer, however registers itself with the discovery service for receiving physical model updates * The federated deployer doesn't use the loader framework * The federated deployer accepts serialized physical model information in XML, rather than raw SCDL as with local deployer * It uses the current builder framework to build, prepare and start the components Work outstanding * Define the physical model in Java * Define the corresponding XML infoset Some of this is related to the contribution and assembly service which Jeremy is working on. I assume the assembly service will be the main consumer to the discovery service and marshalling framework on the master side. On the slave side, the federated deployer will be registered with the discovery service for receiving asynchronous model updates from the master. Ta Meeraj * 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 This message has been checked for all email viruses by MessageLabs.
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Hi, For the sake of similicity can we assume that allocation of components to runtimes are explicitly specified in the SCDL, when it is made available to the assembly service? Then the assembly service can matreilize the physical component model for individual target slave runtimes, serialize it to XML and send it through the discovery service. On the receiving end, the discovery service will route the message to an approriate listener based on the QName of the message. I have already added a federated deployer as a listener. The deployer will use the current loader framework to load the component definition from the XML and pass it to the builder registry to build and deploy the component. Based on this, I would assume we need to build the following components, 1. Define the physical model in Java. 2. Map the physical model to XML infoset sent from the master to the slave. 3. Extend the loader framework to support serialization of physical model to XML. Kind of mirror image of what it does now for deserialization. 4. Write new loaders capable of interpreting the XML snippets representing the physical model and materialize the component definition on the slave. I would assume once the component definitions are built we can use the existing buildres. Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Federated Deployment (was SCDL Location in Composite Implementation) Date: Tue, 30 Jan 2007 12:13:28 -0800 On Jan 30, 2007, at 11:40 AM, Raymond Feng wrote: Yes. The JAR is a packaging format understood by a ContributionService in the domain. Based on the media type (application/zip or application/x.tuscany.jar) this is processed by the appropriate ContributionProcessor implementation and the definitions it contained registered with the domain. The content type works well with archives that can be streamed. How do we handle the case that the contribution is from a directory on the file system (for example, an SCA application installed at folder /tuscany/applications/MyApp)? You can stream off the filesystem too aka FileInputStream or the InputStream from a file: URL. Many platforms provide a way to get media type from a file (e.g. Windows has a registry based on extension). On some, that is supported automatically for file: URLs, on others it isn't. The ContributionService API allows you to pass in a content type if there is some way to figure it out, if not there's always application/x- octet-stream and we can have a processor try and figure out the content type from the stream itself. Then the SCA domain will be: Composite0: include Composite1: Component1 Component2 The resulting component hierarchy will be: http://www.example.com/D1 http://www.example.com/D1/Component1 http://www.example.com/D1/Component2 So the composite1 is not in hierarchy due to "include". Does this scheme require that all components in the top level composites have unique names? Yes - it is a requirement from the spec that they do. This is basically the expanded component definition needed by the builder. The only reference is to the classLoader and I think that would be created by another part of the message. I'm not very sure why ClassLoader is in the message. Shouldn't the target runtime decide which ClassLoader when the component is activated? The message would contain information on which classloader to use. The runtime may need to reuse an existing one or create a new one (e.g. for multiple components with a local connection). It will need to be told by the master what to do related to class sharing. The XPath evaluation for the property value and the decision to use RMI for the transport would be done by the implementation behind the AssemblyService API based on information provided by the logical model, by the runtimes (including what extensions they can support), administration policies and user-supplied metadata. The generation of this configuration would be done by an processor on a node with access to the assembly model (for logical context), the resolved artifact information, and a Java runtime. This may not be the actual node where the component ends up running. It seems to me that we need to pass the fully-configured component definition, i.e., all the model objects referenced by the component. That's required by the JavaComponentBuilder to create runtime metadata to start the component. ... ABC Some of data can be passed by value (for example, the XML value for a property and the ServiceContract), but some of them will need to be re-resolved in the target runtime (Java class name --> Java class). Sounds to me like we're saying the same thing - the message needs to contain the fully-configured co
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Jeremy,
Pls see questions below.
Thanks
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
Date: Mon, 29 Jan 2007 18:50:36 -0800
On Jan 29, 2007, at 5:20 PM, Raymond Feng wrote:
Hi,
I think it's better to discuss the design in the context of a simple
scenario so that we can see the whole picture. I'm giving a try to
capture what I understand. Please forgive me if there's anything dumb and
help me complete/fix it.
I think this is a good idea - some expansion inline.
1) For the purpose of illustration, let's assume that we have a SCA
domain (D1) with two active runtimes: R1 and R2. R1 is running on machine
M1 and R2 on machine M2.
There is a logic composite (Composite0) representing the SCA domain D1.
The domain has a name which I believe is a hierarchical URI. Let's use
http://www.example.com/D1
There is a conceptual component at the root of the domain implemented by
Composite0. The conceptual URI of this component can be that of the
domain: http://www.example.com/D1
2) An SCA application is developed and packaged as a jar file. The jar
file contains a SCDL to represent a compoiste Composite1 with two
components: Component1 and Component2. The SCDL file references a global
element or type in a.xsd by QName for property definitions.
MyApp.jar:
sample.Component1Impl
sample.Component2Impl
META-INF/sca/default.scdl
xsd/a.xsd
The jar file is contributed to the SCA domain. Some services will be
responsible for scanning/loading artifacts in the contribution. Is
"ContributionProcessor" or "ContributionService" for this purpose?
Yes. The JAR is a packaging format understood by a ContributionService in
the domain. Based on the media type (application/zip or
application/x.tuscany.jar) this is processed by the appropriate
ContributionProcessor implementation and the definitions it contained
registered with the domain.
Is artifact resolving going to happen during this phase?
I think it can. We can introspect the artifact once during contribution
and save the results in a platform neutral format for consumption by any
runtime. This is an optimization - we may need to invalidate that cache on
lease expiration or if the artifact is modified.
3) A service (AssemblyService?) will add Composite1 to the logical
composite representing the SCA domain.
The implementation behind AssemblyService anyway. Logically this is
applyChange(add of Composite1).
Then the SCA domain will be:
Composite0:
include Composite1:
Component1
Component2
The resulting component hierarchy will be:
http://www.example.com/D1
http://www.example.com/D1/Component1
http://www.example.com/D1/Component2
4) We decide to deploy Composite1 distributedly: Compnent1 to runtime R1
and Component2 to runtime R2.
R1: Composite1.Component1
R2: Composite1.Component2
So a subset of Composite1 (physical model?) will be sent to R1 and the
other to R2 using some sort of XML messages. Component1 is activated at
R1 and Component2 is activated at R2. They are now running.
I don't think that what is sent is a strict subset of the SCDL supplied by
the user. For example, if we just sent:
${cp1}/foo
then there is insufficient information there to define what transport is
used to connect Component1 to Component2 over r1 and what the actual value
is for p1.
Instead, I think the data sent should define the configuration data needed
by the JavaComponentBuilder, something like:
http://tuscany.apache.org/xmlns/java/ 1.0"
uri="http://www.example.com/D1/Component1";
scope="Composite"
eagerInit='true'>
http://tuscany.apache.org/xmlns/
rmi/1.0" uri="http://m2:1099/D1/Component2"/>
fooValue
The XML is meant to be illustrative. It's also meant to be internal to the
runtime and not editable by users :-)
This is basically the expanded component definition needed by the builder.
The only reference is to the classLoader and I think that would be created
by another part of the message.
The XPath evaluation for the property value and the decision to use RMI
for the transport would be done by the implementation behind the
AssemblyService API based on information provided by the logical model, by
the runtimes (including what extensions they can support), administration
policies and user-supplied metadata.
The generation of this configuration would be done by an
processor on a node with access to the assembly
model (for logical context), the resolved artifact information, and a Java
runtime. This may not be the actual node where the component ends up
running.
How do you see this xml being consumed
Re: Federated Deployment (was SCDL Location in Composite Implementation)
From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Federated Deployment (was SCDL Location in Composite Implementation) Date: Mon, 29 Jan 2007 16:17:21 -0800 On Jan 29, 2007, at 3:47 PM, Meeraj Kunnumpurath wrote: Based on the third option, I think we need to come up with the following, 1. Classes that represent the physical model that represents the artifacts sent to target slave runtimes for deployment. 2. A component that is responsible on the master runtime responsible for assembling the physical model from a logical assembly and interacting with the discovery service to transport them to remote slave runtimes. 3. An inter-operable serialiation protocol that is used to represent the physical model on the wire. 4. A framework for handling the serialization/de-serialization between physical model objects and their wire-level representation. 5. A component that is responsible on the slave runtime to deploy the deserialized model objects. Agreed. For 3, I think we should use XML for that as there is no guarantee that the source and target runtimes will be implemented using the same technology. The content would be the XML types defined in by 1) and that must be extensible and versioned. Serialization between wire- format messages (XML) and in-memory mode should be selectable by each runtime implementation - the Java kernel uses custom loaders for this, I believe the C++/Native kernel uses SDO. I think, regardless of the serialization mechanism that used to represent the wire-level representation of the transported physical model, the collaborating runtimes will have to agree on the same discovery protocol. For example, if a Java runtime chooses to use JXTA as the protocol for distributing physical model artifacts, the target C++ runtime will have to agree on the same protocol. For 5), I think the component/message processor would be fairly lightweight - most of the work should be in the builders (with which builder to use selected by QName of the config object). Yeah, a message listener will be selected based on the QName of the payload and the builder will have injected depenedncies of whatever components that are required to perform any downstream processing like reconstituting the physical model in memory, calling the builder, deployer etc. One key question is how much of this do we need to build from scratch and how much we can leverage on the existing assets. Can the physical model leverage on the existing model classes? I used to think so but recently I've been thinking we should separate logical from physical. The logical model objects would represent SCDL concepts, the physical ones would be lower level targeted as input for the builders. For example, to build a Java component, the builder for it should be passed a definition for the implementation, injection sites, value factories, inbound and outbound wires with interceptor chains and binding definitions. Time permitting, I'll try and post a snippet for this tonight. In addition to the physical model, there will also be control commands like start/stop component etc. I think it will be useful to have a definitive list of infoset exchanged between the master and slave runtimes. Both in XML and the equivalent Java model classes. Also can the current deployer/loader/builder framework be used for deserializing the physical model objects and applying the changeset on the target runtime? Framework wise, yes I think so although from above I think we need more information in the handoff to the builder. The current builder abstraction accepts the parent component, component definition and deployment context to build the component. Would any additional information you envisage in building a component in the federated model be included in the component definition? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Federated Deployment (was SCDL Location in Composite Implementation)
Based on the third option, I think we need to come up with the following, 1. Classes that represent the physical model that represents the artifacts sent to target slave runtimes for deployment. 2. A component that is responsible on the master runtime responsible for assembling the physical model from a logical assembly and interacting with the discovery service to transport them to remote slave runtimes. 3. An inter-operable serialiation protocol that is used to represent the physical model on the wire. 4. A framework for handling the serialization/de-serialization between physical model objects and their wire-level representation. 5. A component that is responsible on the slave runtime to deploy the deserialized model objects. One key question is how much of this do we need to build from scratch and how much we can leverage on the existing assets. Can the physical model leverage on the existing model classes? Also can the current deployer/loader/builder framework be used for deserializing the physical model objects and applying the changeset on the target runtime? Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: SCDL Location in Composite Implementation Date: Mon, 29 Jan 2007 15:24:56 -0800 The normative reference here is the name of the composite being used - scdlLocation and scdlResource are things we've added to allow that name to be resolved in a Java runtime as, to date, there is no spec- defined mechanism for doing that. This is related to the artifact resolution thread Raymond and I are having. In the federated case, I don't think that we can use the user- supplied SCDL to define what needs to be deployed. This is because the logical model supplied by the user can be mapped to different physical environments - for example, a single composite could be decomposed to multiple physical runtimes resulting in components from it being physically deployed separately. If that happens, what is physically running is not the user-supplied model but some subset of it. I think we can handle this in a couple of ways. One is to synthesize composites to represent the physical deployments; this has the advantage of reusing the existing model but the disadvantage that it conflates the logical and physical models. Another is to add extensions to the logical model to reflect physical characteristics and then have each runtime just deploy the bits that are relevant to it; again this conflates the logical and physical models. A third is to separate logical and physical models entirely, passing to the runtimes just the information needed to build the runtime objects (basically a physical model); I think this is our better option as it separates the logical and physical concerns which is in line with our existing separation between config model and runtime objects. Coming back to the original subject, this would mean that things like scdlLocation or any other artifact resolution metadata would only apply where the logical model was being processed. When it comes to the physical representation, these would have already been resolved and converted to their physical representation which would be passed to the target runtime /by-value./ All references would have been converted and the component builders on the target runtime would have a complete definition to work from. I think we have to do this. If we pass references down to the targets then we run the risk that different targets will process the references differently leading to inconsistent deployment across the federation. -- Jeremy On Jan 29, 2007, at 2:30 PM, Meeraj Kunnumpurath wrote: Hi, Currently SCDL location is modelled as a URL in CompositeImplementation class. This works ok as long as the SCDL is loaded from a URL. However, with the stuff I am working on with federated assembly, an SCDL may be transported into the runtime through the discovery mechanism and thw SCDL contents may be materialized fully in memory. I was wondering whether we need a higher-level abstraction than URL or stick with URL and write custom protocol handlers were the source for the URL is not a standard one (an in-memory byte array for example). To give a bit of context, I have been thinking of using the existing deployer/loader/builder framwork that is used for local deployment in the federated scenario as well. Thanks Meeraj _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands
SCDL Location in Composite Implementation
Hi, Currently SCDL location is modelled as a URL in CompositeImplementation class. This works ok as long as the SCDL is loaded from a URL. However, with the stuff I am working on with federated assembly, an SCDL may be transported into the runtime through the discovery mechanism and thw SCDL contents may be materialized fully in memory. I was wondering whether we need a higher-level abstraction than URL or stick with URL and write custom protocol handlers were the source for the URL is not a standard one (an in-memory byte array for example). To give a bit of context, I have been thinking of using the existing deployer/loader/builder framwork that is used for local deployment in the federated scenario as well. Thanks Meeraj _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r500647 - in /incubator/tuscany/java: pom/parent/pom.xml sca/services/discovery/
Raymond, That was by mistake, I have reverted back to 469686. Sorry for the trouble. Meeraj From: "Raymond Feng" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: Subject: Re: svn commit: r500647 - in /incubator/tuscany/java: pom/parent/pom.xml sca/services/discovery/ Date: Sat, 27 Jan 2007 20:23:44 -0800 Hi, Why do we set "snapshots/enabled" to false for Apache SNAPSHOT repo @ http://people.apache.org/repo/m2-snapshot-repository? Thanks, Raymond - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Saturday, January 27, 2007 2:37 PM Subject: svn commit: r500647 - in /incubator/tuscany/java: pom/parent/pom.xml sca/services/discovery/ Author: meerajk Date: Sat Jan 27 14:37:54 2007 New Revision: 500647 URL: http://svn.apache.org/viewvc?view=rev&rev=500647 Log: Deleted services/discovery Removed: incubator/tuscany/java/sca/services/discovery/ Modified: incubator/tuscany/java/pom/parent/pom.xml Modified: incubator/tuscany/java/pom/parent/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/pom/parent/pom.xml?view=diff&rev=500647&r1=500646&r2=500647 == --- incubator/tuscany/java/pom/parent/pom.xml (original) +++ incubator/tuscany/java/pom/parent/pom.xml Sat Jan 27 14:37:54 2007 @@ -70,7 +70,7 @@ Apache SNAPSHOT Repository http://people.apache.org/repo/m2-snapshot-repository -true +false @@ -93,6 +93,17 @@ true + + + +repo1.maven +Repo1 Maven +http://repo1.maven.org/maven2/ + +true + + + @@ -145,6 +156,7 @@ org.apache.maven.plugins maven-checkstyle-plugin +2.1 org.apache.maven.plugins - 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] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r498349 - in /incubator/tuscany/java/sca/services/discovery: installjxta/ installjxta/LICENSE.txt installjxta/NOTICE.txt installjxta/build.xml installjxta/pom.xml jxta/pom.xml
Jeremy, I have asked whether they plan to mavenize the 2.4 release. It doesn't look like their immediate priority. I plan to volunteer to do that for them if they agree. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, January 22, 2007 2:46 PM To: tuscany-dev@ws.apache.org Subject: Re: svn commit: r498349 - in /incubator/tuscany/java/sca/services/discovery: installjxta/ installjxta/LICENSE.txt installjxta/NOTICE.txt installjxta/build.xml installjxta/pom.xml jxta/pom.xml pom.xml Are you working with the JXTA/Maven people to get this version added to the repo? -- Jeremy On Jan 21, 2007, at 7:08 AM, [EMAIL PROTECTED] wrote: > Author: meerajk > Date: Sun Jan 21 07:08:51 2007 > New Revision: 498349 > > URL: http://svn.apache.org/viewvc?view=rev&rev=498349 > Log: > Added module to install jxta 2.4.1 - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RuntimeInfo
Hi, I have been looking at adding runtime id to RuntimeInfo. I think there may be some scope for refactoring the current classes and interfaces used for realising runtime info. The core abstraction is the RuntimeInfo interface in host-api with a specialized interface StandaloneRuntimeInfo in standalone-host-api. The implementations include Standalone, Launcher and Web runtime infos in addition to some of the mock ones used in testing. Some of the methods defined in the RuntimeInfo interface is not supported by the launcher and webapp runtime infos. Also, some of the operations in the core abstractions like getInstallDirectory, getBaseUrl, getApplicationDirectory can be refined further, I guess. I think there are two broad categories of runtime info, client runtime infos and server runtime infos. The server ones include any runtime that stays up running and participate in a standalone or federated logical assembly. These will include webapp, standalone tuscany server etc. Properties like domain, runtime id etc are relavant to them. However, for client runtimes like launcher that runs a specific application and exits, some of these properties may not be relavant. However, there may be common abstractions like profiles etc that are relavant for both client and server runtimes. I am planning to do some work around this area in conjunction with the stuff I am doing on federation and discovery. It would be great to know if others have any thoughts on refining the runtime info abstractions. Many thanks Meeraj * 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 This message has been checked for all email viruses by MessageLabs.
Pulling up profileName
Hi, Can I pull up profile name from StandaloneTuntimeInfo to RuntimeInfo? Iwas thinking about using profile name as the peer name for runtime for the distributed assembly I am working on. I would assume, regardless of the host type, an SCA runtime should be able to participate in a federated SCA domain? Ta Meeraj * 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Simon Laws for Tuscany committer
+1 -Original Message- From: Rick [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 17, 2007 10:59 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Simon Laws for Tuscany committer +1 ant elder wrote: > I'd like to nominate Simon Laws to become a Tuscany committer. Simon > has has done lots of different things for Tuscany - patches, interop > work, the website, release testing, participating in discussions etc, > and he's been contributing to Tuscany since April last year! > > Here's my +1. > > ...ant > - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: non mvn artifacts
I have done that as well, in fact, I am thinkining about volunteering to do the mavenisation. Meeraj From: "Raymond Feng" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: Subject: Re: non mvn artifacts Date: Mon, 15 Jan 2007 11:01:26 -0800 Why don't we ask the JXTA folks to publish the latest versions into maven2 repo if possible :-)? Thanks, Raymond - Original Message - From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]> To: Sent: Monday, January 15, 2007 10:45 AM Subject: non mvn artifacts Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - 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] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: non mvn artifacts
Thanks Bert, I will take a look. From: "Bert Lamb" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: non mvn artifacts Date: Mon, 15 Jan 2007 13:50:21 -0500 I do something similar to this in the helloworldjsonrpc sample, the sample uses the dojo toolkit and downloads it and installs it into the local maven repo if it isn't there already. Have a look at samples/sca/helloworldjsonrpc/pom.xml and build.xml to see how it works. -Bert On 1/15/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - 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] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
non mvn artifacts
Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r495803 - in /incubator/tuscany/java/sca: ./ runtime/standalone/server.start/src/main/java/org/apache/tuscany/standalone/server/ runtime/standalone/server.start/src/main/java/org/ap
Hi Raymond, Sorry, that was committed by accident. I was using it only locally. I will back the change out. BTW it is a repo I use at work, which I have found quite reliable and fast. Ta Meeraj >> -Original Message- >> From: Raymond Feng [mailto:[EMAIL PROTECTED] >> Sent: 14 January 2007 00:56 >> To: tuscany-dev@ws.apache.org >> Subject: Re: svn commit: r495803 - in >> /incubator/tuscany/java/sca: ./ >> runtime/standalone/server.start/src/main/java/org/apache/tusc >> any/standalone/server/ >> runtime/standalone/server.start/src/main/java/org/apache/tusc >> any/standalone/server/management/jmx/ services/ma >> >> Hi, Meeraj. >> >> Would you please give us some background on adding >> http://maven.sateh.com/maven2 as a maven repo? >> >> Thanks, >> Raymond >> >> - Original Message - >> From: <[EMAIL PROTECTED]> >> To: >> Sent: Friday, January 12, 2007 4:43 PM >> Subject: svn commit: r495803 - in >> /incubator/tuscany/java/sca: ./ >> runtime/standalone/server.start/src/main/java/org/apache/tusc >> any/standalone/server/ >> runtime/standalone/server.start/src/main/java/org/apache/tusc >> any/standalone/server/management/jmx/ >> services/man... >> >> >> > Author: meerajk >> > Date: Fri Jan 12 16:43:26 2007 >> > New Revision: 495803 >> > >> > URL: http://svn.apache.org/viewvc?view=rev&rev=495803 >> > Log: >> > Moved JMX agent from standalone server to management.jmx >> > >> > Added: >> > >> > >> incubator/tuscany/java/sca/services/management/jmx/src/main/j >> ava/org/a >> > pache/tuscany/service/management/jmx/agent/ >> > >> > >> incubator/tuscany/java/sca/services/management/jmx/src/main/j >> ava/org/apache/tuscany/service/management/jmx/agent/AbstractA >> gent.java >> > - copied, changed from r495793, >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > >> va/org/apache/tuscany/standalone/server/management/jmx/Abstra >> ctAgent.j >> > ava >> > >> > >> incubator/tuscany/java/sca/services/management/jmx/src/main/j >> ava/org/apache/tuscany/service/management/jmx/agent/Agent.java >> > - copied, changed from r495793, >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > va/org/apache/tuscany/standalone/server/management/jmx/Agent.java >> > >> > >> incubator/tuscany/java/sca/services/management/jmx/src/main/j >> ava/org/apache/tuscany/service/management/jmx/agent/Managemen >> tException.java >> > - copied, changed from r495793, >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > >> va/org/apache/tuscany/standalone/server/management/jmx/Manage >> mentExcep >> > tion.java >> > >> > >> incubator/tuscany/java/sca/services/management/jmx/src/main/j >> ava/org/apache/tuscany/service/management/jmx/agent/RmiAgent.java >> > - copied, changed from r495793, >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > >> va/org/apache/tuscany/standalone/server/management/jmx/RmiAgent.java >> > Removed: >> > >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > >> va/org/apache/tuscany/standalone/server/management/jmx/Abstra >> ctAgent.j >> > ava >> > >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > va/org/apache/tuscany/standalone/server/management/jmx/Agent.java >> > >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > >> va/org/apache/tuscany/standalone/server/management/jmx/Manage >> mentExcep >> > tion.java >> > >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > >> va/org/apache/tuscany/standalone/server/management/jmx/RmiAgent.java >> > Modified: >> >incubator/tuscany/java/sca/pom.xml >> > >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > va/org/apache/tuscany/standalone/server/TuscanyServer.java >> > >> > Modified: incubator/tuscany/java/sca/pom.xml >> > URL: >> > >> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/pom.x >> ml?view=d >> > iff&rev=495803&r1=495802&r2=495803 >> > >> = >> = >> > >> > --- incubator/tuscany/java/sca/pom.xml (original) >> > +++ incubator/tuscany/java/sca/pom.xml Fri Jan 12 16:43:26 2007 >> > @@ -59,6 +59,18 @@ >> > false >> > >> > >> > + >> > +sateh >> > +Maven Sateh >> > +http://maven.sateh.com/maven2// >> > + >> > +true >> > + >> > + >> > +false >> > + >> > + >> > + >> > >> > >> > >> > >> > Modified: >> > >> incubator/tuscany/java/sca/runtime/standalone/server.start/sr >> c/main/ja >> > va/org/apache/tuscany/standalone/server/TuscanyServer.java >> > URL: >> > >> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/runti >> me/st
RE: Distributed assemblies
Jeremy, Based on the discussion we had earlier I have started putting the basic shell around the domain physical model and discovery service. 1. Both physical model discovery and service interfaces are hosted in SPI. 2. Under services I have started on couple of implementations for the discovery service. 3. I guess the physical model realisation would go into core. 3. In standalone assembly, I have created the home for the admin rutnime SCDL, that will host the client facing assembly service and also manage the domain wide singleton assembly model. Once we get this working we can look into moving this from a cerntalized model to a more federated peer-to-peer model. The admin runtime uses the discovery service to listen for federated runtimes, participating in the domain managed by the admin runtime, coming alive. The runtimes publish their presence using the discovery service when they come alive. The admin runtime will use the current topology of the domain to send artifacts that are deployed in the domain using the assembly service to participating runtimes. I am still unclear on how the admin runtime would make a decision on deploy component X in runtime X and component Y in runtime Y. Anyway, I will keep the discovery and the domain physical model service going. Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Distributed assemblies Date: Sat, 13 Jan 2007 12:26:12 -0800 Meeraj and I were chatting this morning about an approach for supporting an SCA Domain that is broader than a single runtime. So far we have been focusing on the wiring and component models within a single address space (runtime) allowing us to hook up user and system components according to the principles of SCA assembly. This has provided us a foundation for expanding functionality to the more interesting distributed case where we are managing an assembly that spans multiple runtimes. To do that, we identified a set of system services that would support this: 1) a global assembly model which represents the logical assembly of application components in the domain 2) a global physical model which represents the online physical structure of the domain (primarily which runtimes are participating) 3) a discovery service which would abstract the protocols used to discover/track the physical structure (a layering over protocols such as UPNP, Bonjour or JXTA) 4) a user-facing assembly service that allows them to manipulate the logical assembly 5) a "run this" (need a better name) service that allows the assembly service to control which logical components are actually running on a physical runtime (this may include bindings to support inter-runtime connections) The first use-case we want to support is one that allows a user to add a component to the assembly that is implemented by a composite that contains two components (X and Y) that are wired to each other but which need to be executed on two different physical runtimes (A and B). The assembly service will direct runtime A to run component X and runtime B to run component Y. It will also direct runtime A to bind the reference and runtime B to bind the service for the connecting wire so that X is able to invoke Y. This will take quite a bit of work so is probably best tackled in stages. The first priorities will be to get implementations of the user-facing assembly service and internal "run this" services running in a manner that supports distribution. We can do this locally by running two runtimes in a single server. At the same time we can be implementing a version of the discovery service that uses one of the standard protocols (which one is TBD) to build up the physical model. With this in place we can add the algorithms that determine how components get allocated to runtimes, starting with a basic form where the user provides the information and advancing to forms where it is configured by the global controller. The second phase will probably work in a master-slave mode where the controller runs on a single runtime (possibly with failover). A third phase will tackle the more complex problem of distributing the assembly model in a multi-master or pure-peer mode. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Build failure in tools
I was getting an error getting the pom for jaxen. From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Build failure in tools Date: Sat, 13 Jan 2007 11:11:09 -0800 I'm getting a download failure in tools: Reason: Error getting POM for 'org.apache.axis2:axis2-codegen' from the repository: Error transferring file org.apache.axis2:axis2-codegen:pom:1.1.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), sateh (http://maven.sateh.com/maven2//), apache.incubator (http://people.apache.org/repo/m2-incubating- repository/), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot- repository), eclipse.emf (http://download.eclipse.org/tools/emf/maven2) Is this the right set of repos for this? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversive
Hi, For eclipse users using subclipse, soemone pointed out this new svn plugin for eclipse (subversive, http://www.polarion.org/index.php?page=overview&project=subversive), which has a lot more features including atomic checkins across projects. Ta Meeraj * 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Continue having the Tuscany weekly IRC chat?
Monday 16:30 GMT is ok for me. -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 12:16 PM To: tuscany-dev@ws.apache.org Subject: Continue having the Tuscany weekly IRC chat? Just checking this for the new year as the chat has been a bit quiet recently - Do people think we should continue having the Tuscany weekly IRC chat and if so is Mondays at 16:30GMT still ok with everyone? I'd say yes and the day/time is fine for me, but what do you all think? If consensus is to continue I'll get the reminder emails going again. ...ant 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standalone server and Management Service
Hi, The first working version of the standalone server and management service are checked in, with support for multiple profiles. The server is in module server.start. The TuscanyServer class has the main method to start the server. The server registers itself with an MBean server exposed to remote clients through RMI. The available management ops are, 1. startRuntime(String profileName): This starts a specified runtime in the named profile based on Jeremy's earlier email on multiple profiles. 2. shutdownRuntime(String profileName): Shuts down the runtime. 3. shutdown(): Shuts down the server and all the booted runtimes. The server by default uses JMX for management. Individual runtimes may choose to use whatever management mechanism they wish. The jmx-host module provides a JMX runtime, that will use a JMX management service. Currently, the manageemnt view of individual components comprises of only the read-only view of properties. This can be extended to mutable properties, ops if deemed appropriate, wires, interceptors etc. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sourcecheck Profile
Hi, Is everyone able to run sourcecheck profile successfully. For me it is failing unable to find the checkstyle and pmd plugins (it is looking for version 2.2 snapshot). I can get it working only with adding http://repo1.maven.org/maven2/ in the plugin registry list in the parent pom and specifying the version of the plugins as 2.1 in the sca pom. I am not sure whether 2.2 is available anywhere else. Just wanted to ehck whether it is working for everyone else, before I checked in the changes to the poms(s). ta Meeraj _ Windows Live Messenger has arrived. Click here to download it for free! http://imagine-msn.com/messenger/launch80/?locale=en-gb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r492824 - /incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/spi/services/management/ManagementService.java
I agree.
However, in the runtime implementation there should be some way to pass
in contextual information into the management service instance. Mbean
server reference to the JmxManagementService for example. A dirty hack
would be to assume the constructor of all implementations would take a
runtime info and use that constructor to reflectively instantiate the
management service instance.
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 3:26 PM
To: tuscany-dev@ws.apache.org
Subject: Re: svn commit: r492824 -
/incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/tuscany/
spi/services/management/ManagementService.java
I don't think the RuntimeInfo is part of the service interface here -
it's more relevant to the implementation of the service than the client
interface. I'll try and think of an alternative.
--
Jeremy
On Jan 4, 2007, at 4:05 PM, [EMAIL PROTECTED] wrote:
> Author: meerajk
> Date: Thu Jan 4 16:05:21 2007
> New Revision: 492824
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=492824
> Log:
> Added RuntimeInfo as part of the ManagementService abstraction.
>
> Modified:
> incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
> tuscany/spi/services/management/ManagementService.java
>
> Modified: incubator/tuscany/java/sca/kernel/spi/src/main/java/org/
> apache/tuscany/spi/services/management/ManagementService.java
> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
> spi/src/main/java/org/apache/tuscany/spi/services/management/
> ManagementService.java?view=diff&rev=492824&r1=492823&r2=492824
> ==
>
> --- incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
> tuscany/spi/services/management/ManagementService.java (original)
> +++ incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
> tuscany/spi/services/management/ManagementService.java Thu Jan 4
> 16:05:21 2007
> @@ -18,6 +18,7 @@
> */
> package org.apache.tuscany.spi.services.management;
>
> +import org.apache.tuscany.host.RuntimeInfo;
> import org.apache.tuscany.spi.component.Component;
>
> /**
> @@ -28,7 +29,7 @@
> * @version $Revision$ $Date$
> *
> */
> -public interface ManagementService {
> +public interface ManagementService {
>
> /**
> * Registers a component for management.
> @@ -37,5 +38,11 @@
> * @param component Component to be registered.
> */
> void registerComponent(String name, Component component);
> +
> +/**
> + * Sets the runtime info used by the management service.
> + * @param runtimeInfo Runtime info for the management service.
> + */
> +void setRuntimeIno(R runtimeInfo);
>
> }
>
>
>
> -
> 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
This message has been checked for all email viruses by MessageLabs.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse code style template
Raymond, I will get the sourcecheck profile working and post the violations. Ta Meeraj From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Eclipse code style template Date: Fri, 05 Jan 2007 07:47:43 + Thanks Raymond. The sourcecheck profile is failing in the build unable to resolve maven checkstyle plugin from the current repos. Ta Meeraj From: "Raymond Feng" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: Subject: Re: Eclipse code style template Date: Thu, 4 Jan 2007 17:19:34 -0800 Hi, I checked in an updated version on Dec. 1, 2006. As we know, the template is not fully conforming to the checkstyle and we agree to fix it case by case. Meeraj, can you run the audit by running "mvn -Psourcecheck" and post the violations to help us understand what's breaking? Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Thursday, January 04, 2007 4:21 PM Subject: Re: Eclipse code style template On Jan 4, 2007, at 3:34 PM, Meeraj Kunnumpurath wrote: Hi, Is the eclipse code style template in etc up-to-date? I have configured my workspace to use it. However, Jim mentioned some of the changes I recently made in kernel screwed up the formatting. I don't think so. IIRC Raymond was working on updating it. -- Jeremy - 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] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse code style template
Thanks Raymond. The sourcecheck profile is failing in the build unable to resolve maven checkstyle plugin from the current repos. Ta Meeraj From: "Raymond Feng" <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: Subject: Re: Eclipse code style template Date: Thu, 4 Jan 2007 17:19:34 -0800 Hi, I checked in an updated version on Dec. 1, 2006. As we know, the template is not fully conforming to the checkstyle and we agree to fix it case by case. Meeraj, can you run the audit by running "mvn -Psourcecheck" and post the violations to help us understand what's breaking? Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Thursday, January 04, 2007 4:21 PM Subject: Re: Eclipse code style template On Jan 4, 2007, at 3:34 PM, Meeraj Kunnumpurath wrote: Hi, Is the eclipse code style template in etc up-to-date? I have configured my workspace to use it. However, Jim mentioned some of the changes I recently made in kernel screwed up the formatting. I don't think so. IIRC Raymond was working on updating it. -- Jeremy - 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] _ MSN Hotmail is evolving check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Update on management service
Hi,
This is a quick summary for the changes to enable management service within
composite components so that component registration can be relayed through
to the management service,
1. The runtime creates a management service and registers with the system
composite
2. The type of management service will be defined in etc/runtime.properties
3. Runtime passes the management service in to the default bootstrapper to
be used by the primodial builder registry
4. BuilderRegistry will have a depenedency on management service
5. This will be autowired for the one that comes from the scdl and set
manually for the one created in bootstrapper
6. CompositeComponent will have a setManagementService
7. After the builder builds the component and if it is a composite component
the builder registry will set the management service.
8. From there onwards the composite component will use the management
service for exposing its child components for management.
We will also have to pass contextual information to the management service
when it is created by the runtime. For eg, the JMX management service would
need a reference to the mbean server used by the host. I have a JMX runtime
info that is wired into the JMX management service to pass the mbean server.
However for this to work with a generic creation mechanism for management
service, we need to have runtime info as part of the management service
abstraction. Something like this in the runtime,
Properties runtimeProps = new Porperties();
InputStream in =
bootClassLoader.getResourceAsStream("/etc/runtime.properties");
runtimeProps.load(in);
String managementServiceClass =
runtimeProps.getProperty("management.service.class");
ManagementService managementService = (ManagementService)
Class.forName(managementServiceClass ).newInstance();
managementService .setRuntimeInfo(runtimeInfo);
and the JmxManagementService's setRuntimeInfo would look like
JmxRunrimeInfo jmxRuntimeInfo = (JmxRuntimeInfo) runtimeInfo;
this.mbeanServer = jmxRuntimeInfo.getMbeanServer();
We could even paremeterize ManagementService with RuntimeInfo to avoid the
donwcast.
Ta
Meeraj
_
Find Singles In Your Area This Christmas With Match.com! msnuk.match.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse code style template
Hi, Is the eclipse code style template in etc up-to-date? I have configured my workspace to use it. However, Jim mentioned some of the changes I recently made in kernel screwed up the formatting. Ta Meeraj _ Find Singles In Your Area This Christmas With Match.com! msnuk.match.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Server profiles
k, that makes sense. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 5:05 PM To: tuscany-dev@ws.apache.org Subject: Re: Server profiles On Jan 4, 2007, at 7:31 AM, Meeraj Kunnumpurath wrote: > Jeremy, > > On having the system.scdl in the etc directory .. > > I am assuming it is the system.scdl for the server itself, rather than > the runtime that is lauched by the server? Each runtime that is > launched through the startRuntime managed operation on the server will > have its own system.scdl, wherever it is stored as long it is > available to the boot classloader of the runtime? I was thinking that each profile (and the system.scdl it contains) would apply to a runtime. The server agent would not need one as it does not contain a system component tree. The startRuntime operation would take the name of a profile and that would be used to start the runtime. The server command could be enhanced to take an optional list of profiles to start, something like: $ server start server otherProfile yetAnother > > Would this mean the distro would be something like > > /install -> Root installer directory > /install/launcher -> Launcher root > /install/launcher/etc -> Launcher runtime properties and system scdl > /install/launcher/boot -> Launcher boot libraries /install/server -> > Server root /install/server/etc -> Server runtime properties and > system scdl /install/server/boot -> Server boot libraries > /install/server/runtime-x -> Runtime x root > /install/server/runtime-x/etc -> Runtime x runtime.properties and > system scdl /install/server/runtime-x/etc/boot -> Runtime x boot > libraries /install/server/runtime-y -> Runtime y root > /install/server/runtime-y/etc -> Runtime y runtime.properties and > system scdl /install/server/runtime-y/etc/boot -> Runtime y boot > libraries I was thinking instead: /install /install/bin/launcher.jar /install/bin/server.jar /install/lib/ [ jars needed by launcher, server commands] /install/profiles/launcher/etc/runtime.properties /install/profiles/launcher/etc/system.scdl /install/profiles/launcher/boot/ [ jars for launcher runtime classloader ] /install/profiles/server/etc/... /install/profiles/server/boot/... /install/profiles/otherProfile/etc/... /install/profiles/otherProfile/boot/... /install/profiles/yetAnother/etc/... /install/profiles/yetAnother/boot/... /install/profiles/... -- Jeremy - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Server profiles
Jeremy, On having the system.scdl in the etc directory .. I am assuming it is the system.scdl for the server itself, rather than the runtime that is lauched by the server? Each runtime that is launched through the startRuntime managed operation on the server will have its own system.scdl, wherever it is stored as long it is available to the boot classloader of the runtime? Would this mean the distro would be something like /install -> Root installer directory /install/launcher -> Launcher root /install/launcher/etc -> Launcher runtime properties and system scdl /install/launcher/boot -> Launcher boot libraries /install/server -> Server root /install/server/etc -> Server runtime properties and system scdl /install/server/boot -> Server boot libraries /install/server/runtime-x -> Runtime x root /install/server/runtime-x/etc -> Runtime x runtime.properties and system scdl /install/server/runtime-x/etc/boot -> Runtime x boot libraries /install/server/runtime-y -> Runtime y root /install/server/runtime-y/etc -> Runtime y runtime.properties and system scdl /install/server/runtime-y/etc/boot -> Runtime y boot libraries Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 3:13 PM To: tuscany-dev@ws.apache.org Subject: Server profiles One problem we had with M2 was that the launcher used a single set of extensions for every application it ran. I think Meeraj's server config will have a similar issue with it's ability to run multiple runtimes at the same time (with the likelihood that the reason someone wants to do that would be that they are configured differently). To address this, I am going to convert the standalone distro to support the notion of runtime profiles by adding a "profiles" directory in the root containing a subdirectory for each profile. There will be two built-in profiles "launcher" and "server" present by default and used by the launcher and server commands. Each profile will contain an "etc" directory which would contain the "runtime.properties" and "system.scdl" files used by that profile's runtime. As a side benefit moving the system.scdl out of the launcher jar will make it easier for users to change it if they want. I'll also add support for a new command line option ( -Dprofile=... ) to allow the user to override the default profile for each command. -- Jeremy - 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 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java kernel release
Francesco, Most of the discussions on management and JMX are available on the recent thread titled Standalone Server. Here is a brief overview of what we have .. Tuscany provides a standalone server in which one or more tuscany runtimes can be started. The server itself used JMX for management. The managed ops include stating/shutting down named runtimes and shutting down the server itself. However, the individual runtimes may choose to any management mechanism (JMX, WSDM, SNMP etc) to enable management. If a runtime decides to use JMX for management, the server will make sure the same mbean server that hosts the server is available for the runtime for registering the managed components within the runtime. This is, however, transparent through the management service abstraction. The abstraction is defined in ManagementService Tuscany SPI. However, the only implementation we have in core is based on JMX. When components are registered, they make them available for management through the management service. Currently, we support read-only view to the component properties. We are discussing about how to enable management of other aspects like poperty mutations, wire management etc. However, they do have other implications around durability of mutations, thread-safety around instances and scopes etc. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 5:08 PM To: tuscany-dev@ws.apache.org Subject: Re: Java kernel release On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote: > Hi Jim, > > as you know my vision about Tuscany architecture is still limited, but > I was wondering whether one of the JMX implementation at the Felix > project could help you. Take a look at http:// > cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html > > This solution is tied to adopt an OSGi container. I thought that > assemblies could be deployed as bundles, and the SCA system controlled > using an OSGi-based JMX console. > Hi Francesco, Meeraj has been leading the JMX integration so I'll let him talk about what his plans are for it... In terms of deploying assemblies as bundles, yes, we want to be able to support that but we also have plans to do more. The SCA collaboration is currently working on deployment (it is one of the big missing pieces prior to releasing the specs as "1.0" versions). It is still very much a work in progress but the idea behind SCA deployment is that we want to support a variety of "packaging" formats as well as the ability to contribute resources (e.g. Java classes, XSDs, WSDL port types, etc.) that an assembly may reference. They key thing we want to do is decouple how resources are referenced in an assembly and how they are physically contributed to the SCA "domain". Another key thing is we want the end-user experience to be very simple. Some specific examples may help to explain this further. Say I have the following component definition: How the com.acme.Foo service is contributed to the SCA runtime should not be evident from the assembly SCDL, as shown above. It could have been contributed through any of the following means: 1. The class file was placed in a directory 2. A jar containing the class file was contributed to a "deployment" service 3. An OSGi bundle containing the class file was contributed to a "deployment" service ..etc.. Similarly, the same mechanism could be used for WSDLs, XSDs, etc. More specifically, two steps take place in this process. The first is the resource is contributed to the SCA domain. The second step is the assembly is mutated, for example, a component is instantiated using the SCDL above. This allows for reuse. Sometimes these steps may be combined from an end-user perspective. For example, I should be able to drop a Java class in a directory and have the runtime introspect and deploy it as a component. The runtime should also be smart enough to be able to figure out how to provision components to various nodes in the service network. For example, if I have a component that requires high availability, it may deploy to a J2EE host environment running Tuscany. Or, it may provision it to an OSGi container running Tuscany. Ditto for the Standalone server. By the time we are done defining the deployment API, I suspect we will have something similar to Subversion. If you are interested in getting involved in helping implement some of this or other parts of Tuscany, let us know and I am sure people will be able to give you pointers to help get you started. Also, we're always interested in hearing about your requirements, particularly since it sounds as if you have several projects that may be able to make use of these capabilities. Jim > Is this approach feasible for you or you prefer to add JMX support > directly to the kernel? > > francesco > - To unsubscribe, e-mail: [EMAIL PROTECTED] For addi
