BPEL Implementation: Latest changes mean no need for deploy.xml !!
Folks, I've just deployed some changes to SVN for the BPEL implementation that remove the need to supply a deploy.xml file alongside your BPEL process script. So now, all you need is your BPEL process script, the related WSDL - and the composite file that defines the SCA component(s) - and you're done. Enjoy! Yours, Mike.
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
Very good news Mike !!! I hope to start working on the db issues as soon as I get some free cycles. On Tue, May 27, 2008 at 10:02 AM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > I've just deployed some changes to SVN for the BPEL implementation that > remove the need to supply a deploy.xml file alongside your BPEL process > script. > > So now, all you need is your BPEL process script, the related WSDL - and the > composite file that defines the SCA component(s) - and you're done. > > Enjoy! > > > Yours, Mike. > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: SCA 1.2.1 release
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 reasons, I think it will take about another 3 weeks to get the new generator code to the state that I would be happy to see it enabled in a release. Regarding TUSCANY-2304, from other emails I see that Ant has sent you a patched version of tuscany-sca-all-1.2-incubating.jar that contains the fix for your problem. Can you explain why you need a new release in addition to this patch? Simon
Re: SCA 1.2.1 release
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 reasons, I think it will take about another 3 weeks >>> to get the new generator code to the state that I would be happy >>> to see it enabled in a release. >>> >>> Regarding TUSCANY-2304, from other emails I see that Ant has sent >>> you a patched version of tuscany-sca-all-1.2-incubating.jar that >>> contains the fix for your problem. Can you explain why you need a >>> new release in addition to this patch? >>> >>> Simon >>> >>> >>> >> >> >> > +1 to Simon's comment. Any kind of "fix creep" over what is really required is going to make this more than a quick bug fix release. Simon
ODE integration and level of Geronimo-connector? was: Levels of Geronimo dependencies
Mike Edwards wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: The following files: sca/modules/core/pom.xml sca/modules/binding-jms/pom.xml sca/modules/policy-transaction/pom.xml sca/modules/binding-ejb/pom.xml sca/modules/implementation-bpel-ode/pom.xml sca/modules/host-webapp/pom.xml sca/modules/implementation-openjpa/pom.xml seem to require different levels of various geronimo JARs. How about making them agree on a single level: Geronimo 2.1? I've tried to change the references to Geronimo 2.1.1 and the corresponding spec JARs and got a successful build, so if there's no objection I'll commit that change in the next few days. +1 from me to get to a single level of Geronimo. I have no opinion as to which level of Geronimo is best. Yours, Mike. I spoke too fast, Geronimo JARs version 2.1.1 breaks implementation-bpel-ode with: testProcessInvocation(org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase) Time elapsed: 0.113 sec <<< ERROR! java.lang.NoSuchMethodError: org.apache.geronimo.connector.outbound.GenericConnectionManager.(Lorg/apache/geronimo/connector/outbound/connectionmanagerconfig/TransactionSupport;Lorg/apache/geronimo/connector/outbound/connectionmanagerconfig/PoolingSupport;ZLorg/apache/geronimo/connector/outbound/connectiontracking/ConnectionTracker;Ljavax/transaction/TransactionManager;Ljava/lang/String;Ljava/lang/ClassLoader;)V at org.apache.ode.il.dbutil.Database.initInternalDb(Database.java:187) at org.apache.ode.il.dbutil.Database.initEmbeddedDb(Database.java:225) at org.apache.ode.il.dbutil.Database.initDataSource(Database.java:144) at org.apache.ode.il.dbutil.Database.start(Database.java:96) at org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.initPersistence(EmbeddedODEServer.java:132) at org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.init(EmbeddedODEServer.java:99) at org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase.setUp(EmbeddedODEServerTestCase.java:58) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Results : Tests in error: testProcessInvocation(org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase) It works with geronimo-connector version 1.2-beta (from Dec 2006), but other versions of geronimo-connector give me that error. Is there a way to get ODE 1.1 or 1.1.1 working with a more recent level of geronimo-connector? -- Jean-Sebastien
Secure-bigbank demo, was Re: svn commit: r641708 - /incubator/tuscany/java/sca/demos/pom.xml
I tried to build the secure-bigbank demo and it worked ok for me. Any particular reason why this demo was removed from build ? On Wed, Mar 26, 2008 at 10:54 PM, <[EMAIL PROTECTED]> wrote: > Author: svkrish > Date: Wed Mar 26 22:54:44 2008 > New Revision: 641708 > > URL: http://svn.apache.org/viewvc?rev=641708&view=rev > Log: > removing secure-bigbank demo > > Modified: >incubator/tuscany/java/sca/demos/pom.xml > > Modified: incubator/tuscany/java/sca/demos/pom.xml > URL: > http://svn.apache.org/viewvc/incubator/tuscany/java/sca/demos/pom.xml?rev=641708&r1=641707&r2=641708&view=diff > == > --- incubator/tuscany/java/sca/demos/pom.xml (original) > +++ incubator/tuscany/java/sca/demos/pom.xml Wed Mar 26 22:54:44 2008 > @@ -43,7 +43,6 @@ > bigbank-stockquote > mortgage-creditcheck > mortgage-loanapproval > -secure-bigbank > xml-bigbank > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: svn commit: r659997 - in /incubator/tuscany/java/sca/modules: ./ host-ejb/ host-ejb/src/ host-ejb/src/main/ host-ejb/src/main/java/ host-ejb/src/main/java/org/ host-ejb/src/main/java/org/apache/ h
David Blevins wrote: This looks really cool. If you guys want any special features, definitely let us know. We've got a 3.0.1 coming down the pipe soon-ish. OK great, Thanks! I'm just starting to look into this, right now I'm able to register session beans implemented as POJOs, find them in JNDI using org.apache.openejb.core.ivm.naming.InitContextFactory and invoke them. I've not been able to get the same working with a remote JNDI factory (org.apache.openejb.client.RemoteInitialContextFactory) yet. I'm just guessing at this point but I'm probably missing something in the initialization of the EJB server [1] for that to work. Also at the moment I'm just registering a POJO that implements the Session bean business interface. Is there a way to register some kind of generic handler (like an Interceptor maybe?) to receive the invocation and any context that goes with it? I think I'll need that to dispatch incoming calls in a generic way to the Tuscany runtime to support non-POJO SCA components (BPEL, scripts etc). Looking at your StatelessInterceptorTest test case, registering OpenEJB interceptors looks easy but I'm not sure if it's the best way to implement that. Any thoughts? Don't know much of anything about the Tuscany architecture, but noticing you've got a module called host-http. We have some code in openejb-http that can support EJB invocations over HTTP which you may like. Might be nice if you don't want to have special ports open just for ejb, could do it all over the existing http setup. The basic idea is to help people integrate SCA components (POJOs, scripts, BPEL processes etc) and EJB session beans using SCA EJB bindings. SCA client components can already use EJB bindings to reference EJBs, like this: We've already implemented that client side support using the JDK ORB to invoke the EJB using the Corba DII, and it already works with OpenEJB. Now I'm trying to complete the picture and allow an SCA component to configure its services using EJB bindings, like this: allowing EJBs (running on the same OpenEJB server or even a different server) to reference and invoke the SCA component as if it was just another EJB. You just need a servlet like this one: https://svn.apache.org/repos/asf/openejb/tags/openejb-3.0/assembly/openejb-tomcat/openejb-tomcat-common/src/main/java/org/apache/openejb/tomcat/common/ServerServlet.java Been thinking to move that into the openejb-http module for a while, seems like a good reason to finally do it. That looks cool, I'll take a look, as you said it could be useful to avoid opening additional ports. I have two questions: - What would we need to do to support that HTTP based EJB invocation from our client/reference side EJB binding (which currently only supports CORBA) - What does that interoperate with? just OpenEJB or do other EJB containers support that to? -David [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-openejb/src/main/java/org/apache/tuscany/sca/host/openejb/OpenEJBServer.java -- Jean-Sebastien
Re: TransformationException when using java interface definition with generics
Don't know what changed in these three days, but, it is working now :)
++Vamsi
On Sat, May 24, 2008 at 4:49 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
wrote:
> Attached generics-problem.patch to recreate the problem.
>
> ++Vamsi
>
>
> On Sat, May 24, 2008 at 4:30 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
> wrote:
>
>>
>>
>> On Fri, May 23, 2008 at 11:53 PM, Raymond Feng <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Hi,
>>>
>>> It's not clear from the SCA spec how generics impacts the interface
>>> mapping. We need some clarifications there.
>>>
>>> The JAXWS 2.1 spec uses the erased type and only honor the type argument
>>> in Collection. At this moment, Tuscany supports the following case:
>>>
>>> @Remotable
>>> public interface MyHelloService extends HelloService {
>>> }
>>>
>>> And use MyHelloService as the service interface for HelloServiceImpl.
>>
>> Hmm... I tried this part and it does not seem to work.
>> SCADomain.newInstance() is throwing an exception. Stack trace given below:
>>
>> org.osoa.sca.ServiceRuntimeException:
>> org.osoa.sca.ServiceRuntimeException:
>> org.apache.tuscany.sca.core.assembly.ActivationException:
>> java.lang.NullPointerException
>> at
>> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
>> at
>> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
>> at
>> org.apache.tuscany.sca.itest.DatabindingTestCase.setUp(DatabindingTestCase.java:39)
>> at junit.framework.TestCase.runBare(TestCase.java:132)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:124)
>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
>> at junit.framework.TestSuite.run(TestSuite.java:227)
>> at
>> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>> 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: org.osoa.sca.ServiceRuntimeException:
>> org.apache.tuscany.sca.core.assembly.ActivationException:
>> java.lang.NullPointerException
>> at
>> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239)
>> at
>> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:113)
>> at
>> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
>> ... 16 more
>> Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
>> java.lang.NullPointerException
>> at
>> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986)
>> at
>> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237)
>> ... 18 more
>> Caused by: java.lang.NullPointerException
>> at
>> org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:212)
>> at
>> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:246)
>> at
>> org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:56)
>> at
>> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:66)
>> at
>> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:46)
>> at
>> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230)
>> at
>> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262)
>> at
>> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142)
>> at
>> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982)
>> ... 19 more
>>
>>
>>>
>>> I don't think it's wise to try to cover other variations before we get it
>>> clarified by the spec.
>>>
>>> Thanks,
>>> Raymond
>>> --
>>> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
>>> Sent: Friday, M
[jira] Resolved: (TUSCANY-2340) Databinding integration tests
[ https://issues.apache.org/jira/browse/TUSCANY-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-2340. --- Resolution: Fixed Patch applied under r660648. Thanks Vamsi for the patch! > Databinding integration tests > - > > Key: TUSCANY-2340 > URL: https://issues.apache.org/jira/browse/TUSCANY-2340 > Project: Tuscany > Issue Type: Test > Components: Java SCA Integration Tests >Reporter: Vamsavardhana Reddy >Assignee: Raymond Feng > Fix For: Java-SCA-Next > > Attachments: TUSCANY-2340-new.patch, TUSCANY-2340.patch > > > I have been trying out a few tests with databindings and am hitting some > TransformationExceptions. I thought it is better I post the tests I am > creating to the JIRA so that others can take a look at these tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (TUSCANY-2332) reconsider non-support for Holders
On Wed, May 21, 2008 at 7:19 PM, Scott Kurz (JIRA) < tuscany-dev@ws.apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Scott Kurz updated TUSCANY-2332: > > >Attachment: guessAndGreet.wsdl > > > reconsider non-support for Holders > > -- > > > > Key: TUSCANY-2332 > > URL: https://issues.apache.org/jira/browse/TUSCANY-2332 > > Project: Tuscany > > Issue Type: Improvement > > Components: Java SCA Data Binding Runtime > >Reporter: Scott Kurz > > Attachments: guessAndGreet.wsdl > > > > > > Though the Java annotations/API spec specifically says wrt WSDL-> Java > mapping: > > The JAX-WS mappings are applied with the following restrictions: > > • No support for holders > > I'd like to suggest that we look into enabling such support anyway, as > this seems overly restrictive and prevents us from supporting existing WSDLs > with inout data. > > At least I don't see how we'd map these WSDLs to Java and would think > we'd be way better off relying on the mapping defined by JAX-WS which does > use Holders. > > (Not sure what this statement in the spec was trying to accomplish.) > > I attached an example WSDL with two operations which we'd want to use > Holders in the corresponding Java methods. One has a common child element > of both input/output wrapper elem and the other has a common part of > input/output message. > > (Maybe it would be better to bring this up before opening a JIRA, but I > wanted to attach the WSDL.) > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > Hi Scott I have a couple of questions/comments related to this. I don't know why the spec specifically stated that we won't support this either but I can make a guess. On a philosophical note if you are in the business of writing coarse grained service interfaces with the intention of being protocol independent then relying on in/out or out parameters in you interface is unlikely to make your interfaces clear and easy to use. Like everything, as a purely technical challenge, I'm sure it could be made to work but IMHO it doesn't add clarity or achieve anything that can't be achieved with clearly delineated input parameters and a response value. As we only deal with doc/lit/wrapped WSDL currently Tuscany only expects one part per message and would always expect there to be a set of input parameters and a response. If this WSDL has come from some other existing system with the intention of representing in/out or out parameters then the SOAP engine on the service end will be marshalling from request parameters and to a responses so Tuscany would just take the WSDL at face value. As a slight aside, looking at the WSDL attached, I had to go and check in the WSDL spec what the hints are for in/out and out params. In WSDL 1.1 I found some words in section 2.4.6 which don't seem to chime with the approach you have taken. What rules are you following to indicate in/out and out parameters. Regards Simon
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
Luciano Resende wrote:
Very good news Mike !!! I hope to start working on the db issues as
soon as I get some free cycles.
Luciano,
There is something that you might be able to help me with right away.
I am running into intermittent problems with transactions in the registration of a BPEL process with
the ODE server. The transaction causing the problem seems to be the one in the
BPELImplementationProvider start() method.
What is this transaction for?
try {
txMgr.begin();
odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
component);
odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
txMgr.commit();
} catch (Exception e) {
e.printStackTrace();
txMgr.rollback();
}
Will it cause a problem if I remove this transaction? To me it does not seem to provide any value
when the Process is being supplied by Tuscany. I can't see any requirement for it in the ODE
documentation.
Yours, Mike.
[jira] Created: (TUSCANY-2343) OSGi bundle design leads to class loading issues
OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ODE integration and level of Geronimo-connector? was: Levels of Geronimo dependencies
On Tue, May 27, 2008 at 10:35 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Mike Edwards wrote: > >> Jean-Sebastien Delfino wrote: >> >>> Jean-Sebastien Delfino wrote: >>> The following files: sca/modules/core/pom.xml sca/modules/binding-jms/pom.xml sca/modules/policy-transaction/pom.xml sca/modules/binding-ejb/pom.xml sca/modules/implementation-bpel-ode/pom.xml sca/modules/host-webapp/pom.xml sca/modules/implementation-openjpa/pom.xml seem to require different levels of various geronimo JARs. How about making them agree on a single level: Geronimo 2.1? >>> >>> I've tried to change the references to Geronimo 2.1.1 and the >>> corresponding spec JARs and got a successful build, so if there's no >>> objection I'll commit that change in the next few days. >>> >>> +1 from me to get to a single level of Geronimo. >> >> I have no opinion as to which level of Geronimo is best. >> >> >> Yours, Mike. >> > > I spoke too fast, Geronimo JARs version 2.1.1 breaks > implementation-bpel-ode with: > > testProcessInvocation(org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase) > Time elapsed: 0.113 sec <<< ERROR! > java.lang.NoSuchMethodError: > org.apache.geronimo.connector.outbound.GenericConnectionManager.(Lorg/apache/geronimo/connector/outbound/connectionmanagerconfig/TransactionSupport;Lorg/apache/geronimo/connector/outbound/connectionmanagerconfig/PoolingSupport;ZLorg/apache/geronimo/connector/outbound/connectiontracking/ConnectionTracker;Ljavax/transaction/TransactionManager;Ljava/lang/String;Ljava/lang/ClassLoader;)V >at > org.apache.ode.il.dbutil.Database.initInternalDb(Database.java:187) >at > org.apache.ode.il.dbutil.Database.initEmbeddedDb(Database.java:225) >at > org.apache.ode.il.dbutil.Database.initDataSource(Database.java:144) >at org.apache.ode.il.dbutil.Database.start(Database.java:96) >at > org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.initPersistence(EmbeddedODEServer.java:132) >at > org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.init(EmbeddedODEServer.java:99) >at > org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase.setUp(EmbeddedODEServerTestCase.java:58) >at junit.framework.TestCase.runBare(TestCase.java:125) >at junit.framework.TestResult$1.protect(TestResult.java:106) >at junit.framework.TestResult.runProtected(TestResult.java:124) >at junit.framework.TestResult.run(TestResult.java:109) >at junit.framework.TestCase.run(TestCase.java:118) >at junit.framework.TestSuite.runTest(TestSuite.java:208) >at junit.framework.TestSuite.run(TestSuite.java:203) >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.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) >at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) >at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) >at org.apache.maven.surefire.Surefire.run(Surefire.java:132) >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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) >at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) > > > Results : > > Tests in error: > > > testProcessInvocation(org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase) > > > It works with geronimo-connector version 1.2-beta (from Dec 2006), but > other versions of geronimo-connector give me that error. > > Is there a way to get ODE 1.1 or 1.1.1 working with a more recent level of > geronimo-connector? > Depends which version of geronimo-transaction you want to use :) At the moment we're using 2.0.1 for geronimo kernel, transaction and connector and it works pretty well. Cheers, Matthieu > > -- > Jean-Sebastien >
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
The transaction is needed by the ProcessStore in order to persist the
process information.
I will research and see if there are any workarounds.
On Tue, May 27, 2008 at 2:21 PM, Mike Edwards
<[EMAIL PROTECTED]> wrote:
> Luciano Resende wrote:
>>
>> Very good news Mike !!! I hope to start working on the db issues as
>> soon as I get some free cycles.
>>
>
> Luciano,
>
> There is something that you might be able to help me with right away.
>
> I am running into intermittent problems with transactions in the
> registration of a BPEL process with the ODE server. The transaction causing
> the problem seems to be the one in the BPELImplementationProvider start()
> method.
>
> What is this transaction for?
>
> try {
>txMgr.begin();
>odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
> component);
>
>odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
>txMgr.commit();
> } catch (Exception e) {
>e.printStackTrace();
>txMgr.rollback();
> }
>
>
> Will it cause a problem if I remove this transaction? To me it does not
> seem to provide any value when the Process is being supplied by Tuscany. I
> can't see any requirement for it in the ODE documentation.
>
>
> Yours, Mike.
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
Actually the process runtime also needs a transaction when you deploy a
process. It persists some data structures needed to optimize message routing
and correlation extraction (basically which receives we can route to).
Cheers,
Matthieu
On Tue, May 27, 2008 at 4:08 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:
> The transaction is needed by the ProcessStore in order to persist the
> process information.
> I will research and see if there are any workarounds.
>
> On Tue, May 27, 2008 at 2:21 PM, Mike Edwards
> <[EMAIL PROTECTED]> wrote:
> > Luciano Resende wrote:
> >>
> >> Very good news Mike !!! I hope to start working on the db issues as
> >> soon as I get some free cycles.
> >>
> >
> > Luciano,
> >
> > There is something that you might be able to help me with right away.
> >
> > I am running into intermittent problems with transactions in the
> > registration of a BPEL process with the ODE server. The transaction
> causing
> > the problem seems to be the one in the BPELImplementationProvider start()
> > method.
> >
> > What is this transaction for?
> >
> > try {
> >txMgr.begin();
> >odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
> > component);
> >
> >odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
> >txMgr.commit();
> > } catch (Exception e) {
> >e.printStackTrace();
> >txMgr.rollback();
> > }
> >
> >
> > Will it cause a problem if I remove this transaction? To me it does not
> > seem to provide any value when the Process is being supplied by Tuscany.
> I
> > can't see any requirement for it in the ODE documentation.
> >
> >
> > Yours, Mike.
> >
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
[jira] Updated: (TUSCANY-2341) Tuscany plugin for Eclipse problem in OS X
[ https://issues.apache.org/jira/browse/TUSCANY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom McGee updated TUSCANY-2341: --- Comment: was deleted > Tuscany plugin for Eclipse problem in OS X > --- > > Key: TUSCANY-2341 > URL: https://issues.apache.org/jira/browse/TUSCANY-2341 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-SCA-1.2 > Environment: Mac OS X 10.5.2, Eclipse 3.3.2 >Reporter: Tom McGee > > With the Tuscany plugin installed into eclipse and a java project created > with the Tuscany library included in the build path the library does not show > up in the project. I used the default location when I installed the plugin. I > have not had this problem when working in windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ODE integration and level of Geronimo-connector? was: Levels of Geronimo dependencies
... Matthieu Riou wrote: Depends which version of geronimo-transaction you want to use :) At the moment we're using 2.0.1 for geronimo kernel, transaction and connector and it works pretty well. I'm getting the same exception with 2.0.1. Do you see any obvious problem with how we've listed the ODE and Geronimo dependencies in our pom.xml [1]? The fact that I'm seeing the same error with 2.0.1 leads me to believe that the problem is in that pom.xml, and some hope that once we get around it it will also work with 2.1.1 :) [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel-ode/pom.xml -- Jean-Sebastien
Re: svn commit: r659997 - in /incubator/tuscany/java/sca/modules: ./ host-ejb/ host-ejb/src/ host-ejb/src/main/ host-ejb/src/main/java/ host-ejb/src/main/java/org/ host-ejb/src/main/java/org/apache/ h
Jean-Sebastien Delfino wrote: David Blevins wrote: This looks really cool. If you guys want any special features, definitely let us know. We've got a 3.0.1 coming down the pipe soon-ish. OK great, Thanks! I'm just starting to look into this, right now I'm able to register session beans implemented as POJOs, find them in JNDI using org.apache.openejb.core.ivm.naming.InitContextFactory and invoke them. I've not been able to get the same working with a remote JNDI factory (org.apache.openejb.client.RemoteInitialContextFactory) yet. I'm just guessing at this point but I'm probably missing something in the initialization of the EJB server [1] for that to work. I've fixed that part in SVN r660759. Also at the moment I'm just registering a POJO that implements the Session bean business interface. Is there a way to register some kind of generic handler (like an Interceptor maybe?) to receive the invocation and any context that goes with it? I think I'll need that to dispatch incoming calls in a generic way to the Tuscany runtime to support non-POJO SCA components (BPEL, scripts etc). Looking at your StatelessInterceptorTest test case, registering OpenEJB interceptors looks easy but I'm not sure if it's the best way to implement that. Any thoughts? Don't know much of anything about the Tuscany architecture, but noticing you've got a module called host-http. We have some code in openejb-http that can support EJB invocations over HTTP which you may like. Might be nice if you don't want to have special ports open just for ejb, could do it all over the existing http setup. The basic idea is to help people integrate SCA components (POJOs, scripts, BPEL processes etc) and EJB session beans using SCA EJB bindings. SCA client components can already use EJB bindings to reference EJBs, like this: We've already implemented that client side support using the JDK ORB to invoke the EJB using the Corba DII, and it already works with OpenEJB. Now I'm trying to complete the picture and allow an SCA component to configure its services using EJB bindings, like this: allowing EJBs (running on the same OpenEJB server or even a different server) to reference and invoke the SCA component as if it was just another EJB. You just need a servlet like this one: https://svn.apache.org/repos/asf/openejb/tags/openejb-3.0/assembly/openejb-tomcat/openejb-tomcat-common/src/main/java/org/apache/openejb/tomcat/common/ServerServlet.java Been thinking to move that into the openejb-http module for a while, seems like a good reason to finally do it. That looks cool, I'll take a look, as you said it could be useful to avoid opening additional ports. I have two questions: - What would we need to do to support that HTTP based EJB invocation from our client/reference side EJB binding (which currently only supports CORBA) - What does that interoperate with? just OpenEJB or do other EJB containers support that to? -David [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-openejb/src/main/java/org/apache/tuscany/sca/host/openejb/OpenEJBServer.java -- Jean-Sebastien
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
Mike Edwards wrote:
Luciano Resende wrote:
Very good news Mike !!! I hope to start working on the db issues as
soon as I get some free cycles.
Luciano,
There is something that you might be able to help me with right away.
I am running into intermittent problems with transactions in the
registration of a BPEL process with the ODE server. The transaction
causing the problem seems to be the one in the
BPELImplementationProvider start() method.
What is this transaction for?
try {
txMgr.begin();
odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
component);
odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
txMgr.commit();
} catch (Exception e) {
e.printStackTrace();
txMgr.rollback();
}
Will it cause a problem if I remove this transaction? To me it does not
seem to provide any value when the Process is being supplied by
Tuscany. I can't see any requirement for it in the ODE documentation.
Yours, Mike.
Rebuiling from scratch gives me the error below. Anybody else seeing
this? Could it be related to the transaction problem discussed here?
Running helloworld.BPELHelloWorldTestCase
org.apache.tuscany.sca.implementation.bpel.ode.ODEDeploymentException:
>>> DEPLOY: Unexpected exception: Error reloading compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:285)
at
org.apache.tuscany.sca.implementation.bpel.provider.BPELImplementationProvider.start(BPELImplementationProvider.java:100)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:42)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.apache.ode.bpel.iapi.BpelEngineException: Error reloading
compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:689)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:654)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:666)
at
org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
at
org.apache.ode.bpel.engine.BpelProcess.hydrate(BpelProcess.java:547)
at
org.apache.ode.bpel.engine.BpelServerImpl.register(BpelServerImpl.java:277)
at
org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:280)
... 25 more
Caused by: java.lang.NullPointerException
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.ode.bpel.o.Serializer.read(Serializer.java:80)
at org.apache.ode.bpel.o.Serializer.(Serializer.java:73)
at
org.apache.ode.bpel.engine.BpelProcess.deserializeCompiledProcess(BpelProcess.java:417)
at
org.apache.ode.bpel.engine.BpelProcess.a
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
I just updated to latest trunk revision and I don't see this problem.
Could this be related to the geronimo level changes you mentioned in
another thread (do you have any local changes related to this )?
On Tue, May 27, 2008 at 7:12 PM, Jean-Sebastien Delfino
<[EMAIL PROTECTED]> wrote:
> Mike Edwards wrote:
>>
>> Luciano Resende wrote:
>>>
>>> Very good news Mike !!! I hope to start working on the db issues as
>>> soon as I get some free cycles.
>>>
>>
>> Luciano,
>>
>> There is something that you might be able to help me with right away.
>>
>> I am running into intermittent problems with transactions in the
>> registration of a BPEL process with the ODE server. The transaction causing
>> the problem seems to be the one in the BPELImplementationProvider start()
>> method.
>>
>> What is this transaction for?
>>
>> try {
>>txMgr.begin();
>>odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
>> component);
>>
>>odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
>>txMgr.commit();
>> } catch (Exception e) {
>>e.printStackTrace();
>>txMgr.rollback();
>> }
>>
>>
>> Will it cause a problem if I remove this transaction? To me it does not
>> seem to provide any value when the Process is being supplied by Tuscany. I
>> can't see any requirement for it in the ODE documentation.
>>
>>
>> Yours, Mike.
>>
>
> Rebuiling from scratch gives me the error below. Anybody else seeing this?
> Could it be related to the transaction problem discussed here?
>
> Running helloworld.BPELHelloWorldTestCase
> org.apache.tuscany.sca.implementation.bpel.ode.ODEDeploymentException: >>>
> DEPLOY: Unexpected exception: Error reloading compiled process
> {http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
> the file appears to be corrupted.
>at
> org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:285)
>at
> org.apache.tuscany.sca.implementation.bpel.provider.BPELImplementationProvider.start(BPELImplementationProvider.java:100)
>at
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631)
>at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245)
>at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:113)
>at
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
>at
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
>at
> helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:42)
>at junit.framework.TestCase.runBare(TestCase.java:125)
>at junit.framework.TestResult$1.protect(TestResult.java:106)
>at junit.framework.TestResult.runProtected(TestResult.java:124)
>at junit.framework.TestResult.run(TestResult.java:109)
>at junit.framework.TestCase.run(TestCase.java:118)
>at junit.framework.TestSuite.runTest(TestSuite.java:208)
>at junit.framework.TestSuite.run(TestSuite.java:203)
>at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
>at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> Caused by: org.apache.ode.bpel.iapi.BpelEngineException: Error reloading
> compiled process
> {http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
> the file appears to be corrupted.
>at
> org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:689)
>at
> org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:654)
>at
> org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:666)
>at org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
>at
> org.apache.ode.bpel.engine.BpelProcess.hydrate(BpelProcess.java:547)
>at
> org.apache.ode.bpel.engine.BpelServerImpl.register(BpelServerImpl.java:277)
>at
> org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(E
Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
Sebastien,
Which operating system are you running on?
The new code compiles the BPEL process to the CBP file and then reads it in. The error is with
reading in the file.
What I don't see below is an error from the new code saying that it is unable to load the file,
which is curious.
Yours, Mike.
Jean-Sebastien Delfino wrote:
Mike Edwards wrote:
Luciano Resende wrote:
Very good news Mike !!! I hope to start working on the db issues as
soon as I get some free cycles.
Luciano,
There is something that you might be able to help me with right away.
I am running into intermittent problems with transactions in the
registration of a BPEL process with the ODE server. The transaction
causing the problem seems to be the one in the
BPELImplementationProvider start() method.
What is this transaction for?
try {
txMgr.begin();
odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
component);
odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
txMgr.commit();
} catch (Exception e) {
e.printStackTrace();
txMgr.rollback();
}
Will it cause a problem if I remove this transaction? To me it does
not seem to provide any value when the Process is being supplied by
Tuscany. I can't see any requirement for it in the ODE documentation.
Yours, Mike.
Rebuiling from scratch gives me the error below. Anybody else seeing
this? Could it be related to the transaction problem discussed here?
Running helloworld.BPELHelloWorldTestCase
org.apache.tuscany.sca.implementation.bpel.ode.ODEDeploymentException:
>>> DEPLOY: Unexpected exception: Error reloading compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:285)
at
org.apache.tuscany.sca.implementation.bpel.provider.BPELImplementationProvider.start(BPELImplementationProvider.java:100)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:42)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.apache.ode.bpel.iapi.BpelEngineException: Error reloading
compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:689)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:654)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:666)
at
org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
at
org.apache.ode.bpel.engine.BpelProcess.hydrate(BpelProcess.java:547)
at
org.apache.ode.bpel.engine.BpelServerImpl.register(BpelServerImpl.java:277)
at
org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:280)
... 25 more
Caused by: java
Re: SCA 1.2.1 release
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 reasons, I think it will take about another 3 weeks > >>> to get the new generator code to the state that I would be happy > >>> to see it enabled in a release. > >>> > >>> Regarding TUSCANY-2304, from other emails I see that Ant has sent > >>> you a patched version of tuscany-sca-all-1.2-incubating.jar that > >>> contains the fix for your problem. Can you explain why you need a > >>> new release in addition to this patch? >
[jira] Assigned: (TUSCANY-2344) NPE from implementation.widget for missing location attribute
[ https://issues.apache.org/jira/browse/TUSCANY-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam reassigned TUSCANY-2344: Assignee: Ramkumar Ramalingam > NPE from implementation.widget for missing location attribute > - > > Key: TUSCANY-2344 > URL: https://issues.apache.org/jira/browse/TUSCANY-2344 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Misc Implementation Extensions >Affects Versions: Java-SCA-Next > Environment: Windows XP >Reporter: Ramkumar Ramalingam >Assignee: Ramkumar Ramalingam > Fix For: Java-SCA-Next > > > Caused by: java.lang.NullPointerException > at > org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationProvider.(WidgetImplementationProvider.java:45) > at > org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationProviderFactory.createImplementationProvider(WidgetImplementationProviderFactory.java:41) > at > org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationProviderFactory.createImplementationProvider(WidgetImplementationProviderFactory.java:1) > at > org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyImplementationProviderFactory.createImplementationProvider(DefaultProviderFactoryExtensionPoint.java:292) > at > org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addImplementationProvider(CompositeActivatorImpl.java:463) > at > org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:973) > ... 19 more > NPE is thrown for missing location attribute We need a fix to catch this > exception much before it reaches WidgetImplementationProvider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2344) NPE from implementation.widget for missing location attribute
NPE from implementation.widget for missing location attribute - Key: TUSCANY-2344 URL: https://issues.apache.org/jira/browse/TUSCANY-2344 Project: Tuscany Issue Type: Bug Components: Java SCA Misc Implementation Extensions Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Fix For: Java-SCA-Next Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationProvider.(WidgetImplementationProvider.java:45) at org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationProviderFactory.createImplementationProvider(WidgetImplementationProviderFactory.java:41) at org.apache.tuscany.sca.implementation.widget.provider.WidgetImplementationProviderFactory.createImplementationProvider(WidgetImplementationProviderFactory.java:1) at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyImplementationProviderFactory.createImplementationProvider(DefaultProviderFactoryExtensionPoint.java:292) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addImplementationProvider(CompositeActivatorImpl.java:463) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:973) ... 19 more NPE is thrown for missing location attribute We need a fix to catch this exception much before it reaches WidgetImplementationProvider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2345) NPE from implementation.resource for missing location attribute
NPE from implementation.resource for missing location attribute --- Key: TUSCANY-2345 URL: https://issues.apache.org/jira/browse/TUSCANY-2345 Project: Tuscany Issue Type: Bug Components: Java SCA Misc Implementation Extensions Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Fix For: Java-SCA-Next java.lang.NullPointerException at org.apache.tuscany.sca.implementation.resource.provider.ResourceImplementationProvider.createInvoker(ResourceImplementationProvider.java:49) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:315) 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:125) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:182) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:195) 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 $Proxy0.get(Unknown Source) NPE is thrown from ResourceImplementationProvider, when the composite is provided with missing location attribute. Need to catch this exception and throw a meaningful message for the user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
