Simon Nash wrote:
Mike Edwards wrote:
Malisetti, Ramanjaneyulu wrote:
Hi,
If Node is created with composite as a string , I mean something like
below. All policy intents are not recognized. I modified “
policy-security-token” itest to load composite as a string, test is
throwing with exception PolicyConfigurationException.
*private* *static* String /composite1 = “xxxxx”;/
/scaNodeFactory/ = SCANodeFactory./newInstance/();
String _contribName1_ = "HelloWorldService" +
"-contribution.xml";
/node/ =
/scaNodeFactory/.createSCANode("HelloWorldService",
/composite1/,*new* SCAContribution("",""));
/node/.start();
Raman,
What do you think that the " new SCAContribution("","") " is
actually doing?
Basically, this says to the Tuscany SCA runtime - create a
Contribution which has no name and where the contents are held at a
null URL location. In other words, this is a non-Contribution.
In SCA, artifacts that are required by Composites that you want to run
are contained in Contributions, which are simply hierarchical
collections of files packaged up in some way - the simplest forms are
either a file system directory and its subdirectories, or else a ZIP
file of the artifacts, again with internal hierarchy through the paths
of each file in the ZIP.
So, in its simplest form, when you create an SCA application using a
Composite file, any artifacts that the composite depends upon (ie uses
somewhere in the composite file) such as a Java class, or the
definition of a Policy Intent or a Policy Set, must be contained
somewhere in the Contribution (or Contributions) that are available to
the SCA runtime.
In your code above, there is no Contribution, so it is not surprising
to find that the SCA runtime fails to resolve things that it needs.
You should create the Contribution class with a real name and a real
URL - the URL pointing either to a ZIP file or to the directory on
disk where your artifacts are kept...
Yours, Mike.
This was my first thought when I saw Raman's post. However I have tried
making this change in the test code that Raman attached to TUSCANY-3569 and
I still see the problem. I have reopened TUSCANY-3569 while I investigate
further.
Simon
I have found and fixed the Tuscany runtime problem, which was caused by an
incorrect order of processing in NodeImpl. See TUSCANY-3569 for more details.
Simon
