Re: SCA 1.2.1 release
On Thu, May 15, 2008 at 10:10 AM, ant elder [EMAIL PROTECTED] wrote: I've had a request to do an official release that includes the fix for TUSCANY-2304. I think this is reasonable so would like to do this, it shouldn't be too hard as its a small fix so its just copying the 1.2 release tag, applying the fix, spinning the new release artifacts and voting. I know we tried this before with 1.0.1 but that ended up with so much new function it made it harder to get out, if 1.2.1 is kept really focused I hope it would be easier. I'd like to start this off tomorrow if no one has any objections, WDYT? There was also a suggestion that maybe a fix for TUSCANY-2251 could get into this, is that likely to be small and ready? ...ant Ok probably doing this today was a little too short notice so how about seeing what we have on Monday. I've created a Java-SCA-1.2.1 release in JIRA, how about we add JIRAs with either patches or specific SVN revision changes for everything we'd like considered for 1.2.1. I really would like to keep this as small as possible though. Ideally there can be a diff of the 1.2 and 1.2.1 tags which is just a screen or two long so reviewing and voting is easy and we don't spend days or weeks work on this. Module and pom.xml changes would scare me as its so easy to screw up the distributions. If we can show this can fly through maybe then it will be easier to do maintenance type releases more often so it becomes easier to leave things out. ...ant
Re: Got expection where the wsdl defines an operation without input parameter
On Thu, May 15, 2008 at 11:02 PM, Gilbert Kwan [EMAIL PROTECTED] wrote: I got following exception in running where the wsdl defines an operation without input parameter. java.lang.IllegalArgumentException: Pass-by-value is not supported for the given object at org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy(JavaBeansDataBinding.java:102) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.copy(DefaultDataBindingExtensionPoint.java:171) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:235) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copyFault(PassByValueInterceptor.java:130) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:115) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy7.getB1Name(Unknown Source) at org.apache.tuscany.sca.vtest.wsbinding.nowsdl.NoWsdlTestCase.testNoWsdl(NoWsdlTestCase.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.NotSerializableException: org.apache.axiom.om.impl.llom.OMElementImpl at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1113) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1439) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1382) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414) at java.lang.Throwable.writeObject(Throwable.java:320) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:972) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1431) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1382) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414) at
[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597382#action_12597382 ] Simon Nash commented on TUSCANY-2324: - Disclaimer: I haven't yet looked at the code. I think the interface contract on the outer reference should be used for the WS binding. According to the spec rules, it must provide a compatible subset of operations on the interface for the inner reference. If the generated WSDL doesn't match the actual WSDL, this suggests that the interfaces are not compatible, which would violate the spec and should be diagnosed as an error. There's a JIRA (TUSCANY-2109) already open for what looks like a very similar problem caused by namespace conflicts between the two interfaces. It may be possible to close this JIRA as a duplicate of TUSCANY-2109. InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding --- Key: TUSCANY-2324 URL: https://issues.apache.org/jira/browse/TUSCANY-2324 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Scott Kurz Priority: Minor If we take the following example where an inner component reference is overridden in two ways by the outer component using the inner Composite as impl: 1) a binding.ws is added 2) a WSDL intf (compatible with the inner Java intf) is declared composite ... name=OuterComposite component name=OuterComponent implementation.composite name=blah:InnerComposite/ reference name=outerRef target=MyTarget interface.wsdl interface=http://blah#wsdl.interface(HelloWorld) / binding.ws/ /reference /component /composite composite name=InnerComposite component name=InnerComponent implementation.java .../ reference name=helloWorldService interface.java interface=test.sca.w2j.ws.statc.exc.helloworld.HelloWorld/ /reference /component reference name=outerRef promote=InnerComponent/helloWorldService/ /composite we have a problem. The CompositeActivatorImpl is going to start an Axis2ReferenceBindingProvider for the inner Composite ref. The WS binding is propagated down or inwards, you could say.But this WS binding has a null IC, so we're going to look at the component ref IC, but this will be the inner component ref IC, which is a Java IC. This kicks off a Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC. So the generated WSDL may not match the actual WSDL, which is a problem. Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the outer component's binding.ws/ we would not have had a problem; it would have been propagated inwards along with the binding itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated binding
...snip The two sets of SPIs could co-exist for a while with BindingProviders working with bindings and ServiceProviders (I just made up that name) with service endpoints. -- Jean-Sebastien At r656959 I've just enabled some changes to take a step toward using an Endpoint representation in the model as an alternative to using cloned bindings as the representation of valid reference targets. It's not replacing the cloned binding approach just yet, to avoid breaking anything, but is the first step on the road. This is what I have done. Made a new Endpoint model type Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Created a new EndpointProvider type and associated factory. Created an Endpoint module to provide a provider implementation. Created an Endpoint wire to trap attempted calls over unresolved endpoints Separated off the Endpoint builder code into a new builder class. Same code but easier to identify. Added an endpoint collection to references Used the Endpoint in the wire builder in place of the old internal target structure. The logic is weaved in to the existing logic as follows. For references with no target, put the binding into reference binding as before Create an Endpoint for all explicit reference targets For resolved endpoints (Endpoints where the target is resolved) put the binding into reference bindings, i.e. the same as before For unresolved endpoints create an endpoint provider and a wire. We don't have unresolved targets in tuscany (except in the sca binding test) so should not happen. If you do put a target name in that can't be matched with a service you'll get a warning. If there is no Endpoint module on the classpath it will not create a provider or a wire hence disabling any Endpoint based processing. The Endpoint model will still be used though As part of this change I've updated the logic that looks for target names in binding uri. It's now applied to all binding types which I believe is what the spec says, There is though an issue here. I'll raise a separate thread. There are also a couple of thoughts I had. Can we make the CompositeBuilderImpl have just one constructor? Should builders be pluggable? I've used some of the CompoisteActivator functions in the EndpointWire that could do with moving into the activator interface. Simon
Re: OSGi-enable 3rd party libraries in Tuscany
On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. But I imagine disk space for jaxb.jar is not the issue. What we want to minimize is the number of jaxb bundles installed into an OSGi runtime, when ServiceMix, Tuscany etc. etc. are installed into one OSGi runtime. There is nothing stopping Tuscany from using org.apache.servicemix.bundles.jaxb.jar or ServiceMix from using org.apache.tuscany.sca.jaxb.jar, if they can both use the same version. Both of these (and the SpringSource version) have the same versioning conventions and export/imports. Using real bundles, we enable OSGi users to decide which bundles (and how many of them) they want to install into their OSGi runtime. Using virtual bundles, Tuscany will probably end up installing jaxb.jar into OSGi regardless of whether there are other variants that it can use. We are taking control away from the user, and could potentially increase the number of bundles installed unnecessarily, and also potentially generate classloading conflicts. Another more minor point is that for Graham's minimal OSGi test that's going to be part of the main build, it will be necessary to build these wrapper bundles, increasing the disk space used by the build because of the need to duplicate the contents of all the third-party jars, which are already in my local maven repo. As far as I know, Graham's minimal OSGi test is a subset of itest/osgi-tuscany, and hence relies on a manifest.jar file with co-located 3rd party jars (it does not load 3rd party jars directly off the maven repo). The bundle-ized 3rd party jars will replace these
Re: Running Tuscany/SCA in Google Android mobile platform
Hi Oscar, My mistake again, the eclipse project files of contribution-impl module were not uploaded, so you are probably using the modules you have downloaded from the sca modules. If you remove the tuscany-contribution-impl from your workspace and add this module from the sandbox it will probably work. Anyway, you will need to update your trunk again to get the project files I'm uploading right now ; ) OK, if you wanna try the retrotranslator as a solution here is a tip: most of the code that were using the Reflection API was commented on org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator class, you just need to edit this class and remove the commented code (it's described there). So, if you uncomment the code and the retrotranslador successfuly work, and I hope it will, you will reach the org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider constructor and it should run OK. Exactly on this constructor I'm getting a NPE when the code described above is commented. About the ant, go on and use it. Further we can evaluate better where we place it in the entire SCA build process. BTW, we even dont know if we will still be using the retrotranslator in future, right?! : ) Use the retrotranslator may help us a lot to workaround this problem for now and go on with our project ; ) Kind Regards, Adriano Crestani On Wed, May 14, 2008 at 2:57 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi Adriano, Thanks alot for your answers. I was able to build the entire workspace from your instructions. When running calculator-android as an Android application I'm getting a ClassNotFoundException [1] for org.apache.tuscany.sca.contribution.processor.impl.DexContributionProcessor. Is the exception you referred to in your original email? ...when you run the calculator-android project as an Android application you should get an exception, that was generated initially by a NPE thrown by org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider constructor. This is caused because the latest Android SDK does not support the Reflection API yet. So, the SCA cannot check the @Reference annotations (I commented the code which tries to read the annotations, so when the execution reach this constructor it throws the NPE). Searching for the class in the exception I'm getting I found org.apache.tuscany.sca.extensibility.ServiceDiscovery. In getServiceClasses it loads the service class I'm getting problems with when running calculator-android as an Android application: org.apache.tuscany.sca.contribution.processor.impl.DexContributionProcessor;type=application/x-dex I couldn't find the corresponding java file in my imported workspace and found that there is no package like org.apache.tuscany.sca.contribution.processor.impl. Am I missing something? Or are these the errors you would expect? I would like to get to the point where I get the exception you described and try to run retrotranslator from there. However, as I'm using the ADT plugin in eclipse I would need to extract code that declares or analyzes annotations you may extract it into a separate library that can be processed with Retrotranslator and added to the main project. That is, unless I use Ant, in which case I would only need to add a few lines to build.xml. I'm continuing to look into this, any thoughts are more than welcome :-) [1] http://delftandroid.googlepages.com/14may2008.html On Mon, May 12, 2008 at 9:13 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, Thanks all for the feedback ; ) At first, I want to correct one mistake, on the first step I described on my previous email, I should not have added the word install, it probably would lead the reader to run the mvn clean install in the downloaded files, as Oscar did. Also, on this same step, the code should not be downloaded from [1], but from [2]. Simon: Thanks for the link ; ). As the Sun Java source codes are under CDDL 1.0 license, it's only needed to include the CDDL license header on each file, and it's already done : ) Jean: I think it is better to keep the code in the sandbox for now. At first, it's not working on the current SCA modules revision yet. And also, I'm commenting many lines at some modules just to get a first run of calculator-sample to further evaluate why and how this commented lines will be adapted to be compatible with both: SCA Java and SCA Android. Oscar: - Are host-android and core-android a part of calculator-android? What do you mean when you say part? They are used by calculator-android, and will prabably be added to tuscany sca modules in future - Should the calculator-android included in [1] have included an AndroidManifest.xml file? Sorry, my mistake, I forgot to add to svn the eclipse project files of these projects. I have already commited these files and if you update your trunk
RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin
Hi, I've just tried building the latest trunk of Tuscany and I'm getting a compile failure in the new endpoint module. The error I am getting is: [INFO] [INFO] Error for project: Apache Tuscany SCA Default Endpoint Implementation (during install) [INFO] [INFO] Compilation failure /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tuscan y/sca/binding/sca/EndpointTestCase.java:[109,32] package org.apache.xml.serialize does not exist /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tuscan y/sca/binding/sca/EndpointTestCase.java:[110,32] package org.apache.xml.serialize does not exist Is anyone else seeing this issue or is it just me? Thanks, Mark -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 16 May 2008 09:26 To: tuscany-dev@ws.apache.org Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object ...snip The two sets of SPIs could co-exist for a while with BindingProviders working with bindings and ServiceProviders (I just made up that name) with service endpoints. -- Jean-Sebastien At r656959 I've just enabled some changes to take a step toward using an Endpoint representation in the model as an alternative to using cloned bindings as the representation of valid reference targets. It's not replacing the cloned binding approach just yet, to avoid breaking anything, but is the first step on the road. This is what I have done. Made a new Endpoint model type Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Created a new EndpointProvider type and associated factory. Created an Endpoint module to provide a provider implementation. Created an Endpoint wire to trap attempted calls over unresolved endpoints Separated off the Endpoint builder code into a new builder class. Same code but easier to identify. Added an endpoint collection to references Used the Endpoint in the wire builder in place of the old internal target structure. The logic is weaved in to the existing logic as follows. For references with no target, put the binding into reference binding as before Create an Endpoint for all explicit reference targets For resolved endpoints (Endpoints where the target is resolved) put the binding into reference bindings, i.e. the same as before For unresolved endpoints create an endpoint provider and a wire. We don't have unresolved targets in tuscany (except in the sca binding test) so should not happen. If you do put a target name in that can't be matched with a service you'll get a warning. If there is no Endpoint module on the classpath it will not create a provider or a wire hence disabling any Endpoint based processing. The Endpoint model will still be used though As part of this change I've updated the logic that looks for target names in binding uri. It's now applied to all binding types which I believe is what the spec says, There is though an issue here. I'll raise a separate thread. There are also a couple of thoughts I had. Can we make the CompositeBuilderImpl have just one constructor? Should builders be pluggable? I've used some of the CompoisteActivator functions in the EndpointWire that could do with moving into the activator interface. Simon _
[jira] Closed: (TUSCANY-1534) Refactor wireable binding support to make it applicable to all bindings
[ https://issues.apache.org/jira/browse/TUSCANY-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-1534. --- Resolution: Fixed Done as part of the latest round of reference/binding/endpoint changes. Refactor wireable binding support to make it applicable to all bindings --- Key: TUSCANY-1534 URL: https://issues.apache.org/jira/browse/TUSCANY-1534 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-Next Extracted from the now closed https://issues.apache.org/jira/browse/TUSCANY-1526 There is consensus that all bindings are potentially wireable and that the current WireableBinding interface should either be removed or applied to all bindings. Hence the following should be a valid configuration. component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component There is further discussion in the mail thread associated with TUSCANY-1526 (http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21448.html) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin
This problem has now been fixed in SVN revision r657009 Thanks, Mark -Original Message- From: Mark Combellack [mailto:[EMAIL PROTECTED] Sent: 16 May 2008 11:26 To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object Hi, I've just tried building the latest trunk of Tuscany and I'm getting a compile failure in the new endpoint module. The error I am getting is: [INFO] [INFO] Error for project: Apache Tuscany SCA Default Endpoint Implementation (during install) [INFO] [INFO] Compilation failure /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc an y/sca/binding/sca/EndpointTestCase.java:[109,32] package org.apache.xml.serialize does not exist /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc an y/sca/binding/sca/EndpointTestCase.java:[110,32] package org.apache.xml.serialize does not exist Is anyone else seeing this issue or is it just me? Thanks, Mark -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 16 May 2008 09:26 To: tuscany-dev@ws.apache.org Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object ...snip The two sets of SPIs could co-exist for a while with BindingProviders working with bindings and ServiceProviders (I just made up that name) with service endpoints. -- Jean-Sebastien At r656959 I've just enabled some changes to take a step toward using an Endpoint representation in the model as an alternative to using cloned bindings as the representation of valid reference targets. It's not replacing the cloned binding approach just yet, to avoid breaking anything, but is the first step on the road. This is what I have done. Made a new Endpoint model type Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Created a new EndpointProvider type and associated factory. Created an Endpoint module to provide a provider implementation. Created an Endpoint wire to trap attempted calls over unresolved endpoints Separated off the Endpoint builder code into a new builder class. Same code but easier to identify. Added an endpoint collection to references Used the Endpoint in the wire builder in place of the old internal target structure. The logic is weaved in to the existing logic as follows. For references with no target, put the binding into reference binding as before Create an Endpoint for all explicit reference targets For resolved endpoints (Endpoints where the target is resolved) put the binding into reference bindings, i.e. the same as before For unresolved endpoints create an endpoint provider and a wire. We don't have unresolved targets in tuscany (except in the sca binding test) so should not happen. If you do put a target name in that can't be matched with a service you'll get a warning. If there is no Endpoint module on the classpath it will not create a provider or a wire hence disabling any Endpoint based processing. The Endpoint model will still be used though As part of this change I've updated the logic that looks for target names in binding uri. It's now applied to all binding types which I believe is what the spec says, There is though an issue here. I'll raise a separate thread. There are also a couple of thoughts I had. Can we make the CompositeBuilderImpl have just one constructor? Should builders be pluggable? I've used some of the CompoisteActivator functions in the EndpointWire that could do with moving into the activator interface. Simon _
Re: Small OSGi sample for the main build?
Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.03.jar XmlSchema-1.3.2.jar xmlsec-1.4.0.jar Let me know what you think? Regards, Graham. 2008/5/15 Mike Edwards [EMAIL PROTECTED]: Graham Charters wrote: Hi, I've been working on a small sample to act as an OSGi sniff test for Tuscany running in OSGi. It's
Re: Small OSGi sample for the main build?
On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.03.jar XmlSchema-1.3.2.jar xmlsec-1.4.0.jar Let me know what you
Re: Small OSGi sample for the main build?
On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar
[jira] Assigned: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-2277: --- Assignee: Simon Laws (was: Ramkumar Ramalingam) Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Small OSGi sample for the main build?
Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar
[jira] Commented: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597473#action_12597473 ] Simon Laws commented on TUSCANY-2277: - Hi Ram Was just trying to apply these patches and am having a few problems. What tool did you use to generate them? I'm guessing Msftedit from the header. Can you regenerate them using a diff tool. Let me know if you need some help. The issues I'm having are - has a strange Msft header (I can libe with this as I can remove it nmanually) - the file dirs are absolute (I can live with this as I can go in and edit) - there are some escaped charaters in there, e.g. \tab, \par, \{, \} which mess it up. (I can't get round this as fixing manually messes up the formatting and the patch tool can't then match the patch against the original code) Thanks Simon Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Small OSGi sample for the main build?
Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar
Re: Conversational semantics using xml in SCDLs
Simon Nash wrote: I am surprised to hear that. I would expect a different interface object to be created for each different interface element appearing in the SCDL. Hmm, my experience recently with the BPEL code shows that the handling of interfaces within Tuscany is not so clean. I'll continue my investigations and report my findings when I understand it all better. I agree that different interface elements SHOULD be used. It just doesn't happen in all the cases that I've experienced. Yours, Mike.
Re: SCA 1.2.1 release
For my 1 cent on this point. The BPEL code is still raw at this stage and I feel it could do with a few more tweaks before it is really ready for prime time - I certainly still have a lot of trouble getting it to work - and I'm working on it!! Yours, Mike. Luciano Resende wrote: In the past, there has been various requests for this feature in the user/dev list, and unfortunately I couldn't get it ready by 1.2. It seems like a reasonable time to add it now that we are going to make this 1.2.1 release. BTW, the changes are localized and not so big. On Thu, May 15, 2008 at 3:07 PM, Simon Nash [EMAIL PROTECTED] wrote: Luciano Resende wrote: Any chance I could add the bpel reference support as part of this release ? The changes are localized and won't affect other areas. Is there a user requesting this support? Remembering the 1.0.1 experience, I think we should keep this release as small and focused as possible. Simon On Thu, May 15, 2008 at 2:10 AM, ant elder [EMAIL PROTECTED] wrote: I've had a request to do an official release that includes the fix for TUSCANY-2304. I think this is reasonable so would like to do this, it shouldn't be too hard as its a small fix so its just copying the 1.2 release tag, applying the fix, spinning the new release artifacts and voting. I know we tried this before with 1.0.1 but that ended up with so much new function it made it harder to get out, if 1.2.1 is kept really focused I hope it would be easier. I'd like to start this off tomorrow if no one has any objections, WDYT? There was also a suggestion that maybe a fix for TUSCANY-2251 could get into this, is that likely to be small and ready? ...ant
[jira] Commented: (TUSCANY-2247) vtest content for Java API spec - Conversation/Async
[ https://issues.apache.org/jira/browse/TUSCANY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597491#action_12597491 ] Kevin Williams commented on TUSCANY-2247: - Leaving this open until resolution of TUSCANY-2312 at which point I will add testing for section 1.6.7.5 which will complete conversation testing. vtest content for Java API spec - Conversation/Async - Key: TUSCANY-2247 URL: https://issues.apache.org/jira/browse/TUSCANY-2247 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-SCA-Next Add vtest content for Java API/Annotation Spec section 1.6 - Conversations and Async -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener
[ https://issues.apache.org/jira/browse/TUSCANY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-2092: --- Assignee: Simon Laws (was: Ramkumar Ramalingam) ConcurrentModificationException in ExtensibleContributionListener - Key: TUSCANY-2092 URL: https://issues.apache.org/jira/browse/TUSCANY-2092 Project: Tuscany Issue Type: Bug Reporter: Greg Dritschler Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: JIRA-2092.patch, TUSCANY-2092.patch java.util.ConcurrentModificationException at java.util.AbstractList$SimpleListIterator.next(Unknown Source) at org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202) The problem occurs if two threads try to add a contribution simultaneously. DefaultContributionListenerExtensionPoint does not synchronize the list of listeners. In particular loadListeners does not prevent multiple threads from trying to load the list of listeners. One thread completes first while the other is still loading. This leads to the exception shown above when a thread tries to iterate the listener list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener
[ https://issues.apache.org/jira/browse/TUSCANY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-2092. --- Resolution: Fixed Thanks for the patch Ram. Committed at 657093 ConcurrentModificationException in ExtensibleContributionListener - Key: TUSCANY-2092 URL: https://issues.apache.org/jira/browse/TUSCANY-2092 Project: Tuscany Issue Type: Bug Reporter: Greg Dritschler Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: JIRA-2092.patch, TUSCANY-2092.patch java.util.ConcurrentModificationException at java.util.AbstractList$SimpleListIterator.next(Unknown Source) at org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202) The problem occurs if two threads try to add a contribution simultaneously. DefaultContributionListenerExtensionPoint does not synchronize the list of listeners. In particular loadListeners does not prevent multiple threads from trying to load the list of listeners. One thread completes first while the other is still loading. This leads to the exception shown above when a thread tries to iterate the listener list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2283) Conversation should end due to non-business exception
[ https://issues.apache.org/jira/browse/TUSCANY-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-2283: --- Assignee: Simon Laws Conversation should end due to non-business exception - Key: TUSCANY-2283 URL: https://issues.apache.org/jira/browse/TUSCANY-2283 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Laws Fix For: Java-SCA-Next The Java APIs and Annotations spec states: 487 A conversation ends, and any state associated with the conversation is freed up, when: ... 492 • Any non-business exception is thrown by a conversational operation This is not happening as illustrated by the vtest: org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.LifetimeTestCase.lifetime11 It is currently @Ignore(d) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Webapp-based Tuscany/Geronimo integration in Tuscany SCA Java 1.2 release
Hi Raymond, One minor netiquette comment... Looks like you used a Reply To button when generating your note (then changed the subject line). Some mail readers will still group your email in the previous email thread (one example is Mac OS X Mail). This can cause emails to be lost/cause confusion. So, it's best to avoid... More below. On May 15, 2008, at 1:52 PM, Raymond Feng wrote: Hi, In the recently released Tuscany SCA Java 1.2 [1], we produce a whitepaper [2] to describe webapp-based Tuscany/Geronimo integration. We would like to share the information here and hope it can trigger more interests from both Geronimo and Tuscany community to bring more values into these areas collaboratively. Thanks! Developing SOA based solutions can be very complex and expensive. Apache Tuscany provides a lightweight infrastructure which enables users to easily implement SOA based solutions or to use their existing assets and align them with SOA principles which would support a business model that can extend and expand as business needs change. Apache Tuscany implements SCA specifications that is being standardized at OASIS. Tuscany provides the capabilities to construct, assemble and deploy composite applications using SCA. This white paper explains how Tuscany integrates with Apache Geronimo, a fully certified Java EE 5 application server runtime, to provide added value to users wanting to develop SOA solutions using Geronimo as a platform. The added values include: * Extensibility of component implementation technologies * Extensibility of transport and protocol abstractions * A notion of cross-application/cross-network assembly and configuration * Integration of SCA with existing or new EJB based applications The following are a set of usage scenarios that both JEE and SCA developers could be interested in. * Access SCA composites from Java EE components using JEE programming model * Access session beans from SCA service components * Expose SCA services as session beans or web services * Include Session Beans in a single SCA composition by providing an SCA implementation for session beans. * Inject SCA service references to web components to enable Web 2.0 * Expose enterprise applications into an SCA domain * Use recursive SCA assembly in enterprise applications [1] http://incubator.apache.org/tuscany/sca-java-releases.html [2] http://cwiki.apache.org/TUSCANYWIKI/tuscany-web-application-based-integration-with-geronimo.html Is there interest in tighter integration between Tuscany/Geronimo? Would there be interest in generating a Tuscany Plugin for Geronimo? Running Tuscany as a service? --kevan
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
Why do we need to be so strict in comparing interfaces? Can't we argue essentially the same point in the case with we have a Java client w/ reference w/ Java intf with a binding.ws? So, following this logic, it's suggested that the NS calculated per-JAXWS for the Java intf must match the portType on the WS binding. So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL of an existing WS w/ wsimport, embedding a @WebService(name = ..., targetNamespace = ...)in the Java. Now the WS evolves and we take the new WSDL w/ portType in a new NS. Maybe a new operation is added but we don't care about it from our existing client. Why should we have to re-gen the Java to reflect the new TNS? Also, someone using an older W2J tool may have an option to select a non-standard pkg when generating Java from WSDL, but the tool doesn't reflect this in the @WebService(... targetNamespace...). Do we really need to break them? Would people agree this is essentially the same case as the overridden, promoted intf, or is the argument that this specific case is a bit different ? I mean, I can certainly see how it simplifies the runtime authors' lives to be strict about NS's when doing intf mapping... but do we really have a good reason to?What use case can we just not handle that would make us need this restriction? Scott On Thu, Apr 17, 2008 at 12:09 PM, Raymond Feng [EMAIL PROTECTED] wrote: +1 on Simon's proposal to add the getNamespace() on Interface from another perspective: converting/mapping between IDLs. Thanks, Raymond -- From: Simon Laws [EMAIL PROTECTED] Sent: Thursday, April 17, 2008 6:32 AM To: tuscany-dev@ws.apache.org Subject: Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected On Thu, Apr 10, 2008 at 10:14 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi Mike Some comments in line Simon Folks, It is right to be concerned over the interface matching, but let's not lose sight of the context here. In general, there are two scenarios to consider: a) the reference is to a service which is defined within the SCA domain and SCA means are used to wire it b) the reference is to a service which is outside the SCA domain and wiring is through configuration of a specific binding and target endpoint This JIRA covers a very specific scenario which adds another twist where there is a different between the interface definition of a composite level reference that promotes a component level reference. In case a) it is possible that a Java interface as used by the client in its reference is exactly the same (file) as is being used by the provider in the service interface. If this is so, then in general, even if WSDL is generated, the reference and the target service are going to match, assuming that the same rules are followed at both ends for generating WSDL. (They should be following JAX-WS according to the specs). It is certainly possible. Maybe even likely. But not guaranteed. In case b), the normal situation would be for the client to be constructed using a Java interface derived from the target WSDL using the WSDL2JAVA tooling. While the reference targets the original service from which the WSDL came, there should be no problem, even if the reference itself is typed in terms of the Java interface. Things get interesting if the target service gets changed - and if the WSDL describing the interface changes. Now, to first order, you might say that if the WSDL is different, how do you know that the new service is compatible with the old one? Even if the operation names match and the input and output messages have the same structure, if the namespaces differ, there is no guarantee that the two services are actually compatible. This proposed change is intended to at least raise a warning that there is something amiss. This is an area where ESB style mediations come into play. Let's assume that the target service does use a different namespace, but that the operations and messages otherwise map. There is still a mediation necessary, since the transmitted messages will use the wrong namespace - the mediation simply has to remap the namespace when sending and receiving messages. More complex mediations are possible, where perhaps the operation names and message names don't match, although the structure and semantics do match. The question for us folks in SCA-land is whether we want to model mediations of this type as explicit components, with services and references that match the reference and endpoint that they are trying to mediate, or whether we want to extend our bindings definition to allow
Re: Webapp-based Tuscany/Geronimo integration in Tuscany SCA Java 1.2 release
On Fri, May 16, 2008 at 4:45 PM, Kevan Miller [EMAIL PROTECTED] wrote: snip Is there interest in tighter integration between Tuscany/Geronimo? Would there be interest in generating a Tuscany Plugin for Geronimo? Running Tuscany as a service? --kevan Yes! I think that would be really useful. Right now we've some ongoing work getting Tomcat and the new Tuscany distributed domain stuff working together so having Geronimo also able to do something similar would be ideal. We've also a Google Summer of Code student working on better Tuscany/SCA management in the Geronimo admin console so that would be helped by this as well. ...ant
[jira] Updated: (TUSCANY-2290) Java 2 Security enablement for Tuscany sample (part 1)
[ https://issues.apache.org/jira/browse/TUSCANY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Becker updated TUSCANY-2290: Attachment: TUSCANY-2290.1.patch New patch generated based on comments in Tuscany dev group. Summary is that security fixes should not be applied to samples to keep them simple. Java 2 Security enablement for Tuscany sample (part 1) -- Key: TUSCANY-2290 URL: https://issues.apache.org/jira/browse/TUSCANY-2290 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Environment: Windows, Java 1.5 Reporter: Dan Becker Fix For: Java-SCA-Next Attachments: TUSCANY-2290.1.patch Fix security issues that arise in Tuscany samples when Java 2 security is turned on via -java.security.manager -Djava.security.policy=tuscany.policy -Dpolicy.allowSystemProperty=true A typical exception might be for sample helloworld sdo ws Problems trying to access System properties: java.security.AccessControlException: access denied (java.util.PropertyPermission java.specification.version read) java.lang.NoClassDefFoundError at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:202) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:116) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:58) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:113) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:159) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:90) at org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72) at org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:152) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:63) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2290) Java 2 Security enablement for Tuscany sample (part 1)
[ https://issues.apache.org/jira/browse/TUSCANY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Becker updated TUSCANY-2290: Attachment: (was: TUSCANY-2290.patch) Java 2 Security enablement for Tuscany sample (part 1) -- Key: TUSCANY-2290 URL: https://issues.apache.org/jira/browse/TUSCANY-2290 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Environment: Windows, Java 1.5 Reporter: Dan Becker Fix For: Java-SCA-Next Attachments: TUSCANY-2290.1.patch Fix security issues that arise in Tuscany samples when Java 2 security is turned on via -java.security.manager -Djava.security.policy=tuscany.policy -Dpolicy.allowSystemProperty=true A typical exception might be for sample helloworld sdo ws Problems trying to access System properties: java.security.AccessControlException: access denied (java.util.PropertyPermission java.specification.version read) java.lang.NoClassDefFoundError at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:202) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:116) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:58) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:113) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:159) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:90) at org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72) at org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:152) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:63) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: More Java security fixes on the way
Jean-Sebastien Delfino wrote: I'd like to suggest the following: - Keep the Java2 security blocks in test case classes - Don't put them in sample program classes Hmmm but looking at these test cases, could you help me understand why we need these technical API calls to the jmsBroker at all? Isn't SCA supposed to shield me from having to deal with that kind of calls? Based on the several opinions, I've regenerated the patch so that samples are keep simple and do not have security code in them. Jean-Sebastien, I can't comment on why several of the samples have explicit JMS broker starts and stops in their JUnit tests as I am not the original author. It seems like the author wanted to ensure the broker was running before running the unit test. However, commenting out the startBroker call in sample-helloworld-ws-service-jms, the JUnit test still ran and passed. -- Thanks, Dan Becker
Re: SCA 1.2.1 release
Mike Edwards wrote: For my 1 cent on this point. The BPEL code is still raw at this stage and I feel it could do with a few more tweaks before it is really ready for prime time - I certainly still have a lot of trouble getting it to work - and I'm working on it!! I'm not familiar with the BPEL code but I do remember what happened with 1.0.1 and I don't think we should repeat that experience. If there are broken things causing serious impact to users for which we already have a fix that's relatively small and localized, these could be considered. I'd expect there to be a very small list of JIRAs falling into this category. For new features, or bugs that are not causing serious user impact, or things that need extensive code changes, or things that are not fully ready and tested yet, I think we should defer them to the next full release. Simon Yours, Mike. Luciano Resende wrote: In the past, there has been various requests for this feature in the user/dev list, and unfortunately I couldn't get it ready by 1.2. It seems like a reasonable time to add it now that we are going to make this 1.2.1 release. BTW, the changes are localized and not so big. On Thu, May 15, 2008 at 3:07 PM, Simon Nash [EMAIL PROTECTED] wrote: Luciano Resende wrote: Any chance I could add the bpel reference support as part of this release ? The changes are localized and won't affect other areas. Is there a user requesting this support? Remembering the 1.0.1 experience, I think we should keep this release as small and focused as possible. Simon On Thu, May 15, 2008 at 2:10 AM, ant elder [EMAIL PROTECTED] wrote: I've had a request to do an official release that includes the fix for TUSCANY-2304. I think this is reasonable so would like to do this, it shouldn't be too hard as its a small fix so its just copying the 1.2 release tag, applying the fix, spinning the new release artifacts and voting. I know we tried this before with 1.0.1 but that ended up with so much new function it made it harder to get out, if 1.2.1 is kept really focused I hope it would be easier. I'd like to start this off tomorrow if no one has any objections, WDYT? There was also a suggestion that maybe a fix for TUSCANY-2251 could get into this, is that likely to be small and ready? ...ant
[jira] Commented: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597544#action_12597544 ] Ramkumar Ramalingam commented on TUSCANY-2277: -- Hi Simon, The issue seems to be due to subeclipse. I did not realize that such characters would crop up due to subeclipse. I apologies for the inconvenience. I am just uploading a new set of patch for the same fixes. Thanks, Ramkumar R Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2277: - Attachment: TUSCANY-2277-Part1-New.rtf Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2277: - Attachment: (was: TUSCANY-2277-Part1-New.rtf) Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2277: - Attachment: TUSCANY-2277-Part1-New.patch Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1-New.patch, TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
Scott Kurz wrote: Why do we need to be so strict in comparing interfaces? Can't we argue essentially the same point in the case with we have a Java client w/ reference w/ Java intf with a binding.ws? So, following this logic, it's suggested that the NS calculated per-JAXWS for the Java intf must match the portType on the WS binding. So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL of an existing WS w/ wsimport, embedding a @WebService(name = ..., targetNamespace = ...)in the Java. Now the WS evolves and we take the new WSDL w/ portType in a new NS. Maybe a new operation is added but we don't care about it from our existing client. Why should we have to re-gen the Java to reflect the new TNS? Adding a new operation would be a compatible change to the interface and should not result in the interface's TNS changing. Also, someone using an older W2J tool may have an option to select a non-standard pkg when generating Java from WSDL, but the tool doesn't reflect this in the @WebService(... targetNamespace...). Do we really need to break them? This is easy to deal with by configuring the reference binding to refer to the WSDL binding that the client code is actually using to make the invocation. If the reference binding.ws doesn't specify any WSDL binding, the binding.ws's interface contract should be generated from the reference's interface.java. Would people agree this is essentially the same case as the overridden, promoted intf, or is the argument that this specific case is a bit different ? It seems pretty similar to me. I mean, I can certainly see how it simplifies the runtime authors' lives to be strict about NS's when doing intf mapping... but do we really have a good reason to?What use case can we just not handle that would make us need this restriction? The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an incorrect namespace was sent on the wire because SCA did not detect the reference/service mismatch. This problem is caused by a mismatch in the WSDL binding rather than a mismatch in the Java interface. However, the specs say that the WSDL binding (including its namespace) is generated by applying the JAX-WS Java2WSDL mapping to the Java interface. If this algorithm doesn't produce the same namespace that's used by the service, the reference won't be able to interoperate with it. Simon Scott On Thu, Apr 17, 2008 at 12:09 PM, Raymond Feng [EMAIL PROTECTED] wrote: +1 on Simon's proposal to add the getNamespace() on Interface from another perspective: converting/mapping between IDLs. Thanks, Raymond -- From: Simon Laws [EMAIL PROTECTED] Sent: Thursday, April 17, 2008 6:32 AM To: tuscany-dev@ws.apache.org Subject: Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected On Thu, Apr 10, 2008 at 10:14 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi Mike Some comments in line Simon Folks, It is right to be concerned over the interface matching, but let's not lose sight of the context here. In general, there are two scenarios to consider: a) the reference is to a service which is defined within the SCA domain and SCA means are used to wire it b) the reference is to a service which is outside the SCA domain and wiring is through configuration of a specific binding and target endpoint This JIRA covers a very specific scenario which adds another twist where there is a different between the interface definition of a composite level reference that promotes a component level reference. In case a) it is possible that a Java interface as used by the client in its reference is exactly the same (file) as is being used by the provider in the service interface. If this is so, then in general, even if WSDL is generated, the reference and the target service are going to match, assuming that the same rules are followed at both ends for generating WSDL. (They should be following JAX-WS according to the specs). It is certainly possible. Maybe even likely. But not guaranteed. In case b), the normal situation would be for the client to be constructed using a Java interface derived from the target WSDL using the WSDL2JAVA tooling. While the reference targets the original service from which the WSDL came, there should be no problem, even if the reference itself is typed in terms of the Java interface. Things get interesting if the target service gets changed - and if the WSDL describing the interface changes. Now, to first order, you might say that if the WSDL is different, how do you know that the new service is compatible with the old one? Even if the operation names match and the input and output messages have the same structure, if the namespaces differ, there is no guarantee that the two services are actually compatible. This proposed
[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2277: - Attachment: (was: TUSCANY-2277-Part1-New.patch) Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin
Please see my comments below. Thanks, Raymond -- From: Simon Laws [EMAIL PROTECTED] Sent: Friday, May 16, 2008 1:26 AM To: tuscany-dev@ws.apache.org Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object ...snip The two sets of SPIs could co-exist for a while with BindingProviders working with bindings and ServiceProviders (I just made up that name) with service endpoints. -- Jean-Sebastien At r656959 I've just enabled some changes to take a step toward using an Endpoint representation in the model as an alternative to using cloned bindings as the representation of valid reference targets. It's not replacing the cloned binding approach just yet, to avoid breaking anything, but is the first step on the road. This is what I have done. Made a new Endpoint model type +100. The schema kind of mixes the binding/endpoint concept together. I think it's much cleaner to add the endpoint model to represent the outbound/inbound addresses. Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Would it be possible to just add the create method the AssemblyFactory? Created a new EndpointProvider type and associated factory. I assume the EndpointProvider is a system utility that match/resolve the endpoints based on the reference/service binding configurations. If so, I suggest that name it differently such as EndpointResolver and we can just have the interface and default impl (no factory is required). We use the term Provider for binding/implementation extensions to provide their specific logic into Tuscany. Created an Endpoint module to provide a provider implementation. Created an Endpoint wire to trap attempted calls over unresolved endpoints Separated off the Endpoint builder code into a new builder class. Same code but easier to identify. Added an endpoint collection to references Used the Endpoint in the wire builder in place of the old internal target structure. The logic is weaved in to the existing logic as follows. For references with no target, put the binding into reference binding as before I think it would be better to create an endpoint for the reference without target. There could be two cases, autowiring and binding with explicit URI to external services. A few examples will help, for example: reference name=myRef target=C1/S1 binding.x/ binding.y/ /reference reference name=myRef target=C1/S1 C2/S1 binding.x/ binding.y/ /reference reference name=myRef binding.x/ binding.y/ /reference reference name=myRef binding.x uri=http://x/ binding.y uri=http://y/ /reference Create an Endpoint for all explicit reference targets For resolved endpoints (Endpoints where the target is resolved) put the binding into reference bindings, i.e. the same as before For unresolved endpoints create an endpoint provider and a wire. We don't have unresolved targets in tuscany (except in the sca binding test) so should not happen. If you do put a target name in that can't be matched with a service you'll get a warning. If there is no Endpoint module on the classpath it will not create a provider or a wire hence disabling any Endpoint based processing. The Endpoint model will still be used though As part of this change I've updated the logic that looks for target names in binding uri. It's now applied to all binding types which I believe is what the spec says, There is though an issue here. I'll raise a separate thread. There are also a couple of thoughts I had. Can we make the CompositeBuilderImpl have just one constructor? Should builders be pluggable? I've used some of the CompoisteActivator functions in the EndpointWire that could do with moving into the activator interface. Simon
[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2277: - Attachment: TUSCANY-2277-Part2-New.patch Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1-New.patch, TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2-New.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3-New.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2277: - Attachment: TUSCANY-2277-Part3-New.patch Standardization of registering msg with monitor --- Key: TUSCANY-2277 URL: https://issues.apache.org/jira/browse/TUSCANY-2277 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2277-Part1-New.patch, TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2-New.patch, TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3-New.patch, TUSCANY-2277-Part3.patch Lokking at the monitors that are being hooked up with different parts of the code, found that we have some inconsistency interms of raising warning errors. In some places we throw exceptions and in other places we raise a warning. Here are some examples for the inconsistency... BaseConfigurationBuilderImpl.java Here we raise only a warning for URISyntaxException, should we not throw an exception too? BaseWireBuilderImpl.java Here we throw exceptions for IncompatibleInterfaceContractException, don't you think we also need to register this message in our monitor? In the same class, we raise a warning message for the PolicyRelated Exceptions, should we also throw an exception here? CompositeProcessor.java There are instances where we throw new ContributionReadException, i believe registering this msg with a monitor is also required as this is caused by incorrect user input. From Simon's comments on how we can go ahead with handling such instance, we will fix the issue as discussed http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tomcat deploy of samples fails
Hi, Which version of Tuscany are you trying? It seems that something went wrong in the bootstrap (we need to dig out the root cause of the exception). Can you also try on Tomcat 6.x? Thanks, Raymond -- From: Magnus Stoveland [EMAIL PROTECTED] Sent: Friday, May 16, 2008 7:04 AM To: tuscany-dev@ws.apache.org Subject: Tomcat deploy of samples fails I've successfully compiled the sample helloworld-ws-sdo-webapp into sample-helloworld-ws-sdo-webapp.war. But when I try to deply the .war to Tomcat 5.5.26, I get the following error: FAIL - Application at context path /sample-helloworld-ws-sdo-webapp could not be started. From the log: - Exception starting filter tuscany javax.servlet.ServletException: org.apache.tuscany.sca.implementation.node.webapp.NodeWebAppServletHost at org.apache.tuscany.sca.node.launcher.NodeServletFilter.init(NodeServletFilter.java:85) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:78) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4222) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:720) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) - Error filterStart Do I need any special configuration/setup to get the Tuscany Servlet Filter running properly? Magnus
Re: Tuscany support for Axis 1.4
Hi, I'm starting to look into the performance improvements in the JAXB/AXIOM data transformation. It seems that the Axis2 1.4 has done a lot of good work there. If possible, I would like to leverage the latest AXIOM and Axis2 code base ASAP. The dependency might be only AXIOM but mixing the versions of AXIOM could be very risky. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 15, 2008 3:00 AM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany support for Axis 1.4 On Wed, May 14, 2008 at 2:33 PM, Mike Edwards [EMAIL PROTECTED] wrote: Lou Amodeo wrote: Is there a plan for Tuscany to support Axis2 1.4? Lou, Any particular goodies that we can expect to get by moving up to Axis 1.4? Yours, Mike. Not sure if there are new functions that we need in 1.4 but the release does include _lots_ of bug fixes so i think it would be worth moving up. The main issues right now is I've just noticed there isn't a corresponding Apache Rampart release for 1.4 yet which is what we need for WS-Security, looks like its coming so guess we'll just have to wait a bit. ...ant
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
On Fri, May 16, 2008 at 1:04 PM, Simon Nash [EMAIL PROTECTED] wrote: Scott Kurz wrote: Why do we need to be so strict in comparing interfaces? Can't we argue essentially the same point in the case with we have a Java client w/ reference w/ Java intf with a binding.ws? So, following this logic, it's suggested that the NS calculated per-JAXWS for the Java intf must match the portType on the WS binding. So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL of an existing WS w/ wsimport, embedding a @WebService(name = ..., targetNamespace = ...)in the Java. Now the WS evolves and we take the new WSDL w/ portType in a new NS. Maybe a new operation is added but we don't care about it from our existing client. Why should we have to re-gen the Java to reflect the new TNS? Adding a new operation would be a compatible change to the interface and should not result in the interface's TNS changing. I'm imagining an organization rolls out a whole new deployment of some service, and changes the TNS in various WSDL/XSDs to reflect that this is version 2.0, or whatever, of the deployment. They wouldn't have to change the TNS, but they might want to, right? Also, someone using an older W2J tool may have an option to select a non-standard pkg when generating Java from WSDL, but the tool doesn't reflect this in the @WebService(... targetNamespace...). Do we really need to break them? This is easy to deal with by configuring the reference binding to refer to the WSDL binding that the client code is actually using to make the invocation. If the reference binding.ws doesn't specify any WSDL binding, the binding.ws's interface contract should be generated from the reference's interface.java. Maybe I'm reading into the discussion too much but I was assuming that being proposed was doing a similar sort of interface compatibility testing between the Java client's intf.java and the binding.ws WSDL intf contract. In other words, I thought we were getting at the point that, in Tuscany across the board, IDLs would only be considered as matching if they matched namespaces (the IDL-neutral equiv. of TNS, Java pkg, etc.). If this is not what others had in mind, then wrt to the interface compatibility testing being proposed, this case does differ from the promoted ref intf case and will be treated separately. That's one of the questions I was asking. Would people agree this is essentially the same case as the overridden, promoted intf, or is the argument that this specific case is a bit different ? It seems pretty similar to me. I mean, I can certainly see how it simplifies the runtime authors' lives to be strict about NS's when doing intf mapping... but do we really have a good reason to?What use case can we just not handle that would make us need this restriction? The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an incorrect namespace was sent on the wire because SCA did not detect the reference/service mismatch. This problem is caused by a mismatch in the WSDL binding rather than a mismatch in the Java interface. However, the specs say that the WSDL binding (including its namespace) is generated by applying the JAX-WS Java2WSDL mapping to the Java interface. If this algorithm doesn't produce the same namespace that's used by the service, the reference won't be able to interoperate with it. Simon There's another angle to view this from in which the error is not caused by a mismatch, per se, but rather by the fact that the intf.wsdl used to configure the promoted reference is not honored. Why is the Java2WSDL done at all, when the user has described the interface with a WSDL?So why does it matter that the Java2WSDL we would have done doesn't match the WSDL we have in hand? Scott
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
Scott Kurz wrote: On Fri, May 16, 2008 at 1:04 PM, Simon Nash [EMAIL PROTECTED] wrote: Scott Kurz wrote: Why do we need to be so strict in comparing interfaces? Can't we argue essentially the same point in the case with we have a Java client w/ reference w/ Java intf with a binding.ws? So, following this logic, it's suggested that the NS calculated per-JAXWS for the Java intf must match the portType on the WS binding. So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL of an existing WS w/ wsimport, embedding a @WebService(name = ..., targetNamespace = ...)in the Java. Now the WS evolves and we take the new WSDL w/ portType in a new NS. Maybe a new operation is added but we don't care about it from our existing client. Why should we have to re-gen the Java to reflect the new TNS? Adding a new operation would be a compatible change to the interface and should not result in the interface's TNS changing. I'm imagining an organization rolls out a whole new deployment of some service, and changes the TNS in various WSDL/XSDs to reflect that this is version 2.0, or whatever, of the deployment. They wouldn't have to change the TNS, but they might want to, right? If they do this when not necessary, they are accepting the need to also upgrade all the clients that talk to these services. Also, someone using an older W2J tool may have an option to select a non-standard pkg when generating Java from WSDL, but the tool doesn't reflect this in the @WebService(... targetNamespace...). Do we really need to break them? This is easy to deal with by configuring the reference binding to refer to the WSDL binding that the client code is actually using to make the invocation. If the reference binding.ws doesn't specify any WSDL binding, the binding.ws's interface contract should be generated from the reference's interface.java. Maybe I'm reading into the discussion too much but I was assuming that being proposed was doing a similar sort of interface compatibility testing between the Java client's intf.java and the binding.ws WSDL intf contract. In other words, I thought we were getting at the point that, in Tuscany across the board, IDLs would only be considered as matching if they matched namespaces (the IDL-neutral equiv. of TNS, Java pkg, etc.). OK, I think I understand now. You are talking about compatibilty checking between a reference's interface.java and the same reference's explicitly specified binding.ws WSDL binding. In this case, I think the namespace information should come from the reference's binding.ws WSDL binding and not from the interface.java, and should not be a problem if the interface.java has a different namespace. Applying the same reasoning to the promoted case, I think I was wrong when I said earlier that it's a problem if the namespace for the inner interface doesn't match the namespace for the outer interface. According to the rule proposed above, interface namespaces should always be ignored, so the interfaces would match. The binding.ws WSDL binding namespace would be derived from the outer interface, and any namespace information on the inner interface would not be used. If this is not what others had in mind, then wrt to the interface compatibility testing being proposed, this case does differ from the promoted ref intf case and will be treated separately. That's one of the questions I was asking. Would people agree this is essentially the same case as the overridden, promoted intf, or is the argument that this specific case is a bit different ? It seems pretty similar to me. I mean, I can certainly see how it simplifies the runtime authors' lives to be strict about NS's when doing intf mapping... but do we really have a good reason to?What use case can we just not handle that would make us need this restriction? The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an incorrect namespace was sent on the wire because SCA did not detect the reference/service mismatch. This problem is caused by a mismatch in the WSDL binding rather than a mismatch in the Java interface. However, the specs say that the WSDL binding (including its namespace) is generated by applying the JAX-WS Java2WSDL mapping to the Java interface. If this algorithm doesn't produce the same namespace that's used by the service, the reference won't be able to interoperate with it. Simon There's another angle to view this from in which the error is not caused by a mismatch, per se, but rather by the fact that the intf.wsdl used to configure the promoted reference is not honored. Yes, I agree with this now. See above. Why is the Java2WSDL done at all, when the user has described the interface with a WSDL?So why does it matter that the Java2WSDL we would have done doesn't match the WSDL we have in hand? In this case, no Java2WSDL should be done, as you say. Simon Scott
[jira] Created: (TUSCANY-2325) Schema validation does not register the exception with the Problem, yet Problem looks for it and finds it to be not-null
Schema validation does not register the exception with the Problem, yet Problem looks for it and finds it to be not-null Key: TUSCANY-2325 URL: https://issues.apache.org/jira/browse/TUSCANY-2325 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Environment: All Reporter: Hasan Muhammad Priority: Critical The following code exists in ValidatingXMLStreamReader /** * Report a error. * * @param problems * @param message * @param model */ private void error(String message, Object model, Object... messageParameters) { Problem problem = new ProblemImpl(this.getClass().getName(), contribution-validation-messages, Severity.ERROR, model, message, (Object[])messageParameters); monitor.problem(problem); } In this case, it does not register the exception with the problem. In the monitor code, we have this else if (problem.getSeverity() == Severity.ERROR) { if (problem.getCause() != null) { problemLogger.log(Level.SEVERE, problem.getMessageId(), problem.getCause()); } else { problemLogger.log(Level.SEVERE, problem.getMessageId(), problem.getMessageParams()); } It finds the cause to be not null, and simply logs the error like this ValidatingXML E SchemaError So either, the Reader should register the exception with problem, or the cause be explicitely initalized to null in the ProblemImpl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Tuscany support for Axis 1.4
Ant mentioned rampart is not ready yet. Doesen't that require us to wait? -Original Message- From: Raymond Feng [EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:14 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Tuscany support for Axis 1.4 Hi, I'm starting to look into the performance improvements in the JAXB/AXIOM data transformation. It seems that the Axis2 1.4 has done a lot of good work there. If possible, I would like to leverage the latest AXIOM and Axis2 code base ASAP. The dependency might be only AXIOM but mixing the versions of AXIOM could be very risky. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 15, 2008 3:00 AM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany support for Axis 1.4 On Wed, May 14, 2008 at 2:33 PM, Mike Edwards [EMAIL PROTECTED] wrote: Lou Amodeo wrote: Is there a plan for Tuscany to support Axis2 1.4? Lou, Any particular goodies that we can expect to get by moving up to Axis 1.4? Yours, Mike. Not sure if there are new functions that we need in 1.4 but the release does include _lots_ of bug fixes so i think it would be worth moving up. The main issues right now is I've just noticed there isn't a corresponding Apache Rampart release for 1.4 yet which is what we need for WS-Security, looks like its coming so guess we'll just have to wait a bit. ...ant
[jira] Resolved: (TUSCANY-2295) Tuscany should allow plugins to load their schemas instead of tuscany schema
[ https://issues.apache.org/jira/browse/TUSCANY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-2295. -- Resolution: Fixed Fixed by using DefaultValidationSchemaExtensionPoint that will allow modules to contribute validation schemas by specifying a META-INF\services\org.apache.tuscany.sca.contribution.processor.ValidationSchema file with a list of schemas as its contents. Tuscany should allow plugins to load their schemas instead of tuscany schema Key: TUSCANY-2295 URL: https://issues.apache.org/jira/browse/TUSCANY-2295 Project: Tuscany Issue Type: Improvement Components: Java SCA Embedded Runtime Environment: All Reporter: Hasan Muhammad Assignee: Luciano Resende Priority: Critical Fix For: Java-SCA-Next Looking at the following code, the schema path is hardcoded, which means that plugins need to change this code everytime to load their schemas. Tuscany should allow plugins to point to their schemas without modifying this code // Allow privileged access to load resource. Requires RuntimePermssion in security policy. URL schemaURL = AccessController.doPrivileged(new PrivilegedActionURL() { public URL run() { return ReallySmallRuntimeBuilder.class.getClassLoader().getResource(tuscany-sca.xsd); } }); Loading schemas should be an extension point. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.