bpel-dev

Re: [bpel-dev] Simplify expression editors?

vincent.zurczak@xxxxxxx (Vincent Zurczak) — Tue, 22 May 2012 11:13:02 GMT

Hi,

I changed my mind, again.
I got back to my first idea, that is to say, rely on the XPath editor. But we must definitely drop the idea of embedding editors in a composite. This is a dead end. It is not intended for that.
To avoid spending too much time on it, I used a styled text with the XPath source viewer configuration. It means we won't have auto-completion and so on for the moment. But we have syntax highlighting, which is a poor first step.

As a user (I'm using this tool too), this is not good at all.
However, it should be possible to add context assistance in a second step. The reason why I can't do it right now is that it requires to refactor the XPath editor and externalize some internal classes (and I don't have time for this).
In a more general matter, I think all the XPath stuff should be externalized in a distinct plugin. It is not the first time I use the XPath source configuration, it goes beyond the scope of BPEL.

Then, we could have an extensibility mechanism based on source viewer configurations instead of editors.
I have no idea how this would impact XText editors.
I will push it in a distinct branch this afternoon.

Vincent.

Le 21/05/2012 20:39, Bob Brodt a écrit :

Hi Vincent,

Thanks for working on this. Before you leave, please drop me a quick email and let me know where we are with this - I can continue working on it and hopefully get a successful build again.

Bob

--
Vincent Zurczak

RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16

Re: [bpel-dev] Simplify expression editors?

bbrodt@xxxxxxx (Bob Brodt) — Mon, 21 May 2012 18:39:26 GMT

Hi Vincent,

Thanks for working on this. Before you leave, please drop me a quick email and let me know where we are with this - I can continue working on it and hopefully get a successful build again.

Bob

Hello,

I have tried the approach we discussed last week.
I have removed a lot of code to simply use the XText editor directly. But there is still a lot of work on it and I don't have that much time (in fact, I can only give it half a day more). And given all these changes, reintroducing the feature would cost a lot of time too. For Juno, I will try something else. I will try to fix just the part that has changed, even if it means using internal code from e4. It means this solution would only work with Juno and that we should have two different builds. This is really tough.

But as you said Bob, we must focus on Juno.
We will talk about merging or upgrading things later.

Regards,

Vincent.

Le 18/05/2012 02:25, Bob Brodt a Ãcrit :

Hi Francesco,

I understand your concern and we are working on rewriting this part of the code because it violates the "do not use internal classes" rule. However, we are committed to having the BPEL Designer ready for the Eclipse Juno release this summer, and this will probably mean that the initial release may not support this extension. This feature will probably be part of a Juno service release (BPEL Designer 1.0.1 maybe?) later this year. That said, it may be possible for us to provide a version of BPEL Designer compatible with Eclipse Indigo, which *does* include this feature.

Be assured that this extension point is not going away - it's simply being delayed a bit until we have some time to rewrite the underlying code. Please let us know if you have available resources to help with this effort! Please monitor https://bugs.eclipse.org/bugs/show_bug.cgi?id=378997 for details about this effort.

________________________
Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

Hi All,

we are using this extension point in a big project.

We have made an embedded editor implementation using Xtext to define a new _expression_ Language.

The bridge between the 2 projects is available on Eclipse Labs: http://code.google.com/a/eclipselabs.org/p/bpel-xtext/

We understand your needs but we would like to stay up to date.

So, if you are evaluating to put back this feature in the future, please note that it is a key feature for us.

We are also willing to help, if needed..

Thanks!

Francesco

--
Vincent Zurczak

RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev

Re: [bpel-dev] Simplify expression editors?

vincent.zurczak@xxxxxxx (Vincent Zurczak) — Mon, 21 May 2012 12:38:04 GMT

Hello,

I have tried the approach we discussed last week.
I have removed a lot of code to simply use the XText editor directly. But there is still a lot of work on it and I don't have that much time (in fact, I can only give it half a day more). And given all these changes, reintroducing the feature would cost a lot of time too. For Juno, I will try something else. I will try to fix just the part that has changed, even if it means using internal code from e4. It means this solution would only work with Juno and that we should have two different builds. This is really tough.

But as you said Bob, we must focus on Juno.
We will talk about merging or upgrading things later.

Regards,

Vincent.

Le 18/05/2012 02:25, Bob Brodt a écrit :

Hi Francesco,

