Re: Domains, runtimes, components and cardinality

[Venkata Krishnan]

Hi,

I guess it should be a good start to have SCA domains span across runtimes
and leave the runtimes being shared by SCA domains to the next iteration.

As for the second point, is there a possibility of seeing this as
replication of components across two runtimes instead of nodes?  Anyways, to
start with, I'd be happy to leave this out for the next iteration.

Thanks

- Venkat


On 6/18/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Following on from recent discussion on the distributed binding (I've been
putting notes here [1])... In a Tuscany SCA runtime what do we expect the
cardinality between the various parts of it to be?

A domain notionally runs on a runtime. In the case of a stand-alone
Tuscany
SCA runtime this will be a single process (C++ exe, Java VM etc.). In the
case of a distributed Tuscany SCA runtime, the runtime is made up of many
distributed nodes that each run parts of the domain.

1/ Can domains share runtimes/nodes?

I.e can components from more than one domain be running inside a single
Tuscany SCA runtime or is the user expected to start up multiple runtimes
to
run multiple domains.

2/ How many nodes can a single component run on?.

I.e. is the assignment of a component to multiple nodes, for performance,
reliability etc. reasons, explicitly supported as part of the topology
description of a distributed domain. If so then the  SCA binding chooses
which node to use. If not then any distribution of workload is considered
to
be a job for the node implementation.

I'd be interested to hear peoples views on this

My starting point is...

1/ No, we will support multiple domains by starting multiple runtimes. We
could add the extra function to support sharing of runtimes between
domains
in the future if it's found to be required.

2/ We shouldn't restrict whatever structure we use to describe the
component/node association to be 1-1. But we can assume 1 in the first
instance and consider adding more complex node selection features to the
SCA
binding in the future.

Regards

Simon

[1] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=59826

NPE at HelperProvider.getDefaultContext

[scyip12]

I have been trying to use SDO revision 536345 (for the fix for 
http://issues.apache.org/jira/browse/TUSCANY-1250) to generate data objects for 
use with various revisions of SCA, and have been banging my head against wall 
after wall. I decided to take the helloworld-ws sample from the 0.90 release 
and modify it to use SDO databinding as a simple test, and I am getting a 
NullPointerException at HelperProvider.getDefaultContext. I took the wsdl from 
the sample and modified it as per below, pointed the XSD2JavaGenerator (from 
revision 536345) at it to generate the data objects, modified the 
HelloWorldService interface and impls, and added the dbosdo factory=... to the 
composite file. I have attached a zip with my files, which the mailing list 
will strip out, but I can send to anyone who would like to take a look. If 
anyone can give me some directions it would be much appreciated. 


http://helloworld"; 
xmlns="http://www.w3.org/2001/XMLSchema";>

  

  

...

  

  

[jira] Commented: (TUSCANY-1355) DAS-RDB does not support Oracle or SqlServer well

[Adriano Crestani (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506019
 ] 

Adriano Crestani commented on TUSCANY-1355:
---

Hi, 

DAS supports Oracle, but when on your code you create a DAS not specifying a 
config file, it, by default, tries to retrieve the tables' metadata using JDBC. 
However, Oracle JDBC Driver does not provide all metadata necessary to build 
the graph.

To solve this issue, you should define a resultset descriptor as explained on 
this page: 
http://incubator.apache.org/tuscany/explicit-resultset-shape-definition.html

> DAS-RDB does not support Oracle or SqlServer well
> -
>
> Key: TUSCANY-1355
> URL: https://issues.apache.org/jira/browse/TUSCANY-1355
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-M2
> Environment: DAS-RDB to access the database of Oracle
>Reporter: wangful
>
> I have used the following simple codes to use DAS to access an Oracle 
> database.
>   //String url = 
> "jdbc:db2j:D:/RAD6/runtimes/base_v6/cloudscape/DAS";
>   String url = "jdbc:oracle:thin:wcs/wcs1@//raptor08:1521/g10";
>   String query = "select * from MYCUSTOMER";
>   String query_result="";
>   Connection conn = null;
>   //  Class.forName("com.ibm.db2j.jdbc.DB2jDriver").newInstance();
>   DriverManager.registerDriver(new 
> oracle.jdbc.driver.OracleDriver());
>   conn = DriverManager.getConnection(url);
>   conn.setAutoCommit(false);
>DAS das = 
> DAS.FACTORY.createDAS(conn);
>   Command readStores = das.createCommand(query);
>   DataObject root = (DataObject)readStores.executeQuery();
>   DataObject cus1 = root.getDataObject("MYCUSTOMER[1]");
>   
>   System.out.println(root.getInt("MYCUSTOMER[1]/ID"));
>   System.out.println(root.getString("MYCUSTOMER[1]/NAME"));
> It will caused the following error: 
> Exception in thread "main" java.lang.IllegalArgumentException: Class 
> 'DataGraphRoot' does not have a feature named 'MYCUSTOMER'
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1804)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2367)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getProperty(DataObjectImpl.java:1287)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2054)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2161)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1940)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1860)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:744)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326)
>   at TestDAS.main(TestDAS.java:47)
> But the same code and same config will work well for  cloudscape database.
> There are also some other problems for Oracle, seems DAS can't work for 
> oracle.
> Will someone look into this problem?
> Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1355) DAS-RDB does not support Oracle or SqlServer well

[wangful (JIRA)]

DAS-RDB does not support Oracle or SqlServer well
-

 Key: TUSCANY-1355
 URL: https://issues.apache.org/jira/browse/TUSCANY-1355
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-M2
 Environment: DAS-RDB to access the database of Oracle
Reporter: wangful


I have used the following simple codes to use DAS to access an Oracle database.

//String url = 
"jdbc:db2j:D:/RAD6/runtimes/base_v6/cloudscape/DAS";
String url = "jdbc:oracle:thin:wcs/wcs1@//raptor08:1521/g10";
String query = "select * from MYCUSTOMER";
String query_result="";
Connection conn = null;
//  Class.forName("com.ibm.db2j.jdbc.DB2jDriver").newInstance();

DriverManager.registerDriver(new 
oracle.jdbc.driver.OracleDriver());

conn = DriverManager.getConnection(url);
conn.setAutoCommit(false);

   DAS das = 
DAS.FACTORY.createDAS(conn);

Command readStores = das.createCommand(query);
DataObject root = (DataObject)readStores.executeQuery();



DataObject cus1 = root.getDataObject("MYCUSTOMER[1]");

System.out.println(root.getInt("MYCUSTOMER[1]/ID"));
System.out.println(root.getString("MYCUSTOMER[1]/NAME"));

It will caused the following error: 

Exception in thread "main" java.lang.IllegalArgumentException: Class 
'DataGraphRoot' does not have a feature named 'MYCUSTOMER'
at 
org.apache.tuscany.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1804)
at 
org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2367)
at 
org.apache.tuscany.sdo.impl.DataObjectImpl.getProperty(DataObjectImpl.java:1287)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2054)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2161)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1940)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1860)
at 
org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:744)
at 
org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216)
at 
org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326)
at TestDAS.main(TestDAS.java:47)

But the same code and same config will work well for  cloudscape database.

There are also some other problems for Oracle, seems DAS can't work for oracle.

Will someone look into this problem?

Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Component Property Definition - resolving 'file' attribute

[Jean-Sebastien Delfino]

Luciano Resende wrote:

Would we also need to post process the contribution to check for
unresolved references ? I'm guessing that, file references outside
from the contribution scope will always be on the unresolved status
,and would need further processing.

On 5/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

Venkata Krishnan wrote:
> Hi,
>
> The property value definition for a component can have an attribute 
named

> 'file' that points to a xml file that might contain the value for a
> property. The question is - now that the contribution service is in 
shape

> must it be used to resolve this file as well just like all other
> artifacts.
> If so could somebody please provide some pointers on how to do this.
> Thanks
>
> - Venkat
>

I think it would be a good idea to use it, this would require a simple
change to our ArtifactResolver implementation to support something like
a FileReference object, similar to what we've done for classes with
ClassReference, but we probably also need to confirm what the SCA
assembly spec actually means by:
<<<
287 - file (optional) – a dereferencable URI to a file containing a
value for the property
 >>>

In particular:
- foo/bar.xml - is foo/bar.xml relative to the current SCA contribution?
or the referencing composite file?
- /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
SCA contribution?
- http://foo.org/bar - is this allowed?

--
Jean-Sebastien




In revision r548560 I have added support for resolution of contribution 
DeployedArtifacts.


To resolve an artifact, you simple need to create a DeployedArtifact - 
see ContributionFactory.createDeployedArtifact() -, set it's URI to the 
URI of the artifact inside the SCA contribution, then call 
ModelResolver.resolve(theDeployedArtifact). You'll get back the 
populated/initialized DeployedArtifact, containing its absolute location 
and the model that was read from it, if any.


This can be used to resolve files used to configure properties and 
implementation files as well.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Domains, runtimes, components and cardinality

[Raymond Feng]

Hi,

Please see my comments inline below.

Thanks,
Raymond

- Original Message - 
From: "Simon Laws" <[EMAIL PROTECTED]>

To: "tuscany-dev" 
Sent: Monday, June 18, 2007 5:25 AM
Subject: Domains, runtimes, components and cardinality



Following on from recent discussion on the distributed binding (I've been
putting notes here [1])... In a Tuscany SCA runtime what do we expect the
cardinality between the various parts of it to be?

