Re: Howto install netbeans BPEL SE
I have a BPEL SU deploying from a SA and it works good, except I have yet to get a doc into it. Im sure I will get it.. I followed the servicemix example for the loanbroker BPEL SU. I dissassembled it and then created my bpel SU exactly how it was. hgkrt wrote: You can find the sun bpel engine from \Your_Sun_APP_Home\addons\jbi-components directory,(use NetBeansIDE6.0M9 installer) named bpelserviceengine.jar. Just copy it to ServiceMix3.1 install directory, and start servicemix, you can see the bpel engine started message. is this you want to do ? but i still not know how to make a bpel su work on servicemix. jbi joe wrote: Is there a way to install netbeans BPEL SE into servicemix 3.1? If so, can I get some detailed instructions on doing it? I took a look through the netbeans and didnt see any zip files that looked to be in the JBI component format. The reason that I am doing this is because I cannot get the syntax of the servicemix-bpe to understand some 2.0 BPEL instructions.For example; if name=MyTest condition $Variable1 = 'SomeTestValue /condition seqence ..blah, blah etc,., /sequence /if -- View this message in context: http://www.nabble.com/Howto-install-netbeans-BPEL-SE-tf3981727s12049.html#a11329467 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Howto install netbeans BPEL SE
servicemix-bpe is not supported anymore. You should give a try to Apache Ode instead. On 6/26/07, jbi joe [EMAIL PROTECTED] wrote: Is there a way to install netbeans BPEL SE into servicemix 3.1? If so, can I get some detailed instructions on doing it? I took a look through the netbeans and didnt see any zip files that looked to be in the JBI component format. The reason that I am doing this is because I cannot get the syntax of the servicemix-bpe to understand some 2.0 BPEL instructions.For example; if name=MyTest condition $Variable1 = 'SomeTestValue /condition seqence ..blah, blah etc,., /sequence /if -- View this message in context: http://www.nabble.com/Howto-install-netbeans-BPEL-SE-tf3981727s12049.html#a11303610 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-946) Upgrade loan-broker-bpel example to use Apache Ode
[ https://issues.apache.org/activemq/browse/SM-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39108 ] Guillaume Nodet commented on SM-946: URL: http://svn.apache.org/viewvc?view=revrev=535118 Upgrade loan-broker-bpel example to use Apache Ode -- Key: SM-946 URL: https://issues.apache.org/activemq/browse/SM-946 Project: ServiceMix Issue Type: Task Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-946) Upgrade loan-broker-bpel example to use Apache Ode
[ https://issues.apache.org/activemq/browse/SM-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-946. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=revrev=535211 URL: http://svn.apache.org/viewvc?view=revrev=535212 Upgrade loan-broker-bpel example to use Apache Ode -- Key: SM-946 URL: https://issues.apache.org/activemq/browse/SM-946 Project: ServiceMix Issue Type: Task Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Upgrade loan broker bpel example to Apache Ode
+1 :) On 5/3/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I have some changes ready to commit to upgrade the loan-broker-bpel example from the ServiceMix distribution to Apache Ode instead of our deprecated servicemix-bpe SE. I think we should make this change in both trunk and 3.1 branch before releasing 3.1.1. Does everyone agree or is there any objection ? -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: Upgrade loan broker bpel example to Apache Ode
Not until there is a release at least. On 5/4/07, Adrian Co [EMAIL PROTECTED] wrote: Hi, Does this mean that ServiceMix will bundle the ode jbi installer or will this be a separate download? Guillaume Nodet wrote: I have some changes ready to commit to upgrade the loan-broker-bpel example from the ServiceMix distribution to Apache Ode instead of our deprecated servicemix-bpe SE. I think we should make this change in both trunk and 3.1 branch before releasing 3.1.1. Does everyone agree or is there any objection ? -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: Upgrade loan broker bpel example to Apache Ode
Yeah, I think we will have to discuss that. That's a good idea, but then I think we would need several distributions maybe. Another problem would be a release cyclic dependency somehow as ServiceMix would rely on Ode and Ode relies on ServiceMix dependencies... On 5/4/07, Alex Boisvert [EMAIL PROTECTED] wrote: On 5/3/07, Adrian Co [EMAIL PROTECTED] wrote: Does this mean that ServiceMix will bundle the ode jbi installer or will this be a separate download? I think as soon as we have an official Apache Ode incubator release, it could be bundled with ServiceMix. alex -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: [jira] correction ODE bpel using xerces - how can i change that ?
Hi, i meant using ode and not the bpe... gnodet wrote: I have really no idea. One of the problem is that the bpel engine used by servicemix-bpe is not supported anymore, that's why this component has been deprecated (see http://incubator.apache.org/servicemix/servicemix-bpe.html). I would advise you to switch to Apache Ode JBI component. See http://incubator.apache.org/ode/ On 3/9/07, yhofri [EMAIL PROTECTED] wrote: Hi, i've been benchmarking the servicemix bpe, and got poor results, a profile showed that lots of cpu is consumed by the xerces org.apache.xerces.parsers.SecuritySupport. shown by the quotation ( bottom to top ) : java.util.zip.ZipFile.getEntry(ZipFile.java:250) org.apache.xerces.parsers.SecuritySupport$6.run(Unknown Source) java.security.AccessController.doPrivileged(Native Method) org.apache.xerces.parsers.SecuritySupport.getResourceAsStream(Unknown Source) ... org.apache.xerces.jaxp.DocumentBuilderImpl.init(Unknown Source) ... org.apache.servicemix.jbi.jaxp.SourceTransformer.toDOMSourceFromStream ... org.apache.servicemix.bpe.external.JbiInvokeAction.execute( JbiInvokeAction.java:243) How can i disable xerces security policy ? How can i avoid xerces from getting the file ? How can i change it from usign xerces, into using sax ??? 10x -- View this message in context: http://www.nabble.com/BPE-using-xerces---how-can-i-change-that---tf3376153s12049.html#a9395934 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/BPE-using-xerces---how-can-i-change-that---tf3376153s12049.html#a9412597 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [jira] correction ODE bpel using xerces - how can i change that ?
From the stack trace, you are actually using servicemix-bpe ... On 3/10/07, yhofri [EMAIL PROTECTED] wrote: Hi, i meant using ode and not the bpe... gnodet wrote: I have really no idea. One of the problem is that the bpel engine used by servicemix-bpe is not supported anymore, that's why this component has been deprecated (see http://incubator.apache.org/servicemix/servicemix-bpe.html). I would advise you to switch to Apache Ode JBI component. See http://incubator.apache.org/ode/ On 3/9/07, yhofri [EMAIL PROTECTED] wrote: Hi, i've been benchmarking the servicemix bpe, and got poor results, a profile showed that lots of cpu is consumed by the xerces org.apache.xerces.parsers.SecuritySupport. shown by the quotation ( bottom to top ) : java.util.zip.ZipFile.getEntry(ZipFile.java:250) org.apache.xerces.parsers.SecuritySupport$6.run(Unknown Source) java.security.AccessController.doPrivileged(Native Method) org.apache.xerces.parsers.SecuritySupport.getResourceAsStream(Unknown Source) ... org.apache.xerces.jaxp.DocumentBuilderImpl.init(Unknown Source) ... org.apache.servicemix.jbi.jaxp.SourceTransformer.toDOMSourceFromStream ... org.apache.servicemix.bpe.external.JbiInvokeAction.execute( JbiInvokeAction.java:243) How can i disable xerces security policy ? How can i avoid xerces from getting the file ? How can i change it from usign xerces, into using sax ??? 10x -- View this message in context: http://www.nabble.com/BPE-using-xerces---how-can-i-change-that---tf3376153s12049.html#a9395934 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/BPE-using-xerces---how-can-i-change-that---tf3376153s12049.html#a9412597 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
integrating Sun - openESB BPEL SE with servicemix
Hi, i've been trying to use Sun - openESB BPEL SE with servicemix, yet encountered some issues. has anyone done that before ? is servicemix compatible with Sun/openESB and any other JBI Spec. components ? 10x hofri -- View this message in context: http://www.nabble.com/integrating-Sun---openESB-BPEL-SE-with-servicemix-tf3260417s12049.html#a9061418 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [jira] integrating Sun - openESB BPEL SE with servicemix
I have installed openESB BpelSE and httpsoapBC. I have deployed a CompositeApplication using this components too. But I havent been able to test this application. See: http://www.nabble.com/forum/ViewPost.jtp?post=9060063framed=yskin=12049 yhofri wrote: Hi, i've been trying to use Sun - openESB BPEL SE with servicemix, yet encountered some issues. has anyone done that before ? is servicemix compatible with Sun/openESB and any other JBI Spec. components ? 10x hofri -- View this message in context: http://www.nabble.com/integrating-Sun---openESB-BPEL-SE-with-servicemix-tf3260417s12049.html#a9063075 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Created: (SM-843) The defaultMep attribute is missing on the jms endpoint in loan-broker-bpel demo
The defaultMep attribute is missing on the jms endpoint in loan-broker-bpel demo Key: SM-843 URL: https://issues.apache.org/activemq/browse/SM-843 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-843) The defaultMep attribute is missing on the jms endpoint in loan-broker-bpel demo
[ https://issues.apache.org/activemq/browse/SM-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-843. Resolution: Fixed Author: gnodet Date: Wed Feb 14 09:12:14 2007 New Revision: 507629 URL: http://svn.apache.org/viewvc?view=revrev=507629 Log: SM-843: The defaultMep attribute is missing on the jms endpoint in loan-broker-bpel demo Modified: incubator/servicemix/trunk/samples/loan-broker/loan-broker-jms-su/src/main/resources/xbean.xml Author: gnodet Date: Wed Feb 14 09:17:00 2007 New Revision: 507631 URL: http://svn.apache.org/viewvc?view=revrev=507631 Log: SM-843: The defaultMep attribute is missing on the jms endpoint in loan-broker-bpel demo Modified: incubator/servicemix/branches/servicemix-3.1/samples/loan-broker/loan-broker-jms-su/src/main/resources/xbean.xml The defaultMep attribute is missing on the jms endpoint in loan-broker-bpel demo Key: SM-843 URL: https://issues.apache.org/activemq/browse/SM-843 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-826) Add client for loan-broker-bpel
[ https://issues.apache.org/activemq/browse/SM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-826. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Feb 14 09:17:09 2007 New Revision: 507632 URL: http://svn.apache.org/viewvc?view=revrev=507632 Log: SM-828: Add a client for the loan-broker-bpel demo. Patch provided by Gregoire Autric, thx \! Added: incubator/servicemix/trunk/samples/loan-broker/build.xml (with props) incubator/servicemix/trunk/samples/loan-broker/src/main/java/ incubator/servicemix/trunk/samples/loan-broker/src/main/java/JMSClient.java (with props) Modified: incubator/servicemix/trunk/samples/loan-broker/README.txt incubator/servicemix/trunk/samples/loan-broker/src/main/assembly/src.xml Add client for loan-broker-bpel --- Key: SM-826 URL: https://issues.apache.org/activemq/browse/SM-826 Project: ServiceMix Issue Type: New Feature Components: servicemix-bpe Affects Versions: incubation Environment: all platforms Reporter: Grégoire A. Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.2 Attachments: JMSClientBPEL.java, loan-broker.diff Original Estimate: 30 minutes Remaining Estimate: 30 minutes add client test for loan-broker-bpel i add the class code, i should be work fine !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-833) into loan-broker-bpel sample - javax.jbi.messaging.MessagingException: Do not understand pattern: null
[ https://issues.apache.org/activemq/browse/SM-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-833. Resolution: Fixed Fix Version/s: 3.2 into loan-broker-bpel sample - javax.jbi.messaging.MessagingException: Do not understand pattern: null -- Key: SM-833 URL: https://issues.apache.org/activemq/browse/SM-833 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Affects Versions: 3.1 Environment: all Reporter: Grégoire A. Fix For: 3.2 Attachments: xbean.xml.diff Original Estimate: 10 minutes Remaining Estimate: 10 minutes Do not understand pattern: null when calling the sample throw the jms endpoint i add the defaultMep=http://www.w3.org/2004/08/wsdl/in-out; into jms endpoint -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-826) Add client for loan-broker-bpel
[ https://issues.apache.org/activemq/browse/SM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-826: --- Fix Version/s: (was: 3.1) 3.2 Add client for loan-broker-bpel --- Key: SM-826 URL: https://issues.apache.org/activemq/browse/SM-826 Project: ServiceMix Issue Type: New Feature Components: servicemix-bpe Affects Versions: incubation Environment: all platforms Reporter: Grégoire A. Priority: Minor Fix For: 3.2 Attachments: JMSClientBPEL.java, loan-broker.diff Original Estimate: 30 minutes Remaining Estimate: 30 minutes add client test for loan-broker-bpel i add the class code, i should be work fine !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-833) into loan-broker-bpel sample - javax.jbi.messaging.MessagingException: Do not understand pattern: null
into loan-broker-bpel sample - javax.jbi.messaging.MessagingException: Do not understand pattern: null -- Key: SM-833 URL: https://issues.apache.org/activemq/browse/SM-833 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Affects Versions: 3.1 Environment: all Reporter: Grégoire A. Attachments: xbean.xml.diff Do not understand pattern: null when calling the sample throw the jms endpoint i add the defaultMep=http://www.w3.org/2004/08/wsdl/in-out; into jms endpoint -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-826) Add client for loan-broker-bpel
[ https://issues.apache.org/activemq/browse/SM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grégoire A. updated SM-826: --- Attachment: loan-broker.diff please get this diff, it includes all needs to add client for loan-broker-bpel Add client for loan-broker-bpel --- Key: SM-826 URL: https://issues.apache.org/activemq/browse/SM-826 Project: ServiceMix Issue Type: New Feature Components: servicemix-bpe Affects Versions: incubation Environment: all platforms Reporter: Grégoire A. Priority: Minor Fix For: 3.1 Attachments: JMSClientBPEL.java, loan-broker.diff Original Estimate: 30 minutes Remaining Estimate: 30 minutes add client test for loan-broker-bpel i add the class code, i should be work fine !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-826) Add client for loan-broker-bpel
[ https://issues.apache.org/activemq/browse/SM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38455 ] Grégoire A. commented on SM-826: the JMSClientBPEL.java file is now useless Add client for loan-broker-bpel --- Key: SM-826 URL: https://issues.apache.org/activemq/browse/SM-826 Project: ServiceMix Issue Type: New Feature Components: servicemix-bpe Affects Versions: incubation Environment: all platforms Reporter: Grégoire A. Priority: Minor Fix For: 3.1 Attachments: JMSClientBPEL.java, loan-broker.diff Original Estimate: 30 minutes Remaining Estimate: 30 minutes add client test for loan-broker-bpel i add the class code, i should be work fine !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-826) Add client for loan-broker-bpel
[ https://issues.apache.org/activemq/browse/SM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38104 ] Guillaume Nodet commented on SM-826: Could you provide a patch (svn diff) with all the necessary files needed to include this class and start it (and add a line to the README.txt to tell how to launch this class). Thanks ! Add client for loan-broker-bpel --- Key: SM-826 URL: https://issues.apache.org/activemq/browse/SM-826 Project: ServiceMix Issue Type: New Feature Components: servicemix-bpe Affects Versions: incubation Environment: all platforms Reporter: Grégoire A. Priority: Minor Fix For: 3.1 Attachments: JMSClientBPEL.java Original Estimate: 30 minutes Remaining Estimate: 30 minutes add client test for loan-broker-bpel i add the class code, i should be work fine !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-826) Add client for loan-broker-bpel
Add client for loan-broker-bpel --- Key: SM-826 URL: https://issues.apache.org/activemq/browse/SM-826 Project: ServiceMix Issue Type: New Feature Components: servicemix-bpe Affects Versions: incubation Environment: all platforms Reporter: Grégoire A. Priority: Minor Fix For: 3.1 Attachments: JMSClientBPEL.java add client test for loan-broker-bpel i add the class code, i should be work fine !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bpel example
The loan-broker-lw-su contains several lightweight components. One of them is a JmsServiceComponent which receives a JMS message posted by the client, route it to the bpel process and send back the response. The bpel process will call several other components (banks, credit agency) before sending back the response to the JmsServiceComponent. On 10/31/06, davipo [EMAIL PROTECTED] wrote: Hi everybody, I've seen the bpel-bpe example of servicemix 3.0 snapshot and it works fine... But i can't understand what is the role of ActiveMq. I know, tell me if i'm wrong, that the JMSClient class send a message on tcp port 61616 and then this message arrive to the bpel that manage it and send the response but the section beetween sending, by JMSClient, and receive, by bpel engine, is not so clear to me. So I think that ActiveMq has a role here but I don't know how. can someone explain me how does it works? thanks and excuse me for my english :) Davide -- View this message in context: http://www.nabble.com/Bpel-example-tf2546064.html#a7094634 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Bpel example
Hi everybody, I've seen the bpel-bpe example of servicemix 3.0 snapshot and it works fine... But i can't understand what is the role of ActiveMq. I know, tell me if i'm wrong, that the JMSClient class send a message on tcp port 61616 and then this message arrive to the bpel that manage it and send the response but the section beetween sending, by JMSClient, and receive, by bpel engine, is not so clear to me. So I think that ActiveMq has a role here but I don't know how. can someone explain me how does it works? thanks and excuse me for my english :) Davide -- View this message in context: http://www.nabble.com/Bpel-example-tf2546064.html#a7094634 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: BPEL
Hi Guillaume, thank you for the explaining.But I have one more question to make I've seen the bpel-bpe example of servicemix 3.0 snapshot and it works fine... But i can't understand what is the role of ActiveMq. I know, tell me if i'm wrong, that the JMSClient class send a message on tcp port 61616 and then this message arrive to the bpel that manage it and send the response but the section beetween sending, by JMSClient, and receive, by bpel engine, is not so clear to me. So I think that ActiveMq has a role here but I don't know how. can you explain me how does it works? thank you and excuse to me for my english :) Davide -- View this message in context: http://www.nabble.com/BPEL-tf2514159.html#a7031698 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
BPEL
Hi everybody, I have only one question to make. There's someone who can explain to me what are, if there are, the differences between PXE and BPE bpel Engines. Thanks Davide -- View this message in context: http://www.nabble.com/BPEL-tf2514159.html#a7011746 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: BPEL
PXE and BPE are two different bpel engines. They have both merged into the Apache Ode project which now provides its own JBI component. See http://incubator.apache.org/ode/ On 10/26/06, davipo [EMAIL PROTECTED] wrote: Hi everybody, I have only one question to make. There's someone who can explain to me what are, if there are, the differences between PXE and BPE bpel Engines. Thanks Davide -- View this message in context: http://www.nabble.com/BPEL-tf2514159.html#a7011746 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
[jira] Resolved: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=all ] Guillaume Nodet resolved SM-526. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Sun Aug 13 23:45:09 2006 New Revision: 431301 URL: http://svn.apache.org/viewvc?rev=431301view=rev Log: SM-526: Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL Modified: incubator/servicemix/trunk/servicemix-bpe/src/main/java/org/apache/servicemix/bpe/external/JbiInvokeAction.java Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Assigned To: Guillaume Nodet Fix For: 3.0-M3 Attachments: JbiInvokeAction.java.patch Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Tests are failing for the BPEL component
Tests are failing for the BPEL component!! (mvn test) --- Test set: org.apache.servicemix.bpe.BPEComponentTest --- Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.859 sec FAILURE! testWithHttp(org.apache.servicemix.bpe.BPEComponentTest) Time elapsed: 0.843 sec ERROR! java.lang.NoClassDefFoundError: javax/servlet/ServletRequest at org.apache.servicemix.http.HttpEndpoint.createConsumerProcessor(HttpEndpoint.java:239) at org.apache.servicemix.soap.SoapEndpoint.activate(SoapEndpoint.java:344) at org.apache.servicemix.common.ServiceUnit.start(ServiceUnit.java:50) at org.apache.servicemix.http.HttpSpringComponent$LifeCycle.doStart(HttpSpringComponent.java:93) at org.apache.servicemix.common.AsyncBaseLifeCycle.start(AsyncBaseLifeCycle.java:199) at org.apache.servicemix.jbi.framework.ComponentMBeanImpl.doStart(ComponentMBeanImpl.java:289) at org.apache.servicemix.jbi.framework.ComponentRegistry.setInitialRunningStateFromStart(ComponentRegistry.java:157) at org.apache.servicemix.jbi.framework.ComponentRegistry.start(ComponentRegistry.java:74) at org.apache.servicemix.jbi.framework.Registry.start(Registry.java:119) at org.apache.servicemix.jbi.container.JBIContainer.start(JBIContainer.java:559) at org.apache.servicemix.bpe.BPEComponentTest.testWithHttp(BPEComponentTest.java:108)
[jira] Commented: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36762 ] Guillaume Nodet commented on SM-526: Is this patch ok to apply ? Your last comment seens to indicate it was not ready ... Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=all ] Grant McDonald updated SM-526: -- Description: When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. was: When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: JbiInvokeAction.java.patch Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36757 ] Guillaume Nodet commented on SM-526: Thx. When you launch the command from the root dir, the patch file will include the path informations. This is much easier to apply as you only need to apply one patch file. Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36753 ] Guillaume Nodet commented on SM-526: Could you please use the 'svn diff' command to create patches ? They are much easier to work with :) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36755 ] Grant McDonald commented on SM-526: --- The patch in the zip file was created using the svn diff command, but I put it in the zip to preserve the path information. I guess the command should have just been issued from the ServiceMix root directory :) I'll do that next time instead. Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
executing BPEL-bpe from Spring
Hi. I would be glad to get a short example of how to execute a simple bpel-bpe flow directly from Spring (without using servicmix.bat). Thanks. -- View this message in context: http://www.nabble.com/executing-BPEL-bpe-from-Spring-tf1895485.html#a5183888 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: src for BPEL-Example
Thanks! I've checked that. -- View this message in context: http://www.nabble.com/src-for-BPEL-Example-t1791958.html#a4934663 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: src for BPEL-Example
On 6/15/06, manuella [EMAIL PROTECTED] wrote: I'm interested in BPEL-Example. And I want to read the source of it. Does anyone know, where I can find it? Thanks! Manuella, The source for the Loan Broker BPEL example is available in the ServiceMix source code. Information on checking out the source code is available here: http://servicemix.org/site/source.html Follow the information about anonymous SVN access. If you're not interested in checking out all of the source code, the Loan Broker example can be browsed here: http://svn.apache.org/viewvc/incubator/servicemix/trunk/incubating-apache-servicemix/src/main/release/examples/loan-broker/ Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: src for BPEL-Example
On 6/15/06, Bruce Snyder [EMAIL PROTECTED] wrote: On 6/15/06, manuella [EMAIL PROTECTED] wrote: I'm interested in BPEL-Example. And I want to read the source of it. Does anyone know, where I can find it? Thanks! Manuella, My apologies, please disregard what I said in my previous message, I just gave you the wrong information :-(. The source for the BPEL example is in the servicemix-bpe component and can be browsed here: http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-bpe/ Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
src for BPEL-Example
I'm interested in BPEL-Example. And I want to read the source of it. Does anyone know, where I can find it? Thanks! -- View this message in context: http://www.nabble.com/src-for-BPEL-Example-t1791958.html#a4882119 Sent from the ServiceMix - Dev forum at Nabble.com.
example bpel error
I have tried to run the BPEL Example on servicemix-2.0.2. This example doesn't work... This is the error message: D:\Program Files\servicemix-2.0.2\assembly\target\servicemix-2.0.2\bin\servicemi x-2.0.2\examples\bpelservicemix servicemix.xml ServiceMix ESB: 2.0.2 Loading ServiceMix from file: servicemix.xml 12:07:42,082 INFO [JournalPersistenceAdapter] Opening journal. 12:07:42,272 INFO [JournalPersistenceAdapter] Opened journal: Active Journal: u sing 2 x 20.0 Megs at: ..\var\journal 12:07:42,272 INFO [JournalPersistenceAdapter] Journal Recovery Started. 12:07:42,392 INFO [JournalPersistenceAdapter] Journal Recovered: 0 message(s) i n transactions recovered. 4-mag-2006 12.07.57 com.fs.pxe.jbi.PxeBootstrap onInstall INFO: onInstall method has been called 4-mag-2006 12.07.58 com.fs.pxe.jbi.PxeLifeCycle init INFO: Transaction Manager bound. 4-mag-2006 12.08.06 com.fs.pxe.jbi.PxeLifeCycle init INFO: Hibernate started. 4-mag-2006 12.08.06 com.fs.pxe.jbi.PxeLifeCycle init INFO: Initialized. 4-mag-2006 12.08.06 com.fs.pxe.jbi.PxeLifeCycle start INFO: Starting PXE. 12:08:07,353 ERROR [ModSfwkMBean] Unable to start RMI transport (server-side). java.rmi.ServerException: RemoteException occurred in server thread; nested exce ption is: java.rmi.UnmarshalException: error unmarshalling arguments; nested excep tion is: java.net.MalformedURLException: no protocol: Files/servicemix-2.0.2/asse mbly/target/servicemix-2.0.2/bin/servicemix-2.0.2/examples/bpel/./wdir/defaultJB I/components/PxeBpelEngine/installation/lib/backport-util-concurrent-2.0_01.jar at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:385 ) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:240) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4 60) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport .java:701) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Stream RemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java: 223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343) ... . ... -- View this message in context: http://www.nabble.com/example-bpel-error-t1555887.html#a4226309 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: example bpel error
PXE integration is broken. You may want to look at servicemix-bpe in the meantime (available in 3.0 distributions) Cheers, Guillaume Nodet On 5/4/06, emicalc [EMAIL PROTECTED] wrote: I have tried to run the BPEL Example on servicemix-2.0.2. This example doesn't work... This is the error message: D:\Program Files\servicemix-2.0.2\assembly\target\servicemix-2.0.2\bin\servicemi x-2.0.2\examples\bpelservicemix servicemix.xml ServiceMix ESB: 2.0.2 Loading ServiceMix from file: servicemix.xml 12:07:42,082 INFO [JournalPersistenceAdapter] Opening journal. 12:07:42,272 INFO [JournalPersistenceAdapter] Opened journal: Active Journal: u sing 2 x 20.0 Megs at: ..\var\journal 12:07:42,272 INFO [JournalPersistenceAdapter] Journal Recovery Started. 12:07:42,392 INFO [JournalPersistenceAdapter] Journal Recovered: 0 message(s) i n transactions recovered. 4-mag-2006 12.07.57 com.fs.pxe.jbi.PxeBootstrap onInstall INFO: onInstall method has been called 4-mag-2006 12.07.58 com.fs.pxe.jbi.PxeLifeCycle init INFO: Transaction Manager bound. 4-mag-2006 12.08.06 com.fs.pxe.jbi.PxeLifeCycle init INFO: Hibernate started. 4-mag-2006 12.08.06 com.fs.pxe.jbi.PxeLifeCycle init INFO: Initialized. 4-mag-2006 12.08.06 com.fs.pxe.jbi.PxeLifeCycle start INFO: Starting PXE. 12:08:07,353 ERROR [ModSfwkMBean] Unable to start RMI transport (server-side). java.rmi.ServerException: RemoteException occurred in server thread; nested exce ption is: java.rmi.UnmarshalException: error unmarshalling arguments; nested excep tion is: java.net.MalformedURLException: no protocol: Files/servicemix-2.0.2/asse mbly/target/servicemix-2.0.2/bin/servicemix-2.0.2/examples/bpel/./wdir/defaultJB I/components/PxeBpelEngine/installation/lib/backport-util-concurrent-2.0_01.jar at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:385 ) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:240) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4 60) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport .java:701) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Stream RemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java: 223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343) ... . ... -- View this message in context: http://www.nabble.com/example-bpel-error-t1555887.html#a4226309 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Ode Proposal (Sybase BPEL engine donation))
On 15 Feb 2006, at 16:31, Sanjiva Weerawarana wrote: On Wed, 2006-02-15 at 15:56 +, James Strachan wrote: Dims Sanjiva Given your arguments that the Sybase BPEL donation should be in a new podling rather than part of ServiceMix - I wonder if you'd like to join us in the ODE proposal then we can have a united Apache community with folks from Agila, Geronimo, ServiceMix, WS involved to insure plenty of cross pollination. Wow I feel special to get asked liked this ;-). I was going to ask to join anyway .. so I'll be happy to. Great! :) However, I would like to request some changes: - Under warning signs, in the Homogenous developers category it lists developers from Sybase, IBM LogicBlaze. Is it the case that the *current* codebase has contribs from all these companies? If not I believe the spirit of the question is about the current codebase, not about the group that'll get it thru incubation. So please indicate who wrote the current codebase (which I believe is all Synbase). Good point - fixed. - The initial committers list is very long. I'm on service-mix dev and I see only 2-3 people committing Have you tried looking at the SVN logs? The codebase has only been in the incubator for 2 months and 12 folks have been hacking the code furiously (and we're still waiting for karma for a couple more committers). (and little or no discussion; am I missing some stuff??). Maybe you're email filters are hiding email? There's a fair amount of discussion... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200602.mbox/thread http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200601.mbox/thread http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200512.mbox/thread There's plenty of background chatter on IRC too if you need more chat (though important decisions and votes always take place via email) Can we try to list people who are really going to write code for this? It doesn't make sense to list *23* committers unless they will really write code. They will. We can always bring people on board as they start contributing. If all these people are really so hot to mess with a BPEL impl, damn, I should feel really good about BPEL ;-). You should as they are. The people listed who are servicemix committers have committed substantial code already to ServiceMix and are keen to work on the integration of BPEL + ServiceMix along with enhancing the core BPEL engine (such as the management persistence piece). The Sybase folks wrote the original code and the Agila committer is the guy who wrote all the BPEL code in Agila - so far I'm happy with the committer list. - Given the, um, strong feelings expressed by so many people about this project, how about if we get the Incubator PMC to sponsor this poddling? Why does the sponsor PMC make any difference to whether the BPEL engine goes top level or not? e.g. Tuscany is sponsored by WS and is gonna be a TLP? Given the Geronimo PMC did vote to accept the patch into ServiceMix (though given the general sentiment to use a separate podling we've backed off), we'd rather stick to the same sponsor PMC for the moment. James --- http://radio.weblogs.com/0112098/
Re: Ode Proposal (Sybase BPEL engine donation))
Dims Sanjiva Given your arguments that the Sybase BPEL donation should be in a new podling rather than part of ServiceMix - I wonder if you'd like to join us in the ODE proposal then we can have a united Apache community with folks from Agila, Geronimo, ServiceMix, WS involved to insure plenty of cross pollination. http://wiki.apache.org/incubator/OdeProposa James Begin forwarded message: From: Alan D. Cabrera [EMAIL PROTECTED] Date: 14 February 2006 07:35:33 GMT To: dev@geronimo.apache.org, general@incubator.apache.org, servicemix-dev@geronimo.apache.org Subject: Ode Proposal Reply-To: general@incubator.apache.org Ok. Here's the proposal http://wiki.apache.org/incubator/ OdeProposal. Please feel free to comment. We need some more mentors. Anyone? James --- http://radio.weblogs.com/0112098/
Re: Ode Proposal (Sybase BPEL engine donation))
On Wed, 2006-02-15 at 15:56 +, James Strachan wrote: Dims Sanjiva Given your arguments that the Sybase BPEL donation should be in a new podling rather than part of ServiceMix - I wonder if you'd like to join us in the ODE proposal then we can have a united Apache community with folks from Agila, Geronimo, ServiceMix, WS involved to insure plenty of cross pollination. Wow I feel special to get asked liked this ;-). I was going to ask to join anyway .. so I'll be happy to. However, I would like to request some changes: - Under warning signs, in the Homogenous developers category it lists developers from Sybase, IBM LogicBlaze. Is it the case that the *current* codebase has contribs from all these companies? If not I believe the spirit of the question is about the current codebase, not about the group that'll get it thru incubation. So please indicate who wrote the current codebase (which I believe is all Synbase). - The initial committers list is very long. I'm on service-mix dev and I see only 2-3 people committing (and little or no discussion; am I missing some stuff??). Can we try to list people who are really going to write code for this? It doesn't make sense to list *23* committers unless they will really write code. We can always bring people on board as they start contributing. If all these people are really so hot to mess with a BPEL impl, damn, I should feel really good about BPEL ;-). - Given the, um, strong feelings expressed by so many people about this project, how about if we get the Incubator PMC to sponsor this poddling? I'm a member of that PMC and I'll be happy to do it. That allows the poddling to decide, upon graduation, its final resting place: Geronimo, new TLP or elsewhere. (NO, I'm not even suggesting it go to WS .. as I said earlier, WS is too damned crowded already.) I see *nothing* to be gained by saying its going to be part of Geronimo at this point; so you see my bias already: go for its own TLP. However, if that appears to be the right thing upon graduation, then so be it. Note that this does not preclude ServiceMix, or *anyone else* from embracing and extending Apache Ode and living happily ever after. In fact, its *much better* for Apache Ode to be on its own because then its likely to be pluggable to more container frameworks and not just Geronimo/ServiceMix. Bye, Sanjiva.
Re: Ode Proposal (Sybase BPEL engine donation))
James, Thanks for taking the first step. Yes, please add me in as a mentor. Here's some feedback first about the proposal before we take the next step. - AFAIK, Geronimo PMC has not voted on this proposal. So can we please get Incubator PMC to sponsor this? - Can we please put out a call to other Open source BPEL engines to join us with their contributions? (ala, Synapse). - Can we please add people in a phased manner as committers? based on their patches/energy on the list? (ala, Harmony) Thanks, dims On 2/15/06, James Strachan [EMAIL PROTECTED] wrote: Dims Sanjiva Given your arguments that the Sybase BPEL donation should be in a new podling rather than part of ServiceMix - I wonder if you'd like to join us in the ODE proposal then we can have a united Apache community with folks from Agila, Geronimo, ServiceMix, WS involved to insure plenty of cross pollination. http://wiki.apache.org/incubator/OdeProposa James Begin forwarded message: From: Alan D. Cabrera [EMAIL PROTECTED] Date: 14 February 2006 07:35:33 GMT To: dev@geronimo.apache.org, general@incubator.apache.org, servicemix-dev@geronimo.apache.org Subject: Ode Proposal Reply-To: general@incubator.apache.org Ok. Here's the proposal http://wiki.apache.org/incubator/ OdeProposal. Please feel free to comment. We need some more mentors. Anyone? James --- http://radio.weblogs.com/0112098/ -- Davanum Srinivas : http://wso2.com/blogs/
Re: Ode Proposal (Sybase BPEL engine donation))
On 15 Feb 2006, at 16:31, Sanjiva Weerawarana wrote: On Wed, 2006-02-15 at 15:56 +, James Strachan wrote: Dims Sanjiva Given your arguments that the Sybase BPEL donation should be in a new podling rather than part of ServiceMix - I wonder if you'd like to join us in the ODE proposal then we can have a united Apache community with folks from Agila, Geronimo, ServiceMix, WS involved to insure plenty of cross pollination. Wow I feel special to get asked liked this ;-). I was going to ask to join anyway .. so I'll be happy to. Great! :) However, I would like to request some changes: - Under warning signs, in the Homogenous developers category it lists developers from Sybase, IBM LogicBlaze. Is it the case that the *current* codebase has contribs from all these companies? If not I believe the spirit of the question is about the current codebase, not about the group that'll get it thru incubation. So please indicate who wrote the current codebase (which I believe is all Synbase). Good point - fixed. - The initial committers list is very long. I'm on service-mix dev and I see only 2-3 people committing Have you tried looking at the SVN logs? The codebase has only been in the incubator for 2 months and 12 folks have been hacking the code furiously (and we're still waiting for karma for a couple more committers). (and little or no discussion; am I missing some stuff??). Maybe you're email filters are hiding email? There's a fair amount of discussion... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200602.mbox/thread http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200601.mbox/thread http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200512.mbox/thread There's plenty of background chatter on IRC too if you need more chat (though important decisions and votes always take place via email) Can we try to list people who are really going to write code for this? It doesn't make sense to list *23* committers unless they will really write code. They will. We can always bring people on board as they start contributing. If all these people are really so hot to mess with a BPEL impl, damn, I should feel really good about BPEL ;-). You should as they are. The people listed who are servicemix committers have committed substantial code already to ServiceMix and are keen to work on the integration of BPEL + ServiceMix along with enhancing the core BPEL engine (such as the management persistence piece). The Sybase folks wrote the original code and the Agila committer is the guy who wrote all the BPEL code in Agila - so far I'm happy with the committer list. - Given the, um, strong feelings expressed by so many people about this project, how about if we get the Incubator PMC to sponsor this poddling? Why does the sponsor PMC make any difference to whether the BPEL engine goes top level or not? e.g. Tuscany is sponsored by WS and is gonna be a TLP? Given the Geronimo PMC did vote to accept the patch into ServiceMix (though given the general sentiment to use a separate podling we've backed off), we'd rather stick to the same sponsor PMC for the moment. James --- http://radio.weblogs.com/0112098/
Re: Ode Proposal (Sybase BPEL engine donation))
On 15 Feb 2006, at 16:54, Davanum Srinivas wrote: James, Thanks for taking the first step. Yes, please add me in as a mentor. Here's some feedback first about the proposal before we take the next step. - AFAIK, Geronimo PMC has not voted on this proposal. We kinda voted already on G-PMC but the new proposal changes things slightly (being a new podling) so to clear things up I've called another vote. - Can we please put out a call to other Open source BPEL engines to join us with their contributions? (ala, Synapse). Sure, we're open to other contributions and contributors from wherever; they can arrive at any time - lets starting incubating - Can we please add people in a phased manner as committers? based on their patches/energy on the list? (ala, Harmony) All the folks on the committer list are folks who've expressed interest in working on the code. The only non-apache committers so far are the Sybase folks who've written all the code being contributed; the rest are already proven committers in Agila, Geronimo or ServiceMix James --- http://radio.weblogs.com/0112098/
Re: Ode Proposal (Sybase BPEL engine donation))
On Feb 15, 2006, at 3:09 PM, Noel J. Bergman wrote: Sanjiva, - Given the, um, strong feelings expressed by so many people about this project, how about if we get the Incubator PMC to sponsor this poddling? Agreed. That is what I said to the Geronimo PMC, as well. The Incubator PMC will sponsor the project. Since you brought this public, I'll post my response along with you original email. I hope you don't mind... On Feb 15, 2006, at 1:25 PM, Noel J. Bergman wrote: No need for this vote. The Incubator PMC will sponsor the project. --- Noel I know it doesn't mean much, but I personally would like to see this as a Geronimo sponsored project. We are the ones that have taken the licks over this for the past 2 weeks and would really like to work to carry this through the full process. So to flip things around on you... There is no need for the Incubator PMC to sponsor. The Geronimo PMC will sponsor the project. Thanks for your understanding. -dain
Re: Ode Proposal (Sybase BPEL engine donation))
[trimmed individuals and pmc's from the cc: list] On Wed, Feb 15, 2006 at 03:22:23PM -0800, Dain Sundstrom wrote: On Feb 15, 2006, at 3:09 PM, Noel J. Bergman wrote: Sanjiva, - Given the, um, strong feelings expressed by so many people about this project, how about if we get the Incubator PMC to sponsor this poddling? Agreed. That is what I said to the Geronimo PMC, as well. The Incubator PMC will sponsor the project. ... I know it doesn't mean much, but I personally would like to see this as a Geronimo sponsored project. We are the ones that have taken the licks over this for the past 2 weeks and would really like to work to carry this through the full process. So to flip things around on you... There is no need for the Incubator PMC to sponsor. The Geronimo PMC will sponsor the project. Thanks for your understanding. A number of folks here in the Incubator believe it is best to establish a community with no prior ties, and have repeated that on a number of occasions (including Sanjiva's and Noel's comments today). The general belief is that this will create a better community around the ASF's BPEL work. Part of the problem that I'm seeing is you use of we in your message. Who is we? And that leads to, who is not we? Why is there a partition? I believe this is one of the primary issues that is being dealt with right now, Dain. You are dividing BPEL workers into a we and others camp. Or, let's just say that was a random term to refer to the Geronimo project and you're not really seeing two groups. i.e. not fair of me to assign that way of thinking to you. Okay. So moving on: why is it important for this to be Geronimo sponsored? Why? Seriously. WTF does it matter? We've already said the IP clearance paperwork is the same no matter what. Great. Get that done and start working. When BPEL is ready to graduate, then we look at where it goes. Quite possibly Geronimo. But what does it matter that Geronimo is the sponsor? Why are you so keyed in on that? I can clearly see benefits with absence of ties. I don't see the benefit of Geronimo sponsoring that you're seeing. And without that understanding, then I get to make up crazy reasons :-P Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Ode Proposal (Sybase BPEL engine donation))
On 2/15/06, Greg Stein [EMAIL PROTECTED] wrote: A number of folks here in the Incubator believe it is best to establish a community with no prior ties, and have repeated that on a number of occasions (including Sanjiva's and Noel's comments today). The general belief is that this will create a better community around the ASF's BPEL work. Greg, I'm trying to understand the statements above. The more I read them the more it seems that the Incubator PMC can decide what's best for a proposal at any given time including making decisions about the oversight. Are there documents about this topic on the Incubator site that I've missed? I truly want to understand this and I'd appreciate any further explanation or identification of any documents that clarifies this issue. Part of the problem that I'm seeing is you use of we in your message. Who is we? And that leads to, who is not we? Why is there a partition? I believe this is one of the primary issues that is being dealt with right now, Dain. You are dividing BPEL workers into a we and others camp. Or, let's just say that was a random term to refer to the Geronimo project and you're not really seeing two groups. i.e. not fair of me to assign that way of thinking to you. Okay. So moving on: why is it important for this to be Geronimo sponsored? Why? Seriously. WTF does it matter? We've already said the IP clearance paperwork is the same no matter what. Great. Get that done and start working. When BPEL is ready to graduate, then we look at where it goes. Quite possibly Geronimo. But what does it matter that Geronimo is the sponsor? Why are you so keyed in on that? I can clearly see benefits with absence of ties. I don't see the benefit of Geronimo sponsoring that you're seeing. And without that understanding, then I get to make up crazy reasons :-P And the statements above aren't helping me understand this any further. Can you help clarify this for me please? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
RE: Ode Proposal (Sybase BPEL engine donation))
Sanjiva, - Given the, um, strong feelings expressed by so many people about this project, how about if we get the Incubator PMC to sponsor this poddling? Agreed. That is what I said to the Geronimo PMC, as well. The Incubator PMC will sponsor the project. --- Noel
Re: BPEL contribution from Sybase
On 14 Feb 2006, at 01:25, Noel J. Bergman wrote: Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. If every JBI implementation has an integrated orchestration engine, then we should factor out the orchestration engine. Furthermore, as per the JBI Specification, Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. Agreed So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), Its not. You can use ServiceMix inside Geronimo, J2EE or J2SE. JBI should be available separately. It is, inside the ServiceMix project. James --- http://radio.weblogs.com/0112098/
BPEL contribution from Sybase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor will be welcomed by the ServiceMix community (as required by the apache way), and *if* a large community develops that wants to split off later they can (as is allowed by the apache process). Right now, I don't see this large community; all I do see is a few very grumpy individuals. If the webservice project really really want to control this code, they can always fork it (as is allowed by the apache process). So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. -dain On Feb 13, 2006, at 12:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
I agree with Dain; let's get the code running in ServiceMix, and then we can break it off when it's ready to stand alone. Thanks, Aaron On 2/13/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor will be welcomed by the ServiceMix community (as required by the apache way), and *if* a large community develops that wants to split off later they can (as is allowed by the apache process). Right now, I don't see this large community; all I do see is a few very grumpy individuals. If the webservice project really really want to control this code, they can always fork it (as is allowed by the apache process). So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. -dain On Feb 13, 2006, at 12:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
After a quick chat with Dims, I think I need to make a quick correction to this email On Feb 13, 2006, at 12:42 PM, Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor will be welcomed by the ServiceMix community (as required by the apache way), and *if* a large community develops that wants to split off later they can (as is allowed by the apache process). Right now, I don't see this large community; all I do see is a few very grumpy individuals. If the webservice project really really want to control this code, they can always fork it (as is allowed by the apache process). I picked up on Ken's comments about having a TLP devoted to Web Services and I should not have picked on the Web Services, instead I think my point is made more clear by replacing the last line with: If any project inside or outside of Apache wants their own copy of this code to develop they can always fork the code (as is allowed by any open source project). I apologies to Dims and the Web Services project for dragging them back into this debate as they have clearly tried to remove themselves. Sorry, -dain So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. -dain On Feb 13, 2006, at 12:21 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After re-reading all the discussion threads and getting some technology education from people kind enough not to bash me on the bonce, my strong recommendation is that the Sybase contribution be made as a new podling proposal to the incubator. That's after also considering the following: 1. The full expanded name of BPEL is 'Business Process Execution Language for Web Services;' 2. We have a TLP devoted to Web Services; and 3. A BPEL engine would be a component useful to a broader range of projects that just Geronimo. It just doesn't make sense to me to embed this into ServiceMix, which is intended to be embedded into the Geronimo project. The issues about who wants to work on it and their current distribution through ASF projects (namely, the claim that most of them are already working on the ServiceMix package) I don't see as being particularly relevant. Having the BPEL effort outside of ServiceMix is a better solution, IMHO, because 1. There's no barrier to ServiceMix people working on it; 2. There's less chance of accidental too-tight binding to the ServiceMix/Geronimo packages; 3. People working on it will see just messages relating to it, and not a bunch of UNrelated mail as well. That last one is pretty important, I think. I suspect that people from outside ServiceMix would be a bit daunted or put off at having to deal with the flux of ServiceMix-specific mail in order to see the BPEL-related messages which might be their sole interest. So: My recommendation is that a new proposal be drafted, and Sybase's BPEL contribution be subnmitted to the incubator as a new standalone podling. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/DqMZrNPMCpn3XdAQI3EwP6Aj+Rlg5+8c4HwNm9rfN/PlCnN0QwDLu+ vCEYIZy7YsHQ0fr/7TNuN5Xn1M+xFtvhw4v4HMrVHhUYLnToyDtob/uyyIrcLpZR 1yH3krVSarHJobtoAiGh/Z9VBvIU/deGNqR7tpfL/3RvtG26HQlTiR/4tRXNCZbY a1xVRt2c34g= =ge/u -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
On Mon, Feb 13, 2006 at 12:42:58PM -0800, Dain Sundstrom wrote: ... Sybase wants to donate to the service-mix community and the ServiceMix community wants to work with the code. Any contributor It should be donate to APACHE. The various people can come to it. To be frank, some communities can bias against newcomers. That isn't right for the ASF, and it *absolutely* is not write for podling communities within the Incubator. This doesn't apply to just BPEL. I had the same reaction to the recent Ajax proposals. oh, sure, Dojo can come and join this new community. Right. They'll feel like outsiders right from the start. Euh. We have some code? Yah, I know you have some, but will you look at ours? Bah. This isn't about control, this is about inclusivity. Targeting one group of folks (... to the service-mix community ...) over another is exclusion, not inclusion. Cheers, -g -- Greg Stein, http://www.lyra.org/
RE: BPEL contribution from Sybase
Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. If every JBI implementation has an integrated orchestration engine, then we should factor out the orchestration engine. Furthermore, as per the JBI Specification, Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), JBI should be available separately. Also, we already have two engines in the Incubator, with two more pending, so we may have three implementations of BPEL. I would expect to see at least one of them close down, and would like to see the orchestration communities merge, if possible. I've heard nothing to provide a reason for not bringing in the contribution as a standalone podling, which ServiceMix and others can consume. This would be in accord with Ken and Mads. On a related note, I believe that we need to evaluate projects for graduation based in part on how well the community collaborates with other ASF projects, and become part of the ASF community. I don't consider ghettos to be healthy for the ASF, no matter how internally successful. --- Noel
Re: BPEL contribution from Sybase
After being nervous for quite a while I have come to think that the sybase bpel engine should go in as part of servicemix and if further uses outside servicemix develop we can see about splitting it off. more comments inline. On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote: Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. If every JBI implementation has an integrated orchestration engine, then we should factor out the orchestration engine. Furthermore, as per the JBI Specification, Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), JBI should be available separately. To me this appears to assume that the interface between the orchestration engine and the JBI container is well defined and all parties agree on it. I haven't heard any claims that this is the case, although I'm still completely unfamiliar with the subject. Also, we already have two engines in the Incubator, with two more pending, so we may have three implementations of BPEL. I would expect to see at least one of them close down, and would like to see the orchestration communities merge, if possible. This appears to me to be a strong indication that BPEL engines cannot live an independent life and that we should try one as part of another project such as servicemix. If the BPEL part of the servicemix community turns out to be big vibrant and wanting its own project, all the better. If not, servicemix gets a component it needs. I've heard nothing to provide a reason for not bringing in the contribution as a standalone podling, which ServiceMix and others can consume. This would be in accord with Ken and Mads. Through all this I don't think I've seen anyone actually say they want to work on the code other than servicemix people. (If I've missed anyone I apologize). It's been on the table a rather long time for that not to mean that there isn't much interest outside servicemix for actually working on it. The incubation process is not a trivial amount of work and having 2 podlings rather than one pretty nearly doubles a good deal of it IMO. Since the original request was to be a part of servicemix, and AFAICT no one outside that group has said they want to work on the project over the last x weeks of stewing, what exactly can we gain by forcing a decision on this group of people who want to work together? On a related note, I believe that we need to evaluate projects for graduation based in part on how well the community collaborates with other ASF projects, and become part of the ASF community. I don't consider ghettos to be healthy for the ASF, no matter how internally successful. After looking at this for a while I don't have any idea what you mean. Could you provide some concrete examples of projects that should not have graduated based on this criterion and pre-incubator projects that would not graduate had they gone through incubation? While this appears at first to be a very nice idea I can't see any way it could mean anything but stifling innovation. I hope you can clarify what you mean. thanks david jencks --- Noel
Re: BPEL contribution from Sybase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. I am not worried about barriers to any committers, accidental too-tight binding or UNrelated mail on mailing lists. All of these issues are worked out every day on mailing lists at Apache. I am much more worried about this donation falling into Apache politics that result in a sausage project that no one wants to eat. IMHO, it's being *pushed* into 'Apache politics.' If it's worthwhile, it will survive wherever it goes. Coming in as a standalone podling will be a measure of its worth. If it can't get enough momentum that way, why do you think it would get any more as part of ServiceMix? If it wouldn't get the momentum standalone, then I think it's much more likely that being embedded into ServiceMix would result in a bolus of legacy code. An inedible and unremovable sausage in a larger sandwich. Sybase wants to donate to the service-mix community In other words, they *don't* want to contribute it to Apache. They want it to go into a specific and particular niche *at* Apache. Why the specificity? Why does Sybase care where it goes? and the ServiceMix community wants to work with the code. A BPEL podling would not be an obstacle to that. Any contributor will be welcomed by the ServiceMix community But if BPEL is all they wanted to work on, they wouldn't be *part* of the ServiceMix community. Right now, I don't see this large community; all I do see is a few very grumpy individuals. Such as whom? *I* see an enormous pressure to bring this into ServiceMix, and a good bit of grumpiness that anyone would have the temerity to opine that there might be a better approach. Since you were replying to my message, which recommended against bringing BPEL into ServiceMix, I infer that I'm one of these 'very grumpy individuals.' Why am I grumpy? What am I grumpy about? You said it, so please tell me what you meant. If the webservice project really really want to control this code, Who said anything about WS 'controlling' the code? I commented that 'Web Services' is part of BPEL's name, and we already have a bunch of people and an effort dedicated to that specific topic. I don't see 'J2EE' in the BPEL name; I *do* see 'Web Services.' So: My recommendation is that the donation be accepted directly into ServiceMix and we all move on to more important issues. The amount of opinion diversity on this issue makes it clear that it's quite important enough on its own, and in fact is *not* a simple thing to 'just do.' - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/FDyJrNPMCpn3XdAQLjXQP/URqbW5Qmtirvt9HSdQJWQByRBzh4wV+Q OrV38DhewUtdUmsjQNvYenkPs9odbacP1Op79ZIkh6EiM0hnwIwnfLPfklDUrp+S fmfRuNmHH4N6fSh7PFK28Zh6GlY/MXpgdI2XDh7n9JGcGBNHTI4kq+YmAsJH/tFr ZnURkBQkRIY= =s2ms -END PGP SIGNATURE-
Re: BPEL contribution from Sybase
I'd like to retract this email. I have doubts on both sides of this and may try to explain them in a clearer way in another message. My apologies david jencks On Feb 13, 2006, at 6:26 PM, David Jencks wrote: After being nervous for quite a while I have come to think that the sybase bpel engine should go in as part of servicemix and if further uses outside servicemix develop we can see about splitting it off. more comments inline. On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote: Dain Sundstrom wrote: I think ServiceMix is the perfect home for a BPEL engine. Every JBI implementation that I am aware of has and integrated orchestration engine exposed via the BPEL specification. If every JBI implementation has an integrated orchestration engine, then we should factor out the orchestration engine. Furthermore, as per the JBI Specification, Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group. JBI is applicable outside the context of J2EE. So if ServiceMix is intended to be embedded exclusively in Geronimo (the subject of a whole other discussion), JBI should be available separately. To me this appears to assume that the interface between the orchestration engine and the JBI container is well defined and all parties agree on it. I haven't heard any claims that this is the case, although I'm still completely unfamiliar with the subject. Also, we already have two engines in the Incubator, with two more pending, so we may have three implementations of BPEL. I would expect to see at least one of them close down, and would like to see the orchestration communities merge, if possible. This appears to me to be a strong indication that BPEL engines cannot live an independent life and that we should try one as part of another project such as servicemix. If the BPEL part of the servicemix community turns out to be big vibrant and wanting its own project, all the better. If not, servicemix gets a component it needs. I've heard nothing to provide a reason for not bringing in the contribution as a standalone podling, which ServiceMix and others can consume. This would be in accord with Ken and Mads. Through all this I don't think I've seen anyone actually say they want to work on the code other than servicemix people. (If I've missed anyone I apologize). It's been on the table a rather long time for that not to mean that there isn't much interest outside servicemix for actually working on it. The incubation process is not a trivial amount of work and having 2 podlings rather than one pretty nearly doubles a good deal of it IMO. Since the original request was to be a part of servicemix, and AFAICT no one outside that group has said they want to work on the project over the last x weeks of stewing, what exactly can we gain by forcing a decision on this group of people who want to work together? On a related note, I believe that we need to evaluate projects for graduation based in part on how well the community collaborates with other ASF projects, and become part of the ASF community. I don't consider ghettos to be healthy for the ASF, no matter how internally successful. After looking at this for a while I don't have any idea what you mean. Could you provide some concrete examples of projects that should not have graduated based on this criterion and pre-incubator projects that would not graduate had they gone through incubation? While this appears at first to be a very nice idea I can't see any way it could mean anything but stifling innovation. I hope you can clarify what you mean. thanks david jencks --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL contribution from Sybase
On 2/13/2006 6:43 PM, Rodent of Unusual Size wrote: Dain Sundstrom wrote: Sybase wants to donate to the service-mix community In other words, they *don't* want to contribute it to Apache. They want it to go into a specific and particular niche *at* Apache. Why the specificity? Why does Sybase care where it goes? I think that Sybase has or had an opinion as to where would be a nice place to start but is not married to it. I'm certain that they will be happy w/ what ever the community decides. Regards, Alan
