Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [smila-dev] [bpel-dev] BPEL Designer extensionActivity bug

Yes, sorry for the confusion, something went wrong when I copied the namespace definition into the mail…

The superfluous namespace definition, that has been added by the BPEL designer is “xmlns:bpel=http://docs.oasis-open.org/wsbpel/2.0/process/executable”.

My guess is that BPEL designer is only working with its default workspace “bpel” and does not care about any other (default) namespace definitions already defined in the file.

Is this true?

 

Here is a snippet out of the BPEL file:

<process name="AddPipeline" targetNamespace="http://www.eclipse.org/smila/processor"

                xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

                xmlns:proc="http://www.eclipse.org/smila/processor" xmlns:rec="http://www.eclipse.org/smila/record" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable">

 

Igor

 

Von: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] Im Auftrag von Bob Brodt
Gesendet: Montag, 13. September 2010 23:13
An: BPEL Designer project developer discussions.
Cc: smila-dev@xxxxxxxxxxx
Betreff: Re: [bpel-dev] [smila-dev] BPEL Designer extensionActivity bug

 

Hi Igor,

Not sure what you mean about the namespace. I see xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" being inserted into the *.bpel file...

_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat

----- "igor novakovic" <igor.novakovic@xxxxxxxxxxxxx> wrote:
>

>

Hi Bob,

 

Yes, I can confirm that both workarounds do work. Now, the fun with the BPEL designer can begin! :-)

 

BTW: I found another minor issue. Although the namespace “xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/executable” is defined the BPEL designer adds a new definition “xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/executable”. Any chance of suppressing this?

 

Regards

Igor

 

 

>

Von: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] Im Auftrag von Bob Brodt
> Gesendet: Montag, 13. September 2010 18:43
> An: BPEL Designer project developer discussions.
> Cc: smila-dev@xxxxxxxxxxx
> Betreff: Re: [bpel-dev] [smila-dev] BPEL Designer extensionActivity bug

 

Hi Igor,
>
> Thanks for the info - I will make the necessary changes. We're still setting up the hudson builds on build.eclipse.org (see https://build.eclipse.org/hudson/job/tycho-bpel/ for latest build status) and it will probably be a couple of days before this is working.
>
> Also, thanks for reminding me about the other issue with the editor (BPEL resource opens with XML editor instead of BPEL Designer). This is because the content type describer is not working for some reason. If you remove the <?xml?>  processing instruction at the beginning of the file, it should work properly. Alternatively, you can right-click and "Open With" on the bpel resource, then select "Other... -> Business Process Editor".
>
> I have created a bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=325133) to track this.
>
> _______________________________________
> Robert ("Bob") Brodt
> Senior Software Engineer, JBoss Riftsaw
> JBoss by Red Hat
>
> ----- "igor novakovic" <igor.novakovic@xxxxxxxxxxxxx> wrote:
> >

>

Hi Bob,

 

Thanks for the tip!

