[Design of JBoss Build System] - Re: [JBASMP-2] Create an Undeploy Mojo
by guignome
"ALRubinger" wrote : "guignome" wrote : I'm guessing there is connection that isn't closed somewhere.
|
| Is there anything other than the error posted which leads you to think this?
|
Just the fact that if I deploy a war once, everything goes right, but if I deploy it twice, it fails with this error.
"ALRubinger" wrote :
| The stack trace points to a CCE, my first impression is due to a version incompatibility between a dependency defined by the project and the AS you're running.
|
Yes, that would make a lot of sense. I'm deploying in jboss-5.0.0.CR2. I'm wondering if there is something wrong with my environment. Would you mind doing a test for me? The easiest way to reproduce the same error on my computer is to try to deploy the slsb twice in a row in jbossass-maven-control-plugin-examples.
ie, in the file maven-jboss-as-control-example/pom.xml replace
| <!--
|
| Deploy into our custom JBossAS Configuration
|
| -->
| <execution>
| <id>deploy-test-slsb</id>
| <goals>
| <goal>deploy</goal>
| </goals>
| <phase>pre-integration-test</phase>
| <configuration>
| <serverConfigName>custom</serverConfigName>
| <files>
| ${project.build.directory}/${project.build.finalName}.${project.packaging}
| </files>
| <jboss.test.run>true</jboss.test.run>
| </configuration>
| </execution>
|
with
| <!--
|
| Deploy into our custom JBossAS Configuration
|
| -->
| <execution>
| <id>deploy-test-slsb</id>
| <goals>
| <goal>deploy</goal>
| </goals>
| <phase>pre-integration-test</phase>
| <configuration>
| <serverConfigName>custom</serverConfigName>
| <files>
| ${project.build.directory}/${project.build.finalName}.${project.packaging}
| </files>
| <jboss.test.run>true</jboss.test.run>
| </configuration>
| </execution>
| <!--
|
| Deploy a second time into our custom JBossAS Configuration
|
| -->
| <execution>
| <id>deploy-test-slsb2</id>
| <goals>
| <goal>deploy</goal>
| </goals>
| <phase>pre-integration-test</phase>
| <configuration>
| <serverConfigName>custom</serverConfigName>
| <files>
| ${project.build.directory}/${project.build.finalName}.${project.packaging}
| </files>
| <jboss.test.run>true</jboss.test.run>
| </configuration>
| </execution>
|
That should fail anyway as you cannot deploy the same war twice, but I'm curious to see if you would get the same exception as mine.
Thanks,
Guillaume
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181014#4181014
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181014
17 years, 6 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"kukeltje" wrote : "heiko.braun(a)jboss.com" wrote : anonymous wrote :
| | | Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
| | |
| |
| | Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
| |
| | - One for building a process model from XML descriptors
| | (Similar to what's in the PVM already)
| | - One for invoking on it (Client API)
| | - One for extending the engine capabilities (i.e. new node types)
| | - One to solve integration problems (TX, persistence, etc)
| |
| |
| +10
| I like the use of jaxb as Thomas is doing. Not fully sure why, but it feels right.
|
| "heiko.braun(a)jboss.com" wrote :
| |
| | But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL.
| |
| To some extend you are correct, but if you search the net for problems regarding mapping bpmn to bpel or xpdl (improved with bpmn 2.0 and xpdl 2.0) it is not that easy and so they are not independent.
|
Oops, forgot to correct this statement after reading (and answering) the last statement in your previous post.
I tend to agree with your statement, it all came down to terminology again ;-)
Implementing an xml based language is then creating a xml binding and in that re-use or extend the building blocks (core elements, base classes for activities in the pvm) to use the pvm api
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181005#4181005
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181005
17 years, 6 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"heiko.braun(a)jboss.com" wrote : anonymous wrote :
| | Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
| |
|
| Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
|
| - One for building a process model from XML descriptors
| (Similar to what's in the PVM already)
| - One for invoking on it (Client API)
| - One for extending the engine capabilities (i.e. new node types)
| - One to solve integration problems (TX, persistence, etc)
|
|
+10
I like the use of jaxb as Thomas is doing. Not fully sure why, but it feels right.
"heiko.braun(a)jboss.com" wrote :
|
| But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL.
|
To some extend you are correct, but if you search the net for problems regarding mapping bpmn to bpel or xpdl (improved with bpmn 2.0 and xpdl 2.0) it is not that easy and so they are not independent.
"heiko.braun(a)jboss.com" wrote :
|
| Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently?
|
Afaik, but could not find it directly, BPMN is based on structured graphs so a split requires a corresponding join.
In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split:
"www.workflowpatterns.com" wrote : These branches may or may not be re-synchronized at some future time.
The number of cases that I've came across in the forum where people did
| fork 1
| / \
| | fork 2
| | / \
| join 1 |
| \ /
| join 2
|
Are rare and could in most cases simply be modeled in another way. The reason jpdl requires this are simple. The implementation of a join is more simple then. This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-)
"heiko.braun(a)jboss.com" wrote :
| The answer to this question has a technical impact on the implementation (i.e. threading, transactions) and thus an impact on the API.
|
It indeed influences the transactions (see the issues with the join in jira) and to a lesser extend threading (it was always stated that jBPM was not a thread-control-engine), therefore the async functionality to leverage e.g. jms
"heiko.braun(a)jboss.com" wrote :
| Why an impact on the API? Because if we chose real parallel execution (open graph, independent path's of execution) then client 'signal' (jBPM3) doesn't make sense anymore. Actually it wouldn't even work because the client will not be in control of execution anymore.
|
For that one parallel gateway you are correct, but again, the fork is not something that I ever signalled from the client api, so no change in that area. For each of the legs in a fork (weren't they called teeth ;-)) there can be wait-states again (activities) that need to be signalled
"heiko.braun(a)jboss.com" wrote :
| I believe that there is a small set of core elements, which are not related to the final PDL that, once we got it right, can be used to assemble concrete engines (jBPM4+jpdl) leveraging building blocks.
|
But those are building blocks behind the scenes, reusable to create a new PDL. Sounds nice, JPDL and e.g. an executable BPMN can leverage both, but that is not related (as you also state above, right?) to the client-api and imo that should be the most stable, simple to use etc...
Great.... I get the feeling we are getting somewhere
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181003#4181003
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181003
17 years, 6 months
[Design of JBoss jBPM] - Re: meeting context
by heiko.braun＠jboss.com
anonymous wrote :
| Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
|
Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
- One for building a process model from XML descriptors
(Similar to what's in the PVM already)
- One for invoking on it (Client API)
- One for extending the engine capabilities (i.e. new node types)
- One to solve integration problems (TX, persistence, etc)
But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL.
Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently? The answer to this question has a technical impact on the implementation (i.e. threading, transactions) and thus an impact on the API.
Why an impact on the API? Because if we chose real parallel execution (open graph, independent path's of execution) then client 'signal' (jBPM3) doesn't make sense anymore. Actually it wouldn't even work because the client will not be in control of execution anymore.
I believe that there is a small set of core elements, which are not related to the final PDL that, once we got it right, can be used to assemble concrete engines (jBPM4+jpdl) leveraging building blocks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180995#4180995
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180995
17 years, 6 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"heiko.braun(a)jboss.com" wrote :
| Let's take a different angle: This is not about the process definition language. (It's going to be pluggable anyway, right?)
|
Ok, maybe we already look at it differently here. Executing process languages is the thing that jBPM (ok PVM) does for you and supporting that should be exposed by the API.
Pluggable yes, but you cannot drop-in replace jpdl for bpel or xpdl :-) and in each of these executable languages you can do things you cannot do with the other.
But instead of going into details, I'll read on first, maybe we agree more than I upfront think ;-)
"heiko.braun(a)jboss.com" wrote :
| Building an API doesn't necessarily mean throwing away what's there, it could as well mean refactoring the existing one.
|
| The API will have core elements and terminology. Each core elements has associated semantics which lead to implementation detail. We want the API to be correct, easy to use and easy to learn.
|
| The process of finding these core elements (or core concepts) and establishing names for them is important to get one step closer to 'correctness'.
|
|
Establishing names... great (read my lips: no-more-mapping).
finding common elements or more complex elements (like different gateways) and use those in jbpm... ehh... jpdl, great, but that is process language. The gateway (decision in jpdl) is not something I've ever used from 'the' api...
Basic things I did do with 'the api' are
- start a process
| - end a process
| - signal process to continue (either via default or supplied transition)
| - set a variable
| - read variable
| - get a tasklist
| - end a task
| - get basic properties of a task/node/.... in a process instance (e.g. task.hasEnded())
| - ...
|
|
| Although... working on tasks is already more complex. In jpdl you can have variables with a task scope, or on the process level. It has to be clear how to do that and should be possible via an api. In howfar this is possible in all process languages I'm not sure, so should this be generic? Or put in a more process language specific api, e.g. on that extends the basic api?
|
| "heiko.braun(a)jboss.com" wrote :
| |
| | The well known list of 'basic concepts', which Thomas suggested, is merely a collection of core elements that will lead to both a meaningful set of API that can represent of large number of use cases to begin with, but at the same time covers critical areas of the engine implementation. At least that's the idea.
| |
|
| You mean language implementation instead of engine implementation right? To me an 'engine' is the implementation of a language on the pvm. Regarding the number of use cases I wonder if this is from a theoretical of practical view. As Bernd points out the flexibility of jBPM/JPDL and the way you can use the current api is one of its usp`s
|
| "heiko.braun(a)jboss.com" wrote :
| | If the list is incomplete or the terminology is somehow misleading then make suggestions how it could be changed.
| |
|
| Terminology is imo certainly not misleading, but the collection of concepts is, well not misleading, but maybe to theoretical, or as mentioned earlier something that belongs in a process language
|
| "heiko.braun(a)jboss.com" wrote :
| | Again this doesn't necessarily mean we ditch the existing jBPM4 code base, it's merely a process of verification.
| |
| | That is what, to a great extend, has been done the last years, hence we are now where we are with the api and language constructs. Verification against real live usecases and not just theoretical usecases (workflow patterns) or a non-excutable, visual definition (bpmn)
|
| That BPMN is eventually becoming more popular, the alignment of BPMN 2.0 with XPDL and a usable (free) editor, the time is now indeed right to leverage it more, but *without* losing the flexibility.
|
| "heiko.braun(a)jboss.com" wrote :
| | If the current code base would already have a precise and 'to the point' API, then we wouldn't need to do it.
| |
|
| The 'current, 3.x' api has grown, and once you know it (it is not hard to learn if you use it) is not to bad. It's not as to the point as it could be but that is something Tom was/is working on for jBPM4 (afaik) before this common api discussion started.
|
| "heiko.braun(a)jboss.com" wrote :
| | Here's how I can picture the meeting:
| | We go through the list of core elements and for each of those we'll first discuss correctness and importance of that element in a BPM world and then secondly match it with jBPM4 elements. Either the BPMN expression is wrong to begin with or unnecessary for jBPM4 (no use case) then we can ditch it right away. But if it turns out to be important then it will either have a representation in jBPM4, just differently named or it requires changes to the code base.
| |
|
| Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
|
| What I think is more important is what we want to do with the (basic) api. Three things (quickly from my head, not complete maybe)
| - work on individual process instances
| | - signalling
| | | - setting properties
| | | - reading properties (
| | | - working on (a set) tasks
| | - getting a tasklist
| | | - ending a task
| | | - setting variables/propperties/...
| | | - advanced things
| | - get a tasknode in a process-definition and create a task on it
| | | - ending specific tasks on other nodes if something happens
| | | - ...
| | |
| |
|
| Why these advanced things? Because up to now you could not do everything in the jpdl language (but also were not limited to it!!!!) but had to write some small (often reusable) javacode to achieve something (see my milestones blog).
|
| Agreeing on a basic api for the first two items will not be hard at all with using BPMN terminology. Extending the language or providing additional node implementations via javacode so more bpmn elements are provided out of the box is also something we can agree on
|
| The third item has a lot to do with the process language. In my milestone example I explicitly create a task from another node. In another upcomming example, I send the other node an event/signal/trigger (yes, we should standardize here ;-)) so it can create the task itself. Probably fits better in BPMN, but are these kinds of events supported? Currently looking into that.
|
| Maybe we should have two api's per 'language', one basic that is common across process/workflow languages and an advanced one specifically for a language. For jpdl, the advanced api can be the jbpm api that is currently there. I'm just not sure though how pageflow, threadcontrol will fit in thebasic api (terminology wise) if that is a goal at all.
|
| "heiko.braun(a)jboss.com" wrote :
| |
| | But we'll start with a small set, and then gradually increase to the API until it is feature complete. In the beginning, the API would not allow you todo everything jBPM4 is currently capable of, but sooner or later it will.
| |
| Two things:
| - Feature complete by the GA release? That is sooner than later.
| - jBPM4 currently is not capable of 'anything' (ok exaggerated a little). The (new(er)!!) api`s are (were?) under development, JPDL4 is under development (maybe new language constructs like support for different gateways out of the box)
|
| Two things I cannot stress enough:
| - backwards compatibility needs to be there....
| - do not underestimate the current flexibility of jBPM (jpdl) and how it is used in other products
|
| Good discussion btw... lets keep it going, maybe the november meeting will be short then and we'll have lots of time to get used to kasteelbier ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180991#4180991
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180991
17 years, 6 months