Security: Added: Public

While reviewing the document, I found no factual technical errors. Following is a list of other problems I found. 

Not being a native speaker, I suggest next time having a native speaker review these documents as I'm sure I didn't catch all the spelling errors, typos and stuff.

General comments:
- Comments in examples are word-wrapped in a way that usually one word overflows to the next line - this leaves tons of unused space on the page and looks unprofessional. If resolved, document gets shorter and better looking.
- Also, the color of the comments (along with the background color) makes them very very hard to read.
- When talking about specific methods (such as "take" or "execute") it would be cool if these were somehow "annotated" to show this isn't just another text. A Courier font perhaps?
- The previous note also applies to class names. The occurences are too many to mention.
- When there are comments in XML examples, their opening and closing chars (<>) are not in the usual comment color.
- Make sure that, when JBoss is mentioned, it's JBoss and not jboss. The same goes for jBPM, XML etc.
- "Justify" text-alignment looks great for print, I suggest we use it.
- 3.5.1.1: "Let's define a business process is a description of the way..." (The 'Let's define a business process' should IMHO be quoted.)
- 3.7.3: The section is completely void of any information; removal suggested.
- 7.1, last listing - completely wrong syntax highlighting.
- 8.9: "For an example on how to do this, check out the Fork and Join node implementation in the jbpm source code :-)." (A link would be good, or just remove the smiley to make it look less like we are challenging our customers."
- 10.11: "People interested in contributing should check the jboss jbpm jira issue tracker for more details." (URL would be nice, also it's JBoss and jBPM and JIRA.)
- 13.6 and 13.7:and 19.3 and perhaps also someplace else: Looks very unprofessional to me to have these "TODO" sections there, some of them don't even provide any information. I suggest re-phrasing or removal.
- 15.1.3: "Setting notify to yes, true or on will cause jBPM to send an email to the actor that will be assigned to this task." (The possible values should be separated from the regular text somehow.)
- 16.1: "(wow, that a lot of seq's in there :-s )." (Is that really necessary there?)
- Index: contains only one item. Is this intentional?

Language-wise problems (delimited by asterisks):
- 1.6 The JBoss jBPM identity component: "The model used in the identity component is richer th*e*n the traditional servlet-, ejb- and portlet models."
- Tutorial: "The examples can also be *fond* in the jBPM download package in the directory src/java.examples."
- 3.1.1: "The IDE is buil*d* around the grammar of a language."
- 3.1.1: "*Where* ten years ago, the biggest part of a developer was spend on writing code."
- 3.1.2.1: "The Graph Oriented Programming implementation technique *is* only targets process languages that are..."
- 3.2.3: "Let's assume that the execute implementation of the doubleCheck's task node *is* adds an entry into ..."
- 3.2.4: "An Action is also a command*s* with an execute method."
- 3.2.4: "All the actions will be executed with the event *fires*."
- 3.2.5: "An execution starts when an event is sen*d* to the execution."
- 3.2.5: "By default, all of these propagation*'s* are done as nested method calls." (repeated)
- 3.2.5: "So the execution can have trave*l*ed over multiple nodes..."
- 3.3.2: "Let's go *though* the steps to extend the Graph Oriented Programming model..."
- 3.3.3: "An invoke will start *of* a new sub process."
- 3.3.4: "The command executor *take* the message from the queue and invokes..."
- 3.4.3: "Graph oriented programming on itself does not*'t* support analytical algorithms..."
- 3.6: "When the BPM engine can be completely integrated into a software development project and when even the BPM engine's database tables *in* integrated into..."
- 3.7.2: "Then other products added and packaged together with the BPM server *to become* a complete BPM suite."
- 6.2.4: "This is done to get people up and running as fast as possible without having to worr*ie* about classpaths."
- 6.2.4: "Previous incompatibilities between a jboss version and a p*e*rticular ehcache version..."
- 6.4: "Make sure that you bind the datasource to an XA datasource in case you're using more th*e*n 1 resource."
- 7.1.4: "To execut*ion* this script with DBVisualizer, you select 'Database->Execute'."
- 8.3.4: "The first transition for which the conditions resolve*s* to 'true' will be taken."
- 8.4: "If more th*e*n one transition has the same name, the first transition..."
- 8.8: "The path of execution of the super process will wait *till* the sub process instance has ended."
- 10.2.1: "A task instance maintains it*'*s state by means of date-properties..."
- 10.2.2: "Task instances can be signa*l*ing. A signa*l*ing task instance is a task instance that, ..."
- 10.2.2: "When no tasks are created on entrance of this node, execution waits in the task node *till* tasks are created."
- 10.3.4: "*So* specify the pooled actors, use one of the following:" (To?)
- 10.4: "The controller can be used to create* *populate and submit variables between"
- 10.11: "jBPM has only knowledge about actorId*'*s and they are represented as ..."
- 13.3: "Jobs that are locked for more then 30 minutes (by default) will be unlocked so that they can be executed by another job." (Doesn't make much sense to me.)
- 13.3: "Non-Repeatable reads are a problem for optimistic locking and *therefor*, isolation level READ_COMMITTED is not enough *cause* it allows for Non-Repeatable reads to occur."
- 13.4: "When using jBPM's built-in asynchronous messaging, messages will be sen*d* by persisting..."
- 13.5: "The asynchronous continuations feature*,* opens up a new world of jBPM usage scenarios."
- 13.5: "Where typically*,* jBPM is used for mode*l*ing business processes, it can now be used from a more technical perspective."
- 13.5: "That typically requires quite a bit *if* difficult set* *up ... "
- 15.1.4: "Similarly as with assignments, emails can be sen*d* as a task reminder."
- 15.3.2: "This is a string that serve*r*s as the identifier of the process participant."
- 16: "As the runtime data of a process execution changes, all the delta*'*s are stored in the logs." (The same repeats in the last paragraph.)
- 16: "E.g. how much time is spen*d* on average in each step of the process* *? Where are the bottlenecks in the process* *?"
- Basically everywhere: it's not "message driven," "process oriented" etc. It's "message-driven," "process-oriented"...

Assigning this issue back to Darrin as my work here is hopefully done.

Items still to be done:

* Dealing with wrapping of source code samples
* tagging of methods, classnames
* correct capitalisation of product names (I did the few I noticed)

"Justify" text-alignment looks great for print, I suggest we use it.
I agree but the document style sheets are out of my control.

- 16.1: "(wow, that a lot of seq's in there :-s )." (Is that really necessary there?)
Not sure what is being referred to here

- Index: contains only one item. Is this intentional? 
I'm not sure that the story is with the index.  It isn't something that is manually included.  There is an element somewhere that causes the docbook processor to do 'hey I need an index to store this item'.

Note to self: raise a JIRA to push these changes back into the jBPM source docs

>> - 16.1: "(wow, that a lot of seq's in there :-s )." (Is that really necessary there?)
> Not sure what is being referred to here 

There is a sentence "(wow, that a lot of seq's in there :-s)." in section 16.1 which, in my opinion, is totally childish and unnecessary.

>> "Justify" text-alignment looks great for print, I suggest we use it.
> I agree but the document style sheets are out of my control. 

Would you, please, suggest to the responsible people to include these changes next time? There's also the syntax highlighting issues that I expect are out of your control for the same reason.

'lot of seqs' comment has been removed.

Changes have been made & updated on the online docs

Diffs for upstream changes have been attached in https://jira.jboss.org/jira/browse/JBPM-1808

Assigning to QE to verify that the change is (also) in the 4.3 CP01 docs.

The document has seen significant improvements since I last read it - great work! The following are some glitches that I found.

2.1: The first code example has some characters converted to XML entities.
2.2: The example has no source code highlighting.
2.3: And one more time.
3.2: Pictures of the classes are too large IMO for the amount of information that they actually carry. Also, please, use anti-aliasing for all the images, so that the ends of transitions look nice.
3.3.3: "... this feature is important *to handle break down large* models in smaller blocks.
8.2: The process graph has no transitions from start node and only one transition to end node. (Arrows aren't prroperly connected.)
10.3.2: Misrendered arrows in fog 10.1
19.1: Fig 19.1 could be made to look much better if the lines were straight.
19.2.3: No highlighting in the code example.

As usual, I found no factual errors, perhaps except the following. Chapter 7.2 mentions the database schema changes - I can't find the JIRA issue right now, but there has been some problems and discussion around much more schema changes going from SOA-P 4.3 GA -> CP01. So you might want to ask Trevor or Julien about it, in case there have been more changes than documented.

And of course, reassign this back to me once you want the updated document reviewed.

Ok, I've transferred the new feedback to SOA-1172

Can you resolve this issue if you are happy that the earlier fixes (ie the ones from 4.2.CP03) are all ok 

Also re: "full justified text" , it does look good but it is actually harder for people to read.  There have been a few studies that show this.  I think it has something to with it being hard for your eyes to track from the end of one line to the start of the next.  

Ok, closing.