some error when i test the samples
hi , i have some questions to ask for help , thank you at first! when i want to test the samples , like the tuscany-sca-1.0-incubator-M2-samples\standalone\calculator when i Building and Running the Samples , i input mvn -N install in , however, there are the errors informations as follows: -the information from the cmd.exe begin-- F:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\ROOT\test\SOA2\tuscany-sca-1.0-incubat or-M2-samples\standalone\calculatormvn [INFO] Scanning for projects... [INFO] [INFO] Building Tuscany Calculator Sample [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] Copying 2 resources to META-INF Downloading: http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.0.1/wstx-asl -3.0.1.pom Downloading: http://people.apache.org/repository/woodstox/poms/wstx-asl-3.0.1.pom Downloading: http://repo1.maven.org/maven2/woodstox/wstx-asl/3.0.1/wstx-asl-3.0.1.pom [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] Resource directory does not exist: F:\Program Files\Apache Software Foundation\Tomcat 5.5\weba pps\ROOT\test\SOA2\tuscany-sca-1.0-incubator-M2-samples\standalone\calculator\src\test\resources Downloading: http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.0.1/wstx-asl -3.0.1.jar Downloading: http://people.apache.org/repository/woodstox/jars/wstx-asl-3.0.1.jar Downloading: http://repo1.maven.org/maven2/woodstox/wstx-asl/3.0.1/wstx-asl-3.0.1.jar 463K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '4a06da0a4202135507ae7665b9579c3 23b2e8ad3'; remote = 'a990acb509424d427f4bdb830196fd3fdf01a496' - RETRYING Downloading: http://repo1.maven.org/maven2/woodstox/wstx-asl/3.0.1/wstx-asl-3.0.1.jar 457/463K -the information from the cmd.exe- end- i have no idea that what i can do to fix this. 2007-08-29 2005yangdehua Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz
Re: Naming webapp samples *-webapp
+1 - Venkat On 8/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Some of our webapp samples are missing a webapp suffix, I'm going to rename them as follows: - helloworld-jsonrpc - helloworld-jsonrpc-webapp - helloworld-dojo - helloworld-dojo-webapp - calculator-webapp-ws - calculator-ws-webapp If there's no objection I'll do that sometime tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming webapp samples *-webapp
On 8/29/07, Venkata Krishnan [EMAIL PROTECTED] wrote: +1 - Venkat On 8/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Some of our webapp samples are missing a webapp suffix, I'm going to rename them as follows: - helloworld-jsonrpc - helloworld-jsonrpc-webapp - helloworld-dojo - helloworld-dojo-webapp - calculator-webapp-ws - calculator-ws-webapp If there's no objection I'll do that sometime tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 Simon
Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: One more observation... when the binding URI is http://localhost:8080/hello/HelloWorldService; the service is available at that URL. Only http://localhost:8080/hello/HelloWorldService?wsdl; results in an exception. Here is what I did. 1. Deploy the HelloWorld sample with binding URI http://localhost:8080/HelloWorldService;. 2. Get the wsdl by accessing http://localhost:8080/HelloWorldService?wsdl; and save to a disk file. 3. Now redeploy HelloWorld sample with binding URI http://localhost:8080/ hello/HelloWorldService. 4. Using WebServices Explorer in Eclipse, and the saved wsdl file from step2, access the service at url in step3. Vamsi On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Ok what happens with a uri of http://localhost:8080/HelloWorldService?wsdlhttp://localhost:8080/hello/HelloWorldService?wsdl I have fixed the problem in plugin code so that it uses a context root / as well. After the fix, I am able to use http://localhost:8080/HelloWorldService?wsdlhttp://localhost:8080/hello/HelloWorldService?wsdlas uri. And for this uri (that ?wsdl in the uri did not matter), I am able to access the wsdl using http://localhost:8080/HelloWorldService?wsdlhttp://localhost:8080/hello/HelloWorldService?wsdl (sorry to keep bouncing this back to you, i've not been able to get the Geronimo integration to build locally yet so can't test this myself) Let me see if I can quickly provide the built plugin so that you can install it in Geronimo 2.0.1. ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Is /hello the mapping for some Geronimo servlet or application thing? /hello is not mapped to any application. What happens if you change the uri in the SCDL to have binding.wsuri=/HelloWorldService/? In this case, GeronimoServletHost.addServletMapping() is getting invoked with ( http://localhost:8085/HelloWorldService;, Axis2ServiceServlet). Since there is no http connector on 8085, the method is throwing an Exception. Thanks, ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: So that must mean in the setContextRoot method at line 279 in TuscanyListingAgent that configContext.getContextRoot() is returning http://localhost:8080/hello/; right? configContext.getContextRoot() is returning hello. Can you debug Axis2ServiceServlet on line 230 and see what gets set on th eline configContext.setContextRoot( request.getContextPath());? request.getContextPath() is evaluating to /hello . Thanks, ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, The URL is http://localhost:8080/hello/HelloWorldService?wsdl; . When I debug the code, I am noticing that in TuscanyListingAgent.processListService () around line 101, the filePart is http://localhost:8080/hello/HelloWorldService; and findAxisServiceName() is returning /hello/HelloWorldService. Inside setContextRoot() arounf line 286, mapping = filePart.substring() is getting called with paramters (28, 21) which is resulting in the Exception. That -7 in the exception message is this 21-28. Vamsi On 8/26/07, ant elder [EMAIL PROTECTED] wrote: On 8/25/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have deployed HelloWorld webservice sample (jar attached in this mail) in Tuscany plugin for Geronimo. This plugin is using 1.0-incubating-SNAPSHOT jars published on 2007-08-23. The sample deploys fine. But, when I access http://localhost:8080/hello/HelloWorldService?wsdl , I am getting a
[jira] Assigned: (TUSCANY-1326) DWR binding should use endpoints as defined in the assembly spec 1.7.2
[ https://issues.apache.org/jira/browse/TUSCANY-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-1326: --- Assignee: Jean-Sebastien Delfino DWR binding should use endpoints as defined in the assembly spec 1.7.2 -- Key: TUSCANY-1326 URL: https://issues.apache.org/jira/browse/TUSCANY-1326 Project: Tuscany Issue Type: Bug Components: Java SCA JSON-RPC Binding Extension Affects Versions: Java-SCA-0.99, Java-SCA-Next Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The jsonrpc and Ajax bindings currently hardcode the endpoint uri of the services they provide. Instead they should use the algorithm described in the SCA assembly spec section 1.7.2 -- 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] Commented: (TUSCANY-1326) DWR binding should use endpoints as defined in the assembly spec 1.7.2
[ https://issues.apache.org/jira/browse/TUSCANY-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523498 ] Jean-Sebastien Delfino commented on TUSCANY-1326: - I'm starting to work on this. To make different services available at different URIs, I thing that we'll need multiple instances of DWRServlet (one per service) instead of the single instance currently mapped to the hardcoded SCADomain/* URI. Will this break DWRServlet? How is DWRServlet designed to be used? DWR binding should use endpoints as defined in the assembly spec 1.7.2 -- Key: TUSCANY-1326 URL: https://issues.apache.org/jira/browse/TUSCANY-1326 Project: Tuscany Issue Type: Bug Components: Java SCA JSON-RPC Binding Extension Affects Versions: Java-SCA-0.99, Java-SCA-Next Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The jsonrpc and Ajax bindings currently hardcode the endpoint uri of the services they provide. Instead they should use the algorithm described in the SCA assembly spec section 1.7.2 -- 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] Resolved: (TUSCANY-1627) alert aggregator demo feeds don't work (may be a wider problem with the way feed url's are managed in host-webapp environment)
[
https://issues.apache.org/jira/browse/TUSCANY-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino resolved TUSCANY-1627.
-
Resolution: Fixed
Can you try again with the latest trunk? it should be fixed now.
See http://www.mail-archive.com/[EMAIL PROTECTED]/msg01668.html for a
description of the issues with the Webapp integration and what I did to fix
them.
Please reopen if there are still any problems. Thanks.
alert aggregator demo feeds don't work (may be a wider problem with the way
feed url's are managed in host-webapp environment)
--
Key: TUSCANY-1627
URL: https://issues.apache.org/jira/browse/TUSCANY-1627
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-0.99
Reporter: Simon Laws
Fix For: Java-SCA-1.0
Using the URL
http://localhost:8080/demo-alert-aggregator/services/AlertsFeedServiceRSS
With the alert-aggregator demo results in a 404.
This is what Tomcat prints out
28-Aug-2007 12:07:24
org.apache.tuscany.sca.binding.feed.provider.FeedBindingLis
tenerServlet doGet
INFO: FeedEndPointServlet (rss_2.0)
/demo-alert-aggregator/services/AlertsFe
edServiceRSS
28-Aug-2007 12:07:24
org.apache.tuscany.sca.binding.feed.provider.FeedBindingLis
tenerServlet doGet
I added a little extra debug and find that the path info is
INFO: FeedEndPointServlet path = /AlertsFeedServiceRSS
Having this path info means that the feed binding will ignore the request.
There is code in FeedBindingListenerServlet that, for rss feeds, only does
something if
if (path == null || path.length() == 0 || path.equals(/)) {
--
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] Resolved: (TUSCANY-1481) TuscanyServlet looks for servlets using path info and not the whole path
[
https://issues.apache.org/jira/browse/TUSCANY-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino resolved TUSCANY-1481.
-
Resolution: Won't Fix
When we package services in a webapp, I think that we have to accept that part
of their URIs will be ignored as host, port, and context root are fixed by the
Web container and cannot be controlled anymore by the SCA runtime embedded in
that Web container.
This is not necessarily an issue, there are other examples where part of the
service/binding URI used to publish a service is ignored or becomes irrelevant:
- localhost for example is ignored in the standalone runtime, assuming that a
service is always running on localhost, in this case the host name (or names)
cannot be controlled by the SCA runtime as it is fixed by the machine on which
it runs and its network configuration
- the complete URI can also become irrelevant in many other cases, in presence
of virtual hosting, proxies, redirections, or URI aliasing, all of which are
external to the SCA runtime.
TuscanyServlet looks for servlets using path info and not the whole path
-
Key: TUSCANY-1481
URL: https://issues.apache.org/jira/browse/TUSCANY-1481
Project: Tuscany
Issue Type: Bug
Components: Java SCA Web App Integration
Affects Versions: Java-SCA-Next
Environment: All
Reporter: Simon Laws
Fix For: Java-SCA-1.0
In the TuscanyServlet service method there is code to find a registerest
servlet
String path = ((HttpServletRequest)req).getPathInfo();
Servlet servlet = servletHost.getServlet(path);
if (servlet == null) {
throw new IllegalStateException(No servlet registered for
path: + path);
}
Currently though in the code servlets can get registered against full path
names, e,g, when the full path name is defined in WSDL, and hence the servlet
is not found. I expect it is this way as its not expecting a full path to be
specified. Why would it, the application is deployed into an already running
app server. We either need to raise an error to tell people why their
services can't be found or check for full path names.
I've dont the latter for now (see the change assoicated with this JIRA) but
would welcome some more thought on this issue as I expect the is a good
reason why it is this way.
--
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-1629) Tuscany does not support using classes in the @Service annotation
Tuscany does not support using classes in the @Service annotation
-
Key: TUSCANY-1629
URL: https://issues.apache.org/jira/browse/TUSCANY-1629
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-0.91
Environment: Linux
Was using Tuscany SVN revision 570353
Reporter: Mark Combellack
Fix For: Java-SCA-0.91
The current implementation of Tuscany does not support using a class in the
@Service annotation.
For example, if I have:
@Service(MyService.class)
public class MyService {
public String op1(){
return op1 invoked;
}
}
The above example is valid from my understanding of the Java Common Annotations
and APIs specification because it says:
1628 The @Service annotation has the following attributes:
1629 • interfaces - The value is an array of interface or class objects that
should be exposed as services
1630 by this component.
1631 • value - A shortcut for the case when the class provides only a single
service interface.
The key phrase is in line 1629 or class objects
Tuscany throws the following exception:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
snipped setup code
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:119)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 16 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:118)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:411)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117)
... 17 more
Caused by:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:88)
at
org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72)
at
org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
at
[jira] Commented: (TUSCANY-1629) Tuscany does not support using classes in the @Service annotation
[
https://issues.apache.org/jira/browse/TUSCANY-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523510
]
Mark Combellack commented on TUSCANY-1629:
--
The problem is in the ServiceProcessor class in the implementation-java
project. When the visitClass method is called, it finds the @Service and then
verifies that the class listed is an interface using the following code:
for (Class? interfaze : interfaces) {
if (!interfaze.isInterface()) {
throw new InvalidServiceType(Service must be an interface,
interfaze);
}
The solution is to remove this check of interfaze is an interface.
Tuscany does not support using classes in the @Service annotation
-
Key: TUSCANY-1629
URL: https://issues.apache.org/jira/browse/TUSCANY-1629
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-0.91
Environment: Linux
Was using Tuscany SVN revision 570353
Reporter: Mark Combellack
Fix For: Java-SCA-0.91
The current implementation of Tuscany does not support using a class in the
@Service annotation.
For example, if I have:
@Service(MyService.class)
public class MyService {
public String op1(){
return op1 invoked;
}
}
The above example is valid from my understanding of the Java Common
Annotations and APIs specification because it says:
1628 The @Service annotation has the following attributes:
1629 • interfaces - The value is an array of interface or class objects that
should be exposed as services
1630 by this component.
1631 • value - A shortcut for the case when the class provides only a single
service interface.
The key phrase is in line 1629 or class objects
Tuscany throws the following exception:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
snipped setup code
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:119)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 16 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:118)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:411)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
[jira] Updated: (TUSCANY-1629) Tuscany does not support using classes in the @Service annotation
[
https://issues.apache.org/jira/browse/TUSCANY-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Combellack updated TUSCANY-1629:
-
Attachment: ServiceAnnotationUsingClass.patch
The attached patch removes the check for the class listed in the @Service
annotation being an interface.
Tuscany does not support using classes in the @Service annotation
-
Key: TUSCANY-1629
URL: https://issues.apache.org/jira/browse/TUSCANY-1629
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-0.91
Environment: Linux
Was using Tuscany SVN revision 570353
Reporter: Mark Combellack
Fix For: Java-SCA-0.91
Attachments: ServiceAnnotationUsingClass.patch
The current implementation of Tuscany does not support using a class in the
@Service annotation.
For example, if I have:
@Service(MyService.class)
public class MyService {
public String op1(){
return op1 invoked;
}
}
The above example is valid from my understanding of the Java Common
Annotations and APIs specification because it says:
1628 The @Service annotation has the following attributes:
1629 • interfaces - The value is an array of interface or class objects that
should be exposed as services
1630 by this component.
1631 • value - A shortcut for the case when the class provides only a single
service interface.
The key phrase is in line 1629 or class objects
Tuscany throws the following exception:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
snipped setup code
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:119)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 16 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:118)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:411)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117)
... 17 more
Caused by:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
[jira] Updated: (TUSCANY-1629) Tuscany does not support using classes in the @Service annotation
[
https://issues.apache.org/jira/browse/TUSCANY-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Combellack updated TUSCANY-1629:
-
Patch Info: [Patch Available]
Marking as patch available
Tuscany does not support using classes in the @Service annotation
-
Key: TUSCANY-1629
URL: https://issues.apache.org/jira/browse/TUSCANY-1629
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-0.91
Environment: Linux
Was using Tuscany SVN revision 570353
Reporter: Mark Combellack
Fix For: Java-SCA-0.91
Attachments: ServiceAnnotationUsingClass.patch
The current implementation of Tuscany does not support using a class in the
@Service annotation.
For example, if I have:
@Service(MyService.class)
public class MyService {
public String op1(){
return op1 invoked;
}
}
The above example is valid from my understanding of the Java Common
Annotations and APIs specification because it says:
1628 The @Service annotation has the following attributes:
1629 • interfaces - The value is an array of interface or class objects that
should be exposed as services
1630 by this component.
1631 • value - A shortcut for the case when the class provides only a single
service interface.
The key phrase is in line 1629 or class objects
Tuscany throws the following exception:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
snipped setup code
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:119)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 16 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:118)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:411)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117)
... 17 more
Caused by:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:88)
at
[jira] Commented: (TUSCANY-1563) WSDL generated on the fly has some problem
[ https://issues.apache.org/jira/browse/TUSCANY-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523518 ] Nishant Joshi commented on TUSCANY-1563: Try with latest code but it got error java.lang.IllegalStateException: No servlet registered for path: WSDL generated on the fly has some problem -- Key: TUSCANY-1563 URL: https://issues.apache.org/jira/browse/TUSCANY-1563 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: Eclipse, tuscany-sca-1.0-incubating-SNAPSHOT (Tuscany Nightly Build), Windows XP Reporter: Nishant Joshi Fix For: Java-SCA-0.99 Hi, I have generated wsdl on the fly using Tuscany Nightly Build.It was creating wsdl with some problem. problem is in generation of tag soap:address location=http://XX:XX:XX:XX:8080/ExampleComponent/MyService; /. here root folder name of Tomcat/webapps is missing.Here in my example root folder name is Example-0.0.1 so soap address will be like soap:address location=http://XX:XX:XX:XX:8080/Example-0.0.1/ExampleComponent/MyService; / not soap:address location=http://XX:XX:XX:XX:8080/ExampleComponent/MyService; /. So here root folder name is missing in soap address location. Because it was creating problem when I have tried to create WebService client using Eclipse Europa's plugins facility. Thanks in advance Nishant Joshi -- 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-1630) On fly wsdl generation with axis2 1.3, coding suggestion draft
On fly wsdl generation with axis2 1.3, coding suggestion draft
--
Key: TUSCANY-1630
URL: https://issues.apache.org/jira/browse/TUSCANY-1630
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-Next
Environment: jdk1.5 windows, eclipse, latest svn code
Reporter: gengshaoguang
The axis2 binding depends on axis2 1.2, it works well for binding.ws when you
provide artificial wsdl and reference it with interface:wsdl
interface=[uri]/. Be careful the service name must be the same to the java
interface.
Then you could remove your wsdl and mark out the interface.wsdl/.
Then the Java2WSDLHelper is going to work, but failed with compilation, it
compiles only with axis2 1.3.
Refresh the classpath, then we should do the following correction to fit axis2
1.3.
...binding.ws.axis2.Axis2ServiceServlet.
private ConfigurationContext conf_ctx;
public void init(ConfigurationContext configContext) {
conf_ctx = configContext; //keep this object locally instead of in the
super's (super now change this member by itself)
/*this.configContext = configContext;
try {
super.init(DUMMY_CONFIG);
} catch (ServletException e) {
throw new RuntimeException(e);
}*/
agent = new TuscanyListingAgent(configContext);
}
.
@Override
protected ConfigurationContext initConfigContext(ServletConfig config)
throws ServletException {
return conf_ctx; //return local instance instead of original: instance
in the super
}
Tomorrow I will make a mvn test case and attach the code here on.
--
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-1629) Tuscany does not support using classes in the @Service annotation
[
https://issues.apache.org/jira/browse/TUSCANY-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1629:
---
Fix Version/s: (was: Java-SCA-0.91)
Java-SCA-1.0
Tuscany does not support using classes in the @Service annotation
-
Key: TUSCANY-1629
URL: https://issues.apache.org/jira/browse/TUSCANY-1629
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-0.91
Environment: Linux
Was using Tuscany SVN revision 570353
Reporter: Mark Combellack
Fix For: Java-SCA-1.0
Attachments: ServiceAnnotationUsingClass.patch
The current implementation of Tuscany does not support using a class in the
@Service annotation.
For example, if I have:
@Service(MyService.class)
public class MyService {
public String op1(){
return op1 invoked;
}
}
The above example is valid from my understanding of the Java Common
Annotations and APIs specification because it says:
1628 The @Service annotation has the following attributes:
1629 • interfaces - The value is an array of interface or class objects that
should be exposed as services
1630 by this component.
1631 • value - A shortcut for the case when the class provides only a single
service interface.
The key phrase is in line 1629 or class objects
Tuscany throws the following exception:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
snipped setup code
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:119)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 16 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:118)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:411)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117)
... 17 more
Caused by:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:88)
at
Re: [jira] Updated: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject
I applied v2 and then v2_b Cheers, On 28/08/2007, Michael Yoder (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1370: --- Attachment: TUSCANY-1370v2_b.txt The v2 patch left out treatment of the objectToXPath member function. This patch takes care of the omission. C++ SDO spec compliance/portability: DataObject --- Key: TUSCANY-1370 URL: https://issues.apache.org/jira/browse/TUSCANY-1370 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issues -- all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1370.txt, TUSCANY-1370v2.txt, TUSCANY-1370v2_b.txt The specification interface DataObject.h exposes off-spec member functions, these should be made internal to the implementation. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 6:34 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataObject Hi, In the DataObject interface, these member functions are exposed which aren't in the C++ 2.1 spec: virtual SDO_API bool hasProperty(const char* name) = 0; virtual SDO_API bool hasProperty(const SDOString name) = 0; virtual SDO_API DataFactory* getDataFactory() = 0; virtual SDO_API void setUserData(const char* path,void* value) = 0; virtual SDO_API void setUserData(const SDOString path, void* value) = 0; virtual SDO_API void setUserData(unsigned int propertyIndex, void* value) = 0; virtual SDO_API void setUserData(const Property property, void* value) = 0; virtual SDO_API void setUserData(void* value) = 0; virtual SDO_API void* getUserData(const char* path) = 0; virtual SDO_API void* getUserData(const SDOString path) = 0; virtual SDO_API void* getUserData(unsigned int propertyIndex) = 0; virtual SDO_API void* getUserData(const Property property) = 0; virtual SDO_API void* getUserData() = 0; virtual SDO_SPI const char* objectToXPath() = 0; Would it be appropriate to file a Jira/patch to have these removed from the spec interface? Or alternatively a Jira to submit them to the spec committee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath
Patch applied. Can you resolve/close the Jiras if the work is now complete on them? Cheers, On 28/08/2007, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I have uploaded a patch for TUSCANY-1548. If someone could review and apply it that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 9:52 AM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath [ https://issues.apache.org/jira/browse/TUSCANY-1548?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1548: --- Attachment: TUSCANY-1548.txt This patch enforces the requirement that multi-valued properties need an index in an xpath for access, and must be added with getList(). multi-valued properties should require indexed xpath Key: TUSCANY-1548 URL: https://issues.apache.org/jira/browse/TUSCANY-1548 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: all Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1548.txt The C++ SDO spec XPath clearly shows access to many-valued properties requiring [] or dot notation to denote an index. In order to retreive a whole list the SDO spec uses the getList() API to retrieve a list. 6.1.13. The get/set API on Class DataObject ... Multi-valued properties are located by the getList API. Multi-valued properties accessed in an xpath without an index should be invalid usage (Tuscany SDO is currently accesses the first element in the list). -- 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] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1631) Support Decimal in SDO C++
Support Decimal in SDO C++ -- Key: TUSCANY-1631 URL: https://issues.apache.org/jira/browse/TUSCANY-1631 Project: Tuscany Issue Type: Improvement Components: C++ SDO, C++ Specification Reporter: Graham Charters Priority: Minor The SDO C++ spec does not address Decimal. The current Tuscany implementation uses String to represent Decimal to avoid loss of precision. It does not internally know that the type is Decimal nor surface any APIs (e.g. set/getDecimal) and therefore there is no validation that the values provided are correct. This can cause problems when a schema defines an xsd:decimal type. An SDO based on that schema will allow an application to set the data to any string and this value can then be serialized out and is invalid against the schema. -- 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] Commented: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523531
]
Kelvin Goodson commented on TUSCANY-1527:
-
This kind of feature is something that has been mentioned a few times before,
and I think now is a good time to do something about it. Thank you for your
detailed description, I'll do some investigations and make some proper
comments soon.
Allow for custom data binding of DataObjects in a Swing UI
--
Key: TUSCANY-1527
URL: https://issues.apache.org/jira/browse/TUSCANY-1527
Project: Tuscany
Issue Type: New Feature
Components: Java SDO Implementation
Reporter: bert.robben
Fix For: Java-SDO-Next
Attachments: com.zip
We're developing 3-tier applications with a swing client, JBoss app server
and a couple of databases in the back-end. On the client side we use sdo
objects as model objects for our UI. As such, we need a mechanism for binding
our objects to the UI controls such that changes in the objects are reflected
in the UI and vice versa.
At the moment, there is no real standard for data binding and many different
implementations exist. As such, it would not be a good idea to build support
for this directly into the sdo core. Ideally, the sdo core would allow
implementations supporting data binding to be added as extensions [an
extension as in jar, module, bundle, component, ...]. This is a request for
supporting this in Tuscany SDO.
-
For our applications, we developed our own implementation of the sdo
specification. This implementation is designed to support that kind of
extensions. In the rest of this description, I'd like to show more details on
our implementation to make this more clear and to serve as food for a
possible discussion.
Our sdo core module defines the abstract class AbstractPartialDataObject
implementing DataObject. This class (together with its superclasses)
implements the majority of the bevahiour of DataObject. This includes
bi-directional property updates, type-safe properties, containment, ... It
doesn't implement however the basic access to property values.
Here's a code fragment.
public abstract class AbstractPartialDataObject extends AbstractDataObject
implements PartialDataObject {
protected abstract Object basicGet(Property property);
protected abstract void basicSet(Property property, Object value);
public Object get(Property property) { ... }
public void set(Property property, Object value) { ... }
...
}
The sdo core module also provides a non-abstract class
DataObjectImplementation that provides a simple implementation of this
abstract behaviour where the property values are stored in an ArrayList.
On top of that we defined an extension that deals with our UI requirements.
Our UI is based on a proprietary UI framework. This framework has the
following requirements:
- single valued properties should be exposed as XObservables. An XObservable
is a kind of ValueModel that provides access to a value (get/set) and also
allows for registration of change listeners
- multi valued properties should be exposed as ListModel instances. A
ListModel is a proprietary class (a bit similar to the javax.swing.ListModel)
that provides List functionality and also allows for change listeners
- the data object itself should allow registration of attribute change
listeners that are notified each time a property changes
The extension implements these requirements by providing an appropriate
subclass ObservableDataObject of AbstractPartialDataObject. The only other
pieces of code needed in the extension is an appropriate implementation of
DataFactory and a wrapper to deal with the differences between ListModel and
List.
Here's the class with the most important code snippets.
public class ObservableDataObject extends CompositePartialDataObject
implements {
private XObservable[] properties;
protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
super(type);
this.properties = new XObservable[type.getProperties().size()];
for (int i = 0; i properties.length; i++) {
initializeProperty(type.getProperty(i));
}
}
private XObservableObject initializeProperty(Property prop) {
XObservableObject observable =
XObservableFactory.create(prop.getType().getInstanceClass(), this);
if (prop.isMany()) {
observable.init(new DataObjectListModel(this, prop));
}
properties[prop.getIndex()] = observable;
return observable;
}
public XObservable getObservable(commonj.sdo.Property property) {
[jira] Created: (TUSCANY-1632) Serialization of xsd:token allows invalid content in SDO C++
Serialization of xsd:token allows invalid content in SDO C++ Key: TUSCANY-1632 URL: https://issues.apache.org/jira/browse/TUSCANY-1632 Project: Tuscany Issue Type: Bug Components: C++ SDO Reporter: Graham Charters Priority: Minor I can define an SDO based on an xml schema which uses the type xsd:token. This is mapped to a String SDO type. I can then create an SDO based off this model and set the string value of that property to something like foo bar . This is invalid against the schema (xsd:token), but valid against the SDO model (string), so I wouldn't necessarily expect an error or warning at this point. I can then write out the SDO as XML and it writes out the string value foo bar which is not valid against the xml schama. I would expect the data to either be modified to be serialized out following the schema (e.g. foo bar), or some kind of warning/error to be generated. -- 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]
Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
[jira] Updated: (TUSCANY-1629) Tuscany does not support using classes in the @Service annotation
[
https://issues.apache.org/jira/browse/TUSCANY-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Combellack updated TUSCANY-1629:
-
Attachment: ServiceAnnotationUsingClassTestCaseUpdate.patch
Attached a patch for the unit tests since it assumes that a @Service with a
class rather than an interface is invalid. Updated the test to test that it is
valid.
Tuscany does not support using classes in the @Service annotation
-
Key: TUSCANY-1629
URL: https://issues.apache.org/jira/browse/TUSCANY-1629
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-0.91
Environment: Linux
Was using Tuscany SVN revision 570353
Reporter: Mark Combellack
Fix For: Java-SCA-1.0
Attachments: ServiceAnnotationUsingClass.patch,
ServiceAnnotationUsingClassTestCaseUpdate.patch
The current implementation of Tuscany does not support using a class in the
@Service annotation.
For example, if I have:
@Service(MyService.class)
public class MyService {
public String op1(){
return op1 invoked;
}
}
The above example is valid from my understanding of the Java Common
Annotations and APIs specification because it says:
1628 The @Service annotation has the following attributes:
1629 • interfaces - The value is an array of interface or class objects that
should be exposed as services
1630 by this component.
1631 • value - A shortcut for the case when the class provides only a single
service interface.
The key phrase is in line 1629 or class objects
Tuscany throws the following exception:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
snipped setup code
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:119)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 16 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType:
Service must be an interface
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:118)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:411)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117)
... 17 more
Caused by:
Re: [RDB DAS] Consistent use of Parameters in Config
Below is one of the use cases where user will get some benefit:-
USE CASE:
bigtable{col1, col2,col50}
SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand(insert into bigtable values (?, ?,
?...50 times));
insertAdhoc.setParameter(ID, new Integer(6));
insertAdhoc.setParameter(LASTNAME, MyLastName);
insertAdhoc.setParameter(ADDRESS, MyLastAddress);
...
insertAdhoc.setParameter(Param50, Value50);
COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand(insert into bigtable values (?, ?,
?...50 times));
insertAdhoc.setParameter(1, new Integer(6));
insertAdhoc.setParameter(2, MyLastName);
insertAdhoc.setParameter(3, MyLastAddress);
...
insertAdhoc.setParameter(50, Value50);
Summary of previous discussion and main intention of this JIRA is to support
the below features:-
1) Add attribute Name to parameter for user convenience/readability
2) Support command.setParameter(name, value) for user
convenience/readability
3) Preserve existing ways of using parameters - e.g.
A
Continue supporting -
Table tableName=CUSTOMER
create sql=insert into customer values (?, ?, ?)
Parameters List=ID LASTNAME ADDRESS /Parameters
/create
/Table
But also support -
Table tableName=CUSTOMER
create sql=insert into customer values (?, ?, ?)
Parameters
Parameter name=ID index=1/ -- rest of the attributes optional
Parameter name=LASTNAME / -- rest of the attributes optional
Parameter name=ADDRESS / -- rest of the attributes optional
/Parameters
/create
/Table
Note: if +ve index is specified in Parameter, it is used, else
auto-increment similar to A is used. As List is an ordered collection, the
sequence appearing in the cofig file will be maintained. Partially
specifying indexes is not supported (i.e. give index for 2 out of 3 params
and leave one without it, is not supported)
B
Continue supporting -
cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
But also support -
cmd.setParameter(BOOKS.BOOK_ID, new Integer(1));
cmd.getParameter(BOOKS.BOOK_ID);
C
Continue supporting -
Command...
Parameter/
Parameter/
/Command
And
Command..No Params in Config, but directly setParameter(idx/name,
value) in program
/Command
But also support
Command insertAdhoc = das.createCommand(insert into CUSTOMER values (?, ?,
?));
insertAdhoc.setParameter(ID, new Integer(6));
insertAdhoc.setParameter(LASTNAME, MyLastName);
insertAdhoc.setParameter(ADDRESS, MyLastAddress);
Note: Convention over config is followed, if Parameters are not defined in
config, the sequence
should match the table columns [convention],else user should specify params
on command in config and specify index attributes in them [config]
4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS is
still at JDK1.4 level current code does not use generics.
5) Changes in config -
xsd:complexType name=Create
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name=Parameters
type=config:Parameters/
/xsd:sequence
xsd:attribute name=sql type=xsd:string/
/xsd:complexType
Similar for Update and Delete.
xsd:complexType name=Parameter
xsd:attribute name=name type=xsd:string/
xsd:attribute name=columnType type=xsd:string/
xsd:attribute name=direction type=xsd:string default=IN/
xsd:attribute name=index type=xsd:int/
/xsd:complexType
xsd:complexType name=Parameters
xsd:sequence
xsd:element maxOccurs=unbounded minOccurs=0 name=Parameter
type=config:Parameter/
/xsd:sequence
xsd:attribute name=List type=xsd:string/
/xsd:complexType
**Note** In Parameters Either List attribute OR Parameter element is used
BUT not both at a time. Attribut List is just to preserve existing
convenience as in 3) A
6) Existing test cases changes -
No changes needed in existing xml configs
Only 2 assertions changed in ProgrammaticConfigTests.
7) Exact code change and new test case details in JIRA-1462 comment
Regards,
Amita
On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I agree with Amita that for clarity is better to let the user set the
parameter name, for all those reasons she has argued on this thread so
far.
But, I don't I agree with to use the [1] instead of [2], because it's not
a
good practice to define the parameter names on only one string separated
by
spaces, it's not a good practice, mainly when we're dealing with XML.
My suggestion is to use [2], but add the xsd:attribute name=name
type=xsd:string on Parameter ComplexType and also keep the index
attribute on it. These way both methods, customer.set(pararmeterName,
value) and customer.setParameter(parameterIndex, value) will be
supported.
However, on any of these cases, the user will need to define a parameter N
times if there are N commands that use it. I don't see any solution
Re: Naming webapp samples *-webapp
+1 Simon Simon Laws wrote: On 8/29/07, Venkata Krishnan [EMAIL PROTECTED] wrote: +1 - Venkat On 8/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Some of our webapp samples are missing a webapp suffix, I'm going to rename them as follows: - helloworld-jsonrpc - helloworld-jsonrpc-webapp - helloworld-dojo - helloworld-dojo-webapp - calculator-webapp-ws - calculator-ws-webapp If there's no objection I'll do that sometime tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NoRegisteredCallbackException check
I have now completed the implementation of approach 2. Another major advantage of approach 2 over approach 1 that I did not include in my previous list is that it is far more efficient. The interceptor only needs to be added to the chains if the client service does not implement the callback interface. This test could be quite expensive in some cases and it is much better to keep it off the runtime invocation path. If the interceptor is present, then it just needs to check that there is a callback object and throw NoRegisteredCallbackException if not. This is a very cheap operation. The new SPI method added for this change is in a new interface ImplementationProvider2 that does not extend ImplementationProvider. This is because JavaImplementationProvider extends ScopedImplementationProvider, which extends ImplementationProvider. I didn't think it was appropriate to change the inheritance of ScopedImplementationProvider as this would have affected any other subclasses of ScopedImplementationProvider in addition to JavaImplementationProvider. ImplementationProvider2 contains a single method void processReferenceWire(RuntimeWire wire); which allows for any kind of postprocessing of the reference wire by the implementation provider. I'm now creating a patch for this implementation that I will attach to TUSCANY-1500. Simon Simon Nash wrote: I am working on adding the check required by the second paragraph of section 1.6.7.5 in the Java Common Annotations and APIs spec (to throw NoRegisteredCallbackException on a client outbound call if a callback is possible, the client service does not implement the callback interface, and there is no registered callback object). I see two possible approaches for doing this: 1. Put this check in the core invocation logic. The code needed to perform the check is specific to the Java component implementation, so putting this checking code in the core would require the core to have a dependency on the implementation-java module, which is not desirable. To avoid this we would add need a new SPI to perform the check. This SPI can optionally be implemented by any component implementation type that wants to support callbacks and enforce this check. 2. Put this check in an outbound interceptor. The is currently an interceptor in the trunk for doing this (CallbackInterfaceInterceptor), but it is not used anywhere and it doesn't currently contain the checking code. This interceptor would need to have checking code specific to the component implementation type that is making the outbound implementation. This means we would need a new SPI to give implementation providers the opportunity to add an interceptor to the invocation chain for their outbound calls. (They can currently only do this for their inbound calls.) So both approaches require a new SPI. I have currently implemented and tested approach 1, using a new assembly SPI interface CallbackImplementation for component implementations to optionally implement, containing a single method boolean supportsCallbackInterface(Interface callbackInterface); which is invoked by the core to perform the implementation-specific test whether or not this componext implementation type implements the passed callback interface. I have added an implementation of this method to JavaImplementationImpl. I could submit this as a patch, but I'm beginning to lean more towards approach 2, mostly because I don't feel very comfortable adding this test to an assembly SPI when its purpose is to perform a runtime check. Also, the existence of CallbackInterfaceInterceptor in the trunk seems to be an indication that someone has thought about this previously and decided on the interceptor approach. So I have been thinking about how to do this using approach 2. My thoughts on approach 2 are a bit more sketchy because I haven't implemented it yet. It would need a new core SPI interface, perhaps ImplementationProvider2 extending ImplementationProvider, which could be optionally implemented by implementation providers. This interface would contain a single method, perhaps void interceptOutboundCall(InvocationChain chain); An implementation provider that wanted to perform this callback check would implement this method and create an implementation-specific subclass of CallbackInterfaceInterceptor that performs the check for its component implementation type, and add this interceptor to the invocation chain. This has the following advantages over approach 1: 1. The new SPI is part of the runtime SPI rather than the assembly SPI. 2. The new SPI could be used for other purposes, not just for this callback check. 3. It seems more in line with with the original design intention that led to the creation of CallbackInterfaceInterceptor. I'll try prototyping this to see how I get on with it. Any opinions on the merits of these approaches (or other suggestions) would be much
[jira] Updated: (TUSCANY-1462) Consistent use of Parameters in Config
[ https://issues.apache.org/jira/browse/TUSCANY-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1462: - Attachment: 1462.patch List of files changed: 1) Command 2) New - ParametersExtendedImpl 3) New - ParameterExtendedImpl 4) SDODataTypeHelper 5) ConfigHelper 6) MappingWrapper 7) DeleteGenerator 8) InsertGenerator 9) UpdateGenerator 10) ConfigUtil 11) CollisionParameter 12) ManagedParameterImpl 13) OptimisticWriteCommandImpl 14) ChangeOperation 15) CommandImpl 16) Statement 17) DeleteCommandImpl 18) InsertCommandImpl 19) WriteCommandImpl 20) ProgrammaticConfigTests 21) BasicCustomerMappingWithCUD.xml 22) BasicCustomerMappingWithCUD2.xml 23) BasicCustomerMappingWithInvalidCUD.xml 24) config.xsd 25) New - NamedParameterTests 26) New - namedParameter.xml 27) DASImpl 28) UpdateCommandImpl 29) ReadCommandImpl 30) SDODataTypes 31) SPCommandImpl 32) AllCommonTests Note: Stored Procedures are not supported for named params get/set Consistent use of Parameters in Config -- Key: TUSCANY-1462 URL: https://issues.apache.org/jira/browse/TUSCANY-1462 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1462.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19970.html Need to followup above mail thread and confirm required changes. -- 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] Resolved: (TUSCANY-1590) Conversation ID's are not unique with multiple references in same component
[ https://issues.apache.org/jira/browse/TUSCANY-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-1590. - Resolution: Fixed The conversational scope container now allows component instances to be registered against more than one coversation id. So there is no need now to share conversation ids between reference in the case of stateful callacks. Conversation ID's are not unique with multiple references in same component Key: TUSCANY-1590 URL: https://issues.apache.org/jira/browse/TUSCANY-1590 Project: Tuscany Issue Type: Bug Reporter: Lou Amodeo Assignee: Simon Laws Fix For: Java-SCA-1.0 I am seeing that the generated conversationId's are not unique when there ar 2 (1) component references. Given the following SCDL both references get the same ID assigned. component name=FrontEndConversationalService implementation.java class=test.sca.bindings.ws.components.FrontEndConversationImpl/ reference name=aBackEndConversationalServiceRef binding.ws wsdlElement=http://components.ws.bindings.sca.test#wsdl.port(BackEndConversationalService/BackEndConversationalServiceSOAP11port)/ /reference reference name=aBackEndConversationalServiceRef2 binding.ws wsdlElement=http://components.ws.bindings.sca.test#wsdl.port(BackEndConversationalService/BackEndConversationalServiceSOAP11port)/ /reference /component -- 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] Commented: (TUSCANY-1562) Service method's throws Exception clause create problem at time of on fly generation of wsdl
[
https://issues.apache.org/jira/browse/TUSCANY-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523582
]
Simon Nash commented on TUSCANY-1562:
-
Hi Nishant. Please can you attach the Java code that you used to generate the
failing WSDL. I'm interested in seeing exactly how the exception is defined.
Thanks.
Service method's throws Exception clause create problem at time of on fly
generation of wsdl
--
Key: TUSCANY-1562
URL: https://issues.apache.org/jira/browse/TUSCANY-1562
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.99, Java-SCA-Next
Environment: Windows XP, tuscany-sca-1.0-incubating-SNAPSHOT,
Eclipse, Tomcat 6, maven
Reporter: Nishant Joshi
Fix For: Java-SCA-1.0
Attachments: Example(Using axis2_1.3-RC2).wsdl,
localhost.2007-08-24.log
Hi, I am creating a simple programme in which when i declared throws clause
in my method, following error is occured, when i try to deploy my war file in
to Tomcat. WAR is generated using maven.
I have also tried using custom Exception but result is same.
Now when i have catch the exception in service method then
problem is solved and wsdl is generated.(so now there is no throws clause).
So in sort problem is defining throws clause in service method create problem.
Note: Following error is in localhost.log file of Tomcat 6.0 at time of
starting of Tomcat.I am using Nightly build SNAPSHOT that i have mentioned in
environment.
SEVERE: exception initializing SCADomain
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts
for fault message : {http://example.com}Exception
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82)
at
org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63)
at
org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4334)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts
for fault message : {http://example.com}Exception
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:169)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 27 more
Caused by: org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no
[jira] Closed: (TUSCANY-1371) C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop)
[ https://issues.apache.org/jira/browse/TUSCANY-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder closed TUSCANY-1371. -- Resolution: Fixed Resolved with applied patch. C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) - Key: TUSCANY-1371 URL: https://issues.apache.org/jira/browse/TUSCANY-1371 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1371.txt The Tuscany C++ SDO specification interface introduces off-spec member function overloads for getProperty. The SDO 2.1 spec introduces the member function: DataObject::getInstanceProperty(const std::string prop), whicfh should replace these functions. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 6:35 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) Hi, In the DataObject interface, these member functions are present which are not in the C++ 2.1 specification: virtual const Property getProperty(unsigned int index) = 0; virtual const Property getProperty(const char* prop) = 0; virtual const Property getProperty(const SDOString prop) = 0; Since the 2.1 spec now has getInstanceProperty(const std::string prop), would it be a good idea to file a Jira/patch to replace these member functions with it in the specification interface? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] Closed: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject
[ https://issues.apache.org/jira/browse/TUSCANY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder closed TUSCANY-1370. -- Resolution: Fixed Resolved with applied patches. C++ SDO spec compliance/portability: DataObject --- Key: TUSCANY-1370 URL: https://issues.apache.org/jira/browse/TUSCANY-1370 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issues -- all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1370.txt, TUSCANY-1370v2.txt, TUSCANY-1370v2_b.txt The specification interface DataObject.h exposes off-spec member functions, these should be made internal to the implementation. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 6:34 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataObject Hi, In the DataObject interface, these member functions are exposed which aren't in the C++ 2.1 spec: virtual SDO_API bool hasProperty(const char* name) = 0; virtual SDO_API bool hasProperty(const SDOString name) = 0; virtual SDO_API DataFactory* getDataFactory() = 0; virtual SDO_API void setUserData(const char* path,void* value) = 0; virtual SDO_API void setUserData(const SDOString path, void* value) = 0; virtual SDO_API void setUserData(unsigned int propertyIndex, void* value) = 0; virtual SDO_API void setUserData(const Property property, void* value) = 0; virtual SDO_API void setUserData(void* value) = 0; virtual SDO_API void* getUserData(const char* path) = 0; virtual SDO_API void* getUserData(const SDOString path) = 0; virtual SDO_API void* getUserData(unsigned int propertyIndex) = 0; virtual SDO_API void* getUserData(const Property property) = 0; virtual SDO_API void* getUserData() = 0; virtual SDO_SPI const char* objectToXPath() = 0; Would it be appropriate to file a Jira/patch to have these removed from the spec interface? Or alternatively a Jira to submit them to the spec committee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] Closed: (TUSCANY-1366) C++ SDO spec portability: SDORuntimeException off-spec member functions
[
https://issues.apache.org/jira/browse/TUSCANY-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Yoder closed TUSCANY-1366.
--
Resolution: Fixed
Resolved with applied patch.
C++ SDO spec portability: SDORuntimeException off-spec member functions
---
Key: TUSCANY-1366
URL: https://issues.apache.org/jira/browse/TUSCANY-1366
Project: Tuscany
Issue Type: Improvement
Components: C++ SDO, C++ Specification
Affects Versions: Cpp-M3
Environment: portability issue -- all platforms
Reporter: Michael Yoder
Fix For: Cpp-Next
Attachments: TUSCANY-1366.txt
Tuscany C++ SDO specification class SDORuntimeException has off-spec member
functions used by SCA (shown in the e-mail thread below). It would seem that
for portability these should be taken internal to Tuscany SDO, or submitted
to the spec committee.
-Original Message-
From: Michael Yoder
Sent: Thursday, June 21, 2007 7:37 PM
To: 'tuscany-dev@ws.apache.org'
Subject: RE: C++ SDO spec compliance/portability: SDORuntimeException
Thanks Pete,
Yes, these issues I am putting together and posting came up when doing a
portability study using HydraSDO to build Tuscany SCA. Since the SDO spec is
separate from SCA, we were thinking this would be a good goal. That seems to
mean making them internal to Tuscany SDO or taking them to the committee.
Michael
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 9:02 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec compliance/portability: SDORuntimeException
Michael,
An interesting set of questions! I'm not convinced that adding methods to the
spec api classes is a compliance issue (in fact it may be impossible to
implement without modifying the spec apis ... constructors etc.) but it could
be a portability issue if it is not clear that the methods are implementation
specific.
The methods below are added so that an SDORuntimeException can contain a
stack of locations indicating where it was thrown/rethrown etc.. These are
only used within the Tuscany implementation so I guess could be moved to
protected and make the classes that use them friends?? I'm not sure how
useful these are anyway but the exception class pre-dates it being used for
SDORuntimeException.
There are also methods to allow simple streaming:
catch(SDORuntimeException e)
{
cout e;
}
I like the simplicity of this but I guess we could write an SDOUtils method
to do something similar instead.
I'm not sure if any of these should be mandated by the specification.
Cheers,
On 21/06/07, Michael Yoder [EMAIL PROTECTED] wrote:
Hi,
The Tuscany SDO C++ class SDORuntimeException has these public member
functions which do not appear in the C++ 2.1 specification:
SDO_API severity_level getSeverity() const; SDO_API void
setSeverity(severity_level sev); SDO_API void setMessageText(const
std::string msg_text); SDO_API void setExceptionLocation(const
std::string file,
unsigned long line,
const std::string function=);
SDO_API void setLocation(const std::string file,
unsigned long line,
const std::string function=);
SDO_API void trace(const std::string text=%1:\n %3 %4 %2);
SDO_API virtual ostream PrintSelf(ostream os) const; SDO_API friend
ostream operator (ostream os, const SDORuntimeException except);
What's the rational behind these additional member functions? Would it
be appropriate to file a bug to have them removed from the public API?
Or alternatively a bug for them to be submitted to the spec committee?
Thanks,
Michael Yoder
Software Developer
Rogue Wave Software
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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] Closed: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer
[
https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Yoder closed TUSCANY-1376.
--
Resolution: Fixed
Resolved with applied patches.
C++ SDO spec portability: RefCountingPointer
Key: TUSCANY-1376
URL: https://issues.apache.org/jira/browse/TUSCANY-1376
Project: Tuscany
Issue Type: Bug
Components: C++ SDO, C++ Specification
Affects Versions: Cpp-M3
Environment: all platforms
Reporter: Michael Yoder
Fix For: Cpp-Next
Attachments: TUSCANY-1376.txt, TUSCANY-1376v2.txt
Tuscany C++ SDO class RefCounting pointer has the member function:
operator T*() {return pointee;}
which expose the raw dumb pointer for SDO classes (for the common use of
smart pointers). This member function is used by SCA, and raises undesirable
object lifetime and allowed operation issues. The member function should be
replaced with a safe (referenced in the below -email thread) conversion to
bool member function.
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 6:16 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec portability: RefCountingPointer
Michael, I strongly suspect that the operator T*() ws put in for a good
reason. It may be a good idea to remove this but it may be non-trivial.
The ostream operator is very useful and there is a default implementation
in RefCountingObject so that objects inheriting from RefCounting object do
not need to implement anything... but they can if appropriate.
You are raising a lot if issues which is great and it would be excellent to
get Tuscany SDO up to 2.1 spec level. I suspect there will be hundreds of
issues some of which may require large re-writes/refactoring of the Tuscany
SDO Code!! Raising these as Jiras is the best thing to do so we can track
them. Helping fix them by submitting patches would be even better ;-)
Cheers,
On 22/06/07, Michael Yoder [EMAIL PROTECTED] wrote:
Hi,
In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO
class RefCountingPointer has functions used externally by SCA:
operator T*() {return pointee;}
friend std::ostream operator (std::ostream os, const
RefCountingPointerT ptr)
It looks like the conversion to T* function may have been put in
originally as a porting alternative to a member function template, but
may not be needed any more since the member template is now included
outside the #ifdef.
Exposing the dumb pointer is undesirable since it raises object
lifetime issues and allows other unwanted operations. Having a
conversion to bool is convenient however, and can be implemented
safely using a member function pointer trick (see:
http://www.artima.com/cppsource/safebool.html).
The shift operator also seems undesireable since it places a burden on
all classes which use smart pointers to implement toString
functionality.
How does it sound to raise a Jira to have these member functions
removed?
Thanks,
Michael Yoder
Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
HydraSDO
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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] Closed: (TUSCANY-1368) C++ SDO portability: class interface Type off-spec enum values
[ https://issues.apache.org/jira/browse/TUSCANY-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder closed TUSCANY-1368. -- Resolution: Fixed Resolved with applied patch. C++ SDO portability: class interface Type off-spec enum values -- Key: TUSCANY-1368 URL: https://issues.apache.org/jira/browse/TUSCANY-1368 Project: Tuscany Issue Type: Improvement Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1368.txt C++ SDO specification class interface Type has enum values (OpenDataObjectType, num_type)which are not in the specification, and are being used externally by SCA. It would seem that for SDO portability these should be taken internal to SDO or submitted to the spec committee. -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 9:21 AM To: tuscany-dev@ws.apache.org Subject: Re: SDO spec compliance/portability: Type enums the num_type is just a convenient way to know the extent of an enum and is common practice. I guess the OpenDataObjectType must be a Tuscany specific extension to handle open types. I'd need to do some research to determine if this is missing from the spec or can be removed. Please raise a Jira for the renaming of IntegerType. It may be useful to raise Jiras for all these issues so we can track them. Cheers, On 21/06/07, Michael Yoder [EMAIL PROTECTED] wrote: Hi, The Tuscany SDO C++ class Type::Types enum has these values which do not appear in the C++ 2.1 specification: - OpenDataObjectType - num_type Would it be appropriate to file a bug to remove the additional values? Or alternatively a bug for them to be submitted to the spec committee? In addition the 2.1 spec renamed the enum value IntegerType to IntType. Would it be appropriate to file a bug to have this value renamed? Thanks, Michael Yoder Software Developer Rogue Wave Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- 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] Closed: (TUSCANY-1374) C++ SDO spec portability: DataObjectInstance
[ https://issues.apache.org/jira/browse/TUSCANY-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder closed TUSCANY-1374. -- Resolution: Fixed Resolved with applied patch. C++ SDO spec portability: DataObjectInstance Key: TUSCANY-1374 URL: https://issues.apache.org/jira/browse/TUSCANY-1374 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1374.txt The Tuscany C++ SDO implementation has a public class DataObjectInstance used by SCA examples. For portability it would be desirable for the examples to use the spec API, and have this non-spec class removed or made internal to the implementation. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:28 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: DataObjectInstance Hi, Tuscany C++ SDO introduces an off-spec class used externally by a few SCA samples, DataObjectInstance. What is the rationale for having this class? Would it be alright for the samples to use SDO API smart pointers instead, and remove this class, or is this a concept that might be worth considering for the specification? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] Closed: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
[ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder closed TUSCANY-1375. -- Resolution: Fixed Resolved with applied patch. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath
I resolved these jiras: TUSCANY-1366 - C++ SDO spec portability: SDORuntimeException off-spec member functions TUSCANY-1368 - C++ SDO portability: class interface Type off-spec enum values TUSCANY-1370 - C++ SDO spec compliance/portability: DataObject TUSCANY-1371 - C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) TUSCANY-1374 - C++ SDO spec portability: DataObjectInstance TUSCANY-1375 - C++ SDO spec portability: C++ type definition API TUSCANY-1376 - C++ SDO spec portability: RefCountingPointer For the others: 1372 and 1442 have patches pending I believe, and I think 1548 will require me to add another patch with additional testing Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 3:13 AM To: tuscany-dev@ws.apache.org Subject: Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath Patch applied. Can you resolve/close the Jiras if the work is now complete on them? Cheers, On 28/08/2007, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I have uploaded a patch for TUSCANY-1548. If someone could review and apply it that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 9:52 AM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath [ https://issues.apache.org/jira/browse/TUSCANY-1548?page=com.atlassian. ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1548: --- Attachment: TUSCANY-1548.txt This patch enforces the requirement that multi-valued properties need an index in an xpath for access, and must be added with getList(). multi-valued properties should require indexed xpath Key: TUSCANY-1548 URL: https://issues.apache.org/jira/browse/TUSCANY-1548 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: all Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1548.txt The C++ SDO spec XPath clearly shows access to many-valued properties requiring [] or dot notation to denote an index. In order to retreive a whole list the SDO spec uses the getList() API to retrieve a list. 6.1.13. The get/set API on Class DataObject ... Multi-valued properties are located by the getList API. Multi-valued properties accessed in an xpath without an index should be invalid usage (Tuscany SDO is currently accesses the first element in the list). -- 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] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
implementation.osgi and SCA annotations
Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. Thank you... Regards, Rajini
Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath
Thanks for that. I applied 1372 and 1442 (with minor change) earlier today. Cheers, On 29/08/2007, Michael Yoder [EMAIL PROTECTED] wrote: I resolved these jiras: TUSCANY-1366 - C++ SDO spec portability: SDORuntimeException off-spec member functions TUSCANY-1368 - C++ SDO portability: class interface Type off-spec enum values TUSCANY-1370 - C++ SDO spec compliance/portability: DataObject TUSCANY-1371 - C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) TUSCANY-1374 - C++ SDO spec portability: DataObjectInstance TUSCANY-1375 - C++ SDO spec portability: C++ type definition API TUSCANY-1376 - C++ SDO spec portability: RefCountingPointer For the others: 1372 and 1442 have patches pending I believe, and I think 1548 will require me to add another patch with additional testing Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 3:13 AM To: tuscany-dev@ws.apache.org Subject: Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath Patch applied. Can you resolve/close the Jiras if the work is now complete on them? Cheers, On 28/08/2007, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I have uploaded a patch for TUSCANY-1548. If someone could review and apply it that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 9:52 AM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath [ https://issues.apache.org/jira/browse/TUSCANY-1548?page=com.atlassian. ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1548: --- Attachment: TUSCANY-1548.txt This patch enforces the requirement that multi-valued properties need an index in an xpath for access, and must be added with getList(). multi-valued properties should require indexed xpath Key: TUSCANY-1548 URL: https://issues.apache.org/jira/browse/TUSCANY-1548 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: all Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1548.txt The C++ SDO spec XPath clearly shows access to many-valued properties requiring [] or dot notation to denote an index. In order to retreive a whole list the SDO spec uses the getList() API to retrieve a list. 6.1.13. The get/set API on Class DataObject ... Multi-valued properties are located by the getList API. Multi-valued properties accessed in an xpath without an index should be invalid usage (Tuscany SDO is currently accesses the first element in the list). -- 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] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1372) C++ SDO spec compliance/portability: DataFactory
[ https://issues.apache.org/jira/browse/TUSCANY-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder closed TUSCANY-1372. -- Resolution: Fixed Resolved with applied patch. C++ SDO spec compliance/portability: DataFactory Key: TUSCANY-1372 URL: https://issues.apache.org/jira/browse/TUSCANY-1372 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1372.txt The Tuscany C++ SDO specification interface DataFactory.h exposes off-spec member functions. These should be made internal to the implementation. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 6:54 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataFactory Hi, In the DataFactory interface, the below member functions are exposed which aren't in the C++ 2.1 spec. Would it be appropriate to file a Jira/patch to have these removed from the spec interface? SDO_API virtual DataFactoryPtr clone(); virtual SDO_API bool generateInterface(const char* fileroot, const char *factoryname) = 0; virtual SDO_API bool generateInterface(const SDOString fileroot, const SDOString factoryname) = 0; virtual SDO_API void setPropertySubstitute( const char* uri, const char* inTypeName, const char* propname, const char* subname, const char* subTypeUri, const char* subTypeName) = 0; virtual SDO_API void setPropertySubstitute( const SDOString uri, const SDOString inTypeName, const SDOString propname, const SDOString subname, const SDOString subTypeUri, const SDOString subTypeName) = 0; virtual SDO_API void setPropertySubstitute( const Type containertype, const char* propname, const char* subname, const Type subtype) = 0; virtual SDO_API void setPropertySubstitute( const Type containertype, const SDOString propname, const SDOString subname, const Type subtype) = 0; Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] Resolved: (TUSCANY-1442) XML Schemas under tuscany/cpp/sca/runtime/extensions are invalid
[ https://issues.apache.org/jira/browse/TUSCANY-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder resolved TUSCANY-1442. Resolution: Fixed Resolved with applied patch. XML Schemas under tuscany/cpp/sca/runtime/extensions are invalid Key: TUSCANY-1442 URL: https://issues.apache.org/jira/browse/TUSCANY-1442 Project: Tuscany Issue Type: Bug Components: C++ SCA Environment: all Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1442.txt The XML Schemas (listed below) for the extensions are invalid. They reference the SCA schema types without including those schemas. These can be made valid by adding an include for the sca types. e.g. include schemaLocation=../../../../xsd/sca.xsd/ tuscany\cpp\sca\runtime\extensions/cpp/xsd/sca-implementation-cpp.xsd tuscany\cpp\sca\runtime\extensions/cpp/xsd/sca-interface-cpp.xsd tuscany\cpp\sca\runtime\extensions/php/xsd/sca-implementation-php.xsd tuscany\cpp\sca\runtime\extensions/python/xsd/sca-implementation-python.xsd tuscany\cpp\sca\runtime\extensions/python/xsd/sca-interface-python.xsd tuscany\cpp\sca\runtime\extensions/rest/xsd/sca-binding-rest.xsd tuscany\cpp\sca\runtime\extensions/rest/xsd/sca-interface-rest.xsd tuscany\cpp\sca\runtime\extensions/ruby/xsd/sca-implementation-ruby.xsd tuscany\cpp\sca\runtime\extensions/sca/xsd/sca-binding-sca.xsd tuscany\cpp\sca\runtime\extensions/ws/xsd/sca-binding-webservice.xsd -- 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-1633) To support reference target for SCA Binding using URI on r558780
To support reference target for SCA Binding using URI on r558780
---
Key: TUSCANY-1633
URL: https://issues.apache.org/jira/browse/TUSCANY-1633
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Environment: Windows
Reporter: Yang Lei
We assume we can use SCA binding 's URI for its target service. We see the
following problems:
1. When there is a SCABinding element under the reference or we are trying to
create one when there is none, the URI is not set. So added a else block to
the following code in CompositeBuilderImpl,matchBinding method:
if (binding instanceof WireableBinding) {
.
} else {
//use terget serviceBinding's URI as referece's binding
URI
//This is to support reference target
if (cloned instanceof SCABinding cloned.getURI() ==
null) {
cloned.setURI(serviceBinding.getURI());
}
}
2. When there is a SCABinding element defined on service side, URI is not set
we need to add the else block:
// Create and configure an SCA binding for the service
if (componentService.getBindings().isEmpty()) {
SCABinding scaBinding =
componentService.getBinding(SCABinding.class);
if (scaBinding == null) {
scaBinding = scaBindingFactory.createSCABinding();
scaBinding.setName(componentService.getName());
componentService.getBindings().add(scaBinding);
}
scaBinding.setComponent(component);
scaBinding.setURI(uri);
}else
{
SCABinding scaBinding =
componentService.getBinding(SCABinding.class);
if (scaBinding != null scaBinding.getURI()==null) {
scaBinding.setURI(uri);
}
}
--
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: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
Can you please add information to the user doc about how to run Tuscany in Geronimo? If you start with a wiki page, I'll link to it from the user doc. Thanks, haleh On 8/29/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi
Re: some error when i test the samples
flying fish wrote: hi , i have some questions to ask for help , thank you at first! when i want to test the samples , like the tuscany-sca-1.0-incubator-M2-samples\standalone\calculator when i Building and Running the Samples , i input mvn -N install in , however, there are the errors informations as follows: Hi, tuscany-sca-1.0-incubator-M2-samples is from Nov 2006, a little too old :) Can you try our last published release instead? Release 0.91 is available there: http://incubator.apache.org/tuscany/sca-java-releases.html We're also about to publish release 0.99, available there: http://people.apache.org/~antelder/tuscany/0.99-RC2/ Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins
This is a nice move. I will look into the code and hopefully contribute to this area. Thanks, Raymond - Original Message - From: Vamsavardhana Reddy [EMAIL PROTECTED] To: Geronimo Dev [EMAIL PROTECTED]; tuscany-dev@ws.apache.org Sent: Wednesday, August 29, 2007 4:36 AM Subject: Tuscany plugin for Geronimo moved from Geronimo sandbox to Geronimo Plugins Hi, I have moved the Tuscany Plugin for Geronimo from sandbox to Geronimo Plugins. The svn URL is https://svn.apache.org/repos/asf/geronimo/plugins/tuscany . I had to add a few additional repositories to the parent pom so that the plugin can be built successfully with a clean m2 local repository. The plugin can be installed on Geronimo 2.0.1. There is a version of the plugin for Geronimo Tomcat distribution and another for Geronimo Jetty distribution. There are a few samples in Geronimo sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/samplesthat can be used with the plugin. Thanks and regards, Vamsi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
Simon Laws wrote: On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/20/07, Simon Nash [EMAIL PROTECTED] wrote: See inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 17, 2007 9:27 AM Subject: Re: Monitoring, logging and exceptions (again) [snip] ant elder wrote: And also my 2p inline... ...ant On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: A number of different requirements have been discussed and solutions proposed. My 2p (I'm using Raymond's definitions b.t.w) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) I feel that tracing of execution paths through the Tuscany codebase would be useful but agree that it's a lot of work and will be difficult to maintain and keep consistent if we did it manually. I'm happy that this is the responsibility of whoever wants to trace through the code and not a core part of the codebase. For the Tuscany developer community AspectJ have been proposed a couple of times and support has been prototyped. We could choose SLF4J as the interface through which messages are output. I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a facade for logging APIs, so you can code to the SLF4J API and then plug in whatever logging impl you like, but if the only logging calls we have are confined to a single tracing aspect we might as well just code that aspect to a specific logging API like JDK logging. That avoids the extra dependency on SLF4J and anyone can add additional aspects if they really want to use a different logger. The main other benefit of SLF4J is its parameterized message logging (avoids all the if(logger.isDebugEnabled()) ) but again if all the logging calls are in a single aspect thats not so useful. Makes sense to me. If we go the aspectj route for tracing method entry/exit, I agree that using the JDK logger directly is simpler. Since the aspect is on the side, we're flexible. JDK logger can be default and it can be replaced easily if the embedders or users choose to do so. A few more questions on this: What dependencies will aspectj add to our distribution? aspectjweaver is more than 1Mb, do we need it? I'll try to spend some time to explore both the compile-time and load-time weaving. What about mid-method logging of specific interesting events, for example the contents of requests as the enter and leave bindings and implementation types and things like that? That sort of logging is often all a lot of users want to see not the detail tracing of every method entry/exit. Could we add things like this in specific places? +1 for the ability to produce this level of information. This is my preferred approach for debugging or understanding how some part of the code works. Having every method entry and exit produce a trace line often creates a huge amount of output that obscures the essential details of what is happening. Can this mid-method logging be split in two categories? a) Debug tracing A simple solution is to split the method in two, and then leverage the entry/exit method tracing as discussed above. In many cases this would lead to a convoluted code structure with local variables needing to be passed as parameters between the two methods, or methods that contain a single line of code (if a trace line needs to be produced from within a loop). We can use JDK logger to add statements in the middle of a method. Then we can use an aspect to capture such calls to dump out the information. For example, if we have the following statement in a method: logger.debug(...); The apsect can trap it by a point cut like call * java.util.logger.Logger.debug(..). If the logger call is already there, why is an aspect needed to trap it? Why not just let it execute? b) End-user readable information (info that a binding is sending/receiving a message for example) This falls into the second category discussed in this thread, reporting significant events to a management console. The above suggestion should help too. The key here is to have some calls to indicate such requirements and they can be then trapped to provide the concrete logic. I think we're starting to see concrete solutions for (a) with aspectj. I have not seen any real concrete proposal for (b) yet. --
[jira] Updated: (TUSCANY-1605) web-resource sample ant script does a compile as part of ant run
[ https://issues.apache.org/jira/browse/TUSCANY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1605: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 web-resource sample ant script does a compile as part of ant run -- Key: TUSCANY-1605 URL: https://issues.apache.org/jira/browse/TUSCANY-1605 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windowx XP Reporter: Simon Nash Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 In the 0.99 binary distro, the web-resource sample's ant script's run target does a compile before the run. This is contrary to our normal samples convention that ant run does not do a compile. -- 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] Commented: (TUSCANY-1605) web-resource sample ant script does a compile as part of ant run
[ https://issues.apache.org/jira/browse/TUSCANY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523647 ] Jean-Sebastien Delfino commented on TUSCANY-1605: - This turned to be a more complex issue :) 1. A bug in the SCA contribution runtime. JarContributionPackageProcessor was not creating DeployedArtifact models for folders. 2. Bugs in our embedded TomcatServer and JettyServer which didn't handle in-jar resources correctly. I am fixing (1) and (2), allowing implementation.resource components to serve in-jar resources normally. I'll also remove the workaround from the sample build.xml. web-resource sample ant script does a compile as part of ant run -- Key: TUSCANY-1605 URL: https://issues.apache.org/jira/browse/TUSCANY-1605 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windowx XP Reporter: Simon Nash Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 In the 0.99 binary distro, the web-resource sample's ant script's run target does a compile before the run. This is contrary to our normal samples convention that ant run does not do a compile. -- 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] Resolved: (TUSCANY-1605) web-resource sample ant script does a compile as part of ant run
[ https://issues.apache.org/jira/browse/TUSCANY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1605. - Resolution: Fixed web-resource sample ant script does a compile as part of ant run -- Key: TUSCANY-1605 URL: https://issues.apache.org/jira/browse/TUSCANY-1605 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windowx XP Reporter: Simon Nash Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 In the 0.99 binary distro, the web-resource sample's ant script's run target does a compile before the run. This is contrary to our normal samples convention that ant run does not do a compile. -- 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-1482) CompositeProcessor does not write out Property objects completely
[ https://issues.apache.org/jira/browse/TUSCANY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1482: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 CompositeProcessor does not write out Property objects completely - Key: TUSCANY-1482 URL: https://issues.apache.org/jira/browse/TUSCANY-1482 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Reporter: Brent Daniel Fix For: Java-SCA-1.0 CompositeProcessor will write out a Property with its name, but will ignore other attributes such as source, many, or must supply. This is true of both component properties and composite properties. -- 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-1451) Fix the algorithm to determine references for an unannotated java class
[ https://issues.apache.org/jira/browse/TUSCANY-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1451: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Fix the algorithm to determine references for an unannotated java class --- Key: TUSCANY-1451 URL: https://issues.apache.org/jira/browse/TUSCANY-1451 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-Next Reporter: Raymond Feng Fix For: Java-SCA-1.0 http://www.osoa.org/display/Main/Errata+for+Java+Component+Implementation+V1.00 4. Fix and clarify algorithm for determining references of an unannotated POJO (section 1.2.7) Replace the algorithm on lines 369-377 with the following: 1) If the Java type is an interface annotated with @Remotable, then it's a reference. 2) Otherwise, if the Java type is an array whose element type is an interface annotated with @Remotable, then it's a reference. 3) Otherwise, if the Java type is a java.util.Collection or a sub-interface or sub-class of it, if the parameterized type of the collection is an interface annotated with @Remotable, then it's a reference. 4) Otherwise it's a property. -- 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-1516) Possible promotion problem with Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1516: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad Fix For: Java-SCA-1.0 Attachments: default.composite, MyServiceImpl.java, mySimpleService.composite, MyTotalService.java, MyTotalServiceImpl.java, MyTotalServiceTest.java I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- 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] Assigned: (TUSCANY-1497) Add full support for service references (which can be passed accross binding protocols)
[ https://issues.apache.org/jira/browse/TUSCANY-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1497: - Assignee: Raymond Feng Add full support for service references (which can be passed accross binding protocols) --- Key: TUSCANY-1497 URL: https://issues.apache.org/jira/browse/TUSCANY-1497 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-Next The Java spec defines CallableReference and ServiceReference. At this moment, we only have limited support for local cases (keeping pointers to java objects). We need to support the marshaling/unmarshaling of service references accross binding protocols. -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1347: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 IndexOutOfBoundsException thrown when trying to locate a service that includes a callback - Key: TUSCANY-1347 URL: https://issues.apache.org/jira/browse/TUSCANY-1347 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-1.0 Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar More complete description and test case to follow Here is the exception thrown... [6/14/07 17:59:55:187 MDT] 0020 SystemErr R java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) at org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1208) Service using callback and methods that don't perform callback over WS binding hangs
[
https://issues.apache.org/jira/browse/TUSCANY-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1208:
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
Service using callback and methods that don't perform callback over WS
binding hangs
Key: TUSCANY-1208
URL: https://issues.apache.org/jira/browse/TUSCANY-1208
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.90
Reporter: Lou Amodeo
Assignee: Simon Nash
Fix For: Java-SCA-1.0
I have a service exposed over the WS binding. The service interface has
multiple methods. Some methods perform callbacks and others do not. The
methods that performs the callback functions while the others hang and
eventually timeout. It appears that the binding is expecting all methods to
perform a
callback. It appears that other have observed the same behavior. I have not
seen this same behavior with the default binding.
From muhwas:
yeah i had the same problem so i thought we can't
inculde sync and async method together in one
Interface. so i created two interfaces and two service
one sync and other async.
From post to list:
Service using WS Binding with Calback and multiple methods on interface hangs
Lou Amodeo
Thu, 12 Apr 2007 18:55:05 -0700
I am seeing a hang when using the Web Services bindings to access a service
that has a callback reference. In this particular case the service expose
several methods on the interface. Only one of the methods invokes a method
on the callback reference. The method that invokes the callback functions
fine. The issue is with the other methods on the interface. It appears
that the binding is expecting every request to the service to perfrom a
callback. What I have found is the latch associated with doneSignal.await()
is never freed up. Also since this method did not use invoke a callback
not sure why it would be using an Async message receiver rather than the
Sync version? Its almost as if the binding is anticipating a mandatory
callback rather than waiting for one to actually be called. After about 5
minutes the request will timeout. Thanks for your help.
*public* Axis2ServiceInOutAsyncMessageReceiver() {
}
*public* *final* *void* receive(*final* MessageContext messageCtx) {
*try* {
Object messageId = messageCtx.getMessageID();
*if* (messageId == *null*) {
messageId = *new* MessageId();
}
// Now use message id as index to context to be used by callback
// target invoker
CountDownLatch doneSignal = *new* CountDownLatch(1);
InvocationContext invCtx =
service.*new* InvocationContext(messageCtx, operation,
getSOAPFactory(messageCtx), doneSignal);
service.addMapping(messageId, invCtx);
invokeBusinessLogic(messageCtx, messageId);
*try* {
doneSignal.await();
} *catch*(InterruptedException e) {
e.printStackTrace();
Timeout occurs after 5 minutes:
[4/12/07 21:49:43:529 EDT] 002b SystemErr R Exception in thread Axis2
Task *org.apache.tuscany.spi.wire.InvocationRuntimeException*:
org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
*java.net.SocketTimeoutException*: Async operation timed out
[4/12/07 21:49:43:529 EDT] 002b SystemErr R at
org.apache.tuscany.binding.axis2.Axis2ReferenceCallback.onError(*
Axis2ReferenceCallback.java:54*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at
org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
(*OutInAxisOperation.java:417*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(*ThreadPoolExecutor.java:665*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
(*ThreadPoolExecutor.java:690*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at java.lang.Thread.run(*
Thread.java:803*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R Caused by:
org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
*java.net.SocketTimeoutException*: Async operation timed out
at com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(*
HTTPTransportSender.java:271*)
at org.apache.axis2.engine.AxisEngine.send(*AxisEngine.java:464*)
at org.apache.axis2.description.OutInAxisOperationClient.send(*
OutInAxisOperation.java:325*)
at
org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
(*OutInAxisOperation.java:400*)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(*ThreadPoolExecutor.java:665*)
at
[jira] Updated: (TUSCANY-966) getRequestContext() does not return a Context
[
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-966:
---
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
Affects Version/s: (was: Java-SCA-M2)
Java-SCA-0.99
Java-SCA-0.91
getRequestContext() does not return a Context
-
Key: TUSCANY-966
URL: https://issues.apache.org/jira/browse/TUSCANY-966
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.91, Java-SCA-0.99
Reporter: Lou Amodeo
Assignee: Simon Nash
Fix For: Java-SCA-1.0
Remote Service hangs obtaining the request context using getRequestContext().
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
CallBackApiServiceImpl message received: Knock Knock
CallBackApiServiceImpl getting request context
[INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There were test failures
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 37 seconds
[INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
[INFO] Final Memory: 7M/18M
[INFO]
---
Test set: org.apache.tuscany.sca.test.CallBackApiITest
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec
FAILURE!
testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest) Time
elapsed: 30.023 sec FAILURE!
junit.framework.ComparisonFailure: CallBackBasicITest expected:Who's There
but was:null
at junit.framework.Assert.assertEquals(Assert.java:81)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
at
org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
package org.apache.tuscany.sca.test;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import org.osoa.sca.RequestContext;
@Service(CallBackApiService.class)
public class CallBackApiServiceImpl implements CallBackApiService {
@Context
protected CompositeContext compositeContext;
protected CallBackApiCallBack callback;
public void knockKnock(String aString) {
System.out.println(CallBackApiServiceImpl message received: +
aString);
callback = this.getCallBackInterface();
callback.callBackMessage(Who's There);
System.out.println(CallBackApiServiceImpl response sent);
return;
}
private CallBackApiCallBack getCallBackInterface()
{
System.out.println(CallBackApiServiceImpl getting request context);
RequestContext rc = compositeContext.getRequestContext();
System.out.println(CallBackApiServiceImpl getting callback from
request context);
callback = (CallBackApiCallBack)
rc.getServiceReference().getCallback();
System.out.println(CallBackApiServiceImpl returning callback);
return callback;
}
--
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-1634) Review the propagation of callable/service references over various bindings
Review the propagation of callable/service references over various bindings --- Key: TUSCANY-1634 URL: https://issues.apache.org/jira/browse/TUSCANY-1634 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-Next The Java spec defines CallableReference and ServiceReference. At this moment, we only have limited support for local cases (keeping pointers to java objects). We need to support the marshaling/unmarshaling of service references accross binding protocols. -- 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-1539) The assembly model does not contain the annotated intent information
[
https://issues.apache.org/jira/browse/TUSCANY-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1539:
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
The assembly model does not contain the annotated intent information
Key: TUSCANY-1539
URL: https://issues.apache.org/jira/browse/TUSCANY-1539
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Assembly Model
Environment: r558780
Reporter: Yang Lei
Fix For: Java-SCA-1.0
I am following JavaAnnotationsAndAPIs section 2.3.1 and 2.4 to create an
sample with both intent annotation and SCDL file. I realize no matter I
define intents or not in SCDL, it is alreays the SCDL version get picked up.
I use the following code to load the composite model:
EmbeddedSCADomain domain= new
EmbeddedSCADomain(this.getClass().getClassLoader(),http://+name);
domain.start();
ModelResolver resolver = new ModelResolverImpl(cl);
ContributionService service=
util.getDomain(null).getContributionService();
service.contribute(contributionId, contributionLocation,
resolver, false);
r service.getContribution(contributionId);
I use the following code to display the composite :
Composite composite =null;
for (DeployedArtifact artifact : contribution.getArtifacts()) {
if (artifact.getModel() instanceof Composite) {
if
(artifact.getURI().toString().endsWith(default.composite))
{
composite = ((Composite)artifact.getModel());
break;
}
}
}
if (composite!=null)
{
System.out.println(this is the artifact);
display(composite);
System.out.println(this is the added composite);
domain.getDomainCompositeHelper().addComposite(composite);
display(composite);
System.out.println(this is the started composite);
domain.getDomainCompositeHelper().startComposite(composite);
display(composite);
}
Under all 3 cases, the composite does not contain the annotated intent setting
--
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] Resolved: (TUSCANY-1497) Add full support for service references (which can be passed accross binding protocols)
[ https://issues.apache.org/jira/browse/TUSCANY-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1497. - Resolution: Fixed Looks like this has been implemented now. Please reopen new JIRA issues for any specific limitations or bug, with a precise description of what the issue is or what needs to be implemented. Thanks. Add full support for service references (which can be passed accross binding protocols) --- Key: TUSCANY-1497 URL: https://issues.apache.org/jira/browse/TUSCANY-1497 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-Next The Java spec defines CallableReference and ServiceReference. At this moment, we only have limited support for local cases (keeping pointers to java objects). We need to support the marshaling/unmarshaling of service references accross binding protocols. -- 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-1308) Need to find a solution for log4j warning messages on sca core libs and test cases
[ https://issues.apache.org/jira/browse/TUSCANY-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1308: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Need to find a solution for log4j warning messages on sca core libs and test cases -- Key: TUSCANY-1308 URL: https://issues.apache.org/jira/browse/TUSCANY-1308 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.90 Reporter: Luciano Resende Fix For: Java-SCA-1.0 Discussion thread available here : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg17755.html Today, when we run some samples or test cases, we get an annoying log4j warnings log4j:WARN No appenders could be found for logger ( org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. I have found a way to fix that, basically by adding a project called log4j-props inside modules, that has a log4j.properties file only, to be packaged in a jar file, then make the projects that are seeing the annoying log4j warning messages to include this dependency as scopetest/scope dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-log4j-props/artifactId version1.0-incubating-SNAPSHOT/version scopetest/scope /dependency After the changes, you would see something like : URLBasedAxisConfigurator.getAxisConfiguration (68) : No repository found , module will be loaded from classpath URLBasedAxisConfigurator.getAxisConfiguration (68) : No repository found , module will be loaded from classpath If people are OK with this, please let me know and I can commit this changes, and we could start adding the dependencies on demand. -- 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-1634) Review the propagation of callable/service references over various bindings
[ https://issues.apache.org/jira/browse/TUSCANY-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1634: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Review the propagation of callable/service references over various bindings --- Key: TUSCANY-1634 URL: https://issues.apache.org/jira/browse/TUSCANY-1634 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-1.0 The Java spec defines CallableReference and ServiceReference. At this moment, we only have limited support for local cases (keeping pointers to java objects). We need to support the marshaling/unmarshaling of service references accross binding protocols. -- 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-1549) itest/recursive RecursiveCompositeTestCase fails with an NPE
[ https://issues.apache.org/jira/browse/TUSCANY-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1549: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 itest/recursive RecursiveCompositeTestCase fails with an NPE Key: TUSCANY-1549 URL: https://issues.apache.org/jira/browse/TUSCANY-1549 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 RecursiveCompositeTestCase fails with the following exception: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at sample.RecursiveCompositeTestCaseFIXME.setUp(RecursiveCompositeTestCaseFIXME.java:32) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.checkCompatibility(InterfaceContractMapperImpl.java:140) at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.isCompatible(InterfaceContractMapperImpl.java:255) at org.apache.tuscany.sca.assembly.builder.impl.CompositeWireBuilderImpl.connectComponentReferences(CompositeWireBuilderImpl.java:355) at org.apache.tuscany.sca.assembly.builder.impl.CompositeWireBuilderImpl.wireComposite(CompositeWireBuilderImpl.java:90) at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:80) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:157) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:231) ... 16 more -- 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-1634) Review the propagation of callable/service references over various bindings
[ https://issues.apache.org/jira/browse/TUSCANY-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng updated TUSCANY-1634: -- Description: It should also have the ability to serialize to/from a URI and to/from a WS-addressing service endpoint reference. Bindings should transport service references in an appropriate binding specific format (possible leveraging the service reference's builtin serialization capabilities), for example: - Web Service binding - serialize to a WS-addressing service endpoint reference, the target Web Service (possibly non SCA) should be able to use that EPR to call the SCA client back - JMS binding - properties of the JMS message - EJB binding - a valid reference to an EJB session bean? not sure about this one etc. was:The Java spec defines CallableReference and ServiceReference. At this moment, we only have limited support for local cases (keeping pointers to java objects). We need to support the marshaling/unmarshaling of service references accross binding protocols. Affects Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Review the propagation of callable/service references over various bindings --- Key: TUSCANY-1634 URL: https://issues.apache.org/jira/browse/TUSCANY-1634 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-1.0 It should also have the ability to serialize to/from a URI and to/from a WS-addressing service endpoint reference. Bindings should transport service references in an appropriate binding specific format (possible leveraging the service reference's builtin serialization capabilities), for example: - Web Service binding - serialize to a WS-addressing service endpoint reference, the target Web Service (possibly non SCA) should be able to use that EPR to call the SCA client back - JMS binding - properties of the JMS message - EJB binding - a valid reference to an EJB session bean? not sure about this one etc. -- 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-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1500: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-1.0 Attachments: patch1, patch2, patch3 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- 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-1345) Many StAXArtifactProcessor implementations read policy but do not write it
[ https://issues.apache.org/jira/browse/TUSCANY-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1345: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Many StAXArtifactProcessor implementations read policy but do not write it -- Key: TUSCANY-1345 URL: https://issues.apache.org/jira/browse/TUSCANY-1345 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.90, Java-SCA-0.91 Environment: sca-java-0.90 Reporter: Matthew Sykes Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.0 While the 0.90 release was closing down, several changes were made to the StAXArtifactProcessor implementations used by the assembly model processors to get rid of the use of an abstract base class capable of dealing with policy. When that work was done, the read operations were updated to read the policy but the write operations were not. It seems that if the processors are going to be used to serialize the model, the write operations would need to serialize the polices as well. I've seen this issue in the RMIBindingProcessor, WebServiceBindingProcessor, and JavaImplementationProcessor but there may be others. -- 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-1337) The JSONRPC biding fails when transforming SDO to JSON
[ https://issues.apache.org/jira/browse/TUSCANY-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1337: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 The JSONRPC biding fails when transforming SDO to JSON --- Key: TUSCANY-1337 URL: https://issues.apache.org/jira/browse/TUSCANY-1337 Project: Tuscany Issue Type: Bug Components: Java SCA JSON-RPC Binding Extension Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-1.0 The JSONRPC biding fails when transforming my SDOs to JSON (Its OK going JSON-SDO). I can across this when creating the feed aggregator demo. A number of methods in the demo service return SDO and they all failed. It seemed that the JSONROC binding was trying to introspect the underlying EMF classes in order to create the JSON formatted object. If you look at the Alert Aggregator semo you will notice that I manually created a number of SDO like classes, for example, AlertsTypeNonSDOImpl, to get round this issue. -- 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-1635) Prototype and document how to use Aspectj to provide tracing to Tuscany code
Prototype and document how to use Aspectj to provide tracing to Tuscany code Key: TUSCANY-1635 URL: https://issues.apache.org/jira/browse/TUSCANY-1635 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-1.0 We agree to use aspectj to generate entry/exit trace calls externally without polluting the runtime source code. We should just provide a sample + documentation showing how to do it on the side. -- 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: Monitoring, logging and exceptions (again)
I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to track the aspectj-based tracing. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 29, 2007 11:06 AM Subject: Re: Monitoring, logging and exceptions (again) Simon Laws wrote: On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/20/07, Simon Nash [EMAIL PROTECTED] wrote: See inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 17, 2007 9:27 AM Subject: Re: Monitoring, logging and exceptions (again) [snip] ant elder wrote: And also my 2p inline... ...ant On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: A number of different requirements have been discussed and solutions proposed. My 2p (I'm using Raymond's definitions b.t.w) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) I feel that tracing of execution paths through the Tuscany codebase would be useful but agree that it's a lot of work and will be difficult to maintain and keep consistent if we did it manually. I'm happy that this is the responsibility of whoever wants to trace through the code and not a core part of the codebase. For the Tuscany developer community AspectJ have been proposed a couple of times and support has been prototyped. We could choose SLF4J as the interface through which messages are output. I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a facade for logging APIs, so you can code to the SLF4J API and then plug in whatever logging impl you like, but if the only logging calls we have are confined to a single tracing aspect we might as well just code that aspect to a specific logging API like JDK logging. That avoids the extra dependency on SLF4J and anyone can add additional aspects if they really want to use a different logger. The main other benefit of SLF4J is its parameterized message logging (avoids all the if(logger.isDebugEnabled()) ) but again if all the logging calls are in a single aspect thats not so useful. Makes sense to me. If we go the aspectj route for tracing method entry/exit, I agree that using the JDK logger directly is simpler. Since the aspect is on the side, we're flexible. JDK logger can be default and it can be replaced easily if the embedders or users choose to do so. A few more questions on this: What dependencies will aspectj add to our distribution? aspectjweaver is more than 1Mb, do we need it? I'll try to spend some time to explore both the compile-time and load-time weaving. What about mid-method logging of specific interesting events, for example the contents of requests as the enter and leave bindings and implementation types and things like that? That sort of logging is often all a lot of users want to see not the detail tracing of every method entry/exit. Could we add things like this in specific places? +1 for the ability to produce this level of information. This is my preferred approach for debugging or understanding how some part of the code works. Having every method entry and exit produce a trace line often creates a huge amount of output that obscures the essential details of what is happening. Can this mid-method logging be split in two categories? a) Debug tracing A simple solution is to split the method in two, and then leverage the entry/exit method tracing as discussed above. In many cases this would lead to a convoluted code structure with local variables needing to be passed as parameters between the two methods, or methods that contain a single line of code (if a trace line needs to be produced from within a loop). We can use JDK logger to add statements in the middle of a method. Then we can use an aspect to capture such calls to dump out the information. For example, if we have the following statement in a method: logger.debug(...); The apsect can trap it by a point cut like call * java.util.logger.Logger.debug(..). If the logger call is already there, why is an aspect needed to trap it? Why not just let it execute? b) End-user readable information (info that a binding is sending/receiving a message for example) This falls into the second category discussed in this thread, reporting significant events to a management console. The above suggestion should help too. The key here is to have some calls to indicate such requirements and they can be then trapped to provide the concrete logic. I think we're starting to see concrete solutions for (a) with aspectj. I have not seen any real concrete proposal for (b) yet. -- Jean-Sebastien
[jira] Created: (TUSCANY-1636) There should not be an SCABinding created under reference if there is no target on the reference 558780
There should not be an SCABinding created under reference if there is no target
on the reference 558780
---
Key: TUSCANY-1636
URL: https://issues.apache.org/jira/browse/TUSCANY-1636
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Reporter: Yang Lei
In CompositeBuilderImpl, we create defeault SCABinding where there is no
binding defined under reference. This will break the SCABinding handling if the
reference does not have a target, then SCABinding willl still get executed so
either there is a NPE as we are not expecting target is not there, or there is
a null object set to the reference, which will override existing reference
value in the component.
I did the following to remove the SCABinding at the end of the
CompositeBuilderImpl.connectComponentReferences, the else block
if (!targets.isEmpty()) {
}else
{
// need to remove the SCABinding we created that did not have
target
if (componentReference.getBindings().size()==1)
{
SCABinding binding =
componentReference.getBinding(SCABinding.class);
if (binding!=null binding.getURI()==null)
{
componentReference.getBindings().clear();
}
}
}
}
--
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] Commented: (TUSCANY-1636) There should not be an SCABinding created under reference if there is no target on the reference 558780
[
https://issues.apache.org/jira/browse/TUSCANY-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523669
]
Raymond Feng commented on TUSCANY-1636:
---
Adding a SCABinding if there is no explicit bindings conforms to the SCA
assembly spec. There might be different cases where the target is not present,
for exaample, the multiplicity is 0..1 or 0..N, or wiredByImpl = true.
I agree we need to have a better exception than NPE, but removing the SCA
binding maybe is not the correct fix :-).
There should not be an SCABinding created under reference if there is no
target on the reference 558780
---
Key: TUSCANY-1636
URL: https://issues.apache.org/jira/browse/TUSCANY-1636
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Reporter: Yang Lei
In CompositeBuilderImpl, we create defeault SCABinding where there is no
binding defined under reference. This will break the SCABinding handling if
the reference does not have a target, then SCABinding willl still get
executed so either there is a NPE as we are not expecting target is not
there, or there is a null object set to the reference, which will override
existing reference value in the component.
I did the following to remove the SCABinding at the end of the
CompositeBuilderImpl.connectComponentReferences, the else block
if (!targets.isEmpty()) {
}else
{
// need to remove the SCABinding we created that did not have
target
if (componentReference.getBindings().size()==1)
{
SCABinding binding =
componentReference.getBinding(SCABinding.class);
if (binding!=null binding.getURI()==null)
{
componentReference.getBindings().clear();
}
}
}
}
--
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: Generating Eclipse WTP Web Projects for our Webapp samples
Should this be added to this guide? http://incubator.apache.org/tuscany/sca-java-development-guide.html If yes, I'll add it in. On 8/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi all, I just thought I'd share this as I found it pretty useful when working with our Webapp samples. If you're using Eclipse WTP and want to get WTP Web Projects generated for our Webapp samples you can simply pass a -Dwtpversion=1.5 option to the usual mvn eclipse:eclipse command, like this: mvn -Dwtpversion=1.5 -Peclipse eclipse:eclipse The magic -Dwtpversion=1.5 option will add the WTP Web project nature to all the Eclipse projects with packagingwar/packaging in their Maven pom.xml. You'll then be able to add these projects to a WTP Tomcat or Geronimo Server configuration, to publish and run them straight from your Eclipse workspace. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there value in keeping download links for old releases?
I'd like to bring this message back to life. A few users posted to the ML recently and asked about M2. Immediate response has been to use the latest since M2 is very old (IMHO makes sense). This email thread was suggesting to remove the download link of very old releases to avoid confusion. We can leave the release history in place to show that there was a release, but remove the link for download to avoid confusion. If everyone agrees, when does a link get removed, in other words, how old the release should be? For starter, M2 is based on an older version of the spec. Should we remove the download link? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh I think yes we should keep them. One of the first things I look at when coming across an open source project is the release history as it gives you a good indication of how much life there is in the project. Maybe from that we don't need actual links to the download artifacts, but something clearly showing we do regular releases and have been doing so for years is a Good Thing IMHO. Another reason is if someone is debugging some old system with a back level release they may need access to the source distro to debug the code. ...ant
Re: Generating Eclipse WTP Web Projects for our Webapp samples
[snip] haleh mahbod wrote: Should this be added to this guide? http://incubator.apache.org/tuscany/sca-java-development-guide.html If yes, I'll add it in. Yes I think it'll be useful. Thanks :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementation.osgi and SCA annotations
Hi Rajini, This may be clear to many, but I am trying to catch up and understand what we are doing in this space. Can you please explain which scenarios are working and what is not working and how your suggestion relates to those scenarios. Thanks Haleh On 8/29/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, We would like to start supporting SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. In the current implementation, SCA annotations are only supported for annotations used in interfaces, since we were keen on supporting existing OSGi bundles without any change. This meant that additional SCA properties like @AllowsPassByReference had to be supported through additional attributes on the implementation.osgi/ element. But since these properties do not have an OSGi equivalent, they cannot be used with existing OSGi bundles, and for new implementations which support these properties, we would like to support SCA annotations to make the OSGi implementation consistent with the Java implementation. This is a fairly big change in implementation.osgi, and I would like your views on whether this is a good time to make the change, so that the implementation will reflect the long-term strategy in the next release. I can submit a patch early next week if it can be integrated before the release. Thank you... Regards, Rajini
Re: Generating Eclipse WTP Web Projects for our Webapp samples
done On 8/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] haleh mahbod wrote: Should this be added to this guide? http://incubator.apache.org/tuscany/sca-java-development-guide.html If yes, I'll add it in. Yes I think it'll be useful. Thanks :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
[ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: import.txt This patch updates the wsdl binding schemas import adding a schemaLocation attribute. This was required for the schemas to be valid. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: import.txt, TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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]
FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
Hi, I uploaded an addendum patch to TUSCANY-1375. If someone could review and apply it that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 6:33 PM To: tuscany-dev@ws.apache.org Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API [ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: import.txt This patch updates the wsdl binding schemas import adding a schemaLocation attribute. This was required for the schemas to be valid. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: import.txt, TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there value in keeping download links for old releases?
A suggestion would be to have the most recent release, and the previous one, and then a link to archive that would point to the root folder of where our releases are stored. We could even just have the latest and the pointer to the archived releases. Thoughts ? On 8/29/07, haleh mahbod [EMAIL PROTECTED] wrote: I'd like to bring this message back to life. A few users posted to the ML recently and asked about M2. Immediate response has been to use the latest since M2 is very old (IMHO makes sense). This email thread was suggesting to remove the download link of very old releases to avoid confusion. We can leave the release history in place to show that there was a release, but remove the link for download to avoid confusion. If everyone agrees, when does a link get removed, in other words, how old the release should be? For starter, M2 is based on an older version of the spec. Should we remove the download link? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh I think yes we should keep them. One of the first things I look at when coming across an open source project is the release history as it gives you a good indication of how much life there is in the project. Maybe from that we don't need actual links to the download artifacts, but something clearly showing we do regular releases and have been doing so for years is a Good Thing IMHO. Another reason is if someone is debugging some old system with a back level release they may need access to the source distro to debug the code. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1335) Documentation for wiki
[ https://issues.apache.org/jira/browse/TUSCANY-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523765 ] Luciano Resende commented on TUSCANY-1335: -- Amita, do we still have anything open here, if all the changes are applied, could you please close the issue. Documentation for wiki --- Key: TUSCANY-1335 URL: https://issues.apache.org/jira/browse/TUSCANY-1335 Project: Tuscany Issue Type: Task Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Amita Vadhavkar Assignee: Simon Laws Fix For: Java-DAS-Next Attachments: ForWiki.zip, ForWikiJune12.zip files for review and addition to wiki -- 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: [SDO Java] What shall we do next?
What is the plan for JIRA-761(Support the ability to unregister all the SDO Types in a namespace) Also, I am just trying to understand that in a condition where some Type is defined in using SDOUtil.createType() and later some attributes of it need to change during the same runtime invocation. So user needs SDOUtil.createOrReplaceType() - how this can be done? Regards, Amita On 8/29/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: Hi Kelvin, Based on my observation on opened JIRAs, I agree we definitely should pay attention to the first two items you listed below - test generated static SDO APIs and multi-threaded scenario more easily. I did some investigation on GroboUtils for multi-thread testing and still couldn't find any remote repository hosting the tool so we may need to host the tool ourselves or find an alternative. What do you think? Fuhwei kelvin goodson [EMAIL PROTECTED] wrote: Having released 1.0-incubating, what are the priorities for SDO Java now. I'm just catching up on reading the lists having taken a break. The major things I had in mind before going away were to - rearrange the project structure to permit generation of java classes during maven tests (TUSCANY-1393) - add multi-threaded test cases (TUSCANY-1182) - for the first of the above, while we are in project reorganisation mode it's probably worth fixing TUSCANY-257 to separate out the Java 5 dependencies - It would be great to get some improvement our web pages; and getting some good user documentation together would be really helpful. My brain hasn't completely returned from vacation, so I've probably missed out some obvious things, so please chip in with your opinions, needs and inspirational ideas! Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
Sounds ok to me. In an earlier version of the RMI Binding, I did something like this with the getUri method of Binding class. - Venkat On 8/29/07, ant elder [EMAIL PROTECTED] wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: One more observation... when the binding URI is http://localhost:8080/hello/HelloWorldService; the service is available at that URL. Only http://localhost:8080/hello/HelloWorldService?wsdl; results in an exception. Here is what I did. 1. Deploy the HelloWorld sample with binding URI http://localhost:8080/HelloWorldService;. 2. Get the wsdl by accessing http://localhost:8080/HelloWorldService?wsdl; and save to a disk file. 3. Now redeploy HelloWorld sample with binding URI http://localhost:8080/ hello/HelloWorldService. 4. Using WebServices Explorer in Eclipse, and the saved wsdl file from step2, access the service at url in step3. Vamsi On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Ok what happens with a uri of http://localhost:8080/HelloWorldService?wsdl http://localhost:8080/hello/HelloWorldService?wsdl I have fixed the problem in plugin code so that it uses a context root / as well. After the fix, I am able to use http://localhost:8080/HelloWorldService?wsdl http://localhost:8080/hello/HelloWorldService?wsdlas uri. And for this uri (that ?wsdl in the uri did not matter), I am able to access the wsdl using http://localhost:8080/HelloWorldService?wsdl http://localhost:8080/hello/HelloWorldService?wsdl (sorry to keep bouncing this back to you, i've not been able to get the Geronimo integration to build locally yet so can't test this myself) Let me see if I can quickly provide the built plugin so that you can install it in Geronimo 2.0.1. ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Is /hello the mapping for some Geronimo servlet or application thing? /hello is not mapped to any application. What happens if you change the uri in the SCDL to have binding.wsuri=/HelloWorldService/? In this case, GeronimoServletHost.addServletMapping() is getting invoked with ( http://localhost:8085/HelloWorldService;, Axis2ServiceServlet). Since there is no http connector on 8085, the method is throwing an Exception. Thanks, ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/26/07, ant elder [EMAIL PROTECTED] wrote: So that must mean in the setContextRoot method at line 279 in TuscanyListingAgent that configContext.getContextRoot() is returning http://localhost:8080/hello/; right? configContext.getContextRoot() is returning hello. Can you debug Axis2ServiceServlet on line 230 and see what gets set on th eline configContext.setContextRoot( request.getContextPath());? request.getContextPath() is evaluating to /hello . Thanks, ...ant On 8/26/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, The URL is http://localhost:8080/hello/HelloWorldService?wsdl; . When I debug the code, I am noticing that in TuscanyListingAgent.processListService () around line 101, the filePart is http://localhost:8080/hello/HelloWorldService; and findAxisServiceName() is returning /hello/HelloWorldService. Inside setContextRoot() arounf line 286, mapping = filePart.substring() is getting called with paramters (28, 21) which is resulting in the Exception. That -7 in the exception message is this 21-28. Vamsi On 8/26/07, ant elder [EMAIL PROTECTED] wrote: On 8/25/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have deployed HelloWorld webservice sample (jar attached in this mail)
Re: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
Patch applied. One thing we need to do is update the NOTICE file to include the licence from the wsdl schema files. Cheers, On 30/08/2007, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I uploaded an addendum patch to TUSCANY-1375. If someone could review and apply it that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 6:33 PM To: tuscany-dev@ws.apache.org Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API [ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: import.txt This patch updates the wsdl binding schemas import adding a schemaLocation attribute. This was required for the schemas to be valid. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: import.txt, TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
