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. 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. 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. 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. The code doesn't currently distinguish between those services that are @Remotable and those that aren't Simon
