[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] 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-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-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:
...types
complexType name=getGreetings
sequence
element name=name type=xsd:string/
/sequence
/complexType
element name=getGreetings type=tns:getGreetings/
...
/types
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-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-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-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-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 componentType
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 this email to add a comment to the issue online.
[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 component 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 component 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 component is only allowed inside composite, so the following declaration should be removed from sca-core.xsd: element name=component type=sca:Component/ 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] 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] Closed: (TUSCANY-640) Service and Reference do not support multiple binding elements
[ https://issues.apache.org/jira/browse/TUSCANY-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-640. -- Resolution: Fixed Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Assignee: Jim Marino (was: Luciano Resende) Service and Reference do not support multiple binding elements Key: TUSCANY-640 URL: https://issues.apache.org/jira/browse/TUSCANY-640 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Jeremy Boynes Assigned To: Jim Marino Priority: Critical Fix For: Java-SCA-2.0-Alpha According to the spec, Service and Reference definitions can have multiple bindings associated with them. Our config model and the associated loaders and builders only support a single binding -- 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-1069) Cannot access default service of a component implemented by a composite using locateService
[ https://issues.apache.org/jira/browse/TUSCANY-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-1069. --- Resolution: Fixed The spec has removed locateService() Cannot access default service of a component implemented by a composite using locateService --- Key: TUSCANY-1069 URL: https://issues.apache.org/jira/browse/TUSCANY-1069 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Jeremy Boynes Fix For: Java-SCA-M3 If the port part of the name supplied to locateService(Class, String) is empty then the class name of the supplied service is used. There is no guarantee that the composite has a single exposed service with that name. If the port name is null then we need to check that the component just has one exposed service and use that regardless of it's name. -- 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-910) CurrentCompositeContext.getContext() returns CompositeContext with null attributes
[ https://issues.apache.org/jira/browse/TUSCANY-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-910. -- Resolution: Fixed The spec has removed this API. CurrentCompositeContext.getContext() returns CompositeContext with null attributes -- Key: TUSCANY-910 URL: https://issues.apache.org/jira/browse/TUSCANY-910 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Environment: Windows XP Reporter: Yang Lei Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-M3 I noticed, that if I call CurrentCompositeContext.getContext(); to get CompositeContext, then the values of most of the api return null: composite name:null composite URI:null Request context:null I defined attributes in the java class(service impl class) with annotation @Context and @ComponentName . They also return null. -- 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-1080) Groovy container NoClassDefFoundError: groovy/lang/GroovyObject when running in standalone environment
[ https://issues.apache.org/jira/browse/TUSCANY-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1080: Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Groovy container NoClassDefFoundError: groovy/lang/GroovyObject when running in standalone environment -- Key: TUSCANY-1080 URL: https://issues.apache.org/jira/browse/TUSCANY-1080 Project: Tuscany Issue Type: Bug Components: Java SCA Groovy Container Affects Versions: Java-SCA-2.0-Alpha Reporter: ant elder Fix For: Java-SCA-2.0-Alpha When running the groovy helloworld sample in the standalone environment it fails with: Exception in thread main java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:92) at groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:457) at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode(GroovyClassLoader.java:475) at groovy.lang.GroovyClassLoader$ClassCollector.call(GroovyClassLoader.java:479) at org.codehaus.groovy.control.CompilationUnit$9.call(CompilationUnit.java:757) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:947) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:478) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:306) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:275) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:270) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:242) at org.apache.tuscany.container.groovy.GroovyComponentBuilder.build(GroovyComponentBuilder.java:81) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:110) at org.apache.tuscany.core.implementation.composite.AbstractCompositeBuilder.build(AbstractCompositeBuilder.java:35) at org.apache.tuscany.core.implementation.composite.CompositeBuilder.build(CompositeBuilder.java:44) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:110) at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java:142) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:97) at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:304) at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplication(AbstractRuntime.java:275) at org.apache.tuscany.launcher.Main.main(Main.java:71) -- 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-1071) Wiring from Source that has only a subset of operations on Target fails.
[
https://issues.apache.org/jira/browse/TUSCANY-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-1071.
---
Resolution: Fixed
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
Wiring from Source that has only a subset of operations on Target fails.
Key: TUSCANY-1071
URL: https://issues.apache.org/jira/browse/TUSCANY-1071
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-M3
Reporter: Rick Rineholt
Fix For: Java-SCA-2.0-Alpha
Tried running helloworldwsClient this fails with the below exception
NoMethodForOperationException for getGreetings1 operation. This operation
exists on the target (WSDL) but not on the source which SHOULD IMO wire. I
tried changing the logic in
org.apache.tuscany.core.wire.WireUtils.createInboundMapping to the following
which I think is better it tries to match source with target operations.
But it failed several unit test cases in core.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
MapMethod, InboundInvocationChain chains = new HashMapMethod,
InboundInvocationChain();
for(Method method : methods){
boolean found = false;
IteratorEntryOperation?, InboundInvocationChain entryI;
for ( entryI = wire.getInvocationChains().entrySet().iterator();
entryI.hasNext() !found ;) {
EntryOperation?, InboundInvocationChain mape =
entryI.next();
Operation? operation = mape.getKey();
InboundInvocationChain chain = mape.getValue();
if (JavaIDLUtils.match(operation, method)){
chains.put(method, chain);
found= true;
}
}
if(!found){
throw new NoMethodForOperationException(method.getName());
}
}
return chains;
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The exception
org.apache.tuscany.core.wire.WireUtils.createInboundMapping(org.apache.tuscany.spi.wire.InboundWire,
java.lang.reflect.Method[]) line: 90
org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.init(java.lang.Class?,
org.apache.tuscany.spi.wire.InboundWire) line: 153
org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.init(java.lang.Class?,
org.apache.tuscany.spi.wire.InboundWire,
org.apache.tuscany.spi.component.WorkContext) line: 76
org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(java.lang.ClassT,
org.apache.tuscany.spi.wire.Wire) line: 62
org.apache.tuscany.core.launcher.CompositeContextImpl(org.apache.tuscany.core.implementation.composite.AbstractCompositeContext).locateService(java.lang.ClassT,
java.lang.String) line: 76
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
--
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-291) Document our test case development guidelines
[ https://issues.apache.org/jira/browse/TUSCANY-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-291: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Assignee: Jeremy Boynes (was: Jim Marino) Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha Document our test case development guidelines - Key: TUSCANY-291 URL: https://issues.apache.org/jira/browse/TUSCANY-291 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-SCA-2.0-Alpha Reporter: Jean-Sebastien Delfino Assigned To: Jeremy Boynes Fix For: Java-SCA-2.0-Alpha This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need these guidelines on our web site. Jim has volunteered to do this. -- 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-862) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl
[ https://issues.apache.org/jira/browse/TUSCANY-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-862. -- Resolution: Fixed The spec has removed this API. NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl - Key: TUSCANY-862 URL: https://issues.apache.org/jira/browse/TUSCANY-862 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: ant elder Assigned To: Jim Marino Fix For: Java-SCA-M3 If you do CurrentCompositeContext.locateService on a reference which uses interface.wsdl you get a NPE: java.lang.NullPointerException at org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) at org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) at org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:275) at org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) at helloworld.HelloWorldWSClient.setUp(HelloWorldWSClient.java:46) Thats becuase the wire.getServiceContract().getInterfaceClass() returns null. To demonstrate change the helloworldwsclient to use the reference 'HelloWorldService' -- 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-643) Integrate Spring NS handling into tuscany impl.spring
[ https://issues.apache.org/jira/browse/TUSCANY-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-643. -- Resolution: Fixed Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Integrate Spring NS handling into tuscany impl.spring - Key: TUSCANY-643 URL: https://issues.apache.org/jira/browse/TUSCANY-643 Project: Tuscany Issue Type: Improvement Affects Versions: Java-M2 Reporter: Andy Piper Priority: Minor Fix For: Java-SCA-2.0-Alpha Attachments: spring.patch, springint.patch I fixed up the Spring impl to utiltize the namespace handling code properly. This is work in progress, but at least eliminates the need for changes to spring. -- 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-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 reassigned TUSCANY-922: -- Assignee: Jim Marino 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 Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Greg Dritschler Assigned To: Jim Marino Priority: Minor Fix For: Java-SCA-2.0-Alpha 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-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-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-Mx) Java-SCA-2.0-Alpha 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 Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Greg Dritschler Assigned To: Jim Marino Priority: Minor Fix For: Java-SCA-2.0-Alpha 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-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-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha 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-SCA-2.0-Alpha Reporter: ant elder Assigned To: Raymond Feng Priority: Critical Fix For: Java-SCA-2.0-Alpha 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] Closed: (TUSCANY-690) Optimize JDK WireService
[ https://issues.apache.org/jira/browse/TUSCANY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-690. -- Resolution: Fixed Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Optimize JDK WireService Key: TUSCANY-690 URL: https://issues.apache.org/jira/browse/TUSCANY-690 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Fix For: Java-SCA-2.0-Alpha Attachments: Tuscany-kernel-core-jdkwireservice-Sept-4.diff This is going to involve several things. To begin with Jim Marino had suggested the creation of dynamic classes for the proxies (instead of java.lang.reflect.Proxy) using ASM and bytecode generation. Please refer to the thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg07271.html Here is a patch that changes the 'createProxy' method of the JDKService class. It generates bytecodes for a proxy implementation class for the wire's interface. It then instantiates this class and returns it (instead of an instance of java.lang.reflect.Proxy as it used to before). After instantiation this proxy is set with the chains that correspond to each of the service methods. Hence during invocation there is no seek into a map based on the invoked method, to find the right chain. The invocation is made with right chain directly. I have been able to successfully compile and run most of the testcases. But a few fail since there are assetions that check if the proxy generated is of 'java.lang.relect.Proxy' type, which obviously is not. Before I go ahead and make those changes I would like to know if the current implementation is fine. I have tested the JavaScript testcases after these changes to the wiring and they work. Thanks - Venkat -- 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-1075) Composite without an implementation causes BuilderConfigException
[ https://issues.apache.org/jira/browse/TUSCANY-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-1075. --- Resolution: Won't Fix This is no longer valid with SCA 1.0 promotes syntax Composite without an implementation causes BuilderConfigException - Key: TUSCANY-1075 URL: https://issues.apache.org/jira/browse/TUSCANY-1075 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: Windows XP SP2, Tuscany M2 distribution Reporter: Andrew Schofield Priority: Minor Fix For: Java-SCA-M3 I've built the webapp/helloworldws sample and deployed it on Tomcat. I've also managed to invoke it using the standalone/helloworldwsclient sample. But, I was surprised to find that there was a (trivial) implementation in the composite of the client (HelloWorldServiceComponent) which just delegates the method calls to the back-end service. I'd really expected to write SCDL for a composite which wired a service directly to a reference with a Web-services binding. This would give a way of connecting an SCA client to an existing Web service without any implementation coding. Here's the SCDL that I tried: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:system=http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT name=helloworldwsclient dbsdo:import.sdo xmlns:dbsdo= http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2; location=wsdl/helloworld.wsdl/ service name=HelloWorldServiceComponent interface.wsdl xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance interface=http://helloworld#wsdl.interface(HelloWorld) wsdli:wsdlLocation=http://helloworld wsdl/helloworld.wsdl / reference name=helloWorldServiceHelloWorldService/reference /service reference name=HelloWorldService interface.wsdl xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance interface=http://helloworld#wsdl.interface(HelloWorld) wsdli:wsdlLocation=http://helloworld wsdl/helloworld.wsdl / binding.ws endpoint= http://helloworld#wsdl.endpoint(HelloWorldService/HelloWorldSoapPort) location=wsdl/helloworld.wsdl / /reference /composite And here's the exception that I got (using Tuscany Java M2): Exception in thread main org.apache.tuscany.spi.builder.BuilderConfigException: No interceptor for operation [getGreetings] at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:336) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:278) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:389) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:163) at org.apache.tuscany.spi.extension.CompositeComponentExtension.prepare(CompositeComponentExtension.java:460) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:86) at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136) at org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:87) at org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:83) -- 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-964) Class Cast Excdeption on Service Reference
[ https://issues.apache.org/jira/browse/TUSCANY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-964. -- Resolution: Won't Fix Casting like this is no longer possible with SCA 1.0 Class Cast Excdeption on Service Reference -- Key: TUSCANY-964 URL: https://issues.apache.org/jira/browse/TUSCANY-964 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Java SCA Integration Tests Reporter: Lou Amodeo Fix For: Java-SCA-M3 Attempt to set a calback using the API. It looks like the $Proxy19 returned does not impliment the ServiceReference interface. --- Test set: org.apache.tuscany.sca.test.CallBackSetCallbackITest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.021 sec FAILURE! testCallBackSetCallback(org.apache.tuscany.sca.test.CallBackSetCallbackITest) Time elapsed: 0.01 sec ERROR! java.lang.ClassCastException: $Proxy19 incompatible with org.osoa.sca.ServiceReference at org.apache.tuscany.sca.test.CallBackSetCallbackClientImpl.test1(CallBackSetCallbackClientImpl.java:54) at org.apache.tuscany.sca.test.CallBackSetCallbackClientImpl.run(CallBackSetCallbackClientImpl.java:29) at org.apache.tuscany.sca.test.CallBackSetCallbackITest.testCallBackSetCallback(CallBackSetCallbackITest.java:12) code snippit: ((ServiceReference) aCallBackService).setCallback(callBack); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1059) Tuscany has a different rule against the SCA spec on how to derive the service name from a java interface
[ https://issues.apache.org/jira/browse/TUSCANY-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1059: Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Tuscany has a different rule against the SCA spec on how to derive the service name from a java interface - Key: TUSCANY-1059 URL: https://issues.apache.org/jira/browse/TUSCANY-1059 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Specification Affects Versions: Java-SCA-2.0-Alpha Reporter: Raymond Feng Priority: Critical Fix For: Java-SCA-2.0-Alpha The current SCA spec says: The service names of the defined services default to the names of the interfaces or class, without the package name. But the tuscany implementation expects the fully-qualified java itnerface name as the service name, Please see the discussions at: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12518.html We either need to propose the change to the SCA spec or have the Tuscany conform to the spec. -- 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-1052) Bi-directional intefaces are assumed to be non-blocking but are not required to be
[ https://issues.apache.org/jira/browse/TUSCANY-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-1052. --- Resolution: Fixed Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Bi-directional intefaces are assumed to be non-blocking but are not required to be -- Key: TUSCANY-1052 URL: https://issues.apache.org/jira/browse/TUSCANY-1052 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2, Java-SCA-M3 Environment: Tuscany revision 495535 Reporter: Matthew Sykes Fix For: Java-SCA-2.0-Alpha Tuscany assumes that the forward operation of a bi-directional interface is non-blocking with respect to the client while the spec does not require that. Based on this assumption, Tuscany's implementation treats the forward operation as if it never returns anything but void and does not raise exceptions. This assumption generally results in an NPE on the client as the NonBlockingBridgingInterceptor was used in wiring. For further information, please see the development list threads associated with http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12511.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12780.html . According to those threads, this behavior is not compliant with the Assembly specification as written. -- 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-687) Add tuscany- as the prefix for our artifact ids
[ https://issues.apache.org/jira/browse/TUSCANY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-687. -- Resolution: Fixed Add tuscany- as the prefix for our artifact ids - Key: TUSCANY-687 URL: https://issues.apache.org/jira/browse/TUSCANY-687 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Fix For: Java-SCA-M3 -- 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-912) Can not define reference in component with multiple value(List or Array)
[ https://issues.apache.org/jira/browse/TUSCANY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-912: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Can not define reference in component with multiple value(List or Array) Key: TUSCANY-912 URL: https://issues.apache.org/jira/browse/TUSCANY-912 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Environment: Windows XP Reporter: Yang Lei Assigned To: Jim Marino Fix For: Java-SCA-2.0-Alpha I tryied both ListMyServcie and MyService [] component name=MyNewListService implementation.java class=mysca.test.myservice.impl.MyListServiceImpl/ reference name=myListServiceMyNCService/MyListService/reference reference name=myListServiceMyListServiceFor2006/MyListService/reference property name=serviceYear2007/property /component Both throw exception on type mis match: Caused by: org.apache.tuscany.spi.wire.IncompatibleServiceContractException: The remotable settings don't match [Service Contract[MyListService;],ServiceContract[MyListService]] at org.apache.tuscany.spi.wire.WireServiceExtension.checkCompatibility(WireServiceExtension.java:60) at org.apache.tuscany.core.builder.ConnectorImpl.checkIfWireable(ConnectorImpl.java:444) ... 25 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-293) Document the architecture of the core runtime
[ https://issues.apache.org/jira/browse/TUSCANY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-293: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha Document the architecture of the core runtime - Key: TUSCANY-293 URL: https://issues.apache.org/jira/browse/TUSCANY-293 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-SCA-2.0-Alpha Reporter: Jean-Sebastien Delfino Assigned To: Jim Marino Fix For: Java-SCA-2.0-Alpha 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 documentation on our web site. Jim and Jeremry have volunteered to do this. Assigning to Jim for now. -- 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-505) xsi:type on root element fo XML doc causes problems
[ https://issues.apache.org/jira/browse/TUSCANY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-505: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-M1) Java-SCA-2.0-Alpha xsi:type on root element fo XML doc causes problems --- Key: TUSCANY-505 URL: https://issues.apache.org/jira/browse/TUSCANY-505 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Environment: Windows XP Reporter: Simon Laws Fix For: Java-SCA-2.0-Alpha If I read the following doc: tns:RootElement xmlns:p=commonj.sdo xmlns:tns=http://www.apache.org/tuscany/interop; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.apache.org/tuscany/interop interop01.xsd SimpleTypeWithNameSimpleTypeWithName/SimpleTypeWithName /tns:RootElement With the following schema schema xmlns= http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.apache.org/tuscany/interop; xmlns:tns= http://www.apache.org/tuscany/interop; include schemaLocation=interop10.xsd/ !-- top level test type -- complexType name=ComplexTypeRootType sequence !-- simple types -- element name=SimpleTypeWithName type=tns:SimpleTypeWithNameType/ /sequence /complexType element name=RootElement type=tns:ComplexTypeRootType/ /schema The I get a valid document (doc) with some data objects in it out of the following code: FileInputStream inFileStream = new FileInputStream (inFileName); XMLDocument doc = XMLHelper.INSTANCE.load(inFileStream); If I try in read in (note I have added and xsi:type attribute): tns:RootElement xmlns:p=commonj.sdo xsi:type=tns:ComplexTypeRootType xmlns:tns=http://www.apache.org/tuscany/interop xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.apache.org/tuscany/interop interop01.xsd SimpleTypeWithNameSimpleTypeWithName/SimpleTypeWithName /tns:RootElement The XMLHelper silently makes an empty document, i.e. the root element is null. I talked with Frank and he suggested changing the xsi:type to refer to a type that extends the root element type. This produced the same effect, i.e. and empty document. However xsi:type does seem to behave in both the base type and extension type case when attached to elements other than the root element. -- 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-292) Document our logging guidelines
[ https://issues.apache.org/jira/browse/TUSCANY-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-292: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha Document our logging guidelines --- Key: TUSCANY-292 URL: https://issues.apache.org/jira/browse/TUSCANY-292 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-SCA-2.0-Alpha Reporter: Jean-Sebastien Delfino Assigned To: Jeremy Boynes Fix For: Java-SCA-2.0-Alpha This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need these guidelines on our web site. Jeremy has volunteered to do this. -- 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-1076) Dynamic outbound wire for CompositeContext.locateService
[ https://issues.apache.org/jira/browse/TUSCANY-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-1076. --- Resolution: Fixed This is not valid anymore with SCA 1.0 Dynamic outbound wire for CompositeContext.locateService Key: TUSCANY-1076 URL: https://issues.apache.org/jira/browse/TUSCANY-1076 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Rick Rineholt Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: TUSCANY-1076.012807.patch CompositeContext.locateService requires an outbound wire to be created so for cases where bindings from the component/reference it locates are different from Java a databinding interceptor can be used to resolve difference in the expect data format. -- 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-966) getRequestContext() does not return a Context
[
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-966:
---
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
Affects Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
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-2.0-Alpha
Reporter: Lou Amodeo
Assigned To: Jim Marino
Fix For: Java-SCA-2.0-Alpha
Remote Service hangs obtaining the request context using getRequestContext().
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
CallBackApiServiceImpl message received: Knock Knock
CallBackApiServiceImpl getting request context
[INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There were test failures
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 37 seconds
[INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
[INFO] Final Memory: 7M/18M
[INFO]
---
Test set: org.apache.tuscany.sca.test.CallBackApiITest
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec
FAILURE!
testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest) Time
elapsed: 30.023 sec FAILURE!
junit.framework.ComparisonFailure: CallBackBasicITest expected:Who's There
but was:null
at junit.framework.Assert.assertEquals(Assert.java:81)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
at
org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
package org.apache.tuscany.sca.test;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import org.osoa.sca.RequestContext;
@Service(CallBackApiService.class)
public class CallBackApiServiceImpl implements CallBackApiService {
@Context
protected CompositeContext compositeContext;
protected CallBackApiCallBack callback;
public void knockKnock(String aString) {
System.out.println(CallBackApiServiceImpl message received: +
aString);
callback = this.getCallBackInterface();
callback.callBackMessage(Who's There);
System.out.println(CallBackApiServiceImpl response sent);
return;
}
private CallBackApiCallBack getCallBackInterface()
{
System.out.println(CallBackApiServiceImpl getting request context);
RequestContext rc = compositeContext.getRequestContext();
System.out.println(CallBackApiServiceImpl getting callback from
request context);
callback = (CallBackApiCallBack)
rc.getServiceReference().getCallback();
System.out.println(CallBackApiServiceImpl returning callback);
return callback;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-997) Incorrect text in NOTICE.txt files
[
https://issues.apache.org/jira/browse/TUSCANY-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-997.
--
Resolution: Fixed
Incorrect text in NOTICE.txt files
--
Key: TUSCANY-997
URL: https://issues.apache.org/jira/browse/TUSCANY-997
Project: Tuscany
Issue Type: Bug
Components: Build System
Affects Versions: Java-SCA-Mx
Environment: all
Reporter: Simon Nash
Priority: Minor
Fix For: Java-SCA-M3
The first line of the following files:
/incubator/tuscany/java/spec/sca/NOTICE.txt
/incubator/tuscany/java/spec/commonj/NOTICE.txt
is
${pom.name}
These NOTICE.txt files are included as is (i.e., without substitution of
this property name) in the javadoc distributions built from the spec/sca and
spec/commonj modules.
--
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-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
[ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1053: Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha Fix Version/s: (was: Java-SCA-M3) Wish list There hasn't yet been agreement on how best to achieve this. Pushing out for now until there is consensus on a solution. Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-Alpha Reporter: ant elder Assigned To: ant elder Fix For: Wish list Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] -- 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-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 updated TUSCANY-695:
---
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
Affects Version/s: (was: Java-M2)
Java-SCA-2.0-Alpha
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 Core
Affects Versions: Java-SCA-2.0-Alpha
Environment: r440401
Reporter: Scott Kurz
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 componentType
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
[jira] Updated: (TUSCANY-1022) Conversation id injection for conversational service provider -- annotation and field access
[ https://issues.apache.org/jira/browse/TUSCANY-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-1022: Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Conversation id injection for conversational service provider -- annotation and field access Key: TUSCANY-1022 URL: https://issues.apache.org/jira/browse/TUSCANY-1022 Project: Tuscany Issue Type: Bug Components: Specification Reporter: Ignacio Silva-Lepe Assigned To: Michael John Edwards Fix For: Java-SCA-2.0-Alpha Section 1.5.2.2 of the Client and Implementation for Java spec shows the use of a @SessionID annotation to inject a conversation id to a conversational service provider, the annotation should be @ConversationID In addition, section 1.5.2.2 of the spec illustrates the use of the injection annotation with a field that has private access. The annotation should be used on protected or public fields only. -- 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-678) Java XSD files cannot be used to validate SCA Model
[ https://issues.apache.org/jira/browse/TUSCANY-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-678: --- Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha There is a licensing question outstanding on the XSDs. Until that is resolved, we cannot ship them. Java XSD files cannot be used to validate SCA Model --- Key: TUSCANY-678 URL: https://issues.apache.org/jira/browse/TUSCANY-678 Project: Tuscany Issue Type: Task Components: Specification Affects Versions: Java-SCA-2.0-Alpha Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-2.0-Alpha The XSD schema files that are packaged in the tuscany java project are out of date with the current SCA model and cannot be used to validate any SCDL files. It appears that the C++ is the one being worked on, but the dates of edit do not correspond with one C++ being more uptodate than Java. The two sets of XSD files need to be synchronized so that both sets reflect the current SCA Model. -- 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-924) Many valued properties not supported
[ https://issues.apache.org/jira/browse/TUSCANY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-924: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Many valued properties not supported Key: TUSCANY-924 URL: https://issues.apache.org/jira/browse/TUSCANY-924 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Brent Daniel Assigned To: Venkatakrishnan Fix For: Java-SCA-2.0-Alpha The SCA runtime currently does not support property many=true/ -- 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-940) Test cases for scope, callback, oneway
[ https://issues.apache.org/jira/browse/TUSCANY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-940: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Test cases for scope, callback, oneway -- Key: TUSCANY-940 URL: https://issues.apache.org/jira/browse/TUSCANY-940 Project: Tuscany Issue Type: Test Components: Java Spec APIs Affects Versions: Java-SCA-Mx Reporter: Greg Dritschler Assigned To: Jim Marino Fix For: Java-SCA-2.0-Alpha Attachments: itest.zip Submission of basic integration tests for @Scope, @Callback, @Oneway, and @Remotable. -- 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-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 reassigned TUSCANY-746: -- Assignee: Jim Marino 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] Updated: (TUSCANY-289) Document how to extend Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-289: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha Document how to extend Tuscany -- Key: TUSCANY-289 URL: https://issues.apache.org/jira/browse/TUSCANY-289 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-SCA-2.0-Alpha Reporter: Jean-Sebastien Delfino Assigned To: Raymond Feng Fix For: Java-SCA-2.0-Alpha Attachments: ExtendingTuscany.odt, ExtendingTuscany.pdf, Tuscany-Ext.zip This is a key item for our release, discussed on our Wiki at http://wiki.apache.org/ws/Tuscany/Tasks. The outline of a document has been created by Jeremy at http://wiki.apache.org/ws/Tuscany/Extending. Jeremy and Jim have volunteered to do this work. -- 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-981) Capability to Remove / Undeploy Applications from Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-981: --- Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha We need to create a design which will handle multi-VM deployment. The old architecture of having composite hierarchies on a single machine has been replaced by a sparse tree model which impacts how this must be done. Capability to Remove / Undeploy Applications from Tuscany - Key: TUSCANY-981 URL: https://issues.apache.org/jira/browse/TUSCANY-981 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-2.0-Alpha Attachments: JIRA981Patches.zip There is no capability to remove an application once it has been deployed into the Tuscany runtime. -- 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-215) Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository
[ https://issues.apache.org/jira/browse/TUSCANY-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-215: --- Affects Version/s: (was: Java-M2) Wish list Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository --- Key: TUSCANY-215 URL: https://issues.apache.org/jira/browse/TUSCANY-215 Project: Tuscany Issue Type: Sub-task Components: Build System Affects Versions: Wish list Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-M3 We need to document the steps to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository. Dan suggested mvn source:jar javadoc:jar deploy. We need to add these steps to our Wiki or Web site. -- 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-925) Complex properties not supported
[ https://issues.apache.org/jira/browse/TUSCANY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-925: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: Java-SCA-2.0-Alpha Complex properties not supported Key: TUSCANY-925 URL: https://issues.apache.org/jira/browse/TUSCANY-925 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Brent Daniel Assigned To: Venkatakrishnan Fix For: Java-SCA-2.0-Alpha This may be intented to be covered in TUSCANY-773, but it was not clear to me. Complex properties are currently not supported by the tuscany runtime. Caused by: java.lang.IllegalArgumentException: Complex property is not supported. at org.apache.tuscany.core.property.SimplePropertyObjectFactory.getInstance(SimplePropertyObjectFactory.java:56) -- 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-871) Sharing of common utilitiy classes between extensions and extensions and application breaks if classloader isolation is followed.
[ https://issues.apache.org/jira/browse/TUSCANY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-871: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Sharing of common utilitiy classes between extensions and extensions and application breaks if classloader isolation is followed. -- Key: TUSCANY-871 URL: https://issues.apache.org/jira/browse/TUSCANY-871 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Rick Rineholt Assigned To: Raymond Feng Priority: Critical Fix For: Java-SCA-2.0-Alpha The current model tries to isolate each extension and the application to their own classloader. This works ok until there is a need to share objects between them. At this point these object's classs are each loaded by seperate classloaders. Classes loaded this way don't work well. For example, a class creating an instance by one classloader in an extension and then passed to an application that has the same class loaded by another class loader will see a classcast exception when an attempt is made to set a reference to the passed in object. Currently an example of this happens with databinding framework when using SDOs. The application creates SDOs loaded by its classloader. When the SDO object is sent on the wire the databinding framework intercepts to attempt to convert SDO to axiom for a webservice interface. But SDO classes in the SDO databinding framework are loaded via another classloader. -- 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-765) Interdependencies between extensions requires specific loading order.
[ https://issues.apache.org/jira/browse/TUSCANY-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-765: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-M2) Java-SCA-2.0-Alpha Interdependencies between extensions requires specific loading order. - Key: TUSCANY-765 URL: https://issues.apache.org/jira/browse/TUSCANY-765 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Rick Rineholt Assigned To: Raymond Feng Priority: Critical Fix For: Java-SCA-2.0-Alpha Working on Big Bank I just noticed an issue in the loading order and interdependencies between extensions. An example of the is the Axis2 binding which requires the WSDL extension to be loaded prior to it so that autowiring can resolve WSDLDefinitionRegistry. Just loading from a directory order won't guarantee this. If we plan on supporting just dropping in of extension jars to a directory will need a means to either prescan to resolve their dependencies or load all and then begin to autowire. This was also indirectly and briefly discussed on the mailing list http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] -- 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-982) WSDL Definitions need to be unregistered from Registry
[ https://issues.apache.org/jira/browse/TUSCANY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-982: --- Fix Version/s: (was: Java-SCA-M3) (was: Java-SCA-integration) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) (was: Java-SCA-integration) Java-SCA-2.0-Alpha WSDL Definitions need to be unregistered from Registry -- Key: TUSCANY-982 URL: https://issues.apache.org/jira/browse/TUSCANY-982 Project: Tuscany Issue Type: Sub-task Components: Java SCA Core Affects Versions: Java-SCA-2.0-Alpha Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-2.0-Alpha When removing an application, the WSDL definitions that were loaded need to be unregistered from WSDLDefinitionRegistry. -- 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-983) Schema Definitions need to be unregistered from Registry
[ https://issues.apache.org/jira/browse/TUSCANY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-983: --- Fix Version/s: (was: Java-SCA-M3) (was: Java-SCA-integration) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) (was: Java-SCA-integration) Java-SCA-2.0-Alpha Schema Definitions need to be unregistered from Registry Key: TUSCANY-983 URL: https://issues.apache.org/jira/browse/TUSCANY-983 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-SCA-2.0-Alpha Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-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] Closed: (TUSCANY-999) No release notes in Tuscany Java SCA binary distribution
[ https://issues.apache.org/jira/browse/TUSCANY-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-999. -- Resolution: Fixed No release notes in Tuscany Java SCA binary distribution Key: TUSCANY-999 URL: https://issues.apache.org/jira/browse/TUSCANY-999 Project: Tuscany Issue Type: Improvement Components: Java SCA Common Affects Versions: Java-M2, Java-SCA-M3 Environment: all Reporter: Simon Nash Priority: Minor Fix For: Java-SCA-M3 Robert Burrell Donkin made the following comment on the Tuscany Java SCA M2 release: i couldn't see any obvious release notes. release notes are important guerilla advertising for open source projects. the same content can be used on the download page, grassroots media (freshmeat.org, for example), in announcements and (of course) in plain text in the root directory of the release. This information does exist but appears to be misplaced. There is a readme.html file in the samples distribution with information on what is in this release and what has changed since the previous milestone release. For future releases, it would be good to include release notes in the binary distribution with this information. -- 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-914) duplicated component name in include overwrite the using one.
[ https://issues.apache.org/jira/browse/TUSCANY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino updated TUSCANY-914: --- Fix Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha Affects Version/s: (was: Java-SCA-M3) Java-SCA-2.0-Alpha duplicated component name in include overwrite the using one. - Key: TUSCANY-914 URL: https://issues.apache.org/jira/browse/TUSCANY-914 Project: Tuscany Issue Type: Improvement Components: Java Spec APIs Affects Versions: Java-SCA-2.0-Alpha Reporter: Yang Lei Assigned To: Jim Marino Fix For: Java-SCA-2.0-Alpha Attachments: tuscany-914-take3.lresende.20070121.txt, tuscany914-take5.lresende.20070121.txt, tuscany914.lresende.20070121.txt duplicated component name in include overwrite the using one. It may be better to throw duplication error. -- 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-177) Need a specification for autowire?
[ https://issues.apache.org/jira/browse/TUSCANY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino closed TUSCANY-177. -- Resolution: Fixed Need a specification for autowire? -- Key: TUSCANY-177 URL: https://issues.apache.org/jira/browse/TUSCANY-177 Project: Tuscany Issue Type: New Feature Components: Specification Affects Versions: Java-SCA-Mx Reporter: Jean-Sebastien Delfino Assigned To: Jeremy Boynes Fix For: Java-SCA-Mx Tuscany has introduced an Autowire capability. This needs to be contributed back to the SCA spec collaboration assembly workgroup. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL PROTECTED] and the associated discussion thread for the details. -- 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-1076) Dynamic outbound wire for CompositeContext.locateService
[ https://issues.apache.org/jira/browse/TUSCANY-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino reassigned TUSCANY-1076: --- Assignee: Jim Marino Dynamic outbound wire for CompositeContext.locateService Key: TUSCANY-1076 URL: https://issues.apache.org/jira/browse/TUSCANY-1076 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Rick Rineholt Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: TUSCANY-1076.012807.patch CompositeContext.locateService requires an outbound wire to be created so for cases where bindings from the component/reference it locates are different from Java a databinding interceptor can be used to resolve difference in the expect data format. -- 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-1076) Dynamic outbound wire for CompositeContext.locateService
[ https://issues.apache.org/jira/browse/TUSCANY-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468171 ] Jim Marino commented on TUSCANY-1076: - I'm in the process of re-working some of this in core and will roll this capability into those changes, so I'm assinging this to myself. In the future, things like the interface processor can be referenced using autowiring and don't need to have their impl classes instantiated directly. Dynamic outbound wire for CompositeContext.locateService Key: TUSCANY-1076 URL: https://issues.apache.org/jira/browse/TUSCANY-1076 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Rick Rineholt Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: TUSCANY-1076.012807.patch CompositeContext.locateService requires an outbound wire to be created so for cases where bindings from the component/reference it locates are different from Java a databinding interceptor can be used to resolve difference in the expect data format. -- 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-640) Service and Reference do not support multiple binding elements
[ https://issues.apache.org/jira/browse/TUSCANY-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466328 ] Jim Marino commented on TUSCANY-640: This should work. There are already unit tests which should confirm this (integration tests are fine as a secondary measure if you want to go ahead and create some as well). Service and Reference do not support multiple binding elements Key: TUSCANY-640 URL: https://issues.apache.org/jira/browse/TUSCANY-640 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Jeremy Boynes Assigned To: Luciano Resende Priority: Critical Fix For: Java-SCA-M3 According to the spec, Service and Reference definitions can have multiple bindings associated with them. Our config model and the associated loaders and builders only support a single binding -- 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-914) duplicated component name in include overwrite the using one.
[ https://issues.apache.org/jira/browse/TUSCANY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Marino reassigned TUSCANY-914: -- Assignee: Jim Marino (was: Luciano Resende) duplicated component name in include overwrite the using one. - Key: TUSCANY-914 URL: https://issues.apache.org/jira/browse/TUSCANY-914 Project: Tuscany Issue Type: Improvement Components: Java Spec APIs Affects Versions: Java-SCA-M3 Reporter: Yang Lei Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: tuscany914.lresende.20070121.txt duplicated component name in include overwrite the using one. It may be better to throw duplication error. -- 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-914) duplicated component name in include overwrite the using one.
[ https://issues.apache.org/jira/browse/TUSCANY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466348 ] Jim Marino commented on TUSCANY-914: Hi Luciano, Thanks for the patch. A couple of comments/suggested changes: 1. Can we change the algorithm to check against component names, service names, and reference names as well as fail fast? We should probably keep a list of all registered named elements and check as the each of the elements are processed. This way, an exception can be thrown pointing to the artifact the definition is in without continuing to process other artifacts. 2. Can you convert the LoaderException to a subclass such as DuplicateComponent, with the name of the component being passed in the ctor as the identifier instead of concatenating the message? This will make it consistent with how we are doing exception handling. 3. Can you include a unit test for ComponentLoader that verfies the exception will be thrown? 4.There are a few comments that should be stripped out including a println Thanks, Jim duplicated component name in include overwrite the using one. - Key: TUSCANY-914 URL: https://issues.apache.org/jira/browse/TUSCANY-914 Project: Tuscany Issue Type: Improvement Components: Java Spec APIs Affects Versions: Java-SCA-M3 Reporter: Yang Lei Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: tuscany914.lresende.20070121.txt duplicated component name in include overwrite the using one. It may be better to throw duplication error. -- 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-914) duplicated component name in include overwrite the using one.
[ https://issues.apache.org/jira/browse/TUSCANY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466401 ] Jim Marino commented on TUSCANY-914: I don't think the algorithm is quite right - component names must be unique from service and reference names. On the unit tests, they should not need to reference any SCDL or external resources or need to instantiate other kernel classes. Instead, they should use EasyMock to pass in a mock XmlStreamReader to the loader which will replay parsing the SCDL. Take a look at some of the other loader unit tests for exampes. duplicated component name in include overwrite the using one. - Key: TUSCANY-914 URL: https://issues.apache.org/jira/browse/TUSCANY-914 Project: Tuscany Issue Type: Improvement Components: Java Spec APIs Affects Versions: Java-SCA-M3 Reporter: Yang Lei Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: tuscany-914-take3.lresende.20070121.txt, tuscany914.lresende.20070121.txt duplicated component name in include overwrite the using one. It may be better to throw duplication error. -- 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-914) duplicated component name in include overwrite the using one.
[ https://issues.apache.org/jira/browse/TUSCANY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466405 ] Jim Marino commented on TUSCANY-914: Sorry, two more things I forgot: - The spec doesn't explicitly say service names and reference names need to be unique w.r.t each other. We need to clarify this in the spec, since they will need to be unique if both can be targets of locateService. - The ctor for DuplicatedComponentException should included a message and an identifier which are passed to the LoaderException superclass. The identifier will be set with the duplicate name when the exception is created instead of putting the name in the message. duplicated component name in include overwrite the using one. - Key: TUSCANY-914 URL: https://issues.apache.org/jira/browse/TUSCANY-914 Project: Tuscany Issue Type: Improvement Components: Java Spec APIs Affects Versions: Java-SCA-M3 Reporter: Yang Lei Assigned To: Jim Marino Fix For: Java-SCA-M3 Attachments: tuscany-914-take3.lresende.20070121.txt, tuscany914.lresende.20070121.txt duplicated component name in include overwrite the using one. It may be better to throw duplication error. -- 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-1001) @SessionID injection is not working..
[ https://issues.apache.org/jira/browse/TUSCANY-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464381 ] Jim Marino commented on TUSCANY-1001: - A quick comment that the spec is being changed to have scopes specified only on the implementation. Services on the other hand can either be non-conversational (default) or conversational. @SessionID injection is not working.. -- Key: TUSCANY-1001 URL: https://issues.apache.org/jira/browse/TUSCANY-1001 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Java SCA Integration Tests Reporter: Lou Amodeo Assigned To: Ignacio Silva-Lepe Fix For: Java-Mx When using the @SessionID annotation and instance variable protected String sessionID the session is not being injected and sessionID 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-1020) java.lang.NoSuchMethodError while building SCA
[ http://issues.apache.org/jira/browse/TUSCANY-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461772 ] Jim Marino commented on TUSCANY-1020: - This looks like your local workspace may be out of sync. Can you make sure you have cleaned all of the target directories and retry? Jim java.lang.NoSuchMethodError while building SCA -- Key: TUSCANY-1020 URL: http://issues.apache.org/jira/browse/TUSCANY-1020 Project: Tuscany Issue Type: Bug Components: Build System, Java SCA Core Affects Versions: Java-M3 Reporter: Luciano Resende [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: X:\java\sca\kernel\spi\target\surefire-reports ... Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.07 sec FAILURE! testCreateInstance(org.apache.tuscany.spi.wire.WireObjectFactoryTestCase) Time elapsed: 0.06 sec ERROR! java.lang.NoSuchMethodError: org.apache.tuscany.spi.wire.WireService.createProxy(Lorg/apache/tuscany/spi/wire/RuntimeWire;)Ljava/lang/Object; at org.apache.tuscany.spi.wire.WireObjectFactoryTestCase.testCreateInstance(WireObjectFactoryTestCase.java:35) Running org.apache.tuscany.spi.databinding.extension.XSDDataTypeConverterTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Results : Tests run: 82, Failures: 0, Errors: 1, Skipped: 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-1005) Build failure in loanappconversationWSClient\src\test\java\loanappconversation\LoanAppConversationTestCase.java
[ http://issues.apache.org/jira/browse/TUSCANY-1005?page=comments#action_12459688 ] Jim Marino commented on TUSCANY-1005: - We should change this to not rely on SPI classes since it is a sample. Per the spec, the behavior here should be ServiceUnavailableException. There are places in the invocation chain where we are not still properly wrapping internal exceptions in ServiceRuntimeException so I'll go in and fix that as part of the wiring/proxy refactors underway. Build failure in loanappconversationWSClient\src\test\java\loanappconversation\LoanAppConversationTestCase.java --- Key: TUSCANY-1005 URL: http://issues.apache.org/jira/browse/TUSCANY-1005 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-Mx Reporter: Luciano Resende Fix For: Java-Mx 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. - If you think it was sent incorrectly contact one of the administrators: http://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-1000) Components do not support multiple services
[ http://issues.apache.org/jira/browse/TUSCANY-1000?page=all ]
Jim Marino reassigned TUSCANY-1000:
---
Assignee: Jim Marino
Components do not support multiple services
---
Key: TUSCANY-1000
URL: http://issues.apache.org/jira/browse/TUSCANY-1000
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-M2
Reporter: Lou Amodeo
Assigned To: Jim Marino
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 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)
--
This message is automatically
[jira] Closed: (TUSCANY-996) Build break with Persistence test case
[ http://issues.apache.org/jira/browse/TUSCANY-996?page=all ] Jim Marino closed TUSCANY-996. -- Resolution: Fixed Meeraj fixed this Build break with Persistence test case -- Key: TUSCANY-996 URL: http://issues.apache.org/jira/browse/TUSCANY-996 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Luciano Resende Fix For: Java-Mx Running org.apache.tuscany.service.persistence.common.PersistenceUnitTestCase log4j:WARN No appenders could be found for logger (org.apache.tuscany.transaction.geronimo.jta.HOWLLog). log4j:WARN Please initialize the log4j system properly. Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.122 sec FAILURE! testGetComponent(org.apache.tuscany.service.persistence.common.PersistenceUnitTestCase) Time elapsed: 7.042 sec ERROR! 4|false|0.9.0-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.tuscany.service.persistence.common.Employe [EMAIL PROTECTED] to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: [EMAIL PROTECTED] at org.apache.openjpa.kernel.BrokerImpl.assertPersistenceCapable(BrokerImpl.java:4130) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2258) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2205) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:959) at org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:469) at org.apache.tuscany.service.persistence.common.TestService1.testMethod(TestService1.java:24) at org.apache.tuscany.service.persistence.common.PersistenceUnitTestCase.setUp(PersistenceUnitTestCase.java:23) 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(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) 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.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) Running org.apache.tuscany.service.persistence.common.DefaultPersistenceUnitBuilderTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.15 sec Running org.apache.tuscany.service.persistence.common.PersistenceUnitScannerTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Results : Tests run: 3, Failures: 0, Errors: 1, Skipped: 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-862) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-862?page=all ] Jim Marino reassigned TUSCANY-862: -- Assignee: Jim Marino (was: Jeremy Boynes) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl - Key: TUSCANY-862 URL: http://issues.apache.org/jira/browse/TUSCANY-862 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: Jim Marino Fix For: Java-Mx If you do CurrentCompositeContext.locateService on a reference which uses interface.wsdl you get a NPE: java.lang.NullPointerException at org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) at org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) at org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:275) at org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) at helloworld.HelloWorldWSClient.setUp(HelloWorldWSClient.java:46) Thats becuase the wire.getServiceContract().getInterfaceClass() returns null. To demonstrate change the helloworldwsclient to use the reference 'HelloWorldService' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-973) HttpSessionScopeContainer should use the HttpSession for session persistance
[ http://issues.apache.org/jira/browse/TUSCANY-973?page=comments#action_12456118 ] Jim Marino commented on TUSCANY-973: This needs to implement semantics similar to conversational persistence and not just use the ServletContext as a container for replication to work properly. At a certain point, the servlet engine needs to be notified of a series of changes through setAttribute. This is the same pattern we have with conversational scope. We should also have a mechanism based on intents that specify whether a particular instance should failover, otherwise, we don't need to store it in the Servlet context. HttpSessionScopeContainer should use the HttpSession for session persistance Key: TUSCANY-973 URL: http://issues.apache.org/jira/browse/TUSCANY-973 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: ant elder Fix For: Java-Mx The HttpSessionScopeContainer should use the HttpSession for session persistance instead of the HashMap it currently uses -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-947) JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially
[ http://issues.apache.org/jira/browse/TUSCANY-947?page=comments#action_12452034 ] Jim Marino commented on TUSCANY-947: This would be a straightforward fix for someone interested in working on a patch :-). This is already implemented in JDKInboundInvocationHandler so code could be taken from there. Also, there are unit tests which verify toString() and hashCode() in JDKInboundInvocationHandlerTestCase. JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially - Key: TUSCANY-947 URL: http://issues.apache.org/jira/browse/TUSCANY-947 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Since JDKCallbackInvocationHandler doesn't handle toString() specially, if the dynamic $Proxy toString() gets called before the invoke of a service operation it will mess up the correlationId, etc.. by nulling them out.. The other InvocationHandler classes in Tuscany do special-case these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-947) JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially
[ http://issues.apache.org/jira/browse/TUSCANY-947?page=comments#action_12452075 ] Jim Marino commented on TUSCANY-947: Thanks Scott. Could you also copy over the unit tests as well ;-) It's nice to have unit tests with a patch so committers can more easilyverify it. It's also useful for avoiding future regressions. If you can do that, I'll apply it. Thanks, Jim JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially - Key: TUSCANY-947 URL: http://issues.apache.org/jira/browse/TUSCANY-947 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Attachments: 947.patch Since JDKCallbackInvocationHandler doesn't handle toString() specially, if the dynamic $Proxy toString() gets called before the invoke of a service operation it will mess up the correlationId, etc.. by nulling them out.. The other InvocationHandler classes in Tuscany do special-case these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-947) JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially
[ http://issues.apache.org/jira/browse/TUSCANY-947?page=all ] Jim Marino closed TUSCANY-947. -- Resolution: Fixed Thanks Scott, I applied the patch. BTW I just started using EasyMock recently after using other mock object framrworks and I think it is really awesome. It saves a lot of time handling stubs but it also allows you to verify thinks much more succinctly. Anyway, thanks for the patch. JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially - Key: TUSCANY-947 URL: http://issues.apache.org/jira/browse/TUSCANY-947 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Attachments: 947.patch, 947.patch Since JDKCallbackInvocationHandler doesn't handle toString() specially, if the dynamic $Proxy toString() gets called before the invoke of a service operation it will mess up the correlationId, etc.. by nulling them out.. The other InvocationHandler classes in Tuscany do special-case these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-940) Test cases for scope, callback, oneway
[ http://issues.apache.org/jira/browse/TUSCANY-940?page=all ] Jim Marino reassigned TUSCANY-940: -- Assignee: Jim Marino Test cases for scope, callback, oneway -- Key: TUSCANY-940 URL: http://issues.apache.org/jira/browse/TUSCANY-940 Project: Tuscany Issue Type: Test Components: Java Spec APIs Affects Versions: Java-Mx Reporter: Greg Dritschler Assigned To: Jim Marino Attachments: itest.zip Submission of basic integration tests for @Scope, @Callback, @Oneway, and @Remotable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-910) CurrentCompositeContext.getContext() returns CompositeContext with null attributes
[ http://issues.apache.org/jira/browse/TUSCANY-910?page=all ] Jim Marino updated TUSCANY-910: --- Component/s: Java SCA Core (was: Java Spec APIs) CurrentCompositeContext.getContext() returns CompositeContext with null attributes -- Key: TUSCANY-910 URL: http://issues.apache.org/jira/browse/TUSCANY-910 Project: Tuscany Issue Type: Bug Components: Java SCA Core Environment: Windows XP Reporter: Yang Lei I noticed, that if I call CurrentCompositeContext.getContext(); to get CompositeContext, then the values of most of the api return null: composite name:null composite URI:null Request context:null I defined attributes in the java class(service impl class) with annotation @Context and @ComponentName . They also return null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-913) no validation on @Reference(required=true)
[ http://issues.apache.org/jira/browse/TUSCANY-913?page=all ] Jim Marino updated TUSCANY-913: --- Component/s: Java SCA POJO Container (was: Java Spec APIs) I'm not sure what this is saying. I think it is that an reference can be injected on an unnanotated (or undecorated in the case of a component type) member. If that is accurate, then this is appropriate behavior and should be closed. Otherwise, please let me know. no validation on @Reference(required=true) -- Key: TUSCANY-913 URL: http://issues.apache.org/jira/browse/TUSCANY-913 Project: Tuscany Issue Type: Improvement Components: Java SCA POJO Container Affects Versions: Java-M2 Environment: windows xp Reporter: Yang Lei @Reference(required=true) or by default @Reference I can define a component without giving reference. The code still works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-936) HttpSessionScopeContainer requires a session to exist
[ http://issues.apache.org/jira/browse/TUSCANY-936?page=comments#action_12450646 ] Jim Marino commented on TUSCANY-936: It looks like the session scope container has not been completely integrated into the web app runtime and LazyHTTPSessionId was left out. To fix this: 1. Copy over LazyHTTPSessionId from the old code base 2. In TuscanyRequestListener, line 61: runtime.httpRequestStarted(session == null ? null : session.getId()); Instead of passing in a null id, pass in an insance of LazyHTTPSessionId. 3. HttpSessionScopeContainer.getInstanceWrapper() needs to check the id if it is an instanceof LazyHTTPSessionId and call getId() on it, and doing a lookup on the value returned. Note calling Servlet.getSession(true) will cause sessions to be created even if they are not accessed which may be a performance issue so it is probably best that this fix is done. HttpSessionScopeContainer requires a session to exist - Key: TUSCANY-936 URL: http://issues.apache.org/jira/browse/TUSCANY-936 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Priority: Minor In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP session. (Look at the class LazyHTTPSessionId to see how it worked.) Now the HttpSessionScopeContainer requires a preexisting session. If a session does not exist, a NullPointerException occurs when it tries to look up the instance using a null key. InstanceWrapper ctx = wrappers.get(key); The problem can be circumvented by creating a session in the web app client. JSPs have sessions by default. Servlets can call getSession(true) to ensure a session exists before invoking an SCA component that requires session scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-927) SCA Policy framework support in Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-927?page=all ] Jim Marino reassigned TUSCANY-927: -- Assignee: Jim Marino SCA Policy framework support in Tuscany --- Key: TUSCANY-927 URL: http://issues.apache.org/jira/browse/TUSCANY-927 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Wish list Environment: all Reporter: Felix Ren Assigned To: Jim Marino Attachments: java.sca.kernel.core.src.test.resources.org.apache.tuscany.core.zip, policyinit.patch Intents and PolicySets support -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-923) @Scope(REQUEST) causes ScopeNotFoundException
[ http://issues.apache.org/jira/browse/TUSCANY-923?page=all ] Jim Marino reassigned TUSCANY-923: -- Assignee: Jim Marino @Scope(REQUEST) causes ScopeNotFoundException --- Key: TUSCANY-923 URL: http://issues.apache.org/jira/browse/TUSCANY-923 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Assigned To: Jim Marino Using @Scope(REQUEST) in an implementation class causes the following error at build time. [INFO] [INFO] Scope object factory not registered for scope [REQUEST] [INFO] [INFO] Trace org.apache.tuscany.spi.component.ScopeNotFoundException: Scope object factory not registered for scope [REQUEST] at org.apache.tuscany.core.component.scope.ScopeRegistryImpl.getScopeContainer(ScopeRegistryImpl.java:65) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:75) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:52) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115) at org.apache.tuscany.core.implementation.composite.CompositeBuilder.build(CompositeBuilder.java:93) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115) at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java:115) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:81) RequestScopeObjectFactory is not registering with the ScopeRegistry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-923) @Scope(REQUEST) causes ScopeNotFoundException
[ http://issues.apache.org/jira/browse/TUSCANY-923?page=all ] Jim Marino closed TUSCANY-923. -- Resolution: Fixed @Scope(REQUEST) causes ScopeNotFoundException --- Key: TUSCANY-923 URL: http://issues.apache.org/jira/browse/TUSCANY-923 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Assigned To: Jim Marino Using @Scope(REQUEST) in an implementation class causes the following error at build time. [INFO] [INFO] Scope object factory not registered for scope [REQUEST] [INFO] [INFO] Trace org.apache.tuscany.spi.component.ScopeNotFoundException: Scope object factory not registered for scope [REQUEST] at org.apache.tuscany.core.component.scope.ScopeRegistryImpl.getScopeContainer(ScopeRegistryImpl.java:65) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:75) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:52) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115) at org.apache.tuscany.core.implementation.composite.CompositeBuilder.build(CompositeBuilder.java:93) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115) at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java:115) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:81) RequestScopeObjectFactory is not registering with the ScopeRegistry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-922) Target instance is not cached in reference proxy
[ http://issues.apache.org/jira/browse/TUSCANY-922?page=comments#action_12449204 ] Jim Marino commented on TUSCANY-922: Individual target invokers will support caching (e.g. JavaTargetInvoker) but the optimization hasn't been turned on yet. Caching could be done in the following situation: 1. The scope of the target is a longer duration than the client, e.g. request---http session, http session---module 2. There are no interceptors on the chain The check should probably be done after all of the post processors have been run in ConnectorImpl If anyone is interested in taking a look, I'd be happy to provide additional help. Target instance is not cached in reference proxy Key: TUSCANY-922 URL: http://issues.apache.org/jira/browse/TUSCANY-922 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: http://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-921) wire element in SCDL causes UnrecognizedElementException
[
http://issues.apache.org/jira/browse/TUSCANY-921?page=comments#action_12449207
]
Jim Marino commented on TUSCANY-921:
To fix this, a StAXElementLoader needs to be implemented that supports wires.
Modifications to the model also need to be made to suppport adding
WireDefinitions.
If someone is interested in looking at this, I'd be happy to help answer
questions.
wire element in SCDL causes UnrecognizedElementException
--
Key: TUSCANY-921
URL: http://issues.apache.org/jira/browse/TUSCANY-921
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Using a wire element in a composite results in an exception.
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org/xmlns/sca/1.0}wire
[{http://www.osoa.org/xmlns/sca/1.0}wire]
Context stack trace: [application]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55)
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:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://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-896) java.lang.IndexOutOfBoundsException trying when there is no default service for the composite
[ http://issues.apache.org/jira/browse/TUSCANY-896?page=all ] Jim Marino reassigned TUSCANY-896: -- Assignee: Jim Marino java.lang.IndexOutOfBoundsException trying when there is no default service for the composite - Key: TUSCANY-896 URL: http://issues.apache.org/jira/browse/TUSCANY-896 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Environment: Win32 Reporter: Luciano Resende Assigned To: Jim Marino Fix For: Java-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. - If you think it was sent incorrectly contact one of the administrators: http://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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=all ] Jim Marino resolved TUSCANY-833. Fix Version/s: Java-Mx Resolution: Fixed Fixed in trunk (not M2) ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical Fix For: Java-Mx If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=all ] Jim Marino reassigned TUSCANY-833: -- Assignee: Jim Marino ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441825 ] Jim Marino commented on TUSCANY-833: Proliferating an encapsulation approach to extensions is the wrong way to fix this as it will just add to the problems. Moreover, it will not solve the issue for Java Pojos. Either we should treat this as a blocker for M2 and fix it or release note that it does not work. I outlined in an email to the list yesterday how to fix this. For the specific script issues, a better workaround involves moving lifecycle scope to the base component type (which would involve moving it from PojoComponentType) as I also outlined. There are, however, other issues which still need to be addressed regarding script extensions as I mentioned in the same mail, which I'm happy to help with. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441862 ] Jim Marino commented on TUSCANY-833: Looking into this more, my preference would be not to fix this or do a hack for M2 since for POJOs, component type side files aren't really useful do to some spec issues. Even if we were to fix the problems outlined, the only things that can be specified in a side file are services, references and proprties. The spec has not yet defined how to represent specific Java concepts such as init/destroy and implementation scopes in the component type schema. This renders side files not very useful. The only type of POJO implementation that could be specified with a side file is statelesss with no intitialization or destruction callbacks. In addition, we already support the algorithm for determining services, references and properties on an unannotated POJO, relegating the need to actuallly have to specify a side file to mostly corner cases involving legacy code. Given the need to stabilize a brach, I think we should release note that we do not support component type side files for POJOs with M2. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441870 ] Jim Marino commented on TUSCANY-833: Responding to Jeremy specifically, I would prefer to do the right way after M2 given side files for POJOs don't really do very much. As for copying the component type in the Java implementation loader, I really don't want to do this since IMO introducing workarounds should only be done in extreme circumstances. For extension types, they definitely shouldn't do this. So, my preference would be option 4: release note it. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-762) Shutdown hang
[ http://issues.apache.org/jira/browse/TUSCANY-762?page=all ] Jim Marino resolved TUSCANY-762. Resolution: Fixed Fixed in 453756 Shutdown hang - Key: TUSCANY-762 URL: http://issues.apache.org/jira/browse/TUSCANY-762 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Jeremy Boynes Assigned To: Jim Marino Priority: Critical Fix For: Java-M2 When shutting down the runtime, stopping parent components can hang if the child has already been stopped because checkInit waits for the child to be started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-767) NPE in CompositeReference.java when service is defined using interface wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-767?page=comments#action_12439768 ] Jim Marino commented on TUSCANY-767: I've applied the patch for kernel with some additional test cases. I think there are execution paths that are not covered so we should probably add more test cases for this. I did not check in the changes to the sample as I am getting the following error: org.apache.tuscany.spi.wire.InvocationRuntimeException: java.lang.NullPointerException at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:76) at org.apache.tuscany.core.wire.AbstractOutboundInvocationHandler.invoke(AbstractOutboundInvocationHandler.java:65) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:121) at $Proxy17.clientMethod(Unknown Source) at innercomposite.InnerCompositeTestCase.test(InnerCompositeTestCase.java:39) Caused by: java.lang.NullPointerException at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:71) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:71) at org.apache.tuscany.core.wire.AbstractOutboundInvocationHandler.invoke(AbstractOutboundInvocationHandler.java:65) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:121) NPE in CompositeReference.java when service is defined using interface wsdl --- Key: TUSCANY-767 URL: http://issues.apache.org/jira/browse/TUSCANY-767 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jim Marino Priority: Blocker Fix For: Java-M2 Attachments: OperationInvocationHandlers.patch, OperationInvocationHandlersWithTestCase.patch If a service is defined using interface wsdl the service contract does not have an interface class this results in org.apache.tuscany.core.implementation.composite.CompositeReference getting an NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-767) NPE in CompositeReference.java when service is defined using interface wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-767?page=all ] Jim Marino reassigned TUSCANY-767: -- Assignee: Jim Marino (was: Ignacio Silva-Lepe) NPE in CompositeReference.java when service is defined using interface wsdl --- Key: TUSCANY-767 URL: http://issues.apache.org/jira/browse/TUSCANY-767 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jim Marino Priority: Blocker Fix For: Java-M2 Attachments: OperationInvocationHandlers.patch If a service is defined using interface wsdl the service contract does not have an interface class this results in org.apache.tuscany.core.implementation.composite.CompositeReference getting an NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-767) NPE in CompositeReference.java when service is defined using interface wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-767?page=comments#action_12439312 ] Jim Marino commented on TUSCANY-767: Ignacio was going to add some testcases to verify behavior and I'll apply. NPE in CompositeReference.java when service is defined using interface wsdl --- Key: TUSCANY-767 URL: http://issues.apache.org/jira/browse/TUSCANY-767 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jim Marino Priority: Blocker Fix For: Java-M2 Attachments: OperationInvocationHandlers.patch If a service is defined using interface wsdl the service contract does not have an interface class this results in org.apache.tuscany.core.implementation.composite.CompositeReference getting an NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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]
