Preparing to release trunk
I have tagged the sca parent pom in preparation for releasing trunk and am about to update the individual modules to use it. I am going to hold off from deploying the pom to the release repository for now so until then it will be necessary to build it locally first: $ cd tags/java/pom/sca/1.0-incubating $ mvn install I am also going to update trunk to use the candidate spec api jar that we are currently voting on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-897) BPEL container based on Apache Ode
[ https://issues.apache.org/jira/browse/TUSCANY-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-897: --- Fix Version/s: (was: Java-SCA-Mx) Java-SCA-2.0-Alpha > BPEL container based on Apache Ode > -- > > Key: TUSCANY-897 > URL: https://issues.apache.org/jira/browse/TUSCANY-897 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Common >Affects Versions: Java-SCA-Mx >Reporter: ant elder > Fix For: Java-SCA-2.0-Alpha > > Attachments: BpelServerLoader.java, container.bpel.zip, > container.bpel_edited.zip, Ode_Jar_New1.zip, Ode_Jar_New2.zip > > > JIRA for attaching patches to create the Tuscany BPEL container based on > Apache Ode. > There's a white paper on SCA and BPEL at: > http://osoa.org/display/Main/Service+Component+Architecture+Specifications > A draft specification is available at: > http://osoa.org/display/Main/Service+Component+Architecture+Specifications > The Tuscany container is at: > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1111) Interchangeability of Java and WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-: Component/s: (was: Java SCA Model) Java SCA Core > Interchangeability of Java and WSDL > --- > > Key: TUSCANY- > URL: https://issues.apache.org/jira/browse/TUSCANY- > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-SCA-integration >Reporter: ant elder > Fix For: Java-SCA-integration > > > JIRA to track issues related to interchangeability of Java and WSDL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-616) JavaServiceContract introspection should use the ImplementationProcessor mechanism
[ https://issues.apache.org/jira/browse/TUSCANY-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-616. -- Resolution: Fixed Fix Version/s: (was: Java-SCA-Mx) Java-SCA-2.0-Alpha > JavaServiceContract introspection should use the ImplementationProcessor > mechanism > -- > > Key: TUSCANY-616 > URL: https://issues.apache.org/jira/browse/TUSCANY-616 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Kernel >Affects Versions: Java-SCA-Mx >Reporter: Jeremy Boynes > Fix For: Java-SCA-2.0-Alpha > > > On the devlist, jboynes wrote: "Thinking a little more, using the > ImplementationProcessor mechanisms seems like a better way to tackle this. > One major advantage would be that we could add metadata to the service > contract based on data type or annotations (e.g. adding metadata saying that > a parameter should be bound using SDO which could be detected through the > marker interface or an @SDO annotation)." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1134) Getting started instructions for building samples
[ https://issues.apache.org/jira/browse/TUSCANY-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-1134. --- Resolution: Fixed Fix Version/s: (was: Java-M2) Java-SCA-2.0-Alpha We've added instructions in the alpha samples > Getting started instructions for building samples > - > > Key: TUSCANY-1134 > URL: https://issues.apache.org/jira/browse/TUSCANY-1134 > Project: Tuscany > Issue Type: Improvement > Components: Website >Affects Versions: Java-M2 >Reporter: Glyn Normington >Priority: Minor > Fix For: Java-SCA-2.0-Alpha > > > I tried to follow the "getting started" link to try Tuscany out for the first > time. I found you have to issue "mvn -N install" from the samples directory > to set up the parent. This was mentioned in > http://incubator.apache.org/tuscany/java_sca_overview.html but was *not* > mentioned in http://incubator.apache.org/tuscany/getting_started.html which > is a shame as the "getting started" link is likely to be a pretty common > starting point. > (Also, the symptoms of not having issued "mvn -N install" from the samples > directory were that building individual samples tried to download > dependencies from a non-existent maven repository rather than giving a more > helpful diagnostic such as reporting that the parent had not been set up > properly.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-810) JPA Support
[ https://issues.apache.org/jira/browse/TUSCANY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-810. -- Resolution: Fixed Fix Version/s: (was: Java-SCA-Mx) Java-SCA-2.0-Alpha > JPA Support > --- > > Key: TUSCANY-810 > URL: https://issues.apache.org/jira/browse/TUSCANY-810 > Project: Tuscany > Issue Type: New Feature >Affects Versions: Java-SCA-Mx >Reporter: Meeraj Kunnumpurath > Assigned To: Meeraj Kunnumpurath > Fix For: Java-SCA-2.0-Alpha > > > Initial support for injecting @PersistenceContext and @PersistenceUnit > annotations in implementation classes/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-896) java.lang.IndexOutOfBoundsException trying when there is no default service for the composite
[ https://issues.apache.org/jira/browse/TUSCANY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-896. -- Resolution: Fixed > java.lang.IndexOutOfBoundsException trying when there is no default service > for the composite > - > > Key: TUSCANY-896 > URL: https://issues.apache.org/jira/browse/TUSCANY-896 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Kernel >Affects Versions: Java-SCA-Mx > Environment: Win32 >Reporter: Luciano Resende > Assigned To: Jim Marino > Fix For: Java-SCA-Mx > > > See detailed discussion available at : > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10273.html > Following stack trace of the error. > java.lang.IndexOutOfBoundsException > : Index: 0, Size: 0 > java.util.ArrayList.RangeCheck(ArrayList.java:546) > java.util.ArrayList.get(ArrayList.java:321) > > org.apache.tuscany.spi.extension.CompositeComponentExtension.getServiceInstance(CompositeComponentExtension.java > :239) > > org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:269) > > org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) > org.apache.jsp.Company_jsp._jspService(Company_jsp.java:80) > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > org.apache.jasper.servlet.JspServletWrapper.service > (JspServletWrapper.java:332) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > javax.servlet.http.HttpServlet.service(HttpServlet.java > :802) > > org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports
[ https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-544: --- Fix Version/s: (was: Java-SCA-Future) Tooling-Next > WSDL2Java should support WSDLs with schema imports > -- > > Key: TUSCANY-544 > URL: https://issues.apache.org/jira/browse/TUSCANY-544 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Ron Gavlin > Fix For: Tooling-Next > > > Many WSDLs choose to import schemas rather than embedding types inline. The > tuscany WSDL2JavaGenerator does not currently support this type of usage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1019) WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1019: Fix Version/s: (was: Java-SCA-Future) Tooling-Next Affects Version/s: (was: Java-SCA-Future) > WSDL2Java should offer option to generate Java signature with non-wrapper > style mapping from doc-lit-wrapped WSDL > - > > Key: TUSCANY-1019 > URL: https://issues.apache.org/jira/browse/TUSCANY-1019 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Tools, Specification >Affects Versions: Java-M2 >Reporter: Scott Kurz > Assigned To: Jean-Sebastien Delfino > Fix For: Tooling-Next > > > It is currently possible to use the WSDL2Java tooling to do each of: > * start w/ doc-lit-wrapped WSDL and generate a wrapper-style Java mapping > * start w/ doc-lit-nonwrapped WSDL and generate a non-wrapper-style Java > mapping > However it is not possible to start w/ doc-lit-wrapped WSDL and generate a > non-wrapper-style Java mapping. > You might want to do this in order to work with the input as a single SDO > rather than having the individual child elements appear on the Java signature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-545) WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename.
[ https://issues.apache.org/jira/browse/TUSCANY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-545: --- Fix Version/s: (was: Java-SCA-Future) Tooling-Next > WSDL2Java should support a URI wsdlname command-line parameter. It currently > treats the wsdlname parm as a filename. > > > Key: TUSCANY-545 > URL: https://issues.apache.org/jira/browse/TUSCANY-545 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Ron Gavlin > Fix For: Tooling-Next > > > WSDL2Java should support a URI wsdlname command-line parameter. It currently > treats the wsdlname parm as a filename. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1137) WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1137: Fix Version/s: (was: Java-SCA-Future) Tooling-Next > WSDL2Java tool should be able to handle imports of other WSDL files into the > original WSDL > -- > > Key: TUSCANY-1137 > URL: https://issues.apache.org/jira/browse/TUSCANY-1137 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Scott Kurz >Priority: Minor > Fix For: Tooling-Future > > Attachments: PortType.wsdl, Service.wsdl > > > If I, for example, define my portType in one WSDL and then import that into > another WSDL where I define my Service/Port, I will have problems, like the > following when running WSDL2Java against the latter WSDL: > Caused by: java.lang.NullPointerException > at > org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped(JavaInterfaceEmitter.java:136) > at > org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.getInputElement(JavaInterfaceEmitter.java:171) > at > org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1926) > at > org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1841) > at > org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:993) > at > org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.writeInterface(JavaInterfaceEmitter.java:196) > at > org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:200) > I believe a key to the problem is the line in > WSDL2JavaGenerator.generateFromWSDL(): > xsdHelper.define(inputStream, inputFile.toURI().toString()); > Though this method is called the EMF 'packageRegistry' field is essentially > empty. I assume this is because XSDHelper.define(...) will not handle a > WSDL import.(It does seem to be handling an XSD schema import, however). > I don't know enough of the SDO APIs to suggest a better method than the > xsdHelper.define(..) we're invoking, however. > I'll attach an example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1142) Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType
[
https://issues.apache.org/jira/browse/TUSCANY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1142:
Fix Version/s: (was: Java-SCA-Future)
(was: Java-SCA-integration)
Tooling-Future
> Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with
> named complexType
>
>
> Key: TUSCANY-1142
> URL: https://issues.apache.org/jira/browse/TUSCANY-1142
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Tools
>Affects Versions: Java-M2
>Reporter: Scott Kurz
> Fix For: Tooling-Future
>
>
> Our WSDL2Java tool maps the following WSDL pattern onto a non-wrapped Java
> interface even when using doc-lit-wrapped WSDL:
> ...
>
>
>
>
>
>
>
> ...
>
> I noticed that wsimport seems to unwrap this and produce:
> getGreetings(String)
> whereas our WSDL2Java treats this as non-wrapped and generates:
> getGreetings(getGreetings)
> The key line of Tuscany code is:
> org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped()
> if (typeMappingEntry.isAnonymous()) {
> wrapped = true;
> }
> As I claim in this JIRA, TUSCANY-1019, it would be nice to ALSO have the
> ability to generate a non-wrapped Java interface from the given WSDL pattern,
> but we should also allow for generation of a wrapped interface (the wrapped
> by my guess should be the default).
> Yang Zhong posted this reply in agreement to the Tuscany dev list.
> Once binding is involved within WSDL2Java, one WSDL portType/message can end
> up with multiple Java classes respective to different bindings.
> It mixes business logic and wire format :-(
> Assuming involving binding is de facto, and only one binding each WSDL
> portType/message,
> maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such as:
> 1. not wrapped if the style is not document or the use is not literal
> 2. not wrapped if the message has more than one parts
> 3. not wrapped if the part isn't element or its local name doesn't match the
> operation local name
> 4. not wrapped if the operation name isn't unique within the portType
> Yes, I agree with Scott not to take isAnonymous() into account.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages
[ https://issues.apache.org/jira/browse/TUSCANY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-978: --- Fix Version/s: (was: Java-SCA-Future) Tooling-Future > Tuscany WSDL2Java can't handle WSDL fault messages > -- > > Key: TUSCANY-978 > URL: https://issues.apache.org/jira/browse/TUSCANY-978 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-M2 > Environment: Tuscany Java-M2 and current trunk >Reporter: Matthew Sykes > Fix For: Tooling-Future > > Attachments: AccountService.wsdl > > > I've been playing with the BigBank sample and have added a fault to the > AccountService's withdraw operation. After changing the AccountService.wsdl > (attached), the Tuscany WSDL2Java no longer works: > [INFO] Generating Java service interfaces from > /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: > org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped > to the name insufficientFundsFault with namespace > http://www.bigbank.com/account > [INFO] > > [INFO] Trace > java.lang.IllegalArgumentException: > org.apache.axis2.wsdl.codegen.CodeGenerationException: > org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped > to the name insufficientFundsFault with namespace > http://www.bigbank.com/account > at > org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244) > at > org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) > 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 java.lang.reflect.Method.invoke(Method.java:615) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: > org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped > to the name insufficientFundsFault with namespace > http://www.bigbank.com/account > at > org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178) > at > org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242) > ... 19 more > Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type > was mapped to the name insufficientFundsFault with namespace > http://www.bigbank.com/account > at > org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73) > at > org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958) > at > org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguag
[jira] Updated: (TUSCANY-199) Bigbank sample should use wires instead of hacked up SOAP addresses
[ https://issues.apache.org/jira/browse/TUSCANY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-199: --- Fix Version/s: (was: Java-SCA-Future) Java-BigBank-Future Affects Version/s: (was: Java-SCA-Future) > Bigbank sample should use wires instead of hacked up SOAP addresses > --- > > Key: TUSCANY-199 > URL: https://issues.apache.org/jira/browse/TUSCANY-199 > Project: Tuscany > Issue Type: Bug > Components: Java BigBank Scenario >Reporter: Jean-Sebastien Delfino >Priority: Minor > Fix For: Java-BigBank-Future > > > The bigbank sample uses a hacked up / fixed SOAP address in the WSDL to > connect the external service in the webclient module component to the entry > point of the account module component. > This is not how it should work. One very important feature of SCA illustrated > by BigBank is to allow module components to be wired together. So we should > change the sample to use wires. This is how the sample is actually described > in the "Building your first SCA application" spec companion document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-751) Update SDO overview of Tuscany site
[ https://issues.apache.org/jira/browse/TUSCANY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-751: --- Fix Version/s: (was: Java-SCA-Future) Website-Enhancements Affects Version/s: (was: Java-M2) > Update SDO overview of Tuscany site > --- > > Key: TUSCANY-751 > URL: https://issues.apache.org/jira/browse/TUSCANY-751 > Project: Tuscany > Issue Type: Improvement > Components: Website >Reporter: Yang ZHONG > Assigned To: Kelvin Goodson > Fix For: Website-Enhancements > > Attachments: ChangeSummary.gif, DataObject.gif, NewSdoOverview.zip, > NewSdoOverview2.zip, NewSdoOverview3.zip, overview.gif, property.gif, > sdouml.zip, type.gif > > > The overview says "SDO simplify and unify ... SDO is language neutral. SDO is > being implemented ... SDO PHP ... SDO can be used ... SDO is a natural format > for representing data on the wire in an SOA environment." > > With new comer hat on, I still don't know what SDO is briefly. > > How about a brief description right after "SDO is a natural format ..." > with a structural diagram clickable towards brief DataObject, Type, Property > and ChangeSummary description? > > SCA overview has demonstrated such a good example. > Thank Andrew for the support > and thank Kelvin and Geoff for the text contribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1057) Add overview of the multi-language and scripting support to the Tuscany Web site
[ https://issues.apache.org/jira/browse/TUSCANY-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1057: Fix Version/s: (was: Cpp-M3) (was: Java-SCA-Future) Website-Enhancements > Add overview of the multi-language and scripting support to the Tuscany Web > site > > > Key: TUSCANY-1057 > URL: https://issues.apache.org/jira/browse/TUSCANY-1057 > Project: Tuscany > Issue Type: Improvement >Affects Versions: Java-SCA-Future, Cpp-M3 >Reporter: Jean-Sebastien Delfino > Fix For: Website-Enhancements > > > We have detailed information in the readmes but no overview on the Web site. > We need an overview page describing this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-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 ] Jim Marino updated TUSCANY-824: --- Fix Version/s: (was: Java-SCA-2.0-Alpha) Java-SCA-2.0 > 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 Kernel >Affects Versions: Java-SCA-2.0-Alpha >Reporter: ant elder > Assigned To: Raymond Feng >Priority: Critical > Fix For: Java-SCA-2.0 > > > 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-610) Initial OSGi support effort
[ https://issues.apache.org/jira/browse/TUSCANY-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-610: --- Component/s: Java SCA OSGi Runtime > Initial OSGi support effort > --- > > Key: TUSCANY-610 > URL: https://issues.apache.org/jira/browse/TUSCANY-610 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA OSGi Runtime >Affects Versions: Java-SCA-Future > Environment: Equinox implementation of OSGi >Reporter: Joel Hawkins > Assigned To: Jim Marino > Fix For: Java-M2 > > Attachments: ClassloaderHook.java, OSGI-SCA.zip > > > An initial implementation of an OSGi binding for exposing SCA services as > OSGi services. > An initial implementation of an OSGi implementation for reusing OSGi services > as SCA atomic components > An OSGi-aware bootstrap environment (which can probably be reduced a bit) > A repackaging of some of the SupplyChain example > There's one class derived from an EPL-copyrighted class - I left the EPL > copyright intact. > The zip contains the samples, the OSGi binding, and a patch for the core. > Most of the patch is the OSGi launcher code. I don't think it belongs in the > core, but that's where I had it while developing. The only other bit in the > patch is a change of two of the Defaultbootstrapper's fields from private to > protected. > Also, some of the OSGi packaging for existing jars (spi, commands, etc) > aren't part of the zip. Not sure how you want to deal with the repackaging > issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1057) Add overview of the multi-language and scripting support to the Tuscany Web site
[ https://issues.apache.org/jira/browse/TUSCANY-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1057: Component/s: Website > Add overview of the multi-language and scripting support to the Tuscany Web > site > > > Key: TUSCANY-1057 > URL: https://issues.apache.org/jira/browse/TUSCANY-1057 > Project: Tuscany > Issue Type: Improvement > Components: Website >Affects Versions: Java-SCA-Future, Cpp-M3 >Reporter: Jean-Sebastien Delfino > Fix For: Website-Enhancements > > > We have detailed information in the readmes but no overview on the Web site. > We need an overview page describing this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA cleanup
As prep fro the release I tried to clean up the JIRA issues a bit. I created a version for the alpha kernel as well as started adding component tags for extensions that will be independently released in the future such as Spring and JPA. I also tried to place issues in proper categories, for example, moving tooling issues from kernel. Currently there are a number of issues in the 2.0 alpha kernel bucket that need to be tagged as a future release of the 2.0 kernel. I currently have a version for the 2.0 kernel but we may want to create one for "alpha2" or whatever we decide to call the next release that has federated support in it. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0
+1 Jim On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote: Please vote to approve the release of the sca-api's for r1.0 of the specification. This is the API code that we recently reviewed but please vote again to confirm the release. [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/spec/sca-api-r1.0/1.0-incubating [src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating-src.tgz http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating-src.zip [rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating.rat [pom] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom [binary] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar [javadoc] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating- javadoc.jar Thanks -- Jeremy - 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: [VOTE] Release 1.0-incubating version of sca-api-r1.0
+1 From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Release 1.0-incubating version of sca-api-r1.0 Date: Sun, 4 Mar 2007 09:41:44 -0800 +1 Jim On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote: Please vote to approve the release of the sca-api's for r1.0 of the specification. This is the API code that we recently reviewed but please vote again to confirm the release. [tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/spec/sca-api-r1.0/1.0-incubating [src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating-src.tgz http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating-src.zip [rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating/sca-api-r1.0-1.0-incubating.rat [pom] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom [binary] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar [javadoc] http://people.apache.org/repo/m2-incubating-repository/ org/osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating- javadoc.jar Thanks -- Jeremy - 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] _ Exclusive Ed Byrne daily comedy clips on MSN Video http://specials.uk.msn.com/edbyrne/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-922) Target instance is not cached in reference proxy
[ https://issues.apache.org/jira/browse/TUSCANY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-922: --- Fix Version/s: (was: Java-SCA-2.0-Alpha) Java-SCA-2.0 > Target instance is not cached in reference proxy > > > Key: TUSCANY-922 > URL: https://issues.apache.org/jira/browse/TUSCANY-922 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Kernel >Affects Versions: Java-SCA-2.0-Alpha >Reporter: Greg Dritschler > Assigned To: Jim Marino >Priority: Minor > Fix For: Java-SCA-2.0 > > > The invocation handler and target invoker have code to support caching the > target instance to avoid doing a container lookup every time the target is > invoked. However no code exists to turn caching on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1039) axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError
[ https://issues.apache.org/jira/browse/TUSCANY-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1039: Component/s: (was: Java SCA Kernel) Java SCA Axis Binding Affects Version/s: (was: Java-SCA-Future) Java-SCA-Axis-Future Fix Version/s: Java-SCA-Axis-Future Move to Axis issues as this is an Axis problem > axis binding is requiring javax/servlet/Servlet in standalone launcher geting > noclassdefFoundError > -- > > Key: TUSCANY-1039 > URL: https://issues.apache.org/jira/browse/TUSCANY-1039 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding >Affects Versions: Java-SCA-Axis-Future >Reporter: Rick Rineholt > Assigned To: Rick Rineholt >Priority: Blocker > Fix For: Java-SCA-Axis-Future > > > axis binding is requiring javax/servlet/Servlet in standalone launcher geting > noclassdefFoundError > This was fixed a few days ago ... seems to be back again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1145) DefaultSCAContainer.stop()/LauncherImpl.shutdownRuntime() is leaking memory
[ https://issues.apache.org/jira/browse/TUSCANY-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1145: Component/s: (was: Java SCA Kernel) Moving this out as this is an integration-branch specific class and not part of the Kernel > DefaultSCAContainer.stop()/LauncherImpl.shutdownRuntime() is leaking memory > > > Key: TUSCANY-1145 > URL: https://issues.apache.org/jira/browse/TUSCANY-1145 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-SCA-integration >Reporter: Raymond Feng > > The PropertyTestCase from iTest-propertyTest suite is failing with > OutOfMemoryError. It has 18 test methods. As a result, the SCAContainer is > started and stopped for 18 times. The last two methods run out of memory due > to leaks in stop(). If we comment out a few methods or just run the failing > methods, it works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1032) Remove interface requirement in Kernel
[ https://issues.apache.org/jira/browse/TUSCANY-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1032: Affects Version/s: Java-SCA-2.0 Java-SCA-2.0-Alpha Fix Version/s: (was: Java-M2) Java-SCA-2.0 Summary: Remove interface requirement in Kernel (was: Remove interface requirement for scripting languages) Generalize the description. Most of the assumptions have been removed except for Java impl types which assumes an interface-based ServiceContract > Remove interface requirement in Kernel > -- > > Key: TUSCANY-1032 > URL: https://issues.apache.org/jira/browse/TUSCANY-1032 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Kernel >Affects Versions: Java-M2, Java-SCA-2.0-Alpha, Java-SCA-2.0 >Reporter: Andrew Borley > Fix For: Java-SCA-2.0 > > > See thread at > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10879.html > There are currently restrictions in the Java runtime that mean an interface > is required when writing Ruby components, but it would be cool if we didn't > force Ruby scripters to write that Java or WSDL interface. > Jim Marino: > It would be nice if the author doesn't need to specify Java or WSDL. I also > think the runtime should not require tooling to be run or force users to > generate things. Perhaps there can be a ruby.idl implementation that > introspects the Ruby artifact and handles this transparently? I imagine WSDL > (and Java) is a turn-off to Ruby people. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-922) Target instance is not cached in reference proxy
[ https://issues.apache.org/jira/browse/TUSCANY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-922: --- Affects Version/s: Java-SCA-2.0 > Target instance is not cached in reference proxy > > > Key: TUSCANY-922 > URL: https://issues.apache.org/jira/browse/TUSCANY-922 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Kernel >Affects Versions: Java-SCA-2.0-Alpha, Java-SCA-2.0 >Reporter: Greg Dritschler > Assigned To: Jim Marino >Priority: Minor > Fix For: Java-SCA-2.0 > > > The invocation handler and target invoker have code to support caching the > target instance to avoid doing a container lookup every time the target is > invoked. However no code exists to turn caching on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1111) Interchangeability of Java and WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-: Fix Version/s: Java-SCA-2.0 Affects Version/s: Java-SCA-2.0 Java-SCA-2.0-Alpha > Interchangeability of Java and WSDL > --- > > Key: TUSCANY- > URL: https://issues.apache.org/jira/browse/TUSCANY- > Project: Tuscany > Issue Type: Bug > Components: Java SCA Kernel >Affects Versions: Java-SCA-integration, Java-SCA-2.0-Alpha, Java-SCA-2.0 >Reporter: ant elder > Fix For: Java-SCA-integration, Java-SCA-2.0 > > > JIRA to track issues related to interchangeability of Java and WSDL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-695) JavaComponentTypeLoader.load() returns PojoComponentType which isn't a ModelObject
[
https://issues.apache.org/jira/browse/TUSCANY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino reassigned TUSCANY-695:
--
Assignee: Jeremy Boynes
> JavaComponentTypeLoader.load() returns PojoComponentType which isn't a
> ModelObject
> --
>
> Key: TUSCANY-695
> URL: https://issues.apache.org/jira/browse/TUSCANY-695
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Kernel
>Affects Versions: Java-SCA-2.0-Alpha
> Environment: r440401
>Reporter: Scott Kurz
> Assigned To: Jeremy Boynes
> Fix For: Java-SCA-2.0-Alpha
>
>
> When I tried using a componentType file along w/ my Java impl I got:
> org.apache.tuscany.spi.loader.UnrecognizedElementException :
> {http://www.osoa.org/xmlns/sca/1.0}componentType
> [{http://www.osoa.org/xmlns/sca/1.0}componentType ]
>
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:113)
> at
> org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadFromSidefile(JavaComponentTypeLoader.java
> )
> at
> org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:71)
> at
> org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java
> :47)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> at
> org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java
> :57)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
> at
> org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:133)
> at org.apache.tuscany.core.loader.ComponentLoader.load
> (ComponentLoader.java:84)
> at
> org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:57)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
> at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
> (CompositeLoader.java:77)
> at
> org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:52)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
> at
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java
> :64)
> at
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:56)
> at
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
> (CompositeComponentTypeLoader.java:38)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
> :118)
> at
> org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:93)
> at
> org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193)
> The problem wasn't the lack of a loader to load
> elems.rather, it was this line in JavaComponentTypeLoader:
> protected PojoComponentType loadFromSidefile(URL url, DeploymentContext
> deploymentContext) throws LoaderException {
> return loaderRegistry.load(null, url, PojoComponentType.class,
> deploymentContext);
> }
> Thie use of 'PojoComponentType.class' as argument is a problem. In
> LoaderRegistryImpl.load, we do (line 109):
> ModelObject mo = load(parent, reader, ctx);
> if (type.isInstance(mo)) {
> So we're loading into a ModelObject, (more specifically,
> org.apache.tuscany.spi.model.ComponentType), but the 'type' here is :
> PojoComponentType.class
> which is in pkg org.apache.tuscany.core.implementation.java and passed into
> the load(..) call.
> On the dev list, Raymond Feng answered my email describing the problem with
> this:
> The ComponentTypeElementLoader creates a generic ComponentType from
> the XML file but the code expects an instance of PojoComponentType. Now the
> question is how to map the generic ComponentType into the PojoComponentType
> if it's required. Jim, do you have ideas?
> Jim Marino replied:
> We should probably have the implementation loader handle creation of
> the particular component type class and populate it by recursing back
> into the loader since it is minimal code
> (ComponentTypeElementLoader). This would be a nice patch for someone
> to work on :-)
> Jim
--
This message is automatically generated by JIRA.
-
You can reply to th
[jira] Updated: (TUSCANY-1005) Build failure in loanappconversationWSClient\src\test\java\loanappconversation\LoanAppConversationTestCase.java
[ https://issues.apache.org/jira/browse/TUSCANY-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1005: Affects Version/s: (was: Java-SCA-Future) Java-M2 > Build failure in > loanappconversationWSClient\src\test\java\loanappconversation\LoanAppConversationTestCase.java > --- > > Key: TUSCANY-1005 > URL: https://issues.apache.org/jira/browse/TUSCANY-1005 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Fix For: Java-M2 > > > Compiling 1 source file to > X:\java\samples\sca\loanappconversationWSClient\target\test-classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > X:\java\samples\sca\loanappconversationWSClient\src\test\java\loanappconversation\LoanAppConversationTestCase.java:[56,14] > exception org.apache.tusc > .TargetNotFoundException is never thrown in body of corresponding try > statement > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 minutes 28 seconds > [INFO] Finished at: Tue Dec 19 06:21:44 PST 2006 > [INFO] Final Memory: 16M/33M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-632) In sca-core.xsd, top level element should be removed
[ https://issues.apache.org/jira/browse/TUSCANY-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-632. -- Resolution: Fixed > In sca-core.xsd, top level element should be removed > > > Key: TUSCANY-632 > URL: https://issues.apache.org/jira/browse/TUSCANY-632 > Project: Tuscany > Issue Type: Bug > Components: Specification >Affects Versions: Cpp-current >Reporter: Jean-Sebastien Delfino > Assigned To: Jean-Sebastien Delfino > Fix For: Cpp-M3 > > > is only allowed inside , so the following declaration > should be removed from sca-core.xsd: > > I will bring this issue to the OSOA spec group. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1090) A service with two operations exposed over a WS binding is not handling the incoming SOAP requests correctly
[ https://issues.apache.org/jira/browse/TUSCANY-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1090: Fix Version/s: Java-SCA-Axis-Future > A service with two operations exposed over a WS binding is not handling the > incoming SOAP requests correctly > > > Key: TUSCANY-1090 > URL: https://issues.apache.org/jira/browse/TUSCANY-1090 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding >Affects Versions: Java-M2 >Reporter: Johny Mathew >Priority: Critical > Fix For: Java-SCA-Axis-Future > > > A service with two operations exposed over a WS binding is not handling the > incoming SOAP requests correctly. I am running the helloworld-ws-asynch > sample. I am calling the getGreetings operation but the > getGreetingsWithCallback is being executed. In the wsdl file both the > SOAPActions are set to "" and looks like it is using the last operation > added to the table. The Axis2 runtime picks a MessageReceiver to dispatch the > incoming request on. It picks this based on the AxisOperation it calculates. > It's calculating the wrong operation. For some reason the > org.apache.axis2.engine.SOAPActionBasedDispatcher's findOperation() is doing > the calculation and it's just looking up the soapAction in a hashtable. I > don't know whether this is an issue for the axis2 runtime or a java2wsdl tool > issue (the tool should not leave the SOAPAction as "") -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-746) on tuscany/mail-lists.html - commits list on www.mail-archive.com is not always complete
[ https://issues.apache.org/jira/browse/TUSCANY-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-746. -- Resolution: Fixed Fixed in the cwiki-based site > on tuscany/mail-lists.html - commits list on www.mail-archive.com is not > always complete > > > Key: TUSCANY-746 > URL: https://issues.apache.org/jira/browse/TUSCANY-746 > Project: Tuscany > Issue Type: New Feature > Components: Website >Reporter: Tom Seelbach > Assigned To: Jim Marino >Priority: Minor > > The http://incubator.apache.org/tuscany/mail-lists.html commits points to : > http://www.mail-archive.com/tuscany-commits%40ws.apache.org/maillist.html > This page appears to be missing some commits. For example the apache.org > mail-archive: > http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200609.mbox/browser > Shows this commit : Thu Sep 21 12:04:16 2006 > r448634 but that commit is missing from > http://www.mail-archive.com/tuscany-commits%40ws.apache.org/maillist.html. > (jumps from 448576 to 548682 My suggestion is to change the commits list > pointer to http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1151) Support specification of and syntax according to the SCA spec
Support specification of and syntax according to the SCA spec Key: TUSCANY-1151 URL: https://issues.apache.org/jira/browse/TUSCANY-1151 Project: Tuscany Issue Type: Bug Components: Java SCA Spring Extension Affects Versions: Java-SCA-Spring-2.0-Alpha Reporter: Jim Marino Assigned To: Jim Marino Fix For: Java-SCA-Spring-2.0-Alpha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1152) Support Spring beans as eager-init singletons with references to SCA composite references
Support Spring beans as eager-init singletons with references to SCA composite references - Key: TUSCANY-1152 URL: https://issues.apache.org/jira/browse/TUSCANY-1152 Project: Tuscany Issue Type: Bug Components: Java SCA Spring Extension Affects Versions: Java-SCA-Spring-2.0-Alpha Reporter: Jim Marino Fix For: Java-SCA-Spring-2.0-Alpha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-695) JavaComponentTypeLoader.load() returns PojoComponentType which isn't a ModelObject
[
https://issues.apache.org/jira/browse/TUSCANY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477872
]
Scott Kurz commented on TUSCANY-695:
Since I opened this.. I just checked and can see that the specific issue
mentioned in the JIRA title has been addressed and a ModelObject is returned
now by JavaComponentTypeLoader.load(). I'm not sure if this was done by
following up on Jim's suggestion.
> JavaComponentTypeLoader.load() returns PojoComponentType which isn't a
> ModelObject
> --
>
> Key: TUSCANY-695
> URL: https://issues.apache.org/jira/browse/TUSCANY-695
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Kernel
>Affects Versions: Java-SCA-2.0-Alpha
> Environment: r440401
>Reporter: Scott Kurz
> Assigned To: Jeremy Boynes
> Fix For: Java-SCA-2.0-Alpha
>
>
> When I tried using a componentType file along w/ my Java impl I got:
> org.apache.tuscany.spi.loader.UnrecognizedElementException :
> {http://www.osoa.org/xmlns/sca/1.0}componentType
> [{http://www.osoa.org/xmlns/sca/1.0}componentType ]
>
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:113)
> at
> org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadFromSidefile(JavaComponentTypeLoader.java
> )
> at
> org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:71)
> at
> org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java
> :47)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> at
> org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java
> :57)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
> at
> org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:133)
> at org.apache.tuscany.core.loader.ComponentLoader.load
> (ComponentLoader.java:84)
> at
> org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:57)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
> at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
> (CompositeLoader.java:77)
> at
> org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:52)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
> at
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java
> :64)
> at
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:56)
> at
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
> (CompositeComponentTypeLoader.java:38)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
> at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
> :118)
> at
> org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:93)
> at
> org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193)
> The problem wasn't the lack of a loader to load
> elems.rather, it was this line in JavaComponentTypeLoader:
> protected PojoComponentType loadFromSidefile(URL url, DeploymentContext
> deploymentContext) throws LoaderException {
> return loaderRegistry.load(null, url, PojoComponentType.class,
> deploymentContext);
> }
> Thie use of 'PojoComponentType.class' as argument is a problem. In
> LoaderRegistryImpl.load, we do (line 109):
> ModelObject mo = load(parent, reader, ctx);
> if (type.isInstance(mo)) {
> So we're loading into a ModelObject, (more specifically,
> org.apache.tuscany.spi.model.ComponentType), but the 'type' here is :
> PojoComponentType.class
> which is in pkg org.apache.tuscany.core.implementation.java and passed into
> the load(..) call.
> On the dev list, Raymond Feng answered my email describing the problem with
> this:
> The ComponentTypeElementLoader creates a generic ComponentType from
> the XML file but the code expects an instance of PojoComponentType. Now the
> question is how to map the generic ComponentType into the PojoComponentType
> if it's required. Jim, do you have ideas?
> Jim Marino replied:
> We should probably have the implementation loader handle creation of
> the particular comp
Sourcecheck failures in core
I get a a bunch of sourcecheck failures in core (including PMD failures) - many of these relate to the marshallers and contribution service so Meeraj, Luciano, please could you clean them up. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1065) Coexistence problem between EMF and Tuscany SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477889 ] Fuhwei Lwo commented on TUSCANY-1065: - Frank, The slowness is caused by the namespace URI, "http://www.example.com/simple";. Since it's not registered with an EPackage, underneath EMF code is trying to open a connection to the Internet that took a long time to fail with an exception. Do you think we should keep this EMF's behavior in SDO space? In my opinion, we should drop it. > 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 > Fix For: Java-SDO-Mx > > Attachments: DeserializationNoSchemaTestCase.java > > > 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site switch to the cwiki
FYI, I've cut-over the site to using the cwiki which should go live as soon as the files replicate. I left the old site files in place under /site as there are still a few wiki links which point back to them (mainly the download pages). I'll try and convert those over as well over the next day. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sourcecheck failures in core
Sorry, I will do that this afternoon. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 1:37 AM To: tuscany-dev@ws.apache.org Subject: Sourcecheck failures in core I get a a bunch of sourcecheck failures in core (including PMD failures) - many of these relate to the marshallers and contribution service so Meeraj, Luciano, please could you clean them up. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