I understand your concern and we are working on rewriting this part of the code because it violates the "do not use internal classes" rule. However, we are committed to having the BPEL Designer ready for the Eclipse Juno release this summer, and this will probably mean that the initial release may not support this extension. This feature will probably be part of a Juno service release (BPEL Designer 1.0.1 maybe?) later this year. That said, it may be possible for us to provide a version of BPEL Designer compatible with Eclipse Indigo, which *does* include this feature.

Be assured that this extension point is not going away - it's simply being delayed a bit until we have some time to rewrite the underlying code. Please let us know if you have available resources to help with this effort! Please monitor https://bugs.eclipse.org/bugs/show_bug.cgi?id=378997 for details about this effort.

________________________
Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

Hi All,

we are using this extension point in a big project.

We have made an embedded editor implementation using Xtext to define a new _expression_ Language.

The bridge between the 2 projects is available on Eclipse Labs: http://code.google.com/a/eclipselabs.org/p/bpel-xtext/

We understand your needs but we would like to stay up to date.

So, if you are evaluating to put back this feature in the future, please note that it is a key feature for us.

We are also willing to help, if needed..

Thanks!

Francesco

--
Vincent Zurczak

RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16

Re: [bpel-dev] BPEL uninitializedVariable

ddweerasiri@xxxxxxx (Denis Weerasiri) — Fri, 18 May 2012 08:36:25 GMT

On Thu, May 17, 2012 at 12:55 PM, Themba Shezi <mrtshezi@xxxxxxxxx> wrote:

Hi

I'm trying to invoke external web service orchestrated using Apache ode, it deploys successful but when i tried to test the following unexpected response appear. Please help i have struggling with this error for two days now

ERROR [INVOKE] org.apache.ode.bpel.common.FaultException: The variable getAmountPLRequest isn't properly initialized

Before you refer a variable you need to initialize it. So Before InvokeGetAmount activity , use an assign activity to initialize the getAmountPLRequest variable.

here is my process

targetNamespace="http://laonProcess.prs"

suppressJoinFailure="yes"
xmlns:tns="http://laonProcess.prs"
xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:ns="http://CreditAgency.loanBrokerApp.org" xmlns:ns0="http://Lender.loanBrokerApp.org" xmlns:ns1="http://Bank.laonBrokerApp.org">

http://Bank.laonBrokerApp.org" location="Bank.wsdl" importType="http://schemas.xmlsoap.org/wsdl/">

http://Lender.loanBrokerApp.org" location="Lenders.wsdl" importType="http://schemas.xmlsoap.org/wsdl/">

http://CreditAgency.loanBrokerApp.org" location="creditAgency.wsdl" importType="http://schemas.xmlsoap.org/wsdl/">

http://laonProcess.prs"
importType="http://schemas.xmlsoap.org/wsdl/" />





partnerLinkType="tns:loanProcess"

myRole="loanProcessProvider"
/>







messageType="tns:loanProcessRequestMessage"/>


messageType="tns:loanProcessResponseMessage"/>







portType="tns:loanProcess"

operation="process" variable="input"
createInstance="yes"/>




http://Lender.loanBrokerApp.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

ns:am
0
0



http://Bank.laonBrokerApp.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

0.0
0
0
ns:amount

ns:bName

http://laonProcess.prs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

tns:result

partnerLink="client"

portType="tns:loanProcess"
operation="process"
variable="output"
/>

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev

Re: [bpel-dev] Simplify expression editors?

bbrodt@xxxxxxx (Bob Brodt) — Fri, 18 May 2012 00:25:08 GMT

Hi Francesco,

I understand your concern and we are working on rewriting this part of the code because it violates the "do not use internal classes" rule. However, we are committed to having the BPEL Designer ready for the Eclipse Juno release this summer, and this will probably mean that the initial release may not support this extension. This feature will probably be part of a Juno service release (BPEL Designer 1.0.1 maybe?) later this year. That said, it may be possible for us to provide a version of BPEL Designer compatible with Eclipse Indigo, which *does* include this feature.

Be assured that this extension point is not going away - it's simply being delayed a bit until we have some time to rewrite the underlying code. Please let us know if you have available resources to help with this effort! Please monitor https://bugs.eclipse.org/bugs/show_bug.cgi?id=378997 for details about this effort.

________________________
Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

Hi All,
we are using this extension point in a big project.
We have made an embedded editor implementation using Xtext to define a new _expression_ Language.

