Re: [NOTICE] Welcome Jean-Sebastien Delfino as new Tuscany PMC Chair
On 22/05/2013 17:35, Luciano Resende wrote: The Tuscany PMC has voted and the Board has confirmed Jean-Sebastien Delfino as the new Tuscany PMC Chair. Congratulations !!! -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ Congratulations, Jean-Sebastien. Yours, Mike.
[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-tabpanelfocusedCommentId=13129641#comment-13129641 ] Mike Edwards commented on TUSCANY-3962: --- The interface does contain overloaded methods but I think that this should be allowed for an @Reference. Uh - no. If this interface is meant to be remotable, this implies that the reference *could* be changed by configuration to use a different service using a different protocol, such as Web services, without changing the implementation code at all. This is what SCA is about. *IF* the interface has overloaded methods and the reference was switched to use Web services, then it would fail. That is the reason for this restriction on overloaded methods. What you have in your example is a case of an interface that can only be used remotely over a very limited set of protocols. I think that needs some special handling so that it is clear that the interface is not usable more generally. eg some kind of Intent gets applied that is only satisfied by a binding.ejb or a similar style of mechanism. 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
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
On 14/09/2011 01:10, Greg Dritschler wrote: These questions have come up before, and in the past we've looked at the Common Annotations for the Java Platform specification (aka JSR 250) for guidance. The rules being proposed here appear to be in opposition to one of those guidelines: (page 2-6) 4. Members inherited from a superclass and which are not hidden or overridden maintain the annotations they had in the class that declared them, including member-level annotations implied by class-level ones. This guideline makes a lot of sense to me and in my opinion it would be a mistake to do something different. Can we go back to the original problem? What code is deciding that an unannotated field in a superclass is a property? I don't see the code that would do that. Greg Greg, Regarding JSR250 and annotations, you are totally correct. However, the question for SCA and the specifications is not about the inheritance of annotations or the inheritance of methods, fields etc. The specifications are making statements about what gets introspected - ie the algorithm that is used to introspect some class to determine the component type. The decision made by the spec folks was that it is important to enable the subclass to be in control - and to do this, it is necessary to limit the introspection of the class to the artifacts that it declares itself - and not to introspect aspects of the parent class. The simplest example concerns the @Service annotation. If the superclass has an @Service annotation and if that annotation was always scanned by the introspection process, then the implication is that the subclass could never turn off the @Service annotation. If the sublcass is to be in control, then the introspection algorithm must not be able to examine the superclass annotations. This is then extended to all the aspects of the introspection algorithm. In some ways, this is a case of we're damned if we do and we're damned if we don't. Either way we construct the introspection algorithm, there are consequences for the developer - more work, more things to do. We've chosen one approach - at least its consistent even if for some developers it means more effort. I'm open to hearing that we've made the wrong choice, but it is fair for me to ask for some convincing examples. Yours, Mike.
Re: [jira] [Updated] (TUSCANY-3947) Compliance testcase POJO_10009 testing for too strict of a condition
On 15/09/2011 22:59, Jennifer A Thompson (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jennifer A Thompson updated TUSCANY-3947:
-
Description:
In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is
checking if the TCCL retrieved is exactly the same as
service1ClassLoaderCheckImpl's classloader. However, it seems as long as the
implementation class is loadable from the TCCL the testcase is still compliant
with the specifiation.
The suggested update is to change:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
String result = thread context classloader is correct;
if( loader != tccl ) result = thread context classloader not correct;
return serviceName + operation1 invoked + result;
}
to:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
ClassLoader loader2 =
Class.forName(org.oasisopen.sca.test.service1ClassLoaderCheckImpl, false,
tccl);
String result = thread context classloader is correct;
if (loader != loader2) result = thread context classloader not correct;
return serviceName + operation1 invoked + result;
}
was:
In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is
checking if the TCCL retrieved is exactly the same as
service1ClassLoaderCheckImpl's classloader. However, it seems as long as the
implementation class is loadable from the TCCL the testcase is still compliant
with the specifiation.
The suggested update is to change:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
String result = thread context classloader is correct;
if( loader != tccl ) result = thread context classloader not correct;
return serviceName + operation1 invoked + result;
}
to:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
ClassLoader loader2 =
Class.forName(org.oasisopen.sca.test.service1ClassLoaderCheckImpl, false,
tccl);
String result = thread context classloader is correct;
if (loader != loader2) result = thread context classloader not correct;
return serviceName + operation1 invoked + result;
}
This testcase would then allow the runtime the flexibility to compose a
classloader that can delegate to the contribution classloader and to other
classloaders (e.g. library loaders).
Compliance testcase POJO_10009 testing for too strict of a condition
-
Key: TUSCANY-3947
URL: https://issues.apache.org/jira/browse/TUSCANY-3947
Project: Tuscany
Issue Type: Improvement
Components: OASIS Compliance - TUSCANY
Affects Versions: Java-SCA-2.x
Reporter: Jennifer A Thompson
Fix For: Java-SCA-2.x
In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is
checking if the TCCL retrieved is exactly the same as
service1ClassLoaderCheckImpl's classloader. However, it seems as long as the
implementation class is loadable from the TCCL the testcase is still compliant
with the specifiation.
The suggested update is to change:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
String result = thread context classloader is correct;
if( loader != tccl ) result = thread context classloader not correct;
return serviceName + operation1 invoked + result;
}
to:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
ClassLoader loader2 =
Class.forName(org.oasisopen.sca.test.service1ClassLoaderCheckImpl, false,
tccl);
String result = thread context classloader is correct;
if (loader != loader2) result = thread context classloader not correct;
return serviceName + operation1 invoked + result;
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Folks,
The specification says this:
The SCA runtime MUST set the thread context class loader of a component implementation class to the
class loader of its containing contribution. [JCI19]
and this:
The SCA runtime MUST ensure that the Java classes used by a contribution are all loaded by a class
loader that is unique for each contribution in the Domain. [JCI100010]
I don't see how this can be interpreted as allowing the TCCL
[jira] [Created] (TUSCANY-3944) MANIFEST.MF for tuscany-node-manager module is missing a dependency for javax.ws.rs
MANIFEST.MF for tuscany-node-manager module is missing a dependency for javax.ws.rs --- Key: TUSCANY-3944 URL: https://issues.apache.org/jira/browse/TUSCANY-3944 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.0-Beta3 tuscany-node-manager has a series of dependencies on the javax.ws.rs API (see DomainCompositeResource for examples), but the MANIFEST.MF has no entries for these dependencies. This results in ClassNotFound exceptions when running Tuscany under OSGi (eg. running the OASIS tests using the OASIS OSGi based Runtime Bridge) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TUSCANY-3944) MANIFEST.MF for tuscany-node-manager module is missing a dependency for javax.ws.rs
[ https://issues.apache.org/jira/browse/TUSCANY-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-3944. --- Resolution: Fixed Resolved by adding an import declaration for javax.ws.rs package into the MANIFEST.MF file for tuscany-node-manager module. Committed under 1169669 MANIFEST.MF for tuscany-node-manager module is missing a dependency for javax.ws.rs --- Key: TUSCANY-3944 URL: https://issues.apache.org/jira/browse/TUSCANY-3944 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.0-Beta3 tuscany-node-manager has a series of dependencies on the javax.ws.rs API (see DomainCompositeResource for examples), but the MANIFEST.MF has no entries for these dependencies. This results in ClassNotFound exceptions when running Tuscany under OSGi (eg. running the OASIS tests using the OASIS OSGi based Runtime Bridge) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3942) Should reference target=XXX with empty child binding.sca element be allowed?
[ https://issues.apache.org/jira/browse/TUSCANY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100115#comment-13100115 ] Mike Edwards commented on TUSCANY-3942: --- Folks, For OASIS, this is illegal, pure simple. It is not allowed to have @target set on a reference and also have binding/ child elements. There are compliance tests which check for this too. Cease desist !! ;-) Yours, Mike. Should reference target=XXX with empty child binding.sca element be allowed? - Key: TUSCANY-3942 URL: https://issues.apache.org/jira/browse/TUSCANY-3942 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Priority: Minor Should this be allowed? (I should have phrased this as uri-less binding.sca rather than empty) reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): if ((binding instanceof SCABinding) (binding.getURI() == null)) continue; I can understand the thought process here, e.g. the context around ASM50026 involves avoiding ambiguity in resolving references, and since an empty, uri-less binding.sca doesn't resolve the reference at all.. it doesn't conflict with the target. However, the language in ASM50026 is plain and simple and seems to disallow this, and doesn't make a special case for binding.sca without a @uri. One problem with tolerating this syntax, (as we do today), is that, in general, when using @target you don't get to select which binding to use, from the reference side.However I could see someone thinking that adding the binding.sca child elem to the reference with @target value would imply that the binding.sca should be used to do the invocation. (ASM50012 implies this). So it's unclear if this should have this behavior making the app implementation-dependent. From a purely Tuscany-only viewpoint I can even see the value of tolerating this... however it's such a simple case syntax-wise, and the spec is clearly trying to specify the correct vs. incorrect behavior... so I do think we should try to follow the letter of the spec in this instance. I tried to find some earlier discussion here, this is all I found which didn't seem to help much (except to make me wonder if there is some other use case, maybe involving callbacks, complicating this.. but I can't think of it): https://issues.apache.org/jira/browse/TUSCANY-3013 Thoughts? Thanks, Scott -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: What should the Tuscany generated WSDL contract look like for an async service?
On 25/08/2011 18:03, Simon Laws wrote:
On Thu, Aug 25, 2011 at 2:49 PM, ant elderant.el...@gmail.com wrote:
Looking to fix TUSCANY-3931 about the clients not working with the
wsdl in the domain registry for async services and i wonder what the
wsdl should really look like. For example with the service interface:
@AsyncInvocation
public interface Service1AsyncServer {
@AsyncFault( {BusinessFault1.class, BusinessFault2.class} )
public void operation1Async( String input, ResponseDispatchString
handler );
}
would we expect the generated wsdl that goes in the domain registry be
that or the equivalent synchronous version, so with an operation1
instead of operation1Async?
...ant
My immediate answer would be that it should look like the synchronous
version with the asyncInvocation intent attached.
When we are matching interfaces we are comparing the synchronous
version because that's what the statement of the service interface
looks like.
Bindings have to decide how to support async invocations. We current
support two models which allow native and non-native support. Our web
services binding doesn't support async natively so I would guess that
?wsdl to the async endpoint results in the synch WSDL (don't know if
it's appropriately decorated). If it did provide native support would
we expect it to represent the async flow explicitly. No sure but we
can look to see it Axis says anything about what it does in the async
case.
Simon
+1
WSDL simply has the AsyncInvocation intent added to it. How that gets interpreted by the binding is
the big thing. The idea is that the binding should really split the request and response handling.
But note that in principle, a non-aware binding could try to treat the operation as synchronous -
it would simply time out in most cases.
Yours, Mike.
Re: What should the Tuscany generated WSDL contract look like for an async service?
On 25/08/2011 20:53, Greg Dritschler wrote: I agree that the DomainRegistry should have the equivalent synchronous version. While we're on this subject, I happened to be wondering today whether @AsyncInvocation obligates the service implementation to use the async service interface? Obviously it makes the most sense to use them together, but is that required? As a service implementer, could I use @AsyncInvocation with the normal synchronous interface? This would mean the service implementation completes inline so to speak and has no need for a ResponseDispatch object. Since @AsyncInvocation is used, the SCA runtime is obligated to provide a suitable thread for a long-running request, and the binding still must support an asynchronous response. Effectively, it means the SCA runtime would do the ResponseDispatch call on behalf of the implementation at the completion of the method. I'm not terribly excited about supporting such a thing, but I didn't see anything in the spec that suggests either way whether it's allowed or disallowed. Greg Greg, Yuk, pretty ugly. I'd be happy if the SCA runtime barfed if it saw @AsyncInvocation being used like that. It isn't a good pattern to encourage since it consumes server resources and is susceptible to failures. As for fixing the spec to disallow this usage - maybe V1.2 could address that. Yours, Mike.
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
On 23/08/2011 23:23, Simon Nash wrote: This sounds like the right approach. One small point is that the description talks about redeclaring fields and methods in the subclass. This is possible with methods, but it doesn't work for fields as this results in a separate field with the same name in the subclass which hides the superclass field. To expose a superclass field as a property in the subclass, the subclass would need to declare a subclass setter method that assigns to the superclass field. Simon Yes, agreed. This all makes subclassing more work, of course, but I see no alternative if the subclass is going to be in control. Yours, Mike.
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
Folks, Commenting on this JIRA: On 19/08/2011 01:32, Vijai Kalathur (JIRA) wrote: Inherited fields in service impl classes are treated as Properties snip 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. -- First, I agree that the Java CI specification is deficient in this area - it does not give a clear definition of what is supposed to happen when the Java implementation class extends another class. Simon Nash commented that the principle is that the implementation class is in control. In particular, if the implementation class is annotated, those annotations are obeyed. This is the correct view, since otherwise the subclass is forced to accept whatever is declared in the superclass with no option of changing things. Sections mentioned below are from the SCA Java CI specification cd034 / csd04. a) CASE 1: Implementation class has some SCA Annotations In the case where the implementation class has one or more SCA annotations (@Service, @Reference, @Property), then the rules that apply to such annotations are followed, as described in Section 8. NOTE: It is important to remember that the SCA annotations @Service, @Reference, @Property are NOT INHERITED. So that @Service on the superclass DOES NOT mean that the sublcass is annotated with @Service through inheritance. If there is an @Service annotation on the class, it is handled as in Section 8. If there is no @Service annotation, then the implementation offers no services. This applies even if the superclass has an @Service annotation. Each Field and Setter method in the implementation class annotated with @Reference or @Property is treated according to Section 8. What about Fields and Setter methods declared in the superclass? Clearly any Fields and Setters without annotations are simply ignored (as stated by Section 8). But what about superclass Fields Setters with annotations? For the implementation class to be in control, then it must be the case that only annotated fields and setter methods in the implementation class are taken into consideration. Any annotated fields and setter methods in the superclass are ignored. This puts a burden on the implementation class to redeclare the fields / setters and annotate them suitably if the implementation class wants those fields / setters treated as references or properties. b) CASE 2: Implementation class has no SCA Annotations, superclass has SCA annotations @Service annotations are introspected from the implementation class itself. Any @Service annotation on the superclass is not inherited. Whether *any* services are offered by the implementation class then depends on whether there are any @Reference or @Property annotations in the class itself (as defined in Section 8.1 of the spec). Regarding the references and properties of the implementation class, following the principle established in CASE 1, annotated fields and methods in the superclass are ignored as far as their annotations are concerned. ie The presence of a @Reference or @Property annotation in the superclass has no impact on whether the implementation class is treated as unannotated. There is a SEPARATE question as to whether the superclass setter methods public/protected fields are considered for the calculation of the references properties of the unannotated class (ignoring their annotations, that is). In my view, all such methods and fields of the superclass are also ignored when computing the references properties of the implementation class. If the subclass wants them as references properties, then the implementation class must redeclare them appropriately. This provides the subclass with control, as defined for CASE 1, at the expense of some work (ie redeclarations etc). c) CASE 3: Implementation class has no SCA Annotations, superclass has no SCA annotations This case follows the principles for CASE 2, except that there are no annotations to ignore! If we agree this approach, we should write it up and make it available permanently. Yours, Mike.
Re: Target service scope with implementation.composite
On 09/08/2011 23:33, Greg Dritschler wrote: New question: What is the scope for resolving a COMPOSITE reference target? It seems like it is resolved in the context of the using composite. I recall seeing something about this somewhere but all I can find is this: http://www.osoa.org/jira/browse/ASSEMBLY-5 Greg Greg, If a composite reference has a target defined, either via @target or via some binding declared on the reference, these are to be taken as DEFAULTS which apply when the composite is used as an implementation by some component (ie a component in a higher level composite). These targets have no meaning within the composite in which they are declared. The configuration of the implementation is supplied by that using component - and the component can either supply all its own configuration (this is expected to be the 99% default situation) or it can decide to use the defaults supplied by the implementation (ie by the composite reference in this case). When viewed this way, the target(s) of the higher level component reference are in the context of the higher level component - either its composite or the Domain, depending on the level of that component. In my opinion, it is not a wise procedure to define targets in a composite reference either using @target or using an SCA binding with a @uri declared. The reason for this is that the writer of the composite cannot normally know the context in which it is going to be used - so for example if they had @target=fooComponent/barService, how could they be sure that the using component was in any kind of context that had a component with the name fooComponent. The idea of setting a default binding target using a concrete binding such as binding.ws makes more sense - ie the composite writer can say - here is a reference for this composite implementation I know that there is one Web service over there that will satisfy the reference. HOWEVER, either way, what counts is the confuguration on the component reference - whether this was explicity set by the component or was a default value derived from the composite reference - and it is the higher level component reference configuration that is then pushed down onto the (proxy) component reference at the lower level (ie the component reference identified in the composite reference @promotes attribute). Note that this process of an implementation potentially having a default configuration for a reference applies in principle to ANY type of implementation, not only to a composite - ie a Java implementation class could in principle have a reference with a binding target defined. I hope that this helps. Yours, Mike.
Re: Target service scope with implementation.composite
On 08/08/2011 14:56, Greg Dritschler wrote: I have the following test case: Composite A: - is deployable - has a component reference with a reference target pointing to some top-level component outside of A - does not promote the component reference Composite B: - is deployable - reuses composite A as the implementation of a component B fails because, when A is used within the context of B, the reference target is not found within A. I think it is correct that this is an error, but given some of the discussion lately about implementation.composite, I'd like a second opinion. Assembly says 1880 For a composite used as a component implementation, wires can only link sources and targets that are 1881 contained in the same composite The error happens to be discovered at the time the reference is invoked (from within the context of B). Unable to bind [] - No endpoints found in the domain that match the reference It seems like it could be detected at build time. Greg Greg, Its an error. If you have a component reference with a target which is a component service of a second component which is not in the composite of the first component, the only way that this reference can be satisifed is by some form of include processing which adds the target component to the context of the first component. This simply can't happen when the composite is used as an implementation - it could happen for a composite deployed directly to the Domain. Yours, Mike.
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
Greg, I'll try to address this with some inline replies, but I get the feeling that maybe a conf call will be needed to interactively work on your concerns. Yours, Mike. On 05/08/2011 16:12, Greg Dritschler wrote: Simon, You seem to be saying there's an equivalence between binding.sca @uri and reference target in terms of promotion behavior. I cannot find anything in the spec that supports that. Here is the description of nonOverridable: 876 nonOverridable : boolean (0..1) - a boolean value, false by default, which indicates whether this 877 component reference can have its targets overridden by a composite reference which promotes the 878 component reference. 879 If @nonOverridable==false, if any target(s) are configured onto the composite references which 880 promote the component reference, then those targets replace all the targets explicitly declared on the 881 component reference for any value of @multiplicity on the component reference. If no targets are 882 defined on any of the composite references which promote the component reference, then any 883 targets explicitly declared on the component reference are used. This means in effect that any targets declared on the component reference act as default targets for that reference. This description explicitly talks about reference targets. There is nothing here that mentions bindings. This description also doesn't explain how nonOverridable applies to higher-level composites that reuse this composite. It only describes the interaction between the composite reference and the component reference within the composite itself. If targets are specified on both an 'outer' component reference and its promoted 'inner' component reference, what is supposed to happen? Is it dependent on the setting of nonOverridable? I can't find anything that addresses this. There are a lot of bones to pick out of here - let me see if I can disentangle them. 1) This section talks about targets of a reference in the sense implied by section 4.3.1 of the specification. There are 7 ways described in there for specifying a target service for a reference, which includes binding specific stuff like binding @uri values. So it is intended to cover bindings as well as the other ways of specifying a target service. 2) How does nonOverridable apply to a higher level COMPONENT (not composite) that reuse this composite? The answer is that it does not. ie the setting has no effect on the configuration of the higher level component - if it did, there would be a description in the spec - there isn't any. What effect nonOverridable has is on the reference that has nonOverridable on it. It basically says whether a promotion obliterates any other targets the reference may have or whether the promotion simply adds targets. The DEFAULT is obliteration. ie if you promote a reference then the target identified by the higher level component is what actually gets used. Only if nothing is supplied at the higher level could a target on the lower level get used (and that is the purpose of this bit complexity - it gives a default (local) target in the case the higher level component does not configure one. The relation between the higher level component reference and the lower level component reference that is promoted is essentially captured in this statement in section 4.3.1: 6. Through the promotion of a component reference by a composite reference of the composite containing the component (the target service is then identified by the configuration of the composite reference) and configuration here means the configuration supplied by the component using the composite as an implementation (there is other material that covers the generalalities of how a component configuration configures ANY implementation - and that applies equally to composite implementations as it does to Java or any other type. If targets are specified on the outer level and the inner level, then what is supposed to happen is described in the section that deals with nonOverridable - and there are 2 cases: 1) If @nonOverridable==false, if any target(s) are configured onto the composite references which promote the component reference, then those targets replace all the targets explicitly declared on the component reference for any value of @multiplicity on the component reference. If no targets are defined on any of the composite references which promote the component reference, then any targets explicitly declared on the component reference are used. This means in effect that any targets declared on the component reference act as default targets for that reference. 2) If @nonOverridable==true, and the component reference @multiplicity is 0..n or 1..n, any targets configured onto the composite references which promote the component reference are added to any references declared on the component reference - that is, the
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
On 04/08/2011 10:27, Simon Laws wrote: On Wed, Aug 3, 2011 at 8:37 PM, Greg Dritschler greg.dritsch...@gmail.com wrote: I have the following composites: Composite A has a component reference myService with binding.sca uri=X. The reference is promoted. Composite B has a component that uses A as its implementation. It redefines reference myService and specifies binding.sca uri=Y. I get the error [ASM50022] Too many targets on reference: myService I've found that EndpointReferenceBuilderImpl.pushDownEndpointReferences() is adding the endpoint references from the outer component reference to the inner component reference. This doesn't seem like it applies in this case. My understanding is that bindings configured on the outer component reference override bindings that would otherwise have been inherited from the promoted reference. pushDownEndpointReferences() was introduced in revision 833132 which says: Fix motivated by ASM-5023. Update code to reflect the OASIS treatment of promoted references. Endpoint references are now copied down to the promoted component reference and the multiplicity validation is performed there. ASM-5023 uses reference target. If I were using reference target instead of binding uri, then I would agree I have an error (assuming multiplicity 0..n or 1..n), since reference targets are additive. But I'm not using reference target. Greg Hi Greg I think the only useful URI on a reference binding.sca is the name of a target service. This is equivalent to specifying the same target service via the target attribute. I think though that you're arguing that the top level binding configuration should override the lower level binding configuration? Simon Folks, Let's be clear about the use of @uri on binding.sca. IF you specify @target on the parent binding - then it is not valid to use binding subelements: If a reference has a value specified for one or more target services in its @target attribute, there MUST NOT be any child binding/ elements declared for that reference. [ASM50026] (Section 4.3.1 Assembly spec) so then IF you have a reference which allows multiple targets and you require a mixture of bindings, where some of them must be resolved bindings (eg reference is to an external web service known via its address) but others are desired to be binding.sca, then necessarily the only way of doing this is to use the @uri attribute on a binding.sca element: reference name=foo multiplicity=1..n binding.sca uri=SomeComponent/SomeService/ binding.ws uri=http://something.com/another/service/ /reference Hope this makes things a bit clearer. Yours, Mike.
Re: getting TooManyReferenceTargets when overriding binding uri of promoted reference
On 04/08/2011 14:27, Greg Dritschler wrote: From the assembly spec on component references: 900 binding : Binding (0..n) - A reference element has zero or more binding elements as children. If no 901 binding elements are specified for the reference, then the bindings specified for the equivalent 902 reference in the componentType of the implementation MUST be used. If binding elements are 903 specified for the reference, then those bindings MUST be used and they override any bindings 904 specified for the equivalent reference in the componentType of the implementation. [ASM50012] If this doesn't hold true, then there's no reason to be able to promote references, because there's no possibility to reconfigure them. I can't find a compliance test for this. Greg, Not sure what this applies to here. However, [ASM50012] relates to test assertions TA 5017 and TA 5018 which in turn are implemented by testcases 5017 and 5018: 5017: Tests that where a reference/ of a component/ has no binding/ child element, but the corresponding reference/ element in the componentType does have a binding child element, the binding/ from the componentType is used for the reference 5018: Tests that where a reference/ of a component/ has a binding/ child element and the corresponding reference/ element in the componentType has a binding child element, the binding/ from the reference/ is used for the reference If it's the promotion aspect you're concerned about, then there are other testcases that deal with that, eg 5023. Yours, Mike.
Re: Question regarding SCAClientFactory.getService() and promoted service
Folks, Simple answer to Scott's questions: On 26/07/2011 16:08, Scott Kurz wrote: Trying to understand myself as the spec doesn't seem crystal clear... I assume we'd agree also that the answer should be the same for this variation: composite B with component C2 service name=S1Promoted promote=C2 binding.ws/!-- Binding now specified on composite service -- /service component name=C2 implementation.java class=.../ service name=S1 binding.ws/ /service /component In contrast, suppose we that composite A with component C1 did not explicitly specify binding.sca, e.g.: component name=C1 implementation.composite name=B/ service name=S1Promoted/ /component Should this bebinding.ws then? YES Does it matter whether B's composite-level service has the binding or not? NO - if the component service has one or more bindings specified. YES - if the component service has zero bindings specified. Scott To quote chapter verse from the OASIS Assembly spec (line numbers for CD06): 770 ... If no 771 binding elements are specified for the service, then the bindings specified for the equivalent service in 772 the componentType of the implementation MUST be used, but if the componentType also has no 773 bindings specified, then binding.sca/ MUST be used as the binding. If binding elements are 774 specified for the service, then those bindings MUST be used and they override any bindings specified 775 for the equivalent service in the componentType of the implementation. [ASM50005] Yours, Mike.
Re: parsing parameters to the init method
On 30/07/2011 20:02, Eranda Sooriyabandara wrote:
Hi Raymond,
Can you model them as SCA properties? We support constructor based
injection.
Is there a example code which explain how to use it? Or can you explain a bit
how can to do it.
thanks
Eranda
Eranda,
The OASIS SCA Java CAA spec has an explanation of the lifecycle of a Java component implementation
in Section 4:
http://docs.oasis-open.org/opencsa/sca-j/sca-javacaa-1.1-spec.pdf
Figure 4.1 is useful in understanding the sequence in which the implementation
is created:
Constructing - Injecting - Initializing - Running
Note that a method annotated with @Init is called during the Initializing phase - and that this
occurs AFTER construction and injection are complete. What this means is that all Properties and
all References will be present at the point the @Init method is called.
Properties and References can be injected either via the constructor or via separate Setter methods
or public fields, appropriately annotated.
If you want Constructor injection, then create a constructor with one or more parameters and
annotate each parameter with either @Reference or @Property, as appropriate. something like this:
@Service(Service1.class)
public class service1ConstrImpl implements Service1 {
@Constructor
public service1ConstrImpl(@Property(name=serviceName,required=true)
String s) {
serviceName = s;
}
private String serviceName = service1;
...
} // end class
This example has a constructor - annotated with @Constructor - and a single parameter which is a
String and which is annotated as a property (@Property) with the name serviceName.
A complex but comprehensive example of the use of all aspects of the lifecycle of a Java
implementation is contained in the OASIS test suite for the Java CAA test suite here:
http://tools.oasis-open.org/version-control/browse/wsvn/sca-j/TestCases/JCA_General_POJO/src/main/java/org/oasisopen/sca/test/service1LifecycleExceptionsImpl.java
(WARNING! long complex piece of code)
So, if you do model all your dependencies as either References or as Properties, the @Init method
will have access to them all, ready to use.
Yours, Mike.
Re: 2.0-beta3 distro review
On 19/07/2011 11:26, ant elder wrote: Ok following the discussion last week about doing a beta3 release i've created a release branch and built the distros from that which are presently uploading to: http://people.apache.org/~antelder/tuscany/2.0-Beta3-review/ I've done a little clean up and tried the getting-started samples which mostly seem to work ok, and the rest of the release including legal files etc looks ok to me. So the only thing left is the quality of samples and documentation. I'm hoping that as with the previous beta release having not completely perfect doc will be ok for this release too. Anyway, please all if you have so time do some review and any clean up that you see as necessary and in a couple of days i'll spin an RC and call a vote to release. ...ant Ant, Unfortunately, I'll not be able to review this before I get back from vacation on Aug 1. Yours, Mike.
[jira] [Commented] (TUSCANY-3893) Policy appliesTo not correctly specified in policy compliance tests
[ https://issues.apache.org/jira/browse/TUSCANY-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068847#comment-13068847 ] Mike Edwards commented on TUSCANY-3893: --- The Policy test suite at OASIS has been fixed to ensure that all @appliesTo XPath values use sca: prefix for any and all SCA elements, as of 20 July 2011 Policy appliesTo not correctly specified in policy compliance tests --- Key: TUSCANY-3893 URL: https://issues.apache.org/jira/browse/TUSCANY-3893 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta2 Reporter: Simon Laws Fix For: Java-SCA-2.0 In several of the policy compliance tests the appliesTo XPath expression includes a note test describing an element without an explicit namespace. For example, from POL_4020, policySet name=BothIntents provides=test:BindingIntent test:ReferenceIntent appliesTo=//binding.sca attachTo=//sca:reference[@name='reference1']/interface.wsdl !-- This policy intentionally left blank -- /policySet Note. appliesTo=//binding.sca rather than appliesTo=//sca:binding.sca The XPath spec expects the namespace to be specified and maps the elements without a namespace shortname to the null namespace. (see http://www.w3.org/TR/xpath/#node-tests). We need to get OASIS to fix the tests. The only one that appears to fail because of this in Tuscany is 4020 but others have the same problem so we need to look at why they don't fail also. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [2.x] Problems and Proposed changes for the OASIS Java Client API - OASIS Issue raised, with Proposal
Folks, An OASIS Java TC issue has been raised for these problems: http://www.osoa.org/jira/browse/JAVA-243 along with the proposed updates, which can be seen in Section B.1.3 of this updated spec: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/42910/sca-javacaa-1.1-spec-wd052.pdf http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/42909/sca-javacaa-1.1-spec-wd052.doc Yours, Mike.
Re: [2.x] Problems and Proposed changes for the OASIS Java Client API - OASIS Issue raised, with Proposal
Folks, An OASIS Java TC issue has been raised for these problems: http://www.osoa.org/jira/browse/JAVA-243 along with the proposed updates, which can be seen in Section B.1.3 of this updated spec: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/42910/sca-javacaa-1.1-spec-wd052.pdf http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/42909/sca-javacaa-1.1-spec-wd052.doc Yours, Mike.
Re: Invocation/Application Context (again)
PS Next I think we should look at context information being passed from the application code to the code involved in a reference invocation... Folks, OK, time to delve into this piece of function. The basic capability of both ComponentContext and RequestContext is to supply information to an implementation when it is invoked. This could include information passed from the Binding implementation to the application (as discussed in the previous email). However, there is another piece of function which is nowhere described in the SCA specifications - and that is the need for the implementation to be able to convey information to the runtime - and specifically the Binding implementation - when invoking a reference. This capability has been discussed on the Tuscany list in the past - notably by some users. Examples include providing Authentication context for the call - where the credentials may depend upon the Authentication of the caller of the service (either passed striaght through, or created on the fly by the application). The question is - how can this be done? One possibility is to use the RequestContext structure to carry the information - or rather the extended form of TuscanyRequestContext, where we can envisage making the setting of extended context values available to the application: void setExtendedContextT( String contextName, T ); Obviously to be useful, there must be some set of well known contextName values which the application code and the binding code can use. However, the principle is simple enough - the application sets up values in the TuscanyRequestContext ahead of the invocation of some reference - and the TuscanyRequestContext is available to the runtime code which implements the reference, including the Binding code. One interesting question here is how to handle application threads which were not used to invoke a service - eg a thread from a pool created managed by the application code. At present, such a thread would have no context associated with it - to enable such threads to pass context to references, there is a need for an API to allow a TuscanyRequestContext to be created for such a thread. However, this is perhaps reaching too far at the moment, given that we have not yet agreed the basic function. Thoughts? Yours, Mike.
Re: Invocation/Application Context (again)
On 15/07/2011 12:08, Simon Laws wrote: Commenting on the last two posts. Generally I prefer the strong typing of context and the ability to have that type injected into an implementation. I do though accept that there is no API alternative to injection for anything other than RequestContext or derivatives. In the derivative case the app writer would be still be expected to cast to TuscanyRequestContext which isn't so elegant but will work. Well, I suppose we could envisage an annotation like @TuscanyRequestContext that would signal injection of a TuscanyRequestContext which would then not need any cast - but of course my concern is that any such code would only work with Tuscany and would not work with any other SCA runtime, which is the flip side of the concern. In terms of strong typing of context I would be concerned about a scheme in which each potential atom of context was separately injected - this would get out of hand very quickly I think. I suppose one scheme is to treat context like a set of Properties to be injected, where the property names are simple strings (of the type I'm advocating for getContext()), with the implication that each field/setter would be annotated like @TuscanyRequestContext( foo ) - and with the assumption that the type of the field/method had better match the implied type of that context property (which must be defined by the runtime, not by the application). I agree that the best we get for the set of names for context atoms is simply documentation - what would be good is a catalog that aims to promote the maximum amount of commonality, especially between Bindings, where I hope that header fields, for example, could use the same names and types for a wide range of binding types. This is really a matter of trying to get developers of binding implementations to use common context fields as far as possible. Of course, once you head down the headers road, then there could be a desire to reflect any and all headers into the application - something I don't think is a great idea - if it matters that much to the application it should be part of the service signature in 99.99% of cases. Yours, Mike.
Re: Invocation/Application Context (again)
Raymond, Can you explain why you prefer strobgly types context extensions? Why is this JAX-RS mechanism a good thing? Can you paint a picture of what this would look like: a) for the application components b) for the runtime/binding components Yours, Mike. On 15/07/2011 17:35, Raymond Feng wrote: I prefer to have strongly-typed context extensions. JAX-RS has the similar mechanism to allow custom context to be injected via @Context. The context can be resolved via: *http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html* * * *Thanks,* *Raymond *
Re: Rename binding-ws-runtime-axis2 to binding-ws-runtime
On 13/07/2011 22:48, ant elder wrote: On Wed, Jul 13, 2011 at 1:27 PM, Mike Edwards mike.edwards.inglen...@gmail.com wrote: On 12/07/2011 21:44, Raymond Feng wrote: Don't we prefer to use a JAX-WS based implementation as the default binding-ws-runtime? Thanks, Raymond / Folks, No problem with the renaming - but as for preferring the JAX-WS impl, I don't agree with that - the Axis binding implementation is the complete one at the moment - and is very much the route for the various policy options including security and reliable messaging. Why would a JAX-WS implementation be a better way to go? The main advantage of it is that its included in Java SE so there are no other external dependencies which makes it very easy to use. But I agree the Axis2 one is much more complete and seems a better choice. There are quite a lot of issues with the JAXWS RI based one, i'd be surprised if anyone is using it for more than simple helloworld demo type things. ...ant Ant, I think you agreeing with me here. The Java SE JAXWS implementation is a noddy one - it is a bare bones implementation ( I strongly urged Sun originally not to include it in the JDK for just this reason). We can't use it very seriously unless we start writing our own handlers for the various SOAP headers that are implied when doing anything beyond the basics - e.g. any form of Security. Yours, Mike.
Re: Invocation/Application Context (again)
On 13/07/2011 16:37, Simon Laws wrote: Yes, it's a shame we don't pass round a TuscanyContext rather than the ExtensionPointRegistry when we configure extension factories. We could look to do that but that's possibly a little orthogonal to how we pass context along the invocation chain. Although having said that if the providers did have access to a more complete context picture they could of course prime a message with a reference to that context at little extra cost. I was hinting at needing to add a context extension point so maybe that is a simple way through this. I.e. define a context base class and have context factories and structures registered against it, e.g. Static context: o.a.t.s.context.ContextFactory - o.a.t.s.context.TuscanyContextFactory;context=o.a.t.s.context.TuscanyContext // for anything that doesn't change at runtime we could add the context object to the registry also Dynamic context: o.a.t.s.context.ContextFactory - o.a.t.s.context.RequestContextFactory;context=o.a.t.s.context.RequestContext o.a.t.s.context.ContextFactory - o.a.t.s.context.MyPolicyContextFactory;context=o.a.t.s.context.MyPolicyContext For the @Context visitor we could then look at the type of the injected context and compare against registered context types before creating and injector (currently it only allows Compoent/RequestContext) For the Message we could then adjust the interface to be something like MapString, Object getHeaders(); // retains this to hold message protocol headers. Any existing code that uses it remains the same T T getContext(ClassT contextClass); // replaces getBindingContext() Hence when you need a particular context you do something like: MyPolicyContext context = message.getContext(MyPolicyContext.class); That should allows us include context extensibly in support of passing policy driven context to component implementations. If subsequently we want to connect context into a hierarchy that's great. Regards Simon Folks, I'd like to break this down into simple steps which address specific issues and functions, rather than considering some grand scheme. Small steps that each provide value. The first thing I'd like to consider is the way in which Context is passed to the application code - and in particular where binding implementation / interceptor extensions can use the Context mechanism to pass (arbitrary) data to the application code - and vice-versa. Currently, there are 2 pieces of Context available to an application: - ComponentContext - RequestContext These can be retrieved either via injection controlled by @ComponentContext and @RequestContext, or via the API with explicit get..() calls. Of these two, perhaps the most important is the RequestContext, although the principles can apply equally to ComponentContext. My thinking is that when requested to supply RequestContext to the application, that Tuscany supplies not the formal OASIS-defined RequestContext, but a subclass - TuscanyRequestContext. I think that the simplest approach to TuscanyRequestContext that is still general is to add a single map-style method to get additional context information, based on the use of a key that is a string: Object getExtendedContext( String contextName ); ...for code within Tuscany there would be an equivalent setter method: void setExtendedContext( String contextName, Object ); If we prefer something more typesafe, we can use Generic versions of these methods: T getExtendedContextT( String contextName ); (etc) What I prefer about this approach is that it is still possible to write application code that is portable through the use of instanceof - avoiding the need for the application to have things like Tuscany annotations in the code. Yours, Mike. PS Next I think we should look at context information being passed from the application code to the code involved in a reference invocation...
Re: Rename binding-ws-runtime-axis2 to binding-ws-runtime
On 12/07/2011 21:44, Raymond Feng wrote: Don't we prefer to use a JAX-WS based implementation as the default binding-ws-runtime? Thanks, Raymond / Folks, No problem with the renaming - but as for preferring the JAX-WS impl, I don't agree with that - the Axis binding implementation is the complete one at the moment - and is very much the route for the various policy options including security and reliable messaging. Why would a JAX-WS implementation be a better way to go? Yours, Mike.
[2.x] Problems and Proposed changes for the OASIS Java Client API
Folks, I understand that there are some problems with the standard OASIS Java Client API that are affecting Tuscany. I'd be grateful if people who know about these problems could list the problems and the proposed fixes - there is a short window of opportunity to get the OASIS code updated, if the problems and the fixes can be fully described. Yours, Mike.
Re: How can we do a next 2.x release?
Folks, I'd like to see us do a full 2.x release - not another Beta. 2.x has been around for a while and it's in pretty good shape. A full release is called for in my opinion. If some samples aren't of the right quality, then leave them out for now - they can be added back later once they are in acceptable shape. Yours, Mike. On 13/07/2011 09:15, Simon Laws wrote: On Wed, Jul 13, 2011 at 4:17 AM, Luciano Resendeluckbr1...@gmail.com wrote: On Tue, Jul 12, 2011 at 3:16 PM, ant elderantel...@apache.org wrote: On Tue, Jul 12, 2011 at 10:30 PM, Luciano Resendeluckbr1...@gmail.com wrote: On Tue, Jul 12, 2011 at 12:54 PM, ant elderant.el...@gmail.com wrote: I've been trying to help a user get going with one of the samples using the latest code but its ended up needing a bunch of change to the sample pom.xml's to get it to work with the latest snapshot code. One of the issues is if you checkout a sample like https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/samples/getting-started/helloworld/ and try to build it that doesn't work unless you've built trunk locally. So, wouldn't this be a similar issue if you get a released version of the helloworld with a released version of tuscany compared to the most recent snapshots ? But thats just one of the reasons, its been ages since we did a trunk release and there are lots of good changes in there. Last time we talked about this I couldn't find three people who said they'd vote for a release, If i just cut an RC of what the trunk builds now i expect there are a lot of broken samples missing doc and and incorrect readme's so whats the minimum we could do to fix that which would get three +1s? If i just did a trunk source release + maven module release but no binary distro would anyone vote for that? Or if i stripped out all the samples or maybe except for one or two samples which really worked and had good READMEs would you vote for that? Or what else would it take? ...ant What would be the version name for the release ? I think we should do a regular milestone/beta release and I'd be ok if some samples might be broken, but I wouldn't like to see source only distros, as that would kind require the users to have to build anyway, unless they are using maven which it's not really a requirement we have imposed into users before. Ok thats sounding more promising, i don't mind not doing a source only release i just want _a_ release with the module jars in maven central, i don't mind what its called 2.0-Beta3 or M6 or something else. So how about if its called 2.0-Beta3 and based off the current trunk so the samples and distro are as they are. I'll try and clean up some helloworld samples but i wont have the time to make all of the samples perfect. ...ant What's the timeframe you are looking for ? I could look at some samples and other minor cleanups over the weekend. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ I can try and take a look through the samples over the next couple of days and do some tidying. Simon
Re: Compile error in trunk sca-java-2.x
Nirmal,
I did an Update followed by a full build this morning and I don't see this error - the build works
fine for me, with only a couple of known test failures relating to some Policy function that is
under development.
Yours, Mike.
On 02/07/2011 08:35, Nirmal Fernando wrote:
Hi,
FYI: I tried building the trunk, it failed with following error.
[INFO]
[INFO] Building Apache Tuscany SCA iTest Base
[INFO]task-segment: [compile]
[INFO]
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] [remote-resources:process {execution: default}]
[INFO]
[INFO] Building Apache Tuscany SCA iTest Base Dependencies
[INFO]task-segment: [compile]
[INFO]
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/base/dependencies/src/main/resources
[INFO] Copying 0 resource
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] No sources to compile
[INFO] [dependency:copy-dependencies {execution: copy}]
[INFO] Copying classes to
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/base/dependencies/target/dependency/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error copying artifact from
/media/798D-18B1/GSoC-2011/Tuscany/trunk/modules/assembly/target/classes to
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/base/dependencies/target/dependency/classes
Embedded error:
/media/798D-18B1/GSoC-2011/Tuscany/trunk/modules/assembly/target/classes (Is a
directory)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error copying artifact
from
/media/798D-18B1/GSoC-2011/Tuscany/trunk/modules/assembly/target/classes to
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/base/dependencies/target/dependency/classes
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error copying
artifact from
/media/798D-18B1/GSoC-2011/Tuscany/trunk/modules/assembly/target/classes to
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/base/dependencies/target/dependency/classes
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.copyFile(AbstractDependencyMojo.java:194)
at
org.apache.maven.plugin.dependency.CopyDependenciesMojo.copyArtifact(CopyDependenciesMojo.java:186)
at
org.apache.maven.plugin.dependency.CopyDependenciesMojo.execute(CopyDependenciesMojo.java:85)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.io.FileNotFoundException:
/media/798D-18B1/GSoC-2011/Tuscany/trunk/modules/assembly/target/classes (Is a
Re: Compile error in trunk sca-java-2.x
On 04/07/2011 14:31, Nirmal Fernando wrote: Did I make a mistake by running mvn compile before mvn install? I tried to run mvn install, it ran out of java heap memory. :( Nirmal, You need to adjust the Maven OPTS for the Java heap size, as described here: http://tuscany.apache.org/tuscany-sca-java-faq.html#TuscanySCAJava-FAQ-BuildD Simply put - set the MAVEN_OPTS environment variable to a value something like this: MAVEN_OPTS=-Xms256m -Xmx1024m -XX:MaxPermSize=350m Yours, Mike.
Re: Compile error in trunk sca-java-2.x
Nirmal,
On my machine, that testcase works fine for me - I do not see the error that
you see.
My local copy was updated ~3 hours ago and I am not missing any recent changes relating to that
testcase.
I am running on Windows XP.
Yours, Mike.
On 04/07/2011 16:00, Nirmal Fernando wrote:
mvn install on trunk fails with :
[INFO]
[INFO] Building Apache Tuscany SCA iTest WS Contribution RPC Lit
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] [build-helper:add-test-source {execution: add-source}]
[INFO] Test Source directory:
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/ws/contribution-rpc-lit/target/jaxws-source
added.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 7 resources
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] [jaxws:wsimport {execution: wsimport1}]
[INFO] Processing:
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/ws/contribution-rpc-lit/target/classes/helloworld-external-service.wsdl
[INFO] jaxws:wsimport args: [-s,
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/ws/contribution-rpc-lit/target/jaxws-source,
-d,
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/ws/contribution-rpc-lit/target/classes,
-verbose, -p, org.apache.tuscany.sca.binding.ws.jaxws.external.service.iface,
-target, 2.1,
-Xnocompile,
/media/798D-18B1/GSoC-2011/Tuscany/trunk/testing/itest/ws/contribution-rpc-lit/target/classes/helloworld-external-service.wsdl]
parsing WSDL...
[INFO]
[ERROR] BUILD ERROR
[INFO]
org.codehaus.classworlds.NoSuchRealmException: plexus.core
at org.codehaus.classworlds.ClassWorld.getRealm(ClassWorld.java:128)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:434)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
Best Regards,
Nirmal
C.S.Nirmal J. Fernando
Department of Computer Science Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.
Blog: http://nirmalfdo.blogspot.com/
Re: [VOTE] Release Tuscany Bundle Plugin 1.0.8 RC1
Ant, The lack of documentation is the reason I will not vote in favour of this. Having done releases without documentation before is no justification in my opinion. How is anyone supposed to learn how to use something if there is no documentation? I'll be happy to help create documentation, but since I am not an expert in this plugin, I don't know what to write. Yours, Mike. On 27/06/2011 10:58, ant elder wrote: No i couldn't because i don't think there is any, and i don't particularly want to have to go write any, does anyone else want to volunteer? We've done half a dozen releases of the plugin before and haven't had to have doc so why should that block this release now especially when we know if we don't do this release its going to end up breaking the Tuscany build. ...ant On Mon, Jun 27, 2011 at 10:44 AM, Florian Mogamoga@gmail.com wrote: Some documentation would definitely help me. Could you point me some resources? Thanks. On Mon, Jun 27, 2011 at 12:31 PM, ant elderant.el...@gmail.com wrote: Any votes? Tuscany will become unbuildable if we don't release this to fix the naming issue in TUSCANY-3861. Is there anything we can do to help get votes for releasing this? ...ant On Tue, Jun 21, 2011 at 7:47 AM, ant elderant.el...@gmail.com wrote: Please vote on releasing the Tuscany Bundle Plugin module 1.0.8 (RC1). The change over the 1.0.7 release is to rename the module from maven-bundle-plugin to tuscany-bundle-plugin, see TUSCANY-3861. The tag for the release is: https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/tuscany-bundle-plugin-1.0.8 The Maven staging repository is: http://people.apache.org/~antelder/tuscany/tuscany-bundle-plugin-1.0.8-RC1 +1 from me. ...ant
Re: where to put a (2.x) two-Contribution test of binding-sca-runtime?
Scott, I think that it is best if you put the sources of the Contributions into some separate modules that are built separately to create Contribution ZIPs that are then used as dependencies by the tests. This is effectively what we do in the OASIS testcases, where there are loads of Contribution ZIPs that are then used by the testcases thenmselves. You must be able to see how the Contributions are built from sources - and be able to change the Contributions in the case where errors or updates need dealing with. This may even be desirable from a test perspective in that sharing of contributions between different testcases may be possible, reducing the overall pile of materials - this too is done in the OASIS tests and makes a big impact on the number of artifacts required, especially in the Assembly testcases. Yours, Mike. PS. Don't feel inhibited to beg steal or borrow any of the OASIS materials. They can be freely reused and contain some entertaining artifacts at the level of both Composites and Implementations. On 23/06/2011 16:54, Scott Kurz wrote: Quick question: I noticed a bug on the path used by binding-sca-runtime when doing a cross-classloader (e.g. cross-Contribution) copy. Not sure how important it is to people to keep the tests structured relatively simply... I'm thinking I'll add the test to the binding-sca-runtime module and just check-in a couple contribution JARs as source, since that's easier to me than trying to build/copy/package things in two JARs. (I see some modules e.g. 'contribution' checking in JARs as source). Kind of ugly not to have the Java as source though... Does anyone have a better suggestion on where to add a test for this case? Thanks, Scott
[jira] [Commented] (TUSCANY-3877) Policy appliesTo processing doesn't match the approach we now have of aggregating policy on endpoints/endpointreferences
[ https://issues.apache.org/jira/browse/TUSCANY-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050964#comment-13050964 ] Mike Edwards commented on TUSCANY-3877: --- I think that the key material is in section 4.15: 1208 3. remove any policySet where the policySet does not apply to the target element. 1209 It is not an error for a policySet to be attached to an element to which it doesn’t apply. So, no policySet gets used on a binding or on an implementation unless @appliesTo for that policySet includes that binding or implementation. So there is no push down in that sense. Ancestor policySets are gathered for consideration for a given binding or implementation (there is push down in that sense) but if they dont apply to the element under consideration, they are ignored. As it says here: 391 Rather, policySets always apply to either binding instances or implementation elements regardless of 392 where they are attached. PolicySets are applied either to bindings or to implementations - they have no use anywhere else - so a policySet saying @appliesTo=//service (say) is going to get left on the floor. Policy appliesTo processing doesn't match the approach we now have of aggregating policy on endpoints/endpointreferences Key: TUSCANY-3877 URL: https://issues.apache.org/jira/browse/TUSCANY-3877 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-M5 Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 There are two issues with the current appliesTo processing in PolicyAppliesToBuilderImpl 1/ For each element that holds a policy set it calculates the appliesTo nodes and checks that the current element is in the set. If not the policySet is removed from the element. The problem here is that it's checking the reference, service and binding nodes when it should be checking the endpoint and endpointreference nodes which hold the aggregated set of policy sets at this point 2/ The spec says. The 400 policySet will apply to any child binding or implementation elements returned from the expression. So, for 401 example, appliesTo=//binding.ws will match any web service binding. If 402 appliesTo=//binding.ws[@impl='axis'] then the policySet would apply only to web service bindings that 403 have an @impl attribute with a value of 'axis'. Is not clear here if a policy set can appliesTo a service, reference or component element, rather than a binding or implementation element, in the expectation that it will be pushed down to the children. I can understand this being the case for attachTo but I don't understand why that would be needed for appliesTo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tuscany Zip Plugin Alpha3 RC2
Ant, Why is this famed README not in either of the jar files: tuscany-zip-plugin-alpha3.jar tuscany-zip-plugin-alpha3-sources.jar Yours, Mike. On 17/06/2011 11:32, ant elder wrote: The most comprehensive doc is in the README file, IIRC thats mostly written by your good self Mike. ...ant
Re: Tuscany Meetup in London
On 04/03/2011 13:46, Simon Nash wrote: Who is planning to attend this meeting? Simon Folks, Sorry, but a couple of customer related meetings mean that I shall not be able to make the London meetup. Yours, Mike.
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
On 28/02/2011 09:58, ant elder wrote: snip It might be worth looking at what the binary distribution is actually for though, perhaps not in this thread so it doesn't bog down the sample discussion. The binary distribution isn't used by any of the Maven builds of the samples or running them. ...ant Folks, For me that IS one of the problems - ie having to use Maven to run a sample. In my opinion, the binary distribution should be available for those folks who want to use Tuscany - and the samples should show them a way to do this without requiring them to use Maven, which is a build tool that not everyone is used to using. Yours, Mike.
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
On 24/02/2011 14:28, Florian Moga wrote: I was thinking that if we use blogging as the primary way of describing samples, it's not even necessary to include a README in each and every sample, people can just search the blog knowing that information will be there (I'm trying to keep things as simple and interactive as possible -- to be honest, in most of the cases, I for one, am not checking the README files not even when I was first starting to look at Tuscany. They are hard to maintain and get out-dated quite easily). One other advantage of blogging would be that comments containing questions and issues to which we'll respond will remain visible for everybody who's checking them out. When a user asks for clarification about a sample, I'm pretty sure we currently don't update the README to cover that. I'm just saying that it might help us be more open to our users, their needs, receive feedback from them and simplify maintainability (a blog post can always be edited or deleted and rewritten if major changes are done). IMO, this will improve the promotion of Tuscany especially with 2.0 approaching and help keep a better contact with users. Imagine that you're doing a nifty improvement on a module and update the sample. Nobody is checking the READMEs, a blog post is out there notifying people. I agree the distribution should have some kind of documentation on samples, I'm thinking that there should be a way of exporting the blog posts to a pdf format with a nice template which we can place in the samples/ directory right before doing a release (this way we don't end up with out dated information). There are a number of open source projects which have dedicated websites for samples, most of which I've seen are web frameworks (e.g Apache Wicket). It's not our case but I think we can do something similar and gain the benefits. Florian, I'm not against blogging, but there must be a description of how to run each sample contained in the distribution along with each sample. There is nothing worse for a newbie than getting a distribution with samples only to find that there is nothing telling them how to run the samples to see what it takes to run an application with that runtime. In my opinion, there should be readme material in the samples directories - that material can point to blogs, but it should be possible to use the samples without ever seeing the blogs. Yours, Mike.
Re: 2.0 binary distribution - was: Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
Folks, Comments inline... On 28/02/2011 11:40, Simon Laws wrote: I was initially assuming that we would retain a way for users to (re-)compile sample contributions from the source provided in the binary distribution. The complicating factor in these conversations seems to be Maven as it leads to a situation where you download the binary distribution, compile the samples with maven and it downloads all the jars again. Maybe we shouldn't look to Maven for sample support. Maybe we should only allow people to recompile samples from the source distribution but this feels inconvenient as samples without source seems to be missing the point. +1 - people should not have to build from the source to use Tuscany - neither should they be forced to use Maven. We could go the other way and do away with the jars we ship with the binary distro and rely more heavily on Maven. I don't really support this approach. Shipping a self contained binary distribution at least gives us some confidence that it will work in six months time. I don't have this level of confidence when using Maven. I recognize that there has been discussion of shipping the jars formatted as a local repo to address this. -1 for removing the binary distro and forcing the use of Maven. But you ask a good question. What is the binary distribution for? Three thoughts that immediately come to mind: 1 - A quick start for new users for running samples without the need to compile anything +1 2 - A vehicle for shipping all the dependencies require by users or embedders of the Tuscany runtime without the need to use Maven to extract them. +1 3 - An environment were we can reasonably expect other run/build-time environments such as OSGi and Ant to function correctly. +1 I'm thinking that If we could make our distribution/sample/osgi story more accurately/consistently reflect the base + extension story I think the binary proposition, and hence the samples, would be clearer. Regards Simon
Re: Spring beans xml sca namespace
On 23/02/2011 13:13, ant elder wrote: The current Tuscanyimplementation.spring code is still using the old OSOA namespace for the sca extensions to the Spring context files. As FYI I plan to update that shortly in trunk, which does mean any existing sca spring applications would need updating if they're using the SCA extensions. ...ant +1 - this does need doing. I assume that this is a 2.x statement and that 1.x will remain unchanged? Do you need help with the 2.x changes? Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
On 14/02/2011 09:11, ant elder wrote: On Sun, Feb 13, 2011 at 7:43 AM, Florian Mogamoga@gmail.com wrote: Please review and vote on RC3 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~fmoga/tuscany/2.0-beta2-RC3/ The release tag is at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC3/ Florian This looks good to me so +1. A couple of issues: - I couldn't find your signing key in a public key server, have you uploaded it anywhere? - there are some testing artifacts in the staging repo we don't really need and which could be deleted - the ones from distribution\tomcat\testing, you could just delete them from the staging repo now. We should move those to be under testing/itest really. Otherwise all looks fine. ...ant Folks, My belated +1 - I only got around to trying it out over the weekend. Thanks for the improvements in the basic samples. At least now there is a set of simple instructions that work for the novice to get the hello world type applications running. Yours, Mike.
Status of binding-atom-js-dojo, binding-jsonrpc-js-dojo, binding-rest-js-dojo
Folks, What is the status of these 3 modules in 2.x please? It looks like their contents have been merged into other modules - shouldn't these modules be deleted? Yours, Mike.
Re: Tuscany Meetup in London
On 14/02/2011 10:29, ant elder wrote: Ok it sounds like this is going to happen on the 7th, where shall we do it? If there are no other suggestions I could try to see if there are any rooms available at IBM Southbank. ...ant Ant, You may well find Southbank difficult at the moment as they are refurbishing all the public meeting rooms - I tried to arrange a meeting there for 21 Feb and could not get anything. Yours, Mike.
Re: 2.x - moving SCABindingMapper
On 10/02/2011 12:15, Simon Laws wrote: I'd like to move the SCABindingMapper interface from binding-sca-runtime / org.apache.tuscany.sca.binding.sca.provider to somewhere like. core-spi / org.apache.tuscany.sca.provider So that people wanting to implement a default binding mapper don't have to have a dependency on a runtime module. Anyone see any issues? Simon Simon, +1 from me There are a few more of this ilk that it would be nice to get around to as well. Yours, Mike.
Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module
On 07/02/2011 10:56, Florian Moga wrote: On Mon, Feb 7, 2011 at 12:43 PM, Simon Laws simonsl...@googlemail.com mailto:simonsl...@googlemail.com wrote: So when you do a full build the build always hangs? Yes. Is that test still in the build as I don't experience that. Yes. What environment are you on? Ubuntu 10.10, Sun JVM 6u22, Maven 2.2.1, Ant 1.7.1 Same happens with OpenJDK Simon -- Apache Tuscany committer: tuscany.apache.org http://tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com http://tuscanyinaction.com Florian, My experience with this testcase is that it fails with a hang on an intermittent basis, relatively infrequently. I am running on Windows XP with Sun JDK 1.6.0_22. I looked into reports of hangs relating to the RMI code and there are reports of such hangs if the RMI Registry is not released correctly when stopping it. RMI uses a pile of threads and can have connections open between Client and Server side that need to be properly closed. A thread dump when the hang occurs does show an RMI thread waiting on some kind of lock, but I am not able to make much sense of what is going on. I suspect that the place to start looking is in the RMIHost code - and in the stop() method of DefaultRMIHost... Yours, Mike.
Re: [DISCUSS] SCA AllowsPassByReference spec clarification
On 09/02/2011 10:56, Simon Nash wrote: On interesting idea (taking up the theme of @RequiresPassByValue) would to require @AllowsPassByReference to always be present (specifying true or false) on every service method and every reference. That would force developers to think about the issue and explicitly state their intentions. It would make Hello World rather ugly, though :-( Simon Yuk !! Yours, Mike.
Re: [DISCUSS] SCA AllowsPassByReference spec clarification
On 08/02/2011 10:08, ant elder wrote: On Tue, Feb 8, 2011 at 9:56 AM, Simon Lawssimonsl...@googlemail.com wrote: I can see that relaxing the current spec restrictiveness would be difficult as things would break in some circumstances, but it does seem like there will be situations when the assembler really knows it would be fine but even so they can't get the PBR optimization because the impls aren't coded with the @AllowsPassByReference annotation. Isn't that a similar situation to where the remotable annotation was added to the interface SCDL element, and there could be a similar allowsPassByReference attribute added to the service and reference SCDL elements? ...ant Hi Ant. Can you say a bit more about the situations when the assembler really knows it would be fine? Reading previous posts to this thread doesn't convince me that that is the case. Simon We'll have to wait for Raymond to see if thats anything like his situation, but there are lots of ways the assembler could know, he may well have full access to the source but still be limited in making any updates due to production lifecycle or control issues. This seems like a similar situation as Java EE appservers have and I believe many appservers have mechanisims for overriding and enabling PBR support in their ORB or EJB modules to gain performance benefits. ...ant Folks, One possibility to start with would be to add a Tuscany extension attribute which could be used by an Assembler to mark a particular service and/or reference as AllowsPassByReference. This would cope with the situation where the Java components are not marked, but the assembler knows enough about them to know that the marking is correct. Yours, Mike.
Re: [DISCUSS] SCA AllowsPassByReference spec clarification
On 08/02/2011 11:17, Simon Nash wrote: I'm very dubious about the wisdom of this. I bear the scars from a previous life of a situation where a flag was added to an enterprise application server (which shall remain nameless) to override the PBV semantics required by the architecture in the interests of performance optimization when the user of the product knew that using PBR would be safe. Needless to say, on a number of occasions this flag was set incorrectly and this resulted in accusations of runtime bugs that were eventually shown after laborious debugging to have been caused by the PBR optimization being enabled incorrectly. IMO it's the implementation's responsibility to make the correct assertions about whether it's PBR-safe. Implementations that don't assert @AllowsPassByReference will have worse performance than those that do support it. If a component developer cares about performance, they need to code their implementation to play by the APBR rules and turn on the flag to say they have done that. If the flag isn't turned on by the implementer, I can't imagine that an assembler will have a detailed enough knowledge of the implementation to be able to safely provide the APBR assertion that the component developer couldn't/ wouldn't/didn't provide. (Deep breath) Now I feel better after getting that off my chest :-) Simon Simon, I sympathise with your viewpoint. It is far better if the Java code itself asserts its cleanliness. My suggestion was not made with any conviction. Yours, Mike.
Re: [DISCUSS] SCA AllowsPassByReference spec clarification
On 08/02/2011 14:12, Simon Nash wrote: Actually in its first incarnation the force PBR override setting was a global flag that applied to the whole runtime, was set on by default, and was poorly documented. (Hard to believe, I know.) After some lobbying from myself the default was changed to off and the documentation was improved, but people still saw it as a go faster flag and turned it on when they shouldn't have done. Eventually it was made more granular instead of a global thing and that helped some more. But the lessons I learned were that 1) users experiencing performance problems will reach for any magic go-faster switch and ignore all health warnings, and 2) when it doesn't work they'll report it as a runtime bug. Simon Folks, I think the nasty feature here is that IF the Java code on either side does the wrong thing and is not clean wrt PBR, the bugs that result may be intermittent and somewhat hard to diagnose, since they may well involve race conditions. Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2
On 05/02/2011 09:51, Florian MOGA wrote: Thank you for the information Ant. I was wondering more about the checks each developer is doing before voting a +1. I'd like to choose a set of checks to perform myself when a vote is called but I can't think of tests other than the ones that I stated earlier... Florian, My approach is first to examine the binary release - install it and try to run things - in particular the samples. Samples not working out of the box always concerns me since this will usually form the experience of someone new to Tuscany and if it does not work cleanly and as advertised that is a poor shop front for the project. There are also cleanliness things like the legal stuff to check over (eg licenses). After probing the binary release, I move on to the source release and try building that from scratch with an empty repo. Given my OASIS background, I am also hot on ensuring that the build passes the conformance tests... Yours, Mike.
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
On 07/02/2011 12:05, ant elder wrote: On Mon, Feb 7, 2011 at 8:51 AM, Simon Nashn...@apache.org wrote: snip I think we're in violent agreement here! Let's pick a small and useful set of high-quality samples to include in the release, then make sure (by automated tests as far as possible) that these samples continue to work in future releases. All other samples would go somewhere else in svn (unreleased/samples?) which would be much more of a mixed bag. Newly created samples would be added to the mixed bag. In future major releases, we could (if we want to) take carefully chosen samples out of the mixed bag and promote them to be added to the release. The reverse is also possible, where we could retire a released sample that no longer seems to be serving much of a useful purpose, by moving it from the released samples to the mixed bag. Simon I see, ok well i guess i'd be willing to give that a try. We've not been very good at finding consensus in the past which is one of the reasons we've ended up with this anyone can do anything approach so i can see there may be problems, but it will be an interesting experiment. ...ant Folks, Let me make a proposal that we can implement right now for Beta2. Remove all samples from the build EXCEPT for the following, which we make work out of the box: getting-started\helloworld-contribution getting-started\helloworld-webapp I think that for the moment, we can put in an HTML file which then points at all the other samples, but back in the repo, with a brief explanation as to what they do and what they show. Over time, we can add back more samples into the build, but only once they are brought up to scratch. Something we need to concentrate on is to make sure that any documentation is correct and especially any suggested ways of running the samples actually work - at the moment, the READMEs for the helloworld samples simply don't work if you follow the instructions in the READMEs. I think that this minimal approach allows us to make quick progress while improving the experience for end users. Yours, Mike.
Re: Tuscany Meetup in London
On 04/02/2011 15:47, ant elder wrote: On Fri, Feb 4, 2011 at 12:46 PM, Florian MOGAmoga@gmail.com wrote: Hi, I'm planning to volunteer at QCon London next month in order to be able to attend the sessions and tutorials. The conference and tutorials take place between 7-11 March. It would be great if we can have a Tuscany meetup (pub meeting or hacking session) in one of the two adjacent weekends (maybe 6th of March?). Looking forward to your feedback. Florian I'm in London and free around then so would be happy to meet up. Would be good if any of the other committers who are not so far from here could come along (Simon/Simon/Mike?), something like a hacking session to clean things up for the 2.0 release would be good. ...ant Folks, A meetup would be great - but I'd prefer a weekday to a weekend - I will get some heat from the boss if I try to use up another precious weekend day for doing programming stuff. Any chance that we could meet on one of those days - 7th - 11th ? Any idea on a good venue? Ideally, we'd want somewhere not too noisy and with good conectivity. IBM South Bank occurred to me, but I know that they are rebuilding the public meeting rooms there which makes find a slot hard at the moment... Yours, Mike.
Re: [DISCUSS] Tuscany website on CMS?
On 07/02/2011 15:09, Simon Laws wrote: An idle question somewhat motivated by recently touching on the sample docs in another ML thread. Are we going to convert from Confluence to CMS [1]? If we are eventually going to have to do this (when the autoexport stops working?) we should probably plan for it rather than do it in a rush when we are forced to. I haven't looked very closely at the details. Anybody given it any thought yet? I note there are notes on migration [2] [1] http://www.staging.apache.org/dev/cms.html [2] https://svn.apache.org/repos/infra/websites/cms/conversion-utilities/cwiki/README.txt Simon Simon, Good to bring this up. However, looking at the material, my heart sinks :-( For me, the key thing has to be the ease of creating and maintaining the material. Using some markup language is ok, but what tools are us poor content creators supposed to use? In see this in the Apache material at [1]: Editing the source in the CMS's webgui relies on the wmd-editor to provide a WYSIWYM look and feel to the CMS. ...only to find that the link they provide to wmd-editor is broken. A very poor start. I checked out some alternative editors and I'm not impressed so far. Things I would like to see are: a) How hyperlinks are created and how they are maintained b) How images/diagrams can be embedded in pages c) How basic page layout is managed - in particular the handling of Menus, banners and so on It is notable how little graphics is contained in the Apache pages for [1] and [2] - are we returning to the stone age here? I get the feeling that this system has been produced for the ease of the publishing process, rather than the creation and maintenance of attractive material. Please someone prove me wrong. Yours, Mike.
[jira] Closed: (TUSCANY-3817) Tuscany fails OASIS Java CAA Testcases 10029 10030
[ https://issues.apache.org/jira/browse/TUSCANY-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards closed TUSCANY-3817. - Tuscany fails OASIS Java CAA Testcases 10029 10030 - Key: TUSCANY-3817 URL: https://issues.apache.org/jira/browse/TUSCANY-3817 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x Tuscany fails OASIS Java CAA testcases 10029 10030, which concern detection of @Remotable annotations in invalid locations within a Java interface. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-3816) iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards closed TUSCANY-3816. - iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks Key: TUSCANY-3816 URL: https://issues.apache.org/jira/browse/TUSCANY-3816 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x The iTest Callback SeparateThread has a component implementation EventProcessorServiceImpl.java which is @Scope(COMPOSITE) and which has a field annotated with @Callback. This violates one of the conformance requirements of the OASIS Java CAA specification, which does not permit the use of the @Callback annotation for COMPOSITE scope components. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-3831) Tuscany fails OASIS compliance test BWS_2016
Tuscany fails OASIS compliance test BWS_2016 Key: TUSCANY-3831 URL: https://issues.apache.org/jira/browse/TUSCANY-3831 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-2.x Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x Tuscany fails testcase BWS_2016. Basically, this test has a binding.ws element with a non-existent WSDL file referenced via a wsdli attribute. The test is expecting a failure with an exception that spots that the WSDL file does not exist. Instead, the code fails with a NullPointerException - clearly not correct. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-3831) Tuscany fails OASIS compliance test BWS_2016
[ https://issues.apache.org/jira/browse/TUSCANY-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12990080#comment-12990080 ] Mike Edwards commented on TUSCANY-3831: --- The problem arises from the WSDLModelResolver in interface-wsdl. The method loadDefinition(...) has code that deals with the case where the WSDL is referenced via a wsdli attribute - and in this case computes a URL for the artifact from the wsdli value. However, at a point further down the method, the code attempts to access the WSDL file, not using the computed URL, but using a location value from the WSDL definition structure - which only has a value IF the WSDL has been loaded from a file contained within a contribution - which is NOT the case in this test (the test is deliberately using a URL which does not point to a file anywhere in any contribution...) MapString, String wsdlImports = indexRead(wsdlDef.getLocation().toURL()); getLocation() returns NULL and this is the source of the NPE The code should instead use the computed URL - which is derived from the wsdli value, if specified, or from the getLocation() value if there is no wsdli value (and note: if both wsdli getLocation() are NULL, the code deal with the situation): MapString, String wsdlImports = indexRead(artifactURL); This version of the code committed in: 1066801 Tuscany fails OASIS compliance test BWS_2016 Key: TUSCANY-3831 URL: https://issues.apache.org/jira/browse/TUSCANY-3831 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-2.x Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x Tuscany fails testcase BWS_2016. Basically, this test has a binding.ws element with a non-existent WSDL file referenced via a wsdli attribute. The test is expecting a failure with an exception that spots that the WSDL file does not exist. Instead, the code fails with a NullPointerException - clearly not correct. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2
On 02/02/2011 18:30, ant elder wrote: On Wed, Feb 2, 2011 at 9:43 AM, Mike Edwards mike.edwards.inglen...@gmail.com wrote: On 02/02/2011 09:04, ant elder wrote: I'll guess that Raymond will want to get the pass-by-reference improvements into this release so what ever happens we'll need to respin to pick those up, what else needs to get done for that respin? Do we need to make further sample improvements right now or can that be done over later releases? Florian - have you found why that itest is using the wrong directory in your environment? Mike - I'm hoping the dom4j issue will go away if it uses the version in the central repo, but what about the sample running issues you first mentioned, do they sound like the same as this issue thats just come up with the beta1 samples - http://apache.markmail.org/message/jzu3c2ixbcqwbie7 ...ant Ant, 1) dom4j issue This is a real issue and there is a fix. The dom4j POM is coming from the intalio repo and this is FORCED by a repository setting in the POM of implementation-bpel-runtime - if you start with a clean repo you WILL get the bad dom4j POM: repositories repository idintalio.org/id urlhttp://www.intalio.org/public/maven2/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories The fix is simply to remove thisrepository setting from the POM of implementation-bpel-runtime. The problem with that is that the reason that repository was there was to get the saxon artifacts so with out it those now aren't found. I'll go have a hunt around and see if there is anywhere else we could use for saxon, otherwise i guess we can add it to the tuscany svn repo. ...ant Ant, OK, works for me. There is ANOTHER problem with dependencies associated with OSGi that needs fixing too - it is in the dependencies for node-launcher-equinox. The impact means that the build does not work correctly under OSGi and that some tests fail. I've done a fix and committed it now. Related, there is a fix in the interface-wsdl module to ensure that Tuscany passes testcase BWS_2016 from OASIS (it was trying to fix THAT testcase that revealed the OSGi problems...). Yours, Mike.
[jira] Closed: (TUSCANY-3829) Test Failure whe building trunk - iTest WS Launcher Axis2 testscases all fail
[ https://issues.apache.org/jira/browse/TUSCANY-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards closed TUSCANY-3829. - Test Failure whe building trunk - iTest WS Launcher Axis2 testscases all fail - Key: TUSCANY-3829 URL: https://issues.apache.org/jira/browse/TUSCANY-3829 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-2.x Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x Running the iTests when building trunk results in all the tests in iTest WS Launcher failing. All test fail with a method not found fault for javax.xml.ws.Webfault.messageName( String ) It is notable that this is a jaxws API class and it is being called from an internal com.sun implementation class. This smacks strongly of a code level mismatch. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2
On 30/01/2011 10:08, ant elder wrote: Please review and vote on RC2 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~antelder/tuscany/2.0-beta2-RC2/ The release tag is at: http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC2 Here's my +1 ...ant Folks, At the moment, in this release, the basic samples don't work with the binary distribution. If you follow the instructions in the README, neither Ant nor Maven ways of running the samples such as getting-started\helloworld-contribution actually work. Currently, Maven fails because the layout of the POM files in the distribution does not match the expected layout in the POMs themselves. Meanwhile the Ant build.xml file is completely missing. I think that we need to fix things so that the samples work out of the box with the binary distribution. Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2
On 30/01/2011 10:08, ant elder wrote: Please review and vote on RC2 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~antelder/tuscany/2.0-beta2-RC2/ The release tag is at: http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC2 Here's my +1 ...ant I get a build test failure when I do a clean build of the source distribution. The failure is with the Legal Checks iTest The surefire output: /error system-errJars in distribution but not in LICENSE: [jaxme-api-0.3.jar] I checked the dependency tree for jaxme and it derives from implementation-bpel: [INFO] | +- org.apache.tuscany.sca:tuscany-implementation-bpel-runtime:jar:2.0-Beta2:compile [INFO] | | +- org.apache.ode:ode-bpel-epr:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-store:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-dao:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-dao-jpa:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-dao-jpa-ojpa-derby:zip:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-runtime:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-api:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-scheduler-simple:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-utils:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-compiler:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-schemas:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-obj:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-jacob:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-jacob-ap:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-agents:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-dao-hibernate:jar:1.3.2:compile [INFO] | | +- org.eclipse.equinox:common:jar:3.5.0-v20090520-1800:compile [INFO] | | +- commons-lang:commons-lang:jar:2.3:compile [INFO] | | +- commons-collections:commons-collections:jar:3.2:compile [INFO] | | +- org.apache.geronimo.modules:geronimo-kernel:jar:2.0.1:compile [INFO] | | +- org.apache.geronimo.components:geronimo-transaction:jar:2.1.4:compile [INFO] | | | +- org.slf4j:slf4j-api:jar:1.6.1:compile [INFO] | | | \- org.objectweb.howl:howl:jar:1.0.1-1:compile [INFO] | | +- org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile [INFO] | | +- org.apache.geronimo.specs:geronimo-jpa_3.0_spec:jar:1.1.1:compile [INFO] | | +- org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:2.0.0:compile [INFO] | | +- org.apache.geronimo.components:geronimo-connector:jar:2.1.4:compile [INFO] | | +- org.apache.derby:derby:jar:10.4.1.3:compile [INFO] | | +- tranql:tranql-connector:jar:1.1:compile [INFO] | | | \- regexp:regexp:jar:1.3:compile [INFO] | | +- org.apache.openjpa:openjpa:jar:1.2.1:compile [INFO] | | | \- commons-pool:commons-pool:jar:1.3:compile [INFO] | | +- net.sourceforge.serp:serp:jar:1.13.1:compile [INFO] | | +- jaxen:jaxen:jar:1.1.1:compile [INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile [INFO] | | | | \- jaxme:jaxme-api:jar:0.3:compile [INFO] | | | \- jdom:jdom:jar:1.0:compile Why this should pop up now I have no idea - presumably some 3rd party dependecncy has changed. Yours, Mike.
Re: Conversational state in 2.x
On 01/02/2011 13:12, Florian MOGA wrote: Hi, I'm currently working on multiple response support for the comet binding. I have an initial implementation but I'm using the thread context to store some internal state between forward and callback calls and this leads to some limitations. So I was thinking that something similar to @Conversational from Tuscany 1.x would improve scalabilty as storing state does not depend on the thread context anymore. To be more precise, for each client an object is created server-side and it has to be accessible from the Invoker when performing a callback call. At the moment, I'm passing this object through the bindingContext property of the Message. When performing the callback call, the callback message is built by copying most of the properties of the ThreadContext Message so I added a slight modification to the core which copies the bindingContext as well. If it's possible, I'd like to be more thread context independent and conversational scope seems to provide this thread-neutral client-specific storage space. It would also enable me to make async invocation of the service implementation. Could you point me out a way to achieve something similar to @Conversational in Tuscany 2.x? From Tuscany In Action I found out that conversations aren’t included in the SCA 1.1 specifications being defined by OASIS and will be reconsidered for a future version of SCA. They’re supported in the Tuscany SCA 1.x codebase but not in Tuscany 2.x. Thanks, Florian Florian, First, let's be clear that Conversational interactions were deliberately removed from SCA V1.1 by the OASIS spec group because of their complexity - and they were also removed from Tuscany 2.0 to match. However, I am not sure that Conversational is what you're really looking for. Let me play back what I think you're wanting. From what you say, the function that you're looking for is for the binding code (in the Comet binding in your case) to be able to store some binding-specific data on a forward request call that is then later accessed by the binding code when a callback is made to that original request. Logically, what you're really looking for is the capability for the binding to place some binding-specific data into the Callback object and for the binding code to be able to access this data at the point where the Callback object is invoked. And one thing to note about this is that the Callback object *might* be serialized between the initial request and the callback - PLUS it is very likely that a different thread will be used to do the callback - so that thread local stuff simply is not going to work. I've been doing this kind of thing for the async service support that has been added recently - and I noticed that the callback mechanism is nowhere near as powerful as the new async code. The async stuff has an internal object called the AsyncResponseInvoker that is used to carry data between the forward invocation and the response - and this includes binding-specific information. This object is also serializable and forms part of the serialization processes used by the service implementation. Currently, the callback processing does not use this approach - but I think that it should. I think that a similar CallbackInvoker should be created in the processing of the forward request - and that it should form part of the callback object state that is serializable. It should have the capability for the binding to insert and retrieve whatever information is required. Does this thinking hit the mark? Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2
On 01/02/2011 13:55, ant elder wrote: On Tue, Feb 1, 2011 at 1:43 PM, Mike Edwards mike.edwards.inglen...@gmail.com wrote: On 30/01/2011 10:08, ant elder wrote: Please review and vote on RC2 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~antelder/tuscany/2.0-beta2-RC2/ The release tag is at: http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC2 Here's my +1 ...ant I get a build test failure when I do a clean build of the source distribution. The failure is with the Legal Checks iTest The surefire output: /error system-errJars in distribution but not in LICENSE: [jaxme-api-0.3.jar] I checked the dependency tree for jaxme and it derives from implementation-bpel: [INFO] | +- org.apache.tuscany.sca:tuscany-implementation-bpel-runtime:jar:2.0-Beta2:compile [INFO] | | +- org.apache.ode:ode-bpel-epr:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-store:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-dao:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-dao-jpa:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-dao-jpa-ojpa-derby:zip:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-runtime:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-api:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-scheduler-simple:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-utils:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-compiler:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-schemas:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-bpel-obj:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-jacob:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-jacob-ap:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-agents:jar:1.3.2:compile [INFO] | | +- org.apache.ode:ode-dao-hibernate:jar:1.3.2:compile [INFO] | | +- org.eclipse.equinox:common:jar:3.5.0-v20090520-1800:compile [INFO] | | +- commons-lang:commons-lang:jar:2.3:compile [INFO] | | +- commons-collections:commons-collections:jar:3.2:compile [INFO] | | +- org.apache.geronimo.modules:geronimo-kernel:jar:2.0.1:compile [INFO] | | +- org.apache.geronimo.components:geronimo-transaction:jar:2.1.4:compile [INFO] | | | +- org.slf4j:slf4j-api:jar:1.6.1:compile [INFO] | | | \- org.objectweb.howl:howl:jar:1.0.1-1:compile [INFO] | | +- org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile [INFO] | | +- org.apache.geronimo.specs:geronimo-jpa_3.0_spec:jar:1.1.1:compile [INFO] | | +- org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:2.0.0:compile [INFO] | | +- org.apache.geronimo.components:geronimo-connector:jar:2.1.4:compile [INFO] | | +- org.apache.derby:derby:jar:10.4.1.3:compile [INFO] | | +- tranql:tranql-connector:jar:1.1:compile [INFO] | | | \- regexp:regexp:jar:1.3:compile [INFO] | | +- org.apache.openjpa:openjpa:jar:1.2.1:compile [INFO] | | | \- commons-pool:commons-pool:jar:1.3:compile [INFO] | | +- net.sourceforge.serp:serp:jar:1.13.1:compile [INFO] | | +- jaxen:jaxen:jar:1.1.1:compile [INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile [INFO] | | | | \- jaxme:jaxme-api:jar:0.3:compile [INFO] | | | \- jdom:jdom:jar:1.0:compile Why this should pop up now I have no idea - presumably some 3rd party dependecncy has changed. Jaxme is defined in the dom4j pom.xml as an optional dependency so it shouldn't be getting included, and it doesn't get included in my build of the distribution so the license itest passing cleanly. Its odd that jaxme is getting included in your build: - what version of Maven are you using? - there are no changes related to this that i can see between trunk/bete2, does jaxme show up in your trunk build? ...ant Ant, Maven is 2.2.0 Can't see it in my trunk build at the moment but I need to do a fresh build of that Yours, Mike.
Re: svn commit: r917777 - /tuscany/sca-java-2.x/trunk/modules/binding-sca-runtime/src/main/java/org/apache/tuscany/sca/binding/sca/provider/RuntimeSCAReferenceBindingProvider.java
On 01/02/2011 22:43, Luciano Resende wrote: This always assume PBV, which will cause extra and unnecessary transformation and degrade performance. Instead of hacking the core runtime, we should really look into the root cause of the issue and fix it. I'd rather really disable the conformance test. I'd rather really disable the conformance test. You've got to be joking !! Yours, Mike.
Re: AllowsPassByReference support
On 01/02/2011 22:53, Raymond Feng wrote: Hi, I would rather that we ignore the failing test cases with JIRA tickets so that we won't forget to fix it. Raymond, On that point, at this stage, I totally disagree. Fix the function so that it passes the tests BEFORE putting it back in. I will be very disappointed if I find more OASIS conformance tests failing... Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2
On 30/01/2011 10:08, ant elder wrote: Please review and vote on RC2 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~antelder/tuscany/2.0-beta2-RC2/ The release tag is at: http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC2 Here's my +1 ...ant Small warning folks. The link to the artifacts above does not work for me - I'm using the Chrome browser. The link above uses a lower case b in beta2 whereas the actual correct link name has a capital B: http://people.apache.org/~antelder/tuscany/2.0-Beta2-RC2/ The corrected form does work for me. Yours, Mike.
Re: Do Tuscany developers use FindBugs?
On 24/01/2011 18:13, César Couto wrote: Dear developers, I am a PhD student at UFMG, Brazil and as part of my research I am making a study about the relevance of the warnings reported by the FindBugs bug finding tool. Since I am planning to use Tuscany as a subject system in my research, I would like to know if Tuscany's developers usually run FindBugs as part of the system development process. Thanks in advance, Cesar Couto -- http://www.decom.cefetmg.br/cesar Cesar, Thinking about this further, I would like to point out that many of us use Eclipse when building and testing the code for Tuscany. Many of the basic static analysis items are dealt with by the code assist feature of Eclipse - and many of us rely on that without even thinking about it. Perhaps rather than having a separate tool like FindBugs it would be more interesting to investigate the possibility of extending the checking that Eclipse performs - Eclipse already does check some of the things that FindBugs checks, but not all of them. It would be far preferable to us Eclipse users to have static check done as we edit...then you absorb things without even thinking about them, which is often the most effective way. Yours, Mike.
Re: Do Tuscany developers use FindBugs?
On 26/01/2011 10:23, Mike Edwards wrote: On 24/01/2011 18:13, César Couto wrote: Dear developers, I am a PhD student at UFMG, Brazil and as part of my research I am making a study about the relevance of the warnings reported by the FindBugs bug finding tool. Since I am planning to use Tuscany as a subject system in my research, I would like to know if Tuscany's developers usually run FindBugs as part of the system development process. Thanks in advance, Cesar Couto -- http://www.decom.cefetmg.br/cesar Cesar, Thinking about this further, I would like to point out that many of us use Eclipse when building and testing the code for Tuscany. Many of the basic static analysis items are dealt with by the code assist feature of Eclipse - and many of us rely on that without even thinking about it. Perhaps rather than having a separate tool like FindBugs it would be more interesting to investigate the possibility of extending the checking that Eclipse performs - Eclipse already does check some of the things that FindBugs checks, but not all of them. It would be far preferable to us Eclipse users to have static check done as we edit...then you absorb things without even thinking about them, which is often the most effective way. Yours, Mike. I'll answer my own question here. There ARE additional code plugins for Eclipse, for example as discussed here: http://codedependents.com/2009/07/01/top-5-static-analysis-plugins-for-eclipse/ It might be good to ask why Eclipse don't include some of these out-of-the-box rather than requiring delelopers to go download install extra stuff I note that FindBugs is one of these plugins ;-) Yours, Mike.
Re: Do Tuscany developers use FindBugs?
On 24/01/2011 18:13, César Couto wrote: Dear developers, I am a PhD student at UFMG, Brazil and as part of my research I am making a study about the relevance of the warnings reported by the FindBugs bug finding tool. Since I am planning to use Tuscany as a subject system in my research, I would like to know if Tuscany's developers usually run FindBugs as part of the system development process. Thanks in advance, Cesar Couto -- http://www.decom.cefetmg.br/cesar Cesar, I can't speak for all Tuscany developers, but I can say that I don't use FindBugs and I am not aware of anyone who does. Our approach in Tuscany is more Test Driven Development, where the development process is led by the creation of testcases which are used to drive and check the development or modification of code. The advantage of this general approach is that we build up a set of testcases that are then used to validate all future changes in the codebase - and which quickly expose any problems caused by code modifications and code additions. The main problem with test driven development is in getting a sufficiently extensive set of testcases - some situations can be difficult to model (eg code running in multiple separate JVMs), plus there is the inevitable failure of imagination and/or foresight as to how the code will be used. Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2
On 23/01/2011 23:56, ant elder wrote: Please review and vote on RC1 of the Java SCA 2.0 Beta2 release. The artifacts are at: http://people.apache.org/~antelder/tuscany/2.0-beta2-RC1/ The release tag is at: http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta2-RC1 Here's my +1 ...ant Ant, We've been working hard on the code for async service handling - and there is clearly a version of that code in the RC1 candidate that you've built. However, we are still working to complete debugging of the code (particularly related to the serialization deserialization of the DispatchResponse and its contents). We'd appreciate it if the fixed version of the code could get into the beta2, rather than the version that's in RC1 at the moment. We need a couple of days to complete the work on async - and this work is getting in the way of us checking over the RC1 that you've prepared, which we'd like to do before taking any further steps on beta2. Yours, Mike.
Re: Do Tuscany developers use FindBugs?
On 25/01/2011 17:38, Luciano Resende wrote: On Tue, Jan 25, 2011 at 5:33 AM, dshdaniel.hais...@googlemail.com wrote: I would say TDD and static code analysis are complementary. Cheers Daniel Agree, I have been playing with Sonar, which provides various metrics and below you can find Tuscany 2.x (modules only) analysis. http://www.figueiredos.com:8080/sonar/project/index/195 Luciano, That link in your email does not seem to work. Spelling mistake? Yours, Mike
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
On 22/01/2011 14:25, ant elder wrote: The problem with doing that is that now the OASIS repo is also checked for every artifact when building online which could add significantly to the total build time. Looking at the current repository definitions i think most of those are old historical ones which we don't even need anymore so i'm going to have a go a cleaning them up. For the ones we do still need i think we should change to define them in the modules that actually require them instead of the top level pom.xml as that should avoid them being queried for irrelevant artifacts. Besides all that why does that itest need to be using the oasis version of the API's? The Tuscany version should work fine shouldn't it (i tried it, it seems to)? ...ant Ant, I think the boot is on the other foot. The SCA API jar is really one that belongs to OASIS - why does Tuscany have its own version of that jar, now that it is available from a Maven repo? I understand that Tuscany had to have its own API module historically, but why do that now? Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
On 20/01/2011 21:17, ant elder wrote: On Thu, Jan 20, 2011 at 9:10 PM, Scott Kurzscottk...@gmail.com wrote: I recreated that MediatorImpl.copyInput failure now... Maybe the problem was that earlier I ran offline and had something stale in my mvn repo??? Anyway..looking into both problems now.. What was a module you used to notice the 2nd problem with JavaInterfaceImpl.isAsyncServerOperation? One example is testing\itest\async-services ...ant Scott, Yes, Ant identifies cases that are still failing. I suspect that your interface handling changes don't account properly for Java interfaces that have the async server format, where a regular method like: String someOperation( Int input ) is mapped to this: void someOperationAsync( Int input, ResponseDispatchString response ) So far it looks like the type of the output parameter is being mapped incorrectly now - I see some instances where the output parameter has a type of idl:input associated with it rather than idl:output. The code that does this is a bit dense and I cannot pin it down yet. Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
On 20/01/2011 23:29, ant elder wrote: On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurzscottk...@gmail.com wrote: I just committed what I hope is a fix in r1061531. It made the copyInput IndexOutOfBoundsException in sample-implementation-extension go away... (will give some more thought to whether this fix to interface-wsdl is the best solution). I can't run that async-services test yet.. I need to update my mvn repo.. but I'm pretty confident my fix should work for that as well. That said..clearly my testing wasn't good enough if Mike's seeing failures all over the place.. so I'm doing some more careful testing now. Scott Thats fixed all the IndexOutOfBoundsException for me. I do still get other test fails in testing\itest\ws\holder-ws-service-multiple-outputs and testing\itest\async-services ...ant Folks, I think I have a fix for the async-services failures: for an interface with the async server format, the databinding applied to the response parameter was being set to IDL:INPUT when it should be IDL:OUTPUT - this is in JavaInterfaceImpl. Changing this enables the async-services Itests to all pass. The holder-ws-service-multiple-outputs is a different problem I suspect. Note: Fixing this raises the question of whether async server interfaces can have holders - and I think the answer is NO. I'll discuss that point separately on the list. Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
On 21/01/2011 11:07, Mike Edwards wrote: On 20/01/2011 23:29, ant elder wrote: On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurzscottk...@gmail.com wrote: I just committed what I hope is a fix in r1061531. It made the copyInput IndexOutOfBoundsException in sample-implementation-extension go away... (will give some more thought to whether this fix to interface-wsdl is the best solution). I can't run that async-services test yet.. I need to update my mvn repo.. but I'm pretty confident my fix should work for that as well. That said..clearly my testing wasn't good enough if Mike's seeing failures all over the place.. so I'm doing some more careful testing now. Scott Thats fixed all the IndexOutOfBoundsException for me. I do still get other test fails in testing\itest\ws\holder-ws-service-multiple-outputs and testing\itest\async-services ...ant Folks, I think I have a fix for the async-services failures: for an interface with the async server format, the databinding applied to the response parameter was being set to IDL:INPUT when it should be IDL:OUTPUT - this is in JavaInterfaceImpl. Changing this enables the async-services Itests to all pass. The holder-ws-service-multiple-outputs is a different problem I suspect. Note: Fixing this raises the question of whether async server interfaces can have holders - and I think the answer is NO. I'll discuss that point separately on the list. Yours, Mike. Fix committed at 1061775 Yours, Mike.
[DISCUSS] Java Interface Holder support - cannot be used for interfaces that are Async Server
Folks,
I think that the recent work on Holder support has revealed something worth
discussing.
The OASIS specs define a specialized form of Java interface for service implementations that are
asynchronous - ie where the response may be delivered from a separate thread long after the request
has been received.
So, if we have a regular synchronous Java interface like this:
public interface StockQuote {
float getPrice(String ticker);
}
then the equivalent async server form of the same interface looks like this:
@Requires(sca:asyncInvocation)
public interface StockQuote {
void getPriceAsync(String ticker, ResponseDispatchFloat dispatch);
}
- note the presence of the asyncInvocation intent, the addition of Async at the end of the method
name and the addition of the ResponseDispatch object which is typed with the response.
Now, the async server form of an interface really expects there to be one object in the response -
it is not expecting any of the input parameters to be used for returning anything - ie it does not
allow for holders. This must be the case since the original invoked method returns absolutely
nothing (it just hands over the request) and all the response is done through the service calling
ResponseDispatchT.sendResponse( T ).
At the moment, I'm for simply not supporting Holders when using the async service pattern. This is
the simplest approach, I think. Anything else get very complex for no good reason.
The alternative implies that the ResponseDispatch will have to be typed by some kind of array object
- and this would imply a lack of type safety. Then the application would have to build an array of
response values and invoke sendResponse() with that array. Frankly it sounds easier to have a
single response object which is a structure or Collection containing all the required elements of
the response...
Thoughts?
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
On 21/01/2011 14:13, Scott Kurz wrote: I saw that too and manually installed it after finding an earlier thread on this ML (too lazy to link). Got the JAR here: http://tools.oasis-open.org/version-control/svn/sca-j/Release/org/oasis-open/sca/j/sca-caa-apis/1.1-CD04/sca-caa-apis-1.1-CD04.jar The earlier thread discussed things like if it couldn't be placed in the central Maven repo... (apparently not??). Folks, The simple answer is that it IS in a Maven repo - but an OASIS one rather than the central one. So the fix is to add this repo into the Tuscany top level POM, which I've just done. Yours, Mike.
[jira] Created: (TUSCANY-3821) Enable binding.ws (Axis2) to deal with Async service invocations
Enable binding.ws (Axis2) to deal with Async service invocations Key: TUSCANY-3821 URL: https://issues.apache.org/jira/browse/TUSCANY-3821 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3821) Enable binding.ws (Axis2) to deal with Async service invocations
[ https://issues.apache.org/jira/browse/TUSCANY-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12984277#action_12984277 ] Mike Edwards commented on TUSCANY-3821: --- Perform this in 2 stages: 1) Enable Axis binding to manage async callback data via AsyncResponseHandler - this also means dealing with serialization of ResponseDispatchImpl when using binding.ws (fails currently) - also enable Axis binding to also handle regular callbacks in a way that is consistent with the handling of async callback 2) Update Axis2 binding to deal with async callbacks natively - requires an understanding of exactly how Axis2 creates the response endpoint on the client, what header data is forwarded to the service and what entity is used to convey information from the request leg of the processing to the response leg (very unclear from the Axis2 documentation) Enable binding.ws (Axis2) to deal with Async service invocations Key: TUSCANY-3821 URL: https://issues.apache.org/jira/browse/TUSCANY-3821 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3821) Enable binding.ws (Axis2) to deal with Async service invocations
[ https://issues.apache.org/jira/browse/TUSCANY-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12984281#action_12984281 ] Mike Edwards commented on TUSCANY-3821: --- Stage 1 (including fixup of callback handling) done in the following commits: binding-ws-runtime-axis2 1061384 core: 1061385 core-spi: 1061389 implementation-java-runtime 1061391 Enable binding.ws (Axis2) to deal with Async service invocations Key: TUSCANY-3821 URL: https://issues.apache.org/jira/browse/TUSCANY-3821 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
On 20/01/2011 21:05, Scott Kurz wrote: I see the problem in JavaInterfaceImpl.isAsyncServerOperation. The output type will be an empty list in this case, so I can tweak the check. The issue with MediatorImpl concerns me more since I ran the same tests and didn't notice that problem. One thing I noticed during various tests I ran was that sometimes I went through MediatorImpl.copy and sometimes I didn't, when running with the default binding. I don't completely understand why. Scott, I see failures all over the place with this index out of bounds problem - grateful if you can upload a fix soon. Yours, Mike.
Re: Why the split package org.apache.tuscany.sca.runtime in domain-node and in core-spi ??
On 19/01/2011 10:25, ant elder wrote: I've renamed this to use org.apache.tuscany.sca.runtime.TuscanyRuntime. I like that name and it seems most appropriate. If that doesn't work for you in the DomainNode module where would you like it - core/core-spi? ...ant Ant, It isn't the class name that's the problem. It's the package name. Please either rename the package - or if you think that these classes really belong in the org.apache.tuscany.sca.runtime package, then please move all the classes so that they are in one place - its the split package that causes mayhem. Yours, Mike.
Re: How to use binding-ws-runtime-jaxws? (UNCLASSIFIED)
On 19/01/2011 22:57, Yang, Gang CTR US USA wrote: Classification: UNCLASSIFIED Caveats: NONE Hi, Urso, Thanks for the reply. Please excuse me for my ignorance (I just came over to 2.0), but how do you select axis2 or jaxws at the first place? In 1.6, if you specify binding.ws then axis2 used because that is the only binding.ws provider. Since you seem to have used jaxws in Tuscany, can you tell me if the concept of jaxws handlers are supported? Thanks a lot. Gang Gang, Do you mean the idea of using JAXWS handlers inside your component implementation code - eg in a POJO? The simple answer to that is no. But before I go any further, can I ask what are you trying to do - what do you want the handlers to do - access some specific SOAP headers, for example? If the answer to that question is yes, then we should discuss the SCA programming model further. Yours, Mike.
Why the split package org.apache.tuscany.sca.runtime in domain-node and in core-spi ??
Folks, Can someone explain why there is now a split package org.apache.tuscany.sca.runtime in the modules domain-node and in core-spi, please? It looks like this has come about due to changes in domain-node. Split packages are at best confusing and to be avoided, in my opinion. For OSGi use, split packages are painful and I don't have a brain big enough to sort out the problems they cause. Unless someone can justify the retention of this split package, I shall rename the part that is in domain-node to: org.apache.tuscany.node.runtime Yours, Mike.
[jira] Commented: (TUSCANY-3811) Enable binding.sca to deal with Async service invocations
[ https://issues.apache.org/jira/browse/TUSCANY-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982633#action_12982633 ] Mike Edwards commented on TUSCANY-3811: --- Updated deserialization code in RuntimeEndpointReferenceImpl RuntimeEndpointImpl to correctly deserialize interface information which is used in the async response handling. Committed in 1059921 Enable binding.sca to deal with Async service invocations - Key: TUSCANY-3811 URL: https://issues.apache.org/jira/browse/TUSCANY-3811 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3817) Tuscany fails OASIS Java CAA Testcases 10029 10030
Tuscany fails OASIS Java CAA Testcases 10029 10030 - Key: TUSCANY-3817 URL: https://issues.apache.org/jira/browse/TUSCANY-3817 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x Tuscany fails OASIS Java CAA testcases 10029 10030, which concern detection of @Remotable annotations in invalid locations within a Java interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-3817) Tuscany fails OASIS Java CAA Testcases 10029 10030
[ https://issues.apache.org/jira/browse/TUSCANY-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-3817. --- Resolution: Fixed Fix to JavaInterfaceIntrospectorImpl in interface-java provided in: 1058146 Tuscany fails OASIS Java CAA Testcases 10029 10030 - Key: TUSCANY-3817 URL: https://issues.apache.org/jira/browse/TUSCANY-3817 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x Tuscany fails OASIS Java CAA testcases 10029 10030, which concern detection of @Remotable annotations in invalid locations within a Java interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-3816) iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-3816. --- Resolution: Fixed A basic fix to the test is committed in: 1058211 However, this test is not ideal in its current form - the COMPOSITE scope component makes the dangerous assumption that it has only 1 client and thus only 1 callback object. A real composite scoped component would have to allow for multiple clients - and would have to identify each of them separately via some kind of unique ID, which would ideally be described at the application level in the forward service interface to the component. e.g. String registerForEvent(String aEventName); -- returns a registrationID as a String... void unregisterForEvent(String aEventName, String registrationID); -- cancels the registration for the given registrationID iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks Key: TUSCANY-3816 URL: https://issues.apache.org/jira/browse/TUSCANY-3816 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x The iTest Callback SeparateThread has a component implementation EventProcessorServiceImpl.java which is @Scope(COMPOSITE) and which has a field annotated with @Callback. This violates one of the conformance requirements of the OASIS Java CAA specification, which does not permit the use of the @Callback annotation for COMPOSITE scope components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3816) iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks
iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks Key: TUSCANY-3816 URL: https://issues.apache.org/jira/browse/TUSCANY-3816 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x The iTest Callback SeparateThread has a component implementation EventProcessorServiceImpl.java which is @Scope(COMPOSITE) and which has a field annotated with @Callback. This violates one of the conformance requirements of the OASIS Java CAA specification, which does not permit the use of the @Callback annotation for COMPOSITE scope components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3816) iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980033#action_12980033 ] Mike Edwards commented on TUSCANY-3816: --- The initial step is to disable this test from the build since the fix for the problem is not simple and will take some time to develop. Committed in 1057555 iTest Callback SeparateThread violates the OASIS rules for COMPOSITE scope components with Callbacks Key: TUSCANY-3816 URL: https://issues.apache.org/jira/browse/TUSCANY-3816 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-2.x The iTest Callback SeparateThread has a component implementation EventProcessorServiceImpl.java which is @Scope(COMPOSITE) and which has a field annotated with @Callback. This violates one of the conformance requirements of the OASIS Java CAA specification, which does not permit the use of the @Callback annotation for COMPOSITE scope components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3786) In the async programming model provide a clear separate between the Java specific bits and the infrastructure bits so it can be used by other implementation types
[ https://issues.apache.org/jira/browse/TUSCANY-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980111#action_12980111 ] Mike Edwards commented on TUSCANY-3786: --- Some separation of the Java code from the core committed in: 1057654 In the async programming model provide a clear separate between the Java specific bits and the infrastructure bits so it can be used by other implementation types -- Key: TUSCANY-3786 URL: https://issues.apache.org/jira/browse/TUSCANY-3786 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-SCA-2.0-Beta1 Environment: all Reporter: Simon Laws Fix For: Java-SCA-2.0 The current async programming model is Java centric and some of this bleeds over into the infrastrcture. I would be good if the programming model were applicable to other implementation types such as BPEL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3801) Add ability to deal with bindings that natively support async interactions
[ https://issues.apache.org/jira/browse/TUSCANY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980113#action_12980113 ] Mike Edwards commented on TUSCANY-3801: --- Further changes to core, core-spi, assembly and binding-ws-runtime-axis2 committed in: 1057645 1057647 1057648 1057650 Add ability to deal with bindings that natively support async interactions --- Key: TUSCANY-3801 URL: https://issues.apache.org/jira/browse/TUSCANY-3801 Project: Tuscany Issue Type: Sub-task Reporter: Simon Laws Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3811) Enable binding.sca to deal with Async service invocations
[ https://issues.apache.org/jira/browse/TUSCANY-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980115#action_12980115 ] Mike Edwards commented on TUSCANY-3811: --- Upgraded support for local binding.sca to use native async invocations provided in: 1057653 - remote case still outstanding Enable binding.sca to deal with Async service invocations - Key: TUSCANY-3811 URL: https://issues.apache.org/jira/browse/TUSCANY-3811 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3813) Tuscany fails OASIS Java CAA testcase 10035 - permits @Callback on a Field / Method of a class marked @Scope(COMPOSITE)
Tuscany fails OASIS Java CAA testcase 10035 - permits @Callback on a Field / Method of a class marked @Scope(COMPOSITE) --- Key: TUSCANY-3813 URL: https://issues.apache.org/jira/browse/TUSCANY-3813 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-2.0 Tuscany fails the OASIS compliance testcase JAVA-CAA 10035. This testcase checks whether a class marked with @Scope(COMPOSITE) is reported as being in error if a Field or a Method of the class is annotated with @Callback. Currently Tuscany fails this testcase, since the code in the Java implementation introspector does not check for these cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-3813) Tuscany fails OASIS Java CAA testcase 10035 - permits @Callback on a Field / Method of a class marked @Scope(COMPOSITE)
[ https://issues.apache.org/jira/browse/TUSCANY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-3813. --- Resolution: Fixed Fix to the ServiceProcessor class in implementation-java introspect.impl package, which checks that @Callback is not used when the class is annotated with @Scope(COMPOSITE) Tuscany fails OASIS Java CAA testcase 10035 - permits @Callback on a Field / Method of a class marked @Scope(COMPOSITE) --- Key: TUSCANY-3813 URL: https://issues.apache.org/jira/browse/TUSCANY-3813 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-2.0 Tuscany fails the OASIS compliance testcase JAVA-CAA 10035. This testcase checks whether a class marked with @Scope(COMPOSITE) is reported as being in error if a Field or a Method of the class is annotated with @Callback. Currently Tuscany fails this testcase, since the code in the Java implementation introspector does not check for these cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TUSCANY-3813) Tuscany fails OASIS Java CAA testcase 10035 - permits @Callback on a Field / Method of a class marked @Scope(COMPOSITE)
[ https://issues.apache.org/jira/browse/TUSCANY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978765#action_12978765 ] Mike Edwards edited comment on TUSCANY-3813 at 1/7/11 7:50 AM: --- Fix to the ServiceProcessor class in implementation-java introspect.impl package, which checks that @Callback is not used when the class is annotated with @Scope(COMPOSITE) Committed in 1056294 was (Author: edwardsmj): Fix to the ServiceProcessor class in implementation-java introspect.impl package, which checks that @Callback is not used when the class is annotated with @Scope(COMPOSITE) Tuscany fails OASIS Java CAA testcase 10035 - permits @Callback on a Field / Method of a class marked @Scope(COMPOSITE) --- Key: TUSCANY-3813 URL: https://issues.apache.org/jira/browse/TUSCANY-3813 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-2.0 Tuscany fails the OASIS compliance testcase JAVA-CAA 10035. This testcase checks whether a class marked with @Scope(COMPOSITE) is reported as being in error if a Field or a Method of the class is annotated with @Callback. Currently Tuscany fails this testcase, since the code in the Java implementation introspector does not check for these cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3807) Enable core async handling code to supply correct information for all binding types
[ https://issues.apache.org/jira/browse/TUSCANY-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12973586#action_12973586 ] Mike Edwards commented on TUSCANY-3807: --- AsyncResponseInvoker made generic to deal with varying forms of async response address information 1051463 Enable core async handling code to supply correct information for all binding types --- Key: TUSCANY-3807 URL: https://issues.apache.org/jira/browse/TUSCANY-3807 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3811) Enable binding.sca to deal with Async service invocations
Enable binding.sca to deal with Async service invocations - Key: TUSCANY-3811 URL: https://issues.apache.org/jira/browse/TUSCANY-3811 Project: Tuscany Issue Type: Sub-task Reporter: Mike Edwards Assignee: Mike Edwards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