I downloaded the Helios J2EE package (http://eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/heliosr) and tested the latest code in your repository with it.

Here is the list of adjustments I had to make in order to compile the code:

1. In /org.eclipse.bpel.examples.extensionPoints/META-INF/MANIFEST.MF I had to downgrade the versions of org.eclipse.wst.jsdt.core and org.eclipse.wst.jsdt.ui from 1.1.1 to 1.1.0

2. Besides checking out all plugins stated on http://eclipse.org/bpel/install.php I also had to chechout the org.eclipse.bpel.xpath10 plugin

Perhaps this info will help you updating the install page.

 

Now to the bugfix itself:

In your mail below you said that in general two things have been fixed now:

The designer should not crash (with an NPE) if unknown/unsupported extension activities are found in a BPEL workflow and that now a simple activity with no property sheet info should be shown up.

Well, the designer does not crash now. I can confirm that. But instead of getting a nice workflow displayed in “design” tab like this:

 

I get only a xml-tree view now:

 

 

Am I doing something wrong here or did I perhaps misunderstand your statement about displaying unknown extension activities?

 

Regards

Igor

 

-----Ursprüngliche Nachricht-----
> > Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Bob Brodt
> > Gesendet: Freitag, 10. September 2010 16:51
> > An: Smila project developer mailing list
> > Cc: bpel-dev@xxxxxxxxxxx
> > Betreff: Re: [smila-dev] BPEL Designer extensionActivity bug

 

Oh I almost forgot, there are directions on how to build from source here:

 

http://eclipse.org/bpel/install.php

 

I still need to update this page for Helios, but just substitute the latest EMF, GEF, DTP and WTP releases for what's listed and it should build without any problems. If you simply install the eclipse 3.6 J2EE bundle, (http://eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/heliosr) it should have everything you need.

 

_______________________________________

Robert ("Bob") Brodt

Senior Software Engineer, JBoss Riftsaw

JBoss by Red Hat

 

----- "igor novakovic" <igor.novakovic@xxxxxxxxxxxxx> wrote:

 

> Great news Bob!

>

> Since I am very iterested in testing the current state of BPEL

> designer, could you please give me some hints how to obtain the

> software/binaries?

> Are there any nightliy builds already out there which I could test?

> The download page (http://eclipse.org/bpel/downloads.php) deals only

> with M4 which is more than a year old. Also the upate-site is still

> tied to M4, right?

>

> BTW: One option would also be building BPEL desinger from souce, but

> on the project's website there are no instructions how to do that.

>

> Regards

> Igor

>

>

> -----Ursprüngliche Nachricht-----

> Von: smila-dev-bounces@xxxxxxxxxxx

> [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Bob Brodt

> Gesendet: Freitag, 10. September 2010 15:50

> An: BPEL Designer project developer discussions.

> Cc: smila-dev@xxxxxxxxxxx

> Betreff: [smila-dev] BPEL Designer extensionActivity bug

>

> Hi Igor and Juergen,

>

> I fixed the problem with the BPEL designer crashing when it tries to

> load an extensionActivity that does not have a supporting extension

> plug-in. It now shows up as a simple activity with not Property Sheet

> info - you have to use the editor's source tab to edit the enclosed

> extension activity's attributes.

>

> This is reported in

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=324115

>

> Of course, the right way to do this is to write an extension point for

> the editor to support the invokeService and invokePipelet activities.

> There's a pretty good example of how to do this in the CVS repo in

> examples/plugins.

>

> Let me know if you still have problems.

>

> _______________________________________

> Robert ("Bob") Brodt

> Senior Software Engineer, JBoss Riftsaw

> JBoss by Red Hat

>

> ----- "igor novakovic" <igor.novakovic@xxxxxxxxxxxxx> wrote:

>

> > My mail should now also reach the BPEL dev mailing list :-)

> >

> > Igor

> >

> > -----Ursprüngliche Nachricht-----

> > Von: smila-dev-bounces@xxxxxxxxxxx

> > [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von

> > igor.novakovic@xxxxxxxxxxxxx

> > Gesendet: Dienstag, 31. August 2010 17:29

> > An: bbrodt@xxxxxxxxxx; smila-dev@xxxxxxxxxxx; bpel-dev@xxxxxxxxxxx

> > Betreff: Re: [smila-dev] The Eclipse BPEL Designer Project - what's

> > the dealhere?

> >

> > Great news Bob!

> > Please keep up the good work. We really look forward having usable

> > BPEL editor for our SMILA workflows.

> >

> > Cheers

> > Igor

> >

> >

> > -----Ursprüngliche Nachricht-----

> > Von: Bob Brodt [mailto:bbrodt@xxxxxxxxxx]

> > Gesendet: Dienstag, 31. August 2010 17:23

> > An: smila-dev@xxxxxxxxxxx; bpel-dev@xxxxxxxxxxx

> > Cc: Novakovic, Igor, M-E-D; Schumacher, Jürgen, M-ED

> > Betreff: The Eclipse BPEL Designer Project - what's the deal here?

> >

> > Good idea Igor :) I have posted this email trail to the dev mailing

> > lists.

> >

> > I have fixed the crash in the BPEL designer caused by unimplemented

> > extensionActivities and will be checking it in to the BPEL CVS repo

> at

> > eclipse.org soon. Ideally, the default implementation of the

> Details

> > Tab in the Property Sheet for unimplemented extensionActivities

> should

> > be something like the WTP XML editor - I'll probably add that later

> > when time permits. Currently, you have to use the Source view in

> the

> > BPEL Designer to edit your extension elements.

> >

> > _______________________________________

> > Robert ("Bob") Brodt

> > Senior Software Engineer, JBoss Riftsaw

> > JBoss by Red Hat

> >

> > ----- "igor novakovic" <igor.novakovic@xxxxxxxxxxxxx> wrote:

> >

> > Hi Bob,

> >

> > Writing an extension plugin for the BPEL editor (or for each

> > extension

> > activity a separate extension plugin) was something that we intend

> to

> > do, but as you already said the editor should definitely not crash

> > when it encounters anything that it is (currently) not able to

> > configure. It would be great if you (JBoss) could fix this by

> merging

> > your fork to the trunk.

> >

> > > Can you (or Igor) tell me a bit more about these invokePipelet

> and

> > > invokeService extension activities? what do they do on the

> runtime?

> >

> > invokePipelet calls a SMILA-pipelet which is a simple POJO that

> > implements some piece of "light-weight" business logic that does

> not

> > consume lots of hardware resources. The lifecycle of this pipelet

> is

> > tied to the one of the BPEL workflow/pipeline.

> > On the other hand, invokeService calls a SMILA-service which is a

> > OSGi

> > declarative service and thereby has its own lifecycle independent

> of

> > the BPEL pipeline where the invocation took place. SMILA-services

> > usually take long to initialize and consume more hardware resources

> > than pipelets and therefore used/executed in several different

> > pipelines/workflows.

> > There are some more details and nice examples on this topic at

> > http://wiki.eclipse.org/SMILA/Documentation/BPEL_Workflow_Processor

>

> >

> > BTW: It would be nice if we could continue our conversation on our

> > mailing list so that the community can profit from this insights.

> >

> > Cheers

> > Igor

> >

> >

> > > -----Ursprüngliche Nachricht-----

> > > Von: Bob Brodt [mailto:bbrodt@xxxxxxxxxx]

> > > Gesendet: Donnerstag, 26. August 2010 14:23

> > > An: Schumacher, Jürgen, M-ED

> > > Cc: Novakovic, Igor, M-E-D

> > > Betreff: Re: AW: [Beepul, beppul or beepell? It's all geek to

> me!]

> > > Comment: "The Eclipse BPEL Designer Project - what's the deal

> > here?"

> > >

> > > Ah ha! That explains it then :)

> > >

> > > You have to write an extension plugin for the BPEL editor that

> > > implements a couple of extension points defined by the editor.

> This

> > is

> > > described here:

> > >

> > > www.eclipse.org/bpel/users/pdf/CreateAnExtensionActivity.pdf

> > >

> > > The document is pretty straight-forward, but let me know if you

> > need

> > > help with this.

> > >

> > > Regardless, the editor should NOT just crash and burn when it

> loads

> > a

> > > bpel file that contains an undefined extension activity. I have

> > > created a bug report on the JBoss community bug tracking system

> > here:

> > >

> > > https://jira.jboss.org/browse/JBIDE-6917

> > >

> > > Some history about this: we (JBoss) were forced to create a fork

> of

> > > the editor because we needed to make some enhancements to allow

> us

> > to

> > > deploy to the Riftsaw runtime, and there were no active

> committers

> > > left at eclipse.org/bpel to help push those enhancements back

> > > upstream. Now that we have some control over that project again,

> we

> > > are planning to merge our bug fixes and enhancements into the

> > eclipse

> > > project, and eventually abandon our fork and consume the eclipse

> > BPEL

> > > editor directly. We hope to have this done in about a month or

> so.

> > At

> > > that point, we'll start doing nightly builds at eclipse and make

> > the

> > > binaries available to the community.

> > >

> > > Can you (or Igor) tell me a bit more about these invokePipelet

> and

> > > invokeService extension activities? what do they do on the

> runtime?

> > > _______________________________________

> > > Robert ("Bob") Brodt

> > > Senior Software Engineer, JBoss Riftsaw

> > > JBoss by Red Hat

> > >

> > > ----- "Jürgen Schumacher" <juergen.schumacher@xxxxxxxxxxxxx>

> wrote:

> > >

> > > > HI Bob,

> > > >

> > > > Am 25.08.2010, 20:10 Uhr, schrieb Bob Brodt

> <bbrodt@xxxxxxxxxx>:

> > > > > Thanks for those Jürgen. By any chance, did you create BPEL

> > > > extension 

> > > > > activities for "invokeService" and "invokePipelet" and if so,

> > can

> > > > you 

> > > > > send along the classes for those? If not, then I think I know

> > the

> > > > reason 

> > > > > why the editor is crashing ;)

