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]
