Re: problem with binding-corba-runtime test running with my local changes... need a different ORB?
Thanks Simon. You were right.. I forgot that I had overwritten the TestOperation setOutputType() call to effectively no-op, so I wasn't building the response correctly. I'll share one thing I did learn (in case someone or myself has to search email for a problem like this in the future). By running with the IBM JDK, you get an "orbtrc" trace file, and by adding this to my maven command line: -DargLine="-Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true" it gets a detailed trace with eyecatcher. This let me see pretty clearly that my "app" data wasn't in the "bad" IIOP payload..just the header/context/etc. info. Scott
Re: 2.x - moving SCABindingMapper
On Thu, Feb 10, 2011 at 1:54 PM, Mike Edwards wrote: > On 10/02/2011 12:15, Simon Laws wrote: >> >> I'd like to move the "SCABindingMapper " interface from >> >> binding-sca-runtime / org.apache.tuscany.sca.binding.sca.provider >> >> to somewhere like. >> >> core-spi / org.apache.tuscany.sca.provider >> >> So that people wanting to implement a default binding mapper don't >> have to have a dependency on a runtime module. >> >> Anyone see any issues? >> >> Simon >> > Simon, > > +1 from me > > There are a few more of this ilk that it would be nice to get around to as > well. > > > Yours, Mike. > Yes, agreed. Here's the next ones I notice assembly / org.apache.tuscany.sca.assembly.impl Provides model implementations that providers of extensions will likely want to extend so I assume this is currently deemed to be part of the SPI. assembly / org.apache.tuscany.sca.interfacedef.impl Contains things like DataTypeImpl which I can imagine will be required directly by people writing extensions (many of our extensions use it) Just seems odd having these called impl when we usually differentiate between interfaces and impl in this way so that the impl doesn't have to be exported. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: problem with binding-corba-runtime test running with my local changes... need a different ORB?
On Wed, Feb 9, 2011 at 10:32 PM, Scott Kurz wrote: > Before trying to tackle > https://issues.apache.org/jira/browse/TUSCANY-3832 > I was trying to deal with the fact that I broke the > binding-corba-runtime module tests, hitting a CORBA MARSHAL exception. > > This module does use a mock 'TestOperation' (which implements > Operation which I'd changed in my patch), leading me to think maybe I > was dealing with an incompatible change serialization type of issue. > > But I'm kind of stuck. I don't see us actually passing TestOperation > as a parameter. In looking at the IDL I don't see why I'd need to > do another idl2java, but maybe I'm wrong. > > I don't know CORBA all that well and was wondering if anyone had any ideas > > When I use the Sun JDK (1.6) I see: > org.omg.CORBA.MARSHAL: vmcid: SUN minor code: 207 completed: No > > When I use the IBM JDK (1.6): > org.omg.CORBA.MARSHAL: No available data: Request 14:read beyond > end of data. No fragments available. vmcid: OMG minor code: 8 > completed: Maybe > > Here are the failed tests: > test_primitivesSetter(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase) > test_arraysSetter(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase) > test_TestObject_setStruct(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase) > test_enums(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase) > test_nonCorbaServants(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase) > test_arraysPassing(org.apache.tuscany.sca.binding.corba.testing.CorbaServantTestCase) > > I'm doing an offline mvn so I don't overwrite my local changes to > other modules. > > I found this post suggesting the Sun JDK 207 code could be addressed > by using the IBM ORB in the Sun JDK > http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14036393 > but I'm guessing that using the IBM JDK is just as good. > > Any ideas?? > > Thanks, > Scott > Not sure Scott but from "No available data: Request 14:read beyond end of data." it does sound like it's expecting more data than it's getting. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Closed: (TUSCANY-3834) Exceptions in application code during @Destroy seem to cause the runtime to stop without trying to stop all of the components
[ https://issues.apache.org/jira/browse/TUSCANY-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3834. --- Resolution: Fixed Fix Version/s: Java-SCA-1.x Java-SCA-2.x Changes committed to 1.x and 2.x > Exceptions in application code during @Destroy seem to cause the runtime to > stop without trying to stop all of the components > - > > Key: TUSCANY-3834 > URL: https://issues.apache.org/jira/browse/TUSCANY-3834 > Project: Tuscany > Issue Type: Bug > Components: SCA Java Runtime >Affects Versions: Java-SCA-2.x, Java-SCA-1.x > Environment: All >Reporter: Simon Laws >Assignee: Simon Laws > Fix For: Java-SCA-2.x, Java-SCA-1.x > > > This affects 1.x and probably affects 2.x > It looks like the runtime doesn't continue shutting down if any of the > operations marked @Destroy throws an exception. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
2.x module NOTICE and LICENSE files
I note that the default maven-remote-resources-plugin configuration now generates default NOTICE and LICENSE files in each modules target/maven-shared-archive-resources directory. These files are then copied into the META-INF directory of each module. As we have hand crafted NOTICE and LICENSE files in some modules, e.g. assembly-xsd, you end up with module jars containing two sets of NOTICE and LICENSE files which are different. My first reaction would be to turn off the auto generated versions. Thoughts? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: 2.x - moving SCABindingMapper
On 10/02/2011 12:15, Simon Laws wrote: I'd like to move the "SCABindingMapper " interface from binding-sca-runtime / org.apache.tuscany.sca.binding.sca.provider to somewhere like. core-spi / org.apache.tuscany.sca.provider So that people wanting to implement a default binding mapper don't have to have a dependency on a runtime module. Anyone see any issues? Simon Simon, +1 from me There are a few more of this ilk that it would be nice to get around to as well. Yours, Mike.
Re: 2.x - moving SCABindingMapper
Sounds ok, the package doesn't seem totally perfect but i can't see anything better so that one seems good enough to me ...ant On Thu, Feb 10, 2011 at 12:15 PM, Simon Laws wrote: > I'd like to move the "SCABindingMapper " interface from > > binding-sca-runtime / org.apache.tuscany.sca.binding.sca.provider > > to somewhere like. > > core-spi / org.apache.tuscany.sca.provider > > So that people wanting to implement a default binding mapper don't > have to have a dependency on a runtime module. > > Anyone see any issues? > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
2.x - moving SCABindingMapper
I'd like to move the "SCABindingMapper " interface from binding-sca-runtime / org.apache.tuscany.sca.binding.sca.provider to somewhere like. core-spi / org.apache.tuscany.sca.provider So that people wanting to implement a default binding mapper don't have to have a dependency on a runtime module. Anyone see any issues? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[DISCUSS] Revisiting documentation
This thread is destined for the following topics: - how should documentation look like in the source distribution - improvements for documentation on the new website - ways to split documentation in a way that it is easier to follow and understand - documentation maintenance - additions for the developer documentation on top of the user doc Feel free to add anything I've missed.
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
>From my latest experience I'd go with 2 required launchers for the samples: 1. the tuscany shell - it's so easy to start with 'mvn tuscany:run' or with the provided scripts. The fact that you can interactively invoke deployed services has a huge plus for user experience. One mention would be that at the moment the shell does not support webapps but that might not be hard to achieve. 2. a unit test - very useful when the user imports the sample in it's own IDE. Gives him the ability to start the runtime, perform debug (if interested in a step-by-step execution) really easy. Also, it helps us to keep track of the broken samples. Regarding documentation, I don't have an idea on how to structure it.. to be honest, I don't know where to start from and I think this is part of a more general topic involving more aspects like the website changes we'll have to do soon. I'll start a separate topic for this to gather ideas. I'm not keen into having an ant build file in every sample. If someone wants to use ant, shouldn't they download all dependencies manually? Won't they use maven for that task anyway? What about ivy? On Thu, Feb 10, 2011 at 11:10 AM, ant elder wrote: > On Tue, Feb 8, 2011 at 7:18 PM, ant elder wrote: > > On Tue, Feb 8, 2011 at 1:26 PM, Simon Laws > wrote: > >> On Tue, Feb 8, 2011 at 12:58 PM, ant elder wrote: > >>> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga > wrote: > Maybe it's time to take a decision so we all know where we're heading. > From > what I see we've got 2 options: > 1/ do the release now according to Mike's suggestion > 2/ discuss documentation and sample structure and launchers, review > and > update all samples accordingly, do the release > I tend to go with 1/ as it gives us the possibility to do more > frequent > releases, to incrementally improve the quality of our samples and > doesn't > imply a big effort which we don't afford at the moment. However, I'm > not > opposing to 2/ if everybody else agrees on this option as I'm not > directly > affected if the release is shipped in 1 week or 1 month. > > >>> > >>> I don't mind making an RC3 according to the 1/ approach this weekend, > >>> i have everything set up still from RC1+2 so it wont take too long. > >>> But i would first like to see a few others agree to the approach as > >>> I'd like to try to avoid spending more time on another RC only to have > >>> someone complain that some sample is missing and want yet another > >>> respin. > >>> > >>> ...ant > >>> > >> > >> If people want to see Beta2 go out now that fine by me but we've had > >> some good discussions on the samples over the last few days so it > >> would be good to get straight on with a Beta3 and make samples the > >> focus of that. > >> > >> Simon > >> > > > > Ok so views on both sides, to move this along how about: > > > > - take a branch from current trunk for the beta2 RC3, maybe or not I > > or someone will actually go ahead and do the work to make a release > > from that branch > > - in trunk go ahead with the new sample approach, so move everything > > somewhere else, fix them up and move back to trunk/samples as they > > become ready, and once thats done do a beta3 release (or if beta2 > > never happen call this beta2). > > > > If no one objects I'll do this is a couple of days. While we wait > > there's nothing stopping anyone continuing to work on the current > > trunk samples. > > > > ...ant > > > > I have now done these. There's a beta2 branch for the release, and all > the trunk samples are now in contrib/samples and the helloworld sample > is in unreleased/samples where we can continuing with making it like > we want. > > ...ant >
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
On Tue, Feb 8, 2011 at 7:18 PM, ant elder wrote: > On Tue, Feb 8, 2011 at 1:26 PM, Simon Laws wrote: >> On Tue, Feb 8, 2011 at 12:58 PM, ant elder wrote: >>> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga wrote: Maybe it's time to take a decision so we all know where we're heading. From what I see we've got 2 options: 1/ do the release now according to Mike's suggestion 2/ discuss documentation and sample structure and launchers, review and update all samples accordingly, do the release I tend to go with 1/ as it gives us the possibility to do more frequent releases, to incrementally improve the quality of our samples and doesn't imply a big effort which we don't afford at the moment. However, I'm not opposing to 2/ if everybody else agrees on this option as I'm not directly affected if the release is shipped in 1 week or 1 month. >>> >>> I don't mind making an RC3 according to the 1/ approach this weekend, >>> i have everything set up still from RC1+2 so it wont take too long. >>> But i would first like to see a few others agree to the approach as >>> I'd like to try to avoid spending more time on another RC only to have >>> someone complain that some sample is missing and want yet another >>> respin. >>> >>> ...ant >>> >> >> If people want to see Beta2 go out now that fine by me but we've had >> some good discussions on the samples over the last few days so it >> would be good to get straight on with a Beta3 and make samples the >> focus of that. >> >> Simon >> > > Ok so views on both sides, to move this along how about: > > - take a branch from current trunk for the beta2 RC3, maybe or not I > or someone will actually go ahead and do the work to make a release > from that branch > - in trunk go ahead with the new sample approach, so move everything > somewhere else, fix them up and move back to trunk/samples as they > become ready, and once thats done do a beta3 release (or if beta2 > never happen call this beta2). > > If no one objects I'll do this is a couple of days. While we wait > there's nothing stopping anyone continuing to work on the current > trunk samples. > > ...ant > I have now done these. There's a beta2 branch for the release, and all the trunk samples are now in contrib/samples and the helloworld sample is in unreleased/samples where we can continuing with making it like we want. ...ant
Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module
I'm calling it as the last line of RMIServiceBindingProvider#stop. On Thu, Feb 10, 2011 at 10:46 AM, Simon Laws wrote: > On Wed, Feb 9, 2011 at 9:44 PM, Florian Moga wrote: > > Hi Mike, > > Thanks for the tips. I've debugged through it and it turns out that the > > stop() method of DefaultRMIHost doesn't even get called. I've done some > > local changes that call that stop method (even though it's really ugly as > I > > had to use casting because the RMIHost interface doesn't have a stop > method > > and ExtensibleRMIHost doesn't provide a stop method through it's public > > API). Even with those hacks, the problem is still reproducible... I'm > trying > > to figure out a way of monitoring what's happening in the concurrent > > environment as simple debugging isn't that helpful in reproducing it. > > Florian > > > > > > Hi Florian > > At what point is the stop method now called with your changes? > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
Re: Issues building Apache Tuscany SCA iTest Distribution Launcher Embedded JSE module
On Wed, Feb 9, 2011 at 9:44 PM, Florian Moga wrote: > Hi Mike, > Thanks for the tips. I've debugged through it and it turns out that the > stop() method of DefaultRMIHost doesn't even get called. I've done some > local changes that call that stop method (even though it's really ugly as I > had to use casting because the RMIHost interface doesn't have a stop method > and ExtensibleRMIHost doesn't provide a stop method through it's public > API). Even with those hacks, the problem is still reproducible... I'm trying > to figure out a way of monitoring what's happening in the concurrent > environment as simple debugging isn't that helpful in reproducing it. > Florian > > Hi Florian At what point is the stop method now called with your changes? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [DISCUSS] SCA AllowsPassByReference spec clarification
On Wed, Feb 9, 2011 at 11:57 AM, Simon Nash wrote: > ant elder wrote: >> >> On Wed, Feb 9, 2011 at 10:56 AM, Simon Nash wrote: >>> >>> ant elder wrote: On Tue, Feb 8, 2011 at 2:12 PM, Simon Nash wrote: > > ant elder wrote: >> >> On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash wrote: >>> >>> Mike Edwards wrote: On 08/02/2011 10:08, ant elder wrote: > > On Tue, Feb 8, 2011 at 9:56 AM, Simon > Laws > wrote: >>> >>> I can see that relaxing the current spec restrictiveness would be >>> difficult as things would break in some circumstances, but it >>> does >>> seem like there will be situations when the assembler really >>> knows >>> it >>> would be fine but even so they can't get the PBR optimization >>> because >>> the impls aren't coded with the @AllowsPassByReference >>> annotation. >>> Isn't that a similar situation to where the remotable annotation >>> was >>> added to the interface SCDL element, and there could be a similar >>> allowsPassByReference attribute added to the service and >>> reference >>> SCDL elements? >>> >>> ...ant >>> >> Hi Ant. >> >> Can you say a bit more about the "situations when the assembler >> really >> knows it would be fine"? Reading previous posts to this thread >> doesn't >> convince me that that is the case. >> >> Simon >> > We'll have to wait for Raymond to see if thats anything like his > situation, but there are lots of ways the assembler could know, he > may > well have full access to the source but still be limited in making > any > updates due to production lifecycle or control issues. This seems > like > a similar situation as Java EE appservers have and I believe many > appservers have mechanisims for overriding and enabling PBR support > in > their ORB or EJB modules to gain performance benefits. > > ...ant > Folks, One possibility to start with would be to add a Tuscany extension attribute which could be used by an Assembler to mark a particular service and/or reference as "AllowsPassByReference". This would cope with the situation where the Java components are not marked, but the assembler knows enough about them to know that the marking is correct. Yours, Mike. >>> I'm very dubious about the wisdom of this. I bear the scars from a >>> previous life of a situation where a flag was added to an enterprise >>> application server (which shall remain nameless) to override the PBV >>> semantics required by the architecture in the interests of >>> performance >>> optimization when the user of the product "knew" that using PBR would >>> be safe. Needless to say, on a number of occasions this flag was set >>> incorrectly and this resulted in accusations of runtime bugs that >>> were >>> eventually shown after laborious debugging to have been caused by the >>> PBR "optimization" being enabled incorrectly. >>> >>> IMO it's the implementation's responsibility to make the correct >>> assertions about whether it's PBR-safe. Implementations that don't >>> assert @AllowsPassByReference will have worse performance than those >>> that do support it. If a component developer cares about >>> performance, >>> they need to code their implementation to play by the APBR rules and >>> turn on the flag to say they have done that. If the flag isn't >>> turned >>> on by the implementer, I can't imagine that an assembler will have a >>> detailed enough knowledge of the implementation to be able to safely >>> provide the APBR assertion that the component developer couldn't/ >>> wouldn't/didn't provide. >>> >>> (Deep breath) Now I feel better after getting that off my chest :-) >>> >>> Simon >>> >>> >> As an attempt to justify this: we don't have any samples that use >> @AllowsPassByReference, and I don't recall ever seeing many in Tuscany >> or elsewhere that do, but i think all those samples i've seen probably >> would have worked fine with it as they don't modify anything >> afterwards. I think it would be relatively uncommon to code something >> that would be unsuitable for using @AllowsPassByReference. So Joe >> developer writing his code probably wont use @AllowsPassByReference >> either, may not even know it exists, and any performance issues likely >> wont get found until much later when running in a production system by >> which time it can be very har