A domain notionally runs on a runtime. In the case of a stand-alone 
Tuscany

SCA runtime this will be a single process (C++ exe, Java VM etc.). In the
case of a distributed Tuscany SCA runtime, the runtime is made up of many
distributed nodes that each run parts of the domain.

1/ Can domains share runtimes/nodes?

I.e can components from more than one domain be running inside a single
Tuscany SCA runtime or is the user expected to start up multiple runtimes 
to

run multiple domains.


I think a single Tuscany SCA runtime can only join one SCA domain. For a 
single machine (node), we can have multiple runtimes. These runtimes will 
have to share the resources, for example, using different ports for the http 
protocol. I'm not sure if we need to have the node

concept between the SCA domain and runtime.



2/ How many nodes can a single component run on?.

I.e. is the assignment of a component to multiple nodes, for performance,
reliability etc. reasons, explicitly supported as part of the topology
description of a distributed domain. If so then the  SCA binding chooses
which node to use. If not then any distribution of workload is considered 
to

be a job for the node implementation.


We might have different cases here:
1) For load-balancing, we can assign a component to multiple runtimes
2) For a singleton service, we may have to assign it to a single runtime (a 
backup runtime can be picked for HA).




I'd be interested to hear peoples views on this

My starting point is...

1/ No, we will support multiple domains by starting multiple runtimes. We
could add the extra function to support sharing of runtimes between 
domains

in the future if it's found to be required.

2/ We shouldn't restrict whatever structure we use to describe the
component/node association to be 1-1. But we can assume 1 in the first
instance and consider adding more complex node selection features to the 
SCA

binding in the future.

Regards

Simon

[1] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=59826




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Changing default Tomcat and Jetty ports to 8080, was: Automated nightly builds

[Jean-Sebastien Delfino]

Luciano Resende wrote:

I have changed all ports to 8085 and all the builds are working now on
the apache machine [1]. I'll add a page to our Wiki describing how you
can watch the results, I'll also configure the builds to send failure
notification to the dev-list. I still have a todo to investigate the
usage of the binary created on the build.

[1] http://vmbuild.apache.org:8080/continuum/servlet/continuum



While working on some improvements of the Jetty and Tomcat embedded 
servers, I noticed that they now use port 8085 by default instead of 
8080. I thought we were going to change all the test case artifacts to 
use 8085, but not actually make 8085 the default port in the Tuscany Web 
Server runtime integration.


I changed the defaults in TomcatServer and JettyServer to 8080, which is 
a widely used default for Tomcat, Jetty, and most server targeting tools 
and went through all the remaining test cases that didn't specify a port 
to specify 8085 in the test case artifacts.


I also ran a build with port 8080 being used by another process on my 
machine to verify that there's no remaining test case using 8080. It 
worked, so it should work as well on the Confluence build machine.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Supporting callbacks across Web Services

[Simon Nash]

In my investigations into TUSCANY-1341, I'have fixed a few minor
blocking defects (see my updates to the JIRA) and I'm now getting
to the heart of the problem.  I think the right approach is to do
this in a similar way to callbacks over direct local wires, with
the forward call proceeding as normal and a callback proxy being
injected on the service side to make a reverse call back to the
client instance using the same Web services connection thar was
used for the forward call from client to server.  This isn't the
approach used by the current code.

So far I have got this path working as far as the attempt to call
back using the service's proxy.  The code to inject this proxy
isn't working properly yet.

I'm not yet sure how callbacks should be mapped to the protocol
used by the Web services connection.  There need to be standard
mappings for this, or SCA callbacks won't interoperate with
non-SCA Web service endpoints.  I'm hoping Axis2 provides a way
to call back from a server to a client over an already established
connection, but I haven't looked into this in detail yet.

I'm hoping my fix will support callback from both two-way methods
and one-way methods.  (The spec seems to imply that both of these
are valid.)  The two-way case seems harder because the callback
invocation will be sent back on the wire before the forward
invocation has returned its response message.  If it's too hard
to do this, I may back off and only support callbacks from
one-way methods for now.  This seems to present challenges as well,
because I'm not sure whether the connection is guaranteed to
remain active after the one-way call has been made and the server
method is running.

Before I go further down this path, I would welcome any comments
on the above issues and whether my basic approach is sound.

  Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Finding the .componentType file

[Mike Edwards]

Ant,

Yes, sometimes the terminology can get confusing.




The component name may be nothing like the implementation name


How does that fit with the spec saying - ""A component type file has the
same name as the implementation file but has the extension 
".componentType""

? I'm looking for a way to make the default case easy, it doesn't have to
deal with every edge case.



Unfortunately, this is no edge case.  There is no reason to expect the 
component name to be even close to the implementation name.




The componentType file is really to be thought of as an extension of the


implementation for those (hopefully few) cases where introspection of
the implementation cannot provide the required information.




Maybe "implementationType" would have been be a better name :-)



One name that we dearly wanted for "componentType" was 
"implementationInfo".  We tried hard to get that name but failed.  That 
alternative makes it clearer that the file contains metadata about the 
implementation.



Yours,  Mike.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1341) Callback over WS Binding is not functioning various issues

[Simon Nash (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505967
 ] 

Simon Nash commented on TUSCANY-1341:
-

I have more news on problem (3).  Further testing has shown that my workaround 
of changing the WSDL (not SCDL - sorry for my confusion) isn't the right 
solution.  The WSDL changes I made to get around problem (3) caused other 
problems and I had to reverse them and add a fix for problem (3).  The problems 
caused by the WSDL changes were:
 a) for a two-way method, removing the wsdl:output element from wsdl:operation 
causes an Axis2 error because Axis2 thinks the method is one-way and isn't 
expecting a response.
 b) removing the wsdl:part from wsdl:message causes the WSDL to become 
unwrapped instead of wrapped.  This causes a problem when 
Input2InputTransformer.transform() is called during service invocation because 
the source/target combination changes from wrapped/unwrapped (which works) to 
unwrapped/unwrapped (which doesn't work).

So I fixed problem (3) by changing 
DataBindingRuntimeWireProcessor.isTransformationRequired(DataType, DataType) to 
return false if either source or target are null.

> Callback over WS Binding is not functioning various issues
> --
>
> Key: TUSCANY-1341
> URL: https://issues.apache.org/jira/browse/TUSCANY-1341
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Misc Binding Extensions
>Affects Versions: Java-SCA-0.90
>Reporter: Lou Amodeo
>
> The callback function using WS bindings doesnt appear to be operation.  So 
> far I have :
> 1) WebServiceBindingProcessor.java 
> -  The resolve() method does not setup the callbackInterface on its 
> InterfaceContract resulting in NPE.
> (i.e. interfaceContract.setCallbackInterface(wsdlCallbackInterface); )
> [6/11/07 13:33:02:220 EDT] 0025 SystemOut O   ... 87 more
> [6/11/07 13:33:02:220 EDT] 0025 SystemOut O Caused by: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(InterfaceContractMapperImpl.java:246)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:337)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:269)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:580)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addComposite(EmbeddedSCADomain.java:124)
>   at 
> com.ibm.ws.sca2.tuscany.util.TuscanyInterfaceImpl.startModule(TuscanyInterfaceImpl.java:223)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:82)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:366)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.stateChanged(SCARuntimeImpl.java:286)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.stateChanged(ApplicationMgrImpl.java:1264)
>   at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectEvent(DeployedApplicationImpl.java:1112)
>   at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.setState(DeployedModuleImpl.java:206)
>   at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:566)
>   at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:814)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:965)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl$1.run(ApplicationMgrImpl.java:1495)
>   at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:3924)
>   at 
> com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:4001)
>   at 
> com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:245)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1500)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at sun.reflect.

[jira] Created: (TUSCANY-1354) SCADomain. getService () should follow CompositeContext.getService() conventions for "service-name"

[Kevin Williams (JIRA)]

SCADomain. getService () should follow CompositeContext.getService() 
conventions for "service-name"
---

 Key: TUSCANY-1354
 URL: https://issues.apache.org/jira/browse/TUSCANY-1354
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-M2
Reporter: Kevin Williams
 Fix For: Java-SCA-Next


The current SCADomain method

"public abstract  B getService(Class businessInterface, String 
serviceName);"

is similar in purpose to the .95 specification for 
CompositeContext.locateService API.  For this reason, the new API should follow 
the conventions established of the old API.

This is from the .95 specification:

public interface CompositeContext {
...
T locateService(Class serviceType, String serviceName);
}

"serviceName" can take on one of the following forms:
/
If the service-name is not provided, the name of the serviceType sans package 
name will be used as the service-name