The bridge between the 2 projects is available on Eclipse Labs: http://code.google.com/a/eclipselabs.org/p/bpel-xtext/

We understand your needs but we would like to stay up to date.

So, if you are evaluating to put back this feature in the future, please note that it is a key feature for us.

We are also willing to help, if needed..

Thanks!

Francesco

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev

Re: [bpel-dev] Simplify expression editors?

francesco.guidieri@xxxxxxx (Francesco Guidieri) — Thu, 17 May 2012 08:36:22 GMT

Hi All,

we are using this extension point in a big project.

We have made an embedded editor implementation using Xtext to define a new _expression_ Language.

The bridge between the 2 projects is available on Eclipse Labs: http://code.google.com/a/eclipselabs.org/p/bpel-xtext/

We understand your needs but we would like to stay up to date.

So, if you are evaluating to put back this feature in the future, please note that it is a key feature for us.

We are also willing to help, if needed..

Thanks!

Francesco

[bpel-dev] BPEL uninitializedVariable

mrtshezi@xxxxxxx (Themba Shezi) — Thu, 17 May 2012 07:25:31 GMT

I'm trying to invoke external web service orchestrated using Apache ode, it deploys successful but when i tried to test the following unexpected response appear. Please help i have struggling with this error for two days now

ERROR [INVOKE] org.apache.ode.bpel.common.FaultException: The variable getAmountPLRequest isn't properly initialized

here is my process

targetNamespace="http://laonProcess.prs"

suppressJoinFailure="yes"

xmlns:tns="http://laonProcess.prs"

xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:ns="http://CreditAgency.loanBrokerApp.org" xmlns:ns0="http://Lender.loanBrokerApp.org" xmlns:ns1="http://Bank.laonBrokerApp.org">

http://Bank.laonBrokerApp.org" location="Bank.wsdl" importType="http://schemas.xmlsoap.org/wsdl/">

http://Lender.loanBrokerApp.org" location="Lenders.wsdl" importType="http://schemas.xmlsoap.org/wsdl/">

http://CreditAgency.loanBrokerApp.org" location="creditAgency.wsdl" importType="http://schemas.xmlsoap.org/wsdl/">

http://laonProcess.prs"

importType="http://schemas.xmlsoap.org/wsdl/" />

partnerLinkType="tns:loanProcess"

myRole="loanProcessProvider"

messageType="tns:loanProcessRequestMessage"/>

messageType="tns:loanProcessResponseMessage"/>

portType="tns:loanProcess"

operation="process" variable="input"

createInstance="yes"/>

http://Lender.loanBrokerApp.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

ns:am

http://Bank.laonBrokerApp.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

0.0

ns:amount

ns:bName

http://laonProcess.prs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

tns:result

partnerLink="client"

portType="tns:loanProcess"

operation="process"

variable="output"

Re: [bpel-dev] Simplify expression editors?

bbrodt@xxxxxxx (Bob Brodt) — Tue, 15 May 2012 12:13:00 GMT

Hi Vincent,

If no one is using this extension point anyway my vote is to remove it and simplify the code. We can always try to figure out a way to add it back later if it is needed. I think getting this ready in time for the Juno release is the priority now.

Please let me know if I can help with anything.
Thanks!

Bob

