Implement WorkContextProvider Check

[gurkanerdogdu]

Hi;

I am trying to implement WorkContextProvider error conditions when RA submits work instance that implements WorkContextProvider to the application server. (Chapter 11.4.3)

Is it ok to add code into the WorkManagerImpl#verfiyWork.

Also, which WorkContexts will be supported by the JBoss?

Thanks;

--Gurkan

[jesper.pedersen]

Is it ok to add code into the WorkManagerImpl#verfiyWork.

verifyWork is a check for spec compliance - so I would say something like setupWorkContextProviders would be better.

You can see how test case against the WorkManager are implemented in the core module also. There is a section in the developer about the 3 levels of test cases that we should have.

Also, which WorkContexts will be supported by the JBoss?

The 1.0 implementation should support all the contexts listed in the spec.

[gurkanerdogdu]

I have implemented partial of Chapter 11.

See https://jira.jboss.org/jira/browse/JBJCA-112

Thanks;

[jesper.pedersen]

The patches looks good.

But if I could get you to run

ant checkstyle

and update the patches, that would be great :)

[gurkanerdogdu]

Sure. Is there any eclipse formatter file that I can use ?

Thanks;

[jesper.pedersen]

Jeff, can you create a page under http://www.jboss.org/community/wiki/JBossJCAPOJO called

http://www.jboss.org/community/wiki/JBossJCAPOJODevelopment

where you'll attach your Eclipse files ?

[gurkanerdogdu]

"jesper.pedersen" wrote:
The patches looks good.
and update the patches, that would be great :)

I updated attachments after running checkstyle tool and correcting implementation. New attachments are suffixed with ".patch".

I am not able to remove old attachments from jira, perhaps I have no enough permission to do this.

Thanks;

[jesper.pedersen]

Applied.

There were a couple of .undeploy() missing the test cases - I added those. Plus made it compile using JDK5.

Thanks for the contribution :)

[jeff.zhang]

Hi Gurkan,

Please see
http://www.jboss.org/community/wiki/JBossJCAPOJODevelopment

JBoss community use http://www.jboss.org/eclipse-settings.xml.zip as eclipse formatter.
And we JCA team also use checkstyle for addition code style.

hope useful.

[gurkanerdogdu]

Hi;

As I re-read chapter 10 and 11, "WorkCompletedException" may be thrown after a "Work" instance is run by a WorkManager (i.e, after it is accepted and started). In chapter 11, spec. says that if the "WorkManager" fails to setup work contexts that are provided by the "Work" instance before running the work instance, it throws WorkCompletedException with specific error codes.

In my implementation, I put "setupWorkContext" code into the "doWork,startWork,scheduleWork" section of the WorkManagerImpl. It means that, exception may be thrown by the time resource adapter submits works to the manager, so we are able to catch wrong submissions early.

Is it true or we have to change the location of the "setupWorkContext" to other place?

I am confused here.

Thanks;

[jesper.pedersen]

Figure 11-1 shows that the getWorkContexts() method is called by the WorkManager after the Work instance has been submitted by doWork(), startWork() and scheuleWork().

Chapter 10.3.3.5 states that a WorkCompletedException can be thrown with an appropriate error code which in this case is one of the WorkContextErrorCodes.

There is a bit more work in regards to custom contexts if you see the last paragraph in 11.4.2 - the container must always check the most specific context first - and then go up the in hierarchy to find a supported one.

You can just attach a single patch with all the changes needed if you don't want to split the patch into separate pieces. And more tests are always good :)

You can get additional checkstyle checks by uncommenting

<module name="UnusedImports"/>

in tools/checkstyle/checkstyle.xml. A couple of checkstyle bugs does that we can't enable this module by default at the moment.

Thanks for your contributions !

[gurkanerdogdu]

Figure 11-1 shows that the getWorkContexts() method is called by the WorkManager after the Work instance has been submitted by doWork(), startWork() and scheuleWork().

Chapter 10.3.3.5 states that a WorkCompletedException can be thrown with an appropriate error code which in this case is one of the WorkContextErrorCodes.

Then, place that I put "setupWorkcontext" is wrong. I have to setup work contexts just before "Work" is run by the "WorkManager".

In current codebase, it seems that there are several different methods that are responsible for setting up "ExecutionContext", namely "WorkManagerImpl#importWork" and "WorkManagerImpl#startWork". *Import* work is called by the "doWork()..." methods but *Start* work is called from "WorkWrapper#execute" method. But according to the spec., context has to be setup after *Work* is accepted and just before it is run. Then it seems that current implementation is wrong because context is imported before submitting work instance via "importWork" method.

AFAIK from the specification, execution context is setup in "start" phase of the work lifecycle (submit->accept->start). And again according to the specification, if execution context is not setup succesfully within "start" phase, it throws "WorkCompletedException".

But in WrapperImpl#execute method, it first calls "WorkManagerImpl#startWork" to do some execution context specific actions. If it gets exception it throws WorkRejectedException, otherwise it calls "run" method of the work instance. But spec says to throws WorkCompletedException.

Sorry for pollution, but I do not exactly understand which methods in the codebase correspond to work's lifecycle phases "submitted, accepted, rejected, started and completed". Therefore, I do not know where to put "setupWorkContext" implementation.

Morever, I guess that current execution context setups has to be changed also using new work context provider semantic. Effected places are "WorkManagerImpl#importWork,startWork, cancelWork,endWork" methods.

There is a bit more work in regards to custom contexts if you see the last paragraph in 11.4.2 - the container must always check the most specific context first - and then go up the in hierarchy to find a supported one.

Specification says that this must done by the resource adapter before it submits work instance to the server via BootstrapContext#isContextSuported.

I think that this is not related with the application server. Currently, I checked specific context support via method "WorkManagerImpl#getSupportedWorkContextClass(Class". This method checks given context class with application server supported context classes using ".equals". If it does not support specific instance, it falls through "super class" of the adaptor context class.

[jesper.pedersen]

The WorkContext's must be setup in the work thread before run() is executed.

So the best place for this would be WorkManagerImpl::startWork(WorkWrapper) as we need to interact this the rest of the container in regards to the TransactionContext and SecurityContext.

I agree that the layout of the WorkManagerImpl class could be a bit better - limit duplicated code, more logging and so on.

Feel free to reorganize the WorkManagerImpl class such that each phase is better described.

HTH

[gurkanerdogdu]

I updated patches. I removed duplicates from WorkManagerImpl and tidy up code. I also updates WorkWrapper implementation to add "setupWorkContextProviders".

I also added test for "WorkContextLifecycleListener".

Thanks;

--Gurkan