The current implementation getService ends up in the following code:

 public  ServiceReference getServiceReference(Class businessInterface, 
String name) {

// Extract the component name
String componentName;
String serviceName;
int i = name.indexOf('/');
if (i != -1) {
componentName = name.substring(0, i);
serviceName = name.substring(i + 1);

} else {
componentName = name;
serviceName = null;
}

It seems that the "else" should default serviceName to 
businessInterface.getSimpleName() in order to follow the existing convention.

A test case will follow shortly.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SCA Continuum build failure (resource issue)

[Simon Laws]

Hi Luciano

Thinking back, when I originally started bringing the JMS binding back to
life I used ActiveMQ 4.1.0  and was getting errors something like this. The
error doesn't occur at 4.2 so I didn't look at it very closely. 4.2 is only
a snapshot though so not very helpful yet. If it's causing problems with the
continuum build I could take a closer look at 4.1.?.

Simon

[jira] Created: (TUSCANY-1353) Exception attempting to insert rows using DAS w/BEA WebLogic Sybase JDBC driver (BEA WebLogic 8.1 SP6)

[Ron Gavlin (JIRA)]

Exception attempting to insert rows using DAS w/BEA WebLogic Sybase JDBC driver 
(BEA WebLogic 8.1 SP6)
--

 Key: TUSCANY-1353
 URL: https://issues.apache.org/jira/browse/TUSCANY-1353
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-DAS-M2
 Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, WebLogic Sybase 
JDBC driver
Reporter: Ron Gavlin
Priority: Critical


Greetings,

I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic 
Sybase JDBC driver (BEA WebLogic 8.1 SP6). The code below generates the 
following stacktrace:

...
Command insert = das.createCommand("insert into Test (testCol1, testCol2) 
values (?, ?)");
insert.setParameter(1, "str1");
insert.setParameter(2, "str2");
insert.execute();

Stacktrace:

Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected.
at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source)
at weblogic.jdbc.base.BaseException.getException(Unknown Source)
at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source)
at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source)
at 
weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159)
at 
org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173)
at 
org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133)

at 
org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44)



While interactively debugging 
org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String 
queryString, String[] returnKeys), I noticed if I manually change the boolean 
member variable useGetGeneratedKeys to false, no exception is generated and the 
insert works as designed. What is the correct fix here?

- Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PackageNotFoundException

[scyip12]

Thanks for the quick reply. I actually found out from the developer who rebuilt 
the generator that some other updates to the SDO jars were necessary, 
afterwhich the PackageNotFoundException disappeared. I am now getting a NPE 
which I think may be related to the issue 
https://issues.apache.org/jira/browse/TUSCANY-1299 , so I will download a later 
revision and try again. 


- Original Message 
From: kelvin goodson <[EMAIL PROTECTED]>
To: tuscany-dev@ws.apache.org
Sent: Monday, June 18, 2007 11:01:47 AM
Subject: Re: PackageNotFoundException


Hi,
  could you please help me be sure I've got this right. Do I understand
correctly that you
1) encountered the problem as described in TUSCANY-1250 (which didn't make
it into the beta1 release)
2) Rebuilt the generator to include the fix for 1250
3) following this,  having regenerated your classes with the rebuilt
generator you then try to use them and you get a PackageNotFoundException?

I need more detail to have a chance of diagnosing the issue. Could you
please post a test case which exhibits the problem?  Please include the
schema, generated classes, and a list of any options you use to generate the
classes. Attachments will be stripped from emails to the list, so if you
could cc me directly that will help.  Could you also tell me the details of
the source you are using, i.e. did you do an svn extract and if so what
revision level, or did you patch up the beta1 source distribution.

Regards, Kelvin.

On 18/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I am trying to migrate from Tuscany M2 to 0.90 (and SDO 1.0 beta 1) and I
> am encountering a "PackageNotFoundException: Package with uri
> 'http://' not found. (http:///temp.xml, 4,
> 62)". I had to get a later version of the SDO generator to get around the
> bug: http://issues.apache.org/jira/browse/TUSCANY-1250 and regenerate my
> data objects, so I'm not sure if anyone else has encountered this problem
> yet. Any ideas or help around the above exception would be much appreciated.

binding.sca

[Simon Laws]

The sca binding that I use in the distributed runtime has a few more
features than the one provided in assembly/core. I'd like to keep this
function separate from what has gone before. Any objections to me creating

binding-sca
or even
binding-sca-distributed

As an aside I also have a small number of new/extended runtime and domain
classes to check in.  They are a bit of a strange set of things that I
needed to create to see how it could fit together. I'm going to put them in
a module called "distributed" unless anyone objects. Once I have it working
better we can shuffle/refactor code as people see fit. It maybe that some of
then can be replaced if people have better ways of doing things.

Regards

Simon

Re: SCA Continuum build failure (resource issue)

[Jean-Sebastien Delfino]

Luciano Resende wrote:

Our continuum build is failing with some resource utilization issues :

INFO: ActiveMQ Message Broker (localhost,
ID:vmbuild.apache.org-53376-1181958568786-1:0) is shutting down
Jun 15, 2007 6:49:45 PM org.apache.activemq.ActiveMQConnection 
onAsyncException

WARNING: Async exception with no exception listener: java.io.EOFException
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:358)
at 
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:267) 

at 
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:156) 

at 
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)

at java.lang.Thread.run(Thread.java:595)
Jun 15, 2007 6:49:45 PM org.apache.activemq.broker.TransportConnector 
stop

INFO: Connector tcp://vmbuild.apache.org:61616 Stopped


This is probably a similar issue as the default http port, or a access
control issue.
Could someone with more experience with ActiveMQ help on this issue ?



I am seeing the same exception when I build but it doesn't cause a build 
failure on my machine. ActiveMQ complains about an EOF exception when it 
shuts down, but it looked benign to me. Does it actually break the build 
on the continuum machine?


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Finding the .componentType file

[Jean-Sebastien Delfino]

ant elder wrote:

On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:



The component name may be nothing like the implementation name


How does that fit with the spec saying - ""A component type file has the
same name as the implementation file but has the extension 
".componentType""

? I'm looking for a way to make the default case easy, it doesn't have to
deal with every edge case.


Here's an example:
component name: CalculatorServiceComponent
implementation class: calculator.CalculatorImpl
implementation file: src/main/java/calculator/CalculatorImpl.java
componentType file: 
src/main/resources/calculator/CalculatorImpl.componentType


another one:
component name: CalculatorServiceComponent
implementation class: calculator.CalculatorImpl$AnotherImpl
implementation file: calculator.CalculatorImpl.java
componentType file suggestion: 
src/main/resources/calculator/CalculatorImpl.AnotherImpl.componentType


a third one with two components:
component 1 name: CalculatorServiceComponent
component 2 name: AnotherCalculatorComponent
implementation class: calculator.CalculatorImpl
implementation file: src/main/java/calculator/CalculatorImpl.java
componentType file: 
src/main/resources/calculator/CalculatorImpl.componentType


This shows that:
- the component type file path cannot always be automatically derived 
from the implementation file without implementation specific logic
- the component type file  path cannot be derived from the component 
name at all




The componentType file is really to be thought of as an extension of the

implementation for those (hopefully few) cases where introspection of
the implementation cannot provide the required information.



Maybe "implementationType" would have been be a better name :-)


Here's my understanding of the relationships between component, 
component type, implementation and implementation type:

- componentType describes a type of component
- implementation is a concrete representation of a component type
- a componentType describes an implementation
- a component is an instance of a component type
- implementation type characterizes a type of implementation, a 
programming language or technology, "java", "bpel", "script" for example.




My suggestion is that the SPI should put the burden on the

implementation module - for example a special method on the
xxxImplementation class with a name like "locateComponentTypeFile".
Actual loading of the componenttype file can be generic, but finding the
file is definitely a job for the implementation-handling code.




Implementation.getURI() already exists and seems the right method for this.



The problem with this is some don't want the simple xxxImplementation 
class

to even be implementing any interface


Making more difficult to replace these classes by others.



so ideally as much generic function
would be built in the runtime, and thats what I'm trying to find a way of
doing.

I was wondering if the contribution service could help here. It could
discover all the .componentType files in a contribution making their 
names

available,


Doesn't it do it already?


the values of all the attributes of the xxxImplementation class
are also known so it could compare  all the attribute values against 
all the
found .componentType file names ignoring the file extension and when 
there's

a match thats the .componentType for the implementation. How does that
sound?

   ...ant



It sounds unpredictable :)

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 0.91 release?

[Luciano Resende]

