[jira] Closed: (TUSCANY-1061) ReadMe on how to write SCA Integration Test Cases
[ https://issues.apache.org/jira/browse/TUSCANY-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1061. -- Resolution: Fixed Applied. Thanks for the doc Hasan, looks really useful. ReadMe on how to write SCA Integration Test Cases - Key: TUSCANY-1061 URL: https://issues.apache.org/jira/browse/TUSCANY-1061 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Environment: ALL Reporter: Hasan Muhammad Assigned To: ant elder Priority: Trivial Fix For: Java-M3 Attachments: IntegrationTestHelp.html A ReadMe on how to write SCA Integration Test Cases. Per request from Raymond, I have created this readme. It is in the same style as the readme for GettingStarted on Tuscany. This readme is currently stored in tuscany/java/testing/sca/itest dir. If you would change the location of the readme while committing, then please make changes to the following code in the source so that the format is mainted. @import url(../../../javadoc/css/maven-base.css); @import url(../../../javadoc/css/maven-theme.css); @import url(../../../javadoc/css/site.css); /style link href=../../../javadoc/css/print.css media=print -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1061) ReadMe on how to write SCA Integration Test Cases
[ https://issues.apache.org/jira/browse/TUSCANY-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1061: -- Assignee: ant elder ReadMe on how to write SCA Integration Test Cases - Key: TUSCANY-1061 URL: https://issues.apache.org/jira/browse/TUSCANY-1061 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Environment: ALL Reporter: Hasan Muhammad Assigned To: ant elder Priority: Trivial Fix For: Java-M3 Attachments: IntegrationTestHelp.html A ReadMe on how to write SCA Integration Test Cases. Per request from Raymond, I have created this readme. It is in the same style as the readme for GettingStarted on Tuscany. This readme is currently stored in tuscany/java/testing/sca/itest dir. If you would change the location of the readme while committing, then please make changes to the following code in the source so that the format is mainted. @import url(../../../javadoc/css/maven-base.css); @import url(../../../javadoc/css/maven-theme.css); @import url(../../../javadoc/css/site.css); /style link href=../../../javadoc/css/print.css media=print -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[ https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-824: -- Priority: Critical (was: Blocker) Was only a blocker while we were holding M2 for this so lowering priority now DataBinding: Is it a concern of Programming Model vs. Assembly? --- Key: TUSCANY-824 URL: https://issues.apache.org/jira/browse/TUSCANY-824 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Priority: Critical Fix For: Java-M3 There have been some question about the DataBinding framework and if it should be a concern of the Programming Model vs. Assembly? See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html and a follow up mention in: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-296) Document the architecture of the Java container
[ https://issues.apache.org/jira/browse/TUSCANY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-296. - Resolution: Fixed Closing as this is an old M1 thing and the Java container is now part of the core Document the architecture of the Java container --- Key: TUSCANY-296 URL: https://issues.apache.org/jira/browse/TUSCANY-296 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jim Marino Fix For: Java-SCA-M3 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Jim has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-181) Need a command line tool and maven2 plugin to validate an SCA assembly
[ https://issues.apache.org/jira/browse/TUSCANY-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-181: -- Fix Version/s: (was: Java-SCA-Mx) Wish list Need a command line tool and maven2 plugin to validate an SCA assembly -- Key: TUSCANY-181 URL: https://issues.apache.org/jira/browse/TUSCANY-181 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Affects Versions: Java-SCA-Mx Reporter: Jean-Sebastien Delfino Fix For: Wish list We need a command line tool and a maven2 plugin to validate an SCA assembly. This is important to help application developers detect and diagnose problems in their assembly before they deploy and run the application. This tool should take an SCA assembly (module or subsytem) and run a set of validation rules on its artifacts. - XML schema validation on the SCDL artifacts - semantic validation on the assembly model (e.g. verify that an interface declared on a service actually exists, verify that a wire can actually be resolved) The tool should generate messages with enough context information, including file name, line number, and relevant assembly model objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-734) SCDL Validation tool
[ https://issues.apache.org/jira/browse/TUSCANY-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-734. - Resolution: Duplicate Dup of TUSCANY-181 SCDL Validation tool Key: TUSCANY-734 URL: https://issues.apache.org/jira/browse/TUSCANY-734 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Affects Versions: Java-SCA-Mx Reporter: Rick Rineholt Fix For: Java-SCA-Mx A tool is needed that can validate SCDL at build time. Some requirments are: Should run as a command line or as a Maven plugin. Priority on isolating the location of errors (file, line number) and giving detailed meaningful explanations. Optionally, Given a search path should validate referenced java class files and wsdl exists Option to fail or warn on non existence. Validate wiring. Extensible. Allow registration of extensions to validate non SCDL elements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
about InboundWire and OutboundWire
Hi all: My english is very poor , so hope you can sit through util read this question over, :-) why has InboundWire and OutboundWire two class,and what they useful? OutboundWire: for managing the reference side of a wire about this explain, can I think InboundWire: for managing the service side of a wire? but you explain for managing the inbound side of a wire please you describe detail. thinks very much - Mp3疯狂搜-新歌热歌高速下
RE: OSGi sample posted
Hi Lee,
Sorry for the delayed response - other duties call.
I've done some work moving the sample up to M2, but with the kernel
re-factoring that's taking place, I've decided to wait a bit before
re-engaging.
If you need the sample upgraded to M2, I can try and get back to it this
weekend.
Cheers,
Joel
-Original Message-
From: Lee Surprenant [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 16, 2007 7:57 AM
To: tuscany-dev@ws.apache.org
Subject: Re: OSGi sample posted
I am curious as to the current status of the OSGi binding. I have run
the sample successfully and also tried to set up the included
workspace. Unfortunately, when I try to run the sample in eclipse, I
get the following error that I am looking at now:
org.apache.tuscany.spi.loader.LoaderException:
org.apache.tuscany.idl.wsdl.InvalidWSDLException: Element cannot be
resolved: {http://customer}purchaseGoodsRequest [http://customer
wsdl/CustomerService.wsdl]
Context stack trace: [customer]
at
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader.load(InterfaceWSDLLoader
.java:138)
at
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader.load(InterfaceWSDLLoader
.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImp
l.java:94)
...
Caused by: org.apache.tuscany.idl.wsdl.InvalidWSDLException: Element
cannot be resolved: {http://customer}purchaseGoodsRequest
at
org.apache.tuscany.idl.wsdl.WSDLOperation$WSDLPart.init(WSDLOperation.
java:232)
at
org.apache.tuscany.idl.wsdl.WSDLOperation.getMessageType(WSDLOperation.j
ava:174)
at
org.apache.tuscany.idl.wsdl.WSDLOperation.getInputType(WSDLOperation.jav
a:117)
at
org.apache.tuscany.idl.wsdl.WSDLOperation.getOperation(WSDLOperation.jav
a:189)
at
org.apache.tuscany.idl.wsdl.InterfaceWSDLIntrospectorImpl.introspectOper
ation(InterfaceWSDLIntrospectorImpl.java:67)
at
org.apache.tuscany.idl.wsdl.InterfaceWSDLIntrospectorImpl.introspectOper
ations(InterfaceWSDLIntrospectorImpl.java:58)
at
org.apache.tuscany.idl.wsdl.InterfaceWSDLIntrospectorImpl.introspect(Int
erfaceWSDLIntrospectorImpl.java:94)
at
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader.load(InterfaceWSDLLoader
.java:130)
... 34 more
It is not clear to me what revision these jars are at...has there been
any effort to extend this test case to the released M2 jars? Do you
have any other pointers on how to set up the workspace? I am
interested in creating a sample app which involves a tuscany runtime
playing nice with some devices exposed as OSGi services (preferably
with M2 for stability).
Thanks,
Lee
On 1/7/07, Wengatz, Nicole [EMAIL PROTECTED] wrote:
Hi Joel,
sorry for the late reply.
I had a look to your prototype (thanks for providing it), it runs fine
on my machine.
Some questions/comments:
1)
What's the relation between the folder projects and the folder
plugins?
Is there a maven/ant script to build the content of the plugins
folder?
I imported the projects into Eclipse and found some compile problems
in org.apache.axis2 and tuscany_osgi_sca_binding_axis2. But since the
plugins
folder does not contain tuscany-osgi-sca-binding-axis2, I got the
impression
that's not used currently (maybe could be deleted?).
2)
The config directory under TuscanySample could be deleted, the
configuration
directory contains the required configuration, isn't it?
3) Shipper
You provided two implementations, Java and Spring.
In the implementation (the Java Class) there shouldn't be any
difference?
Why are the service and reference tags sub-tags of
implementation-spring?
I thought, implementation, reference and service should be on the
same
level?
4) WebService Access from Shipper to Customer
How does it work exactly?
Is the reference entry (SCACustomer) really required?
My impression it that the entry property name=customer
ref=SCACustomer/
together with the CustomerService.wsdl is enough (at least it still
worked after deleting
the reference entry in spring_sample.scdl file :-)
Thanks and best regards
Nicole
-Original Message-
From: Hawkins, Joel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 29, 2006 11:01 PM
To: tuscany-dev@ws.apache.org
Subject: OSGi sample posted
Jim, Nicole,
I've posted my OSGi sample on my people.apache.org site -
http://people.apache.org/~jhawkins/Tuscany/TuscanySample.zip
There's a readme that describes the sample and how to run it. I've
also
included a snapshot of my Eclipse work area. The Tuscany binaries are
based on a synch of HEAD performed yesterday.
I've got a few things to finish up (like support for scdl imports)
before creating a patch I'd be happy with, so please bear with me.
I've come to the conclusion that we need to develop some packaging
conventions for deploying apache functionality into OSGi. I'm aware of
the Eclipse Orbit project, which is providing some common packaging of
Apache (and other non-eclipse)
Re: Spec changes, modularity, and scaling the Java SCA project
I see I made a numbering mistake by not having a step 4...In any event, I'll assume the original numbering (no step 4). Comments inline. On Jan 17, 2007, at 9:05 PM, haleh mahbod wrote: Hi Jim, I don't understand what you mean when you talk about the do-not- use kernel version. A do-not-use or internal-use kernel means a version which is not intended for use outside the project by extenders. It is intended only to provide a stable cut of kernel for extensions in Tuscany to work from so they do not have to reference HEAD. As kernel evolves, we may publish additional releases. My desire is that the next release of kernel be stable enough that it becomes a distribution others can use. Here is how I am understanding your proposal. . Is this correct? Step #1 in your list: is a release of the kernel with content as of today . This will live in a branch - Extensions will need to be sync'd up on this version We don't need to branch to do this. We just cut the release from HEAD and then continue development. Extensions will reference the release, which will be in the Maven repo. Step #2 is a release of existing extensions on the Kernel - At this point Kernel and extensions can be used by users Step 2 involves having the extensions use the release and not HEAD. It does not involve any other release (of extensions or kernel). This will be done immediately after the release is posted to Maven. Step #3 is kernel evolving in the trunk to sync up with latest spec changes Step 3 is evolving the kernel to implement the latest spec changes as well as continue separate development of the extensions which refer to the released version of kernel from Step 1. In other words, development continues in parallel. Step #4 is the follow on release of the kernel with the spec changes - Extensions will need to be sync'd up on this version. Step 4 (improperly labeled step 5) involves a release of kernel. At some point after that, the extensions will individually or in sets move up to use that release. Extensions do not need to move at once as they will be on individual development cycles. Step #5 is the release of extensions on top of kernel in step 4- At this point the new Kernel and extensions can be used by users Kernel will be usuable by end-users after step 4 as, we will be cutting a kernel distribution. After that point, there will be releases of extensions which will be done either individually or in sets. For example, the Axis extensions (web services binding and Java2WSDL tooling) may be released X days later. Followed by that, maybe a week later if it is ready, the Spring extension will be released. The key thing is we have a separate kernel release and extensions are released on individual schedules. Jim Thanks, Haleh On 1/17/07, Jim Marino [EMAIL PROTECTED] wrote: Hi, A few of us are participating in the SCA Assembly offsite this week. The outcome of the offsite is that there will be a number of changes introduced into the specification which will impact the kernel and extensions. We can summarize and discuss the changes in separate threads but I wanted to propose a way for handling these changes which will allow kernel and extension development to proceed apace while minimizing instability. This proposal is also intended to allow us to introduce the remaining modularity changes that have been previously discussed. Specifically, I propose we initiate a release of kernel over the next several days which serve as a baseline for extension development. This release of kernel would be intended only for internal extension development and not for end-users. The purpose of the release is to allow kernel changes to be introduced without causing instability in the extensions. Later, a stable kernel release will be made which extensions will upgrade to. This release would be the kernel release we have been discussing over the last couple of weeks. When, extensions are ready, they would be released individually or in sets. I see this process happing in the following steps: 1. Release a internal-use kernel version, which will be initiated over the next couple of days 2. Right after, switch extensions to build off the the do-not-use kernel version 3. Continue development of kernel and extensions simultaneously. At this point we also reorganize the build tree and extensions as we previously described, grouping extensions and samples by how they will be distributed 5. Release a version of kernel with a stable SPI (the Java kernel release), incorporating the new SCA changes 6. Release extensions individually or in sets as they are ready Comments/suggestions/thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: about InboundWire and OutboundWire
On Jan 18, 2007, at 2:51 AM, wenbin wang wrote: Hi all: My english is very poor , so hope you can sit through util read this question over, :-) Actually it seems pretty good :-) why has InboundWire and OutboundWire two class,and what they useful? Wires have two sides since there may be policy or other things associated with a source or target, for example, transaction context. The following picture may help to explain. Component A and Component B both references wired to a service on Component C: A -- C B -- A and B may have policies attached to their references that are distinct and hence the runtime will create outbound wires for those. C may also have policies associated with its service, which is represented by an inbound wire. The runtime will connect the inbound wires from A and B to C. This will also help with re-wiring scenarios, for example B gets re-targeted to D. OutboundWire: for managing the reference side of a wire about this explain, can I think InboundWire: for managing the service side of a wire? but you explain for managing the inbound side of a wire The inbound side of a wire involves policies and other things associated with a service, for example, security or transactions. These are manifested as interceptors. Each wire has a set of invocation chains associated with the service operations. The interceptors are part of these invocation chains. I hope this helps. Jim please you describe detail. thinks very much - Mp3疯狂搜-新歌热歌高速下 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1063) Improve diagnostics running XSD2JavaGenerator against bad schema
Improve diagnostics running XSD2JavaGenerator against bad schema Key: TUSCANY-1063 URL: https://issues.apache.org/jira/browse/TUSCANY-1063 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SCA-M3 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-M3 I gave an invalid XSD file to the XSD2JavaGenerator and had to use the debugger to figure out the problem. It might be nice to do a printStackTrace() on any exception before throwing out of main(). Also it might be good to print out simple error messages in the cases that: a) the usage was correct but the specified file can't be read b) the file can be read but there is no valid schema found As a sample of the latter here is my invalid schema xsd:schema xmlns:tns=http://helloworld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified targetNamespace=http://helloworld; complexType name=Person sequence element name=firstName type=string/ element name=lastName type=string/ /sequence /complexType /xsd:schema -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1064) WSDL2Java tool doesn't have an option to generate Java non-wrapper style interface using dynamic SDO (commonj.sdo.DataObject)
WSDL2Java tool doesn't have an option to generate Java non-wrapper style interface using dynamic SDO (commonj.sdo.DataObject) - Key: TUSCANY-1064 URL: https://issues.apache.org/jira/browse/TUSCANY-1064 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-SCA-M3 Reporter: Fuhwei Lwo Fix For: Java-SCA-Mx As a developer using SCA and SDO for databinding, I would expect wsdl2java tool provide an option for me to use dynamic SDO. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1065) Coexistence problem between EMF and Tuscany SDO
Coexistence problem between EMF and Tuscany SDO --- Key: TUSCANY-1065 URL: https://issues.apache.org/jira/browse/TUSCANY-1065 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo When EMF and Tuscany SDO are running in the same JVM, Tuscany SDO is completely not working when EMF was run and initialized before SDO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465774 ] Ignacio Silva-Lepe commented on TUSCANY-1003: - Ok, I am past the ServiceRuntimeException, I was missing a @Service declaration. But now I am getting the following TransformationException: org.apache.tuscany.spi.databinding.TransformationException: java.lang.NullPointe rException at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.tra nsform(Output2OutputTransformer.java:197) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate(Mediato rImpl.java:91) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.transf orm(DataBindingInteceptor.java:106) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:92) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke( JDKOutboundInvocationHandler.java:166) at $Proxy25.getGreetings(Unknown Source) at helloworld.HelloWorldServiceComponent.getGreetings(HelloWorldServiceC omponent.java:40) Caused by: java.lang.NullPointerException at org.apache.tuscany.databinding.axiom.OMElementWrapperHandler.getChild (OMElementWrapperHandler.java:50) at org.apache.tuscany.databinding.axiom.OMElementWrapperHandler.getChild (OMElementWrapperHandler.java:34) at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.tra nsform(Output2OutputTransformer.java:187) Any ideas? NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-SCA-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
[jira] Resolved: (TUSCANY-965) Context Injection is not functioning
[
https://issues.apache.org/jira/browse/TUSCANY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Silva-Lepe resolved TUSCANY-965.
Resolution: Fixed
Testing with r497459 shows this working, can you verify as well?
Context Injection is not functioning
Key: TUSCANY-965
URL: https://issues.apache.org/jira/browse/TUSCANY-965
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core, Java SCA Integration Tests
Affects Versions: Java-SCA-M3
Reporter: Lou Amodeo
Fix For: Java-SCA-M3
Appears that Contesxt injection when using setters and attributes is not
working. In each case the context attribute is null.
a) setter method
package org.apache.tuscany.sca.test;
import org.osoa.sca.CurrentCompositeContext;
import org.osoa.sca.ServiceReference;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Remotable;
import org.osoa.sca.annotations.Scope;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import junit.framework.Assert;
@Service(CallBackSetCallbackClient.class)
public class CallBackSetCallbackClientImpl implements
CallBackSetCallbackClient {
@Reference
protected CallBackSetCalbackService aCallBackService;
@Reference
protected CallBackSetCallbackCallback callBack;
private CompositeContext context;
@Context
public void setContext(CompositeContext aContext)
{
context = aContext;
}
public void run() {
if (context == null)
System.out.println(Context is null);
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
Context is null
b) attribute
package org.apache.tuscany.sca.test;
import org.osoa.sca.CurrentCompositeContext;
import org.osoa.sca.ServiceReference;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Remotable;
import org.osoa.sca.annotations.Scope;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import junit.framework.Assert;
@Service(CallBackSetCallbackClient.class)
public class CallBackSetCallbackClientImpl implements
CallBackSetCallbackClient {
@Reference
protected CallBackSetCalbackService aCallBackService;
@Reference
protected CallBackSetCallbackCallback callBack;
@Context
protected CompositeContext context;
public void run() {
if (context == null)
System.out.println(Context is null);
[WARNING] Unable to get resource from repository central
(http://repo1.maven.or
/maven2)
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
Context is null
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-966) getRequestContext() does not return a Context
[
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465795
]
Ignacio Silva-Lepe commented on TUSCANY-966:
Although context injection works now (see TUSCANY-965), its api is still not
implemented
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, Java SCA Integration Tests
Affects Versions: Java-SCA-M3
Reporter: Lou Amodeo
Assigned To: Jim Marino
Fix For: Java-SCA-M3
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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465799 ] Venkatakrishnan commented on TUSCANY-1003: -- Hi Ignacio, I debugged this a bit and what I figure out is that in the Output2OutputTransformer the output wrapper is null and this causes the NPE in the Axiom databinding code. The method seems to be getGreetings and the tranformer is looking at the result which is null and creating a output wrapper for this which inturn also ends up as null. I guess Raymond will be able to throw better light on this while I continue to see if I can get better info about this. - Venkat NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-SCA-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(Internal OutputBuffer.java:746) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuf fer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 991) at org.apache.coyote.Response.action(Response.java:182) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 322) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:29 3) at
Re: Spec changes, modularity, and scaling the Java SCA project
Another question comes to mind, how will we handle issues found in the do-not-use kernel if they are found by extension writers and are blocking? Do they get fixed ? Parallel development on both kernels? Blocking till the new kernel is ready? Jim Marino wrote: Hi, A few of us are participating in the SCA Assembly offsite this week. The outcome of the offsite is that there will be a number of changes introduced into the specification which will impact the kernel and extensions. We can summarize and discuss the changes in separate threads but I wanted to propose a way for handling these changes which will allow kernel and extension development to proceed apace while minimizing instability. This proposal is also intended to allow us to introduce the remaining modularity changes that have been previously discussed. Specifically, I propose we initiate a release of kernel over the next several days which serve as a baseline for extension development. This release of kernel would be intended only for internal extension development and not for end-users. The purpose of the release is to allow kernel changes to be introduced without causing instability in the extensions. Later, a stable kernel release will be made which extensions will upgrade to. This release would be the kernel release we have been discussing over the last couple of weeks. When, extensions are ready, they would be released individually or in sets. I see this process happing in the following steps: 1. Release a internal-use kernel version, which will be initiated over the next couple of days 2. Right after, switch extensions to build off the the do-not-use kernel version 3. Continue development of kernel and extensions simultaneously. At this point we also reorganize the build tree and extensions as we previously described, grouping extensions and samples by how they will be distributed 5. Release a version of kernel with a stable SPI (the Java kernel release), incorporating the new SCA changes 6. Release extensions individually or in sets as they are ready Comments/suggestions/thoughts? Jim - 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: Spec changes, modularity, and scaling the Java SCA project
On Jan 18, 2007, at 8:18 AM, Rick wrote: Will there be an svn a tag or branch of the do-not-use kernel so the extension writers have something to debug with ? For those developers, I assume that the procedure then is to check out their extension code from SVN at the HEAD, check out the do-not-use kernel parts with svn tag version of do-not-use to have matching source? I think we would tag it or just use the revision number, whichever is easiest. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec changes, modularity, and scaling the Java SCA project
On Jan 18, 2007, at 8:27 AM, Rick wrote: Another question comes to mind, how will we handle issues found in the do-not-use kernel if they are found by extension writers and are blocking? Do they get fixed ? Parallel development on both kernels? Blocking till the new kernel is ready? I'd prefer not to branch. Since this will hopefully be a short period before we have another release, I think they would block or a patch could be applied locally to the extension. If someone has another solution, we could look at that. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec changes, modularity, and scaling the Java SCA project
On 1/18/07, Jim Marino [EMAIL PROTECTED] wrote: On Jan 18, 2007, at 8:27 AM, Rick wrote: Another question comes to mind, how will we handle issues found in the do-not-use kernel if they are found by extension writers and are blocking? Do they get fixed ? Parallel development on both kernels? Blocking till the new kernel is ready? I'd prefer not to branch. Since this will hopefully be a short period before we have another release, I think they would block or a patch could be applied locally to the extension. If someone has another solution, we could look at that. Would it be possible to put off deciding on this until all these proposed changes are publicly available somewhere so we all have more idea about whats involved and can make a more informed decision? ...ant
[jira] Created: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory
Failing to run samples with Standalone distributions : Unable to locate profile directory - Key: TUSCANY-1066 URL: https://issues.apache.org/jira/browse/TUSCANY-1066 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Luciano Resende Fix For: Java-SCA-M3 Build a distribution and try to run standalone sample calculator Exception in thread main java.io.FileNotFoundException: Unable to locate profile directory: d:\temp\sca_standalone_distribution\profiles\launcher at org.apache.tuscany.runtime.standalone.DirectoryHelper.getProfileDirectory(DirectoryHelper.java:124) at org.apache.tuscany.launcher.Main.createRuntimeInfo(Main.java:89) at org.apache.tuscany.launcher.Main.main(Main.java:56) Workaround : build : java/sca/runtime/standalone/assembly then overlap the generated zip in the standalone distribution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec changes, modularity, and scaling the Java SCA project
haleh mahbod wrote: Hi Jim, I don't understand what you mean when you talk about the do-not-use kernel version. Here is how I am understanding your proposal. . Is this correct? Step #1 in your list: is a release of the kernel with content as of today . This will live in a branch - Extensions will need to be sync'd up on this version Step #2 is a release of existing extensions on the Kernel - At this point Kernel and extensions can be used by users Step #3 is kernel evolving in the trunk to sync up with latest spec changes Step #4 is the follow on release of the kernel with the spec changes - Extensions will need to be sync'd up on this version. Step #5 is the release of extensions on top of kernel in step 4- At this point the new Kernel and extensions can be used by users Thanks, Haleh On 1/17/07, Jim Marino [EMAIL PROTECTED] wrote: Hi, A few of us are participating in the SCA Assembly offsite this week. The outcome of the offsite is that there will be a number of changes introduced into the specification which will impact the kernel and extensions. We can summarize and discuss the changes in separate threads but I wanted to propose a way for handling these changes which will allow kernel and extension development to proceed apace while minimizing instability. This proposal is also intended to allow us to introduce the remaining modularity changes that have been previously discussed. Specifically, I propose we initiate a release of kernel over the next several days which serve as a baseline for extension development. This release of kernel would be intended only for internal extension development and not for end-users. The purpose of the release is to allow kernel changes to be introduced without causing instability in the extensions. Later, a stable kernel release will be made which extensions will upgrade to. This release would be the kernel release we have been discussing over the last couple of weeks. When, extensions are ready, they would be released individually or in sets. I see this process happing in the following steps: 1. Release a internal-use kernel version, which will be initiated over the next couple of days 2. Right after, switch extensions to build off the the do-not-use kernel version 3. Continue development of kernel and extensions simultaneously. At this point we also reorganize the build tree and extensions as we previously described, grouping extensions and samples by how they will be distributed 5. Release a version of kernel with a stable SPI (the Java kernel release), incorporating the new SCA changes 6. Release extensions individually or in sets as they are ready Comments/suggestions/thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 I think this is a very good plan. It will allow the kernel to evolve and start implementing spec changes, and at the same time provides the stable base that the rest of the project needs to scale. Will there be a list of features from the POJO CI and assembly spec supported / not supported by the internal-use kernel release? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec changes, modularity, and scaling the Java SCA project
I'd suggest copying it and changing the version to 'do-not-use- SNAPSHOT' or something. Artifacts can be published to the SNAPSHOT repo but there's no need to formally release as this is really a development snapshot. It can be patched if something critical comes up but wouldn't be intended for long term development. Another alternative is to branch the kernel and do the new work there merging back in when its complete. I think that might be confusing though. -- Jeremy On Jan 18, 2007, at 8:39 AM, Jim Marino wrote: On Jan 18, 2007, at 8:27 AM, Rick wrote: Another question comes to mind, how will we handle issues found in the do-not-use kernel if they are found by extension writers and are blocking? Do they get fixed ? Parallel development on both kernels? Blocking till the new kernel is ready? I'd prefer not to branch. Since this will hopefully be a short period before we have another release, I think they would block or a patch could be applied locally to the extension. If someone has another solution, we could look at that. Jim - 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: Spec changes, modularity, and scaling the Java SCA project
On Jan 18, 2007, at 9:01 AM, Jeremy Boynes wrote: I'd suggest copying it and changing the version to 'do-not-use- SNAPSHOT' or something. Artifacts can be published to the SNAPSHOT repo but there's no need to formally release as this is really a development snapshot. It can be patched if something critical comes up but wouldn't be intended for long term development. Another alternative is to branch the kernel and do the new work there merging back in when its complete. I think that might be confusing though. -- I'd prefer the first option - do-not-use-SNAPSHOT. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] help setting up autoconf for PHP extension
I realize I haven't posted on progress with the PHP extension for a while. Having a few problems with it at the moment. I've been working on windows and have most of the changes made to enable references. However a couple of days ago I ran into a script dependent memory error in the embeded PHP engine. It's a little tricky to trace this because we have the following path to the running script Axis2C - CPP SCA - PHP - Script. I.e. there is a lot of C/C++ to go wrong and most of it we didn't write. Needless to say the script is fine outside of PHP. I've tried attacking the problem in various ways but am a little stumped on windows, e.g. I can't get purify to run the exe all the way to the point that it crashes. I'm now moving the whole environment over to linux to see if I get the same error and so that I can try some of the Linux based tools, e.g. valgrind. I need a little help with the autoconf setup for CPP SCA. Specifically where do I tell autoconf about the PHP engine include path that it needs to build the PHP extension? Thanks Simon
[jira] Commented: (TUSCANY-1046) NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION)
[ https://issues.apache.org/jira/browse/TUSCANY-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465858 ] Ignacio Silva-Lepe commented on TUSCANY-1046: - To indicate to the client runtime that a conversation needs to be started, the interface used by the client needs to be marked as conversational. In other words, there needs to be an indication in the contract between the client and the service that the interaction is conversational. The actual syntax to use is, at the moment, @Scope(CONVERSATION) [notice that the spec illustrates this by using @Scope(session)] but I believe that is supposed to change, probably to something like @Conversational. The fact that the contract between the client and the service is conversational does not necessarily imply that the service implementation must be managed as conversational by the container. So it is possible to have a conversational client interface but not a service implementation managed as conversational. The opposite case, a non-conversational client interface and a conversational service implementation, does not make sense if any client at all wants to interact conversationally with the service, and so the client runtime does not start a conversation. This case can still be useful for handling conversational callbacks, for instance, in which case some other mechanism for starting the conversation will be implemented, but it is not there yet. NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION) -- Key: TUSCANY-1046 URL: https://issues.apache.org/jira/browse/TUSCANY-1046 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Reporter: Lou Amodeo Assigned To: Ignacio Silva-Lepe Fix For: Java-SCA-Mx Attachments: test-CallBackSetCallbackConv.zip r494421 test-CallBackSetCallbackConv - This test attempts to use @Scope(CONVERSATION). Upon launch of test case using integration test environment the following NPE occurs. --- Test set: org.apache.tuscany.sca.test.CallBackSetCallbackConvITest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec FAILURE! testCallBackSetCallback(org.apache.tuscany.sca.test.CallBackSetCallbackConvITest) Time elapsed: 0.01 sec ERROR! java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:172) at java.util.concurrent.ConcurrentHashMap.containsKey(ConcurrentHashMap.java:760) at org.apache.tuscany.core.services.store.memory.MemoryStore.insertRecord(MemoryStore.java:110) at org.apache.tuscany.core.component.scope.ConversationalScopeContainer.getInstance(ConversationalScopeContainer.java:92) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:122) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:127) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:75) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122) at $Proxy22.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvITest.testCallBackSetCallback(CallBackSetCallbackConvITest.java:12) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec changes, modularity, and scaling the Java SCA project
Hi, Jeremy. I need a bit clarification: are you proposing not to release the current kernel but branch (with the latest kernel code in trunk) it instead so that the extension developers can reference stable SNAPSHOT versions of the current level kernel while we make breaking changes in trunk? Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, January 18, 2007 9:01 AM Subject: Re: Spec changes, modularity, and scaling the Java SCA project I'd suggest copying it and changing the version to 'do-not-use- SNAPSHOT' or something. Artifacts can be published to the SNAPSHOT repo but there's no need to formally release as this is really a development snapshot. It can be patched if something critical comes up but wouldn't be intended for long term development. Another alternative is to branch the kernel and do the new work there merging back in when its complete. I think that might be confusing though. -- Jeremy On Jan 18, 2007, at 8:39 AM, Jim Marino wrote: On Jan 18, 2007, at 8:27 AM, Rick wrote: Another question comes to mind, how will we handle issues found in the do-not-use kernel if they are found by extension writers and are blocking? Do they get fixed ? Parallel development on both kernels? Blocking till the new kernel is ready? I'd prefer not to branch. Since this will hopefully be a short period before we have another release, I think they would block or a patch could be applied locally to the extension. If someone has another solution, we could look at that. Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-965) Context Injection is not functioning
[
https://issues.apache.org/jira/browse/TUSCANY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465865
]
Lou Amodeo commented on TUSCANY-965:
I agree, its working with r497564.
Context Injection is not functioning
Key: TUSCANY-965
URL: https://issues.apache.org/jira/browse/TUSCANY-965
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core, Java SCA Integration Tests
Affects Versions: Java-SCA-M3
Reporter: Lou Amodeo
Fix For: Java-SCA-M3
Appears that Contesxt injection when using setters and attributes is not
working. In each case the context attribute is null.
a) setter method
package org.apache.tuscany.sca.test;
import org.osoa.sca.CurrentCompositeContext;
import org.osoa.sca.ServiceReference;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Remotable;
import org.osoa.sca.annotations.Scope;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import junit.framework.Assert;
@Service(CallBackSetCallbackClient.class)
public class CallBackSetCallbackClientImpl implements
CallBackSetCallbackClient {
@Reference
protected CallBackSetCalbackService aCallBackService;
@Reference
protected CallBackSetCallbackCallback callBack;
private CompositeContext context;
@Context
public void setContext(CompositeContext aContext)
{
context = aContext;
}
public void run() {
if (context == null)
System.out.println(Context is null);
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
Context is null
b) attribute
package org.apache.tuscany.sca.test;
import org.osoa.sca.CurrentCompositeContext;
import org.osoa.sca.ServiceReference;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Remotable;
import org.osoa.sca.annotations.Scope;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import junit.framework.Assert;
@Service(CallBackSetCallbackClient.class)
public class CallBackSetCallbackClientImpl implements
CallBackSetCallbackClient {
@Reference
protected CallBackSetCalbackService aCallBackService;
@Reference
protected CallBackSetCallbackCallback callBack;
@Context
protected CompositeContext context;
public void run() {
if (context == null)
System.out.println(Context is null);
[WARNING] Unable to get resource from repository central
(http://repo1.maven.or
/maven2)
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
Context is null
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-965) Context Injection is not functioning
[
https://issues.apache.org/jira/browse/TUSCANY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Silva-Lepe closed TUSCANY-965.
--
Context Injection is not functioning
Key: TUSCANY-965
URL: https://issues.apache.org/jira/browse/TUSCANY-965
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core, Java SCA Integration Tests
Affects Versions: Java-SCA-M3
Reporter: Lou Amodeo
Fix For: Java-SCA-M3
Appears that Contesxt injection when using setters and attributes is not
working. In each case the context attribute is null.
a) setter method
package org.apache.tuscany.sca.test;
import org.osoa.sca.CurrentCompositeContext;
import org.osoa.sca.ServiceReference;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Remotable;
import org.osoa.sca.annotations.Scope;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import junit.framework.Assert;
@Service(CallBackSetCallbackClient.class)
public class CallBackSetCallbackClientImpl implements
CallBackSetCallbackClient {
@Reference
protected CallBackSetCalbackService aCallBackService;
@Reference
protected CallBackSetCallbackCallback callBack;
private CompositeContext context;
@Context
public void setContext(CompositeContext aContext)
{
context = aContext;
}
public void run() {
if (context == null)
System.out.println(Context is null);
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
Context is null
b) attribute
package org.apache.tuscany.sca.test;
import org.osoa.sca.CurrentCompositeContext;
import org.osoa.sca.ServiceReference;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Remotable;
import org.osoa.sca.annotations.Scope;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import junit.framework.Assert;
@Service(CallBackSetCallbackClient.class)
public class CallBackSetCallbackClientImpl implements
CallBackSetCallbackClient {
@Reference
protected CallBackSetCalbackService aCallBackService;
@Reference
protected CallBackSetCallbackCallback callBack;
@Context
protected CompositeContext context;
public void run() {
if (context == null)
System.out.println(Context is null);
[WARNING] Unable to get resource from repository central
(http://repo1.maven.or
/maven2)
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
Context is null
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-966) getRequestContext() does not return a Context
[
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465871
]
Lou Amodeo commented on TUSCANY-966:
With r497564 the getRequestContext() no longer hangs but issues the following:
Test set: org.apache.tuscany.sca.test.CallBackApiITest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.07 sec
FAILURE!
testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest) Time elapsed:
0.01 sec ERROR!
java.lang.UnsupportedOperationException
at
org.apache.tuscany.core.implementation.composite.ManagedCompositeContext.getRequestContext(ManagedCompositeContext.java:54)
at
org.apache.tuscany.sca.test.CallBackApiServiceImpl.getCallBackInterface(CallBackApiServiceImpl.java:52)
at
org.apache.tuscany.sca.test.CallBackApiServiceImpl.knockKnock(CallBackApiServiceImpl.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:93)
at
org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67)
at
org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44)
at
org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(PassByValueInterceptor.java:68)
at
org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41)
at
org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(AbstractOutboundInvocationHandler.java:91)
at
org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:166)
at $Proxy23.knockKnock(Unknown Source)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.test3a(CallBackApiClientImpl.java:36)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:93)
at
org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67)
at
org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44)
at
org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45)
at
org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122)
at $Proxy22.run(Unknown Source)
at
org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
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, Java SCA Integration Tests
Affects Versions: Java-SCA-M3
Reporter: Lou Amodeo
Assigned To: Jim Marino
Fix For: Java-SCA-M3
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:
[jira] Updated: (TUSCANY-1050) For some schemas, the code generated will not compile (notication and settable problems)
[ https://issues.apache.org/jira/browse/TUSCANY-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1050: Attachment: TUSCANY1050.patch For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SCA-M3, Java-SCA-Mx Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Mx Attachments: TUSCANY1050.patch, TUSCANY1050.patch, TUSCANY1050.xsd Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1050) For some schemas, the code generated will not compile (notication and settable problems)
[ https://issues.apache.org/jira/browse/TUSCANY-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465874 ] David T. Adcox commented on TUSCANY-1050: - Thanks for the pointers on java jet files. I've updated the patch to properly format the output. For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SCA-M3, Java-SCA-Mx Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Mx Attachments: TUSCANY1050.patch, TUSCANY1050.patch, TUSCANY1050.xsd Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] help setting up autoconf for PHP extension
Simon Laws wrote: I realize I haven't posted on progress with the PHP extension for a while. Having a few problems with it at the moment. I've been working on windows and have most of the changes made to enable references. However a couple of days ago I ran into a script dependent memory error in the embeded PHP engine. It's a little tricky to trace this because we have the following path to the running script Axis2C - CPP SCA - PHP - Script. I.e. there is a lot of C/C++ to go wrong and most of it we didn't write. Needless to say the script is fine outside of PHP. I've tried attacking the problem in various ways but am a little stumped on windows, e.g. I can't get purify to run the exe all the way to the point that it crashes. I'm now moving the whole environment over to linux to see if I get the same error and so that I can try some of the Linux based tools, e.g. valgrind. I need a little help with the autoconf setup for CPP SCA. Specifically where do I tell autoconf about the PHP engine include path that it needs to build the PHP extension? Thanks Simon Simon, You need to configure two environment variables PHP_INCLUDE and PHP_LIB. Here's what I have on my machine: PHP_INCLUDE=$HOME/Tuscany/php5/php-5.2.0-bin/include/php export PHP_INCLUDE PHP_LIB=$HOME/Tuscany/php5/php-5.2.0-bin/lib export PHP_LIB Then run autogen.sh, then configure --prefix=$TUSCANY_SCACPP --with-axis2c --enable-all-extensions as usual. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec changes, modularity, and scaling the Java SCA project
On Jan 18, 2007, at 12:35 PM, Raymond Feng wrote: Hi, Jeremy. I need a bit clarification: are you proposing not to release the current kernel but branch (with the latest kernel code in trunk) it instead so that the extension developers can reference stable SNAPSHOT versions of the current level kernel while we make breaking changes in trunk? Kind of, yes. It would be a stable snapshot but would not be released by the project at this time - this would make Jim's do-not-use criteria clear. If we decided later to Release it, we would just need to vote on the content at that time. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OverrideOptions for references?
Hi, When I investigate the issue reported by JIRA http://issues.apache.org/jira/browse/TUSCANY-994, I find there are inconsistencies for the references. 1) In the assembly spec, the syntax of the reference is: for componentType: reference name=xs:NCName override=sca:OverrideOptions? multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ /reference for composite: reference name=xs:NCName override=sca:OverrideOptions? multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* /reference OverrideOptions has the value of must, may, and no. 2) In the java CI spec, the syntax of the @Reference annotation is: The @Reference annotation has the following attributes: * name - the name of the reference, which defaults to the name of the field of the Java class * required - whether injection of service or services is required, which defaults to false Question 1: How do we annotate the reference with override=no? I assume override=must is required=true and override=may is required=false. Question 2: The current Tuscany ReferenceDefinition model matches the attribute required of the java @Reference annotation and the ReferenceLoader doesn't parse the override attribute at all. It is a bug, right? Question 3: It seems that SCA spec issue 44 will have some impacts on this, is there any update? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory
[ https://issues.apache.org/jira/browse/TUSCANY-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes resolved TUSCANY-1066. Resolution: Won't Fix This should work with just the runtime/standalone assembly. We should remove the old distribution. Failing to run samples with Standalone distributions : Unable to locate profile directory - Key: TUSCANY-1066 URL: https://issues.apache.org/jira/browse/TUSCANY-1066 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Luciano Resende Fix For: Java-SCA-M3 Build a distribution and try to run standalone sample calculator Exception in thread main java.io.FileNotFoundException: Unable to locate profile directory: d:\temp\sca_standalone_distribution\profiles\launcher at org.apache.tuscany.runtime.standalone.DirectoryHelper.getProfileDirectory(DirectoryHelper.java:124) at org.apache.tuscany.launcher.Main.createRuntimeInfo(Main.java:89) at org.apache.tuscany.launcher.Main.main(Main.java:56) Workaround : build : java/sca/runtime/standalone/assembly then overlap the generated zip in the standalone distribution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Correct SCA Standalone distribution, Fwd: [jira] Resolved: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory
Thanks for looking into this Jeremy, Are you saying that distributions/sca/standalone is kind of obsolete right now ? What is going to be the right basic standalone distribution we should use, and tell others to use ? the assembly zip directly ? -- Luciano Resende http://people.apache.org/~lresende -- Forwarded message -- From: Jeremy Boynes (JIRA) tuscany-dev@ws.apache.org Date: Jan 18, 2007 3:35 PM Subject: [jira] Resolved: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory To: tuscany-dev@ws.apache.org [ https://issues.apache.org/jira/browse/TUSCANY-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Jeremy Boynes resolved TUSCANY-1066. Resolution: Won't Fix This should work with just the runtime/standalone assembly. We should remove the old distribution. Failing to run samples with Standalone distributions : Unable to locate profile directory - Key: TUSCANY-1066 URL: https://issues.apache.org/jira/browse/TUSCANY-1066 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Luciano Resende Fix For: Java-SCA-M3 Build a distribution and try to run standalone sample calculator Exception in thread main java.io.FileNotFoundException: Unable to locate profile directory: d:\temp\sca_standalone_distribution\profiles\launcher at org.apache.tuscany.runtime.standalone.DirectoryHelper.getProfileDirectory( DirectoryHelper.java:124) at org.apache.tuscany.launcher.Main.createRuntimeInfo(Main.java:89) at org.apache.tuscany.launcher.Main.main(Main.java:56) Workaround : build : java/sca/runtime/standalone/assembly then overlap the generated zip in the standalone distribution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Correct SCA Standalone distribution, Fwd: [jira] Resolved: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory
On Jan 18, 2007, at 4:00 PM, Luciano Resende wrote: Thanks for looking into this Jeremy, Are you saying that distributions/sca/standalone is kind of obsolete right now ? Yes. I'll remove it to cut the confusion. What is going to be the right basic standalone distribution we should use, and tell others to use ? the assembly zip directly ? The assembly zip in trunk is the most current. I would suggest people who want something a little more stable use M2. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1028) Autowire should support all compatible services interfaces in class hierarchy
[ https://issues.apache.org/jira/browse/TUSCANY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465929 ] Raymond Feng commented on TUSCANY-1028: --- Jeremy, it seems that you have fixed the problem in CompositeComponentExtension.java by checking intterfaze.isAssignable(serviceInterface). Can you confirm? Thanks, Raymond Autowire should support all compatible services interfaces in class hierarchy - Key: TUSCANY-1028 URL: https://issues.apache.org/jira/browse/TUSCANY-1028 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-SCA-M3 When a component registers as an autowire target other components should be able to autowire to is using any super-interface rather than just the interface it registers with. For example, if X1 extends X and a component offers service X1 then it should be a valid target for clients with X references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1000) Components do not support multiple services
[
https://issues.apache.org/jira/browse/TUSCANY-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465931
]
Raymond Feng commented on TUSCANY-1000:
---
Hi,
I don't see this problem any more. I also search the trunk code and there's no
such exception with the given message. But I run into the same issue as
TUSCANY-1046.
Thanks,
Raymond
Components do not support multiple services
---
Key: TUSCANY-1000
URL: https://issues.apache.org/jira/browse/TUSCANY-1000
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core, Java SCA Integration Tests
Affects Versions: Java-SCA-M3
Reporter: Lou Amodeo
Assigned To: Jim Marino
Fix For: Java-SCA-M3
I have a component that implements multiple service interfaces at runtime the
locateService() receives an exception indicating that components can only
have 1 service. The CI spec states that a component can declare using
@Service an array of interfaces.
@Service(interfaces={ConversationsClient.class,ConversationsClient2.class})
public class ConversationsClientImpl implements ConversationsClient,
ConversationsClient2, ConversationsCallback {
---
Test set: org.apache.tuscany.sca.test.ConversationsITest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec
FAILURE!
testCallBackSetCallback(org.apache.tuscany.sca.test.ConversationsITest) Time
elapsed: 0 sec ERROR!
org.apache.tuscany.spi.component.TargetException: Component must have exactly
one service
at
org.apache.tuscany.core.implementation.java.JavaAtomicComponent.getServiceInstance(JavaAtomicComponent.java:72)
at
org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:268)
at
org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65)
at
org.apache.tuscany.sca.test.ConversationsITest.setUp(ConversationsITest.java:17)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at
org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.run(TuscanyITestMojo.java:122)
at
org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.runSurefire(TuscanyITestMojo.java:88)
at
org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.execute(TuscanyITestMojo.java:77)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
[jira] Resolved: (TUSCANY-1058) MavenEmbeddedRuntime incompatible with MonitorFactory
[
https://issues.apache.org/jira/browse/TUSCANY-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-1058.
---
Resolution: Cannot Reproduce
MavenEmbeddedRuntime incompatible with MonitorFactory
-
Key: TUSCANY-1058
URL: https://issues.apache.org/jira/browse/TUSCANY-1058
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Reporter: Lou Amodeo
Fix For: Java-SCA-M3
r496640. Looks like an incompatible change occurred with MonitorFactory?
maven2)
INFO] [tuscany-itest:start {execution: start}]
INFO] Starting Tuscany...
INFO]
ERROR] FATAL ERROR
INFO]
INFO]
org/apache/tuscany/sca/plugin/itest/MavenEmbeddedRuntime.createDefaultMon
torFactory()Lorg/apache/tuscany/host/MonitorFactory;
INFO]
INFO] Trace
ava.lang.NoSuchMethodError:
org/apache/tuscany/sca/plugin/itest/MavenEmbeddedRu
time.createDefaultMonitorFactory()Lorg/apache/tuscany/host/MonitorFactory;
at
org.apache.tuscany.sca.plugin.itest.TuscanyStartMojo.execute(TuscanyS
artMojo.java:257)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
Manager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ltLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
ecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
tLifecycleExecutor.java:454)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-903) Integration testing for SCA properties
[ https://issues.apache.org/jira/browse/TUSCANY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-903. Resolution: Fixed The test cases are now checked in under java/testing/sca/itest/propertyTest Integration testing for SCA properties -- Key: TUSCANY-903 URL: https://issues.apache.org/jira/browse/TUSCANY-903 Project: Tuscany Issue Type: Test Components: Java SCA Core Reporter: Brent Daniel Fix For: Java-SCA-M3 Attachments: propertyTests.txt I have the start of some tests for component properties using the itest plugin that I would like to contribute to an integration test suite for tuscany. I plan on building on top of these, but would like to go ahead and contribute them and gather feedback so that we can nail down some basics. I will attach a patch with the current tests to this JIRA, but there are a few unresolved issues: 1) I'm not sure where these tests should live in the build. My proposal would be to place them in tuscany/java/sca/testing. 2) Will future integration tests be contained in one large bucket or will there be seperate buckets for various technology combinations? (ie, would there just be java/sca/testing or would there be java/sca/testing/properties, java/sca/testing/integrationWebapp, java/sca/testing/ws-bindings, etc?) 3) When does integration testing happen? Is it part of the main-line build or will it be required to run it seperately? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1028) Autowire should support all compatible services interfaces in class hierarchy
[ https://issues.apache.org/jira/browse/TUSCANY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes resolved TUSCANY-1028. Resolution: Fixed This is fixed although the solution is not very elegant. Autowire should support all compatible services interfaces in class hierarchy - Key: TUSCANY-1028 URL: https://issues.apache.org/jira/browse/TUSCANY-1028 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-SCA-M3 When a component registers as an autowire target other components should be able to autowire to is using any super-interface rather than just the interface it registers with. For example, if X1 extends X and a component offers service X1 then it should be a valid target for clients with X references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LocateService on reference with web service binding,
I was looking at http://issues.apache.org/jira/browse/TUSCANY-862 I tried changing the helloWorldClient sample to directly :locate the reference using a web service binding. This no longer gets an NPE. Currently it gets a ServiceRuntimeException: Local binding for service not found. This is thrown in AbstractCompositeContext.getInboundWire line 106. There is no match on the reference case cause the check on BindingType line 100 for match on Wire.LOCAL_BINDING and type is binding.ws Anyon know the reason for this check? Stack: org.apache.tuscany.core.launcher.CompositeContextImpl(org.apache.tuscany.core.implementation.composite.AbstractCompositeContext).getInboundWire(org.apache.tuscany.spi.component.SCAObject, org.apache.tuscany.spi.QualifiedName) line: 106 org.apache.tuscany.core.launcher.CompositeContextImpl(org.apache.tuscany.core.implementation.composite.AbstractCompositeContext).locateService(java.lang.ClassT, java.lang.String) line: 66 helloworld.HelloWorldClient.main(java.lang.String[]) line: 32 sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) line: not available [native method] sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 39 sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 25 java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) line: 585 org.apache.tuscany.launcher.Main.runApplication(java.io.File, java.lang.ClassLoader, java.lang.String[]) line: 154 org.apache.tuscany.launcher.Main.main(java.lang.String[]) line: 77 Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
about InboundWire and OutboundWire
Hi all: for example A means composite reference; B means component reference; C means other composite service if B be wired to A , is means A has InboundWire and B has OutboundWire if A has binding to C, is means A has OutboundWire and C has InboundWire Is this(I understand) true ? thaks - Mp3疯狂搜-新歌热歌高速下
java.lang.IllegalArgumentException when use DataFactory.create(Class interfaceClass)
Hello, is there anyone encounter following exception which occur when
I use DataFactoy to create a DataObject:
/*to create a DataObject**/
User user=(User)DataFactory.INSTANCE.create(User.class);
user.setUserId(sdo3);
user.setPassword(sdo3);
user.setName(sdo3);
user.setAvailable(1);
/*User DataObject**/
public interface User {
public String getUserId();
public void setUserId(String userId);
public String getPassword();
public void setPassword(String password);
public String getName();
public void setName(String name);
public String getAvailable();
public void setAvailable(String available);
}
/the exception thrown*/
java.lang.IllegalArgumentException
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:63)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:53)
at example.junit.UserTest.testAddUser(UserTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Appreciate your help in advance.
Best Regards,
Sam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ https://issues.apache.org/jira/browse/TUSCANY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan resolved TUSCANY-773. - Resolution: Fixed This is resolved since property values get loaded from component defintions. Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: https://issues.apache.org/jira/browse/TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Raymond Feng Fix For: Java-SCA-M3 Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, Tuscany-spec-sca-03-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
