Re: Build failure in helloworld-bpel sample
I guess that would be me as the fix I did outlined another issue (as
described in the thread Luciano pointed at). So you guys expect to always
have all the tests passing on trunk all the time?
Cheers,
Matthieu
On Thu, Jun 5, 2008 at 12:57 PM, Mike Edwards
[EMAIL PROTECTED] wrote:
Folks,
Someone has updated the code in SVN since this afternoon - so I am
investigating.
Yours, Mike.
Mike Edwards wrote:
Simon,
I did an SVN update and build of Tuscany earlier this afternoon and I did
not see this failure.
The code currently checked in to the Tuscany SVN was fixed up to avoid the
error listed by Luciano and certainly seems to work for me.
Is anyone else seeing the same problem that Simon is getting?
Yours, Mike.
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
Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org
}helloPartnerLink#hello
Creating invocation message:
args.: ?xml version=1.0 encoding=UTF-8?
hello xmlns=
http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdlmessageHello/message/hello
message..:?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello/message/hello/TestPart/message
Invocation status:RESPONSE
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec
FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 9.494 sec
ERRO
R!
junit.framework.ComparisonFailure: expected:Hello World but was:
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
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.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.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(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)
Results :
Tests in error:
testInvoke(helloworld.BPELHelloWorldTestCase)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]
Okay, this took a while because it was actually far trickier than I
expected. Here were the two problems (the first being the serious one):
* When OpenJPA first connects to the DB it initializes its sequence table
and does it using a different connection. It's fine when it's done in
isolation (like at startup) but with Derby, when a transaction that creates
stuff gets executed, it causes a lock timeout because the two connections
are competing to set a value. To fix this I've set a little parameters (all
that time for a single line fix...) that forces the initialization when we
start the engine.
* The HelloWorld process assignment was actually setting a variable that
wasn't structured properly when checking the message schema. I updated the
assignment.
So now we get the proper message in and out. I still have one last problem,
when the message gets back to Tuscany I get:
org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: local part cannot be null when
creating a QName
at
org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103)
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 $Proxy5.hello(Unknown Source)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)
The message looks fine to me, any idea what this could be? I've committed my
fixes so you should be able to reproduce it.
Cheers,
Matthieu
On Fri, May 30, 2008 at 11:39 PM, Matthieu Riou [EMAIL PROTECTED]
wrote:
I've started looking at the DbError issue and reproduced it. Digging deeper
it seems it's caused by a lock timeout in Derby on the
OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
deployed process. Here is an excerpt from the logs:
DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1http://tuscany.apache.org/implementation/bpel/example/helloworld%7DHelloWorld-1(guid=hqejbhcnphr3beiwcxrx88)
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT t0.ID, t0.GUID,
t0.PROCESS_ID, t0.PROCESS_TYPE, t0.VERSION FROM ODE_PROCESS t0 WHERE
(t0.PROCESS_ID = ?)
DEBUG - GeronimoLog.debug(66) | bound (1,{
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1http://tuscany.apache.org/implementation/bpel/example/helloworld%7DHelloWorld-1
)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
DEBUG - GeronimoLog.debug(66) | bound (1,0)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: INSERT INTO
OPENJPA_SEQUENCE_TABLE (ID, SEQUENCE_VALUE) VALUES (?, ?)
DEBUG - GeronimoLog.debug(66) | bound (2,1) (1,0)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
DEBUG - GeronimoLog.debug(66) | bound (1,0)
WARN - GeronimoLog.warn(96) | connectionErrorOccurred called with null
java.sql.SQLException: A lock could not be obtained within the time
requested
Right now I really have no clue why this is happening, there's no reason
why a lock would get stuck on the OpenJPA sequence table. I have to dig
deeper but it's getting late, I'll try to find more time during the week-end
or Monday.
Cheers,
Matthieu
On Fri, May 30, 2008 at 1:42 PM, Mike Edwards
[EMAIL PROTECTED] wrote:
Original Message
Subject: Re: SCA BPEL - Problems with ODE - Help requested
Date: Fri, 30 May 2008 17:51:12 +0100
From: Mike Edwards [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Matthieu Riou wrote:
On Thu, May 29, 2008 at 11:41 AM, Mike Edwards
[EMAIL PROTECTED] wrote:
Folks,
I've run into problems with the SCA BPEL implementation and the way it
interacts with the ODE engine - and I
Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]
On Thu, Jun 5, 2008 at 12:38 PM, Mike Edwards [EMAIL PROTECTED] wrote: Matthieu, First - many thanks for your hard work on this. I take no pleasure in saying this, but I am glad that the DB problem was ODE's problem rather than Tuscany's - it looks like you are far more experienced in handling that area of code! Regarding that remaining error, which is generated by Tuscany. I am assuming that this is the same error that I examined previously when using the TuscanyProcessConfImpl rather than the ODE ProcessConfImpl - namely that the returned data structure from ODE is simply different - and I believe it is in error - as the top level element is of a different type: - quoting from my previous email, in the case of using the TuscanyProcessConfImpl: Actually I think it's a different problem even if the symptom looks identical (as I mentioned, I fixed the process). First, it always break in the same way, whether the process is transient or not (which is reassuring). Second, the message looks good to me this time: Response: ?xml version=1.0 encoding=UTF-8? messageTestParthello xmlns= http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;messageHello World/message/hello/TestPart/message The namespaces of the hello and the message elements seem correct. Don't you think? Cheers, Matthieu When we switch to using the Tuscany ProcessConfImpl - with its transient setting, when we invoke the same process, we get back a different type of object - an ElementImpl named TestPart. This contains an ElementNSImpl object named hello containing a TextImpl child holding Hello World. This structural layout is clearly different to the previous case - and is wrong - it isn't what is expected. To explain futher, the direct cause of that exception you list is the fact that the top level element returned - the ElementImpl - does NOT have a namespace declared (I believe that it should be an ElementNSImpl) - and it is the lack of the NS that is at the root of the null exception that Tuscany returns. I note that this is NOT the same data structure that is returned by ODE when the ODE ProcessConfImpl is used - that data structure IS headed by a DeferredElementNSImpl (the deferred aspect isn't important, but the NS aspect very much is important). I could not determine why there was this difference in the data structure returned. I'll have another check using your fixed version of the code - but it would be useful if you could give me a clue about where in the ODE code this data element is being generated - it is very hard to trace. Yours, Mike. PS - I assume that I need to take a latest build from the ODE SVN to get your fixes for the DB problem? Matthieu Riou wrote: Okay, this took a while because it was actually far trickier than I expected. Here were the two problems (the first being the serious one): * When OpenJPA first connects to the DB it initializes its sequence table and does it using a different connection. It's fine when it's done in isolation (like at startup) but with Derby, when a transaction that creates stuff gets executed, it causes a lock timeout because the two connections are competing to set a value. To fix this I've set a little parameters (all that time for a single line fix...) that forces the initialization when we start the engine. * The HelloWorld process assignment was actually setting a variable that wasn't structured properly when checking the message schema. I updated the assignment. So now we get the proper message in and out. I still have one last problem, when the message gets back to Tuscany I get: org.apache.tuscany.sca.databinding.TransformationException: java.lang.IllegalArgumentException: local part cannot be null when creating a QName at org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) 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 $Proxy5.hello(Unknown Source) at helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56) The message looks fine to me, any idea what this could be? I've committed my fixes so you should
Re: SCA BPEL - Problems with ODE - Help requested
On Thu, May 29, 2008 at 11:41 AM, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I've run into problems with the SCA BPEL implementation and the way it interacts with the ODE engine - and I need help from some ODE experts, please. OK, the SCA code is using the ODE engine in an embedded mode - and the Tuscany code is trying to supply all the information and interfaces for each BPEL process to the ODE Engine - and in particular it aims to bypass the ODE database store so far as the BPEL process and its configuration are concerned. So - Tuscany now has its own version of the ProcessConfImpl (I sent a version of this out in a previous email). One thing I discovered is that it is necessary for the Tuscany ProcessConfImpl to return true to the isTransient() method. Otherwise, the ODE engine seems to try to find information about the process in the database with nasty consequences (failed transactions). Normally that shouldn't be a problem. Transient tells ODE to execute the process in memory but that only applies to short living processes, for most scenarios you'll want to have persistent executions. So we should try to see why these transactions fail. HOWEVER, this has a side effect that is both curious and problematic. Using the ODE ProcessConfImpl (and by implication the database store for the process itself), for a trivial Hello World BPEL process, when the hello operation is invoked on the BPEL process, the ODE engine returns the result message as a DeferredElementNSImpl class with the name TestPart - which on inspection contains a child element message containing the expected Hello World string. (I attach the relevant part of the WSDL at the bottom) When we switch to using the Tuscany ProcessConfImpl - with its transient setting, when we invoke the same process, we get back a different type of object - an ElementImpl named TestPart. This contains an ElementNSImpl object named hello containing a TextImpl child holding Hello World. This structural layout is clearly different to the previous case - and is wrong - it isn't what is expected. Can anyone explain the difference in the two cases? Any assistance gratefully received. I don't see what could create this difference. The deferred element vs. normal element is nothing to worry about, it's just that the structure has already been traversed in one case because of the storage different, but the content itself should be identical. Usually the switch from transient to persistent doesn't bring that kind of differences but there's nothing I can think of off the top of my head that could create this behavior. The structural difference kind of reminds the difference between rpc and document style part wrappers but that shouldn't show here. So I'd like to reproduce this and see what's going wrong. Is all your code committed? Which test case are you using? Thanks, Matthieu Is it perhaps due to differences in the compilation of the process? Or is the process treated in some very different way when it is transient? Yours, Mike Edwards. - Relevant WSDL sections: wsdl:types schema elementFormDefault=qualified targetNamespace= http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl; xmlns=http://www.w3.org/2001/XMLSchema; element name=hello complexType sequence element name=message type=xsd:string/ /sequence /complexType /element /schema /wsdl:types wsdl:message name=HelloMessage wsdl:part element=tns:hello name=TestPart/ /wsdl:message wsdl:portType name=HelloPortType wsdl:operation name=hello wsdl:input message=tns:HelloMessage name=TestIn/ wsdl:output message=tns:HelloMessage name=TestOut/ /wsdl:operation /wsdl:portType plnk:partnerLinkType name=HelloPartnerLinkType plnk:role name=me portType=tns:HelloPortType/ plnk:role name=you portType=tns:HelloPortType/ /plnk:partnerLinkType --- Relevant BPEL section: process name=HelloWorld targetNamespace= http://tuscany.apache.org/implementation/bpel/example/helloworld; xmlns:bpws=http://schemas.xmlsoap.org/ws/2004/03/business-process/; xmlns=http://schemas.xmlsoap.org/ws/2004/03/business-process/; xmlns:tns= http://tuscany.apache.org/implementation/bpel/example/helloworld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:test= http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl; queryLanguage=urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0 expressionLanguage=urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0 import location=helloworld.wsdl importType= http://schemas.xmlsoap.org/wsdl/; namespace=
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.init(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 !!
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://people.apache.org/%7Elresende
http://lresende.blogspot.com/
Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration
On Fri, May 23, 2008 at 9:03 AM, Mike Edwards [EMAIL PROTECTED] wrote: Matthieu Riou wrote: What mike says. I should just add that picking the right process version depending on what's already executing is handled by the runtime. The only thing that it will need is to know what is the definition for all the process versions that are still around (haven't been undeployed). You just need to keep these artifacts around and feed them to the engine (by calling register) as long as they're needed. If you want, I can code the method that compiles the BPEL file if you give me a signature that gets the file as parameter (I don't know how you would look it up in the filesystem). Cheers, Matthieu Yours optimistically, Mike. Matthieu, I'd appreciate it if you could pass your eyes over my implementation of a ProcessConf, inline below. There are a few questions that I have: 1) ProcessConfImpl from the ODE code has more public methods than are present in the ProcessConf interface. What are they used for - and by which code? Those are only used by the store implementation or by a test case for one of them. You don't need to worry about those as you won't have a store implementation. 2) What is getDefinitionforService(...) supposed to return? The problem is over the interpretation of the name Service - what kind of service is this? A service from the WSDL? A service as listed in the deploy.xml file? And what definition are we talking about - the definition of the Service in the WSDL file, or the definition of the portType at which the service points? It returns the WSDL object model associated with a given WSDL service qualified name. When something gets deployed, we scan all the WSDL documents and associate them with the services they define. This method is basically used by the engine to get the definition of the services that you defined in the deploy.xml. It can then pass this definition on to the integration layer when it wants a service to get activated. 3) What are Properties as returned by getProperties()? We have a set of custom name/value properties that can be defined in the deploy.xml that people can use to attribute some custom values to their process definitions. This is mostly used in the management API so that a graphical tool listing all process definitions could for example filter them by department. Those are somewhat different to what SCA properties for BPEL are, so I'm not sure what would be the best way to declare this in Tuscany. Perhaps some additional property elements in the componentType definition? In any case, it's not crucial for now. I'd appreciate any assistance you can give Looking through your code, it looks pretty good. We'll need better error reporting on the compilation but I've seen you already have a todo tag here so nothing to add. We'll also probably need versioning soon, it's a pretty common in BPEL when you incrementally deploy new processes but for a first implementation, we can definitely live with it. Looks pretty nice overall, thanks a lot for your work! Matthieu Yours, Mike. /* * 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. */ package org.apache.tuscany.sca.implementation.bpel.ode; import java.io.File; import java.io.InputStream; import java.io.FileInputStream; import java.io.IOException; import java.net.URI; import java.net.URL; import java.util.Date; import java.util.List; import java.util.Collection; import java.util.Map; import java.util.HashMap; import java.util.Arrays; import javax.wsdl.Definition; import javax.wsdl.PortType; import javax.xml.namespace.QName; import org.apache.ode.bpel.evt.BpelEvent.TYPE; import org.apache.ode.bpel.iapi.Endpoint; import org.apache.ode.bpel.iapi.ProcessConf; import org.apache.ode.bpel.iapi.ProcessState; import org.apache.ode.bpel.compiler.BpelC; import org.w3c.dom.Node; import org.apache.tuscany.sca.implementation.bpel.BPELImplementation; import org.apache.tuscany.sca.interfacedef.wsdl.WSDLDefinition; import org.apache.tuscany.sca.interfacedef.wsdl.WSDLInterface; import org.apache.tuscany.sca.assembly.Reference; import org.apache.tuscany.sca.assembly.Service; public class
Re: TLP migration
On Thu, May 22, 2008 at 3:55 AM, ant elder [EMAIL PROTECTED] wrote: Now that we have graduated we have some work to do to migrate to a TLP, the Incubator has information about this if anyone is interested in helping out, for example a good start is http://incubator.apache.org/guides/graduation.html#transfer Don't hesitate to let me know if you need a help, I can give you a hand. Matthieu 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. ...ant [1] http://apache.markmail.org/message/7caukr2i3uwg6w2c [2] http://apache.markmail.org/message/xit3tee7iqpfztx6
Graduation
Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present. Congratulations guys! Matthieu
Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration
On Tue, May 20, 2008 at 2:12 PM, Mike Edwards [EMAIL PROTECTED] wrote: Luciano Resende wrote: So, in the case where we replace the ODE Process Store module with one implemented by Tuscany, is this new module going to be responsible for handling all the versioning and matching a running process instance with the right BPEL process version ? Also, can the modules that handle deploy.xml and process store be implemented separately (e.g Tuscany would handle deploy.xml but still use ode process store module) ? Thanks Luciano Luciano, My reading of Matthieu's note is that what is necessary is simply that Tuscany must implement a ProcessConf class, rather than the whole process store. That can be prepared entirely from information which Tuscany has to hand, although as Matthieu points out, there are complex details within the ProcessConf implementation that will require us to re-use some ODE modules that compile the BPEL process file, but he says that doing that will not be too hard ;-) With Tuscany, the Process Store is not needed since Tuscany has the Domain configuration to drive things. What mike says. I should just add that picking the right process version depending on what's already executing is handled by the runtime. The only thing that it will need is to know what is the definition for all the process versions that are still around (haven't been undeployed). You just need to keep these artifacts around and feed them to the engine (by calling register) as long as they're needed. If you want, I can code the method that compiles the BPEL file if you give me a signature that gets the file as parameter (I don't know how you would look it up in the filesystem). Cheers, Matthieu Yours optimistically, Mike.
Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration
On Mon, May 19, 2008 at 9:11 AM, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I am interested in getting rid of the need to have a physical deploy.xml file in the directory with a BPEL process file. Can I supply the same information to the ODE runtime through some other means, such as method parameters or some in-memory mechanism? The short answer is: yes, you can. The long answer is... a bit longer :) For the SCA integration, the SCA runtime has all the information contained in the deploy.xml file, but in another form. It would be great to relieve the developers from the need to create this file. Let me explain a bit how that works. The ODE runtime doesn't know anything about the file system, descriptors or even BPEL files. It just knows that something is supposed to call it, passing an interface implementation (ProcessConf [1]) that provides everything it needs (and a bit more actually). It's so dumb that it doesn't even know which processes it should know about, so every time the server is restarted, it expects to be called again with the same process definition information. Parrallely in ODE we have a process store that handles all the nitty gritty details of knowing where is what in which version and remembering it. The process store doesn't know about the runtime and the runtime doesn't know about the store. The advantage is that, in theory, you could pick different clustering models (one store / multiple servers, multiple stores / multiple servers) depending on how you want things to be arranged. The other advantage is that you can get rid of the store altogether if you have all the necessary information. When a new process is deployed (or undeployed, or retired, or ...), the store just produces an event. Same thing when the whole server is restarted, the store produces several events for each process the runtime should know about. These events are just relayed by the Integration Layer that binds the store and the runtime and implements external communication (all the interfaces Luciano has implemented). Getting back to Tuscany, what I'm thinking is that we should remove the store (and its events) from the equation. Tuscany would just let the runtime know when when a process is available by calling BpelServer.register(ProcessConf), providing its own implementation of ProcessConf. The current Tuscany integration layer already has a reference to the BpelServer, so that's easy. The caveat is that in this case, Tuscany will also need to compile the .bpel file to provide the CBP (Compiled Business Process) but that's fairly painless (see DeploymentUnitDir.compile(File) [2]). The net advantage of this for Tuscany will be a much better integration and much more control over the process lifecycle. So let me know what you think and I can help with your ProcessConf implementation. Cheers, Matthieu [1] http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ProcessConf.java [2] http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/DeploymentUnitDir.java Yours, Mike Edwards Apache Tuscany team.
Re: SCA BPEL - ODE Database dependency
I think Alex didn't mean it's there already, just pointed out a way to add this :) We already have something similar in bpel-store [1]. You can configure OpenJPA to create the schema for you if it can't find it. So what you would do is basically: 1. Create a derby instance. 2. Point OpenJPA to it with the right option (just add it as a property in [2]). 3. Instantiate the store asking it to create its schema as well. 4. There's no 4. Given that Tuscany already has its own IL, you have all the freedom to do this when assembling the pieces. The only missing one is the property in 2. Cheers, Matthieu [1] http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/jpa/DbConfStoreConnectionFactory.java [2] http://svn.apache.org/repos/asf/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java On Tue, May 13, 2008 at 12:04 PM, Luciano Resende [EMAIL PROTECTED] wrote: Good to know we already have the code to create a new Derby dabase instance with a fresh Ode Schema. I guess I have missed this when creating the Tuscany Embedded Ode Server. Could you please point me to where this is available ? On Tue, May 13, 2008 at 11:56 AM, Alex Boisvert [EMAIL PROTECTED] wrote: Perhaps by defining a new database mode SAMPLE (we already have EMBEDDED, INTERNAL, EXTERNAL), that creates a new Derby database instance with a fresh Ode schema everytime the server is started? alex On Tue, May 13, 2008 at 11:50 AM, Luciano Resende [EMAIL PROTECTED] wrote: In Apache Tuscany, we have a embedded ODE Server that has a dependency on the ODE database (ode-dao-jpa-ojpa-derby-1.1.zip) that get's unzip by the build process when the app is run. I see two issues with this approach : The build infrastructure to unzip the db needs to be copied on every sample app and when running from an IDE, this code might not have been executed, and will require the application developer to go outside of the ide, to run some build command to create the db and make it available on the classpath. I was wondering if there is some kind of script that could be used to generate the db structure and any initial content. If so, I was thinking to integrate this script into the Embedded ODE Server initialization code, and create the proper db dependencies if not found. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
On Sat, May 10, 2008 at 12:17 AM, ant elder [EMAIL PROTECTED] wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 Matthieu +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged.
Re: What's next for SCA BPEL Integration
On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 8:53 AM, ant elder [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende [EMAIL PROTECTED] wrote: Now that we are making more progress with the SCA BPEL integration and have figured out how to make References to work, let's discuss what could be the next steps on this area. Below are couple examples of what we could do next - WS-BPEL Process Introspection : Currently we are requiring SCA componentType files, we could introspect the BPEL process file to generate the component type information from it. - Integrate BEPL with the store scenario tutorial : We could add a OrderProcessing step to the store checkout, and illustrate a more real integration scenario. Other then these, we could review the SCA_ClientAndImplementationModelFor BPEL and identify other areas that we might need enhancements. Scenarios / Samples / Demos are always welcome too. Or if you have other suggestions, feel free to jump to the discussion. BTW: Copying the ODE list in case they want to jump and help, or in case they have other ideas. Not a very exciting one but is there any clean up of the dependencies possible? Currently using the implementation.bpel extension brings in 78 addition dependency jars at about 20meg, i wondered if some of those could get excluded? ...ant Part of this is because we have a Embedded ODE BPEL engine, and that itself brings several dependencies. But this is certainly something to investigate. It would be also good if ODE could be more flexible/dynamic with some dependencies (e.g Saxon) and only really require these dependencies if they are going to be in use, this would help our side as well. Saxon is going to be hard to remove, there are very few BPEL processes that won't need any XPath expressions to execute so I'm not sure it's one we can save. But you're right for the embedded engine, right now we use our own stuff for everything ODE needs to execute: connection pool, transaction manager, jpa instance, thread pool, ... I'm guessing for many of these we could reuse what comes with Tuscany. Cheers, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: What's next for SCA BPEL Integration
On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende [EMAIL PROTECTED] wrote: Now that we are making more progress with the SCA BPEL integration and have figured out how to make References to work, let's discuss what could be the next steps on this area. Below are couple examples of what we could do next - WS-BPEL Process Introspection : Currently we are requiring SCA componentType files, we could introspect the BPEL process file to generate the component type information from it. - Integrate BEPL with the store scenario tutorial : We could add a OrderProcessing step to the store checkout, and illustrate a more real integration scenario. Other then these, we could review the SCA_ClientAndImplementationModelFor BPEL and identify other areas that we might need enhancements. Scenarios / Samples / Demos are always welcome too. Or if you have other suggestions, feel free to jump to the discussion. BTW: Copying the ODE list in case they want to jump and help, or in case they have other ideas. I was thinking about the deployment model as well. Right now you still need a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete port. In an SCA context I'm thinking this should be handled by the container. Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: Graduation next steps
I'm happy to see this discussion going and I think most of the points listed make a lot of sense. A small detail to add to the list that I think could have some importance: your -dev list is flooded by Jira issues. Newcomers interested in Tuscany's development are very likely to get overwhelmed by all the noise. I'd redirect that to -commits. Cheers, Matthieu On Feb 1, 2008 2:47 AM, Simon Laws [EMAIL PROTECTED] wrote: On Jan 31, 2008 1:41 PM, ant elder [EMAIL PROTECTED] wrote: I'd like to get some discussion going on what we want to do for graduating to an Apache TLP. The attempt back in November raised issues about diversity and since then it feels like we've just been waiting around hoping diversity would improve. We were unlikely then and we are almost there, would it help to have a target to aim for so we can be a bit more proactive? How about trying again at the April or May board meeting which would give us a two or three full months from now? Having a few months would give us some time to work on turning some of the contributors we already have into committers and to get other committers added to the PPMC, but a few months is also near enough to keep us focused. If we're seen to be working on this it may also encourage some of the contributors we have to be more active and so easier to make committers. There's a lot i think the project could do to encourage others to participate, here's a few things I can think of - We have a lot of downloads and real users, we need to try to get more of these people engaged and contributing, things that may help are: - better documentation, whats there is a bit sparse and our website has started to fall behind and there's quite a few extensions with no or out dated documentation - more publicity about what each new Tuscany release can do, we have lots of new stuff in 1.1 but the only place we say that is in the release notes. The Tuscany blog is a little neglected these days - post to user list as each bit of new function is completed to try to engage users and to show them their comments can make a real difference to what gets in the next release - more timely action on JIRAs, we're getting quite a back log, if we're quick to look at JIRAs it might encourage users to help debug and provide patches Once a user does start contributing I think there are things we could do better on the the dev list to make it easier and to encourage participation: - just generally improve the ML traffic which is at an all time low, if we the active developers don't discuss much then new contributors likely wont either - one reason ML traffic could be down is that discussion is going on off-list instead, is there? Is it really necessary? Lets make a real effort to keep all discussion on the dev list. - more timely replies in discussions. if someone replies to a thread often it ends up with people waiting for a follow-up reply, if that follow-up takes ages to come the discussion can stall and people loose interest and move on to something else. - we may need to provide more active help to contributors when they make suggestions, not just ask if they'd implement it but at least provide lots of detail about how they could do it or even step up and help code even if we may not think its the most useful thing What do others think, would any of those things help? Any other suggestions that could help improve our diversity? Does aiming for the April board meet sound ok or too soon or too far? ...ant I think all of the things you suggest are excellent ideas and that we should do better in all of these areas regardless of our aspirations to graduate from the incubator. I wouldn't like to think we put effort in now and then sit back as soon as we do graduate. I'm in two minds about whether having a target for graduation is appropriate. I would like to suggest that we give ourselves a target for improving our diversity by addressing all of the good points you make and undertake to report/discuss our progress with the IPMC at some interval (monthly) to see if a new graduation proposal is appropriate. However I'll have to take you advice as to whether posting to general@, reporting what progress we have made and soliciting feedback will provide a response or whether we actually have to start a [VOTE] to get peoples attention. Motivated by your points some specific thoughts that come to mind... JIRA Handling The JIRA backlog is a real problem and I, for one, have been very poor at addressing this. We want to be in a position where incoming JIRA are classified, assigned and turned round as quickly as possible. So two problems to solve. 1. The backlog - Can we set up an IRC chat session(s) to walk through the 170 or so outstanding JIRA to decide what to do about them ASAP. 2. The process going forward Sort out
Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a)
Looks good to me, thanks for correcting the problems mentioned by Sebastian. +1 Matthieu On Jan 28, 2008 9:31 AM, Simon Laws [EMAIL PROTECTED] wrote: Hi, The previous VOTE thread here for SCA Java 1.1-incubating identified some issues. http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html A new release candidate (RC3a) has been created addressing the issues as discussed in the previous thread. I'm starting this IPMC VOTE thread in parallel with the project vote thread as the material content of the release hasn't changed significantly and I don't want to delay before getting IPMC eyeballs on it. The ongoing thread in the Tuscany community can be found here http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27401.html The release includes a set of bug-fixes and new function such as the implementation of binding.jms. You can see a list of changes at: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/distribution/src/main/release/CHANGES The signed binary and source distributions, the RAT reports, and the Maven staging repository are listed at the following links. SVN Tag: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/ Stage maven repo: http://people.apache.org/~slaws/tuscany/1.1-RC3a/maven/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/maven/ http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/maven/ RAT report: http://people.apache.org/~slaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txthttp://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt Binary and source distros (zip/gz/asc/md5) : http://people.apache.org/~slaws/tuscany/1.1-RC3a/http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/ http://people.apache.org/%7Eslaws/tuscany/1.1-RC3a/ Please review and approve the release. This vote will remain open for at least 72 hours. Thank you for your attention, Simon
Re: [VOTE] Graduate Tuscany as a top level project
On 10/9/07, ant elder [EMAIL PROTECTED] wrote: Looks like we've closed all the discussions around this so we can now vote on it. We've an Incubator discussion thread on our graduation but I don't see why we can't let that run in parallel, so ... Please vote on graduating Tuscany as a top level project and the proposal below. +1
Re: Graduation Checklist, was: Graduation
On 10/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: How about we put a check list up on the wiki so we all get a view of what's going on and what needs to be done by when. I've started one here by copying the checklist from the graduation guide ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Graduation+Checklist ) but we need to work out what we need to do specifically for Tuscany and, of course by, when. Simon I looked at the Tuscany Graduation Checklist Wiki page and it looks like we're making good progress. I have a few comments. Bullet #1 points to http://incubator.apache.org/projects/tuscany.html, 2 new committers are missing on that page. Brady Johnson Simon Nash Bullet #3 - Are there three or more independent committers? says The project committers are drawn from 6 independent organizations. Status says Needs Checking. I count 8 independent organizations, more than the requirement of 3. Can we mark it Done or clarify what else needs checking? Bullet #9 - Ensure that mentors and IPMC have no remaining issues. Let's start with our mentors, could our mentors please list any remaining issues? I personally have no remaining issues. My main concerns were related to the specs IP and diversity and both have either been addressed or are currently being addressed. You should send an e-mail to [EMAIL PROTECTED] mentioning that you're on the track to graduation and ask if other IPMCers have pending issues. I'd expect a few questions but probably nothing you can't answer properly. Cheers, Matthieu Row #11 - A draft resolution is available at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution After discussing the draft on the mailing list, people seem to be OK with this text: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24387.html Row #13 - Openness of specification process. Looks like there is consensus in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24282.html. I think we can mark this one Done. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
On 9/27/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/27/07, ant elder [EMAIL PROTECTED] wrote: On 9/27/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, Simon Laws wrote: On 9/27/07, ant elder [EMAIL PROTECTED] wrote: On 9/27/07, Matthieu Riou [EMAIL PROTECTED] wrote: snip So you have 4 more days after Sunday :) But there's no reason to rush out, I'm just clarifying the timeline, you'll be ready when you'll be ready and you can also target Nov. 21st. The November time frame sounds good to me and gives plenty of time to sort out things and bring it up with the IPMC so we know if they've any issues we need to address before calling a vote. I think that November is allowing things to slide too much. Are there any reasons that will DEFINITELY prevent achieving October? Otherwise October is my vote. ...ant But there is nothing stopping us pushing ahead now. If we happened to be ready for October we should try for October. +1 from me. Leaving a slacker schedule typically does not help. Set the challenging schedule and focus on the big items to get us there. Go for October. Two of things i think we should do are: - the PPMC doesn't yet reflect the diversity of the committers. We've all been a bit busy with 1.0 etc and there's a few people now who we could look at as PPMC members, Matthieu brought this up earlier on the thread. Doing this now may help prevent any questions about diversity. +1 - the openness of the specs and our interaction with OSOA has been brought up before by the Incubator. Most things have now moved to OASIS and that should resolve those issues but stuff still happens at OSOA. We need to come up with an approach to dealing with that, and i think it would be good to do this now before trying to graduate. You refer to at least [1]. Separating some of the issues I think are involved. 1 - OASIS doesn't meet the openness of participation required set out in mail [1]. I believe the issue is that while all stages of spec development are open to anyone to see you have to pay to contribute. This is not a Tuscany specific issue. 2 - Do the IPR terms chosen by the SCA TCs in OASIS make upcoming OSASIS specifications suitable for implementation by Tuscany when they appear? I guess we need to get the view from legal@ on this. Are these public yet? 3 - Do the license associated with the OSOA v1.0 specs, that we currently implement, cause concern? legal@ again. 4 - Some V1.0 specs haven't moved to OASIS, e.g. EJB binding, so we either stick with OSOA V1.0, assuming that the licenses are acceptable, or remove the binding (I'm assuming here that this is what binding-ejb is) 5 - On ongoing OSOA work. Assuming that there is ongoing work and that the mode of operation is unchanged, maybe we wait until it reaches OASIS. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200607.mbox/[EMAIL PROTECTED]
Re: Graduation
On 9/26/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Matthieu Riou wrote: Guys, I'm definitely +1 for both graduation and ant as the chair. For the tasks, as ant mentioned the graduation guide [1] is definitely a good read. A few additional details: * In your resolution, one of the most important parts is the description. Don't be too broad, you can eventually expand the scope later on if necessary (simple request/ack to the board). Right now the wording is good but a bit too fuzzy I think. It's also good to add a statement about how the project can interact or play with other projects. * The other important parts of the resolution are the chair and the PMC list. Look like you're pretty much set on that side. You can choose to extend the PMC too, and add committers that aren't in the PPMC yet but would deserve to. * Make sure that your project status page is up-to-date [2] Once you're set, you can start a formal vote on the board resolution in the community. Then you'll ask for the incubator vote. You'll also have to take the board schedule into account. Usually meetings are the third Wednesday of each month so it's too late for this month but you could be in good shape for October (should be the 17th). Cheers! Matthieu [1] http://incubator.apache.org/guides/graduation .html [2] http://incubator.apache.org/projects/tuscany.html I just looked at the calendar at [3] and I'm not sure what people are planning on Sunday but according to this calendar we should start a vote on the resolution this Sunday to be in a good shape for the 17th :) Yeah, the calendar shows more the expected duration of each steps but as a timeline it's a bit confusing. The tasks can be parallelized and it's also possible to do stuff on Thursdays and Fridays :) The hard constraints are the following: * the board meeting is the 17th * the resolution must be submitted at least 72 hours before (the deadline is usually Monday) which would be the 15th. * the IPMC must have voted the board resolution before, another 72 hours, usually the week-ends don't count so that would be the 9th * finally the community vote is one more 72 hours which would get you to the 4th. So you have 4 more days after Sunday :) But there's no reason to rush out, I'm just clarifying the timeline, you'll be ready when you'll be ready and you can also target Nov. 21st. As you said it's better if the resolution is not too fuzzy, I'll try to propose small changes to crisp it up a bit (just saw that Haleh just proposed some changes to it too in this thread). What else can I can help with? I think that's pretty much it. Compared to everything that comes before, graduation is a pretty straightforward process (even if it takes time). Matthieu [3] http://incubator.apache.org/guides/graduation.html#process -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
On 9/24/07, Luciano Resende [EMAIL PROTECTED] wrote: I have reviewed and updated our STATUS file [1] and Status page (that should be refreshed soon) [2] with latest and missing news. Please let me know if I missed something :) Looks good, it's great that you revived this thread! Any other task from the Graduation checklist [4] that I could help ? You could maybe start a separate thread to discuss the resolution draft? Is everybody happy with the description? Also it's a detail but the common practice is usually to list people Apache e-mail address (@apache.org) for the PMC as it gives the apache id. You have a nice collection of gmail addresses though ;) Matthieu [1] https://svn.apache.org/repos/asf/incubator/tuscany/STATUS [2] http://incubator.apache.org/projects/tuscany.html [3] http://incubator.apache.org/guides/graduation.html [4] http://incubator.apache.org/guides/graduation#checklist On 9/13/07, Matthieu Riou [EMAIL PROTECTED] wrote: Guys, I'm definitely +1 for both graduation and ant as the chair. For the tasks, as ant mentioned the graduation guide [1] is definitely a good read. A few additional details: * In your resolution, one of the most important parts is the description. Don't be too broad, you can eventually expand the scope later on if necessary (simple request/ack to the board). Right now the wording is good but a bit too fuzzy I think. It's also good to add a statement about how the project can interact or play with other projects. * The other important parts of the resolution are the chair and the PMC list. Look like you're pretty much set on that side. You can choose to extend the PMC too, and add committers that aren't in the PPMC yet but would deserve to. * Make sure that your project status page is up-to-date [2] Once you're set, you can start a formal vote on the board resolution in the community. Then you'll ask for the incubator vote. You'll also have to take the board schedule into account. Usually meetings are the third Wednesday of each month so it's too late for this month but you could be in good shape for October (should be the 17th). Cheers! Matthieu [1] http://incubator.apache.org/guides/graduation .html [2] http://incubator.apache.org/projects/tuscany.html On 9/12/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, +1. +1. Can we start to identify work tasks to get us there and then start to parcel out work amongst folk on the project? Yours, Mike. ant elder wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution , we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html . ..ant - 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java DAS beta2
There are a couple of copyright notices that you should add in your NOTICE file, mostly derby, stax and woodstox (as described in [1]). Also JSTL is listed in your LICENSE file although I don't think it's part of the release (at least not in the binary package). Everything else looks fine to me as well. Nothing critical for this release though, so here's my +1. Matthieu [1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-notice On 9/21/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta2 distribution of Tuscany DAS for Java. The Release Candidate for Tuscany Java DAS beta2 is available at http://people.apache.org/~lresende/tuscany/das-beta2-rc1/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta2-rc1/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta2-rc1/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta2-rc1/das-beta2-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta2-rc1/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 1.0 RC3a
Everything looks good but it seems that a few copyright notices are missing in the NOTICE file. Is it generated by Maven? I could spot at least XmlBeans, Xalan, Xerces and Derby. As that's the only problem I can find, I think you can just patch the release archives without the necessity of restarting the vote if you want. Cheers, Matthieu On 9/20/07, kelvin goodson [EMAIL PROTECTED] wrote: +1 Kelvin. On 19/09/2007, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the 1.0 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-RC3a/ The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.0-RC3a/ http://people.apache.org/%7Eantelder/tuscany/1.0-RC3a/ This includes the signed binary and source distributions, the RAT reports, and the Maven staging repository. Many thanks, ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 1.0 RC3a
On 9/20/07, Matthieu Riou [EMAIL PROTECTED] wrote: Everything looks good but it seems that a few copyright notices are missing in the NOTICE file. Is it generated by Maven? I could spot at least XmlBeans, Xalan, Xerces and Derby. Replying to myself :) Actually I don't see a reason this should delay the release at hand as it looks pretty good. You should just make sure that this issue is properly addressed before the next release but I don't think this is a real problem for now. So here is my +1. As that's the only problem I can find, I think you can just patch the release archives without the necessity of restarting the vote if you want. Cheers, Matthieu On 9/20/07, kelvin goodson [EMAIL PROTECTED] wrote: +1 Kelvin. On 19/09/2007, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the 1.0 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-RC3a/ The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.0-RC3a/http://people.apache.org/%7Eantelder/tuscany/1.0-RC3a/ http://people.apache.org/%7Eantelder/tuscany/1.0-RC3a/ This includes the signed binary and source distributions, the RAT reports, and the Maven staging repository. Many thanks, ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA WS-BPEL - Initial support available
Super! Thanks Luciano! Matthieu On 9/15/07, Luciano Resende [EMAIL PROTECTED] wrote: This is a quick note to let the community know that I managed to get initial WS-BPEL component implementation ready just in time for our SCA 1.0 release. As described in [1] and [2], we can now invoke executables WS-BPEL process from an SCA runtime. As for a WS-BPEL engine, we are using Apache ODE [3][4].The current implementation.bpel is available in trunk at [5] and you can see a simple helloWorld BPEL process being invoked. I'm working on a new sample to better demonstrate the usage of this new component type, I'll also look into references as well. I'd also like to Thank all the help from the ODE community, especially Matthieu Riou. [1] http://osoa.org/display/Main/SCA+BPEL+White+Paper [2] http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1 [3] http://ode.apache.org [4] http://www.infoq.com/articles/paul-brown-ode [5] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementation-bpel dependencies
On 9/15/07, ant elder [EMAIL PROTECTED] wrote: The implementation-bpel brings in nearly 30Meg of new dependency jars, i'm guessing a lot of these aren't really necessary and we could exclude them, but the list is so long it will take a while to work out, could any of the bpel/Ode experts say which they think are essential? Looks like Maven is doing its magic. Although there seems to be quite a few duplicates in the list. The complete list of jars brought in by implementation-bpel is: I'm adding a '-' in front of the dependencies that aren't needed and a 'd' when I find a duplicate. I've left the tuscany ones but you'll probably want to declare them as provided. Ultimately many more could be declared as provided if they're already bundled in tuscany (like the geronimo transaction manager and the tranql connection pool). activation-1.1.jar - activeio-2.0-r118.jar - ant-1.6.2.jar - avalon-framework-4.1.3.jar axion-1.0-M3-dev.jar backport-util-concurrent-2.2.jar - classworlds-1.1-alpha-2.jar - common-2.2.3.jar commons-codec-1.2.jar commons-collections-3.1.jar - commons-jexl-1.1.jar commons-lang-2.1.jar commons-pool-1.3.jar commons-primitives-1.0.jar derby-10.1.3.1.jar - dom4j-1.6.1.jar - ecore-2.2.3.jar - ecore-change-2.2.3.jar - ecore-xmi-2.2.3.jar - geronimo-common-1.2-beta.jar geronimo-connector-1.2-beta.jar - geronimo-core-1.2-beta.jar - geronimo-deployment-1.2-beta.jar geronimo-ejb_2.1_spec-1.1.jar - geronimo-interceptor-1.2-beta.jar - geronimo-j2ee-1.2-beta.jar geronimo-j2ee-connector_1.5_spec-1.1.jar - geronimo-j2ee-jacc_1.0_spec-1.1.jar - geronimo-j2ee-management_1.0_spec-1.1.jar - geronimo-jms_1.1_spec-1.0.1.jar geronimo-jpa_3.0_spec-1.0.jar - geronimo-jta_1.0.1B_spec-1.0.jar geronimo-kernel-1.2-beta.jar - geronimo-management-1.2-beta.jar - geronimo-naming-1.2-beta.jar - geronimo-security-1.2-beta.jar geronimo-spec-j2ee-connector-1.5-rc4.jar geronimo-spec-jta-1.0.1B-rc4.jar - geronimo-system-1.2-beta.jar geronimo-transaction-1.2-beta.jar - geronimo-util-1.2-beta.jar - howl-1.0.1-1.jar - hsqldb-1.8.0.1.jar icu4j-2.6.1.jar - javacc-3.2.jar jaxen-1.1-beta-8.jar - jdom-1.0.jar log4j-1.2.12.jar - logkit-1.0.1.jar - mail-1.4.jar - maven-artifact-2.0.2.jar - maven-artifact-ant-2.0.4.jar - maven-artifact-manager-2.0.2.jar - maven-error-diagnostics-2.0.2.jar - maven-model-2.0.2.jar - maven-profile-2.0.2.jar - maven-project-2.0.2.jar - maven-repository-metadata-2.0.2.jar - maven-settings-2.0.2.jar - mx4j-3.0.1.jar d geronimo-connector-1.2-beta.jar d geronimo-core-1.2-beta.jar d geronimo-deployment-1.2-beta.jar d geronimo-ejb_2.1_spec-1.1.jar d geronimo-interceptor-1.2-beta.jar d geronimo-j2ee-1.2-beta.jar d geronimo-j2ee-connector_1.5_spec-1.1.jar d geronimo-j2ee-jacc_1.0_spec-1.1.jar d geronimo-j2ee-management_1.0_spec-1.1.jar d geronimo-jms_1.1_spec-1.0.1.jar d geronimo-jpa_3.0_spec-1.0.jar d geronimo-jta_1.0.1B_spec-1.0.jar d geronimo-kernel-1.2-beta.jar d geronimo-management-1.2-beta.jar d geronimo-naming-1.2-beta.jar d geronimo-security-1.2-beta.jar d geronimo-spec-j2ee-connector-1.5-rc4.jar d geronimo-spec-jta-1.0.1B-rc4.jar d geronimo-system-1.2-beta.jar d geronimo-transaction-1.2-beta.jar d geronimo-util-1.2-beta.jar d howl-1.0.1-1.jar d hsqldb-1.8.0.1.jar d icu4j-2.6.1.jar d javacc-3.2.jar d jdom-1.0.jar d log4j-1.2.12.jar d logkit-1.0.1.jar d mail-1.4.jar d maven-artifact-2.0.2.jar d maven-artifact-ant-2.0.4.jar d maven-artifact-manager-2.0.2.jar d maven-error-diagnostics-2.0.2.jar d maven-model-2.0.2.jar d maven-profile-2.0.2.jar d maven-project-2.0.2.jar d maven-repository-metadata-2.0.2.jar d maven-settings-2.0.2.jar d mx4j-3.0.1.jar ode-bpel-api-1.1.jar ode-bpel-compiler-1.1.jar ode-bpel-dao-1.1.jar ode-bpel-epr-1.1.jar ode-bpel-obj-1.1.jar ode-bpel-runtime-1.1.jar ode-bpel-schemas-1.1.jar ode-bpel-store-1.1.jar ode-dao-jpa-1.1.jar ode-jacob-1.1.jar ode-jacob-ap-1.1.jar ode-scheduler-simple-1.1.jar ode-utils-1.1.jar - ognl-2.6.9.jar openjpa-all-0.9.7-incubating.jar - openjpa-jdbc-0.9.7-incubating.jar - openjpa-jdbc-5-0.9.7-incubating.jar - openjpa-kernel-0.9.7-incubating.jar - openjpa-kernel-5-0.9.7-incubating.jar - openjpa-lib-0.9.7-incubating.jar - openjpa-persistence-0.9.7-incubating.jar - openjpa-persistence-jdbc-0.9.7-incubating.jar - openjpa-xmlstore-0.9.7-incubating.jar - plexus-container-default-1.0-alpha-9.jar - plexus-utils-1.1.jar - quartz-1.5.2.jar regexp-1.3.jar saxon-8.7.jar saxon-dom-8.7.jar saxon-xpath-8.7.jar serp-1.12.0.jar - servlet-api-2.3.jar - tagsoup-0.9.7.jar tranql-connector-1.1.jar tuscany-databinding-axiom-1.0-incubating.jar tuscany-implementation-bpel-1.0-incubating.jar tuscany-interface-wsdl-1.0-incubating.jar tuscany-interface-wsdl-xml-1.0-incubating.jar tuscany-sdo-api-r2.1-1.0-incubating.jar tuscany-sdo-impl-1.0-incubating.jar tuscany-sdo-lib-1.0-incubating.jar - wagon-file-1.0-alpha-7.jar -
Re: Tuscany mentor changes
On 9/11/07, ant elder [EMAIL PROTECTED] wrote: An update on some changes to the Tuscany incubation mentors: - Dims has stepped down as mentor. Many many thanks for all the help and guidance during our incubation, its been invaluable. - Paul Fremantle and Matthieu Riou have signed up as new mentors joining Sam so we now have three. Thanks guys and welcome aboard. ...ant Sorry for the late reply, I was a bit swamped. Thanks a lot for the welcome and I hope we can all work to make from Tuscany a successful graduation soon! Cheers, Matthieu
Re: BPEL implementation: WSDL and BPEL resolving
Hi Raymond, Sorry for the late reply, your e-mail passed through my filters :) The approach described in the document sounds good to me, it's similar to what we're doing for import resolution within an ODE deployment package. So that should work. The only part I'm not so clear about though is when the resolution occurs, is it when the contribution is loaded? And thanks for the congrats! Matthieu On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Matthieu. Congratulations on the ODE graduation! We have made some processes in Tuscany regarding to the artifact resolving. Please see more details at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts . I think the strategy will apply to BPEL as well. Would you please take a look? Hopefully, we can get the implementation.bpel working soon. Thanks, Raymond - Original Message - From: Matthieu Riou [EMAIL PROTECTED] To: Luciano Resende [EMAIL PROTECTED] Cc: tuscany-dev@ws.apache.org Sent: Thursday, July 05, 2007 5:08 PM Subject: Re: BPEL implementation: WSDL and BPEL resolving Sure, no problem. And thanks :-) On 7/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Matthieu I'm little overbooked these days, but let me see if I could try to look into the resolution thing over the weekend. Is that OK ? On 7/5/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
BPEL implementation: WSDL and BPEL resolving
Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu
[jira] Updated: (TUSCANY-1413) WSDL and BPEL resolving
[ https://issues.apache.org/jira/browse/TUSCANY-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1413: --- Attachment: patch.txt WSDL and BPEL resolving --- Key: TUSCANY-1413 URL: https://issues.apache.org/jira/browse/TUSCANY-1413 Project: Tuscany Issue Type: Improvement Components: Java SCA BEPL Implementation Extension Reporter: Matthieu Riou Priority: Minor Attachments: patch.txt, patch.zip I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. This patch adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1413) WSDL and BPEL resolving
WSDL and BPEL resolving --- Key: TUSCANY-1413 URL: https://issues.apache.org/jira/browse/TUSCANY-1413 Project: Tuscany Issue Type: Improvement Components: Java SCA BEPL Implementation Extension Reporter: Matthieu Riou Priority: Minor I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. This patch adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL implementation: WSDL and BPEL resolving
Sure, no problem. And thanks :-) On 7/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Matthieu I'm little overbooked these days, but let me see if I could try to look into the resolution thing over the weekend. Is that OK ? On 7/5/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Resolving files, getting the component interface
Hi, Thanks for the reply, see my comments in line: On 7/2/07, Raymond Feng [EMAIL PROTECTED] wrote:snip We can follow the QName resolving approach to figure out which BPEL file to use. Do you have some pointers and code that I can look at to see how this resolving is done in Tuscany right now? In case I need to extend it for BPEL. During the processing of a SCA contribution, we can create a BPELImplementation w/ the QName and mark it unresolved. For each BEPL file, we can record an entry to associate an BPEL file with the QName of the process. After resolving the QName of a process to a BPEL model, we can use the QName of the portType from the partLinkType in BEPL file to tell the WSDLs. Right but if I'm following correctly that means that the process will only be really loaded when the implementation is first used (say on the first message). That means that the process is only compiled and validated at that time which makes me a bit nervous. Basically no static validation of a deployed process would be done before the first message and you would then need to invoke to find out what's possibly wrong with your process. Ideally the process should be fully loaded with the contribution. Cheers, Matthieu Thanks, Raymond - Original Message - From: Matthieu Riou [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 02, 2007 9:27 AM Subject: Resolving files, getting the component interface Hi guys, I'm continuing on the ODE / Tuscany integration and I have a few more riddles. Say that I have to following composite: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace= http://bpel; xmlns:sc=http://bpel; xmlns:c=http://bpel; name=bpel service name=BPELHelloWorldService promote=BPELHelloWorldComponent interface.wsdl interface= http://tuscany.apache.org/implementation/bpel/example/helloworld.wsd#wsdl.interface(HelloPortType) / /service component name=BPELHelloWorldComponent implementation.bpel process=bpel-process/ /component /composite I have 2 problems here: 1. How can I retrieve the WSDL interface associated with the BPEL implementation? I need basic information about that WSDL to be able to load the BPEL file and register it in ODE. 2. How do I load the BPEL file? I could add a specific attribute for the file name but it's not so nice. Is there something that I can reuse that's already been implemented? I think you automatically load all the WSDLs from a contribution for example and then check from the namespace when you need to retrieve something. Can I plug into that resolution mechanism? I've been looking a bit at the code but a lot of the WSDL-related work is done in binding components that seem to reuse common binding-specific code. Thanks! Matthieu
[jira] Created: (TUSCANY-1394) Database import for tests, using ODE released version
Database import for tests, using ODE released version - Key: TUSCANY-1394 URL: https://issues.apache.org/jira/browse/TUSCANY-1394 Project: Tuscany Issue Type: Improvement Components: Java SCA BEPL Implementation Extension Reporter: Matthieu Riou Attachments: patch.txt, patch.zip The attached path corrects 2 things so that the module can compile and have passing tests without any tweaking: - The ODE derby database gets downloaded as a regular dependency and unzipped in the test directory before tests are executed. - Using released version of ODE instead of a local snapshot (ode-1.0-incubating). If a more recent version of ODE is needed, I'll publish a snapshot version. After this patch is applied, the module should compile and the test should run without any prior tweaking (like compiling ODE and such). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1394) Database import for tests, using ODE released version
[ https://issues.apache.org/jira/browse/TUSCANY-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1394: --- Attachment: patch.txt Patch to apply to implementation-bpel. Database import for tests, using ODE released version - Key: TUSCANY-1394 URL: https://issues.apache.org/jira/browse/TUSCANY-1394 Project: Tuscany Issue Type: Improvement Components: Java SCA BEPL Implementation Extension Reporter: Matthieu Riou Attachments: patch.txt, patch.zip The attached path corrects 2 things so that the module can compile and have passing tests without any tweaking: - The ODE derby database gets downloaded as a regular dependency and unzipped in the test directory before tests are executed. - Using released version of ODE instead of a local snapshot (ode-1.0-incubating). If a more recent version of ODE is needed, I'll publish a snapshot version. After this patch is applied, the module should compile and the test should run without any prior tweaking (like compiling ODE and such). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1394) Database import for tests, using ODE released version
[ https://issues.apache.org/jira/browse/TUSCANY-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1394: --- Attachment: patch.zip Unzip in implementation-bpel. Database import for tests, using ODE released version - Key: TUSCANY-1394 URL: https://issues.apache.org/jira/browse/TUSCANY-1394 Project: Tuscany Issue Type: Improvement Components: Java SCA BEPL Implementation Extension Reporter: Matthieu Riou Attachments: patch.txt, patch.zip The attached path corrects 2 things so that the module can compile and have passing tests without any tweaking: - The ODE derby database gets downloaded as a regular dependency and unzipped in the test directory before tests are executed. - Using released version of ODE instead of a local snapshot (ode-1.0-incubating). If a more recent version of ODE is needed, I'll publish a snapshot version. After this patch is applied, the module should compile and the test should run without any prior tweaking (like compiling ODE and such). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation.bpel
Hi, See my answers in line: On 6/24/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed your initial patch for Tuscany-1365, and also provided a summary of the necessary steps to build ODE [1] for the ones interested on playing with the implementation at the moment. Perfect, thanks! One thing I noticed is that some required databases (ode-work/jpadb) is not being created (if not present)... is this a configuration issue as we were discussing on [2] or something that we need to investigate further ? Actually that's something I indicated in the bug report. The database is required if we want meaningful tests and for now it must be copied manually. I'll try to make Maven2 download it and unzip it somewhere, I just have to pay the time toll that goes with any non-trivial Maven2 task :) I'll try to have another patch ready today or tomorrow. Cheers, Matthieu [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+implementation.bpel [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19068.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany/ODE resources questions
I don't know what would be the best way from the Tuscany standpoint, but having some sort of configuration object (maybe a StAXArtifactProcessor) mirroring part of a global Tuscany configuration and available in the module activator would be nice. And you'll probably have people at some point who will ask you how they can configure this or that in Jetty or Tomcat. And yes, there will be only one ODE server instance on which processes will be deployed. The approach I used for now is to instantiate a server wrapper in the module activator and initialize the engine lazily in the provider, when the first implementation is started. Matthieu On 6/22/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Is this something that we should consider permitting thro external config files ? And how would it work - the contribution service picks the resource up and makes it available to the module activators ? Thanks - Venkat On 6/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm still reviewing the patch provided by Matthieu [1], but I think he is taking the similar approach we have for the embedded hosts. I think that, one difference, is that we don't necessary expose or let the user tweak server configuration when we start an embedded jetty or tomcat, do we ? [1] http://issues.apache.org/jira/browse/TUSCANY-1365 On 6/22/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I assume there is going to be just about 'one' ODE instance which might be running several processes that are implementations of different components in a deployment. Is the ODE server something that we should implement on lines with the 'hosts' that we have have ? Thoughts ? - Venkat On 6/21/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I'm starting on the lifecycle part of the Tuscany/ODE integration to get an engine started with all its necessary resources (transaction, persistence, ...). I can go with in-memory mode and light configuration for now but we'll want a fully working server sooner or later. So I have a few questions: 1. How can I get server-wide configuration properties to configure the behavior of the engine? Things like the size of our thread pool, if we should use an embedded database or try to lookup a datasource, some memory optimization modes we can run in, ... These would be for the whole ODE server and not on a per-process basis. 2. How can I get the a transaction manager? I haven't been able to find an extension point for it. If there are none available, I can still create my own but it'd be probably be better to reuse the Tuscany one if it's there. 3. In embedded persistence mode, ODE uses a Derby database. Which means files located somewhere. Is there a way to lookup a given directory under which the database could be made available? For example when we deploy ODE in a webapp for example, the database is prepackage in the webapp and we find it under the context root (or alternatively a path can be configured, see 1) I think that's all for now but I'll certainly find more in the coming days :) Thanks! Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany ODE - integration
Hi Sam, I've submitted a patch yesterday to apply on the skeleton that Luciano provided (see [1]). It's a first step to get something up and running. I'm also discussing with the Tuscany guys how to handle the ODE configuration (see [2]). As for process deployment, we wouldn't have a deployment directory as in the standard ODE as the deployment is going to be provided by Tuscany as a SCA assembly (which is basically going to break our process store but one problem at a time :) ). So please have a look at the patch and check the SCA assembly model specification [3]. From there we can start incrementing. Matthieu [1] https://issues.apache.org/jira/browse/TUSCANY-1365 [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL PROTECTED] [3 http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf?version=1 ] On 6/22/07, sam tam [EMAIL PROTECTED] wrote: Hello, In the process on integrating Tuscany ODE, I have started to with implementation-bpel [skeleton available in the trunk] To start with, In order to invoke a Bpel Process in ODE, we require 1) Deployment Directory 2) Service Id 3) Operation [from wsdl / java interface ] 4) Input Args. So my plan is to provide DeploymentDir ServiceId in the composite file. In order to invoke, we have an interface and client as usual. In the client the we invoke : bpelservice.hello(Input_Args) where hello - operation name. By this we can start with an initial run. In the Invoker of Bpel Implementation we can setUp, Run, invoke bpel process get response and finally tear down ODE runtime. Am almost done with this work except one problem: In this process of Invocation : Considering CRUD sample /Bpel_Implemenation skeleton, the function name(Operation Name eg: hello,create etc..) for the client is given in the CRUD interface https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/implementation-crud-extension/src/main/java/crud/CRUD.java But this Implementation is specific for one client , how to do such that runtime automatically finds the impl of the user defined methods, and goes on invoking it ? Is my approach for the integartion Tuscany / ODE acceptabe ? Kindly provide your views..[esp. Lucaino , Matthieu , Ant and all other members ] Sam...
Re: Tuscany/ODE resources questions
Hi Simon, Please see my answers in line: On 6/22/07, Simon Laws [EMAIL PROTECTED] wrote: Can I just check that I understood what you have said. I.e. that there will be only one ODE server instance on which processes will be deployed. Does this mean, 1 ODE server instance per Tuscany runtime node (a tuscany Java SCA runtime in a Java VM) - I think this is the case given what you say about module activator Or 1 ODE service instance per machine that handles any number of tuscany runtime nodes. Your first statement is the right one yes, one ODE server per Tuscany runtime node. I'm asking because one of the things I'm interested in is how we manage a domain running across multiple runtime nodes. So if I understand correctly we're talking about clustering here. As far as ODE is concerned, I believe both deployment models should be supported: one single ODE instance that all Tuscany nodes use (locally or remotely depending on where the instance is physically instantiated) and one instance per node (and in that second deployment model, ODE would need to support clustering). From the ODE standpoint the first mode is the easiest to support (no need to be clustering aware and handle state propagation) and it's not quite what we're doing right now. So I guess we'd have to migrate at some point to that mode when it's possible? Looking to the future I have to be able to provide such data out to nodes remotely. To allow for this each distributed runtime node starts a small SCA assembly purely for managing meta data, I.e. it defines services with interfaces for reading and writing specific meta data. In that way I can use any SCA binding to send data to a node. So a binding could still allow the data to be read from a (distributed) file system but it doesn't have to be. Sounds good. That's actually more or less what I was thinking of when I mentioned the usage of files, configuration or any type of external resource. Ideally, within Tuscany, ODE shouldn't care about where things are physically located. I'm not suggesting you do anything about this specifically yet but I would like to talk about it as the implementation progresses just in case we have to do anthing to keep ODE happy. Yep, good idea. When the implementation matures we'll have to answer to those questions so it's good to ask them early :) Thanks, Matthieu Regards Simon
[jira] Created: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation
Bootstrap the ODE server in the BPEL implementation --- Key: TUSCANY-1365 URL: https://issues.apache.org/jira/browse/TUSCANY-1365 Project: Tuscany Issue Type: New Feature Components: Java SCA BPEL Implementation Extension Reporter: Matthieu Riou Attachments: ode-init.patch I'm attaching a patch and a zip (for new files) containing the necessary code to bootstrap the ODE BPEL server. It actually doesn't give you much as it's just initializing all resources needed by the server and then loading it, so nothing is there for exchanging messages. But it's already a start. Testing is a bit rough as it's still very preliminary but here are the steps to get the test case to run: 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk as some tweaks or improvements here and there will probably be needed in ODE as well. Later on, when the implementation is bit more stable, I'll publish snapshots and eventually transition to an ODE release. In the meantime, here is how to build ODE (using buildr): http://incubator.apache.org/ode/jacob.html Run the install task instead of package to have the created jars published in your local directory. 2. The server initializes Derby, so you need to have a Derby database. For now it will be looking for it in an ode-work subdirectory of the BPEL implementation root directory (until we implement a better way to find it). Create this directory and copy the jpadb directory found in ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You should end up with implementation-bpel/ode-work/jpadb. 3. Run mvn test. Maven2 being a pain, it will download the whole world. Several things aren't actually required but come with transitive dependencies, we'll have to exclude things at some point but for now it should work. If the Maven2 build fails because it couldn't download a dependency, you'll need to add some remote repositories. Here are the ones we have in ODE: repositories.remote http://pxe.intalio.org/public/maven2; repositories.remote http://people.apache.org/repo/m2-incubating-repository; repositories.remote http://repo1.maven.org/maven2; repositories.remote http://people.apache.org/repo/m2-snapshot-repository; Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation
[ https://issues.apache.org/jira/browse/TUSCANY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1365: --- Attachment: ode-init.patch Patch file to apply in implementation-bpel Bootstrap the ODE server in the BPEL implementation --- Key: TUSCANY-1365 URL: https://issues.apache.org/jira/browse/TUSCANY-1365 Project: Tuscany Issue Type: New Feature Components: Java SCA BPEL Implementation Extension Reporter: Matthieu Riou Attachments: ode-init.patch I'm attaching a patch and a zip (for new files) containing the necessary code to bootstrap the ODE BPEL server. It actually doesn't give you much as it's just initializing all resources needed by the server and then loading it, so nothing is there for exchanging messages. But it's already a start. Testing is a bit rough as it's still very preliminary but here are the steps to get the test case to run: 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk as some tweaks or improvements here and there will probably be needed in ODE as well. Later on, when the implementation is bit more stable, I'll publish snapshots and eventually transition to an ODE release. In the meantime, here is how to build ODE (using buildr): http://incubator.apache.org/ode/jacob.html Run the install task instead of package to have the created jars published in your local directory. 2. The server initializes Derby, so you need to have a Derby database. For now it will be looking for it in an ode-work subdirectory of the BPEL implementation root directory (until we implement a better way to find it). Create this directory and copy the jpadb directory found in ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You should end up with implementation-bpel/ode-work/jpadb. 3. Run mvn test. Maven2 being a pain, it will download the whole world. Several things aren't actually required but come with transitive dependencies, we'll have to exclude things at some point but for now it should work. If the Maven2 build fails because it couldn't download a dependency, you'll need to add some remote repositories. Here are the ones we have in ODE: repositories.remote http://pxe.intalio.org/public/maven2; repositories.remote http://people.apache.org/repo/m2-incubating-repository; repositories.remote http://repo1.maven.org/maven2; repositories.remote http://people.apache.org/repo/m2-snapshot-repository; Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation
[ https://issues.apache.org/jira/browse/TUSCANY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Riou updated TUSCANY-1365: --- Attachment: ode-init.zip Zip file to unzip in implementation-bpel Bootstrap the ODE server in the BPEL implementation --- Key: TUSCANY-1365 URL: https://issues.apache.org/jira/browse/TUSCANY-1365 Project: Tuscany Issue Type: New Feature Components: Java SCA BPEL Implementation Extension Reporter: Matthieu Riou Attachments: ode-init.patch, ode-init.zip I'm attaching a patch and a zip (for new files) containing the necessary code to bootstrap the ODE BPEL server. It actually doesn't give you much as it's just initializing all resources needed by the server and then loading it, so nothing is there for exchanging messages. But it's already a start. Testing is a bit rough as it's still very preliminary but here are the steps to get the test case to run: 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk as some tweaks or improvements here and there will probably be needed in ODE as well. Later on, when the implementation is bit more stable, I'll publish snapshots and eventually transition to an ODE release. In the meantime, here is how to build ODE (using buildr): http://incubator.apache.org/ode/jacob.html Run the install task instead of package to have the created jars published in your local directory. 2. The server initializes Derby, so you need to have a Derby database. For now it will be looking for it in an ode-work subdirectory of the BPEL implementation root directory (until we implement a better way to find it). Create this directory and copy the jpadb directory found in ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You should end up with implementation-bpel/ode-work/jpadb. 3. Run mvn test. Maven2 being a pain, it will download the whole world. Several things aren't actually required but come with transitive dependencies, we'll have to exclude things at some point but for now it should work. If the Maven2 build fails because it couldn't download a dependency, you'll need to add some remote repositories. Here are the ones we have in ODE: repositories.remote http://pxe.intalio.org/public/maven2; repositories.remote http://people.apache.org/repo/m2-incubating-repository; repositories.remote http://repo1.maven.org/maven2; repositories.remote http://people.apache.org/repo/m2-snapshot-repository; Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany/ODE resources questions
Hi guys, I'm starting on the lifecycle part of the Tuscany/ODE integration to get an engine started with all its necessary resources (transaction, persistence, ...). I can go with in-memory mode and light configuration for now but we'll want a fully working server sooner or later. So I have a few questions: 1. How can I get server-wide configuration properties to configure the behavior of the engine? Things like the size of our thread pool, if we should use an embedded database or try to lookup a datasource, some memory optimization modes we can run in, ... These would be for the whole ODE server and not on a per-process basis. 2. How can I get the a transaction manager? I haven't been able to find an extension point for it. If there are none available, I can still create my own but it'd be probably be better to reuse the Tuscany one if it's there. 3. In embedded persistence mode, ODE uses a Derby database. Which means files located somewhere. Is there a way to lookup a given directory under which the database could be made available? For example when we deploy ODE in a webapp for example, the database is prepackage in the webapp and we find it under the context root (or alternatively a path can be configured, see 1) I think that's all for now but I'll certainly find more in the coming days :) Thanks! Matthieu
Re: SCA WS-BPEL
Hi Sam, I'll have a deeper look at this today or tomorrow. I'll certainly have a look at what you've contributed so far. My understanding is that Tuscany's SPIs have significantly changed so we may be better off starting from scratch from the skeleton Luciano has created and import (understand copy/paste) the code you've already done gradually (tweaking what needs to be tweaked). Anyway I'll create a new issue for this, trying to merge the new skeleton and what you've done before and maybe we can start from that. Cheers, Matthieu On 6/14/07, sam tam [EMAIL PROTECTED] wrote: Hello, This is regarding the integration of Apache ODE and Apache Tuscany ! I have contributed a container in Apache Tuscnay for BPEL which was an initial startup http://issues.apache.org/jira/browse/TUSCANY-897 I think that was during M2 release [ During the month of Dec 2006 ] I want to contribute more for the integration because I had been working on it before . I replied to Luciano's mail regarding this in Apache ODE ML but accidentally I missed Tuscany ML. So I just want to inform you guys ! Sam Tam. On 6/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi All I'm sending this e-mail to reactivate the collaboration between Apache Tuscany and Apache ODE as initiated by Matthieu a while ago[1]. It would be great if we could have an WS-BPEL component implementation described in [2] and [3], where we would be able to run executables WS-BPEL process from an SCA runtime. In order to get this started, I have put together a skeleton that we could use as the bases for implementation.bepel and it's available at [4]. I'm in the middle of simplifying it further, and I'll keep you guys posted of my progress. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10042.html [2] http://osoa.org/display/Main/SCA+BPEL+White+Paper [3] http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1 [4] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --
Re: SCA and BPEL
Hi Sam,
I've had a look at your implementation and played with a couple of things on
my side as well. I think I have a much better idea of how things can play
with each other now and how to solve your problems.
- For server instantiation, you should create a separate component for it
with @Init and @Destroy annotations. I've made a rough implementation of it
and I think you could take it and start from that. You'll just have to add
the component as a system implementation in your bpel.system.cdl. I'll
attach the java file to the same Jira issue. Then you can have this injected
in the BpelComponentBuilder using a constructor like:
public BpelComponentBuilder(@Autowire BpelServerLoader serverLoader) {
_server = serverLoader.getServer();
_store = serverLoader.getStore();
}
That should fix the server instantiation problem.
- For the binding part you will need to go through a real remote web service
invocation. Check of the Tuscany helloworldws is structured with the
sample-helloworldws web application being deployed in Tomcat and the client
sample-helloworldwsclient calling it remotely. I think you can even reuse
the client almost as is. However the server side should change to something
like:
service name=HelloWorldBPELService
interface.wsdl interface=
http://ode/bpel/unit-test.wsdl#wsdl.interface(HelloPortType)
wsdli:wsdlLocation=http://ode/bpel/unit-test.wsdl
HelloWorld2.wsdl/
binding.ws endpoint=
http://ode/bpel/unit-test.wsdl#wsdl.endpoint(HelloService/HelloPort)
location=HelloWorld2.wsdl /
referenceHelloWorldBPELComponent/reference
/service
component name=HelloWorldBPELComponent
bpel:implementation.bpeldepDir=/home/dusty/Dev/Projects/tuscany/sca/services/containers/container.bpel/src/test/resources/HelloWorld2
serviceId=http://ode/bpel/unit-test.wsdlHelloService/
/component
Again check the Tuscany sample-helloworldws service declaration, it's almost
the same except for the implementation that will be BPEL in our case instead
of java. You can even use the same type of SDO databinding So you will need
to package the BPEL container on the server side in Tomcat and that should
get loaded.
Let me know if you need more,
Matthieu
On 11/26/06, sam tam [EMAIL PROTECTED] wrote:
Hello Guys..
As discussed earlier about Integration of SCA(Apache Tuscany) and BPEL
(Apache Ode),
I have started with a bpel container for Apache Tuscany(SCA).
Also i have attached a small readme file .
And a test case file also.
The link for the attached source is :
http://issues.apache.org/jira/browse/TUSCANY-897?page=all
Comments:
Things to do :
- need to figure out a better way than instantiating the server for every
component
- need to bring in databinding into the invoke method to be able to
convert
java objects to xml that can be sent over ODE requests and also do the
reverse for the response.
Guys I need your feedback on this !!! Plz share your ideas . !!.
Sam..Tam...
___
On 10/29/06, sam tam [EMAIL PROTECTED] wrote:
That would be fine with me Ant. I am residing in India ..So to confirm
:
Thursday 4pm BST !
Sam...
On 10/29/06, ant elder [EMAIL PROTECTED] wrote:
Thats fine for me, how about you Sam?
...ant
On 10/27/06, Matthieu Riou [EMAIL PROTECTED] wrote:
Actually most Ode committers (including myself) are in California.
Also
we're going to be a bit busy early next week. So would 4pm BST (8am
PST) on
Thursday work for you?
On 10/27/06, ant elder [EMAIL PROTECTED] wrote:
Sure ok I guess an IRC chat would be fine to get started. I'm in
UK
time
zone but can be pretty flexible about scheduling it. How about
9:30am BST
next Tuesday?
..ant
On 10/26/06, Matthieu Riou [EMAIL PROTECTED] wrote:
Hi,
So what about an IRC session to get started? Everybody
interested
could come to ask questions and we would discuss in more details
how this
could be done. We can both exchange our views on SCA / BPEL and
give as much
information as possible to the volunteers (like Sam [1]).
What do you think?
Matthieu
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL
PROTECTED]
On 10/25/06, ant elder [EMAIL PROTECTED] wrote:
On 10/25/06, Matthieu Riou [EMAIL PROTECTED] wrote:
Hi all,
This e-mail is being sent to both Apache Ode and Tuscany
development mailing
lists.
The objective is to see which possible collaboration could
happen
between
our 2 projects and how we could integrate them. Alex, Cory
and
myself (we're
all Ode contributors) met with Jean-Sebastien Delfino and
Simon
Laws
(Tuscany contributors) during the ApacheCon in Austin and
we've
found out
[jira] Updated: (TUSCANY-897) BPEL container based on Apache Ode
[ http://issues.apache.org/jira/browse/TUSCANY-897?page=all ] Matthieu Riou updated TUSCANY-897: -- Attachment: BpelServerLoader.java Simple loader than can be used to initialize Ode. BPEL container based on Apache Ode -- Key: TUSCANY-897 URL: http://issues.apache.org/jira/browse/TUSCANY-897 Project: Tuscany Issue Type: New Feature Components: Java SCA Common Affects Versions: Java-Mx Reporter: ant elder Fix For: Java-Mx Attachments: BpelServerLoader.java, container.bpel.zip JIRA for attaching patches to create the Tuscany BPEL container based on Apache Ode. There's a white paper on SCA and BPEL at: http://osoa.org/display/Main/Service+Component+Architecture+Specifications A draft specification is available at: http://osoa.org/display/Main/Service+Component+Architecture+Specifications The Tuscany container is at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test compilation failure
Hi, I just wanted to let you know that I had a small compilation failure when building Tuscany from the sources (latest trunk) with a test case that didn't compile: /home/dusty/Dev/Projects/tuscany/sca/tools/src/test/java/org/example/creditscore/doclit/DoclitPackage.java:[23,41] cannot find symbol symbol : class ModelPackageImpl location: package org.apache.tuscany.sdo.model.impl And more. Look like a package has been moved. No big deal, I just skipped the tests for that module but just wanted to let you know... Cheers, Matthieu
[BPEL] Transaction managers, datasources and more
Hi, I have a better and better idea on how Apache Ode could be used as a Tuscany container. However I'm still wondering how I can get hold on some resources in Tuscany. To run Ode's BPEL engine we need basic services like a transaction manager, a datasource or a thread scheduler ( java.util.concurrent.ExecutorService). How could these be provided to the BPEL container? Do you already have something for this? Or should we assume that we're running in a managed environment (i.e. Geronimo) and lookup these things ourselves? Thanks, Matthieu
Re: IRC chat on Ode/Tuscany integration: Thursday 2nd Nov 4pm GMT/8amPST (was Re: SCA and BPEL)
Thanks ant! On 11/3/06, ant elder [EMAIL PROTECTED] wrote: As discussed, I've created an empty skeleton container for this at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/ There's a JIRA for attaching patches to at: https://issues.apache.org/jira/browse/TUSCANY-897 Starting sending your patches! ...ant
Re: Private mailing list now set up for Tuscany
It's simply sending an e-mail to the infrastructure mailing-list, giving them the mailing-list name and your Apache id and they'll add you as a moderator. Matthieu On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 7/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 27, 2006, at 9:02 AM, ant elder wrote: Did you ever add me as a moderator for the private list, I've not seen any moderation requests? So you must have seen all the subscription requests...could you post a list of who has subscribed? (or is there some other way I can find the subscriber list myself and I'll post the list?) I haven't figured out how to add you as a moderator - I'd ask one of our mentors to explain the mechanism ... Dims, any idea how to add me as moderator to the Tuscany lists? Thanks, ...ant
Re: SCA and BPEL
Actually most Ode committers (including myself) are in California. Also we're going to be a bit busy early next week. So would 4pm BST (8am PST) on Thursday work for you? On 10/27/06, ant elder [EMAIL PROTECTED] wrote: Sure ok I guess an IRC chat would be fine to get started. I'm in UK time zone but can be pretty flexible about scheduling it. How about 9:30am BST next Tuesday? ..ant On 10/26/06, Matthieu Riou [EMAIL PROTECTED] wrote: Hi, So what about an IRC session to get started? Everybody interested could come to ask questions and we would discuss in more details how this could be done. We can both exchange our views on SCA / BPEL and give as much information as possible to the volunteers (like Sam [1]). What do you think? Matthieu [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED] On 10/25/06, ant elder [EMAIL PROTECTED] wrote: On 10/25/06, Matthieu Riou [EMAIL PROTECTED] wrote: Hi all, This e-mail is being sent to both Apache Ode and Tuscany development mailing lists. The objective is to see which possible collaboration could happen between our 2 projects and how we could integrate them. Alex, Cory and myself (we're all Ode contributors) met with Jean-Sebastien Delfino and Simon Laws (Tuscany contributors) during the ApacheCon in Austin and we've found out that integrating Ode into Tuscany could be a brilliant idea. From the Tuscany side, there's an SCA client and implementation spec for BPEL. Roughly, it defines how a BPEL process can be used as an SCA component (or at least that's my understanding of it). So I guess Ode could be a good choice for the BPEL part of that. From the Apache Ode perspective, we've defined an interface to the engine ( a.k.a. the integration API or IAPI for acromyn lovers) and we would like to support several integration scenarii. Currently we have an integration layer for Axis2 to support all web services interactions, we also have one for JBI and another one for CXF has been proposed. We would love to have an implementation of these interfaces for Tuscany to be able to run Ode in an SCA environment (for the curious, the interfaces are herehttps://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ ). I think the discussion (if discussion there is) should take place on tuscany-dev as there's less of us, Ode people, so it's easier for us to subscribe to it. So what would it take to fit into Tuscany? Thanks, Matthieu Hi Matthieu, this would be really great, i'd love for Tuscany to get a involved with Ode to get a BPEL component. For those that haven't found these already there's a white paper on SCA and BPEL [1] and a specification [2]. You can see the type of thing required to implement a container for a new component type in Tuscany by looking at some of our existing ones [3] I agree it may be easiest for the discussions to be over here initially, but i've subscribed to ode-dev as well anyway. I'd be very happy to help you do this, how would you like to get started? ...ant [1] http://osoa.org/display/Main/SCA+BPEL+White+Paper [2] http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_v0.95.pdf?version=2 [3] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/
Re: SCA and BPEL
Hi, So what about an IRC session to get started? Everybody interested could come to ask questions and we would discuss in more details how this could be done. We can both exchange our views on SCA / BPEL and give as much information as possible to the volunteers (like Sam [1]). What do you think? Matthieu [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED] On 10/25/06, ant elder [EMAIL PROTECTED] wrote: On 10/25/06, Matthieu Riou [EMAIL PROTECTED] wrote: Hi all, This e-mail is being sent to both Apache Ode and Tuscany development mailing lists. The objective is to see which possible collaboration could happen between our 2 projects and how we could integrate them. Alex, Cory and myself (we're all Ode contributors) met with Jean-Sebastien Delfino and Simon Laws (Tuscany contributors) during the ApacheCon in Austin and we've found out that integrating Ode into Tuscany could be a brilliant idea. From the Tuscany side, there's an SCA client and implementation spec for BPEL. Roughly, it defines how a BPEL process can be used as an SCA component (or at least that's my understanding of it). So I guess Ode could be a good choice for the BPEL part of that. From the Apache Ode perspective, we've defined an interface to the engine ( a.k.a. the integration API or IAPI for acromyn lovers) and we would like to support several integration scenarii. Currently we have an integration layer for Axis2 to support all web services interactions, we also have one for JBI and another one for CXF has been proposed. We would love to have an implementation of these interfaces for Tuscany to be able to run Ode in an SCA environment (for the curious, the interfaces are herehttps://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ ). I think the discussion (if discussion there is) should take place on tuscany-dev as there's less of us, Ode people, so it's easier for us to subscribe to it. So what would it take to fit into Tuscany? Thanks, Matthieu Hi Matthieu, this would be really great, i'd love for Tuscany to get a involved with Ode to get a BPEL component. For those that haven't found these already there's a white paper on SCA and BPEL [1] and a specification [2]. You can see the type of thing required to implement a container for a new component type in Tuscany by looking at some of our existing ones [3] I agree it may be easiest for the discussions to be over here initially, but i've subscribed to ode-dev as well anyway. I'd be very happy to help you do this, how would you like to get started? ...ant [1] http://osoa.org/display/Main/SCA+BPEL+White+Paper [2] http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_v0.95.pdf?version=2 [3] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/
Re: SCA and BPEL - Integration
Hi, Nice volunteering indeed! So on the Ode side, I'd go with implementing a specific integration layer for Tuscany instead of reusing the Axis2 one. That would allow in-VM SCA / BPEL interactions and a greater integration between the two. Ode provides an integration API that you have to implement if you want to plug the engine into something else. The engine uses this API to get whatever it needs to work, like the ability to send and receive messages, to get some representation of the services it's going to interact with, or even threads and transactions. So you would just wire up all services Tuscany provides into the engine when implementing these interfaces. To see what those look like you can have a look at [1]. We currently have 3 working implementations for these interfaces: Axis2, JBI and test. The Axis2 one is wrapped around Axis2 in a WAR and works in any servlet container. The JBI one is bundled in a Service Assembly and can be deployed in ServiceMix. The test one works in-memory in a standalone manner. These are great examples to look at to see how the required services are provided to the engine and how everything is initialized. In particular you can have a look at ODEServer [2] for Axis2 and OdeLifeCycle [3] for JBI, these are where all the initialization and wiring up logic happens for these 2 integrations. I'd start from the test IAPI implementation [4] [5] to see how things work out, this will run in memory so you won't have to worry about providing a datasource and a transaction manager to start with. Then you can bring some pieces from the Axis2 and JBI integrations (copy / paste is your friend) and increment from that. Implement the different communication interfaces by using Tuscany services and you should be all set. Now I think we could discuss about the details and how to use Tuscany services in Ode during an IRC chat session as I proposed in the other thread? So we can all have a better understanding of how this will work and you'll have more information to start from. Matthieu [1] https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ [2] https://svn.apache.org/repos/asf/incubator/ode/trunk/axis2/src/main/java/org/apache/ode/axis2/ODEServer.java [3] https://svn.apache.org/repos/asf/incubator/ode/trunk/jbi/src/main/java/org/apache/ode/jbi/OdeLifeCycle.java [4] https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/src/test/java/org/apache/ode/test/BPELTest.java [5] https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/src/main/java/org/apache/ode/test/ On 10/26/06, ant elder [EMAIL PROTECTED] wrote: On 10/26/06, sam tam [EMAIL PROTECTED] wrote: Hi, I am a student and I have been looking into this topic for my project work. I'd like to contribute as much in this with some help from you folks. For now here is what I have been doing as ground work. - Tried out Tuscany M1 release and also recently from the current development branch. - With Apache ODE I deployed sample process in Tomcat and have been able to call it using a SOAP message. At the present moment I am trying to figure out how to integrate ODE into Tuscany. One obvious thought I have in my mind is to use the Tuscany Axis2 Binding and invoke the BPEL process as a reference. I am going to be digging into the OSOA specs for this and hope to get better clarity as I go along. I'd be happy to take advice from you folks on taking this forward. Thanks. Sam. Hi Sam, Its great you're interested in this, it would be really good to have BPEL support in Tuscany. In case you didn't see due to all the ASF email problems over the last few days, the Ode guys have also just started talking about this: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10042.html. I talked about how to start a new container in this old mail: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/browser . I'd start with trying to get a simple helloworld going which for this would be a combination of the Tuscany helloworldws sample and the Ode axis2-examples HelloWorld2. Basically start by copying the existing sample and one of the Tuscany containers, rename everything to BPEL. Remember when you do the copy/rename there's scdl in the META-INF/sca directory that you'll need to edit to update with the new class names. As there's an existing SCA spec for this you get some help with what to do. The spec defines what the implementation element looks like: implementation.bpel process=xs:QName/ So you'll need something like a BPELImplementation and BPELImplementationLoader for that. Use one of the existing ones and just change the QName constant to be implementation.bpel and the code to read in the attribute named process. A harder part will be how Tuscany locates the BPEL process XML, for now its likely easiest to add a location attribute and have the loader just read it in, and then sort this part out properly later oncee
SCA and BPEL
Hi all, This e-mail is being sent to both Apache Ode and Tuscany development mailing lists. The objective is to see which possible collaboration could happen between our 2 projects and how we could integrate them. Alex, Cory and myself (we're all Ode contributors) met with Jean-Sebastien Delfino and Simon Laws (Tuscany contributors) during the ApacheCon in Austin and we've found out that integrating Ode into Tuscany could be a brilliant idea. From the Tuscany side, there's an SCA client and implementation spec for BPEL. Roughly, it defines how a BPEL process can be used as an SCA component (or at least that's my understanding of it). So I guess Ode could be a good choice for the BPEL part of that. From the Apache Ode perspective, we've defined an interface to the engine ( a.k.a. the integration API or IAPI for acromyn lovers) and we would like to support several integration scenarii. Currently we have an integration layer for Axis2 to support all web services interactions, we also have one for JBI and another one for CXF has been proposed. We would love to have an implementation of these interfaces for Tuscany to be able to run Ode in an SCA environment (for the curious, the interfaces are herehttps://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ ). I think the discussion (if discussion there is) should take place on tuscany-dev as there's less of us, Ode people, so it's easier for us to subscribe to it. So what would it take to fit into Tuscany? Thanks, Matthieu