Sorry, I'm having some restricted internet access as I'm traveling
since last week... that's probably why we haven't created a DAS
release candidate yet... but the community and I think that we are
ready to have one.

Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
following items:
  - implementation.das
  - implementation.data
  - some samples (maybe including the samples we didn't ship in 0.9)

On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:

What will be the relationship between SCA 0.91 and DAS?  I have seen
some discussions on the list about a DAS release.  Will SCA 0.91 have
this DAS release as a dependency?

   Simon

Luciano Resende wrote:

> I have updated the wiki [1] page with things that I'm working on, and
> would like to have in 0.91 .
>
> As for the implementation.das question regarding it's canned derby db,
> we recently created a db utility to create and populate the database,
> and I have plans to integrate with it.
>
> [1]
> 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
>
>
> On 6/16/07, ant elder <[EMAIL PROTECTED]> wrote:
>
>> Wow 571 license problems! after being clean for 0.90 just a month ago.
>>
>> One question this brings up is what is actually intended to be
>> included in
>> 0.91? There's been quite a few new extensions and demo's etc added
>> recently
>> but no one has said they want those included in 0.91. Should they be by
>> default or should we just include things that are mentioned on the
>> release
>> wiki page? If so anyone else care to help clean things up, add missing
>> license headers, check the distribution works and includes
>> dependencies etc?
>> The implementation.das is including an entire database in the src, is
>> there
>> any way that could be generated by the tests?
>>
>>...ant
>>
>> On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>> >
>> > Thanks Ant.  So could we all please use this wiki page to put down
>> things
>> > that are going to be increments over 0.90.
>> >
>> > Also I run the RAT on the trunk - just java/sca and here is the
>> report.  I
>> > intend to go and fix the missing headers just ahead of cutting the
>> branch.
>> > Before that if anybody would like to jump in and help with this,
>> please feel
>> > free do so.
>> >
>> >
>> 
http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt
>>
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> > On 6/14/07, ant elder <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Taking a branch around the 20th sounds ok to me.
>> > >
>> > > The high level things I'm focusing on for the 0.91 release are:
>> > >
>> > > - Simplification of using script components (working without
>> > > .componentType
>> > > side files)
>> > > - First cut of the simpler binding/implementation SPI
>> > > - clean up of ajax and jsonrpc bindings
>> > > - The EJB binding
>> > >
>> > > I'd also said to someone on the user list I'd get WS services without
>> > > wsdl
>> > > working so will try to do that as well.
>> > >
>> > > Most of the code for those is close-ish to being done, though there's
>> > > still
>> > > a whole lot of related sample work to get done.
>> > >
>> > > I'd started a wiki page for 0.91 at
>> > >
>> > >
>> 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
>>
>> > >
>> > >...ant
>> > >
>> > > On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > Thanks for the faith and encouragement.  This is going to be my
>> first
>> > > > experience and I am sure of getting all the help from you folks to
>> > > pull
>> > > > this
>> > > > off successfully.
>> > > >
>> > > > So, to start with, I propose to cut a branch around June 20th,
>> > > 2007.  If
>> > > > people are ok with this, then all that we'd like to be a part of
>> > > 0.91should
>> > > > get in by then (June 20th, 2007).  Does that work fine with
>> everybody?
>> > > >
>> > > > Also, I'd also like to list down the significant additions /
>> > > enhancements
>> > > > over 0.90 for the Release Notes.  You can state the item here on
>> this
>> > > > thread
>> > > > and I will take care of recording it.
>> > > >
>> > > > - Venkat
>> > > >
>> > > > On 6/13/07, Simon Nash < [EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > +1 from me too.  I'm sure Venkat will do a fine job.
>> > > > >
>> > > > >Simon
>> > > > >
>> > > > > Jean-Sebastien Delfino wrote:
>> > > > >
>> > > > > > Simon Laws wrote:
>> > > > > >
>> > > > > >> Yeah, Venkat did loads on the last release. +1 from me for
>> Venkat
>> > > as
>> > > > > >> 0.91 RM
>> > > > > >>
>> > > > > >> Simon
>> > > > > >>
>> > > > > >
>> > > > > > +1 from me
>> > > > > >
>> > > > > >



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com

Re: PackageNotFoundException

[kelvin goodson]

Hi,
 could you please help me be sure I've got this right. Do I understand
correctly that you
1) encountered the problem as described in TUSCANY-1250 (which didn't make
it into the beta1 release)
2) Rebuilt the generator to include the fix for 1250
3) following this,  having regenerated your classes with the rebuilt
generator you then try to use them and you get a PackageNotFoundException?

I need more detail to have a chance of diagnosing the issue. Could you
please post a test case which exhibits the problem?  Please include the
schema, generated classes, and a list of any options you use to generate the
classes. Attachments will be stripped from emails to the list, so if you
could cc me directly that will help.  Could you also tell me the details of
the source you are using, i.e. did you do an svn extract and if so what
revision level, or did you patch up the beta1 source distribution.

Regards, Kelvin.

On 18/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


I am trying to migrate from Tuscany M2 to 0.90 (and SDO 1.0 beta 1) and I
am encountering a "PackageNotFoundException: Package with uri
'http://' not found. (http:///temp.xml, 4,
62)". I had to get a later version of the SDO generator to get around the
bug: http://issues.apache.org/jira/browse/TUSCANY-1250 and regenerate my
data objects, so I'm not sure if anyone else has encountered this problem
yet. Any ideas or help around the above exception would be much appreciated.

Re: Policy Framework Impl. in Tuscany

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Hi,

I am keen on adding further to the Policy support thats in Tuscany 
today. I
recently run thro the Policy Framework specs and was looking into 
Tuscany on

how far we had gone on this.  Here's my understanding of all that.  I
request people's perspective on my understanding before I go ahead and
implement things.

1.  Policy intents and PolicySets are things that can be defined at the
domain level.  I propose we have Policy Registry or Repository that hosts
the set of all intents and policy sets that pertain to a domain.


+1 but I think we could start with something simpler than a repository, 
simply a model for definitions.xml, and a reader for this file.




2. There can be a PolicyRegistryService that can provide interfaces to 
add,

retrieve and remove intents and policies to the Policy Registry /
Repository.


+1



3. The set of intents and policy sets for a domain could be defined in 
the
definitions.xml file which could be picked up by the 
ContributionsProcessor
(see line 2490 of Assembly Model Spec).  Infact there is more - such 
as the
intents that are supported by binding and implementation types in the 
domain
and so on.  We could have a processor for the sca definitions that 
will read
among other artifacts the policy intents and policy sets and add them 
to the
registry.  The model objects to represent policy intents and policy 
sets and

the factory to create them are already in place under the policy module.



Policy administration is independent of SCA contributions. How about a 
new policy-xml module for the code that will read definitions.xml, 
independent of the ContributionProcessor?



4. SCA artifacts will have intents and policy sets attached to them.
Presently the artifact processors create the Intents and PolicySet 
objects.

I propose that the artifact processor that read these SCA Artifacts will
just about read the QNames and resolve them in the resolution phase 
with the
help of the PolicyRegistryService.  This way we can also check if the 
intent
or policy set specified for an artifact is really applicable to the 
artifact

or not.



Intents need to be resolved to point to the intents defined in 
definitions.xml in ArtifactProcessor.resolve(). I'd suggest to adopt to 
the same approach as for all other objects that need to be resolved:

1. read creates an Intent / PolicySet with unresolved = true
2. resolve replaces it with the resolved Intent / PolicySet

5. Loading of PolicySet could get a bit deeper since there is 
extensibility

that is allowed on the policy language that could be used.  But I guess
WS-Policy will need to be supported for by Tuscany as that is view to 
be a

common thing that could be used

So thats a summary the loading part.

In the building phase there are algorithms that the Policy Framework 
Specs

has specified to validate the wiring between components in the context of
policies (including each end of the wire could inherit from ancestor
artifacts and what is the binding or implementation type being used 
and what

that supports inherently).

Finally during runtime we have to make sure that the policy statements 
are

handed out to the appropriate QoS infrastructures i.e Security or
Transaction support modules so that they may be enforced.  I am a bit
unclear on the options related to this at the present moment.

Before I get to a discussion on the wiring and runtime aspects related to
policy I wish to know if my thoughts are in the right direction this far.


Yes, this sounds good to me. I'd suggest to start small with:
- reading of definitions.xml
- completing the Policy Intent and PolicySet models
- starting with a a real Policy implementation, like Security, to help 
drive the design and implementation with a concrete use case.




Thanks

- Venkat


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

PackageNotFoundException

[scyip12]

I am trying to migrate from Tuscany M2 to 0.90 (and SDO 1.0 beta 1) and I am 
encountering a "PackageNotFoundException: Package with uri 'http://' not found. (http:///temp.xml, 4, 62)". I had to get a later 
version of the SDO generator to get around the bug: 
http://issues.apache.org/jira/browse/TUSCANY-1250 and regenerate my data 
objects, so I'm not sure if anyone else has encountered this problem yet. Any 
ideas or help around the above exception would be much appreciated.

Re: [CTS] Removing namespace prefix assumptions from tests

[kelvin goodson]

Thanks ant,  it would indeed appear to be a BSD license.  Here's the
breadcrumb trail that, along with Ant's note, gives me the confidence to
feel that it's ok to go ahead with this -- the apache page [1] is forwarded
to [2] and [2] contains the section  "Category A: Authorized Licenses",
which contains a link to [3].

Kelvin.

[1] http://www.apache.org/legal/3party.html
[2] http://people.apache.org/~cliffs/3party.html
[3] http://opensource.org/licenses/bsd-license.php

On 18/06/07, ant elder <[EMAIL PROTECTED]> wrote:


Its just a BSD license isn't it? And so fine to use. Infact we did at one
point use Xmlunit in some of the SCA WS testcases, not sure if thats still
the case. I'd say just go ahead and use it if it does what you need.

   ...ant

