I like the look of the workspace code Sebastien has been writing and I propose to try it out on samples/calculator-distributed.
In particular I'd like to help Felix who is hitting the common filesystem restriction of the current domain implementation . Let me know if anyone has any concerns. I'll report back with what I learn. There are other modules that rely on distributed support itest/callable-references itest/domain itest/osgi-tuscany/tuscany-3rdparty itest/osgi-tuscay/tuscany-runtime samples/calculator-distributed tools/eclipse/plugins/runtime I'm happy to think about those if the sample/calculator-distributed goes ok. Regards Simon [1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg02610.html On Mon, Mar 10, 2008 at 6:07 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Jean-Sebastien Delfino wrote: > > Simon Laws wrote: > >> On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <[EMAIL PROTECTED]> > >> wrote: > >> > >>> > >>> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino < > >>> [EMAIL PROTECTED]> wrote: > >>> > >>>> Jean-Sebastien Delfino wrote: > >>>>> Simon Laws wrote: > >>>>>> I've been running the workspace code today with a view to > integrating > >>>> the > >>>>>> new code in assembly which calculates service endpoints i.e. point4 > >>>>>> above. > >>>>>> > >>>>>> I think we need to amend point 4 to make this work properly.. > >>>>>> > >>>>>> 4. Point my Web browser to the various ATOM collections to get: > >>>>>> - lists of contributions, composites and nodes > >>>>>> - list of contributions that are required by a given contribution > >>>>>> - the source of a particular composite > >>>>>> - the output of a composite after the domain composite has been > built > >>>> by > >>>>>> CompositeBuilder > >>>>>> > >>>>>> Looking at the code in DeployableCompositeCollectionImpl I see that > >>>> on > >>>>>> doGet() it builds the request composite. What the last point needs > >>>> to > >>>>>> do is > >>>>>> > >>>>>> - read the whole domain > >>>>>> - set up all of the service URIs for each of the included > composites > >>>>>> taking > >>>>>> into account the node to which each composite is assigned > >>>>>> - build the whole domain using CompositeBuilder > >>>>>> - extract the required composite from the domain and serialize it > >>>> out. > >>>>> Yes, exactly! > >>>>> > >>>>>> Are you changing this code or can I put this in? > >>>>> Just go ahead, I'll update and merge if I have any other changes in > >>>> the > >>>>> same classes. > >>>>> > >>>> Simon, a quick update: I've done an initial bring-up of node2-impl. > >>>> It's > >>>> still a little rough but you can give it a try if you want. > >>>> > >>>> The steps to run the store app for example with node2 are as follows: > >>>> > >>>> 1) use workspace-admin to add the store and assets contributions to > the > >>>> domain; > >>>> > >>>> 2) add the store composite to the domain composite using the admin as > >>>> well; > >>>> > >>>> 3) start the StoreLauncher2 class that I just added to the store > >>>> module; > >>>> > >>>> 4) that will start an instance of node2 with all the node config > served > >>>> from the admin app. > >>>> > >>>> So the next step is to integrate your node allocation code with > >>>> workspace-admin and that will complete the story. Then we'll be able > to > >>>> remove all the currently hardcoded endpoint URIs from the composites. > >>>> > >>>> I'll send a more detailed description and steps to run more scenarios > >>>> later on Friday. > >>>> > >>>> -- > >>>> Jean-Sebastien > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> Ok, sounds good. I've done the uri integration although there are > some > >>> issues we need to discuss. First I'll update with your code, commit my > >>> changes and then post here about the issues. > >>> > >>> Regards > >>> > >>> Simon > >>> > >> I've now checked in my changes (last commit was 634762) to integrate > >> the URI > >> calculation code with the workspace. I've run the new store launcher > >> following Sebastien's instructions from a previous post to this thread. > I > >> don't seem to have broken it too much although I'm not seeing any > >> prices for > >> the catalog items. > > > > I was seeing that issue too before, it's a minor bug in the property > > writing code, which is not writing property values correctly. > > > >> Issues with the URI generation code.... > >> > >> I have to turn model resolution back on by uncommenting a line in > >> ContributionContentProcessor.resolve. Otherwise the JavaImplementation > >> types > >> are not read and > >> compositeConfiguationBuilder.calculateBindingURIs(defaultBindings, > >> composite, null); can't generate default services. I then had to tun > >> it back > >> off to make the store sample work. I need some help on this one. > > > > I'm investigating now. > > > >> > >> If you hand craft services it seems to be OK although I have noticed, > >> looking at the generated SCDL, that it seems to be assuming that all > >> generated service names will be based on the implementation classname > >> regardless of whether the interface is marked as @Remotable or not. > Feels > >> like a bug somewhere so am going to look at that next. > > > > OK > > > >> > >> To get Java implementation resolution to work I needed to hack in the > >> Java > >> factories setup in the DeployableCompositeCollectionImpl.initialize() > >> method. This is not very good and raises the bigger question about > >> the set > >> up in here. It's creating a set of extension points in parallel to > those > >> created by the runtime running this component. Can we either use the > >> registry created by the underlying runtime or do similar generic setup. > > > > Yes, I'd like to keep the infrastructure used by the admin decoupled > > from the infrastructure of the runtime hosting the admin, but I'll try > > to simplify the setup by creating an instance of runtime for the admin > > and getting the necessary objects out of it, instead of assembling it > > from scratch as it is now. > > > >> The code doesn't currently distinguish between those services that are > >> @Remotable and those that aren't > >> > >> Simon > >> > > > > > > Simon, > > After a few more changes, the domain / node allocation, default URI > calculation and resolution of references across nodes now works OK. > > I was able to remove all the hardcoded URIs in the tutorial composites > as they now get determined from the configuration of the nodes that the > composites are deployed to. > > You can use the latest tutorial modules to see the end to end > integration, with the following steps: > > 1. Start tutorial/domain/.../LaunchTutorialAdmin. > > 2. Open http://localhost:9990/ui/composite in your Web browser. You > should see all the tutorial contributions and deployables that I've > added to that domain. > > 3. Click the feeds in the "composite install image" to see the resolved > composites. > > 4. Start all the launch programs in tutorial/nodes, you can start them > in any order you want. > > 5. Open tutorial/assets/tutorial.html in your Web browser, follow the > links to the various store implementations. > > Hope this helps. > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