> > > >

> > > > I'm not completely sure which classes you mean, so let's see:

> > > >

> > > > We did not create any special code for the BPEL editor (I even

> > did

> > > > not

> > > > do the experiments with the editor myself, so I do not know the

> > > > details).

> > > >

> > > > The code that executes the "invokePipelet/Service" actions is

> > here:

> > > >

> > > >  

> > > >

> > >

> >

> https://dev.eclipse.org/svnroot/rt/org.eclipse.smila/trunk/org.eclipse.smila.processing.bpel/code/src/org/eclipse/smila/processing/bpel

> > > >

> > > > starting with SMILAExtensionBundle.java, which does the actual

> > > > integration 

> > > > into the ODE engine.

> > > >

> > > > Classes which can be invoked using the "invokePipelet" activity

> > > exist

> > > > in 

> > > > the SMILA repository, e.g. at

> > > >

> > > >  

> > > >

> > >

> >

> https://dev.eclipse.org/svnroot/rt/org.eclipse.smila/trunk/org.eclipse.smila.processing.pipelets/code/src/org/eclipse/smila/processing/pipelets

> > > >

> > > > All this code was probably not in the classpath of the BPEL

> > editor.

> > > >

> > > > Hope this helps (-:

> > > >

> > > > Thanks,

> > > > Juergen.

> > > >

> > > > PS: I'll be out of office tomorrow and on Monday, so I'll not

> be

> > > able

> > > > to 

> > > > answer further questions before

> > > > Tuesday. But Igor or someone else from the team should still be

> > > able

> > > > to 

> > > > answer.

> > _______________________________________________

> > smila-dev mailing list

> > smila-dev@xxxxxxxxxxx

> > https://dev.eclipse.org/mailman/listinfo/smila-dev

> > _______________________________________________

> > bpel-dev mailing list

> > bpel-dev@xxxxxxxxxxx

> > https://dev.eclipse.org/mailman/listinfo/bpel-dev

> _______________________________________________

> smila-dev mailing list

> smila-dev@xxxxxxxxxxx

> https://dev.eclipse.org/mailman/listinfo/smila-dev

> _______________________________________________

> smila-dev mailing list

> smila-dev@xxxxxxxxxxx

> https://dev.eclipse.org/mailman/listinfo/smila-dev

_______________________________________________

smila-dev mailing list

smila-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/smila-dev


> > _______________________________________________ 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


Back to the top