On 6/18/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> Andy,  to my eye the license looks OK, BUT, I'm not a lawyer and I can't
> speak for the ASF.  I see that there is an Apache project providing tags
> for
> xmlunit [1], so that would give me a warm feeling,  but looking in their
> distribution artifacts, they don't redistribute XMLUnit and therefore
> don't
> have the requirement to republish the XMLUnit license.
>
> I think we need  to send a notice to [EMAIL PROTECTED] to check this out.
> Would you be happy to do that? If you are, it would probably be worth
> copying the Incubator Project Management Committee (IPMC) at
> [EMAIL PROTECTED]
>
> Regards, Kelvin.
>
> [1] http://jakarta.apache.org/commons/jelly/libs/xmlunit/index.html
>
> On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> >
> > XMLUnit does look like it would provide value.
> >
> > They have a proprietary license, pasted below. If you think this
license
> > would allow us to use it within the CTS then I'd be happy to spend
some
> > time
> > investigating this further.
> >
> > Thanks,
> >
> > Andy.
> >
> > /*
> > **
> > Copyright (c) 2001-2007, Jeff Martin, Tim Bacon
> > All rights reserved.
> >
> > Redistribution and use in source and binary forms, with or without
> > modification, are permitted provided that the following conditions
> > are met:
> >
> > * Redistributions of source code must retain the above copyright
> >   notice, this list of conditions and the following disclaimer.
> > * Redistributions in binary form must reproduce the above
> >   copyright notice, this list of conditions and the following
> >   disclaimer in the documentation and/or other materials provided
> >   with the distribution.
> > * Neither the name of the xmlunit.sourceforge.net nor the names
> >   of its contributors may be used to endorse or promote products
> >   derived from this software without specific prior written
> >   permission.
> >
> > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> > FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> > COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> > INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> > BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> > LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
> > ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> > POSSIBILITY OF SUCH DAMAGE.
> >
> > **
> > */
> >
> >
> >
> >
> >
> > -Original Message-
> > From: kelvin goodson [mailto:[EMAIL PROTECTED]
> > Sent: 18 June 2007 11:38
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [CTS] Removing namespace prefix assumptions from tests
> >
> > Hi Andy,
> >   http://issues.apache.org/jira/browse/TUSCANY-1263 has a comment in
it
> > from
> > Lionel Villard ...
> >
> > "FYI, it exists an open source tool for comparing XML files:
> > http://xmlunit.sourceforge.net/ , I haven't tried it"
> >
> > I had been hoping to take a look at this, from both the technical and
> the
> > license aspects, but I haven't had the time yet.  This may be a better
> way
> > to fix all these issues.  If no-one has the bandwidth to look at this,
> > perhaps there's scope for tactical fixes such as that in your patch
that
> > would be superceded by the xmlunit dependency or the like.
> >
> > Regards, Kelvin.
> >
> >
> >
> > On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> > >
> > > XMLHelperTest.testDefineTypes() fails if an implementation does not
> > > specifically use the "customer" namespace prefix when serializing a
> > > document, even though it is equally valid for example to use the
> prefix
> > > "foo" or "ns0" to refer to the namespace.
> > >
> > > I have submitted a patch for TUSCANY-1351 that updates
> > XMLEq

Re: [CTS] Removing namespace prefix assumptions from tests

[ant elder]

Its just a BSD license isn't it? And so fine to use. Infact we did at one
point use Xmlunit in some of the SCA WS testcases, not sure if thats still
the case. I'd say just go ahead and use it if it does what you need.

  ...ant

On 6/18/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


Andy,  to my eye the license looks OK, BUT, I'm not a lawyer and I can't
speak for the ASF.  I see that there is an Apache project providing tags
for
xmlunit [1], so that would give me a warm feeling,  but looking in their
distribution artifacts, they don't redistribute XMLUnit and therefore
don't
have the requirement to republish the XMLUnit license.

I think we need  to send a notice to [EMAIL PROTECTED] to check this out.
Would you be happy to do that? If you are, it would probably be worth
copying the Incubator Project Management Committee (IPMC) at
[EMAIL PROTECTED]

Regards, Kelvin.

[1] http://jakarta.apache.org/commons/jelly/libs/xmlunit/index.html

On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
> XMLUnit does look like it would provide value.
>
> They have a proprietary license, pasted below. If you think this license
> would allow us to use it within the CTS then I'd be happy to spend some
> time
> investigating this further.
>
> Thanks,
>
> Andy.
>
> /*
> **
> Copyright (c) 2001-2007, Jeff Martin, Tim Bacon
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
>
> * Redistributions of source code must retain the above copyright
>   notice, this list of conditions and the following disclaimer.
> * Redistributions in binary form must reproduce the above
>   copyright notice, this list of conditions and the following
>   disclaimer in the documentation and/or other materials provided
>   with the distribution.
> * Neither the name of the xmlunit.sourceforge.net nor the names
>   of its contributors may be used to endorse or promote products
>   derived from this software without specific prior written
>   permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
> ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>
> **
> */
>
>
>
>
>
> -Original Message-
> From: kelvin goodson [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2007 11:38
> To: tuscany-dev@ws.apache.org
> Subject: Re: [CTS] Removing namespace prefix assumptions from tests
>
> Hi Andy,
>   http://issues.apache.org/jira/browse/TUSCANY-1263 has a comment in it
> from
> Lionel Villard ...
>
> "FYI, it exists an open source tool for comparing XML files:
> http://xmlunit.sourceforge.net/ , I haven't tried it"
>
> I had been hoping to take a look at this, from both the technical and
the
> license aspects, but I haven't had the time yet.  This may be a better
way
> to fix all these issues.  If no-one has the bandwidth to look at this,
> perhaps there's scope for tactical fixes such as that in your patch that
> would be superceded by the xmlunit dependency or the like.
>
> Regards, Kelvin.
>
>
>
> On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> >
> > XMLHelperTest.testDefineTypes() fails if an implementation does not
> > specifically use the "customer" namespace prefix when serializing a
> > document, even though it is equally valid for example to use the
prefix
> > "foo" or "ns0" to refer to the namespace.
> >
> > I have submitted a patch for TUSCANY-1351 that updates
> XMLEqualityChecker
> > so
> > that it does not compare namespace prefixes on elements (but rather
> > compares
> > the namespace URI and the local name).
> >
> > Also, XMLEqualityChecker  will no longer compare the value of
attributes
> > that use the "xmlns" or "xsi" prefixes. This is necessary because
> > attributes
> > such as xmlns:ns0="http://example.com/customer"; and
> > xsi:type="ns0:Customer"
> > were deemd to be incorrect because they reference the namespace prefix
> > that
> > differs from the one used in the gold xml file.
> >
> > This seems like a rather inelegant hack but I'm not sure how else to
> > remove
> > the tuscany-specific prefix assumptions without re-writing the test or
> > re-implementing XMLEqualityChecke

[jira] Resolved: (TUSCANY-1352) NPE in SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-1352.
-

Resolution: Fixed

Applied Ron's fix, thanks.

> NPE in 
> SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema
> 
>
> Key: TUSCANY-1352
> URL: https://issues.apache.org/jira/browse/TUSCANY-1352
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Critical
>
> While attempting to use Tuscany DAS with the latest Tuscany SDO, I triggered 
> a NPE in the recently added 
> SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema 
> method. The problem occurs when the DAS ConfigUtil.loadConfig method is 
> invoked which causes the SDO runtime to try and locate the "sdoJava.xsd" 
> schema. This schema has a null targetNamespace which triggers the NPE. The 
> required code change is as follows:
> ... (SDOXSDEcoreBuilder.java line 809)
> /* OLD */
> XSDSchema schema = (XSDSchema)iter.next();
> if (schema.getTargetNamespace().equals(namespaceURI))
> {
>   return schema;
> }
> /* NEW */
> XSDSchema schema = (XSDSchema)iter.next();
> String targetNamespace = schema.getTargetNamespace();
> if (targetNamespace != null && 
> targetNamespace.equals(namespaceURI))
> {
>   return schema;
> }
> Would someone please apply the above patch which allows Tuscany DAS to once 
> again work with the Tuscany SDO head? If I have some time in the next few 
> days, I'll try to add a test method to JiraTestCases.java that attempts to 
> "reproduce the problem"/"verify the fix".
> Thanks,
> - Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [CTS] Removing namespace prefix assumptions from tests

[kelvin goodson]

Andy,  to my eye the license looks OK, BUT, I'm not a lawyer and I can't
speak for the ASF.  I see that there is an Apache project providing tags for
xmlunit [1], so that would give me a warm feeling,  but looking in their
distribution artifacts, they don't redistribute XMLUnit and therefore don't
have the requirement to republish the XMLUnit license.

I think we need  to send a notice to [EMAIL PROTECTED] to check this out.
Would you be happy to do that? If you are, it would probably be worth
copying the Incubator Project Management Committee (IPMC) at
[EMAIL PROTECTED]

Regards, Kelvin.

[1] http://jakarta.apache.org/commons/jelly/libs/xmlunit/index.html

On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:


XMLUnit does look like it would provide value.

They have a proprietary license, pasted below. If you think this license
would allow us to use it within the CTS then I'd be happy to spend some
time
investigating this further.

Thanks,

Andy.

/*
**
Copyright (c) 2001-2007, Jeff Martin, Tim Bacon
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided
  with the distribution.
* Neither the name of the xmlunit.sourceforge.net nor the names
  of its contributors may be used to endorse or promote products
  derived from this software without specific prior written
  permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

**
*/





-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 18 June 2007 11:38
To: tuscany-dev@ws.apache.org
Subject: Re: [CTS] Removing namespace prefix assumptions from tests

Hi Andy,
  http://issues.apache.org/jira/browse/TUSCANY-1263 has a comment in it
from
Lionel Villard ...

"FYI, it exists an open source tool for comparing XML files:
http://xmlunit.sourceforge.net/ , I haven't tried it"

I had been hoping to take a look at this, from both the technical and the
license aspects, but I haven't had the time yet.  This may be a better way
to fix all these issues.  If no-one has the bandwidth to look at this,
perhaps there's scope for tactical fixes such as that in your patch that
would be superceded by the xmlunit dependency or the like.

Regards, Kelvin.



On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
> XMLHelperTest.testDefineTypes() fails if an implementation does not
> specifically use the "customer" namespace prefix when serializing a
> document, even though it is equally valid for example to use the prefix
> "foo" or "ns0" to refer to the namespace.
>
> I have submitted a patch for TUSCANY-1351 that updates
XMLEqualityChecker
> so
> that it does not compare namespace prefixes on elements (but rather
> compares
> the namespace URI and the local name).
>
> Also, XMLEqualityChecker  will no longer compare the value of attributes
> that use the "xmlns" or "xsi" prefixes. This is necessary because
> attributes
> such as xmlns:ns0="http://example.com/customer"; and
> xsi:type="ns0:Customer"
> were deemd to be incorrect because they reference the namespace prefix
> that
> differs from the one used in the gold xml file.
>
> This seems like a rather inelegant hack but I'm not sure how else to
> remove
> the tuscany-specific prefix assumptions without re-writing the test or
> re-implementing XMLEqualityChecker to have more intelligence when
> comparing
> documents.
>
> Does anyone have any better suggestions for resolving this issue or
should
> I
> go ahead and apply this patch?
>
> Thanks,
>
> Andy.
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Domains, runtimes, components and cardinality

[Simon Laws]

Following on from recent discussion on the distributed binding (I've been
putting notes here [1])... In a Tuscany SCA runtime what do we expect the
cardinality between the various parts of it to be?

A domain notionally runs on a runtime. In the case of a stand-alone Tuscany
SCA runtime this will be a single process (C++ exe, Java VM etc.). In the
case of a distributed Tuscany SCA runtime, the runtime is made up of many
distributed nodes that each run parts of the domain.

1/ Can domains share runtimes/nodes?

I.e can components from more than one domain be running inside a single
Tuscany SCA runtime or is the user expected to start up multiple runtimes to
run multiple domains.

2/ How many nodes can a single component run on?.

I.e. is the assignment of a component to multiple nodes, for performance,
reliability etc. reasons, explicitly supported as part of the topology
description of a distributed domain. If so then the  SCA binding chooses
which node to use. If not then any distribution of workload is considered to
be a job for the node implementation.

I'd be interested to hear peoples views on this

My starting point is...

1/ No, we will support multiple domains by starting multiple runtimes. We
could add the extra function to support sharing of runtimes between domains
in the future if it's found to be required.

2/ We shouldn't restrict whatever structure we use to describe the
component/node association to be 1-1. But we can assume 1 in the first
instance and consider adding more complex node selection features to the SCA
binding in the future.

Regards

Simon

[1] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=59826

Re: Finding the .componentType file

[ant elder]

On 6/18/07, ant elder <[EMAIL PROTECTED]> wrote:




On 6/18/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> On 6/18/07, ant elder <[EMAIL PROTECTED] > wrote:
>
> > On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > The component name may be nothing like the implementation name
> >
> >
> > How does that fit with the spec saying - ""A component type file has
> > the
> > same name as the implementation file but has the extension
> > ".componentType""
> > ? I'm looking for a way to make the default case easy, it doesn't have
> > to
> > deal with every edge case.
> >
> > The componentType file is really to be thought of as an extension of
> > the
> > > implementation for those (hopefully few) cases where introspection
> > of
> > > the implementation cannot provide the required information.
> >
> >
> > Maybe "implementationType" would have been be a better name :-)
> >
> > My suggestion is that the SPI should put the burden on the
> > > implementation module - for example a special method on the
> > > xxxImplementation class with a name like "locateComponentTypeFile".
> > > Actual loading of the componenttype file can be generic, but finding
> > the
> > > file is definitely a job for the implementation-handling code.
> >
> >
> > The problem with this is some don't want the simple xxxImplementation
> > class
> > to even be implementing any interface so ideally as much generic
> > function
> > would be built in the runtime, and thats what I'm trying to find a way
> > of
> > doing.
> >
> > I was wondering if the contribution service could help here. It could
> > discover all the .componentType files in a contribution making their
> > names
> > available,  the values of all the attributes of the xxxImplementation
> > class
> > are also known so it could compare  all the attribute values against
> > all the
> > found .componentType file names ignoring the file extension and when
> > there's
> > a match thats the .componentType for the implementation. How does that
> >
> > sound?
>
>
> That could be quite a gamble in my opinion.  There is a possibility that
> some attribute value of an implementation type instance could end up
> matching a componentType that corresponds to some other implementation.
>

Its xxx/yyy.componentType matching xxx/yyy.zzz, so "xxx/yyy." matching
some other attribute value would be pretty rare wouldn't it?  So for that
rare case it could just throw some exception if the implementation type impl
tries to use the default discovery mechanism.



I've committed a strawman impl that works as described above (the code is
rough, its just the design I'm trying to get pinned down for now). I'm
completely open to alternative ways of doing this, either code contributions
or just rough idea suggestions and I'll code it up. But all the tests are
passing like this now (and specifically the script testcases using
references which require the .componentType side file) so hopefully that can
help focus concrete suggestion which keep all the existing functionality
working.

  ...ant

[jira] Created: (TUSCANY-1352) NPE in SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema

[Ron Gavlin (JIRA)]

NPE in SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema


 Key: TUSCANY-1352
 URL: https://issues.apache.org/jira/browse/TUSCANY-1352
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical


While attempting to use Tuscany DAS with the latest Tuscany SDO, I triggered a 
NPE in the recently added 
SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema 
method. The problem occurs when the DAS ConfigUtil.loadConfig method is invoked 
which causes the SDO runtime to try and locate the "sdoJava.xsd" schema. This 
schema has a null targetNamespace which triggers the NPE. The required code 
change is as follows:

... (SDOXSDEcoreBuilder.java line 809)

/* OLD */
XSDSchema schema = (XSDSchema)iter.next();
if (schema.getTargetNamespace().equals(namespaceURI))
{
  return schema;
}

/* NEW */
XSDSchema schema = (XSDSchema)iter.next();
String targetNamespace = schema.getTargetNamespace();
if (targetNamespace != null && targetNamespace.equals(namespaceURI))
{
  return schema;
}

Would someone please apply the above patch which allows Tuscany DAS to once 
again work with the Tuscany SDO head? If I have some time in the next few days, 
I'll try to add a test method to JiraTestCases.java that attempts to "reproduce 
the problem"/"verify the fix".

Thanks,

- Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [CTS] Removing namespace prefix assumptions from tests

[Andy Grove]

XMLUnit does look like it would provide value.

They have a proprietary license, pasted below. If you think this license
would allow us to use it within the CTS then I'd be happy to spend some time
investigating this further.

Thanks,

Andy.

/*
**
Copyright (c) 2001-2007, Jeff Martin, Tim Bacon
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided
  with the distribution.
* Neither the name of the xmlunit.sourceforge.net nor the names
  of its contributors may be used to endorse or promote products
  derived from this software without specific prior written
  permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

**
*/





-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED] 
Sent: 18 June 2007 11:38
To: tuscany-dev@ws.apache.org
Subject: Re: [CTS] Removing namespace prefix assumptions from tests

