[Design of JBoss jBPM] - Re: introducing process instance ?
by tom.baeyens＠jboss.com
"jbarrez" wrote : -> This could lead to castings of executions to ProcessInstances, which aren't process instances (ie no root execution). But for the compiler, nothing is wrong since they are exactly the same...
|
i don't see the need for those casts. first, the api returns process instances where appropriate.
secondly, process instance doesn't add any methods, so there will be no reason to cast :-)
the thing that i'm mostly in doubt about is the return value of the signal methods. previously we returned the execution in which the signal was given. but in the context of this thread it looks to me more logically that we return the process instance. that could lead to confusion, but if we introduce the ProcessInstance interface, it becomes clear that the process instance is returned. so on balance i am in favour of introducing ProcessInstance and changing the return value of the signal methods to ProcessInstance
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225890#4225890
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225890
17 years, 2 months
[Design of JBoss jBPM] - Re: introducing process instance ?
by jbarrez
anonymous wrote : in the implementation. And then suppose that jPDL wants to add a property to all executions... then you end up in multiple inheritence.
I understand.
Extending implementation classes is indeed a no-go when the process instance implementation must be extendable.
So how do you see the inheritance?
| ProcessInstance (interface) extends Execution
| ExecutionImpl implements ProcessInstance, Execution
|
-> This could lead to castings of executions to ProcessInstances, which aren't process instances (ie no root execution). But for the compiler, nothing is wrong since they are exactly the same...
I don't know, I get a funy feeling about it when I think about it like that... This leads back to the question if processInstance == Execution? (I know we already discussed this, but perhaps I'm seeing this in the wrong perspective here)
anonymous wrote :
| and besides, i think it is best that all executions (incl process instances) are stored in only 1 single table.
|
Definitely
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225884#4225884
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225884
17 years, 2 months
[Design of JBoss Web Services] - ESB / WS integration issue on AS5
by alessio.soldano＠jboss.com
Daniel Bevenius wrote:
Hi Alession,
hope you don't mind me emailing directly. Kevin Conner gave me your email address and I'd like to ask your advice an issue I'm having.
Background
In the ESB you can specify that a service should be exposed as a WS. Upon deploying the service a web-app will get generated
and deployed. As part of this process a number of files get generated, like the webservice implementation, jaxws handler chain, wsdl file.
In JBoss AS 4.x this was done by actually creating a .war file on the local filesystem, but in AS5 it is done by using a
number of deployers.
This is what I want to achive:
1. Generate a wsdl and add that wsdl to a deployment unit so that it will be available to other deployers, mainly the WS deployer(s).
I'm trying to to add the wsdl to an in-memory VFS, and then add that as a metadata location to the deploymentunit. This is done by the following deployer:
http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/jbo...
I'm currently adding this to the Deployment units metadata locations using deploymentUnit.appendMetaDataLocation(dynamicRoot.getRoot()) which I was advised on doing by Ales. I have previously adding it to the classpath but the classpath gets ignored by the tomcat deployer which can be seen in server.log.
3. Generate a ws provider which sets the 'wsdlLocation' attribute to the wsld generated above. This is done by the following deployer:
http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/jbo...
Upon deployment the following error message is displayed:
| Caused by: java.io.IOException: Child not found WEB-INF/wsdl/ESBServiceSample/HelloWorldPubService.wsdl for
| DelegatingHandler(a)18297205[path=Quickstart_publish_as_webservice.esb context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb], available children:
| [ZipEntryHandler(a)32154980[path=Quickstart_publish_as_webservice.esb/.classpath context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/.classpath],
| ZipEntryHandler(a)1067582[path=Quickstart_publish_as_webservice.esb/.project context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/.project],
| ZipEntryHandler(a)24788458[path=Quickstart_publish_as_webservice.esb/META-INF context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/META-INF],
| ZipEntryHandler(a)7797905[path=Quickstart_publish_as_webservice.esb/fault.xsd context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/fault.xsd],
| ZipEntryHandler(a)29339526[path=Quickstart_publish_as_webservice.esb/jbmq-queue-service.xml context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/jbmq-queue-service.xml],
| ZipEntryHandler(a)27043349[path=Quickstart_publish_as_webservice.esb/org context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/org],
| ZipEntryHandler(a)22800383[path=Quickstart_publish_as_webservice.esb/request.xsd context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/request.xsd],
| ZipEntryHandler(a)14430122[path=Quickstart_publish_as_webservice.esb/response.xsd context=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/ real=file:/opt/jboss/as/jboss-5.0.1.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/response.xsd]]
| at org.jboss.virtual.VirtualFile.findChild(VirtualFile.java:461)
| at org.jboss.metadata.serviceref.VirtualFileAdaptor.findChild(VirtualFileAdaptor.java:99)
| at org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl.getMetaDataFileURL(ArchiveDeploymentImpl.java:97)
| at org.jboss.ws.metadata.builder.jaxws.JAXWSProviderMetaDataBuilder.buildProviderMetaData(JAXWSProviderMetaDataBuilder.java:125)
| at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:55)
| at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderJSE.buildMetaData(JAXWSMetaDataBuilderJSE.java:61)
| ... 24 more
|
As far as I can tell the WS deployers do not use the metadata location on the deployment unit. I can't see that deployment unit's metadata location is used when JAXWSProviderMetaDataBuilder tries to locate the wsdl.
When a org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl is created by newDeployment(DeploymentUnit) in AbstractDeployerHook, only the deployment unit's simpleName and classloader are used.
ArchiveDeployerHook which extends AbstractDeployerHook attaches the deployment unit (to the ArchiveDeployment), so it would be available to JAXWSProviderMetaDataBuilder and could potentially be used to search for a wsdl set by an earlier deployer. This would require a code modification though.
In JAXWSProviderMetaDataBuilder, line 121
| // Process WSDL
| String wsdlLocation = anWebServiceProvider.wsdlLocation();
| if (wsdlLocation.length() > 0)
| {
| URL wsdlURL = dep.getMetaDataFileURL(wsdlLocation);
| serviceMetaData.setWsdlLocation(wsdlURL); // This is line 125 if you are following the above stacktrace
| }
|
The field dep is an instance of ArchiveDeplomentImpl and its getMetaDataFileUrl looks like this:
| public URL getMetaDataFileURL(String resourcePath) throws IOException
| {
| URL resourceURL = null;
| if (resourcePath != null && resourcePath.length() > 0)
| {
| if (resourcePath.startsWith("/"))
| resourcePath = resourcePath.substring(1);
|
| try
| {
| // assign an absolute URL
| resourceURL = new URL(resourcePath);
| }
| catch (MalformedURLException ex)
| {
| // ignore
| }
|
| if (resourceURL == null && getRootFile() != null)
| {
| UnifiedVirtualFile vfResource = getRootFile().findChild(resourcePath);
| resourceURL = vfResource.toURL();
| }
| }
|
| return resourceURL;
| }
|
If I modify JAXWSProviderMetaDataBuilder, to something like this (pardon the ugly code here):
| // Process WSDL
| String wsdlLocation = anWebServiceProvider.wsdlLocation();
| if (wsdlLocation.length() > 0)
| {
| URL wsdlURL = null;
| DeploymentUnit deploymentUnit = dep.getAttachment(DeploymentUnit.class);
| if (deploymentUnit instanceof VFSDeploymentUnit)
| {
| VFSDeploymentUnit vfsunit = (VFSDeploymentUnit) deploymentUnit;
| VirtualFile metaDataFile = vfsunit.getMetaDataFile(wsdlLocation);
| if (metaDataFile != null)
| {
| try
| {
| wsdlURL = metaDataFile.toURL();
| }
| catch (URISyntaxException e)
| {
| e.printStackTrace();
| }
| }
| }
| if (wsdlURL == null)
| {
| wsdlURL = dep.getMetaDataFileURL(wsdlLocation);
| }
| serviceMetaData.setWsdlLocation(wsdlURL);
| }
|
I updated the jbossws-native-3.0.5.GA/modules/core/pom.xml, but adding the two following dependencies to get the above code to build:
| <dependency>
| <groupId>org.jboss.deployers</groupId>
| <artifactId>jboss-deployers-structure-spi</artifactId>
| <version>2.0.5.GA</version>
| <scope>provided</scope>
| </dependency>
| <dependency>
| <groupId>org.jboss.deployers</groupId>
| <artifactId>jboss-deployers-vfs-spi</artifactId>
| <version>2.0.5.GA</version>
| <scope>provided</scope>
| </dependency>
|
Using this it works for me but this is sort of a hack and perhaps I'm going about this in the wrong way. Is there a better/different way of achiving this?
Thanks,
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225871#4225871
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225871
17 years, 2 months
[Design of JBoss jBPM] - Re: introducing process instance ?
by tom.baeyens＠jboss.com
"jbarrez" wrote : But I don't agree that the ProcessInstance should be an interface.
| Why not make it an extension of the ExecutionImpl? After all, the ProcessInstance is just another name of a very specific execution (ie the root execution). You could add some specifc stuff to the process instance (eg business key? as it was in jbpm3 or getAllWaitStates())
|
the ProcessInstance interface that I propose is in the api.
i can't make the same distinction in the implementation classes. but the api user will not notice that.
suppose that we have
class ProcessInstanceImpl extends ExecutionImpl {
| ...
| }
in the implementation. And then suppose that jPDL wants to add a property to all executions... then you end up in multiple inheritence.
and besides, i think it is best that all executions (incl process instances) are stored in only 1 single table.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225852#4225852
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225852
17 years, 2 months
[Design of PVM (Process Virtual Machine)] - Re: Composite execution problem
by beeke
Thank you, Tom
The Sequence class is :test-pojo/EventPropagationTest#Sequence.
| public static class Sequence implements ExternalActivityBehaviour {
| private static final long serialVersionUID = 1L;
| public void execute(ActivityExecution execution) {
| List<Activity> activities = execution.getActivity().getActivities();
| if ( (activities!=null)
| && (!activities.isEmpty())
| ) {
| execution.execute(activities.get(0));
| }
| }
| public void signal(ActivityExecution execution, String signal, Map<String, Object> parameters) {
| Activity previous = execution.getPreviousActivity();
| List<Activity> activities = execution.getActivity().getActivities();
| int index = activities.indexOf(previous);
| index++;
| if (index < activities.size()) {
| Activity next = activities.get(index);
| execution.execute(next);
| }
| }
|
When I set the transition:.initial().needsPrevious().transition("end"),
the sequence activity in ExecutionImpl.proceed() will never executed as a block stucted code.
If I modify the structure like this:
| .startActivity("three", new WaitState()).transition("end")
| .endActivity()
|
It works fine.
But the structure is
http://docs.jboss.org/jbpm/pvm/manual/html_single/images/ch02.transition....
Can you tell me how to write a currect ActivityBehaviour?
Thank you!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225851#4225851
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225851
17 years, 2 months
