javadoc feedback

[tom.baeyens]

i revised the javadoc updates in the wiring some comments. please check the updates carefully so that you can see how i want things different

some general comments:

* only document things that are not clear from the code or bare javadocs itself. less text means that it's easier to find the information you're looking for. only document if it really adds value to the code or javadocs.

* take into account how javadocs get generated. You have the classname or methodname and then behind it comes the first line. Leverage this by starting javadocs as if the classname or method name was in front of it. that also creates much more conseise docs.

* only relevant document API. (eg. exception constructors don't need to be documented as we're the only ones using them and they speak for themselves)

* in the wirecontext, there are some things left todo

next:

* can you run the coverage tests ?
then you can find out what features are not tested. Often a lot of error conditions are not tested. Good exception messages are part of the API. Running the coverage tests and adding tests for those exceptions often is a good way of finding out which exceptions need to be documented in the javadocs.

* check field transactionName in WireDefinition. not sure if this is feasible for you as it requires a lot of background information on what the transaction is for and how it's used. you if you want you can describe on this forum how you would move it to the environment.

[porcherg]

check field transactionName in WireDefinition. not sure if this is feasible for you as it requires a lot of background information on what the transaction is for and how it's used. you if you want you can describe on this forum how you would move it to the environment.

I am not sure I understand what a transaction is.
Here is what I've understood from reading the code: In a wire context, we can specify a resource to be associated to a transaction, and then, when the context is being closed, the associated resources are committed or rolled back.

Is a transaction only associated with a block context or each context can define its own transaction ?

If only the block context has a transaction, we could move the transactionName to the EnvironmentFactory. During the parsing of the environment xml, we could modify StandardTransactionBinding to push the created TransactionDescriptor into the Parse. We can later get the descriptor of the Transaction from the parse to set a transactionName field in the environmentFactory (and then set it in the created environments).

Can this modification work ?

Guillaume

[tom.baeyens]

"porcherg" wrote:
Is a transaction only associated with a block context or each context can define its own transaction ?

That is indeed the point. A transaction only makes sense on a block context.

"porcherg" wrote:

If only the block context has a transaction, we could move the transactionName to the EnvironmentFactory. During the parsing of the environment xml, we could modify StandardTransactionBinding to push the created TransactionDescriptor into the Parse. We can later get the descriptor of the Transaction from the parse to set a transactionName field in the environmentFactory (and then set it in the created environments).

Can this modification work ?

From the sound of it, that is what i want. You can go ahead and make this change.

I have ported test org.jbpm.msg.MemMessageServiceTest into pvm. That test is succeeding now. If that test succeeds after you made the change, check in and ping me here.

[porcherg]

Pushing the StandardTransactionDescriptor in the Parse does not work because the WireParser pushes aWireDefinition, then pops the first element of the parse (WireDefinition before, the transaction descriptor with my first idea)

I don't think a modification in the WireParser is a good solution. I tried to have the same result by just searching for a StandardTransactionDescriptor in the block wireDefinition.

With this method, the test succeeds.

I've just submitted my modifications.

I have also removed the argument 'objectName' from the method 'processPendingInitialization' in WireContext (this argument was not used in the method)

Guillaume