Hi Andy,
  http://issues.apache.org/jira/browse/TUSCANY-1263 has a comment in it from
Lionel Villard ...

"FYI, it exists an open source tool for comparing XML files:
http://xmlunit.sourceforge.net/ , I haven't tried it"

I had been hoping to take a look at this, from both the technical and the
license aspects, but I haven't had the time yet.  This may be a better way
to fix all these issues.  If no-one has the bandwidth to look at this,
perhaps there's scope for tactical fixes such as that in your patch that
would be superceded by the xmlunit dependency or the like.

Regards, Kelvin.



On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
> XMLHelperTest.testDefineTypes() fails if an implementation does not
> specifically use the "customer" namespace prefix when serializing a
> document, even though it is equally valid for example to use the prefix
> "foo" or "ns0" to refer to the namespace.
>
> I have submitted a patch for TUSCANY-1351 that updates XMLEqualityChecker
> so
> that it does not compare namespace prefixes on elements (but rather
> compares
> the namespace URI and the local name).
>
> Also, XMLEqualityChecker  will no longer compare the value of attributes
> that use the "xmlns" or "xsi" prefixes. This is necessary because
> attributes
> such as xmlns:ns0="http://example.com/customer"; and
> xsi:type="ns0:Customer"
> were deemd to be incorrect because they reference the namespace prefix
> that
> differs from the one used in the gold xml file.
>
> This seems like a rather inelegant hack but I'm not sure how else to
> remove
> the tuscany-specific prefix assumptions without re-writing the test or
> re-implementing XMLEqualityChecker to have more intelligence when
> comparing
> documents.
>
> Does anyone have any better suggestions for resolving this issue or should
> I
> go ahead and apply this patch?
>
> Thanks,
>
> Andy.
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1341) Callback over WS Binding is not functioning various issues

[Simon Nash (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505785
 ] 

Simon Nash commented on TUSCANY-1341:
-

I have been looking at this and I have been making some progress.  I decided to 
take the simple-callback sample and create a new version of this called 
simple-callback-ws that uses the Web Service binding.

For problem (1), it seems that the Web Service Binding spec needs to add 
support for specifying the callback interface (PortType).  I'll pursue this 
with the spec authors.  Meanwhile, I have created a patch to obtain and set the 
callback interface based on a naming conention that the callback interface 
PortType name must be Callback, where  is the 
name of the PortType for the regular interface.

For problem (2), I changed the signature of findCallbackOperation() to pass in 
the contract instead of the wire.

I came across Problem (3) in my testing.  This was caused by an error in the 
SCDL.  For methods with void return types, the WSDL must not specify a 
wsdl:part within the wsdl:message for the method response.  Alternatively, the 
wsdl:output method response can be omitted from the wsdl:operation.  Tuscany 
should produce an error message for this, not a NPE. 

I'm currently looking into problem (4).  I think some fairly major changes are 
needed in this area.

I also discovered another problem in my testing:

5) InterfaceContractMapperImpl.checkCompatibility() does not work for callback 
interfaces.  For the regular interface, there is a FIXME comment and workaround 
code for remotable interfaces that only checks that the method names match 
(because the code that does the full check is broken).  This workaround code is 
not present for the calllback interface, so the compatibility check is failing 
for interfaces with callbacks.  For now, I have copied the FIXME comment and 
code to the callback interface path.

