You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/12/08 14:19:23 UTC
[2.x] node configuration attributes
The node configuration file starts as follows:
<node xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903"
xmlns="http://tuscany.apache.org/xmlns/sca/1.1"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
uri="http://sample/nodes/TestNode1"
domain="http://domain1"
domainRegistry="tribes:default">
This seems a little confusing.
- why "uri" rather than nodeURI?
- why "domain" rather than "domainURI?
- what's the difference between domain and domainRegistry?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [2.x] node configuration attributes
Posted by Raymond Feng <en...@gmail.com>.
You can think this way:
domainURI: The URI of an SCA domain is the "logical id" (or name) of the
domain. The syntax of the URI is free-form and it doesn't imply any URL
connections.
domainRegistryURI: The URI of the "physical address" for the domain
registry. For example, we can use "tribes://228.0.0.100:50000" to say we are
going to use a tribes-based multicast over 228.0.0.100 (a multicast address
for the group) and port 50000. If the domain registry is a HTTP based
server, then the URI can be something like http://myhost:8080/mydomain.
Theoretically, we can use the same protocol address to support multiple SCA
domains. The domain URI can then be used to organize the entries for
endpoint descriptions.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, December 08, 2009 9:59 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] node configuration attributes
> ok, wasn't suggesting that we remove node/@uri just questioning it's
> name. So we would have...
>
> <node xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903"
> xmlns="http://tuscany.apache.org/xmlns/sca/1.1"
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
> uri="http://sample/nodes/TestNode1"
> domainURI="http://domain1"
> domainRegistryURI="tribes:default">
>
> Still not clear about the precise utility of domainURI vs
> domainRegistryURI. I'll take a look at the code
>
> Simon
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
ok, wasn't suggesting that we remove node/@uri just questioning it's
name. So we would have...
<node xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903"
xmlns="http://tuscany.apache.org/xmlns/sca/1.1"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
uri="http://sample/nodes/TestNode1"
domainURI="http://domain1"
domainRegistryURI="tribes:default">
Still not clear about the precise utility of domainURI vs
domainRegistryURI. I'll take a look at the code
Simon
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
Heh, well whatever I'm not saying don't, just it doesn't seem so
necessary or interesting to me ATM.
You didn't comment on the bit about the whether a user really needs to
know or care about the node URI?
...ant
On Tue, Dec 8, 2009 at 11:52 PM, Raymond Feng <en...@gmail.com> wrote:
> I don't agree. Using an external XML gives us the flexibility to configure
> the node. It is very useful for launchers. In the webapp case, we can start
> it from a remote node.xml without packaging the composites/contributions in
> the webapp itself.
>
> Having APIs doesn't conflict with the need to support XML configuration.
> It's just different ways to populate the in-memory model. It's somewhat
> similar as SCA SCDL vs. the Tuscany models.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, December 08, 2009 3:40 PM
> To: <de...@tuscany.apache.org>
> Subject: Re: [2.x] node configuration attributes
>
>> On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> See my comments inline.
>>>
>>> Thanks,
>>> Raymond
>>> --------------------------------------------------
>>> From: "ant elder" <an...@apache.org>
>>> Sent: Tuesday, December 08, 2009 2:58 PM
>>> To: <de...@tuscany.apache.org>
>>> Subject: Re: [2.x] node configuration attributes
>>>
>>> [[snip]]
>>>
>>>> What are the use cases for the XML representation? We dont actually
>>>> have anything in 2.x that needs this yet, could it be left till there
>>>> is something?
>>>
>>> Yes, we do.
>>>
>>> * We use the node.xml files to configure the client and server node in
>>> itest-nodes-two-nodes-two-vms-test.
>>> * We use it in web application integration so that a node can be created
>>> from the webapp from a node.xml which can be local or remote.
>>
>> Those arent really "use cases" though are they and they both can be
>> done fine if not better with the other exsiting APIs.
>>
>>> * We plan to bring up the Domain Manager which will provision the domain
>>> into a set of nodes. The configuration will be served using the node.xml
>>> format.
>>>
>>
>> Ok that might be one, but wouldn't it better to work out what any xml
>> that might need looks like at the time its being done?
>>
>>>>
>>>>> 4) I don't think node/@uri should be removed. Multiple nodes can have
>>>>> the
>>>>> same domain URI and domain registry URI. The node URI should uniquely
>>>>> identifies a node within an SCA domain. We can use a simple name
>>>>> instead
>>>>> of
>>>>> URI.
>>>>>
>>>>
>>>> What are the use cases for the node URI? The "node" is a concept thats
>>>> not in any SCA spec which we're making up for Tuscany so I'm trying to
>>>> understand if there are real reasons for needing to expose a node uri
>>>> in any user API?
>>>
>>> Node URI is used to uniquely identify a node within the SCA domain. It's
>>> similar as the domain or contribution URI. You can view it as an "id" of
>>> the
>>> node. If the URI is not provided, we will generate one. Having a
>>> user-defined ID makes it simpler to manage the nodes (for example, in the
>>> domain manager).
>>>
>>
>> But again, we don't have a domain manager yet so are there any other
>> real reasons for a user needing to give a node an id? Users care about
>> things like domains and contributions and services, why do they need
>> to think about nodes id's?
>>
>> What i'm trying to get at with these is what do we really need in the
>> Java API. Currently theres lots of stuff thats just there for
>> historical reasons that I think we can clean up and simplify and I
>> hope these reviews will help with that, and we should try to minimize
>> adding stuff just in case coz it sounds like it could be useful one
>> day. Maybe we will need an XML format too but thats less interesting
>> to me at the moment.
>>
>> ...ant
>
>
Re: [2.x] node configuration attributes
Posted by Raymond Feng <en...@gmail.com>.
I don't agree. Using an external XML gives us the flexibility to configure
the node. It is very useful for launchers. In the webapp case, we can start
it from a remote node.xml without packaging the composites/contributions in
the webapp itself.
Having APIs doesn't conflict with the need to support XML configuration.
It's just different ways to populate the in-memory model. It's somewhat
similar as SCA SCDL vs. the Tuscany models.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, December 08, 2009 3:40 PM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] node configuration attributes
> On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <en...@gmail.com> wrote:
>> See my comments inline.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Tuesday, December 08, 2009 2:58 PM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: [2.x] node configuration attributes
>>
>> [[snip]]
>>
>>> What are the use cases for the XML representation? We dont actually
>>> have anything in 2.x that needs this yet, could it be left till there
>>> is something?
>>
>> Yes, we do.
>>
>> * We use the node.xml files to configure the client and server node in
>> itest-nodes-two-nodes-two-vms-test.
>> * We use it in web application integration so that a node can be created
>> from the webapp from a node.xml which can be local or remote.
>
> Those arent really "use cases" though are they and they both can be
> done fine if not better with the other exsiting APIs.
>
>> * We plan to bring up the Domain Manager which will provision the domain
>> into a set of nodes. The configuration will be served using the node.xml
>> format.
>>
>
> Ok that might be one, but wouldn't it better to work out what any xml
> that might need looks like at the time its being done?
>
>>>
>>>> 4) I don't think node/@uri should be removed. Multiple nodes can have
>>>> the
>>>> same domain URI and domain registry URI. The node URI should uniquely
>>>> identifies a node within an SCA domain. We can use a simple name
>>>> instead
>>>> of
>>>> URI.
>>>>
>>>
>>> What are the use cases for the node URI? The "node" is a concept thats
>>> not in any SCA spec which we're making up for Tuscany so I'm trying to
>>> understand if there are real reasons for needing to expose a node uri
>>> in any user API?
>>
>> Node URI is used to uniquely identify a node within the SCA domain. It's
>> similar as the domain or contribution URI. You can view it as an "id" of
>> the
>> node. If the URI is not provided, we will generate one. Having a
>> user-defined ID makes it simpler to manage the nodes (for example, in the
>> domain manager).
>>
>
> But again, we don't have a domain manager yet so are there any other
> real reasons for a user needing to give a node an id? Users care about
> things like domains and contributions and services, why do they need
> to think about nodes id's?
>
> What i'm trying to get at with these is what do we really need in the
> Java API. Currently theres lots of stuff thats just there for
> historical reasons that I think we can clean up and simplify and I
> hope these reviews will help with that, and we should try to minimize
> adding stuff just in case coz it sounds like it could be useful one
> day. Maybe we will need an XML format too but thats less interesting
> to me at the moment.
>
> ...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <en...@gmail.com> wrote:
> See my comments inline.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, December 08, 2009 2:58 PM
> To: <de...@tuscany.apache.org>
> Subject: Re: [2.x] node configuration attributes
>
> [[snip]]
>
>> What are the use cases for the XML representation? We dont actually
>> have anything in 2.x that needs this yet, could it be left till there
>> is something?
>
> Yes, we do.
>
> * We use the node.xml files to configure the client and server node in
> itest-nodes-two-nodes-two-vms-test.
> * We use it in web application integration so that a node can be created
> from the webapp from a node.xml which can be local or remote.
Those arent really "use cases" though are they and they both can be
done fine if not better with the other exsiting APIs.
> * We plan to bring up the Domain Manager which will provision the domain
> into a set of nodes. The configuration will be served using the node.xml
> format.
>
Ok that might be one, but wouldn't it better to work out what any xml
that might need looks like at the time its being done?
>>
>>> 4) I don't think node/@uri should be removed. Multiple nodes can have the
>>> same domain URI and domain registry URI. The node URI should uniquely
>>> identifies a node within an SCA domain. We can use a simple name instead
>>> of
>>> URI.
>>>
>>
>> What are the use cases for the node URI? The "node" is a concept thats
>> not in any SCA spec which we're making up for Tuscany so I'm trying to
>> understand if there are real reasons for needing to expose a node uri
>> in any user API?
>
> Node URI is used to uniquely identify a node within the SCA domain. It's
> similar as the domain or contribution URI. You can view it as an "id" of the
> node. If the URI is not provided, we will generate one. Having a
> user-defined ID makes it simpler to manage the nodes (for example, in the
> domain manager).
>
But again, we don't have a domain manager yet so are there any other
real reasons for a user needing to give a node an id? Users care about
things like domains and contributions and services, why do they need
to think about nodes id's?
What i'm trying to get at with these is what do we really need in the
Java API. Currently theres lots of stuff thats just there for
historical reasons that I think we can clean up and simplify and I
hope these reviews will help with that, and we should try to minimize
adding stuff just in case coz it sounds like it could be useful one
day. Maybe we will need an XML format too but thats less interesting
to me at the moment.
...ant
Re: [2.x] node configuration attributes
Posted by Raymond Feng <en...@gmail.com>.
See my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, December 08, 2009 2:58 PM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] node configuration attributes
[[snip]]
> What are the use cases for the XML representation? We dont actually
> have anything in 2.x that needs this yet, could it be left till there
> is something?
Yes, we do.
* We use the node.xml files to configure the client and server node in
itest-nodes-two-nodes-two-vms-test.
* We use it in web application integration so that a node can be created
from the webapp from a node.xml which can be local or remote.
* We plan to bring up the Domain Manager which will provision the domain
into a set of nodes. The configuration will be served using the node.xml
format.
>
>> 4) I don't think node/@uri should be removed. Multiple nodes can have the
>> same domain URI and domain registry URI. The node URI should uniquely
>> identifies a node within an SCA domain. We can use a simple name instead
>> of
>> URI.
>>
>
> What are the use cases for the node URI? The "node" is a concept thats
> not in any SCA spec which we're making up for Tuscany so I'm trying to
> understand if there are real reasons for needing to expose a node uri
> in any user API?
Node URI is used to uniquely identify a node within the SCA domain. It's
similar as the domain or contribution URI. You can view it as an "id" of the
node. If the URI is not provided, we will generate one. Having a
user-defined ID makes it simpler to manage the nodes (for example, in the
domain manager).
>
> ...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 8, 2009 at 4:06 PM, Raymond Feng <en...@gmail.com> wrote:
> 4) Having an XML representation of the node configuration is good. It can
> serve as the canonical persistence format. Sure, the node configuration can
> be derived from many options:
> * arguments on the command line
> * programmatically via the NodeConfiguration model APIs
> * from a live URL to the domain manager
> * from classpath discovery
> * ...
What are the use cases for the XML representation? We dont actually
have anything in 2.x that needs this yet, could it be left till there
is something?
> 4) I don't think node/@uri should be removed. Multiple nodes can have the
> same domain URI and domain registry URI. The node URI should uniquely
> identifies a node within an SCA domain. We can use a simple name instead of
> URI.
>
What are the use cases for the node URI? The "node" is a concept thats
not in any SCA spec which we're making up for Tuscany so I'm trying to
understand if there are real reasons for needing to expose a node uri
in any user API?
...ant
Re: [2.x] node configuration attributes
Posted by Raymond Feng <en...@gmail.com>.
Some points:
1) The element name is <node>. Using "uri" as the attribute name is
consistent with the standard SCA XML style, such as component/@uri,
binding/@uri.
2) @domain is the URI of the SCA domain. The domain URI is defined by SCA
assembly spec. It uniquely identifies an SCA domain. I'm OK to change it to
be domainURI.
3) @domainRegistry holds a URI that can be used to connect to the domain
registry. Our EndpointRegistry uses the domain URI and domain registry URI
to connect to the back store that holds the endpoint descriptions.
4) Having an XML representation of the node configuration is good. It can
serve as the canonical persistence format. Sure, the node configuration can
be derived from many options:
* arguments on the command line
* programmatically via the NodeConfiguration model APIs
* from a live URL to the domain manager
* from classpath discovery
* ...
4) I don't think node/@uri should be removed. Multiple nodes can have the
same domain URI and domain registry URI. The node URI should uniquely
identifies a node within an SCA domain. We can use a simple name instead of
URI.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Tuesday, December 08, 2009 5:57 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] node configuration attributes
> On Tue, Dec 8, 2009 at 1:19 PM, Simon Laws <si...@googlemail.com>
> wrote:
>> The node configuration file starts as follows:
>>
>> <node xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903"
>> xmlns="http://tuscany.apache.org/xmlns/sca/1.1"
>> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
>> uri="http://sample/nodes/TestNode1"
>> domain="http://domain1"
>> domainRegistry="tribes:default">
>>
>> This seems a little confusing.
>>
>> - why "uri" rather than nodeURI?
>> - why "domain" rather than "domainURI?
>> - what's the difference between domain and domainRegistry?
>>
>
> Theres a lot that still needs to be cleaned up in this area. I dont
> think theres any longer a need for the node uri should to be surfaced
> to users at all. When i added the registry uri the intention was the
> domain name would be derived from that, so with "tribes:default" i'd
> expected the domain name to be "default" and not need to be defined
> elsewhere. It would also be good to make all this easier to use from
> the APIs without needing to write an XML document.
>
> ...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Wed, Dec 9, 2009 at 3:09 PM, Simon Laws <si...@googlemail.com> wrote:
>>
>> - it would useful and consistent to have a way to use Nodes with the
>> objects created from the Deployer so for example you can doing things
>> like Deployer.loadContribution, fiddle about with the Contribution and
>> then use that object in a Node. I'm not suggesting a method signature
>> for this yet as this opens up quite a lot of interesting options. For
>> example, all the NodeFactory methods about attaching or adding
>> deployment composites could then be done via the Deployer instead of
>> all the overloaded createNode methods. To do this well requires quite
>> a lot of changes to the Node APIs but after some playing around it
>> looks to me like it could make the APIs much cleaner with the simple
>> uses clear and obvious and the more complex cases more consistent and
>> powerful.
>
> Interesting. Sounds like you have examples. Can you post? Need to be
> careful about dependencies, i.e. to use the API what dependencies do
> you need to include. We have a workspace manager in 1.x that combines
> deployer type features with the ability to interact with the
> runtime/exntrsion points. No precisely what you are suggesting but I
> remember there were a lot of dependencies. Let discuss more and see
> where it goes.
>
I could add some code to show it, but before I do can you say more
about what the dependencies might be? The only dependency issues i can
think of are being able to use the Deployer without dragging in the
whole runtime but thats not an issue for Node, AFAIR all the workspace
stuff was removed as we just didnt have any use cases for the
functions it provided.
...ant
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
Sounds like a reasonable idea what with people being out and unable to
help out.
Simon
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
I'd quite like to get done some of the changes we've been talking
about in this thread but I know people are out for the year now so I'm
not sure i should just dive in changing the existing module. Perhaps a
new module to do the changes in parallel with the existing so all the
old code can remain unchanged for now?
...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
This thread is getting a bit hard to follow, i'll try replying to
individual part in separate emails:
On Wed, Dec 9, 2009 at 3:09 PM, Simon Laws <si...@googlemail.com> wrote:
>>
>> Some to remove:
>> - all the ones using classloaders
>> - the Client Interface and just add the getService method to Node
>
> Can we return an SCA client factory instance for the node
>
Something like that seems like it would be nice, but the SCAClient API
dosn't make it work so well as the getService method isn't on an
interface its on the abstract class SCAClientFactory so we'd have to
make Node a subclass of SCAClientFactory. Or do you mean have a getter
on Node for an SCAClientFactory? That seems a bit better. Another
option would be to remove getService entirely and just always use the
SCAClient API, so:
SCAClientFactory.newInstance(...).getService(...)
instead of
node.getService(...) or node.getSCAClientFactory().getService(...)
Only using the SCAClient API would help reinforce the separation of
client and runtime.
...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@gmail.com>.
On Wed, Dec 9, 2009 at 4:52 PM, Raymond Feng <en...@gmail.com> wrote:
> I'm open to refine some of the createNode() flavors.
Good.
...ant
Re: [2.x] node configuration attributes
Posted by Raymond Feng <en...@gmail.com>.
Before we start to refactor the NodeFactory/Node API, let me explain how the
current ones are defined.
1) A NodeFactory represents an instance of the Tuscany kernel with an
ExtensionPointRegistry to access all extension points and extensions.
2) A Node is a unit of work that consists of a group of top-level components
from the SCA domain composite that can be started/stopped together. It's
typically configured as a list of contributions with deployable composites
that contain the group of top-level components.
3) A NodeConfiguration model is defined to capture all the attributes for
the configuration of a Node. NodeFactory can be used as the factory to
create NodeConfiguration instances. The NodeConfiguration provides a Java
DSL style methods to set the attributes. For example,
NodeConfiguration configuration =
NodeFactory.newInstance().createNodeConfiguration().setDomainURI("domain1").setURI("node1")
.setDomainRegistryURI("tribes://...").addContribution("c1",
"file://.../contribution1");
4) A NodeConfiguration can be populated from various sources, such as the
command-line arguments, an XML node.xml, a feed, or classpath discovery.
5) NodeFactory.createNode(NodeConfiguration config) is the ultimate method
that all other flavors of createNode() methods will delegate to. Each flavor
of the createNode() API is just to provide a convenient way to populate a
NodeConfiguration.
6) The following is a list of createNode() methods:
Create a node instance from the NodeConfiguration model. This is the
canonical API.
createNode(NodeConfiguration):
The following methods create a NodeConfiguration from the deployment
composite (which can be the URI within a contribution, an absolute URL, or
the content) and a list of contributions (uri for the id and url for the
location).
createNode(Contribution...):
createNode(String, Contribution...)
createNode(String, String[])
createNode(String, String[], String[])
createNode(InputStream, Contribution...)
createNode(Reader, Contribution...)
createNode(Reader, String[], String[])
Please note it's a combination of different ways to provide the deployment
composite and contributions. For example, we can use the
uri/reader/inputstream for the composite. For contributions, they can be
passed in as an array of Contribution (uri+location) obects, two arrays of
contribution uris and locations (String[], String[]) or an array of
contribution locations (String[], the uri is default to the location).
The next two methods allows a Node to created from the node.xml.
createNode(InputStream)
createNode(URL)
The last two methods are shortcuts to discover the node configuration from
the classpath.
createNode() - using META-INF/sca-contribution.xml as the resource to look
up the contribution on the classpath.
createNode(String, ClassLoader) - using the deployment composite uri as the
resource name and the classloader to look up a contribution on the
classpath. The location of the contribution is the classpath entry to the
resource name.
I'm open to refine some of the createNode() flavors.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Wednesday, December 09, 2009 7:09 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: [2.x] node configuration attributes
>> - createNode(URI uri, String... contributionLocations);
>> where the uri is the config uri that can be used to configure things
>> like the domain name and registry. That would match the SCAClient API
>> that takes the the similar uri to connect to the running services
>
> +1 It would seem sensible that all the atributes (that started this
> discussion) should be able to be provided via the API as well as via
> the XML file. So we should support uri, domainURI, domainRegistryURI
> (I haven't gone back and looked at the difference yet)
>
>>
>> - it would useful and consistent to have a way to use Nodes with the
>> objects created from the Deployer so for example you can doing things
>> like Deployer.loadContribution, fiddle about with the Contribution and
>> then use that object in a Node. I'm not suggesting a method signature
>> for this yet as this opens up quite a lot of interesting options. For
>> example, all the NodeFactory methods about attaching or adding
>> deployment composites could then be done via the Deployer instead of
>> all the overloaded createNode methods. To do this well requires quite
>> a lot of changes to the Node APIs but after some playing around it
>> looks to me like it could make the APIs much cleaner with the simple
>> uses clear and obvious and the more complex cases more consistent and
>> powerful.
>
> Interesting. Sounds like you have examples. Can you post? Need to be
> careful about dependencies, i.e. to use the API what dependencies do
> you need to include. We have a workspace manager in 1.x that combines
> deployer type features with the ability to interact with the
> runtime/exntrsion points. No precisely what you are suggesting but I
> remember there were a lot of dependencies. Let discuss more and see
> where it goes.
>
>>
>> - rename createNode(URL) to match the other loadConfiguration method,
>> or rename both to something like createNodeFromConfig
>
> Didn't spot those methods down at the bottom of NodeFactory. So we also
> have...
>
> public abstract Node createNode(NodeConfiguration configuration);
> node configuration object
> public abstract NodeConfiguration loadConfiguration(InputStream
> xml, URL base);
> XML = node config xml? base = ?
>
> createNode would be more consistent
>
>>
>> Some to remove:
>> - all the ones using classloaders
>> - the Client Interface and just add the getService method to Node
>
> Can we return an SCA client factory instance for the node
>
>> - the destroy method
>> - the getInstance(String domainURI) as there's the createNode that
>> includes the URI
>>
>> ...ant
>>
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
> - createNode(URI uri, String... contributionLocations);
> where the uri is the config uri that can be used to configure things
> like the domain name and registry. That would match the SCAClient API
> that takes the the similar uri to connect to the running services
+1 It would seem sensible that all the atributes (that started this
discussion) should be able to be provided via the API as well as via
the XML file. So we should support uri, domainURI, domainRegistryURI
(I haven't gone back and looked at the difference yet)
>
> - it would useful and consistent to have a way to use Nodes with the
> objects created from the Deployer so for example you can doing things
> like Deployer.loadContribution, fiddle about with the Contribution and
> then use that object in a Node. I'm not suggesting a method signature
> for this yet as this opens up quite a lot of interesting options. For
> example, all the NodeFactory methods about attaching or adding
> deployment composites could then be done via the Deployer instead of
> all the overloaded createNode methods. To do this well requires quite
> a lot of changes to the Node APIs but after some playing around it
> looks to me like it could make the APIs much cleaner with the simple
> uses clear and obvious and the more complex cases more consistent and
> powerful.
Interesting. Sounds like you have examples. Can you post? Need to be
careful about dependencies, i.e. to use the API what dependencies do
you need to include. We have a workspace manager in 1.x that combines
deployer type features with the ability to interact with the
runtime/exntrsion points. No precisely what you are suggesting but I
remember there were a lot of dependencies. Let discuss more and see
where it goes.
>
> - rename createNode(URL) to match the other loadConfiguration method,
> or rename both to something like createNodeFromConfig
Didn't spot those methods down at the bottom of NodeFactory. So we also have...
public abstract Node createNode(NodeConfiguration configuration);
node configuration object
public abstract NodeConfiguration loadConfiguration(InputStream
xml, URL base);
XML = node config xml? base = ?
createNode would be more consistent
>
> Some to remove:
> - all the ones using classloaders
> - the Client Interface and just add the getService method to Node
Can we return an SCA client factory instance for the node
> - the destroy method
> - the getInstance(String domainURI) as there's the createNode that
> includes the URI
>
> ...ant
>
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 15, 2009 at 3:26 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 3:31 AM, ant elder <an...@apache.org> wrote:
>> On Wed, Dec 9, 2009 at 2:41 PM, ant elder <an...@apache.org> wrote:
>>
>>> Some to remove:
>>> - all the ones using classloaders
>>> - the Client Interface and just add the getService method to Node
>>> - the destroy method
>>> - the getInstance(String domainURI) as there's the createNode that
>>> includes the URI
>>>
>>
>> Another method to consider for removal is the Node start() method. I
>> don't see why is thats needed now as after a node is created you can
>> do nothing except start or stop it so it might as well just be created
>> in the started state. If for some reason the was a need to pass around
>> an unstarted Node you can just pass around a NodeConfiguration
>> instead.
>>
>> ...ant
>>
>
> Without start/stop, how do you restart a node after some configuration changes ?
>
You have to create a new node. Which is actually the same as it is
now as there are no methods to update a Node after its created.
...ant
Re: [2.x] node configuration attributes
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Dec 15, 2009 at 3:31 AM, ant elder <an...@apache.org> wrote:
> On Wed, Dec 9, 2009 at 2:41 PM, ant elder <an...@apache.org> wrote:
>
>> Some to remove:
>> - all the ones using classloaders
>> - the Client Interface and just add the getService method to Node
>> - the destroy method
>> - the getInstance(String domainURI) as there's the createNode that
>> includes the URI
>>
>
> Another method to consider for removal is the Node start() method. I
> don't see why is thats needed now as after a node is created you can
> do nothing except start or stop it so it might as well just be created
> in the started state. If for some reason the was a need to pass around
> an unstarted Node you can just pass around a NodeConfiguration
> instead.
>
> ...ant
>
Without start/stop, how do you restart a node after some configuration changes ?
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 15, 2009 at 4:48 PM, Raymond Feng <en...@gmail.com> wrote:
> A few of PMC members including me are out for vacation. Would it be possible
> that we hold off some of the changes?
Sure, did you see the other email about not changing the existing
modules while people are out?
>>> Some to remove:
>>> - all the ones using classloaders
>>> - the Client Interface and just add the getService method to Node
>>> - the destroy method
>>> - the getInstance(String domainURI) as there's the createNode that
>>> includes the URI
>>>
>
> +1. Do you plan to have a Helper that can be used to populate
> NodeConfiguration from the resource and classloader?
>
Not unless someone has a good use case for needing it. (and then if
they do I'd wonder why the methods to support it wouldn't go in the
actual API classes instead of a helper)
>>
>> Another method to consider for removal is the Node start() method. I
>> don't see why is thats needed now as after a node is created you can
>> do nothing except start or stop it so it might as well just be created
>> in the started state. If for some reason the was a need to pass around
>> an unstarted Node you can just pass around a NodeConfiguration
>> instead.
>>
>
> I prefer to keep the start() method for a few reasons:
> 1) symmetric with stop(): users of the API will remember to call stop() if
> they call start().
> 2) consistent with the other SPIs that involve the lifecycle management,
> such as LifeCycleListener
> 3) the start/stop can be potentially exposed to management layer
>
What would the management layer do with it? If there's a use case then
fine, but right now there's not much useful you can do. If we do keep
a separate start() then I'd like to be able to add other methods to
Node so you can do configuration directly on the Node before starting
it, eg node=NodeFactory.createNode();
node.addContribution(contribution); node.start();
...ant
Re: [2.x] node configuration attributes
Posted by Raymond Feng <en...@gmail.com>.
A few of PMC members including me are out for vacation. Would it be possible
that we hold off some of the changes? See my brief comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, December 15, 2009 3:31 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] node configuration attributes
> On Wed, Dec 9, 2009 at 2:41 PM, ant elder <an...@apache.org> wrote:
>
>> Some to remove:
>> - all the ones using classloaders
>> - the Client Interface and just add the getService method to Node
>> - the destroy method
>> - the getInstance(String domainURI) as there's the createNode that
>> includes the URI
>>
+1. Do you plan to have a Helper that can be used to populate
NodeConfiguration from the resource and classloader?
>
> Another method to consider for removal is the Node start() method. I
> don't see why is thats needed now as after a node is created you can
> do nothing except start or stop it so it might as well just be created
> in the started state. If for some reason the was a need to pass around
> an unstarted Node you can just pass around a NodeConfiguration
> instead.
>
I prefer to keep the start() method for a few reasons:
1) symmetric with stop(): users of the API will remember to call stop() if
they call start().
2) consistent with the other SPIs that involve the lifecycle management,
such as LifeCycleListener
3) the start/stop can be potentially exposed to management layer
Can we hold it off?
> ...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Wed, Dec 9, 2009 at 2:41 PM, ant elder <an...@apache.org> wrote:
> Some to remove:
> - all the ones using classloaders
> - the Client Interface and just add the getService method to Node
> - the destroy method
> - the getInstance(String domainURI) as there's the createNode that
> includes the URI
>
Another method to consider for removal is the Node start() method. I
don't see why is thats needed now as after a node is created you can
do nothing except start or stop it so it might as well just be created
in the started state. If for some reason the was a need to pass around
an unstarted Node you can just pass around a NodeConfiguration
instead.
...ant
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Wed, Dec 9, 2009 at 2:02 PM, Simon Laws <si...@googlemail.com> wrote:
> The createNode(String... contributionLocations); operation sounds
> reasonable. I'd like to make a list of what we have in various places
> and what it's utility is. We already have several ways of creating
> nodes through APIs and launchers and they are not consistent.
>
> node-api/NodeFactory
> public Node createNode(URL configurationURL) {
> URL of a node config doc
> public Node createNode(InputStream is) {
> node config doc as a stream
> public Node createNode(String deploymentCompositeURI,
> Contribution... contributions)
> deployment composite URI and list of contribution configurations
> public final Node createNode(String deploymentCompositeURI,
> String[] uris, String locations[])
> ???
> public final Node createNode(String deploymentCompositeURI, String
> locations[])
> ???
> public final Node createNode(Reader deploymentCompositeContent,
> String[] uris, String locations[])
> ???
> public final Node createNode(String compositeURI, ClassLoader classLoader)
> ???
> public Node createNode(Contribution... contributions)
> list of contribution configurations
> public Node createNode(InputStream compositeContent,
> Contribution... contributions)
> contributions and deployment composite in an input stream
> public Node createNode(Reader compositeContent, Contribution...
> contributions)
> contributions and deployment composite in a reader
> public Node createNode()
> assume contrib is in current directory
> Seems to be a lot. What can we add/remove? Ant already suggested a
> list of contribution locations.
>
Some more additions:
- createNode(URI uri, String... contributionLocations);
where the uri is the config uri that can be used to configure things
like the domain name and registry. That would match the SCAClient API
that takes the the similar uri to connect to the running services
- it would useful and consistent to have a way to use Nodes with the
objects created from the Deployer so for example you can doing things
like Deployer.loadContribution, fiddle about with the Contribution and
then use that object in a Node. I'm not suggesting a method signature
for this yet as this opens up quite a lot of interesting options. For
example, all the NodeFactory methods about attaching or adding
deployment composites could then be done via the Deployer instead of
all the overloaded createNode methods. To do this well requires quite
a lot of changes to the Node APIs but after some playing around it
looks to me like it could make the APIs much cleaner with the simple
uses clear and obvious and the more complex cases more consistent and
powerful.
- rename createNode(URL) to match the other loadConfiguration method,
or rename both to something like createNodeFromConfig
Some to remove:
- all the ones using classloaders
- the Client Interface and just add the getService method to Node
- the destroy method
- the getInstance(String domainURI) as there's the createNode that
includes the URI
...ant
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
The createNode(String... contributionLocations); operation sounds
reasonable. I'd like to make a list of what we have in various places
and what it's utility is. We already have several ways of creating
nodes through APIs and launchers and they are not consistent.
node-api/NodeFactory
public Node createNode(URL configurationURL) {
URL of a node config doc
public Node createNode(InputStream is) {
node config doc as a stream
public Node createNode(String deploymentCompositeURI,
Contribution... contributions)
deployment composite URI and list of contribution configurations
public final Node createNode(String deploymentCompositeURI,
String[] uris, String locations[])
???
public final Node createNode(String deploymentCompositeURI, String
locations[])
???
public final Node createNode(Reader deploymentCompositeContent,
String[] uris, String locations[])
???
public final Node createNode(String compositeURI, ClassLoader classLoader)
???
public Node createNode(Contribution... contributions)
list of contribution configurations
public Node createNode(InputStream compositeContent,
Contribution... contributions)
contributions and deployment composite in an input stream
public Node createNode(Reader compositeContent, Contribution...
contributions)
contributions and deployment composite in a reader
public Node createNode()
assume contrib is in current directory
Seems to be a lot. What can we add/remove? Ant already suggested a
list of contribution locations.
domain-node/DomainNodeMain
what args can be provided here?
node-launcher/NodeMain
-nd
-dm
I'd be happy to loose this one. Extra code for very little value
IMHO. Just choose the appropriate launcher
node-launcher/NodeLauncher
-c compositeUri
-n node
-s service
-t time to live
contribution... a list of contribution locations
are there other options?
node-launcher/NodeDaemonLauncher
This this just started the node launcher and waits (with some fancy
shut down logic)
node-launcher/DomainManagerLauncher
I assume this is not used at the moment?
node-launcher-equinox/NodeLauncher
Has different options again so need to consolidate
Simon
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 8, 2009 at 3:25 PM, Simon Laws <si...@googlemail.com> wrote:
> 3/ review API use cases
Ok so whats the easiest way to do that?
- posting to the ML or wiki page with suggestions and updates
- dive in and start updating the node-api module
- start a new node-api module somewhere else to work on the use cases
and updates
That last of those seem easiest to me as it will make it easier to
keep track of.
To start, the simplest most common use case we have is to create a
Node from contributions which have deployables defined in
sca-contribution.xml files so it would be good to have a simplest
possible method for that, eg:
createNode(String... contributionLocations);
does that sound reasonable?
...ant
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
> Sounds ok and I don't think that already exists, I'd also add a 3/ or
> perhaps that should be 0/ "review what the use cases are that the APIs
> are for".
>
> ...ant
>
+1
1/ review what the configuration parameter set is
2/ review the various APIs we have and what parameters they support.
3/ review API use cases
Simon
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 8, 2009 at 2:44 PM, Simon Laws <si...@googlemail.com> wrote:
> OK good. I don't see negatives in supporting an XML syntax that
> represents configuration params as long as those parameters are clear
> and consistent.
I wasn't saying there should not be XML, i was suggesting that if
there is XML it should match the API and that the API should be easy
to use so that if you're doing something programatically like these
testcases then you'd probably be using the API instead of resorting to
writing XML.
> So it seems that we should
>
> 1/ review what the configuration parameter set is
> 2/ review the various APIs we have and what parameters they support.
>
> I'll can go and make a list assuming that someone doesn't point me
> toward an existing one.
>
Sounds ok and I don't think that already exists, I'd also add a 3/ or
perhaps that should be 0/ "review what the use cases are that the APIs
are for".
...ant
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
OK good. I don't see negatives in supporting an XML syntax that
represents configuration params as long as those parameters are clear
and consistent. So it seems that we should
1/ review what the configuration parameter set is
2/ review the various APIs we have and what parameters they support.
I'll can go and make a list assuming that someone doesn't point me
toward an existing one.
Simon
Re: [2.x] node configuration attributes
Posted by ant elder <an...@apache.org>.
On Tue, Dec 8, 2009 at 1:59 PM, Simon Laws <si...@googlemail.com> wrote:
> Is it possible to specify the domainRegistry via the APi at the moment?
>
> Simon
>
Yep, in NodeConfiguration.setDomainRegistryURI or using the more
simple DomainNode in its constructor.
...ant
Re: [2.x] node configuration attributes
Posted by Simon Laws <si...@googlemail.com>.
Is it possible to specify the domainRegistry via the APi at the moment?
Simon
Re: [2.x] node configuration attributes
Posted by ant elder <an...@gmail.com>.
On Tue, Dec 8, 2009 at 1:19 PM, Simon Laws <si...@googlemail.com> wrote:
> The node configuration file starts as follows:
>
> <node xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200903"
> xmlns="http://tuscany.apache.org/xmlns/sca/1.1"
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
> uri="http://sample/nodes/TestNode1"
> domain="http://domain1"
> domainRegistry="tribes:default">
>
> This seems a little confusing.
>
> - why "uri" rather than nodeURI?
> - why "domain" rather than "domainURI?
> - what's the difference between domain and domainRegistry?
>
Theres a lot that still needs to be cleaned up in this area. I dont
think theres any longer a need for the node uri should to be surfaced
to users at all. When i added the registry uri the intention was the
domain name would be derived from that, so with "tribes:default" i'd
expected the domain name to be "default" and not need to be defined
elsewhere. It would also be good to make all this easier to use from
the APIs without needing to write an XML document.
...ant