You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/02/17 15:36:24 UTC
URI handling during deployment
Working on the runtimes, I ran into a few quirks due to the way URIs
are represented during deployment - as a list of path name parts
rather than as a URI.
I'd like to simplify this by replacing #getPathNames with #getURI
containing the URI of the composite being deployed. That will remove
the need for loaders to reconstruct the URI from the path name each
time.
I think we should also abide by the standard convention that the URIs
for container-type components end in a '/' - that makes the
distinction clear and simplifies the use of URI#resolve.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: URI handling during deployment
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 17, 2007, at 6:36 AM, Jeremy Boynes wrote:
> Working on the runtimes, I ran into a few quirks due to the way
> URIs are represented during deployment - as a list of path name
> parts rather than as a URI.
>
> I'd like to simplify this by replacing #getPathNames with #getURI
> containing the URI of the composite being deployed. That will
> remove the need for loaders to reconstruct the URI from the path
> name each time.
>
+1. getPathNames was an ugly little hack I put in to get things
bootstrapped. It should go away.
> I think we should also abide by the standard convention that the
> URIs for container-type components end in a '/' - that makes the
> distinction clear and simplifies the use of URI#resolve.
>
+1. We can then get rid of URIHelper.getDefragmentedName() as well.
I also would like us to standardize our naming convention since we
have a bunch of different styles. How about getting rid of dot
notation and going with just simple camel notation since we can use
the component hierarchy, as in:
/Bar/Foo
In terms of domains, it seems as if we need three types: application,
system, and runtime. This will avoid name clashes and isolate wiring.
Thoughts,
Jim
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: URI handling during deployment
Posted by Jeremy Boynes <jb...@apache.org>.
So this turned into a ball of twine (see r508831) ...
I removed all references to pathNames held by the DeploymentContext
and replaced them with using the URI.
This lead to issues inside the ComponentManager where it was tracking
parent/child relationships, so I needed to refactor that to handle
parent (container uri) vs. leaf (non-container) correctly. This
highlighted an issue with the way the ComponentManager propagated
start events recursively down the hierarchy that meant it would not
work unless all the components were present on the local machine.
To resolve that, I removed the start/stop broadcasting from the
component implementation and changed the deployer to return a
collection of all components that it built. This allows all built
components to be started and means that intermediate parents do not
need to be present.
We still need to tackle the semantic of eager init across a federated
environment where multiple passes may be needed (because the
components in the composite may be on different machines). I think
the solution for this is to have the master send the eager init
events out in the right order; for now this needs to be done by
whomever calls the local deployer.
I wasn't able to test the standalone runtime as I still get a compile
error and the smoketest hangs.
--
Jeremy
On Feb 17, 2007, at 6:36 AM, Jeremy Boynes wrote:
> Working on the runtimes, I ran into a few quirks due to the way
> URIs are represented during deployment - as a list of path name
> parts rather than as a URI.
>
> I'd like to simplify this by replacing #getPathNames with #getURI
> containing the URI of the composite being deployed. That will
> remove the need for loaders to reconstruct the URI from the path
> name each time.
>
> I think we should also abide by the standard convention that the
> URIs for container-type components end in a '/' - that makes the
> distinction clear and simplifies the use of URI#resolve.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org