[jira] [Commented] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema
[ https://issues.apache.org/jira/browse/TUSCANY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236509#comment-13236509 ] Simon Laws commented on TUSCANY-4035: - Hi Kaushik Can you check the flag that says you're happy that this is a patch that Apache can use? > Application could possibly fail to start if multiple threads are loading the > same schema > > > Key: TUSCANY-4035 > URL: https://issues.apache.org/jira/browse/TUSCANY-4035 > Project: Tuscany > Issue Type: Bug >Reporter: Kaushik Mukherjee > Attachments: TUSCANY-4035.patch > > > This was an issue in Tuscany 1.x and is likely an issue in the 2.x code as > well. The fix in 1.x was to synchronize schema loading across all > XSDModelResolvers. > Starting multiple applications simultaneously can lead to an > exception such as: > org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in > collection. Namespace: http://my.namespace > at > org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:223) > > at > org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:202) > at > org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424) > at > org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347) > at > org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379) > at > org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:204) > at > org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:240) > at > org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:114) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding
[ https://issues.apache.org/jira/browse/TUSCANY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236484#comment-13236484 ] Simon Laws commented on TUSCANY-4031: - Hi Greg Are you happy to have this patch applied? If so can you check the box in the JIRA to confirm that. Thanks. > IntentNotSatisfiedAtBuild warning occurs when reference uses an intent > provided by binding > -- > > Key: TUSCANY-4031 > URL: https://issues.apache.org/jira/browse/TUSCANY-4031 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-SCA-2.0 >Reporter: Greg Dritschler >Priority: Minor > Attachments: TUSCANY-4031.patch > > > ComponentPolicyBuilderImpl.checkIntentsResolved() checks when intents used by > an Endpoint are provided by the binding. It should do the same for intents > used by an EndpointReference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4026) XSDModelResolver fails to initiate WSDL model resolution for inline schemas
[ https://issues.apache.org/jira/browse/TUSCANY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227198#comment-13227198 ] Simon Laws commented on TUSCANY-4026: - Hi Kaushik I tried to apply the patch but there seems to be some changes missing. The patch applies a dependency from xsd to interface-wsdl. However there is already a dependency in the opposite direction. How did you get round this in your build? > XSDModelResolver fails to initiate WSDL model resolution for inline schemas > --- > > Key: TUSCANY-4026 > URL: https://issues.apache.org/jira/browse/TUSCANY-4026 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Databinding-SDO >Affects Versions: Java-SCA-2.x >Reporter: Kaushik Mukherjee > Attachments: JIRA-4206.patch > > > XSDModelResolver fails to initiate WSDLModelResolver for inline schemas > during start so there is no inline schema document object model added to the > contribution. When we try to resolve the namespace and type associated with > the inline schema we fail to find the document since it was never built. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217216#comment-13217216 ] Simon Laws commented on TUSCANY-4017: - Another thought. We collate the policy information from the composite, component, reference/service, binding hierarchy onto Endpoints and EncpointReferences. I don't believe we push that back to bindings. So if you look at the binding I can well believe you still see "exactlyOnce". If you look at the Endpoint or EndpointReference you should see "atleastOnce"/"atMostOnce". > Tuscany needs to process profile intents as in OSOA > --- > > Key: TUSCANY-4017 > URL: https://issues.apache.org/jira/browse/TUSCANY-4017 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Policy >Affects Versions: Java-SCA-2.0-Beta3 >Reporter: Rashmi Hunt >Assignee: Simon Laws > Fix For: Java-SCA-2.x > > > In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when > I tried to get intent name > from PolicySubject. > In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany > used to return it as > 'atleastOnce'/'atMostOnce' as intent name ( > PolicyComputationUtils.expandProfileIntents()) , which > seems to be missing in OASIS implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211771#comment-13211771 ] Simon Laws commented on TUSCANY-4017: - At revision: 1291186 I added a test case which looks at how the exactlyOnce profile intent resolves to atLeastOnce and atMostOnce in the endpoint. I need a bit more information about where in the code you were looking for the resolved intents. > Tuscany needs to process profile intents as in OSOA > --- > > Key: TUSCANY-4017 > URL: https://issues.apache.org/jira/browse/TUSCANY-4017 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Policy >Affects Versions: Java-SCA-2.0-Beta3 >Reporter: Rashmi Hunt >Assignee: Simon Laws > Fix For: Java-SCA-2.x > > > In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when > I tried to get intent name > from PolicySubject. > In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany > used to return it as > 'atleastOnce'/'atMostOnce' as intent name ( > PolicyComputationUtils.expandProfileIntents()) , which > seems to be missing in OASIS implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it
[ https://issues.apache.org/jira/browse/TUSCANY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206168#comment-13206168 ] Simon Laws commented on TUSCANY-4013: - I've just noticed that the binding model is all over the pace in terms of what extended what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. I wanted this fix for binding.ws so I'll fix that first and raise a separate JIRA to tidy up the binding models. > Can't tell what binding URI the user provided in the SCDL after the builder > has run as the BindingURIBuilder overwrites it > -- > > Key: TUSCANY-4013 > URL: https://issues.apache.org/jira/browse/TUSCANY-4013 > Project: Tuscany > Issue Type: Bug > Components: SCA Java Runtime >Affects Versions: Java-SCA-2.0-Beta3 > Environment: All >Reporter: Simon Laws >Priority: Minor > Fix For: Java-SCA-2.0 > > > The BindingURIBuilder overwrites any URI provided by the user so I propose to > add a new field to binding (userSpecifiedURI) to hold what the user > originally typed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204341#comment-13204341 ] Simon Laws commented on TUSCANY-3924: - I'm seeing the same Raymond. I don't think my approach is good so am about to revert some of it. I had a chat offline with Mike Edwards and I think we need to rethink the interpretation of the spec (which is not clear in this area) as I'm feeling uncomfortable about the code ignoring base class information. > Inherited fields in service impl classes are treated as Properties > -- > > Key: TUSCANY-3924 > URL: https://issues.apache.org/jira/browse/TUSCANY-3924 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Assembly Model >Affects Versions: Java-SCA-2.x >Reporter: Vijai Kalathur >Assignee: Simon Laws > Fix For: Java-SCA-2.x > > > In the scenario where the Service impl class extends a class which has no SCA > annotations in it, protected fields in the base class are interpreted like > Properties. > Ideally, only the fields in the impl class should be introspected for > References/Properties. The fields in the base class should not be > interpreted as References/Properties if there are no SCA annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181260#comment-13181260 ] Simon Laws commented on TUSCANY-3932: - Following on from my first comment I've made some initial changes at revision: 1228150 to make the handling of callbacks more consistent in the code as it stands at the moment. These are. Make the sca binding retain it's original URI rather than overwriting with the delegate URI (I've added some more fields to hold the delegate info) Have the delegate WS binding detect when it is delegating and pass the sca binding URI for callbacks in this case. In this was the callback code at the service can use the usual SCA endpoint lookup process to satisfy the callback reference. Make the JMS binding use the From EPR->CallbackEP model to transfer the callback binding infro into the infrastructure. This simplifies the CallbackServiceReference somewhat. > Callbacks don't work in the distributed domain > -- > > Key: TUSCANY-3932 > URL: https://issues.apache.org/jira/browse/TUSCANY-3932 > Project: Tuscany > Issue Type: Bug > Components: SCA Java Runtime >Affects Versions: Java-SCA-2.0-Beta3 > Environment: All >Reporter: Simon Laws >Assignee: Simon Laws > Fix For: Java-SCA-2.0 > > > The callback wire calculation currently requires knowledge of the service > runtime. This will not be available in the distributed case where the > Endpoint matched by and retrieved from the registry will not have a built > runtime behind it. We need to refactor this based on the configuration > available in the SCDL written to represent a remote Endpoint. > Of particular interest is callback bindings that are generated vs callback > bindings that are specified by the user. If a user specifies a binding this > should automatically be available in the reference node as it will be written > be default when the Endpoint is written out. Automatically generated callback > bindings, usually generated to match the forward binding, won't be in that > list and won't get written out so we need to address that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding
[ https://issues.apache.org/jira/browse/TUSCANY-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181245#comment-13181245 ] Simon Laws commented on TUSCANY-3910: - In the code currently these two visitors are configured as follows: org.apache.tuscany.sca.core.databinding.processor.WrapperJavaInterfaceProcessor;ranking=200 org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor;ranking=100 They are used in descending order so the WrapperJavaInterfaceProcessor will always run before JAXWSJavaInterfaceProcessor. My first suggestion would be to swap this order and see if this improves things. > Ensure that JAX-WS wrapper generation occurs before databinding introspection > to avoid need for @RequestWrapper, etc. to set databinding > > > Key: TUSCANY-3910 > URL: https://issues.apache.org/jira/browse/TUSCANY-3910 > Project: Tuscany > Issue Type: Improvement > Components: SCA Java Runtime >Affects Versions: Java-SCA-2.0 >Reporter: Scott Kurz >Assignee: Scott Kurz > > Say I have a wrapped-style WSDL interface which I want to map to Java intf: > Node greetDOM(Node name); > Our databinding introspection will correctly mark the input/output with > DOMDataBinding. The JAXWSJavaInterfaceProcessor will generate the wrappers > since they are not already present from the Java perspective. > Then there is some more function in WrapperJavaInterfaceProcessor to > "promote" the parm/returnVal databindings to the wrapper-level databindings. >However, while in 1.x this always ran after the wrappers were generated, > in 2.x the order isn't so determined because of the way we factored out the > addition of the interface processors. > So the user has to ensure the JAX-WS annotations are present and that they > specify the databinding (via the className), which is a pain to add manually > if he doesn't have a tool to do it, e.g.: > @RequestWrapper(localName = "greetDOM", targetNamespace = > "http://intf.privatecopy.itest/";, className = "org.w3c.dom.Node") > @ResponseWrapper(localName = "greetDOMResponse", targetNamespace = > "http://intf.privatecopy.itest/";, className = "org.w3c.dom.Node") > Node greetDOM(Node name); > We seem to need an ordering so that the WrapperJavaInterfaceProcessor runs > after JAXWSJavaInterfaceProcessor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179567#comment-13179567 ] Simon Laws commented on TUSCANY-3932: - I've been looking at this an I also note that there is code in the CallbackServiceReference that resets the binding on the original callback endpoint reference rather than the cloned version which doesn't sound right. Also after the clone the binding provider isn't reset so in effect the binding provider, and associated wires, are shared between all callback references for a particular component. I suspect that this will cause problems for concurrent requests to the component. > Callbacks don't work in the distributed domain > -- > > Key: TUSCANY-3932 > URL: https://issues.apache.org/jira/browse/TUSCANY-3932 > Project: Tuscany > Issue Type: Bug > Components: SCA Java Runtime >Affects Versions: Java-SCA-2.0-Beta3 > Environment: All >Reporter: Simon Laws >Assignee: Simon Laws > Fix For: Java-SCA-2.0 > > > The callback wire calculation currently requires knowledge of the service > runtime. This will not be available in the distributed case where the > Endpoint matched by and retrieved from the registry will not have a built > runtime behind it. We need to refactor this based on the configuration > available in the SCDL written to represent a remote Endpoint. > Of particular interest is callback bindings that are generated vs callback > bindings that are specified by the user. If a user specifies a binding this > should automatically be available in the reference node as it will be written > be default when the Endpoint is written out. Automatically generated callback > bindings, usually generated to match the forward binding, won't be in that > list and won't get written out so we need to address that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3965) In a Service Implementation annotated with @Service, it's unannonated properties should not be introspected
[
https://issues.apache.org/jira/browse/TUSCANY-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163524#comment-13163524
]
Simon Laws commented on TUSCANY-3965:
-
At revision: 1210860 I added some more changes to generally not detect
properties/references automatically if there are @Service/@Reference/@Property
annotations. This highlights some errors in the JCI tests so I've added some
excludes to the JCI test suite until I can get OASIS to fix them. I'll leave
this JIRA open until I can remove the excludes.
> In a Service Implementation annotated with @Service, it's unannonated
> properties should not be introspected
> ---
>
> Key: TUSCANY-3965
> URL: https://issues.apache.org/jira/browse/TUSCANY-3965
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-2.0-Beta1
> Environment: All
>Reporter: Hasan Muhammad
>Priority: Critical
> Fix For: Java-SCA-2.x
>
>
> I was trying to deploy a composite which has component implementing a java
> implementation annotated with @Service which has the following field
> @Service(TestOasis.class)
> public class TestOasisImpl implements TestOasis {
> @DefaultHelperContext
> protected HelperContext helperContext;
> This is not a property as it clearly does not have a @Property annotation and
> hence the composite definition does not define this property. However, the
> validation is logging this as an error as follows
> [Composite: {http://docs.oasis-open.org/ns/opencsa/sca/200912}, Component:
> SDOSimpleServiceJavaSerOasis] - No type specified on component property:
> Component = SDOSimpleServiceJavaSerOasis Property = helperContext
> This is coming from org.apache.tuscany.sca.builder.impl.ComponentBuilderImpl
> and the message ID is NoTypeForComponentProperty
> This validation is too strict and we should ignore properties defined in
> Service class which are not annotated with @Property. The CI spec section 8.1
> appears to confirm to this deduction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3985) Manipulate custom SOAP headers
[ https://issues.apache.org/jira/browse/TUSCANY-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160091#comment-13160091 ] Simon Laws commented on TUSCANY-3985: - This is the link I couldn't find http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/testing/itest/policy/interceptors/ This doesn't deal directly with editing the message header but gives a good demonstration of the various ways you can construct and deploy policy interceptors inside which you could add code to edit message headers. > Manipulate custom SOAP headers > -- > > Key: TUSCANY-3985 > URL: https://issues.apache.org/jira/browse/TUSCANY-3985 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Axis Binding Extension > Environment: Any >Reporter: Ricky Wong > > Is there any way to manipulate custom SOAP headers when using Web Services > bindings? We need the team to both set values in SOAP headers as well as > retrieve values from SOAP headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3985) Manipulate custom SOAP headers
[
https://issues.apache.org/jira/browse/TUSCANY-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160082#comment-13160082
]
Simon Laws commented on TUSCANY-3985:
-
To do this you have to manipulate the headers at the Axis level. You can do
this in one of two ways:
1/ Write a Tuscany policy interceptor that does something like:
public Message invoke(Message msg) {
WSAxis2BindingContext bindingContext = msg.getBindingContext();
OperationClient operationClient =
bindingContext.getAxisOperationClient();
MessageContext requestMC = operationClient.getMessageContext("Out");
// from requestMC I think you can get the envelope and do what you like
See
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/policy-security/src/main/java/org/apache/tuscany/sca/policy/authentication/basic/
and
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-ws-runtime-axis2/src/main/java/org/apache/tuscany/sca/binding/ws/axis2/policy/authentication/basic/
as examples of creating a policy and associated interceptors for both
reference and service sides
2/ Write a Tuscany policy interceptor that installs a native Axis interceptor
You can do this by adding the appropriate code to add the Axis interceptor
inside the configureBinding(Object context) operation of a Tuscany policy
provider. I can't lay my hand on an example of this but I'm sure there is one
somewhere. I'll update this JIRA if I find link.
If you've not created a policy for Tuscany 2.x before it can seem a bit
daunting so post to the mail list if you have questions.
> Manipulate custom SOAP headers
> --
>
> Key: TUSCANY-3985
> URL: https://issues.apache.org/jira/browse/TUSCANY-3985
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Axis Binding Extension
> Environment: Any
>Reporter: Ricky Wong
>
> Is there any way to manipulate custom SOAP headers when using Web Services
> bindings? We need the team to both set values in SOAP headers as well as
> retrieve values from SOAP headers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3965) In a Service Implementation annotated with @Service, it's unannonated properties should not be introspected
[
https://issues.apache.org/jira/browse/TUSCANY-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13138383#comment-13138383
]
Simon Laws commented on TUSCANY-3965:
-
The discussion on the ML
(http://mail-archives.apache.org/mod_mbox/tuscany-dev/201108.mbox/%3c4e53d96a.5040...@gmail.com%3e)
tailed off a while back and the majority view seems to be that we should
ignore any properties on a super class on the basis that the implementation
class should be in control. I'll do the changes to make this so.
> In a Service Implementation annotated with @Service, it's unannonated
> properties should not be introspected
> ---
>
> Key: TUSCANY-3965
> URL: https://issues.apache.org/jira/browse/TUSCANY-3965
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-2.0-Beta1
> Environment: All
>Reporter: Hasan Muhammad
>Assignee: Simon Laws
>Priority: Critical
> Fix For: Java-SCA-2.x
>
>
> I was trying to deploy a composite which has component implementing a java
> implementation annotated with @Service which has the following field
> @Service(TestOasis.class)
> public class TestOasisImpl implements TestOasis {
> @DefaultHelperContext
> protected HelperContext helperContext;
> This is not a property as it clearly does not have a @Property annotation and
> hence the composite definition does not define this property. However, the
> validation is logging this as an error as follows
> [Composite: {http://docs.oasis-open.org/ns/opencsa/sca/200912}, Component:
> SDOSimpleServiceJavaSerOasis] - No type specified on component property:
> Component = SDOSimpleServiceJavaSerOasis Property = helperContext
> This is coming from org.apache.tuscany.sca.builder.impl.ComponentBuilderImpl
> and the message ID is NoTypeForComponentProperty
> This validation is too strict and we should ignore properties defined in
> Service class which are not annotated with @Property. The CI spec section 8.1
> appears to confirm to this deduction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3962) JCA20001 should not apply to interfaces which Tuscancy references
[ https://issues.apache.org/jira/browse/TUSCANY-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13130596#comment-13130596 ] Simon Laws commented on TUSCANY-3962: - I don't think you're trying to do anything particularly strange. I think what we'd have to do to make this work is relax the code I referenced to determine whether the interface is remoteable from and SCA point of view or not. I can try this and see if I get a clean build. Anyone see particlar concerns about doing this? > JCA20001 should not apply to interfaces which Tuscancy references > - > > Key: TUSCANY-3962 > URL: https://issues.apache.org/jira/browse/TUSCANY-3962 > Project: Tuscany > Issue Type: Bug > Components: OASIS Compliance - TUSCANY >Affects Versions: Java-SCA-2.0-Beta3 > Environment: WindowsXP SP3 >Reporter: Glen Conboy > Attachments: myscaproject.zip > > > I have a component which references a Java RMI interface. > When I try to run Tuscany I get this error: > org.apache.tuscany.sca.interfacedef.OverloadedOperationException: [JCA20001] > Cannot overload operation xyz on aaa.bbb.ccc.ddd.ServerInterface as it is a > @Remotable interface > JCA20001 basically states "Remotable Services MUST NOT make use of method > overloading". However I think that this should only apply to services which > Tuscany is exposing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3959) Intent matching is not performed for intents that may be provided by the binding
[
https://issues.apache.org/jira/browse/TUSCANY-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128757#comment-13128757
]
Simon Laws commented on TUSCANY-3959:
-
I do think that this highlights an issue but not with the piece of code
referenced. The code referenced is trying to determine whether there are any
intents that have no policy sets and I believe it's operation is correct. The
policy match code as it stands does just that. Matches policy. It doesn't
attempt to match intents but turns them into policy sets and matches those. The
problem, as described, highlights that "mayProvide" intents don't give rise to
policy sets as the policy it natively provided by the binding so it's possible
to have intents at the reference that don't match the service and not detect
it.
We could the test described but separately from the test looking for
unsatisfied intents. I'll look into it.
> Intent matching is not performed for intents that may be provided by the
> binding
>
>
> Key: TUSCANY-3959
> URL: https://issues.apache.org/jira/browse/TUSCANY-3959
> Project: Tuscany
> Issue Type: Bug
>Affects Versions: Java-SCA-2.0
>Reporter: Greg Dritschler
>
> EndpointReferenceBinderImpl.haveMatchingPolicy() matches the intents
> specified on a reference bindiing to those specified on a potential target
> service binding. For some reason, it skips over intents that may be provided
> by the binding.
> } else if (bindingType != null &&
>bindingType.getMayProvidedIntents().contains(intent)){
> eprIntents.remove(intent);
> Even though the binding provides the intent when requested to do so, it still
> should be matched. It doesn't make sense to allow the client to tell the
> reference binding to do something if the service binding isn't doing the same
> thing. Note that this applies only to interaction intents. Implementation
> intents (such as transactedOneWay) SHOULD NOT be matched. So the above logic
> should be changed such that:
> a) if the intent is an interaction intent, remove it if the endpoint also has
> the endpoint
> b) if the intent is an implementation intent, remove it
> ** NOTE ** TUSCANY-3958 must be addressed before this JIRA. TUSCANY-3958
> reports that intents are not present in a remote endpoint. Obviously we have
> to fix getting the intents in remote endpoints before we fix matching them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3962) JCA20001 should not apply to interfaces which Tuscancy references
[ https://issues.apache.org/jira/browse/TUSCANY-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128722#comment-13128722 ] Simon Laws commented on TUSCANY-3962: - Thanks for the example Glen. It looks like there are no SCA annotations in this example. I looked at the JavaInterfaceIntrospector and found this comment // Consider @javax.ejb.Remote, java.rmi.Remote and javax.ejb.EJBObject // equivalent to @Remotable So it looks like your interface is treated as @Remotable. We have to decide whether this is correct or not because, as you've found, there are implications re. method overloading. > JCA20001 should not apply to interfaces which Tuscancy references > - > > Key: TUSCANY-3962 > URL: https://issues.apache.org/jira/browse/TUSCANY-3962 > Project: Tuscany > Issue Type: Bug > Components: OASIS Compliance - TUSCANY >Affects Versions: Java-SCA-2.0-Beta3 > Environment: WindowsXP SP3 >Reporter: Glen Conboy > Attachments: myscaproject.zip > > > I have a component which references a Java RMI interface. > When I try to run Tuscany I get this error: > org.apache.tuscany.sca.interfacedef.OverloadedOperationException: [JCA20001] > Cannot overload operation xyz on aaa.bbb.ccc.ddd.ServerInterface as it is a > @Remotable interface > JCA20001 basically states "Remotable Services MUST NOT make use of method > overloading". However I think that this should only apply to services which > Tuscany is exposing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3962) JCA20001 should not apply to interfaces which Tuscancy references
[ https://issues.apache.org/jira/browse/TUSCANY-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126434#comment-13126434 ] Simon Laws commented on TUSCANY-3962: - In this case have you excluded some @Remotable interfaces by not including them in the @Service() annotation? I suspect what is happening is that the code introspects all of the interfaces of an implementation regardless of the @Service configuration. > JCA20001 should not apply to interfaces which Tuscancy references > - > > Key: TUSCANY-3962 > URL: https://issues.apache.org/jira/browse/TUSCANY-3962 > Project: Tuscany > Issue Type: Bug > Components: OASIS Compliance - TUSCANY >Affects Versions: Java-SCA-2.0-Beta3 > Environment: WindowsXP SP3 >Reporter: Glen Conboy > > I have a component which references a Java RMI interface. > When I try to run Tuscany I get this error: > org.apache.tuscany.sca.interfacedef.OverloadedOperationException: [JCA20001] > Cannot overload operation xyz on aaa.bbb.ccc.ddd.ServerInterface as it is a > @Remotable interface > JCA20001 basically states "Remotable Services MUST NOT make use of method > overloading". However I think that this should only apply to services which > Tuscany is exposing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3943) JAXWS Elements are not processed by the WSDLModelResolver - enableWrapperStyle elements are ignored
[ https://issues.apache.org/jira/browse/TUSCANY-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124090#comment-13124090 ] Simon Laws commented on TUSCANY-3943: - I've committed the patch Eric but it fails. Judging by comments here I'm assuming that that is expected so I've marked the two tests as @Ignore. To get the test to run I had to replace the contribution location string target/itest-contribution-doc-lit-disablewrapped.jar with ../disablewrapped-app/target/disablewrapped-app.jar Is my change correct? Also most of the XML artifacts in the patch were missing license headers. I've added them. > JAXWS Elements are not processed by the WSDLModelResolver - > enableWrapperStyle elements are ignored > --- > > Key: TUSCANY-3943 > URL: https://issues.apache.org/jira/browse/TUSCANY-3943 > Project: Tuscany > Issue Type: Improvement > Components: SCA Java Runtime > Environment: All systems >Reporter: Eric Larsen > Fix For: Java-SCA-2.x > > Attachments: binding-ws-wsdlgen.patch, interface-wsdl.patch, > itest.patch > > > Tuscany doesn't process any jaxws tags that are included in WSDL files. This > causes any enableWrapperStyle elements to be ignored, which causes a logic > failure in the wrapping logic when Tuscany expects wrapped objects, and Java > classes generated by external tools such as wsimport are not wrapped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
