13 Replies Latest reply on Jul 20, 2009 4:55 PM by Gurkan Erdogdu

    Implement WorkContextProvider Check

    Gurkan Erdogdu Newbie

      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

        • 1. Re: Implement WorkContextProvider Check
          Jesper Pedersen Master

           


          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.

          • 2. Re: Implement WorkContextProvider Check
            Gurkan Erdogdu Newbie

            I have implemented partial of Chapter 11.

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

            Thanks;

            • 3. Re: Implement WorkContextProvider Check
              Jesper Pedersen Master

              The patches looks good.

              But if I could get you to run

              ant checkstyle
              


              and update the patches, that would be great :)

              • 4. Re: Implement WorkContextProvider Check
                Gurkan Erdogdu Newbie

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

                Thanks;

                • 6. Re: Implement WorkContextProvider Check
                  Gurkan Erdogdu Newbie

                   

                  "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;

                  • 7. Re: Implement WorkContextProvider Check
                    Jesper Pedersen Master

                    Applied.

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

                    Thanks for the contribution :)

                    • 8. Re: Implement WorkContextProvider Check
                      Jeff Zhang Newbie

                      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.

                      • 9. Re: Implement WorkContextProvider Check
                        Gurkan Erdogdu Newbie

                        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;

                        • 10. Re: Implement WorkContextProvider Check
                          Jesper Pedersen Master

                          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 !

                          • 11. Re: Implement WorkContextProvider Check
                            Gurkan Erdogdu Newbie

                             

                            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.

                            • 12. Re: Implement WorkContextProvider Check
                              Jesper Pedersen Master

                              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

                              • 13. Re: Implement WorkContextProvider Check
                                Gurkan Erdogdu Newbie

                                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