----- Original Message -----
> Hi Bob, all,
>
> Le 10/05/2012 14:53, Bob Brodt a Ãcrit :
> > It looks like the expression editor needs to be rewritten, so if
> > you have time to work on this, I'd sure appreciate it :)
>
> I have started to work on it.
> First, I must say I am not very optimistic about our chances to
> reimplement it before Juno's release. Right now, what is in Juno M7
> will
> throw an exception at runtime.
> And second, I am thinking about the interest of such a feature.
>
> The embedded editors allow to embed a text editor in any composite.
> There is an extension-point for that, so that people can plug
> editors.
> We also have an extension-point for expression editors. Expression
> editors are created through embedded editors.
>
> Technically, this is cool. You have freedom of choice in your
> expression
> language, extensibility (although it all works with non-API code,
> which
> is the reason why the Juno build is broken).
> But is it really used or useful? Could not we only propose the XPath
> editor for expressions?
> I agree, that would restrain a part of freedom, but that would be
> straight-forward for users. And that would simplify a lot of code
> too.
>
> As a reminder, the code we are working on had been written before
> Eclipse 3.0 was released. And I am not sure the feature itself, this
> extensibility, is used by anyone.
> What I suggest is quite radical. We remove the extension points for
> the
> embedded editors and the expression editors.
> And we only reference the XPath editor. What will be extensible are
> the
> XPath functions that you can use in your BPEL. That's all. And if
> people
> complain about the removal of the extension-points, we will see then
> if
> it is possible to bring them back.
>
> Once again, we try to remain compatible with Helios, Indigo and Juno.
> One thing that could be done too, is that the extensibility could be
> an
> extra-plug-in for Helios and Indigo, but not shipped by default
> within
> Eclipse. We have an extension-point. If we find it, we use it.
> Otherwise, we only use the XPath editor. This is more complicated
> than
> simply removing it.
>
> What do you think?
>
>              Vincent.
>
> --
> Vincent Zurczak
>
> RCP Developer & ESB Consultant
> Petals Link: http://www.petalslink.com
> My Blog: http://vzurczak.wordpress.com
> +33 (0) 4 76 96 15 16
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
>

[bpel-dev] Simplify expression editors?

vincent.zurczak@xxxxxxx (Vincent Zurczak) — Tue, 15 May 2012 09:10:36 GMT

Hi Bob, all,

Le 10/05/2012 14:53, Bob Brodt a écrit :

It looks like the expression editor needs to be rewritten, so if you have time to work on this, I'd sure appreciate it :)

I have started to work on it. First, I must say I am not very optimistic about our chances to reimplement it before Juno's release. Right now, what is in Juno M7 will throw an exception at runtime. And second, I am thinking about the interest of such a feature.

The embedded editors allow to embed a text editor in any composite. There is an extension-point for that, so that people can plug editors. We also have an extension-point for expression editors. Expression editors are created through embedded editors.

Technically, this is cool. You have freedom of choice in your expression language, extensibility (although it all works with non-API code, which is the reason why the Juno build is broken). But is it really used or useful? Could not we only propose the XPath editor for expressions? I agree, that would restrain a part of freedom, but that would be straight-forward for users. And that would simplify a lot of code too.

As a reminder, the code we are working on had been written before Eclipse 3.0 was released. And I am not sure the feature itself, this extensibility, is used by anyone. What I suggest is quite radical. We remove the extension points for the embedded editors and the expression editors. And we only reference the XPath editor. What will be extensible are the XPath functions that you can use in your BPEL. That's all. And if people complain about the removal of the extension-points, we will see then if it is possible to bring them back.

Once again, we try to remain compatible with Helios, Indigo and Juno. One thing that could be done too, is that the extensibility could be an extra-plug-in for Helios and Indigo, but not shipped by default within Eclipse. We have an extension-point. If we find it, we use it. Otherwise, we only use the XPath editor. This is more complicated than simply removing it.

What do you think?

            Vincent.

--
Vincent Zurczak

RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16

Re: [bpel-dev] Broken build for Juno

bbrodt@xxxxxxx (Bob Brodt) — Thu, 10 May 2012 12:56:42 GMT

Sorry, copy and paste error :)
It's this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=378997

----- Original Message -----
> Hi Vincent,
> 
> I've created https://bugs.eclipse.org/bugs/show_bug.cgi?id=368598 to
> track this. I was hoping to get back to this yesterday but ran out
> of time. It looks like the expression editor needs to be rewritten,
> so if you have time to work on this, I'd sure appreciate it :)
> 
> Thanks!
> Bob
> 
> ----- Original Message -----
> > Hi,
> > 
> > The build is broken for Juno.
> > After investigation, it appears to be due to the use of non-API
> > classes
> > in common.ui (code that was moved in e4 and results in conflicts
> > with
> > the previous versions of Eclipse).
> > I found some classes that were useless and that can be removed
> > without
> > any incidence.
> > 
> > But there is the expression editor framework that remains a
> > problem.
> > I will try to find more time tomorrow to work on it.
> > 
> >              Vincent.
> > 
> > --
> > Vincent Zurczak
> > 
> > RCP Developer & ESB Consultant
> > Petals Link: http://www.petalslink.com
> > My Blog: http://vzurczak.wordpress.com
> > +33 (0) 4 76 96 15 16
> > _______________________________________________
> > bpel-dev mailing list
> > bpel-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/bpel-dev
> > 
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
>