Shared web context

[heiko.braun]

https://jira.jboss.org/jira/browse/RIFTSAW-65

If we derive the web context from the wsdl file, then it's very likely that we run into the error attached to the issue above. It's actually not an error, but to be expected, because every bpel enpoint deployment internally creates web application deployment and thus cannot re-use and existing context.

Any ideas?

[objectiser]

But the context for each example is unique if taken as a whole.

The HelloWorld is http://localhost:8080/bpel/processes/helloWorld,
and the SimpleCorrelation is http://localhost:8080/bpel/processes/helloGoodbyeWorld

So if the file path part of the URL is taken as a whole, and not as individual parts in a hierarchical namespace, then it should be unqiue. Is that possible?

[heiko.braun]

No, because in a servlet container the first path element after the host is considered the 'webcontext'. The remaining elements are servlet mappings.
All examples that we currently have thereby use the same webcontext 'bpel'.

In the beginning i've implemented dynamic webcontext for each deployment
in order to circumvent this problem.

Any ideas how to move forward?

[objectiser]

Any idea how the Axis2 integration layer handles this, as they must have the same problem?

[objectiser]

Just realised - the Axis2 integration layer just provides a single servlet for dealing with all requests in the 'bpel' web context - so this is different to the JAX-WS approach where each separate deployment has its own servlet I guess, and therefore needs a separate webcontext.

Possibly this needs to be something that a user needs to be aware of - and use the webcontext name associated with the bpel deployment (e.g. myapp-1.jar we would recommend they use 'myapp/whatever' for the service URL?

So it is up to the user to keep them correctly segmented? If so, then we just need to update the examples in line with this.

[heiko.braun]

Right, currently it's up to the user. Axis always used a single servlet, even in 1.x versions. The problem is that you'd force anything that relates to webcontext to be shared, i.e. the security credentials, etc. Which is wrong IMO.

We might comeup with a solution that can re-use a webcontext, but that would mean that any existing process would need to be undeployed when a new process wants to join the party:

1. Deploy process A
1.1) Create web context:
 ProcessA -> /bpel/processA
2. Deploy process B
2.1 Undeploy webcontext /bpel/
2.2 Add ProcessB -> /bpel/processB
3.) redeploy both using webcontext /bpel/
 Process A -> /bpel/processA
 Process B -> /bpel/processB

However at some point existing processes would not be available
until the update to the webcontext is finished.