I'm planning to leave this JIRA open until the end-to-end path is working, and 
raise other JIRAs for problems and fixes that I find along the way., starting 
with the following:
  add the simple-callback-ws sample
  problem (1) and my patch for this
  problem (5) and my patch for this
  a description of problem (3)

I'm leaving problem (2) for now as I think there will be more major work needed 
in this area that could eliminate the need for the findCallbackOperation() 
method altogether.


> Callback over WS Binding is not functioning various issues
> --
>
> Key: TUSCANY-1341
> URL: https://issues.apache.org/jira/browse/TUSCANY-1341
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Misc Binding Extensions
>Affects Versions: Java-SCA-0.90
>Reporter: Lou Amodeo
>
> The callback function using WS bindings doesnt appear to be operation.  So 
> far I have :
> 1) WebServiceBindingProcessor.java 
> -  The resolve() method does not setup the callbackInterface on its 
> InterfaceContract resulting in NPE.
> (i.e. interfaceContract.setCallbackInterface(wsdlCallbackInterface); )
> [6/11/07 13:33:02:220 EDT] 0025 SystemOut O   ... 87 more
> [6/11/07 13:33:02:220 EDT] 0025 SystemOut O Caused by: 
> java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(InterfaceContractMapperImpl.java:246)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:337)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:269)
>   at 
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:580)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addComposite(EmbeddedSCADomain.java:124)
>   at 
> com.ibm.ws.sca2.tuscany.util.TuscanyInterfaceImpl.startModule(TuscanyInterfaceImpl.java:223)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:82)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:366)
>   at 
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.stateChanged(SCARuntimeImpl.java:286)
>   at 
> com.ibm.ws.runtime.component.ApplicationMgrImpl.stateChanged(ApplicationMgrImpl.java:1264)
>   at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectEvent(DeployedApplicationImpl.java:1112)
>   at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.setState(DeployedModuleImpl.java:206)
>   at 
> com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:566)
>   at 
> com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:814)
>   at 
> 

Re: 0.91 release?

[Simon Nash]

What will be the relationship between SCA 0.91 and DAS?  I have seen
some discussions on the list about a DAS release.  Will SCA 0.91 have
this DAS release as a dependency?

  Simon

Luciano Resende wrote:


I have updated the wiki [1] page with things that I'm working on, and
would like to have in 0.91 .

As for the implementation.das question regarding it's canned derby db,
we recently created a db utility to create and populate the database,
and I have plans to integrate with it.

[1] 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents 



On 6/16/07, ant elder <[EMAIL PROTECTED]> wrote:


Wow 571 license problems! after being clean for 0.90 just a month ago.

One question this brings up is what is actually intended to be 
included in
0.91? There's been quite a few new extensions and demo's etc added 
recently

but no one has said they want those included in 0.91. Should they be by
default or should we just include things that are mentioned on the 
release

wiki page? If so anyone else care to help clean things up, add missing
license headers, check the distribution works and includes 
dependencies etc?
The implementation.das is including an entire database in the src, is 
there

any way that could be generated by the tests?

   ...ant

On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Thanks Ant.  So could we all please use this wiki page to put down 
things

> that are going to be increments over 0.90.
>
> Also I run the RAT on the trunk - just java/sca and here is the 
report.  I
> intend to go and fix the missing headers just ahead of cutting the 
branch.
> Before that if anybody would like to jump in and help with this, 
please feel

> free do so.
>
> 
http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt 


>
> Thanks
>
> - Venkat
>
> On 6/14/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > Taking a branch around the 20th sounds ok to me.
> >
> > The high level things I'm focusing on for the 0.91 release are:
> >
> > - Simplification of using script components (working without
> > .componentType
> > side files)
> > - First cut of the simpler binding/implementation SPI
> > - clean up of ajax and jsonrpc bindings
> > - The EJB binding
> >
> > I'd also said to someone on the user list I'd get WS services without
> > wsdl
> > working so will try to do that as well.
> >
> > Most of the code for those is close-ish to being done, though there's
> > still
> > a whole lot of related sample work to get done.
> >
> > I'd started a wiki page for 0.91 at
> >
> > 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents 


> >
> >...ant
> >
> > On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > Thanks for the faith and encouragement.  This is going to be my 
first

> > > experience and I am sure of getting all the help from you folks to
> > pull
> > > this
> > > off successfully.
> > >
> > > So, to start with, I propose to cut a branch around June 20th,
> > 2007.  If
> > > people are ok with this, then all that we'd like to be a part of
> > 0.91should
> > > get in by then (June 20th, 2007).  Does that work fine with 
everybody?

> > >
> > > Also, I'd also like to list down the significant additions /
> > enhancements
> > > over 0.90 for the Release Notes.  You can state the item here on 
this

> > > thread
> > > and I will take care of recording it.
> > >
> > > - Venkat
> > >
> > > On 6/13/07, Simon Nash < [EMAIL PROTECTED]> wrote:
> > > >
> > > > +1 from me too.  I'm sure Venkat will do a fine job.
> > > >
> > > >Simon
> > > >
> > > > Jean-Sebastien Delfino wrote:
> > > >
> > > > > Simon Laws wrote:
> > > > >
> > > > >> Yeah, Venkat did loads on the last release. +1 from me for 
Venkat

> > as
> > > > >> 0.91 RM
> > > > >>
> > > > >> Simon
> > > > >>
> > > > >
> > > > > +1 from me
> > > > >
> > > > >




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [CTS] Removing namespace prefix assumptions from tests

[kelvin goodson]

Hi Andy,
 http://issues.apache.org/jira/browse/TUSCANY-1263 has a comment in it from
Lionel Villard ...

"FYI, it exists an open source tool for comparing XML files:
http://xmlunit.sourceforge.net/ , I haven't tried it"

I had been hoping to take a look at this, from both the technical and the
license aspects, but I haven't had the time yet.  This may be a better way
to fix all these issues.  If no-one has the bandwidth to look at this,
perhaps there's scope for tactical fixes such as that in your patch that
would be superceded by the xmlunit dependency or the like.

Regards, Kelvin.



On 18/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:


XMLHelperTest.testDefineTypes() fails if an implementation does not
specifically use the "customer" namespace prefix when serializing a
document, even though it is equally valid for example to use the prefix
"foo" or "ns0" to refer to the namespace.

I have submitted a patch for TUSCANY-1351 that updates XMLEqualityChecker
so
that it does not compare namespace prefixes on elements (but rather
compares
the namespace URI and the local name).

Also, XMLEqualityChecker  will no longer compare the value of attributes
that use the "xmlns" or "xsi" prefixes. This is necessary because
attributes
such as xmlns:ns0="http://example.com/customer"; and
xsi:type="ns0:Customer"
were deemd to be incorrect because they reference the namespace prefix
that
differs from the one used in the gold xml file.

This seems like a rather inelegant hack but I'm not sure how else to
remove
the tuscany-specific prefix assumptions without re-writing the test or
re-implementing XMLEqualityChecker to have more intelligence when
comparing
documents.

Does anyone have any better suggestions for resolving this issue or should
I
go ahead and apply this patch?

Thanks,

Andy.

Re: Finding the .componentType file

[ant elder]

On 6/18/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


On 6/18/07, ant elder <[EMAIL PROTECTED]> wrote:

> On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
>
> 
>
> The component name may be nothing like the implementation name
>
>
> How does that fit with the spec saying - ""A component type file has the
> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't have
> to
> deal with every edge case.
>
> The componentType file is really to be thought of as an extension of the
> > implementation for those (hopefully few) cases where introspection of
> > the implementation cannot provide the required information.
>
>
> Maybe "implementationType" would have been be a better name :-)
>
> My suggestion is that the SPI should put the burden on the
> > implementation module - for example a special method on the
> > xxxImplementation class with a name like "locateComponentTypeFile".
> > Actual loading of the componenttype file can be generic, but finding
> the
> > file is definitely a job for the implementation-handling code.
>
>
> The problem with this is some don't want the simple xxxImplementation
> class
> to even be implementing any interface so ideally as much generic
> function
> would be built in the runtime, and thats what I'm trying to find a way
> of
> doing.
>
> I was wondering if the contribution service could help here. It could
> discover all the .componentType files in a contribution making their
> names
> available,  the values of all the attributes of the xxxImplementation
> class
> are also known so it could compare  all the attribute values against all
> the
> found .componentType file names ignoring the file extension and when
> there's
> a match thats the .componentType for the implementation. How does that
> sound?


That could be quite a gamble in my opinion.  There is a possibility that
some attribute value of an implementation type instance could end up
matching a componentType that corresponds to some other implementation.



