Re: Working on the release 1.3 branch
On Mon, Jun 16, 2008 at 1:09 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi I've changed the version number and got rid of the DISCLAIMER files. I'm looking at the getting the distribution build working, checking LICENSE/NOTICE and dependency versions before cutting an RC0 for us to look at. If people want to help out with this pre-RC0 release prep then feel free and just go ahead. If you want to fix functional issues with the release, e.g. a good indicator is if you are going to make the same change to trunk, can you also raise a JIRA against 1.3 to cover the change so I can see what's being fixed. Thanks Simon It looks like the binary distribution build is broken in the 1.3 branch, i think related to the change i did back in r663551http://svn.apache.org/viewvc?view=revrevision=663551. I'm still investigating but it maybe best to go back to using the really old shade plugin for now in the branch so it doesn't hold up anything in the 1.3 release. ..ant
Re: Working on the release 1.3 branch
On Mon, Jun 16, 2008 at 3:22 PM, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 3:17 PM, ant elder [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 1:09 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi I've changed the version number and got rid of the DISCLAIMER files. I'm looking at the getting the distribution build working, checking LICENSE/NOTICE and dependency versions before cutting an RC0 for us to look at. If people want to help out with this pre-RC0 release prep then feel free and just go ahead. If you want to fix functional issues with the release, e.g. a good indicator is if you are going to make the same change to trunk, can you also raise a JIRA against 1.3 to cover the change so I can see what's being fixed. Thanks Simon It looks like the binary distribution build is broken in the 1.3 branch, i think related to the change i did back in r663551http://svn.apache.org/viewvc?view=revrevision=663551. I'm still investigating but it maybe best to go back to using the really old shade plugin for now in the branch so it doesn't hold up anything in the 1.3 release. ..ant How broken is it? It its a day to fix then I suggest we do it. If it's a week then I agree lets use the old one. Simon A lot of dependency jars aren't getting included in the binary distribution so samples will be broken. Not sure why not yet so i can't say how long it will take to fix it :) I worried that people might be trying to test things in 1.3 now so a broken binary distribution would cause some inconvenience. What about if i revert it in the branch now so as to not hinder testing and if it can be fixed then put it back in the branch then? ...ant
com.example classes included in the databinding extension jars
I'm having a lot of trouble getting the bundle jar to work in the 1.3 branch as databinding-jaxb and databinding-jaxb-axiom both include the class com.example.ipo.jaxb.Address which causes the shade plugiin to fail with a duplicate class exception. Can anyone see any way to either stop these classes being included in the databinding jars, or to have the old shade plugin filter them out (or get the new shade plugin to include all the other dependencies)? Or if not how about moving the unit tests out into an itest so the classes don't get included? ...ant
IMPORTANT: TLP SVN move tonight
The Tuscany SVN should be moving to the TLP location tonight so everyone will need to switch to the new location, which will be https://svn.apache.org/repos/asf/tuscany. You can change your local copy with svn switch --relocate. ...ant
Re: IMPORTANT: TLP SVN move tonight
I hope so yes, but its not yet clear exactly when the DNS changes will be done. Will let you know as soon as i know anything. ...ant On Mon, Jun 16, 2008 at 11:49 PM, Raymond Feng [EMAIL PROTECTED] wrote: Thanks for the update. What about our web site? Is it going to be hosted at http://tuscany.apache.org soon? Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Monday, June 16, 2008 3:06 PM To: tuscany-dev tuscany-dev@ws.apache.org Subject: IMPORTANT: TLP SVN move tonight The Tuscany SVN should be moving to the TLP location tonight so everyone will need to switch to the new location, which will be https://svn.apache.org/repos/asf/tuscany. You can change your local copy with svn switch --relocate. ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards [EMAIL PROTECTED] wrote: snip b) A variety of functional components, that represent sets of coherent functions. Each consists of a series of the basic modules, aggregated together. Their function in life is to assist developers of applications that embed some level of Tuscany capability (including tools, Tuscany itself and so on) These are probably not agreed by folk today - we have work to do here to define these. You demonstrate the problem in your example above - you want Basic Web Services separate from Web Services Security - but for an end user, the step from using the first to using the second is a trivial addition of @required=integrity to the SCDL. Anyone care to have a go at defining these compoennts? Thats taking a different tack to the launcher appraoch but maybe we need both and this approach would be easier for embedders so ok to move things long I'll try an initial stab at it: 1) tuscany-scdl4j An aggregated jar containing _all_ the model and stax processor classes which can be used by tools etc for for reading/writing scdl without booting a runtime. It includes all the extension classes as they generally don't drag in any other dependencies so its not really any problem to incude them. The only required dependency would be on stax, maybe some optional dependencies like wsdl4j as the wsdl extension may need that. Not sure if any of the contribution modules should be included, would have to investigate that a bit. 2) tuscany-runtime An aggregated jar containing the minimum modules to start a runtime able to run something like the simple calculator sample. Has dependencies on tuscany-scdl4j and minimal other jars - geronimo-commonj_1.1_spec, cglib, jaxb etc. 3) tuscany-api An aggregated jar containing everything tuscany/sca applications might need to compile - sca-api, SCADomain class from host-embedded, node2-api, jsp taglib etc. Has no external dependencies. 4) Single jars for all the binding and implementation type extensions which add the capability to the minimal tuscany-runtime. We're already starting to get these with the way extensions are being structured nowadays - binding-jsonrpc-runtime, binding-ejb-runtime, implementation-widget-runtime etc. The above would make life for embedders much easier like the Tuscany-Geronimo integration code (or JBoss when they come along) less likely to break over releases as we add remove modules. ...ant
Re: Tuscany Board Report for June
Last call for any input on what i'll be submitting tomorrow: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/June+2008 ...ant On Tue, Jun 10, 2008 at 9:59 AM, ant elder [EMAIL PROTECTED] wrote: I need to submit our ASF board report by next Monday. I've created a wiki page - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/June+2008 - please add anything you want mentioned. ...ant
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
Trunk is now 1.4-SNAPSHOT in r667767 and a fresh build runs ok for me. Based on all this thread 1.4-SNAPSHOT isn't perfect but seemed what there was best consensus for right now. Feel free to revisit and I'd be happy to do the work to change trunk version to something else if anyone can get consensus on something else. ...ant On Fri, Jun 13, 2008 at 9:45 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: On 6/13/08, ant elder [EMAIL PROTECTED] wrote: Are the OSGI real versions required to be numeric, which would also mean 1.x wouldn't work so well as a version for OSGi right? Yes, the versions need to be numeric, 1.x wont work. ...ant On Fri, Jun 13, 2008 at 9:24 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I am not sure how relevant this is, but in the context of versioning Tuscany for OSGi, Tuscany modules are being built as OSGi bundles with real versions (eg. the current build uses 2.0). The version used is not currently derived from the maven version, instead it is specified independently as a property in modules/pom.xml - so it won't actually break if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become less obvious to OSGi users what version a Tuscany build really is. We will need a real version for the snapshot builds for building OSGi bundles regardless of whether we use that as the version for maven. The question is whether we need OSGi build versioning to be consistent with maven versions - OSGi users building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4 release, while non-OSGi users as you say may expect to use the latest SNAPSHOT. Anyway, I just thought I will point this out, I dont actually mind either way. On 6/13/08, ant elder [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 9:41 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant I'd prefer the next logical number, 1.3 for example. I still think plain SNAPSHOT would be simplest but as no one else seems to like that I think I agree with this - the next logical number seems better than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT when the 1.3 branch is taken, do say if you really don't like this but its what we've been doing most of the time in the past so i hope most can live with it. ...ant I've been asked off list to highlight an issue that may not have been clear from whats already been said in this thread. If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to date with the latest code will use that version in their dependencies. They may not pay that close attention to the dev list so when we create the branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the users dependencies will still use 1.4-SNAPSHOT but now instead of getting the latest code they're getting the stable branch code. One way this could be avoided is by using a trunk version of simply SNAPSHOT. Is anyone really against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? ...ant -- Thank you... Regards, Rajini -- Thank you... Regards, Rajini
[jira] Assigned: (TUSCANY-2391) Tuscany SCA support in the Geronimo Admin Console
[ https://issues.apache.org/jira/browse/TUSCANY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-2391: -- Assignee: ant elder Tuscany SCA support in the Geronimo Admin Console - Key: TUSCANY-2391 URL: https://issues.apache.org/jira/browse/TUSCANY-2391 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Reporter: Thilina Buddhika Assignee: ant elder Attachments: geronimo_ACE.zip This is the primary implementation of this Admin Console Extension. It does not contain any functionality related to Tuscany. But it is intended to use this as the basis for developing the ACE. The patch contains the source, and provides a maven build file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2391) Tuscany SCA support in the Geronimo Admin Console
[ https://issues.apache.org/jira/browse/TUSCANY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605074#action_12605074 ] ant elder commented on TUSCANY-2391: Patch applied to your sandbos area at: https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/thilina/geronimo_ACE/ It tried building and deploying to Geronimo 2.1.1 and it appears in the admin console and runs. Cool! Tuscany SCA support in the Geronimo Admin Console - Key: TUSCANY-2391 URL: https://issues.apache.org/jira/browse/TUSCANY-2391 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Reporter: Thilina Buddhika Assignee: ant elder Attachments: geronimo_ACE.zip This is the primary implementation of this Admin Console Extension. It does not contain any functionality related to Tuscany. But it is intended to use this as the basis for developing the ACE. The patch contains the source, and provides a maven build file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Updating the Geronimo Tuscany plugin to work with Geronimo 2.1
I've tried the Tuscany-Geronimo integration code [1] with Geronimo 2.1.1 releases and it doesn't work anymore. Could anyone help or say what is required to get it working again? This would be useful for a GSoC student whos writing a Gernimo console extension to manage SCA apps - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console TIA, ...ant [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/
Re: Updating the Geronimo Tuscany plugin to work with Geronimo 2.1
Following the instructions at: https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/README.TXTwhen i do step (3) it says: Installation FAILED: A plugin configuration must include one plugin artifact, not 0 Looking in the geronimo-plugin.xml at https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/tuscany-tomcat/src/main/resources/META-INF/geronimo-plugin.xmlit only mentions Geronimo version 2.0.1, 2.0.2 and 2.0.3-SNAPSHOT so i guessed that means its not ready for 2.1.1 right? If thats the case is there any doc anywhere on what might be needed to update it? ...ant On Sat, Jun 14, 2008 at 5:38 PM, David Jencks [EMAIL PROTECTED] wrote: Could you give us some idea what problems you are having? Most likely you'll need a 2.1 to 2.1.1 adapter plugin (not yet written or in svn AFAIK) and possibly some other modifications. thanks david jencks On Jun 14, 2008, at 6:33 AM, ant elder wrote: I've tried the Tuscany-Geronimo integration code [1] with Geronimo 2.1.1 releases and it doesn't work anymore. Could anyone help or say what is required to get it working again? This would be useful for a GSoC student whos writing a Gernimo console extension to manage SCA apps - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console TIA, ...ant [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
On Tue, Jun 10, 2008 at 9:41 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant I'd prefer the next logical number, 1.3 for example. I still think plain SNAPSHOT would be simplest but as no one else seems to like that I think I agree with this - the next logical number seems better than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT when the 1.3 branch is taken, do say if you really don't like this but its what we've been doing most of the time in the past so i hope most can live with it. ...ant I've been asked off list to highlight an issue that may not have been clear from whats already been said in this thread. If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to date with the latest code will use that version in their dependencies. They may not pay that close attention to the dev list so when we create the branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the users dependencies will still use 1.4-SNAPSHOT but now instead of getting the latest code they're getting the stable branch code. One way this could be avoided is by using a trunk version of simply SNAPSHOT. Is anyone really against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? ...ant
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
Are the OSGI real versions required to be numeric, which would also mean 1.x wouldn't work so well as a version for OSGi right? ...ant On Fri, Jun 13, 2008 at 9:24 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I am not sure how relevant this is, but in the context of versioning Tuscany for OSGi, Tuscany modules are being built as OSGi bundles with real versions (eg. the current build uses 2.0). The version used is not currently derived from the maven version, instead it is specified independently as a property in modules/pom.xml - so it won't actually break if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become less obvious to OSGi users what version a Tuscany build really is. We will need a real version for the snapshot builds for building OSGi bundles regardless of whether we use that as the version for maven. The question is whether we need OSGi build versioning to be consistent with maven versions - OSGi users building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4 release, while non-OSGi users as you say may expect to use the latest SNAPSHOT. Anyway, I just thought I will point this out, I dont actually mind either way. On 6/13/08, ant elder [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 9:41 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant I'd prefer the next logical number, 1.3 for example. I still think plain SNAPSHOT would be simplest but as no one else seems to like that I think I agree with this - the next logical number seems better than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT when the 1.3 branch is taken, do say if you really don't like this but its what we've been doing most of the time in the past so i hope most can live with it. ...ant I've been asked off list to highlight an issue that may not have been clear from whats already been said in this thread. If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to date with the latest code will use that version in their dependencies. They may not pay that close attention to the dev list so when we create the branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the users dependencies will still use 1.4-SNAPSHOT but now instead of getting the latest code they're getting the stable branch code. One way this could be avoided is by using a trunk version of simply SNAPSHOT. Is anyone really against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? ...ant -- Thank you... Regards, Rajini
Re: JMS transport specs/documentation
On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera [EMAIL PROTECTED] wrote: Hi Andreas I was wondering whether there is somewhere a specification or documentation that gives a clear overview of what types of messages Synapse's JMS transport is supposed to accept and how it should process these messages. More precisely I'm looking for a document that contains requirements such as If the incoming message is a BytesMessage and has a 'Content-Type' property, then the transport ... etc. Is there already something like that? Sorry, there isn't much external documentation yet..except in my head :-) .. however, I have been planning to update the JMS transport to handle JTA transactions for sometime, and I also wanted to change the design to support both JMS 1.0 and 1.1 in a better way. Some of the current issues we have came about as we came across a user who wanted JMS 1.0 support, at which point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1). We also have plans to adhere to the proposed binding for SOAP over JMS specificationhttp://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/[EMAIL PROTECTED]. At the same time, we need to update our code to not use setMessageListener() etc. which the newer JEE app servers (such as WebSphere) does not allow.. If not, are there people who are interested in helping to write this kind of specification? Note that I believe that the current behavior of the JMS transport is not always appropriate. E.g. a BytesMessage with Content-Type 'text/plain; charset=...' produces a binary wrapper, while I would expect a text wrapper. Therefore the specs to be written would focus on the to-be situation rather than the as-is situation. I would certainly be very interested to keep working on the JMS transport and I believe that with your help and that of any others in the community, we could really improve the current implementation to be much better asankha How about also something like an SCA compatibility mode so Synapse could sit in front of Tuscany/SCA JMS services? It would mainly be just setting some header properties. I'm mostly a lurker on the Synapse list these days but i could help from the SCA specification and Tuscany interop side of things. ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Fri, Jun 13, 2008 at 3:50 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: So just to be clear on what is being suggested this would be like the launcher we used to have back in M2 days right? ...ant No, the M2 launcher mixed too many different aspects: a) load the Tuscany JARs b) download then from the network as necessary b) launch your application code c) turn a client into a a 'client component' I am talking about what's currently demonstrated in: samples/calculator-distributed, in LaunchCalculatorNodeA or tutorial/store-client, in LaunchStoreClient for example, which only address (a). -- Jean-Sebastien Fair enough, i think we'd all be a bit nervous about trying b) download them from the network as necessary again :) ...ant
Re: Tuscany support for Axis 1.4
On Mon, Jun 9, 2008 at 10:17 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 1:12 PM, Lou Amodeo [EMAIL PROTECTED] wrote: Is there a plan for Tuscany to support Axis2 1.4? Axis2 1.4 and the associated wss4j and rampart releases for 1.4 are all out and available in the Maven repositories now. I've still a couple of issues to resolve to get everything in the build working with 1.4 but hope to have those fixed in the next day or 2 so would like to move up to 1.4 then This isn't going so well so I'm wondering if it would be better to NOT move up to Axis2 1.4 for the SCA 1.3 release. The are still some minor issues that are more of an inconvenience eg the way our soap/jms support is configured causes a big ugly stacktrace in samples that don't incude the JMS API now, but the main problem is with ws-security not working yet and when that is fixed a bug in WSS4J we'll like hit which may need a new release to fix [1]. How would people feel about staying on Axis2 1.3 for now, i know there's a dessire to get the latest versions of XmlSchema and AXIOM but will it break anything in our 1.3 release if we don't do that? ...ant [1] http://apache.markmail.org/message/2t7kdnf2tw33sphg
Re: SVN build process.
20 minutes! what sort of super machine do you have, its approaching an hour on my machine! I do agree with the principal though. I think one of the problems is its just getting so big we try to take short cuts by not always building everything, in the restructuring of future releases thats being talked about on other threads maybe we should try to break up the build somehow so some parts can be more independent parts of the build somehow to make it a bit smaller and faster. ...ant On Thu, Jun 12, 2008 at 10:15 AM, Giorgio Zoppi [EMAIL PROTECTED] wrote: Hi, i've a proposal for current svn. We could make most of our effort to make the svn compile. I suggest to trying a fresh build before committing meaniful things and after committing. It's matter of 20 minutes but it saves us more times. If doens't compile, you might fix or disable what it doens't compile. For example yesterday the corba tests module didn't work from a fresh build. Ciao, Giorgio. --- Venceremos adelante, o victoria o muerte!
Re: Test failure: org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()
I can confirm that the test works ok now for me. ...ant On Thu, Jun 12, 2008 at 11:33 AM, Simon Nash [EMAIL PROTECTED] wrote: Simon Nash wrote: Raymond Feng wrote: Hi, Do any of you see this failure too? Yes, I see it. It appears the test is wrong, and this is now showing up because of my recent check-in r666738 in which I fixed a problem where the conversation object was incorrectly being returned as null even though there is an active conversation. This test appears to be checking for the incorrect behaviour. The call b.testNullConversation() creates a conversation, since the BComponent interface is @Conversational and BComponentImpl has @Scope(CONVERSATION). Calling RequestContext.getConversation() while this method is active should return non-null, not null. I fixed this test case under r667036. Simon Simon Thanks, Raymond org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation() java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:69) at org.junit.Assert.assertTrue(Assert.java:32) at org.junit.Assert.assertNull(Assert.java:256) at org.junit.Assert.assertNull(Assert.java:265) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.impl.BComponentImpl.testNullConversation(BComponentImpl.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:133) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) 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 $Proxy14.testNullConversation(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation(CallableReferenceTestCase.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.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)
[jira] Closed: (TUSCANY-2274) @Scope vTest failing intermittently
[ https://issues.apache.org/jira/browse/TUSCANY-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-2274. -- Resolution: Fixed Fixed in r667046 and r667049 but adding some synchronization clauses @Scope vTest failing intermittently Key: TUSCANY-2274 URL: https://issues.apache.org/jira/browse/TUSCANY-2274 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Fix For: Java-SCA-Next The atScope1 vTest fails intermittently like this: --- T E S T S --- Running org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase Setting up Apr 26, 2008 5:00:57 PM org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime buildComposite WARNING: Can't find monitor extension on the classpath GService-initGService atScope1 Exception in thread Thread-5 java.lang.IllegalArgumentException: Invalid phase name: component.implementation at org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:106) at org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:70) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:316) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115) at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:232) ThreadB1-BService2 ThreadB2-BService9 at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:245) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy17.setCurrentState(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359) Exception in thread Thread-4 org.osoa.sca.ServiceUnavailableException: Service not found for component CComponent reference $self$.CService (bi ndingURI=/CComponent operation=getName). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and t hat if running in a remote node that the interface of the target service marked as @Remotable at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:247) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy17.setCurrentState(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359) atScope2 --- Still not clear if this is a runtime r test setup issue. I have added Ignore annotation until this is resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I wonder if some of this debate is due to us not all talking about they same thing so maybe it would help to go back to this proposal: Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime - the launcher should detect the presence of installed extensions in a particular Tuscany installation - as a user / app developer I should not have to know the list of JARs from all these extensions. This is a fundamentally different approach from what we do today where we have all the Tuscany jars and dependencies on the application classpath. One of the main reasons for having jars of aggregated modules is to make it easier for users but if we change to have a runtime launcher which handles the all the module jars instead of the user then that reason goes away. To make this clear, today if a user has an Ant build script for their application that build script needs to hardcode each Tuscany module jar and dependency jar name so the build script breaks every time we change things. The tuscany-all and manifest jars help some but as has been pointed they have other problems. If we change to use the launcher approach then the Ant build script just needs to hardcode the Tuscany API and launcher bootstrap jar names and the location of the Tuscany install, and those few names should not change much over Tuscany releses so the user application doesn't get broken when we change Tuscany internal things. It doesn't really matter to the user if the actual Tuscany install folder has 10 jars or 200 jars all the they care about is the install location and the launcher handles it all for them. This is similar to developing webapps for Tomcat, to the user all they care about is the servlet-api jar and where Tomcat is installed, they don't care whats in the Tomcat server lib directory. We did use this launcher approach back in M2 and we changed in 0.90 as a launcher makes things harder for Tuscany developers, for example when debugging Tuscany internals, but maybe _now_ it would be better to change back to a launcher approach as it makes things easier for users. ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of users we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Thu, Jun 12, 2008 at 4:31 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of users we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. Actually this isn't quite what I was saying. (Sorry that I wasn't clear.) I'm talking about the lowest level components that we distribute as binaries, not about larger groupings that are created from these components to provide convenient aggregations of functionality. These groupings might be useful as well, as you are suggesting here and Graham suggested in his recent post. So back to the basic components. I see no value at this level in breaking things down any lower than a unit of functionality that might be included or excluded as a whole from some valid scenario. To give an example, I wouldn't put everything
[jira] Closed: (TUSCANY-2243) ServiceRuntimeException due to NPE with ComponentContext.getService()
[ https://issues.apache.org/jira/browse/TUSCANY-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-2243. -- Resolution: Fixed It looks like the problem reported in the subject of this jira is now fixed and the remaining ignored test was incorrectly reporting a failure so i've corrected that ServiceRuntimeException due to NPE with ComponentContext.getService() - Key: TUSCANY-2243 URL: https://issues.apache.org/jira/browse/TUSCANY-2243 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Yee-Kang Chang Assignee: ant elder Fix For: Java-SCA-Next Attachments: ComponentContextUpdatesJIRA2243.patch ComponentContext.getService() did not return the expected service when invoked. It works with a @Reference field is defined for the service in the Impl class but it failed without the annotation. The reference is defined in the SCDL. Section 1.4.1.1 of the specification says, When a component implementation needs access to a service where the reference to the service is not known at compile time, the reference can be located using the component's ComponentContext. So, this should work without @Reference defined. org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:228) at org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:110) at org.apache.tuscany.sca.core.context.ComponentContextImpl.getService(ComponentContextImpl.java:102) at org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.impl.AComponentImpl.testServiceLookup(AComponentImpl.java:96) 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.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) 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.testServiceLookup(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.ComponentContextTestCase.testServiceLookup(ComponentContextTestCase.java:170) 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.lang.NullPointerException at org.apache.tuscany.sca.core.context.ComponentContextImpl.getInterfaceContract
Re: Release 1.3?
On Tue, Jun 10, 2008 at 11:53 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 10:14 AM, Simon Nash [EMAIL PROTECTED] wrote: Mike Edwards wrote: Simon Laws wrote: It's been a little while now since we did our 1.2 release. Since then there has been lots of activity and of course we have graduated. It feels like the right time to do a 1.3 release. Looking back at the mail list over the last couple of months there are quite a few candidates for inclusion that I can see; Better BPEL support Improvements to the domain manager app Improved runtime Java2WSDL processing Support for validation monitoring Databinding improvements Performance improvements JSR250 annotation support OSGi support improvements and a simple OSGi runtime test Java 2 security enablement Quite a few more tests for various parts of the runtime Lots of JIRA fixes. and of course we can remove the incubating assignment and drum up a bit of publicity for our TLP graduation I'd also like to have a bit of a tidy up for this release and remove the old domain modules we are no longer using (I'll post on this separately) What else has been added or changed? I think the things I would like to get done can be closed off next week ready to cut a branch. Thoughts? Simon Yes, I give a +1. BPEL is looking a lot better now. I'd like to add a couple of more sophisticated itests/samples as well and the release will be a good spur. Yours, Mike. I think this is a good time to do a 1.3 release. This would make the new runtime Java2WSDL generation available to Tuscany users, and resolve a number of issues with the previous code generation that used Axis2. The other improvements listed are valuable as well. Simon OK, so it looks like people want to do this Re. Luciano's question about RM. I'll volunteer to be RM this time round and all help is greatly appreciated. If though Luciano (or anyone else for that matter) you are keen to RM this time then I won't fight you for it;-) Would seem a little unfair though as you did the last one. Anyone have things they are working one that would stop us moving forward with this and cutting the R1.3 branch at the end of this week? Regards Simon +1 to Simon as RM and taking the branch at the end of this week. ...ant
Re: JMS Client
On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi [EMAIL PROTECTED] wrote: Hi All, I can now run JMS client successfully with latest binding.jms, but you need to confirm following with WAS 6 before testing it.. this was done with the help of Ant... This investigation done on sample sample-helloworld-jms-webapp 1) see the link http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798tstart=0 2) You need to add localhost:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging in the property Provider endpoints of Connection Factory, You can find it in the websphere admin console, under resourses - JMS click on your connection factory Here SIB_ENDPOINT_ADDRESS is the port defined under websphere admin console and look in servers-application server, click on server1, and then in the server1 panel there are two things under Communications in ports it should list SIB_ENDPOINT_ADDRESS here second entry of port 7276 is defaul to provide... 3) In this sample there is a property to set in the web.xml to say start when the server starts up not on the first web request this was not come with standard sample otherwise you need to call your service throgh hello.jsp and then you client would work woth it (jsp is come in the sample sample-helloworld-jms-webapp) by using above steps i can now run my client successfully. Thanks Ant for all your help.. Please Ant correct me in this explanation. please let us know if anybody have any questions... :) -- Thanks Nishant Joshi That all sounds about right, the only thing I'd add is that there is some doc on the connection factory provider endpoints field at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html I've added a short section on using this WebSphere client for JMS to the binding.jms doc on the website, its very brief right now and just refers to this email thread, Nishant or anyone else - interested in adding more detail or expanding it out into a separate more detaailed how-to wiki page? ...ant ...ant
Re: NPE in JMS itests was: Re: JMS Client
On Wed, Jun 11, 2008 at 8:29 AM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, Jun 11, 2008 at 8:23 AM, ant elder [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi [EMAIL PROTECTED]
wrote:
Hi All,
I can now run JMS client successfully with latest binding.jms, but you
need
to confirm following with WAS 6 before testing it.. this was done with
the
help of Ant...
This investigation done on sample sample-helloworld-jms-webapp
1) see the link
http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798tstart=0
2) You need to add
localhost:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging
in the property Provider endpoints of Connection Factory, You can find
it
in
the websphere admin console, under resourses - JMS click on your
connection
factory
Here SIB_ENDPOINT_ADDRESS is the port defined under websphere admin
console and look in servers-application server, click on server1, and
then
in the server1 panel there are two things under Communications in ports
it
should list SIB_ENDPOINT_ADDRESS
here second entry of port 7276 is defaul to provide...
3) In this sample there is a property to set in the web.xml to say
start
when the server starts up not on the first web request this was not
come
with standard sample otherwise you need to call your service throgh
hello.jsp and then you client would work woth it (jsp is come in the
sample
sample-helloworld-jms-webapp)
by using above steps i can now run my client successfully.
Thanks Ant for all your help..
Please Ant correct me in this explanation.
please let us know if anybody have any questions... :)
--
Thanks
Nishant Joshi
That all sounds about right, the only thing I'd add is that there is some
doc on the connection factory provider endpoints field at
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html
I've added a short section on using this WebSphere client for JMS to the
binding.jms doc on the website, its very brief right now and just refers
to
this email thread, Nishant or anyone else - interested in adding more
detail
or expanding it out into a separate more detaailed how-to wiki page?
...ant
...ant
I'm seeing an NPE in the JMS itests on the line
if
(props.get(Context.INITIAL_CONTEXT_FACTORY).equals(com.ibm.websphere.naming.WsnInitialContextFactory))
{
Seems to be related to the changes here and could do with an if null
check
I guess. Is there a fix in hand for this or shall I make the change?
Simon
I've just committed a fix.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: snip If we are anyway going to require a launcher of some form, wouldn't it be just as easy to maintain one-bundle-per-module? I agree, if we go back to requiring a launcher that changes a lot how we'd could put this together. I'm not at all against requiring a launcher as that does make things easier in some respects, but lets remember why we did used to do this and then chucked it out in the 0.90 rewrite ;) ...ant
Re: [VOTE] Release SDO 1.1.1
So thats works ok for two, doesn't work for one. Luciano, I had to build a couple of times with -U to get all the emf jars successfully downloaded, have you tried that or can you find any other way to get a build through in your environment? ...ant On Tue, Jun 10, 2008 at 11:32 AM, Murtaza Goga [EMAIL PROTECTED] wrote: I built this release last night, built clean. -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 5:29 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Release SDO 1.1.1 I'd like to get this voted on and released but nervous to start that after Kelvin had trouble getting the emf dependencies, could any one else try building the tag and seeing if it works or not for them - https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R C2/-https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/- its a small checkout and doesn't take long to build. ...ant On Sat, Jun 7, 2008 at 9:15 AM, ant elder [EMAIL PROTECTED] wrote: It seems to work fine for me, the binary distribution ends up with a lib folder containing: backport-util-concurrent-3.0.jar codegen-2.2.3.jar codegen-ecore-2.2.3.jar common-2.2.3.jar ecore-2.2.3.jar ecore-change-2.2.3.jar ecore-xmi-2.2.3.jar sample-sdo-1.1.1.jar stax-api-1.0.1.jar tuscany-sdo-api-r2.1-1.1.1.jar tuscany-sdo-impl-1.1.1.jar tuscany-sdo-lib-1.1.1.jar tuscany-sdo-tools-1.1.1.jar wstx-asl-3.2.1.jar xsd-2.2.3.jar I've put the distributions that I get from the 1.1.1-RC2 tag up at http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2 http://people.a pache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2, how do they look? ...ant On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, yes, I added that workaround, and that satisfied most of the EMF jars, but not these two. It's odd, the 2 jars we need are there in the repository you suggested, but maven will not download them. Kelvin. 2008/6/6 Luciano Resende [EMAIL PROTECTED]: Did you try the workaround I mentioned before on this thread [1] where I added a new repository ? It was actually for other jars, but might help in this case as well... [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson [EMAIL PROTECTED] wrote: I've made all the changes required in the tag [1] to get rid of the felix jars, find and include the emf jars, and I've removed the incubating tag, DISCLAIMER files etc. However, I'm currently stumped as to why two emf jars available [2] and [3] don't get downloaded by the build. The build output complains about URLs that, if cut and pasted into a browser, work fine. Any clues to explain this odd maven behaviour are welcome. Kelvin [1] https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R C2/https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/ [2] http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c odegen/2.2.3/http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/ [3] http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c odegen-ecore/2.2.3/http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/ 2008/6/3 Rajini Sivaram [EMAIL PROTECTED]: Kelvin, Sorry about the delay in getting back to you - I can see that you have found a solution. Yes, you are absolutely right, the felix framework should use scope provided since SdoBundleActivator is only used when SDO is running inside an OSGi container, and the framework classes are provided by the container. On 6/3/08, kelvin goodson [EMAIL PROTECTED] wrote: Just a thought, would I be right in guessing that if ever our SdoBundleActivator is touched in the runtime, then the environment would be expected to provide the classes to satisfy import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; ? in which case I think declaring a provided scope for the felix dependency would be the right way to do things Kelvin. 2008/6/3 kelvin goodson [EMAIL PROTECTED]: Thanks Ant, that looks like progress, but the felix framework jar is now not in the list of distributed jars. Kelvin. 2008/6/3 ant elder [EMAIL PROTECTED]: Adding an exclude for felix to the distribution pom can fix that, eg here's local changes i have just tried: Index: src/main/assembly/bin.xml
Re: Running vtests with security on
On Thu, May 15, 2008 at 8:32 PM, Dan Becker [EMAIL PROTECTED] wrote:
Since I am not much of a Maven expert, I thought I would run this by the
Tuscany community to see if I am going down the right path or to see if
there are better ideas.
Normally when I test with any Tuscany sample or test with Java 2
security enabled, I use the JVM options -Djava.security.manager
-Djava.security.policy=tuscany.policy -Djava.security.debug=policy. The
tuscany.policy file enables certain parts of Tuscany code to access
sensitive API calls, such as reading system properties or writing to the
file system. When I run Tuscany JUnit tests in Eclipse, I add these
options to the JUnit Run As dialog settings.
The Tuscany vtests run when you execute Maven on the vtest pom with the
test goal. I was thinking of adding a profile that specifies the
additional properties above. Also, I would provide an example
tuscany.policy file that provides the proper permissions for the Tuscany
code base. This when you wanted to run vtests with security on, you
would invoke this profile along with the test goal.
Any additional suggestions or comments?
--
Thanks, Dan Becker
In preparation for the 1.3 branch I've just had a try building trunk with
security on and get a few failures:
[INFO] Error for project: Apache Tuscany SCA Databinding Integration Tests -
JAXB Bottom Up (during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\databindings\jaxb-bottom-up\target\surefire-reports
for the individual test results.
[INFO]
[INFO] Error for project: Apache Tuscany SCA Late Reference Resolution
Integration Test (during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\late-reference-resolution\target\surefire-reports
for the individual test results.
[INFO]
[INFO] Error for project: Apache Tuscany SCA OSGi-SCA Integration Tests
(during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\osgi-implementation\target\surefire-reports for
the individual test results.
(the itests jaxb-bottom-up and late-reference-resolution fail as well but
they're also failing for me in trunk right now without security on)
Thats using the command:
mvn test -P security
-Dtuscany.policy.file=file:///c:\Tuscany\tuscany.policy -o
and with a the tuscany.policy file containing:
grant codeBase file:/C:/Tuscany/SVN/trunk/- {
permission java.security.AllPermission;
};
grant codeBase file:/C:/Documents and
Settings/Administrator/.m2/repository/- {
permission java.security.AllPermission;
};
grant codeBase file:/e:/temp/eclipse/eclipse/- {
// permission java.security.AllPermission;
permission java.net.SocketPermission 127.0.0.1:*,
connect,accept,resolve;
permission java.io.FilePermission ALL FILES, read;
permission java.lang.RuntimePermission accessDeclaredMembers;
permission java.lang.RuntimePermission getClassLoader;
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission *, read;
};
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram [EMAIL PROTECTED] wrote: ,snip You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ Great article, thanks for the link. Thats over a year old now so has much changed eg in relation to comments like The delayed services feature requires some small tweaks to the basic Equinox runtime, and these tweaks have not been implemented yet in the released version 3.2. They do not appear at all yet (at the time of writing) in the other open source OSGi runtimes, Apache Felix and Knopflerfish.? ...ant
Re: Unable to download the artifact from any repository
It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelder. Could there be some old config in you maven settings.xml file (eg at C:\Documents and Settings\Administrator\.m2\settings.xml) from when you reviewing the 1.0 RC1a? ...ant On Wed, Jun 11, 2008 at 5:05 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: I continued looking into this issue and found that the parent-2-incubating.pom can't be downloaded and thus leads to the errors shown below. I tested this by checking out the most recent version of the java code and building as explained in [1]. I read that a possible workaround might be to download the pom and do things manually but it's not possible to acces the file on any of these URLs. Is there anywhere else I can get this file from? Am I missing something? (I feel like I might be doing something terribly wrong...) $ mvn clean install -Dtest=no [INFO] Scanning for projects... Downloading: http://people.apache.org/~antelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pomhttp://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ws.zones.apache.org/repository2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://www.ibiblio.net/pub/packages/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany ArtifactId: parent Version: 2-incubating Reason: Unable to download the artifact from any repository org.apache.tuscany:parent:pom:2-incubating [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html On Wed, Jun 11, 2008 at 10:43 AM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi, I'm re-doing my SCA installation by following the steps in [1] and keep running into a problem when doing clean install: mvn clean install -Dtest=no After searching the mailing list archives I found some suggestions, but haven't been able to resolve the problem. I posted the stack trace in [2]. What can be going wrong? Any suggestions? Any help is greatly appreciated. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008 [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008 -- best, -oscar Oscar Castañeda -- best, -oscar Oscar Castañeda
OSGi presentation
Timely post of a presentation on server side OSGi: http://www.infoq.com/presentations/colyer-server-side-osgi ...ant
Re: Unable to download the artifact from any repository
) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:185) ... 20 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Jun 11 20:08:02 CEST 2008 [INFO] Final Memory: 1M/2M [INFO] On Wed, Jun 11, 2008 at 6:11 PM, ant elder [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder. Could there be some old config in you maven settings.xml file (eg at C:\Documents and Settings\Administrator\.m2\settings.xml) from when you reviewing the 1.0 RC1a? ...ant On Wed, Jun 11, 2008 at 5:05 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: I continued looking into this issue and found that the parent-2-incubating.pom can't be downloaded and thus leads to the errors shown below. I tested this by checking out the most recent version of the java code and building as explained in [1]. I read that a possible workaround might be to download the pom and do things manually but it's not possible to acces the file on any of these URLs. Is there anywhere else I can get this file from? Am I missing something? (I feel like I might be doing something terribly wrong...) $ mvn clean install -Dtest=no [INFO] Scanning for projects... Downloading: http://people.apache.org/~antelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pomhttp://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom http://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom http://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ws.zones.apache.org/repository2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://www.ibiblio.net/pub/packages/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany ArtifactId: parent Version: 2-incubating Reason: Unable to download the artifact from any repository org.apache.tuscany:parent:pom:2-incubating [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html On Wed, Jun 11, 2008 at 10:43 AM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi, I'm re-doing my SCA installation by following the steps in [1] and keep running into a problem when doing clean install: mvn clean install -Dtest=no After searching the mailing list archives I found some suggestions, but haven't been able to resolve the problem. I posted the stack trace in [2]. What can be going wrong? Any suggestions? Any help is greatly appreciated. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008 [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008 -- best, -oscar Oscar Castañeda -- best, -oscar Oscar Castañeda -- best, -oscar Oscar Castañeda
Re: Unable to download the artifact from any repository
It looks like what you're building isn't looking in the Apache incubating repository, does the pom.xml in the top level of where you're building have repository idapache.incubator/id urlhttp://people.apache.org/repo/m2-incubating-repository/url /repository in the repositories section? ...ant On Wed, Jun 11, 2008 at 7:29 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tuscany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1260) ... 17
Re: Unable to download the artifact from any repository
Looks like you're right and thats missing which does seem like a bug. ...ant On Wed, Jun 11, 2008 at 7:47 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We should have the following maven repo declared in the pom.xml: repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository But I cannot find it anywhere in the pom.xml under the java/sca tree. Is it a bug? If we build from sca folder, then it works fine. What about building modules/... from an empty local maven repo? Thanks, Raymond -- From: Oscar Castaneda [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:29 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Unable to download the artifact from any repository Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM
Account Request - Scott Kurz - Tuscany
Dear root, Please create an id for Scott Kurz on the Tuscany project Preferred userid:scottkurz Full name: Scott Kurz Forwarding email address:[EMAIL PROTECTED] Requested Karma for: ws-tuscany ICLA is on file. Votes: tuscany-private, June 9, Message-ID: [EMAIL PROTECTED] Many thanks, ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Can you say a bit more about what an extension registry mechanism would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? ...ant
Re: JMS Client
I've been able to recreate this problem by using a non-IBM JRE with the WebSphere JMS client. Turns out the Tuscany JMS binding needs to a special property added to the JNDI initial context environment when NOT running on an IBM JRE. I've updated the binding-jms code to do this and it works ok now for me could you give it a try? ...ant On Tue, Jun 10, 2008 at 8:34 AM, Nishant Joshi [EMAIL PROTECTED] wrote: Hi Ant, Thanks for your investigation on this. I m getting exception with WebSphere JMS client with a Sun JDK... below is the stacktrace for it... javax.naming.NamingException: Failed to initialize the ORB [Root exception is java.lang.ClassCastException: com.sun.corba.se.impl.orb.ORBImpl] at com.ibm.ws.naming.util.Helpers.getOrb(Helpers.java:314) at com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:383) at com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:113) at com.ibm.ws.naming.util.WsnInitCtx.getContextIfNull(WsnInitCtx.java:428) at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:144) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactory.jndiLookUp(JMSResourceFactory.java:149) at org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactory.lookupDestination(JMSResourceFactory.java:129) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestinationQueue(JMSBindingInvoker.java:134) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestination(JMSBindingInvoker.java:83) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.init(JMSBindingInvoker.java:66) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingReferenceBindingProvider.createInvoker(JMSBindingReferenceBindingProvider.java:117) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy15.sayHello(Unknown Source) at helloworld.HelloWorldClientImpl.sayHello(HelloWorldClientImpl.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) 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 org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149) at helloworld.HelloWorldClientImpl$$EnhancerByCGLIB$$e8cbf9a4.sayHello(generated) at helloworld.JMSClient.main(JMSClient.java:20) at helloworld.ClientTest.testServiceCall(ClientTest.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant I'd prefer the next logical number, 1.3 for example. I still think plain SNAPSHOT would be simplest but as no one else seems to like that I think I agree with this - the next logical number seems better than things like 1.x or 2.0 etc. So, I plan to change trunk to 1.4-SNAPSHOT when the 1.3 branch is taken, do say if you really don't like this but its what we've been doing most of the time in the past so i hope most can live with it. ...ant
Tuscany Board Report for June
I need to submit our ASF board report by next Monday. I've created a wiki page - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/June+2008 - please add anything you want mentioned. ...ant
Re: [VOTE] Release SDO 1.1.1
I'd like to get this voted on and released but nervous to start that after
Kelvin had trouble getting the emf dependencies, could any one else try
building the tag and seeing if it works or not for them -
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/-
its a small checkout and doesn't take long to build.
...ant
On Sat, Jun 7, 2008 at 9:15 AM, ant elder [EMAIL PROTECTED] wrote:
It seems to work fine for me, the binary distribution ends up with a lib
folder containing:
backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1.jar
tuscany-sdo-impl-1.1.1.jar
tuscany-sdo-lib-1.1.1.jar
tuscany-sdo-tools-1.1.1.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar
I've put the distributions that I get from the 1.1.1-RC2 tag up at
http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2,
how do they look?
...ant
On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson [EMAIL PROTECTED]
wrote:
Hi Luciano,
yes, I added that workaround, and that satisfied most of the EMF jars,
but not these two. It's odd, the 2 jars we need are there in the
repository
you suggested, but maven will not download them.
Kelvin.
2008/6/6 Luciano Resende [EMAIL PROTECTED]:
Did you try the workaround I mentioned before on this thread [1] where
I added a new repository ? It was actually for other jars, but might
help in this case as well...
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html
On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
I've made all the changes required in the tag [1] to get rid of the
felix
jars, find and include the emf jars, and I've removed the incubating
tag,
DISCLAIMER files etc. However, I'm currently stumped as to why two
emf
jars available [2] and [3] don't get downloaded by the build. The
build
output complains about URLs that, if cut and pasted into a browser,
work
fine. Any clues to explain this odd maven behaviour are welcome.
Kelvin
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/
[2]
http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/
[3]
http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/
2008/6/3 Rajini Sivaram [EMAIL PROTECTED]:
Kelvin,
Sorry about the delay in getting back to you - I can see that you
have
found
a solution. Yes, you are absolutely right, the felix framework should
use
scope provided since SdoBundleActivator is only used when SDO is
running
inside an OSGi container, and the framework classes are provided by
the
container.
On 6/3/08, kelvin goodson [EMAIL PROTECTED] wrote:
Just a thought, would I be right in guessing that if ever our
SdoBundleActivator is touched in the runtime, then the environment
would
be
expected to provide the classes to satisfy
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
?
in which case I think declaring a provided scope for the felix
dependency
would be the right way to do things
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
Thanks Ant, that looks like progress, but the felix framework
jar
is
now
not in the list of distributed jars.
Kelvin.
2008/6/3 ant elder [EMAIL PROTECTED]:
Adding an exclude for felix to the distribution pom can fix that,
eg
here's
local changes i have just tried:
Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml (revision 662488)
+++ src/main/assembly/bin.xml (working copy)
@@ -120,13 +120,13 @@
dependencySets
dependencySet
outputDirectorytuscany-sdo-${sdo.version}/lib/outputDirectory
-includes
-
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
+!-- includes
+
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
includeorg.apache.tuscany.sdo:tuscany-sdo-lib/include
includeorg.apache.tuscany.sdo:tuscany-sdo-impl/include
includeorg.apache.tuscany.sdo:tuscany-sdo-tools/include
includeorg.apache.tuscany.sdo:sample-sdo/include
-/includes
+/includes --
fileMode0644/fileMode
/dependencySet
Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Can you say a bit more about what an extension registry mechanism would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? Yes, I think this is important. Ideally the Tuscany core runtime would figure out which pieces are needed for the domain configuration and load these pieces automatically. Good requirement, but I don't think that the current manifest + tuscany-all JAR solution is a good one (for example it mixes APIs and internals in the same JAR, doesn't work well with IDEs, works only for one big distro, requires different settings in J2SE and webapps) I'm not saying I
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 6:52 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please see my comments inline. Thanks, Raymond [snip] Good requirement, but I don't think that the current manifest + tuscany-all JAR solution is a good one (for example it mixes APIs and internals in the same JAR, doesn't work well with IDEs, works only for one big distro, requires different settings in J2SE and webapps) IMHO, the all-in-one package pretty much defeats our modularity. For example, all module activators will be called even the extension won't be used at all. Calling a module activator is pretty minimal initialization overhead especially if it just fails right away with something like a ClassNotFoundException and the runtime carries on, and this is what happens with the our bundle jar - you can just use it without the extension dependencies you don't need and it works fine. Note I'm not necessarily saying we should be keeping the single one big bundle jar, i'm just trying to avoid the impression that the _only_ option we have is everything in individual separate jars. Two extension cannot have different versions of a 3rd party jar. Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime This is similar to JEE launchClient. If I can invoke the Launcher directly in java, I would be happy. So just to be clear on what is being suggested this would be like the launcher we used to have back in M2 days right? ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 7:03 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. I'm not sure i agree with that, individual small maven modules are for making things easier for developers, aggregated jars are for making things easier for users. There is lots of prior discussion about the pros and cons of this eg just search for all the projects using the shade plugin and then their mailing lists when they did that. Though if we do go back to a runtime launcher approach then users don't need to care so much as the launcher will hide some of these internal details. ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 10:59 PM, Mike Edwards [EMAIL PROTECTED] wrote: snip Good debate here, but let's be clear about the big picture before the details swamp the debate. Big +1 to that, i really hope we can some consensus on what the distributions and runtimes should look like before we decide what registries etc we need to use to implement them. ...ant
[NOTICE] Scott Kurz voted as Tuscany committer
The Tuscany PMC has voted for Scott Kurz to become a Tuscany committer. Welcome Scott! ...ant
[ANNOUNCE] Apache Tuscany SCA Java 1.2.1 released
The Apache Tuscany team are pleased to announce the 1.2.1 release of the Java SCA project. Apache Tuscany provides a runtime environment based on the Service Component Architecture (SCA). SCA is a set of specifications aimed at simplifying SOA application development. These specifications are being standardized by OASIS as part of the Open Composite Services Architecture (Open CSA). This 1.2.1 release is a maintenance release over the 1.2 release, see the RELEASE_NOTES and CHANGES file for details, and to download the distributions please go to: http://incubator.apache.org/tuscany/sca-java-releases.html To find out more about OASIS Open CSA go to: http://www.oasis-opencsa.org Apache Tuscany welcomes your help. Any contribution, including code, testing, contributions to the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany Thank you for your interest in Apache Tuscany! The Apache Tuscany Team.
Re: [PROPOSAL] Disable unused domain modules
On Mon, Jun 9, 2008 at 9:56 AM, Simon Laws [EMAIL PROTECTED] wrote: Hi All Now that the new domain manager app is starting to settle down a bit I'd like to disable the unused domain modules from the main build. They are... modules/domain modules/domain-api modules/domain-xml modules/node modules/node-api modules/node-xml I have removed these from most of the places they were previously referenced with the exception of a couple of samples/itests. I propose that we break these final dependencies and remove these modules from the main build and from the distribution builds. The module themselves can remain in place for a little while longer until we are happy the builds are stable and then I think we can move them out to sandbox/old. These modules are now replaced by a range of domain and node features spread across various modules. These are the ones I am aware of: modules/domain-manager - represents the configured domain and provides a web interface to users modules/endpoint - a plug point for late reference resolution (we don't actually support late reference resolution yet in our runtimes.The domain assumes that wires are known and static) modules/implementation-node - the model that represents a configured node in the domain. Used to provide default binding configuration and relate composites to nodes modules/implementation-node-runtime modules/implementation-node-xml modules/node2-api - the new node implementation that reads its configuration from the command line or directly from the domain-manager modules/node2-impl modules/node2-launcher modules/node2-launcher-webbapp modules/runtime modules/runtime-tomcat - deep integration with tomcat that allows composite application wars to be deployed which don't contain Tuscany jars (under development) modules/workspace - the code behind the domain-manager contribution processing. modules/workspace-impl modules/workspace-xml Regards Simon +1 to removing the old modules. I'd prefer they are deleted from the modules folder than left there just not part of the build. They'll always be there in SVN history if they are ever needed again for something. ...ant
Re: Tuscany support for Axis 1.4
On Wed, May 14, 2008 at 1:12 PM, Lou Amodeo [EMAIL PROTECTED] wrote: Is there a plan for Tuscany to support Axis2 1.4? Axis2 1.4 and the associated wss4j and rampart releases for 1.4 are all out and available in the Maven repositories now. I've still a couple of issues to resolve to get everything in the build working with 1.4 but hope to have those fixed in the next day or 2 so would like to move up to 1.4 then ...ant
Re: JMS Client
On Fri, Jun 6, 2008 at 4:14 PM, Nishant Joshi [EMAIL PROTECTED] wrote: Hi All, Here is the more detail regarding error... I have trace the error and found that exceptino source is from method getInitialContext() of org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactory Here is the complete stack trace org.apache.tuscany.sca.binding.jms.impl.JMSBindingException: JMS Destination HelloWorldService not found with create mode of ifnotexist while registering binding serviceA invoker at org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestinationQueue(JMSBindingInvoker.java:169) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.lookupDestination(JMSBindingInvoker.java:83) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingInvoker.init(JMSBindingInvoker.java:66) at org.apache.tuscany.sca.binding.jms.provider.JMSBindingReferenceBindingProvider.createInvoker(JMSBindingReferenceBindingProvider.java:117) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy15.sayHello(Unknown Source) at helloworld.HelloWorldClientImpl.sayHello(HelloWorldClientImpl.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) 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 org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149) at helloworld.HelloWorldClientImpl$$EnhancerByCGLIB$$2ae21c1f.sayHello(generated) at helloworld.JMSClient.main(JMSClient.java:20) at helloworld.ClientTest.testServiceCall(ClientTest.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Has anybody idea why should i m not able to connect to a Queue of WAS ? -- Thanks Nishant Joshi The easiest way to get this to work is using the jars from the WebSphere J2SE JMS client -
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
On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've created an itest (late-reference-resolution) to show how late resolution could be done using endpoint resolvers. In the itest BindingScaEndpointResolverImpl it says I can cheat here because... could you say a little about how a real use of this could work? And what do you think about having some code somewhere - in an itest or module somwhere - which demonstrates that? I'd be happy to help write that, I'm asking as in runtime-tomcat i need to do the same thing but haven't been able to figure out how its intended to be done for real. ...ant
Re: [VOTE] Release SDO 1.1.1
It seems to work fine for me, the binary distribution ends up with a lib
folder containing:
backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1.jar
tuscany-sdo-impl-1.1.1.jar
tuscany-sdo-lib-1.1.1.jar
tuscany-sdo-tools-1.1.1.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar
I've put the distributions that I get from the 1.1.1-RC2 tag up at
http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2, how do they look?
...ant
On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson [EMAIL PROTECTED]
wrote:
Hi Luciano,
yes, I added that workaround, and that satisfied most of the EMF jars,
but not these two. It's odd, the 2 jars we need are there in the repository
you suggested, but maven will not download them.
Kelvin.
2008/6/6 Luciano Resende [EMAIL PROTECTED]:
Did you try the workaround I mentioned before on this thread [1] where
I added a new repository ? It was actually for other jars, but might
help in this case as well...
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html
On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
I've made all the changes required in the tag [1] to get rid of the
felix
jars, find and include the emf jars, and I've removed the incubating
tag,
DISCLAIMER files etc. However, I'm currently stumped as to why two
emf
jars available [2] and [3] don't get downloaded by the build. The
build
output complains about URLs that, if cut and pasted into a browser,
work
fine. Any clues to explain this odd maven behaviour are welcome.
Kelvin
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/
[2]
http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/
[3]
http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/
2008/6/3 Rajini Sivaram [EMAIL PROTECTED]:
Kelvin,
Sorry about the delay in getting back to you - I can see that you have
found
a solution. Yes, you are absolutely right, the felix framework should
use
scope provided since SdoBundleActivator is only used when SDO is
running
inside an OSGi container, and the framework classes are provided by
the
container.
On 6/3/08, kelvin goodson [EMAIL PROTECTED] wrote:
Just a thought, would I be right in guessing that if ever our
SdoBundleActivator is touched in the runtime, then the environment
would
be
expected to provide the classes to satisfy
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
?
in which case I think declaring a provided scope for the felix
dependency
would be the right way to do things
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
Thanks Ant, that looks like progress, but the felix framework
jar
is
now
not in the list of distributed jars.
Kelvin.
2008/6/3 ant elder [EMAIL PROTECTED]:
Adding an exclude for felix to the distribution pom can fix that,
eg
here's
local changes i have just tried:
Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml (revision 662488)
+++ src/main/assembly/bin.xml (working copy)
@@ -120,13 +120,13 @@
dependencySets
dependencySet
outputDirectorytuscany-sdo-${sdo.version}/lib/outputDirectory
-includes
-
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
+!-- includes
+
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
includeorg.apache.tuscany.sdo:tuscany-sdo-lib/include
includeorg.apache.tuscany.sdo:tuscany-sdo-impl/include
includeorg.apache.tuscany.sdo:tuscany-sdo-tools/include
includeorg.apache.tuscany.sdo:sample-sdo/include
-/includes
+/includes --
fileMode0644/fileMode
/dependencySet
Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12 @@
groupIdorg.apache.tuscany.sdo/groupId
artifactIdtuscany-sdo-impl/artifactId
version${pom.version}/version
+exclusions
+exclusion
+groupIdorg.apache.felix/groupId
+
artifactIdorg.apache.felix.main/artifactId
+/exclusion
+/exclusions
/dependency
dependency
groupIdorg.apache.tuscany.sdo/groupId
@@ -67,6 +73,7
Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console
I've created you a folder in our sandbox area https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/thilina, thats yours to use for whatever you like. Ideally most of the code you do will go in trunk as part of our regular build but you can use the sandbox area as a staging area where you can experiment or store stuff without having to worry about correctness, beauty or breaking any builds. ...ant On Sat, Jun 7, 2008 at 8:13 AM, Thilina Buddhika [EMAIL PROTECTED] wrote: Hi, Yes, these modules are available. But earlier there was a web app under this package which made use of these modules to provide with SCA domain admin functionality. This was only working with a local SCA domain. So as I feel, it would be good, if we can get this web app to run with an ACE as the first phase, and then extend its functionality. This web app was available under org.apache.tuscany.sca.workspace.admin.* . If this has been removed, then we can start it from the scratch by using the available workspace modules. As an alternative to this, Ant has suggested to bring the available tuscany-geronimo intergration code to work with latest geronimo versions. In the mean time as Ant has suggested, it is better if we can set up an svn location to place my workings, so that everyone can see it. Any thoughts ? Thank You. regards, / thilina On Wed, May 28, 2008 at 7:49 PM, Luciano Resende [EMAIL PROTECTED] wrote: The tuscany-workspace-xxx modules are still available : Directory of .\java\sca\modules 05/27/2008 09:12 PMDIR workspace 05/27/2008 09:13 PMDIR workspace-impl 05/27/2008 09:12 PMDIR workspace-xml On Wed, May 28, 2008 at 1:08 AM, Thilina Buddhika [EMAIL PROTECTED] wrote: Hi, I started coding phase on Monday. As the first step, I took a svn update and successfully built it. As discussed earlier in the mailing list (when preparing the proposal), it was decided to bring up the tuscany-workspace- admin as a regular web application and run it inside Geronimo as the first step. But I could not find this class and other related classes in my copy of the Tuscany SCA source. org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain Has the workspace-admin been moved to a different package ? Thank You. regs, / thilina On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika [EMAIL PROTECTED] wrote: Hi, I thought of briefing my work within last few days to Tuscany-dev, so that community can give feedback on it. The wiki page[1] will also be updated along with this. Nowadays I am reading about ACEs and Portlets. I was able to implement a simple ACE and deploy it in Geronimo. Also it was possible to call some JSPs and Servlets within that ACE. I am digging more into this and planning to look at available web based SCA domain admin tool in Tuscany. thanks! best regards, / thilina [1] - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika [EMAIL PROTECTED] wrote: Hi, Thanks Luciano for creating that wiki page. It is really easy to work with confluence wiki. I created a child page[1] and moved my content to it, from my earlier wiki page. I'll be use this new wiki page from now onwards. thanks! best regards, / thilina [1] - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende [EMAIL PROTECTED] wrote: Hi Thilina Thanks for taking the initiative and creating the wiki page. I just created a wiki page/section to be used for GSoC 2008 [1], at the Tuscany Wiki, maybe you and all other students create child pages and use that one. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008 On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika [EMAIL PROTECTED] wrote: Hi, I started working on my project. According to the Google time line[1], now it is the community bonding period. These days I am going through the documentations again, and getting more familiar with the project. I started a wiki page[2] to display the current status of the project. I will be frequently updating that wiki page. I will be using this thread to for the discussions with the community. thanks! best regards, / thilina [1] - http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline [2] - http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- E-Mail : [EMAIL PROTECTED] I blog
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
On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've updated all the code that used EndpointProviders. This includes runtime-tomcat but I was unable to get this running following Ant's instruction on this thread. It maybe that I did something wrong so I'll give it another go a little later. What is the problem you get? ...ant
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
On Sat, Jun 7, 2008 at 12:48 PM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've updated all the code that used EndpointProviders. This includes runtime-tomcat but I was unable to get this running following Ant's instruction on this thread. It maybe that I did something wrong so I'll give it another go a little later. What is the problem you get? I've just tried this, there was a problem with the runtime-tomcat META-INF/services file being out of date with the package moves, i've updated this and it now all works ok for me following the instructions in that earlier email in this thread. ...ant
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
On Thu, Jun 5, 2008 at 8:43 PM, Simon Nash [EMAIL PROTECTED] wrote: Simon Laws wrote: On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi [EMAIL PROTECTED] wrote: 2008/6/4 ant elder [EMAIL PROTECTED]: Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to remove incubating at some point and as its not clear if the next release would be 2.0 or something else so i wondered if we should also remove the 2.0 giving a trunk version of simply SNAPSHOT? Any comments on that or the timeframe for doing the change? I'd like to do it nowish so we have some time to discover any problems before the next release. ...ant Hi ant, could you try a fresh build from svn? I've some problems with and I 'd go on with my work before we're arriving to 2.0. Ciao, Giorgio. --- Venceremos adelante, o victoria o muerte! I agree that it doesn't feel like the next release will be 2.0 I would prefer that we keep the trunk compatible with our 1.X level APIs for the time being as it feels like there is still a more 1.X releases to do If people are going to start making breaking changes in a branch (we discussed this under the 2.0 thread but it's not happening yet) then it would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so that I know by looking on my disc what I'm working with When (if?) the time comes down the line to break from our 1.X APIs we could then go to SNAPSHOT or 2.0 SNAPSHOT I think it's useful to have some version number. 1.x seems to clearly describe what we are currently developing in trunk, so my preference is for 1.x-SNAPSHOT. Simon Lots of different views so far on this thread, better than no one replying :) I'm tempted to go with 1.x-SNAPSHOT as I think from whats been said most would be ok with that, please say if you would _not_ be unhappy with it. Note that all other projects I've looked at use either a specific numeric number followed by the -SNAPSHOT suffix, or else just the string SNAPSHOT for the trunk version, so having the letter x as part of our version number makes for an unusual version name. Don't see why it shouldn't work though. ...ant
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant
Re: Release 1.3?
+1 from me. Incidentally I've spent a bit of time over the last couple of days trying all the various samples and demos etc with the latest trunk code and its all looking in quite good shape so it does seem like a fine time to be taking a release branch. ...ant On Fri, Jun 6, 2008 at 9:21 AM, Simon Laws [EMAIL PROTECTED] wrote: It's been a little while now since we did our 1.2 release. Since then there has been lots of activity and of course we have graduated. It feels like the right time to do a 1.3 release. Looking back at the mail list over the last couple of months there are quite a few candidates for inclusion that I can see; Better BPEL support Improvements to the domain manager app Improved runtime Java2WSDL processing Support for validation monitoring Databinding improvements Performance improvements JSR250 annotation support OSGi support improvements and a simple OSGi runtime test Java 2 security enablement Quite a few more tests for various parts of the runtime Lots of JIRA fixes. and of course we can remove the incubating assignment and drum up a bit of publicity for our TLP graduation I'd also like to have a bit of a tidy up for this release and remove the old domain modules we are no longer using (I'll post on this separately) What else has been added or changed? I think the things I would like to get done can be closed off next week ready to cut a branch. Thoughts? Simon
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
That seems a little odd to me, i'd prefer just snapshot, 1.x, or the actual next number over 1.5. ...ant On Fri, Jun 6, 2008 at 9:17 AM, Luciano Resende [EMAIL PROTECTED] wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: Red Hat/JBoss involvement with Tuscany
On Fri, Jun 6, 2008 at 11:12 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 10:57 AM, Mark Little [EMAIL PROTECTED] wrote: Hi, I just wanted to let people know officially that people from Red Hat/JBoss will be getting involved with Tuscany over the coming months as we look at the best way in which to provide SCA support for our SOA Platform users. We're very excited about helping on Tuscany and complimenting the work we're doing at OASIS. Mark. Mark Little [EMAIL PROTECTED] JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland). Hi Mark That's exciting news indeed. Welcome to you all! Regards SimonL Echoing that sentiment, this is really great news. I look forward to working with you all. ...ant
[jira] Commented: (TUSCANY-2274) @Scope vTest failing intermittently
[ https://issues.apache.org/jira/browse/TUSCANY-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602993#action_12602993 ] ant elder commented on TUSCANY-2274: One interesting part of this is it rarely happens to me when I build just the individual module but often happens when I'm building everything from the top sca folder. Doesn't make it easy to debug :-( @Scope vTest failing intermittently Key: TUSCANY-2274 URL: https://issues.apache.org/jira/browse/TUSCANY-2274 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Fix For: Java-SCA-Next The atScope1 vTest fails intermittently like this: --- T E S T S --- Running org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase Setting up Apr 26, 2008 5:00:57 PM org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime buildComposite WARNING: Can't find monitor extension on the classpath GService-initGService atScope1 Exception in thread Thread-5 java.lang.IllegalArgumentException: Invalid phase name: component.implementation at org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:106) at org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker(InvocationChainImpl.java:70) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:316) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115) at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:232) ThreadB1-BService2 ThreadB2-BService9 at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:245) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy17.setCurrentState(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359) Exception in thread Thread-4 org.osoa.sca.ServiceUnavailableException: Service not found for component CComponent reference $self$.CService (bi ndingURI=/CComponent operation=getName). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and t hat if running in a remote node that the interface of the target service marked as @Remotable at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:247) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy17.setCurrentState(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase$CThread.run(ScopeAnnotationTestCase.java:359) atScope2 --- Still not clear if this is a runtime r test setup issue. I have added Ignore annotation until this is resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build failure in helloworld-bpel sample
On Fri, Jun 6, 2008 at 2:49 PM, Simon Nash [EMAIL PROTECTED] wrote: Simon Nash wrote: I did a recent svn update and rebuild and I'm seeing the following test error from the helloworld-bpel sample. Are other people seeing this? Any ideas? Simon I have committed a fix (or at least a workaround) for this build break problem. The revision number is r663938. Just to confirm, this has fixed the problem for me and the sample now builds ok. ...ant
Re: TLP migration
On Thu, May 22, 2008 at 11:55 AM, ant elder [EMAIL PROTECTED] wrote: snip We can also look at doing an official ASF press release, a couple of examples are the Synapse ones at [1] and [2]. We probably want to wait till we have the website migrated to the TLP before sending that out but I'll setup a wiki page for a press release that we can work on in the mean time. See: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Graduation+PR One of the emails about graduation PR suggests: Timing a release to happen just after the graduation is complete is probably the best - saying hey look we're a TLP seems a bit weak news wise, especially if it's before the bits are moved to TLP - http://apache.markmail.org/message/s2qecqsd2d7o77cs We've the 1.3 release being talked about now, i've (slowly) started on some of the TLP migration tasks and hope to do that a bit more actively next week so we should have http://tuscany.apache.org going soon, and there also the Red Hat/JBoss news so we're starting to get some good content for a press release. It would be good to get some quotes from high profile people or customers using Tuscany, and another thing that would be good is to get some stats - Tuscany has had over one hundred thousand downloads type of thing, does anyone have some download numbers to hand? ...ant
[RESULT] [Vote] Release Tuscany Java SCA 1.2.1 (RC1)
Passed with +1s from me, Luciano Resende, Dave Sowerby, Vamsavardhana Reddy , Dan Becker, Simon Laws, Davanum Srinivas, and affirmative comments from Mike Edwards and haleh mahbod. Thanks everyone for participating. ...ant On Sun, Jun 1, 2008 at 10:10 PM, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the release artifacts for the Tuscany SCA for Java 1.2.1 maintenance release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.2.1-RC1/http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1 The _only_ code change in this over the 1.2 release is in r657526 [1], all other changes are just version updates and doc changes for the release. +1 to release from me. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL PROTECTED]
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
On Wed, Jun 4, 2008 at 5:59 PM, Luciano Resende [EMAIL PROTECTED] wrote: The good thing about having a version on the pom is that you can have multiple SNAPSHOTs available in a maven repo (e.g 1.2-SNAPSHOT, 1.2.1-SNAPSHOT, TRUNK x-SNAPSHOT and TRUNK y-SNAPSHOT), this also allows for multiple active development streams. If you have SNAPSHOT only, I guess you are restricted to only latest SNAPSHOT, and I also don't see how you would be able to have multiple active development streams in this case. Well I don't think we should be having multiple active development streams :) Fine to have historic 1.x, 2.x, 3.x etc branches which are kept alive for maintenance, and that will work fine with trunk being just SNAPSHOT. But we're a small group of active committers still learning how to get consensus on things and i worry it could easily end quite badly if we have multiple trunks all being developed in parralel competing to be the next new version. ...ant
[jira] Closed: (TUSCANY-2369) sample-calculator-ws-webapp fails to deploy
[ https://issues.apache.org/jira/browse/TUSCANY-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-2369. -- Resolution: Fixed Works fine today now when i try to debug it with a fresh build sample-calculator-ws-webapp fails to deploy --- Key: TUSCANY-2369 URL: https://issues.apache.org/jira/browse/TUSCANY-2369 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next sample-calculator-ws-webapp fails to deploy on Tomcat with the following: org.osoa.sca.ServiceRuntimeException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:218) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:52) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4356) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:829) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:718) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:258) ... 30 more Caused by: java.lang.NoSuchMethodError: org.apache.tuscany.sca.databinding.DataBinding.getXMLTypeHelperClass()Ljava/lang/Class; at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:515) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:487) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:383) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:159) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68
Re: SCA 1.2.1 release
The vote for the 1.2.1 release has now passed - http://apache.markmail.org/message/s23xtktwohpfaacq. I'm a bit busy so will take a little while to get the website etc updated (unless anyone wants to help sooner?) but I've copied the artifacts to the maven repository so they are now publicly available to use. ...ant On Mon, Jun 2, 2008 at 10:47 AM, Dave Sowerby [EMAIL PROTECTED] wrote: Hey Ant, Thanks for offering to perform this task! Have you managed to make any progress with this? Cheers, Dave. On Thu, May 29, 2008 at 10:15 AM, ant elder [EMAIL PROTECTED] wrote: Yes, now that it looks like everyone wants this to go ahead I'll go do this, not sure if I'll have time to finish it today and I'm out tomorrow but I'll try to make sure the artifacts are built and available by the end of the weekend. ...ant On Thu, May 29, 2008 at 10:07 AM, Dave Sowerby [EMAIL PROTECTED] wrote: Hi All, Could anyone give me any time scales for the 1.2.1 release? The release I'm preparing is due to be released within the next week and is unfortunately blocked awaiting this update. I'm available to assist in any way necessary. Cheers, Dave. On Wed, May 28, 2008 at 7:13 AM, haleh mahbod [EMAIL PROTECTED] wrote: I can help with validating the samples and demos for 1.2.1. On 5/27/08, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 6:26 PM, Simon Nash [EMAIL PROTECTED] wrote: Dave Sowerby wrote: Hi Simon, With regards to the 1.2.1 release you are correct that we have a patched version of tuscany-sca-all which would work, but this however leaves us in an awkward configuration position. We're currently preparing a software release based around Tuscany which is completely open to customers of our use of Tuscany, such that we document fully how to construct services independent of our software. As such, we do not ship any Tuscany artifacts and instead encourage our customers to utilise the published maven repository. Whilst requiring a patch version of one of the jars is possible; I don't feel that this is a good representation of Tuscany - either documenting a variant version or expecting a non-standard version of 1.2-incubating. These potential solutions are more likely to cause issues for customers that would undermine the image of Tuscany that we try to project. Is anyone adamantly opposed to this release? Do you feel Tuscany 1.2.1 is still an option? I'd hope that given the potential to damage our customer's perception of Tuscany would be enough to justify this minor release. Thanks for the clarifaction and explanation. It seems to me that because we distribute Tuscany via Maven repos, which can't be patched, this kind of situation will arise whenever a serious bug is found. We can use patches to isolate a problem and confirm the fix, but we generally won't be able to use them as an alternative to a release. In a situation like this, unless a new release is imminent, the best solution seems to be to produce a quick bug fix release without incurring the overhead of a full release and testing cycle. Ant has suggested that we could do this by applying a small set of carefully controlled changes to the previous 1.2 release tag. I think we need to be very strict about what changes go in, to avoid another experience like 1.0.1. Specifically, I would suggest only including the fix for TUSCANY-2304. What do others think of this? Simon Cheers, Dave. On Tue, May 20, 2008 at 12:00 PM, Simon Nash [EMAIL PROTECTED] wrote: Nishant Joshi wrote: Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . Hi Nishant, The work to fix TUSCANY-2251 has turned out bigger than expected. It's one of those cases where the first 80%-90% can be done quite quickly but supporting the final 10%-20% of cases turns up many issues, some of which require
Re: JMS Client
On Wed, Jun 4, 2008 at 6:08 AM, Nishant Joshi [EMAIL PROTECTED] wrote: Hi All, I m new to JMS, I have a question regarding a JMS client means How can i access Tuscnay JMS service remotely. I have refered sample from https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-jms-webapp/ and deployed it on WS with instruction given on README file. It was working fine and i can access a client jsp given with the sample. so in binding.ws i can pass a service url and access the service from my client which was remote means on diff machine. So how can it be possible with binding.jms ? Ex. I have one Sample service which was deployed on machine X and port 8080 so my service address is like http://X:8080/MyService/MyComponent http://x:8080/MyService/MyComponent so this is the url where wsdl was generating. now from client side (which was on machine Y) scdl i have following kinda structure... component name=ClientComponent implementation.java class=com.sample.Client / reference name=service / /component reference name=service promote=ClientComponent/service interface.java interface=com.sample.MyService / binding.ws uri=http://X:8080/MyService/MyComponent http://x:8080/MyService/MyComponent / /reference so I want same kinda sample for binding.jms has anybody try this ? -- Thanks Nishant Joshi Yes you can do this by telling the client where the remote JMS broker is. You do that with the jndiURL and initialContextFactory attributes of the JMS binding. There's an example of this in an testcase at https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/external/client.composite. That test uses ActiveMQ, I've not actually tried this on WebShpere but I think by default the JNDI port is 2809 and the initialContextFactory class is com.ibm.websphere.naming.WsnInitialContextFactory. ...ant
Re: svn commit: r663002 - in /incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources: tuscany-sca-data-helper.xsd tuscany-sca-implementation-das.xsd tuscany-sca-implementation-data-xml.xsd
I'm getting a build failure in modules/assembly-xml after this with the error below, does anyone else see that? Commenting out the includes for implementation-das and data-xml gets it going again. testReadBinding(org.apache.tuscany.sca.assembly.xml.ReadDocumentTestCase) Time elapsed: 0.032 sec ERROR! java.lang.IllegalStateException: org.xml.sax.SAXParseException: cos-nonambig: WC[http://tuscany.apache.org/xmlns/sca/1. 0] and http://tuscany.apache.org/xmlns/sca/1.0:ConnectionInfo (or elements from their substitution group) violate Un ique Particle Attribution. During validation against this schema, ambiguity would be created for those two particles. at org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory.initializeSchemas(DefaultValid atingXMLInputFactory.java:135) ...ant On Wed, Jun 4, 2008 at 7:27 AM, [EMAIL PROTECTED] wrote: Author: lresende Date: Tue Jun 3 23:27:11 2008 New Revision: 663002 URL: http://svn.apache.org/viewvc?rev=663002view=rev Log: Schema for implementation.das and implementation.data Added: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd (with props) incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd (with props) incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-data-xml.xsd (with props) Modified: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca.xsd Added: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd?rev=663002view=auto == --- incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd (added) +++ incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd Tue Jun 3 23:27:11 2008 @@ -0,0 +1,44 @@ +?xml version=1.0 encoding=UTF-8? +!-- + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. +-- +schema xmlns=http://www.w3.org/2001/XMLSchema; +targetNamespace=http://data.tuscany.apache.org/xmlns/sca/1.0; +xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; +xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0; +xmlns:data=http://data.tuscany.apache.org/xmlns/sca/1.0; +elementFormDefault=qualified + +complexType name=ConnectionProperties + attribute name=driverClass type=string / + attribute name=databaseURL type=string / + attribute name=userName type=string default= / + attribute name=password type=string default= / + attribute name=loginTimeout type=int default=0 / +/complexType + +complexType name=ConnectionInfo + sequence + element maxOccurs=1 minOccurs=0 + name=ConnectionProperties type=data:ConnectionProperties / + /sequence + attribute name=dataSource type=string / + attribute name=managedtx type=boolean + default=true / +/complexType +/schema Propchange: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd -- svn:eol-style = native Propchange: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd -- svn:keywords = Rev Date Propchange: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd -- svn:mime-type = text/xml Added: incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd?rev=663002view=auto
itest/validation problem
I'm getting a test fail in itest/validation with the failed test: testCalculator(impl.resource.CouldNotResolveLocationTestCase). Does this work or fail for anyone else? ...ant
[jira] Created: (TUSCANY-2369) sample-calculator-ws-webapp fails to deploy
sample-calculator-ws-webapp fails to deploy --- Key: TUSCANY-2369 URL: https://issues.apache.org/jira/browse/TUSCANY-2369 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next sample-calculator-ws-webapp fails to deploy on Tomcat with the following: org.osoa.sca.ServiceRuntimeException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:218) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:52) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4356) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:829) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:718) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:258) ... 30 more Caused by: java.lang.NoSuchMethodError: org.apache.tuscany.sca.databinding.DataBinding.getXMLTypeHelperClass()Ljava/lang/Class; at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:515) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:487) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:383) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:159) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47
Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to remove incubating at some point and as its not clear if the next release would be 2.0 or something else so i wondered if we should also remove the 2.0 giving a trunk version of simply SNAPSHOT? Any comments on that or the timeframe for doing the change? I'd like to do it nowish so we have some time to discover any problems before the next release. ...ant
Re: [jira] Updated: (TUSCANY-2357) CORBA objects invocation mechanism
Thanks for reminding, i'm applying it now. ...ant On Wed, Jun 4, 2008 at 12:17 PM, Wojtek Janiszewski [EMAIL PROTECTED] wrote: Hi, I'm starting to worry that following patch will be orphaned :). Could anyone take a look? Thanks, Wojtek Wojtek Janiszewski (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Wojtek Janiszewski updated TUSCANY-2357: Attachment: add-license-headers.patch.tar.gz Thanks for reminding. Here's a patch which adds headers to all java and idl files. Wojtek CORBA objects invocation mechanism -- Key: TUSCANY-2357 URL: https://issues.apache.org/jira/browse/TUSCANY-2357 Project: Tuscany Issue Type: New Feature Reporter: Wojtek Janiszewski Attachments: add-license-headers.patch.tar.gz, corba-operation-invoker.patch.tar.gz Implementation of generic mechanism for remote operation invocation: passing CORBA structures, sequences, primitives as arguments, retrieving return values (also structs, seq, prims.). There is no exception handling yet. It's not connected to CORBA binding extension yet - it won't be hard, and I think it's now more important to complete this generic mechanism. Some tests are provided - you need to have tnameserv in your PATH to run tests correctly!
[jira] Commented: (TUSCANY-2357) CORBA objects invocation mechanism
[ https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602249#action_12602249 ] ant elder commented on TUSCANY-2357: Applied license header patch in r663066, thanks for the patch! CORBA objects invocation mechanism -- Key: TUSCANY-2357 URL: https://issues.apache.org/jira/browse/TUSCANY-2357 Project: Tuscany Issue Type: New Feature Reporter: Wojtek Janiszewski Attachments: add-license-headers.patch.tar.gz, corba-operation-invoker.patch.tar.gz Implementation of generic mechanism for remote operation invocation: passing CORBA structures, sequences, primitives as arguments, retrieving return values (also structs, seq, prims.). There is no exception handling yet. It's not connected to CORBA binding extension yet - it won't be hard, and I think it's now more important to complete this generic mechanism. Some tests are provided - you need to have tnameserv in your PATH to run tests correctly! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JMS Client
On Wed, Jun 4, 2008 at 11:21 AM, Nishant Joshi [EMAIL PROTECTED]
wrote:
Thanks Ant,
I have composed client for WS Here is the snippet of the client
-
public class HelloWorldClientImpl {
@Reference
protected HelloWorldService serviceA;
public String sayHello(String name) {
System.out.println(HelloWorldClientImpl.serviceA = +serviceA);
return serviceA.sayHello(name);
}
}
-
@Remotable
public interface HelloWorldService {
String sayHello(String name);
}
-
public class JMSClient {
public static void main(String[] args) throws NodeException {
SCANode node = SCANodeFactory.createNodeWithComposite(client.composite);
HelloWorldClientImpl client =
node.getDomain().getService(HelloWorldClientImpl.class,
HelloWorldClient);
System.out.println(client.sayHello(World));
}
}
-
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=RPCComposite
component name=HelloWorldClient
implementation.java class=helloworld.HelloWorldClientImpl/
reference name=serviceA /
/component
reference name=serviceA promote=HelloWorldClient/serviceA
interface.java interface=helloworld.HelloWorldService /
binding.jms
initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory
jndiURL=iiop://localhost:2809
destination name=HelloWorldService/
response
destination name=HelloWorldService/
/response
/binding.jms
/reference
/composite
-
jndi.properties
# START SNIPPET: jndi
java.naming.factory.initial =
com.ibm.websphere.naming.WsnInitialContextFactory
# use the following property to configure the default connector
java.naming.provider.url = vm://localhost?broker.persistent=false
# use the following property to specify the JNDI name the connection
factory
# should appear as.
#connectionFactoryNames = connectionFactory, queueConnectionFactory,
topicConnectionFactry
connectionFactoryNames = ConnectionFactory
# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
# queue.RequestQueue = RequestQueue
# queue.ResponseQueue = ResponseQueue
queue.HelloWorldService = HelloWorldService
# register some topics in JNDI using the form
# topic.[jndiName] = [physicalName]
#topic.MyTopic = example.MyTopic
# END SNIPPET: jndi
Here Service is deployed successfuly, i can test with hello.jspIt was
working fine in WS.
Now when i run above code I m getting HelloWorldClientImpl.serviceA =
null
and gettign NPE
I m using HelloWorldService for both Request and Response queue...
any idea ?
Thanks
Nishant Joshi
I'll give it a try but it will take a while as I'm still recovering from a
harddrive crash last week so will need to find and reinstall WebSphere.
Anyone else with WAS installed able to give this a try in the meantime with
the helloworld-jms-webapp sample?
...ant
Re: [Vote] Release Tuscany Java SCA 1.2.1 (RC1)
Thanks for the vote. It seemed safer for this maintenance release to keep incubating in the artifact names just to minimize changes. It probably is as easy as the change to the release number but who know where problems may hide. I thought we could use the up coming SDO 1.1.1 release as a test of removing the suffix to see if the are any places that we need to be careful with. ...ant On Tue, Jun 3, 2008 at 8:10 AM, Luciano Resende [EMAIL PROTECTED] wrote: My only minor comment is whether we are still going to use incubating on the release name/artifacts. Other then that, all looks ok, and here is my +1. On Sun, Jun 1, 2008 at 2:10 PM, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the release artifacts for the Tuscany SCA for Java 1.2.1 maintenance release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.2.1-RC1/http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/ http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1 The _only_ code change in this over the 1.2 release is in r657526 [1], all other changes are just version updates and doc changes for the release. +1 to release from me. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: [VOTE] Release SDO 1.1.1
Adding an exclude for felix to the distribution pom can fix that, eg here's
local changes i have just tried:
Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml (revision 662488)
+++ src/main/assembly/bin.xml (working copy)
@@ -120,13 +120,13 @@
dependencySets
dependencySet
outputDirectorytuscany-sdo-${sdo.version}/lib/outputDirectory
-includes
-
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
+!-- includes
+
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
includeorg.apache.tuscany.sdo:tuscany-sdo-lib/include
includeorg.apache.tuscany.sdo:tuscany-sdo-impl/include
includeorg.apache.tuscany.sdo:tuscany-sdo-tools/include
includeorg.apache.tuscany.sdo:sample-sdo/include
-/includes
+/includes --
fileMode0644/fileMode
/dependencySet
Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12 @@
groupIdorg.apache.tuscany.sdo/groupId
artifactIdtuscany-sdo-impl/artifactId
version${pom.version}/version
+exclusions
+exclusion
+groupIdorg.apache.felix/groupId
+artifactIdorg.apache.felix.main/artifactId
+/exclusion
+/exclusions
/dependency
dependency
groupIdorg.apache.tuscany.sdo/groupId
@@ -67,6 +73,7 @@
artifactIdsample-sdo/artifactId
version${pom.version}/version
/dependency
+
/dependencies
build
Which results in a lib directory containing:
backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1-incubating-SNAPSHOT.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar
...ant
On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
I had an offline chat with Rajini. It seems we need just the framework jar
of felix in the distro, but if the dependency on felix is declared as test
scope in the pom, then that jar is not available to main phase of the
build. If its not declared as test scope then we get 5 felix jars in the
binary distro. Rajini's going to take a look when she gets some time.
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The felix jars were introduced in the fix for SDO does not work with
OSGi [1] in commit 620763 [2]. I don't know if this is expected
behaviour, not being an OSGI expert. Comments anyone?
Kelvin.
[1] https://issues.apache.org/jira/browse/TUSCANY-1293
[2] http://svn.apache.org/viewcvs?view=revrev=620763
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The required libraries are
sample-sdo-%RELEASE%.jar
sdo-api-r2.1-%RELEASE%.jar
tuscany-sdo-lib-%RELEASE%.jar
tuscany-sdo-impl-%RELEASE%.jar
tuscany-sdo-tools-%RELEASE%.jar
codegen-ecore-2.2.3.jar
codegen-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
common-2.2.3.jar
xsd-2.2.3.jar
stax-api-1.0.1.jar
wstx-asl-3.2.0.jar
with
backport-util-concurrent being optional if you want threadsafe
collections with Java 1.4 IIRC
The felix jar inclusions were introduced some time between commit level
600913 and 627754; I'm working on narrowing this down at the moment.
Kelvin.
2008/6/2 ant elder [EMAIL PROTECTED]:
It is strange.
Removing the includes at the bottom of the assembly bin.xml changes it
so
that the dependencies do get included again, but several felix
dependencies
also get dragged in. What is the complete list of jars that should be
included?
...ant
On Mon, Jun 2, 2008 at 6:02 PM, kelvin goodson [EMAIL PROTECTED]
wrote:
This failure also occurs with the 2.1 version and the 2.2-beta-1
version.
The current trunk version is 2.2-beta-3-SNAPSHOT, which I haven't
found in
a repository yet, so the only version that seems ever to have worked
is
the
2.2-SNAPSHOT version. I have taken a look at the assembly plugin
JIRAs,
but
it's hard to trawl that since so many JIRAs reference the word
dependency.
It's not clear to me whether we benefited from a freak bug that was to
our
advantage in the 2.2-SNAPSHOT version or whether all the other
versions
have
a bug/bugs.
Kelvin.
2008/6/2 kelvin goodson [EMAIL PROTECTED]:
I have pinned down the change that caused the absence of EMF jars in
the
distribution zip to be the switch from the maven assembly plugin
version
2.2-SNAPSHOT to the 2.2-beta-2 as altered here [1].I hope
Re: [VOTE] Release SDO 1.1.1
That sounds right to me.
...ant
On Tue, Jun 3, 2008 at 11:57 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
Just a thought, would I be right in guessing that if ever our
SdoBundleActivator is touched in the runtime, then the environment would
be
expected to provide the classes to satisfy
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
?
in which case I think declaring a provided scope for the felix dependency
would be the right way to do things
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
Thanks Ant, that looks like progress, but the felix framework jar is
now
not in the list of distributed jars.
Kelvin.
2008/6/3 ant elder [EMAIL PROTECTED]:
Adding an exclude for felix to the distribution pom can fix that, eg
here's
local changes i have just tried:
Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml (revision 662488)
+++ src/main/assembly/bin.xml (working copy)
@@ -120,13 +120,13 @@
dependencySets
dependencySet
outputDirectorytuscany-sdo-${sdo.version}/lib/outputDirectory
-includes
-
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
+!-- includes
+
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
includeorg.apache.tuscany.sdo:tuscany-sdo-lib/include
includeorg.apache.tuscany.sdo:tuscany-sdo-impl/include
includeorg.apache.tuscany.sdo:tuscany-sdo-tools/include
includeorg.apache.tuscany.sdo:sample-sdo/include
-/includes
+/includes --
fileMode0644/fileMode
/dependencySet
Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12 @@
groupIdorg.apache.tuscany.sdo/groupId
artifactIdtuscany-sdo-impl/artifactId
version${pom.version}/version
+exclusions
+exclusion
+groupIdorg.apache.felix/groupId
+artifactIdorg.apache.felix.main/artifactId
+/exclusion
+/exclusions
/dependency
dependency
groupIdorg.apache.tuscany.sdo/groupId
@@ -67,6 +73,7 @@
artifactIdsample-sdo/artifactId
version${pom.version}/version
/dependency
+
/dependencies
build
Which results in a lib directory containing:
backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1-incubating-SNAPSHOT.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar
...ant
On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
I had an offline chat with Rajini. It seems we need just the
framework
jar
of felix in the distro, but if the dependency on felix is declared as
test
scope in the pom, then that jar is not available to main phase of the
build. If its not declared as test scope then we get 5 felix jars in
the
binary distro. Rajini's going to take a look when she gets some time.
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The felix jars were introduced in the fix for SDO does not work
with
OSGi [1] in commit 620763 [2]. I don't know if this is expected
behaviour, not being an OSGI expert. Comments anyone?
Kelvin.
[1] https://issues.apache.org/jira/browse/TUSCANY-1293
[2] http://svn.apache.org/viewcvs?view=revrev=620763
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The required libraries are
sample-sdo-%RELEASE%.jar
sdo-api-r2.1-%RELEASE%.jar
tuscany-sdo-lib-%RELEASE%.jar
tuscany-sdo-impl-%RELEASE%.jar
tuscany-sdo-tools-%RELEASE%.jar
codegen-ecore-2.2.3.jar
codegen-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
common-2.2.3.jar
xsd-2.2.3.jar
stax-api-1.0.1.jar
wstx-asl-3.2.0.jar
with
backport-util-concurrent being optional if you want threadsafe
collections with Java 1.4 IIRC
The felix jar inclusions were introduced some time between commit
level
600913 and 627754; I'm working on narrowing this down at the
moment.
Kelvin.
2008/6/2 ant elder [EMAIL PROTECTED]:
It is strange.
Removing the includes at the bottom of the assembly bin.xml
changes
it
so
that the dependencies do get included again, but several felix
dependencies
also get dragged in. What is the complete list of jars that should
be
included
Re: [VOTE] Release SDO 1.1.1
Sounds good to me.
...ant
On Tue, Jun 3, 2008 at 1:03 PM, kelvin goodson [EMAIL PROTECTED]
wrote:
OK, I think I have everything I need now to respin this RC. I'm inclined
to take the opportunity to remove the incubating tag on this release
whilst I'm fixing up the poms.
Kelvin.
2008/6/3 ant elder [EMAIL PROTECTED]:
That sounds right to me.
...ant
On Tue, Jun 3, 2008 at 11:57 AM, kelvin goodson [EMAIL PROTECTED]
wrote:
Just a thought, would I be right in guessing that if ever our
SdoBundleActivator is touched in the runtime, then the environment
would
be
expected to provide the classes to satisfy
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
?
in which case I think declaring a provided scope for the felix
dependency
would be the right way to do things
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
Thanks Ant, that looks like progress, but the felix framework jar is
now
not in the list of distributed jars.
Kelvin.
2008/6/3 ant elder [EMAIL PROTECTED]:
Adding an exclude for felix to the distribution pom can fix that, eg
here's
local changes i have just tried:
Index: src/main/assembly/bin.xml
===
--- src/main/assembly/bin.xml (revision 662488)
+++ src/main/assembly/bin.xml (working copy)
@@ -120,13 +120,13 @@
dependencySets
dependencySet
outputDirectorytuscany-sdo-${sdo.version}/lib/outputDirectory
-includes
-
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
+!-- includes
+
includeorg.apache.tuscany.sdo:tuscany-sdo-api-r2.1/include
includeorg.apache.tuscany.sdo:tuscany-sdo-lib/include
includeorg.apache.tuscany.sdo:tuscany-sdo-impl/include
includeorg.apache.tuscany.sdo:tuscany-sdo-tools/include
includeorg.apache.tuscany.sdo:sample-sdo/include
-/includes
+/includes --
fileMode0644/fileMode
/dependencySet
Index: pom.xml
===
--- pom.xml (revision 662488)
+++ pom.xml (working copy)
@@ -56,6 +56,12 @@
groupIdorg.apache.tuscany.sdo/groupId
artifactIdtuscany-sdo-impl/artifactId
version${pom.version}/version
+exclusions
+exclusion
+groupIdorg.apache.felix/groupId
+artifactIdorg.apache.felix.main/artifactId
+/exclusion
+/exclusions
/dependency
dependency
groupIdorg.apache.tuscany.sdo/groupId
@@ -67,6 +73,7 @@
artifactIdsample-sdo/artifactId
version${pom.version}/version
/dependency
+
/dependencies
build
Which results in a lib directory containing:
backport-util-concurrent-3.0.jar
codegen-2.2.3.jar
codegen-ecore-2.2.3.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
sample-sdo-1.1.1-incubating-SNAPSHOT.jar
stax-api-1.0.1.jar
tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
wstx-asl-3.2.1.jar
xsd-2.2.3.jar
...ant
On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson
[EMAIL PROTECTED]
wrote:
I had an offline chat with Rajini. It seems we need just the
framework
jar
of felix in the distro, but if the dependency on felix is declared
as
test
scope in the pom, then that jar is not available to main phase of
the
build. If its not declared as test scope then we get 5 felix jars
in
the
binary distro. Rajini's going to take a look when she gets some
time.
Kelvin.
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The felix jars were introduced in the fix for SDO does not work
with
OSGi [1] in commit 620763 [2]. I don't know if this is expected
behaviour, not being an OSGI expert. Comments anyone?
Kelvin.
[1] https://issues.apache.org/jira/browse/TUSCANY-1293
[2] http://svn.apache.org/viewcvs?view=revrev=620763
2008/6/3 kelvin goodson [EMAIL PROTECTED]:
The required libraries are
sample-sdo-%RELEASE%.jar
sdo-api-r2.1-%RELEASE%.jar
tuscany-sdo-lib-%RELEASE%.jar
tuscany-sdo-impl-%RELEASE%.jar
tuscany-sdo-tools-%RELEASE%.jar
codegen-ecore-2.2.3.jar
codegen-2.2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
common-2.2.3.jar
xsd-2.2.3.jar
stax-api-1.0.1.jar
wstx-asl-3.2.0.jar
with
backport-util-concurrent being optional if you want threadsafe
collections with Java 1.4
Re: parent pom and incubator references
On Tue, Jun 3, 2008 at 2:24 PM, kelvin goodson [EMAIL PROTECTED] wrote: As mentioned elsewhere on this list in the discussion about respinning the SDO 1.1.1 RC, I'm hoping to drop the incubating tag in the release name. This has led me to look at the parent pom, and I guess we need a new version of parent pom that doesn't reference the incubator repo, and then open a vote on that. I may be opening a whole new kettle of Pandora's worms that would have been best left unopened for a point release. On the other hand I guess it needs doing some time soon. Digging around a few other top level projects, and seeing the comments in our own parent pom, it would appear I might be able to just drop the apache.incubator repository stanza in a new revision of the parent pom. Is that true? any guidance would be very welcome. Kelvin. How about removing the reference to the Tuscany parent pom and just defining whatever is required in the top level SDO pom.xml. We talked about doing this once before - http://apache.markmail.org/message/2woxtw7lfalm3rtx. The only concern was if it caused trouble if building all the subprojects under tuscany/java together, but does anyone ever do that these days? ...ant
[jira] Created: (TUSCANY-2359) Rationalize the SCA runtime use of cglib and asm dependencies
Rationalize the SCA runtime use of cglib and asm dependencies - Key: TUSCANY-2359 URL: https://issues.apache.org/jira/browse/TUSCANY-2359 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next The Tuscany runtime now has dependencies on both asm-all and cglib-nodep, these both do the same type of thing, and the -nodep version of cglib includes asm, so it would be nice to rationalize the use of these to just one dependency. Asm is used by interface-java-jaxws, cglib-nodep is used by CglibProxyFactory.java in the core module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JAXWSJavaInterfaceProcessorTestCase fail?
On a fresh check out I'm getting a failure in JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just me? ...ant testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase) Time elapsed: 0.046 s ec FAILURE! junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt erfaceProcessorTestCase.java:80)
Re: JAXWSJavaInterfaceProcessorTestCase fail?
Looks like this is a jdk issue, works ok with IBM JDK5 but always fails for me with the Sun JDK. ...ant On Mon, Jun 2, 2008 at 8:50 AM, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Jun 2, 2008 at 8:32 AM, ant elder [EMAIL PROTECTED] wrote: On a fresh check out I'm getting a failure in JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just me? ...ant testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase) Time elapsed: 0.046 s ec FAILURE! junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt erfaceProcessorTestCase.java:80) Failed for me also first time through with mvn -o. Just tried building that module independently with mvn clean and then mvn and it appears to work.So I'll try another build and see what happens. Simon
Re: JAXWSJavaInterfaceProcessorTestCase fail?
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04) ...ant On Mon, Jun 2, 2008 at 10:30 AM, Mike Edwards [EMAIL PROTECTED] wrote: ant elder wrote: Looks like this is a jdk issue, works ok with IBM JDK5 but always fails for me with the Sun JDK. ...ant On Mon, Jun 2, 2008 at 8:50 AM, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Jun 2, 2008 at 8:32 AM, ant elder [EMAIL PROTECTED] wrote: On a fresh check out I'm getting a failure in JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just me? ...ant testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase) Time elapsed: 0.046 s ec FAILURE! junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt erfaceProcessorTestCase.java:80) Failed for me also first time through with mvn -o. Just tried building that module independently with mvn clean and then mvn and it appears to work.So I'll try another build and see what happens. Simon Ant, Which level of the Sun JDK are you using? Is this a JAXB level issue? Sun changed horses on JAXB during the 6.0 releases Yours, Mike.
[jira] Commented: (TUSCANY-2357) CORBA objects invocation mechanism
[ https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601596#action_12601596 ] ant elder commented on TUSCANY-2357: Thanks Wojtek, patch applied. One comment, where possible the files in SVN should have the ASF license header you can see the format from existing files, eg its the following for Java files: /* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * License); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY * KIND, either express or implied. See the License for the * specific language governing permissions and limitations * under the License. */ CORBA objects invocation mechanism -- Key: TUSCANY-2357 URL: https://issues.apache.org/jira/browse/TUSCANY-2357 Project: Tuscany Issue Type: New Feature Reporter: Wojtek Janiszewski Attachments: corba-operation-invoker.patch.tar.gz Implementation of generic mechanism for remote operation invocation: passing CORBA structures, sequences, primitives as arguments, retrieving return values (also structs, seq, prims.). There is no exception handling yet. It's not connected to CORBA binding extension yet - it won't be hard, and I think it's now more important to complete this generic mechanism. Some tests are provided - you need to have tnameserv in your PATH to run tests correctly! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2291) Runtime does not detect illegal mix of local and remoteable on bidirectional interface
[ https://issues.apache.org/jira/browse/TUSCANY-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601556#action_12601556 ] ant elder commented on TUSCANY-2291: Fixed in r662367 but the vtest is still commented out because as an exception is thrown when this problem is detected that breaks all the other tests in this vtest module. The vtest could be changed to work like vtest-java-api-annotations-destroy to use SCANode2Factory to start individual composites but there's also work on going to use monitors and trapping exceptions so a validation error doesn't stop the domain startup so maybe thats the better fix Runtime does not detect illegal mix of local and remoteable on bidirectional interface -- Key: TUSCANY-2291 URL: https://issues.apache.org/jira/browse/TUSCANY-2291 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Priority: Minor Fix For: Java-SCA-Next From Lines 534, 535 of the Java API/Annotaitons spec: Callbacks may be used for both remotable and local services. Either both interfaces of a bidirectional service must be remotable, or both must be local. It is illegal to mix the two. The test org.apache.tuscany.sca.vtest.javaapi.conversation.callback.statefulCallback3 demonstrates this error and 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: SCA 1.2.1 release
Yes! See - http://apache.markmail.org/message/bd7dw4ixeauvyznk. ...ant On Mon, Jun 2, 2008 at 10:47 AM, Dave Sowerby [EMAIL PROTECTED] wrote: Hey Ant, Thanks for offering to perform this task! Have you managed to make any progress with this? Cheers, Dave. On Thu, May 29, 2008 at 10:15 AM, ant elder [EMAIL PROTECTED] wrote: Yes, now that it looks like everyone wants this to go ahead I'll go do this, not sure if I'll have time to finish it today and I'm out tomorrow but I'll try to make sure the artifacts are built and available by the end of the weekend. ...ant On Thu, May 29, 2008 at 10:07 AM, Dave Sowerby [EMAIL PROTECTED] wrote: Hi All, Could anyone give me any time scales for the 1.2.1 release? The release I'm preparing is due to be released within the next week and is unfortunately blocked awaiting this update. I'm available to assist in any way necessary. Cheers, Dave. On Wed, May 28, 2008 at 7:13 AM, haleh mahbod [EMAIL PROTECTED] wrote: I can help with validating the samples and demos for 1.2.1. On 5/27/08, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 6:26 PM, Simon Nash [EMAIL PROTECTED] wrote: Dave Sowerby wrote: Hi Simon, With regards to the 1.2.1 release you are correct that we have a patched version of tuscany-sca-all which would work, but this however leaves us in an awkward configuration position. We're currently preparing a software release based around Tuscany which is completely open to customers of our use of Tuscany, such that we document fully how to construct services independent of our software. As such, we do not ship any Tuscany artifacts and instead encourage our customers to utilise the published maven repository. Whilst requiring a patch version of one of the jars is possible; I don't feel that this is a good representation of Tuscany - either documenting a variant version or expecting a non-standard version of 1.2-incubating. These potential solutions are more likely to cause issues for customers that would undermine the image of Tuscany that we try to project. Is anyone adamantly opposed to this release? Do you feel Tuscany 1.2.1 is still an option? I'd hope that given the potential to damage our customer's perception of Tuscany would be enough to justify this minor release. Thanks for the clarifaction and explanation. It seems to me that because we distribute Tuscany via Maven repos, which can't be patched, this kind of situation will arise whenever a serious bug is found. We can use patches to isolate a problem and confirm the fix, but we generally won't be able to use them as an alternative to a release. In a situation like this, unless a new release is imminent, the best solution seems to be to produce a quick bug fix release without incurring the overhead of a full release and testing cycle. Ant has suggested that we could do this by applying a small set of carefully controlled changes to the previous 1.2 release tag. I think we need to be very strict about what changes go in, to avoid another experience like 1.0.1. Specifically, I would suggest only including the fix for TUSCANY-2304. What do others think of this? Simon Cheers, Dave. On Tue, May 20, 2008 at 12:00 PM, Simon Nash [EMAIL PROTECTED] wrote: Nishant Joshi wrote: Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . Hi Nishant, The work to fix TUSCANY-2251 has turned out bigger than expected. It's one of those cases where the first 80%-90% can be done quite quickly but supporting the final 10%-20% of cases turns up many issues, some of which require changes in other parts of the code. I'm preparing a (large) checkin to update the new generator code so that it handles most of the cases (perhaps 95%). This should be enough to get the full build to run with the new code. However
Re: what should happen if service and binding.ws require different soap version?
I think right now our binding.ws services (or Axis2 services) will work with either SOAP 1.1 or 1.2, and the response from the service will use the same soap version as the request. Thats the default Axis2 behaviour, not sure if its possible to change to restrict that. So right now the Tuscany code only uses the soap intent for references. So those two marked as Error below will actually just work with the current Tuscany code. ...ant On Mon, Jun 2, 2008 at 5:01 PM, Gilbert Kwan [EMAIL PROTECTED] wrote: The following table shows all combinations: Service Require vs Reference Require: None vs None: OK None vs soap: OK None vs soap.1_1: OK None vs soap.1_2: OK soap vs None: OK soap vs soap: OK soap vs soap.1_1: OK soap vs soap.1_2: OK soap.1_1 vs None: OK soap.1_1 vs soap: OK soap.1_1 vs soap.1_1: OK soap.1_1 vs soap.1_2: Error soap.1_2 vs None: OK soap.1_2 vs soap: OK soap.1_2 vs soap.1_1: Error soap.1_2 vs soap.1_2: OK I guess there are only 2 scenarios should generate error. Right? Thanks Gilbert On Mon, Jun 2, 2008 at 6:17 AM, Mike Edwards [EMAIL PROTECTED] wrote: Gilbert Kwan wrote: I defined a service requires soap.1_2 component name=BComponentSOAP12 implementation.java class=BServiceSOAP12Impl/ service name=BServiceSOAP12 interface.java interface=BServiceSOAP12/ binding.ws requires=soap.1_2/ /service /component and a reference by ws binding which requires soap.1_1 component name=AComponent15 implementation.java class=AServiceImpl/ reference name=b1 target=BComponentSOAP12/BServiceSOAP12 interface.java interface=..BServiceSOAP12/ binding.ws requires=soap.1_1 uri=http://localhost:8080/BComponentSOAP12/ /reference /component I got no warning, error message, or exception. Is it fine? What is the proper behaviour of this scenario? Thanks Gilbert Gilbert, That looks like an error to me. Both sides need to be using the same SOAP level. Looks like a failure of the policy matching between the two ends - I suggest raising a JIRA for this one. Yours, Mike.
[NOTICE] Vamsavardhana Reddy voted as Tuscany committer
The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany committer. Congratulations and welcome! ...ant
Re: JAXWSJavaInterfaceProcessorTestCase fail?
Works for me now, thanks. ...ant On Mon, Jun 2, 2008 at 6:56 PM, Raymond Feng [EMAIL PROTECTED] wrote: Now it should be fixed under r662499. There was a typo in the code that led to JDK dependent behaviors (ordering in the Class.getMethods()). Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Monday, June 02, 2008 2:37 AM To: tuscany-dev@ws.apache.org Subject: Re: JAXWSJavaInterfaceProcessorTestCase fail? Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04) ...ant On Mon, Jun 2, 2008 at 10:30 AM, Mike Edwards [EMAIL PROTECTED] wrote: ant elder wrote: Looks like this is a jdk issue, works ok with IBM JDK5 but always fails for me with the Sun JDK. ...ant On Mon, Jun 2, 2008 at 8:50 AM, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Jun 2, 2008 at 8:32 AM, ant elder [EMAIL PROTECTED] wrote: On a fresh check out I'm getting a failure in JAXWSJavaInterfaceProcessorTestCase, anyone else seeing that or is it just me? ...ant testProcessor(org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase) Time elapsed: 0.046 s ec FAILURE! junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessorTestCase.testProcessor(JAXWSJavaInt erfaceProcessorTestCase.java:80) Failed for me also first time through with mvn -o. Just tried building that module independently with mvn clean and then mvn and it appears to work.So I'll try another build and see what happens. Simon Ant, Which level of the Sun JDK are you using? Is this a JAXB level issue? Sun changed horses on JAXB during the 6.0 releases Yours, Mike.
Re: [VOTE] Release SDO 1.1.1
It is strange. Removing the includes at the bottom of the assembly bin.xml changes it so that the dependencies do get included again, but several felix dependencies also get dragged in. What is the complete list of jars that should be included? ...ant On Mon, Jun 2, 2008 at 6:02 PM, kelvin goodson [EMAIL PROTECTED] wrote: This failure also occurs with the 2.1 version and the 2.2-beta-1 version. The current trunk version is 2.2-beta-3-SNAPSHOT, which I haven't found in a repository yet, so the only version that seems ever to have worked is the 2.2-SNAPSHOT version. I have taken a look at the assembly plugin JIRAs, but it's hard to trawl that since so many JIRAs reference the word dependency. It's not clear to me whether we benefited from a freak bug that was to our advantage in the 2.2-SNAPSHOT version or whether all the other versions have a bug/bugs. Kelvin. 2008/6/2 kelvin goodson [EMAIL PROTECTED]: I have pinned down the change that caused the absence of EMF jars in the distribution zip to be the switch from the maven assembly plugin version 2.2-SNAPSHOT to the 2.2-beta-2 as altered here [1].I hope to look at this again soon, but have to stop for now. If anyone has any views on what version we should be using please pipe up. Kelvin. [1] http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/pom.xml?r1=628691r2=642349pathrev=642349diff_format=h Kelvin. 2008/5/19 kelvin goodson [EMAIL PROTECTED]: I'm looking at fixing a problem wrt running the samples at the moment. Also, I found that with a combination of using IBM JDK 1.5 and maven 2.0.7 I got hit by http://jira.codehaus.org/browse/MJAVADOC-135 when trying to build from the top. We say in our BUILDING doc that 2.0.7 is OK, perhaps if we need to respin we should raise that in order to avoid IBM JDK users hitting this issue. It's fine with 2.0.9 Kelvin. 2008/5/18 ant elder [EMAIL PROTECTED]: Please review and vote on the SDO 1.1.1 release. The artifacts including binary and source distributions, staging maven repo and release notes are available at http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC1/http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/ http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/ http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/. The only difference between this and the 1.1 release is the fix for http://issues.apache.org/jira/browse/TUSCANY-2240. +1 from me. ...ant
[Vote] Release Tuscany Java SCA 1.2.1 (RC1)
Please review and vote on the release artifacts for the Tuscany SCA for Java 1.2.1 maintenance release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.2.1-RC1/http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1 The _only_ code change in this over the 1.2 release is in r657526 [1], all other changes are just version updates and doc changes for the release. +1 to release from me. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL PROTECTED]
Re: SCA 1.2.1 release
Yes, now that it looks like everyone wants this to go ahead I'll go do this, not sure if I'll have time to finish it today and I'm out tomorrow but I'll try to make sure the artifacts are built and available by the end of the weekend. ...ant On Thu, May 29, 2008 at 10:07 AM, Dave Sowerby [EMAIL PROTECTED] wrote: Hi All, Could anyone give me any time scales for the 1.2.1 release? The release I'm preparing is due to be released within the next week and is unfortunately blocked awaiting this update. I'm available to assist in any way necessary. Cheers, Dave. On Wed, May 28, 2008 at 7:13 AM, haleh mahbod [EMAIL PROTECTED] wrote: I can help with validating the samples and demos for 1.2.1. On 5/27/08, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 6:26 PM, Simon Nash [EMAIL PROTECTED] wrote: Dave Sowerby wrote: Hi Simon, With regards to the 1.2.1 release you are correct that we have a patched version of tuscany-sca-all which would work, but this however leaves us in an awkward configuration position. We're currently preparing a software release based around Tuscany which is completely open to customers of our use of Tuscany, such that we document fully how to construct services independent of our software. As such, we do not ship any Tuscany artifacts and instead encourage our customers to utilise the published maven repository. Whilst requiring a patch version of one of the jars is possible; I don't feel that this is a good representation of Tuscany - either documenting a variant version or expecting a non-standard version of 1.2-incubating. These potential solutions are more likely to cause issues for customers that would undermine the image of Tuscany that we try to project. Is anyone adamantly opposed to this release? Do you feel Tuscany 1.2.1 is still an option? I'd hope that given the potential to damage our customer's perception of Tuscany would be enough to justify this minor release. Thanks for the clarifaction and explanation. It seems to me that because we distribute Tuscany via Maven repos, which can't be patched, this kind of situation will arise whenever a serious bug is found. We can use patches to isolate a problem and confirm the fix, but we generally won't be able to use them as an alternative to a release. In a situation like this, unless a new release is imminent, the best solution seems to be to produce a quick bug fix release without incurring the overhead of a full release and testing cycle. Ant has suggested that we could do this by applying a small set of carefully controlled changes to the previous 1.2 release tag. I think we need to be very strict about what changes go in, to avoid another experience like 1.0.1. Specifically, I would suggest only including the fix for TUSCANY-2304. What do others think of this? Simon Cheers, Dave. On Tue, May 20, 2008 at 12:00 PM, Simon Nash [EMAIL PROTECTED] wrote: Nishant Joshi wrote: Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . Hi Nishant, The work to fix TUSCANY-2251 has turned out bigger than expected. It's one of those cases where the first 80%-90% can be done quite quickly but supporting the final 10%-20% of cases turns up many issues, some of which require changes in other parts of the code. I'm preparing a (large) checkin to update the new generator code so that it handles most of the cases (perhaps 95%). This should be enough to get the full build to run with the new code. However, I wouldn't consider the new code to be ready to release at that point. It will need quite a bit of further testing and a few more updates to take care of the remaining 5% of cases. Some of these cases will require discussion on the list to agree how they should be handled. Also, the new code will need testing by people other than myself with their scenarios to make sure that it does not break cases that worked with the previous Java2WSDL generator. For all these
Re: Apache Tuscany committer status reaffirmation
On Sat, Apr 12, 2008 at 10:23 AM, ant elder [EMAIL PROTECTED] wrote: You are receiving this email because you are listed as an Apache Tuscany committer. Tuscany is looking to graduate in the near future and following Apache Incubator practice is cleaning up the committer list. Tuscany has 35 committers listed on the status file some of those have left and some were just listed there when the original proposal was accepted and have never even once committed anything. We've decided any one who has interacted with the project within the last 12 months will automatically remain a committer, anyone else will need to reply to this email to retain their committer status. These are the committers who've participated in the last 12 months and will automatically retain their committer status: adrianocrestani Adriano Crestani amita Amita Vadhavkar ajborleyAndrew Borley antelderAnt Elder bjohnsonBrady Johnson dkulp Dan Kulp frankb Frank Budinsky fuhwei Fuhwei Lwo giorgio Giorgio Zoppi isilval Ignacio Silva-Lepe jsdelfino Jean-Sebastien Delfino kelvingoodson Kelvin Goodson kwilliams Kevin Williams lresendeLuciano Resende mcombellack Mark Combellack myoder Michael Yoder edwardsmj Mike Edwards nashSimon Nash rsivaramRajini Sivaram rfeng Raymond Feng robbinspg Pete Robbins slaws Simon Laws svkrish Venkata Krishnan So, if you are not on that list but would like to retain your Tuscany committer status please reply to this email and let us know about how you would like to be involved with Tuscany. Also, if you are on that list but no longer want to stay a committer once Tuscany graduates you can also reply to this email and we'll remove your name. Many thanks, The Apache Tuscany PPMC So after having this pending for over a month that would make the current committer list: adrianocrestani,amita,ajborley,antelder,antollinim,bdaniel,bjohnson,dkulp,frankb,fuhwei,fwang,giorgio,isilval,jsdelfino,kelvingoodson,kwilliams,lresende,mcombellack,myoder,edwardsmj,nash,rsivaram,rfeng,robbinspg,slaws,svkrish ...ant
Re: Tuscany Java2WSDL and WSDL2Java tools
On Thu, May 22, 2008 at 6:02 PM, Raymond Feng [EMAIL PROTECTED] wrote: snip Anyway, so would we be committing to doing this in time for the next release? If so I can stop looking at upgrading the exsiting tools to work with Axis2 1.4. Or is this just something to look at in the furture and I still need to get the existing tools running with Axis2 1.4 in time for our next SCA release? Effort wise, which approach requires more? We need to make a good balance here. If the migration to 1.4 is an one-day work, then I think it's worth to migrate it 1st to have a working base. Its not just about getting the old tool working again though - the current tool code produces different wsdl than what the runtime does and it will get even more different as we switch to the new runtime wsdl generation code, and AFAICT we have nothing that uses the current tool, no doc on how to use it, and no testcases. Yes writing a new tool based on the new runtime wsdl generation code is more effort but isn't that inevertably going to happen so spending any more time on the old tool code a bit redundant? ...ant
Re: SCA Java builds are getting very large
On Wed, Apr 9, 2008 at 9:39 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Feb 16, 2008 at 11:48 PM, Simon Nash [EMAIL PROTECTED] wrote: It isn't long since I could do a complete checkout and build of Tuscany SCA Java in around 400 MB of disk space. Today I was amazed when I ran out of space despite having cleared over a gigabyte before starting. I tend to keep a few builds around for various reasons and the space factor is rapidly becoming more and more of an inhibitor to my development productivity. The full checkout and build that I did a week ago occupied 718 MB on disk. Today's version weighs in at a hefty 1020 MB. I've done some digging around, and there's nothing that seems very easy to eliminate. The biggest files are webapp samples and ActiveMQ logs. This size explosion adds more weight to the evidence that we need to split up the codebase into more modular chunks that can be built and tested independently. Simon To do a complete build of trunk now takes 1.5GB of disk space on my machine, thats for the trunk src build folder and the local maven repository. As part of the cleanup being talked about for the next release I'd like to try to reduce this a lot, i've raised TUSCANY-2212 to track this, if you've any ideas to help please feel free to add a comment/help. Having to start over on a new hard drive i can give a status update on this, a trunk build is down to 989MB on my machine. An improvement on the previous 1.5GB but still quite big. ...ant
Re: How do I get my Continuum build server account unlocked?
Mine too, id is ant. Trying to access the nightly builds also still fails with an authorisation error as well http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html. Is there something up with Continuum? ...ant On Fri, May 23, 2008 at 10:55 AM, Mark Combellack [EMAIL PROTECTED] wrote: Hi, I've just tried accessing the Continuum build server [1] and have discovered that my account is locked. How do I go about getting my account unlocked? Can anyone do this for me? My account id is mcombellack. Thanks, Mark [1] http://vmbuild.apache.org/continuum/
Fwd: Graduation
Forwarding for those not on tuscany-dev... Congratulations everyone and a very big thank you to our mentors and all the incubator folks for their help and guidance during the incubation, wouldn't have made it without you. ...ant -- Forwarded message -- From: Matthieu Riou [EMAIL PROTECTED] Date: Wed, May 21, 2008 at 10:14 PM Subject: Graduation To: tuscany-dev tuscany-dev@ws.apache.org Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present. Congratulations guys! Matthieu
