[ https://issues.apache.org/jira/browse/TUSCANY-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788182#action_12788182
]
Luciano Resende commented on TUSCANY-3390:
------------------------------------------
Thanks for reporting this, While I take a look at this, in order for you to make progress,
you could look into the samples/store from the 1.5.1 release which is basically the same example
from the getting started guide.
> atom feed does not work on browsers properly for 1.5.1
> ------------------------------------------------------
>
> Key: TUSCANY-3390
> URL: https://issues.apache.org/jira/browse/TUSCANY-3390
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA ATOM Binding Extension
> Affects Versions: Java-SCA-1.5.1
> Environment: windows xp java 1.6 eclipse 3.4 ganymede sca 1.5.1 plugin
> Reporter: Kalpeshkumar Soni
>
> I installed eclipse and installed the tuscany plugin from http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/
> I was able to run the store sample that uses jsonrpc and atom feed as an example
> the atom feed is not working properly
> in the browser i see the items but not correct name or prices
> it does not look like the screen shots posted in http://tuscany.apache.org/getting-started-with-tuscany-using-tuscany-eclipse-plugin.html
when I hit http://localhost:8080/ShoppingCart
> I tried with Firefox 3.5 and IE7
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TUSCANY-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788159#action_12788159
]
Kalpeshkumar Soni commented on TUSCANY-3390:
--------------------------------------------
This is the xml for the /ShoppingCart/Cart
<?xml version="1.0" encoding="http://www.w3.org/2005/Atom" standalone="no"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">Feed</title>
<id>Feed31472225</id>
<entry>
<id>cart-490e683a-c27a-49a9-a0b5-d861c443def1</id>
<title type="text">item</title>
<content type="application/xml">
<ns2:root xmlns:ns2="http://tuscany.apache.org/xmlns/sca/databinding/jaxb/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="item">
<name xmlns="">Pear</name>
<price xmlns="">$1.55</price>
</ns2:root>
</content>
<link href="cart-490e683a-c27a-49a9-a0b5-d861c443def1"/>
</entry>
</feed>
> atom feed does not work on browsers properly for 1.5.1
> ------------------------------------------------------
>
> Key: TUSCANY-3390
> URL: https://issues.apache.org/jira/browse/TUSCANY-3390
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA ATOM Binding Extension
> Affects Versions: Java-SCA-1.5.1
> Environment: windows xp java 1.6 eclipse 3.4 ganymede sca 1.5.1 plugin
> Reporter: Kalpeshkumar Soni
>
> I installed eclipse and installed the tuscany plugin from http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/
> I was able to run the store sample that uses jsonrpc and atom feed as an example
> the atom feed is not working properly
> in the browser i see the items but not correct name or prices
> it does not look like the screen shots posted in http://tuscany.apache.org/getting-started-with-tuscany-using-tuscany-eclipse-plugin.html
when I hit http://localhost:8080/ShoppingCart
> I tried with Firefox 3.5 and IE7
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
atom feed does not work on browsers properly for 1.5.1
------------------------------------------------------
Key: TUSCANY-3390
URL: https://issues.apache.org/jira/browse/TUSCANY-3390
Project: Tuscany
Issue Type: Bug
Components: Java SCA ATOM Binding Extension
Affects Versions: Java-SCA-1.5.1
Environment: windows xp java 1.6 eclipse 3.4 ganymede sca 1.5.1 plugin
Reporter: Kalpeshkumar Soni
I installed eclipse and installed the tuscany plugin from http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/
I was able to run the store sample that uses jsonrpc and atom feed as an example
the atom feed is not working properly
in the browser i see the items but not correct name or prices
it does not look like the screen shots posted in http://tuscany.apache.org/getting-started-with-tuscany-using-tuscany-eclipse-plugin.html
when I hit http://localhost:8080/ShoppingCart
I tried with Firefox 3.5 and IE7
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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" <simonslaws@googlemail.com>
Sent: Wednesday, December 09, 2009 7:09 AM
To: <dev@tuscany.apache.org>; <antelder@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
>>
On Wed, Dec 9, 2009 at 12:59 AM, Simon Laws <simonslaws@googlemail.com> wrote: > Tutorial or demo seems like the right place to me. I would go with > Tutorial given the option. I agree with Simon that it's not a good fit > with samples. > > Simon > Great, +1 for tutorial. -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.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
>
On Wed, Dec 9, 2009 at 2:02 PM, Simon Laws <simonslaws@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
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
On Tue, Dec 8, 2009 at 3:25 PM, Simon Laws <simonslaws@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
On Tue, Dec 8, 2009 at 5:14 AM, Luciano Resende <luckbr1975@gmail.com> wrote: > On Mon, Dec 7, 2009 at 6:01 AM, ant elder <ant.elder@gmail.com> wrote: >> On Sat, Dec 5, 2009 at 1:00 AM, Raymond Feng <enjoyjava@gmail.com> wrote: >>> Hi, >>> >>> I fixed the issue under http://svn.apache.org/viewvc?rev=887470&view=rev. >>> >> >> Thanks that does help get passed this particular problem. >> >>> I also have some local changes that enable the build.xml to run two nodes >>> with different JVMs over tribes based multicast. Do you know if the build >>> machine supports multicast? If so, I can commit the changes. >>> >> >> I'd guess that multicast will work within the one build machine, but >> if it didn't the static routes support we have does work enough to >> support this as there's just two nodes. However, the test isn't really >> good enough at verifying things work yet - if something breaks the >> test will still pass successfully - so there's not a whole lot of >> point having it part of the build until we fix that. I've already >> started looking at adding some better tests as part of all this domain >> work. >> >> Incidentally i'm finding quite a lot of other issues as i use this to >> do with things like the classloaders using by tribes or sca bindings, >> inconsistencies in the endpoint URIs used by all the different pieces, >> particular runtime requirements caused by the way endpoints get >> serialized etc. I'll try to post more on those in separate emails. >> >> ...ant >> > > Where we are with this issue ? Does this happen just when deployed in > the tomcat/tuscany.war environment or is there a way to reproduce this > using some itest (e.g. itest-nodes-two-nodes-two-vms-test) ? If you > guys still have the issue and want some help, I could take a look at > this. > No its not just the tomcat/tuscany.war environment, but there aren't very good or many tests around this area yet, helping write some would be a great place to start :) ...ant
On Wed, Dec 9, 2009 at 8:54 AM, ant elder <ant.elder@gmail.com> wrote: > On Wed, Dec 9, 2009 at 7:37 AM, Ramkumar R <ramkumar.rj@gmail.com> wrote: >> Hi Simon, >> >> Comments inline... >> >>> Not sure if this is important or not. In the implementation invoker we >>> need to set TCCL to the contribution classloader that loaded the >>> implementation class we are about to call. So how to get the >>> contribution and it's classloader for the class we are about to call. >>> The easy way is to get the classloader from the class and set that of >>> course. I don't know if no changes have been made to make this work or >>> that some changes have been made but that something was missed out. >>> >> >> The issue seems to be resolved and the testcase passes, by setting the TCCL >> to the >> classloader that loaded the implementation class we are about to call. >> > > Is that really correct though for what section 10.3 in the spec is > saying? The implementation class doesn't necessarily come from the > containing contribution it could be an imported class, in which case > according to JCI100010 and JCI100011 that would be using be a > different class loader. Not sure what you mean by "containing contribution" here but as I understand it TCCL should reference the class loader that loaded the component implementation class. I.e this is neither just some arbitraty class loader nor is it necessarily the class loader for the contribution that loaded the running composite. > >> But this approach raises few questions in my mind as shown below... >> >> 1. In 1.x code base, we have been using the ContributionClassLoaderProvider >> to set the >> classloader for the contribution, but in 2.x not sure about the reason as >> why decided to >> get away with ContributionClassLoaderProvider. >> > > I'm not sure if i understood this from your 1st email - isnt there a > ClassLoaderModelResolver instance per contribution? And if so what > happens if the ClassLoaderModelResolver instance is set as the TCCL? Not sure precisely what the question is here. >> 2. May be, I am not understanding the big picture as why the specs is so >> keen in >> doing so. What would be the disadvantage if we don't set the TCCL to the >> contribution classloader. >> > > I guess just so there's a consistent and predictable way to use class > loaders and contribution resources across runtimes. And when you are coding in the context of of a component implementation you get a know classloader environment, i.e. the classloader for the class that you are implementing. Simon
Tutorial or demo seems like the right place to me. I would go with Tutorial given the option. I agree with Simon that it's not a good fit with samples. Simon
On Wed, Dec 9, 2009 at 7:37 AM, Ramkumar R <ramkumar.rj@gmail.com> wrote: > Hi Simon, > > Comments inline... > >> Not sure if this is important or not. In the implementation invoker we >> need to set TCCL to the contribution classloader that loaded the >> implementation class we are about to call. So how to get the >> contribution and it's classloader for the class we are about to call. >> The easy way is to get the classloader from the class and set that of >> course. I don't know if no changes have been made to make this work or >> that some changes have been made but that something was missed out. >> > > The issue seems to be resolved and the testcase passes, by setting the TCCL > to the > classloader that loaded the implementation class we are about to call. > Is that really correct though for what section 10.3 in the spec is saying? The implementation class doesn't necessarily come from the containing contribution it could be an imported class, in which case according to JCI100010 and JCI100011 that would be using be a different class loader. > But this approach raises few questions in my mind as shown below... > > 1. In 1.x code base, we have been using the ContributionClassLoaderProvider > to set the > classloader for the contribution, but in 2.x not sure about the reason as > why decided to > get away with ContributionClassLoaderProvider. > I'm not sure if i understood this from your 1st email - isnt there a ClassLoaderModelResolver instance per contribution? And if so what happens if the ClassLoaderModelResolver instance is set as the TCCL? > 2. May be, I am not understanding the big picture as why the specs is so > keen in > doing so. What would be the disadvantage if we don't set the TCCL to the > contribution classloader. > I guess just so there's a consistent and predictable way to use class loaders and contribution resources across runtimes. ...ant
Luciano Resende wrote: > On Tue, Dec 8, 2009 at 9:00 PM, Simon Nash <nash@apache.org> wrote: >> Simon Laws wrote: >>> +1 also would like to see the sample in the 1.x trunk if people are >>> happy to see it added. >>> >>> Simon >>> >>> >> I have added this component to JIRA. >> >> +1 for making the travel sample part of the 1.x trunk. >> > > Where in trunk are you guys thinking to have it ? Under tutorials/travel ? > Anyway, +1 to make it part of trunk. > > Putting this under tutorials/travel makes sense to me. The other option is to put it under samples, but this seems less appropriate because the samples directory currently contains a number of much smaller samples that illustrate specific aspects of SCA rather than how SCA is used in a realistic application. Simon
*Hi Simon,* Comments inline... Not sure if this is important or not. In the implementation invoker we > need to set TCCL to the contribution classloader that loaded the > implementation class we are about to call. So how to get the > contribution and it's classloader for the class we are about to call. > The easy way is to get the classloader from the class and set that of > course. I don't know if no changes have been made to make this work or > that some changes have been made but that something was missed out. > > The issue seems to be resolved and the testcase passes, by setting the TCCL to the classloader that loaded the implementation class we are about to call. But this approach raises few questions in my mind as shown below... 1. In 1.x code base, we have been using the ContributionClassLoaderProvider to set the classloader for the contribution, but in 2.x not sure about the reason as why decided to get away with ContributionClassLoaderProvider. 2. May be, I am not understanding the big picture as why the specs is so keen in doing so. What would be the disadvantage if we don't set the TCCL to the contribution classloader. -- Thanks & Regards, Ramkumar Ramalingam
On Tue, Dec 8, 2009 at 9:00 PM, Simon Nash <nash@apache.org> wrote: > Simon Laws wrote: >> >> +1 also would like to see the sample in the 1.x trunk if people are >> happy to see it added. >> >> Simon >> >> > I have added this component to JIRA. > > +1 for making the travel sample part of the 1.x trunk. > Where in trunk are you guys thinking to have it ? Under tutorials/travel ? Anyway, +1 to make it part of trunk. -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
Simon Laws wrote: > +1 also would like to see the sample in the 1.x trunk if people are > happy to see it added. > > Simon > > I have added this component to JIRA. +1 for making the travel sample part of the 1.x trunk. Simon
[ https://issues.apache.org/jira/browse/TUSCANY-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende updated TUSCANY-3389:
-------------------------------------
Affects Version/s: Java-SCA-Next
Fix Version/s: Java-SCA-Next
Assignee: Luciano Resende
> Tuscany Policies is returning an error code of 401 instead of 403 when an authenticated
user requests a service which is not authorized for their role
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-3389
> URL: https://issues.apache.org/jira/browse/TUSCANY-3389
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Policy
> Affects Versions: Java-SCA-Next
> Environment: WASCE on Mac
> Reporter: Abraham Guerra
> Assignee: Luciano Resende
> Priority: Minor
> Fix For: Java-SCA-Next
>
>
> I defined a secured service and provided authorized roles.
> I authenticated as a user who is not in the appropriate role and requested the above
service.
> Policies returned a 401 error instead of 403
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Tuscany Policies is returning an error code of 401 instead of 403 when an authenticated user
requests a service which is not authorized for their role
------------------------------------------------------------------------------------------------------------------------------------------------------
Key: TUSCANY-3389
URL: https://issues.apache.org/jira/browse/TUSCANY-3389
Project: Tuscany
Issue Type: Bug
Components: Java SCA Policy
Environment: WASCE on Mac
Reporter: Abraham Guerra
Priority: Minor
I defined a secured service and provided authorized roles.
I authenticated as a user who is not in the appropriate role and requested the above service.
Policies returned a 401 error instead of 403
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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 <enjoyjava@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" <antelder@apache.org> > Sent: Tuesday, December 08, 2009 3:40 PM > To: <dev@tuscany.apache.org> > Subject: Re: [2.x] node configuration attributes > >> On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <enjoyjava@gmail.com> wrote: >>> >>> See my comments inline. >>> >>> Thanks, >>> Raymond >>> -------------------------------------------------- >>> From: "ant elder" <antelder@apache.org> >>> Sent: Tuesday, December 08, 2009 2:58 PM >>> To: <dev@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 > >
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" <antelder@apache.org> Sent: Tuesday, December 08, 2009 3:40 PM To: <dev@tuscany.apache.org> Subject: Re: [2.x] node configuration attributes > On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <enjoyjava@gmail.com> wrote: >> See my comments inline. >> >> Thanks, >> Raymond >> -------------------------------------------------- >> From: "ant elder" <antelder@apache.org> >> Sent: Tuesday, December 08, 2009 2:58 PM >> To: <dev@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
On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <enjoyjava@gmail.com> wrote: > See my comments inline. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <antelder@apache.org> > Sent: Tuesday, December 08, 2009 2:58 PM > To: <dev@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
See my comments inline. Thanks, Raymond -------------------------------------------------- From: "ant elder" <antelder@apache.org> Sent: Tuesday, December 08, 2009 2:58 PM To: <dev@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
On Tue, Dec 8, 2009 at 4:06 PM, Raymond Feng <enjoyjava@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
The scenarios you listed look good. You added the matching perspective to what I had for the serialization/deserialization. Case 1: No serialization/deserialization is involved. The matching is based on the local endpoints. Case 2: Remote endpoint descriptions are received from the registry which can be p2p or centralized. It only provides the following information: * The protocol-specific endpoint address (to connect to the target endpoint) * The binding structural URI (to identify the endpoint in the domain hierarchy to resolve @target) * The binding type (to know the binding protocol) * The intents and policySets (to match the policy configurations) Deployment-time matching is limited since the node doesn't have knowledge of the artifacts (interfaces in particular) from the target endpoint. Case 3: A domain manager that serves as: * A repository for contributions that can be used to validate domain-level wirings at deployment time * A a registry to provide endpoint descriptions and policy definitions at runtime Thanks, Raymond -------------------------------------------------- From: "Simon Laws" <simonslaws@googlemail.com> Sent: Tuesday, December 08, 2009 10:15 AM To: <dev@tuscany.apache.org> Subject: Re: [2.x] What information should be serialized with EndpointReference/Endpoint and how to resolve them on the consumer side? > I think we have to take a view on this. Standing back what scenarios > are we trying to support? > > 1/ a single node that matches EPRs within a composite > 2/ a distributed set of nodes that are started independently, have no > central point of control and no ability to match domain level EPRs > other than via the distributed registry > 3/ a distributed set of nodes that are started with reference to a > distributed registry populated by a domain manager > > In 1 the node has all of the contributions/assets it needs to validate > all wires and ensure that EPRs match EPs before the application is > started > > In 2 each node can only validate local wires fully before the app is > started. For EPRs to services running in other nodes we want to > minimize the amount of information used for matching and hence the > amount of information that has to be represented in the registry. I > think the minimum set is as follows (taken from the wiki page) > The protocol-specific endpoint address > The binding structural URI > The binding type > The intents and policySets > > I've missed out interface contracts here because even if we do name > the contract in the registry we won't have the assets local to the EPR > to complete the matching process. We could choose some intermediate > format for the interface contract and pass that but it's extra > complication. The flip side of this is that we may wire remote > references and then find that there is some interface matching issue > at runtime. > > In 3, as in 1, the full set of matching can be performed before the > registry is populated because the domain manager has access to all of > the assets. interface matching errors can therefore be reported before > the nodes are started. > > So can we live with leaving detection of interface miss-matches until > runtime in scenario 2? I think I probably could in the first instance > but it leaves me a little uneasy that there is an inconsistency. > > A subsidiary question related to policy sets. We will provide policy > specific matching code which will need to be present in the EPR node > in order for the match to take place. However we would have to assume > that any resources to which a policy set refers may not be available > for matching based on the point made above. I.e. we can match the XML > but not any referenced resources. > > Simon
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" <simonslaws@googlemail.com> Sent: Tuesday, December 08, 2009 9:59 AM To: <dev@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
I think we have to take a view on this. Standing back what scenarios are we trying to support? 1/ a single node that matches EPRs within a composite 2/ a distributed set of nodes that are started independently, have no central point of control and no ability to match domain level EPRs other than via the distributed registry 3/ a distributed set of nodes that are started with reference to a distributed registry populated by a domain manager In 1 the node has all of the contributions/assets it needs to validate all wires and ensure that EPRs match EPs before the application is started In 2 each node can only validate local wires fully before the app is started. For EPRs to services running in other nodes we want to minimize the amount of information used for matching and hence the amount of information that has to be represented in the registry. I think the minimum set is as follows (taken from the wiki page) The protocol-specific endpoint address The binding structural URI The binding type The intents and policySets I've missed out interface contracts here because even if we do name the contract in the registry we won't have the assets local to the EPR to complete the matching process. We could choose some intermediate format for the interface contract and pass that but it's extra complication. The flip side of this is that we may wire remote references and then find that there is some interface matching issue at runtime. In 3, as in 1, the full set of matching can be performed before the registry is populated because the domain manager has access to all of the assets. interface matching errors can therefore be reported before the nodes are started. So can we live with leaving detection of interface miss-matches until runtime in scenario 2? I think I probably could in the first instance but it leaves me a little uneasy that there is an inconsistency. A subsidiary question related to policy sets. We will provide policy specific matching code which will need to be present in the EPR node in order for the match to take place. However we would have to assume that any resources to which a policy set refers may not be available for matching based on the point made above. I.e. we can match the XML but not any referenced resources. Simon
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
+1 also would like to see the sample in the 1.x trunk if people are happy to see it added. Simon
Thanks Luciano Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Update OASIS SCA Namespace
---------------------------
Key: TUSCANY-3388
URL: https://issues.apache.org/jira/browse/TUSCANY-3388
Project: Tuscany
Issue Type: Bug
Components: OASIS Compliance - TUSCANY
Affects Versions: Java-SCA-2.0
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.0
In last week OASIS Assembly F2F, it was decided that the OASIS SCA Namespace is going to be
changed as described below:
currently:
http://docs.oasis-open.org/ns/opencsa/sca/200903
new:
http://docs.oasis-open.org/ns/opencsa/sca/200912
I'm going to create a JIRA, and work on the necessary changes by end of weekend once the OASIS
schemas get updated.
[1] http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/200912/msg00019.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
In last week OASIS Assembly F2F, it was decided that the OASIS SCA Namespace is going to be changed as described below: currently: http://docs.oasis-open.org/ns/opencsa/sca/200903 new: http://docs.oasis-open.org/ns/opencsa/sca/200912 I'm going to create a JIRA, and work on the necessary changes by end of weekend once the OASIS schemas get updated. [1] http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/200912/msg00019.html -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
On Mon, Dec 7, 2009 at 10:44 PM, Raymond Feng <enjoyjava@gmail.com> wrote: > +1. When it is ready, we can release the travel sample as well. > +1 -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.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" <ant.elder@gmail.com>
Sent: Tuesday, December 08, 2009 5:57 AM
To: <dev@tuscany.apache.org>
Subject: Re: [2.x] node configuration attributes
> On Tue, Dec 8, 2009 at 1:19 PM, Simon Laws <simonslaws@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
> 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
On Tue, Dec 8, 2009 at 2:44 PM, Simon Laws <simonslaws@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
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
On Tue, Dec 8, 2009 at 1:59 PM, Simon Laws <simonslaws@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
Is it possible to specify the domainRegistry via the APi at the moment? Simon
On Tue, Dec 8, 2009 at 1:19 PM, Simon Laws <simonslaws@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