Its xxx/yyy.componentType matching xxx/yyy.zzz, so "xxx/yyy." matching some
other attribute value would be pretty rare wouldn't it?  So for that rare
case it could just throw some exception if the implementation type impl
tries to use the default discovery mechanism.

Even if the specs changed to have an attribute called 'implArtifact' or

'implResource'  so that you can pick up the implementation resource
information, it would still not help to deal generically if implementation
types have their own means of loading this and the associated componentType
info.  And then what is implementation types decide to  add their extensions
to a ComponentType. ?



Then they have to override the default behaviour and implement this
themselves. This is for the "simple" implementation type impl so it doesn't
have to cope with every possibility...and after nearly two years there's
been no Tuscany extension yet that adds to the ComponentType...

  ...ant

Re: Finding the .componentType file

[Venkata Krishnan]

On 6/18/07, ant elder <[EMAIL PROTECTED]> wrote:


On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:



The component name may be nothing like the implementation name


How does that fit with the spec saying - ""A component type file has the
same name as the implementation file but has the extension
".componentType""
? I'm looking for a way to make the default case easy, it doesn't have to
deal with every edge case.

The componentType file is really to be thought of as an extension of the
> implementation for those (hopefully few) cases where introspection of
> the implementation cannot provide the required information.


Maybe "implementationType" would have been be a better name :-)

My suggestion is that the SPI should put the burden on the
> implementation module - for example a special method on the
> xxxImplementation class with a name like "locateComponentTypeFile".
> Actual loading of the componenttype file can be generic, but finding the
> file is definitely a job for the implementation-handling code.


The problem with this is some don't want the simple xxxImplementation
class
to even be implementing any interface so ideally as much generic function
would be built in the runtime, and thats what I'm trying to find a way of
doing.

I was wondering if the contribution service could help here. It could
discover all the .componentType files in a contribution making their names
available,  the values of all the attributes of the xxxImplementation
class
are also known so it could compare  all the attribute values against all
the
found .componentType file names ignoring the file extension and when
there's
a match thats the .componentType for the implementation. How does that
sound?



That could be quite a gamble in my opinion.  There is a possibility that
some attribute value of an implementation type instance could end up
matching a componentType that corresponds to some other implementation.

Even if the specs changed to have an attribute called 'implArtifact' or
'implResource'  so that you can pick up the implementation resource
information, it would still not help to deal generically if implementation
types have their own means of loading this and the associated componentType
info.  And then what is implementation types decide to  add their extensions
to a ComponentType. ?


...ant



- Venkat

Adding OSGi runtime to Maven repository

[Rajini Sivaram]

Hello,

The only version of Equinox OSGi runtime that I could find in a maven
repository that Tuscany uses is version 3.1.1 from
http://repo1.maven.org/maven2/org/eclipse/equinox/osgi/3.1.1/ which is quite
old. Even though it is sufficient to do a build, it seems to fall over when
tests are run if the directory where it is loaded from contains spaces. Is
it possible to install Equinox 3.3 into a maven repository where Tuscany can
find it?


Thank you...

Regards,

Rajini

[CTS] Removing namespace prefix assumptions from tests

[Andy Grove]

XMLHelperTest.testDefineTypes() fails if an implementation does not
specifically use the "customer" namespace prefix when serializing a
document, even though it is equally valid for example to use the prefix
"foo" or "ns0" to refer to the namespace.

I have submitted a patch for TUSCANY-1351 that updates XMLEqualityChecker so
that it does not compare namespace prefixes on elements (but rather compares
the namespace URI and the local name).

Also, XMLEqualityChecker  will no longer compare the value of attributes
that use the "xmlns" or "xsi" prefixes. This is necessary because attributes
such as xmlns:ns0="http://example.com/customer"; and xsi:type="ns0:Customer"
were deemd to be incorrect because they reference the namespace prefix that
differs from the one used in the gold xml file.

This seems like a rather inelegant hack but I'm not sure how else to remove
the tuscany-specific prefix assumptions without re-writing the test or
re-implementing XMLEqualityChecker to have more intelligence when comparing
documents.

Does anyone have any better suggestions for resolving this issue or should I
go ahead and apply this patch?

Thanks,

Andy.

[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions

[Andy Grove (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Grove updated TUSCANY-1351:


Attachment: tuscany-1351.patch

New version of patch that fixes another namespace assumption. 

> Some CTS tests are tuscany specific due to namespace prefix assumptions
> ---
>
> Key: TUSCANY-1351
> URL: https://issues.apache.org/jira/browse/TUSCANY-1351
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: tuscany-1351.patch
>
>
> A number of CTS tests fail against implementations that use different 
> namespace prefixes than Tuscany when serializing documents, even though the 
> correct namespaces are referenced.
> For example, XMLHelperTest.testDefineType expects the root element of a 
> serialized document to be defined as :
> http://example.com/customer"; >
> If an implementation uses a different prefix then the test fails. For 
> example, this will fail, even though it is valid:
> http://example.com/customer"; >
> The XMLEqualityChecker should be updated to ignore the specific prefix used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions

[Andy Grove (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Grove updated TUSCANY-1351:


Attachment: (was: tuscany-1351.patch)

> Some CTS tests are tuscany specific due to namespace prefix assumptions
> ---
>
> Key: TUSCANY-1351
> URL: https://issues.apache.org/jira/browse/TUSCANY-1351
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: tuscany-1351.patch
>
>
> A number of CTS tests fail against implementations that use different 
> namespace prefixes than Tuscany when serializing documents, even though the 
> correct namespaces are referenced.
> For example, XMLHelperTest.testDefineType expects the root element of a 
> serialized document to be defined as :
> http://example.com/customer"; >
> If an implementation uses a different prefix then the test fails. For 
> example, this will fail, even though it is valid:
> http://example.com/customer"; >
> The XMLEqualityChecker should be updated to ignore the specific prefix used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions

[Andy Grove (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Grove updated TUSCANY-1351:


Attachment: tuscany-1351.patch

Patch that resolves this issue by removing prefix-specific comparisons and 
instead just relies in comparison of namespace uri and local name. Also remove 
duplicate code that checked the namespace.

> Some CTS tests are tuscany specific due to namespace prefix assumptions
> ---
>
> Key: TUSCANY-1351
> URL: https://issues.apache.org/jira/browse/TUSCANY-1351
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: tuscany-1351.patch
>
>
> A number of CTS tests fail against implementations that use different 
> namespace prefixes than Tuscany when serializing documents, even though the 
> correct namespaces are referenced.
> For example, XMLHelperTest.testDefineType expects the root element of a 
> serialized document to be defined as :
> http://example.com/customer"; >
> If an implementation uses a different prefix then the test fails. For 
> example, this will fail, even though it is valid:
> http://example.com/customer"; >
> The XMLEqualityChecker should be updated to ignore the specific prefix used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions

[Andy Grove (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Grove updated TUSCANY-1351:


Patch Info: [Patch Available]

> Some CTS tests are tuscany specific due to namespace prefix assumptions
> ---
>
> Key: TUSCANY-1351
> URL: https://issues.apache.org/jira/browse/TUSCANY-1351
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Reporter: Andy Grove
> Attachments: tuscany-1351.patch
>
>
> A number of CTS tests fail against implementations that use different 
> namespace prefixes than Tuscany when serializing documents, even though the 
> correct namespaces are referenced.
> For example, XMLHelperTest.testDefineType expects the root element of a 
> serialized document to be defined as :
> http://example.com/customer"; >
> If an implementation uses a different prefix then the test fails. For 
> example, this will fail, even though it is valid:
> http://example.com/customer"; >
> The XMLEqualityChecker should be updated to ignore the specific prefix used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions

[Andy Grove (JIRA)]

Some CTS tests are tuscany specific due to namespace prefix assumptions
---

 Key: TUSCANY-1351
 URL: https://issues.apache.org/jira/browse/TUSCANY-1351
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove


A number of CTS tests fail against implementations that use different namespace 
prefixes than Tuscany when serializing documents, even though the correct 
namespaces are referenced.

For example, XMLHelperTest.testDefineType expects the root element of a 
serialized document to be defined as :

http://example.com/customer"; >

If an implementation uses a different prefix then the test fails. For example, 
this will fail, even though it is valid:

http://example.com/customer"; >

The XMLEqualityChecker should be updated to ignore the specific prefix used.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Finding the .componentType file

[ant elder]

On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:



The component name may be nothing like the implementation name


How does that fit with the spec saying - ""A component type file has the
same name as the implementation file but has the extension ".componentType""
? I'm looking for a way to make the default case easy, it doesn't have to
deal with every edge case.

The componentType file is really to be thought of as an extension of the

implementation for those (hopefully few) cases where introspection of
the implementation cannot provide the required information.



Maybe "implementationType" would have been be a better name :-)

My suggestion is that the SPI should put the burden on the

implementation module - for example a special method on the
xxxImplementation class with a name like "locateComponentTypeFile".
Actual loading of the componenttype file can be generic, but finding the
file is definitely a job for the implementation-handling code.



The problem with this is some don't want the simple xxxImplementation class
to even be implementing any interface so ideally as much generic function
would be built in the runtime, and thats what I'm trying to find a way of
doing.

I was wondering if the contribution service could help here. It could
discover all the .componentType files in a contribution making their names
available,  the values of all the attributes of the xxxImplementation class
are also known so it could compare  all the attribute values against all the
found .componentType file names ignoring the file extension and when there's
a match thats the .componentType for the implementation. How does that
sound?

   ...ant