Details

    • Similar issues:
      KULRICE-6683Add a "THIN" client run mode to KEW, KIM, and KSB modules
      KULRICE-2695Create a rice-sample-applications repository in SVN and update sample embedded and thin client examples from 0.9.2/0.9.3 and put them in there
      KULRICE-9588Correct KEW documentation on implementing a thin client
      KULRICE-6360Remove RunMode.THIN and other traces of legacy "THIN" mode as it is no longer needed
      KULRICE-2983Update thin client integration model so that it provides for proper connection to KIM services
      KULRICE-7991Refactor client side state handling
      KULRICE-2817Deploy thin client sample app to test environment
      KULRICE-3784KEW Thin Client integration does not work properly
      KULRICE-7573The standalone version of WorkflowDocumentActionsService should always be called when kew.mode is Thin or Remote
      KULRICE-3783Reduce client-side library dependencies for KEW thin client applications
    • Rice Module:
      Rice Core
    • Application Requirement:
      Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      I've prepared a patch (attached) that provides some Rice refactoring, per an email thread that transpired last year (see comments). The re-factor tackles four items:

      1. Creates plug-ability in the Rice Thin Client via Spring and Rice configuration
      2. Changes the Thin Client paradigm from KEW centric to Rice centric
      3. Establishes a starting point (KEDL) for making EDocLite a separate module
      4. Exposes KEDL services on the bus and adds ThinClient access to that service

      1. sample-thinclient-beans.xml
        4 kB
        tim carroll
      2. sample-thinclient-config.xml
        2 kB
        tim carroll
      3. sources.diff
        95 kB
        tim carroll
      4. summary.diff
        3 kB
        tim carroll

        Issue Links

          Activity

          Hide
          tim carroll (Inactive) added a comment -

          Hi Tim, yes we could set up a code review to go through what you did and see if it makes sense to integrate it. Just get in touch once you are ready.

          Thanks,
          Eric

          On Oct 18, 2010, at 6:47 PM, Carroll, Timothy Dale wrote:

          Hah... Agreed. Whoever made those comments didn't pull any punches...

          I'm in that code making some changes to facilitate some of our needs. In the end, I believe it will be incrementally better, although there will still be some work to do per your comments. Would you guys be willing to do a code review and consider it for trunk? I'd rather not have to track and apply the changes again.

          Thanks, Tim

          On Oct 15, 2010, at 5:02 PM, Westfall, Eric Curtis wrote:

          Well now, those are some brutally honest comments Unfortunately it looks like they never made it into a jira issue.

          I think this code is essentially ensuring the the Rice resource loader stack is "stacked" correctly, as per the diagram on this page:

          https://wiki.kuali.org/display/KULRICE/Diagram+Scratch+Page

          Essentially, local services should be loaded first, then those from plugins, and lastly those which are being accessed remotely from the service bus. So it first invokes the method on KEWConfigurer which initializes and starts the plugin registry and then decides it will go ahead and place it on the resource loader stack itself (notice how the addModulesResourceLoaders method on RiceConfigurer doesn't actually do anything with the result of KewConfigurer.getResourceLoaderToRegister).

          After that it asks the KSB for it's resource loader to register (this is the "RemoteResourceLoader" which knows how to create proxies to remote services) and then it adds that to the resource loader stack. Note that while we call this thing a "stack" the addResourceLoader method on GRL actually puts it on the bottom.

          I think the main problem with this code is that KEWConfigurer.getResourceLoaderToRegister() is actually side affecting the GRL. If we were going to do that, we should just rename the method to "registerResourceLoaders" and then pass GRL.getRootResourceLoader() into it. Then it could handle publishing to the GRL as it sees fit. The same could be done with the KSB equivalent of this method.

          There are other problems in the code surrounding Rice configuration (namely, the RiceConfigurer is what I would call a "god object"). I think that some of them will be addressed with some of the work we are doing for Rice 1.1.

          Thanks,
          Eric

          On Oct 15, 2010, at 4:18 PM, Carroll, Timothy Dale wrote:

          Okay. Related to this thread, can someone help me answer the question and call for help posed in the two TODO: comments in the RiceConfigurer.java source? Here is the snippet that I am referring to:

          /**

          • This method decides the sequence of module resource loaders to be added to global resource loader (GRL).
          • It asks the individual module configurers for the resource loader they want to register and adds them to GRL.
          • <p>TODO: the implementation of this method seems like a total HACK, it seems like the implementation on
          • RiceConfigurerBase makes more sense since it is more general, also, very strange how the
          • getResourceLoaderToRegister method on KEWConfigurer is side-affecting. This whole thing looks like a mess.
          • Somebody untangle this, please!
          • @throws Exception
            */
            @Override
            protected void addModulesResourceLoaders() throws Exception {
            if(getKewConfigurer()!=null) { // TODO: Check - In the method getResourceLoaderToRegister of KewConfigurer, // does the call registry.start() depend on the preceding line GlobalResourceLoader.addResourceLoader(coreResourceLoader)? // Ideally we would like to register the resource loader into GRL over here getKewConfigurer().getResourceLoaderToRegister(); }

            if(getKsbConfigurer()!=null)

            { GlobalResourceLoader.addResourceLoader(getKsbConfigurer().getResourceLoaderToRegister()); }

            }

          Thanks a bunch. Tim

          On Oct 13, 2010, at 4:53 PM, Westfall, Eric Curtis wrote:

          Hi tim, yes this does sound reasonable and you are correct in the observation that the kew thin configured is basically a specialized RiceConfigurer that understands how to configure rice for thin client access.

          One point of confusion here may be the fact that thin client does not e en connect to the ksb service registry. As an alternative to the presence of the registry, you have to manually map service names to endpoint urls (as part of thin client configuration). It's currently not very "extensible" to services outside the four or so that it requires...I think that's what you are running into.

          One more thing, you may be able to set a custom rootresourceloader implementation on the thinclientkewconfigurer instead of modifying the thin client RL.

          Thanks, eric

          Sent from my iPhone

          On Oct 13, 2010, at 6:32 AM, "Carroll, Timothy Dale" <tcarroll@illinois.edu> wrote:

          Thanks. I'll keep this in mind as I move forward. I'm not sure how often we will have the need to add new services to the bus, so I'm inclined to help rework the thin client a bit to make it more configurable in this regard.

          I see one inconsistency that may hold the key to solving part of this puzzle. Currently, there appear to be three thin client configurers (KIMThinClientConfigurer, KSBThinClientConfigurer, and ThinClientKEWConfigurer). The KEW one is not only named a bit different, but it acts a bit different too. The KIM and KSB configurers fend for themselves, while the KEW configurer goes out of it's way to pull in the KIM and KSB modules as well.

          It seems like KEW should have a thin client configurer that fends for itself like the other two. Then, the current ThinClientKEWConfigurer should be renamed (removing the KEW specificity) to ThinClientConfigurer to serve as a master thin client configurer, and it should be modified to pull in the new aforementioned KEWThinClientConfigurer.

          Next, the master ThinClientConfigurer and the ThinClientResourceLoader could/should be spring-afied and/or tied to a config file, which would identify which services the thin client wanted to wire up.

          Does this sound like a reasonable approach?

          Regards, Tim

          On Oct 13, 2010, at 12:55 AM, Scott W. Gibson wrote:

          If you are going to do this on a larger scale you probably should move away from the thin client and just use the ksb from your clients. Doing so would eliminate all those additional steps. If you are interested, here is an example of the spring config used by Kuali Student to bring up the ksb in a client (there may be more general examples somewhere on the wiki)

          https://test.kuali.org/svn/student/trunk/ks-core/ks-core-web/src/main/resources/ksb/ks-core-web-context.xml

          This will require your clients to have a db connection with access to the krsb* tables in the standalone rice database.
          ________________________________________
          From: rice.collab@kuali.org [rice.collab@kuali.org] On Behalf Of Carroll, Timothy Dale [tcarroll@illinois.edu]
          Sent: Tuesday, October 12, 2010 11:49 PM
          To: rice.collab@kuali.org
          Subject: Re: [kuali] Add Service to Bus

          ANOTHER UPDATE...

          I ended up writing a service locator as described below and then modifying the ThinClientResourceLoader to include the necessary references to my EDocLite remoting services; however, I don't really like the idea of having to modify the ThinClientResourceLoader each time I add a service. I'm thinking I either need to continue down the path I outlined previously by writing a custom configurer and resource loader for my service... or, perhaps the ThinClientResourceLoader could be a bit more dynamic and configuration based.

          Anyone have any thoughts on that?

          Thanks, Tim

          On Oct 12, 2010, at 10:30 PM, Carroll, Timothy Dale wrote:

          UPDATE.

          I believe the new service is posted to the bus correctly (I can see it in the service registry anyway...); however, the service locator code that I put in place is not finding it. It appears that different service locator techniques have to be used when you are running embedded versus thin client mode. Anyway, it looks like exposing EDocLite remotely is going to require me to dig pretty deep. Without piggybacking on KEW, it looks like I'll have to write a configurer, a service locator, and perhaps a resource loader... in the spirit of ThinClientKEWConfigurer, KEWServiceLocator, and ThinClientResourceLoader respectively.

          Someone please let me know if I'm out in left field.

          Thanks, Tim

          On Oct 12, 2010, at 8:04 PM, Carroll, Timothy Dale wrote:

          Hi All.

          I'm trying to add a service to the bus for exposing EDocLite functions remotely, and it is proving a bit challenging. Can anyone point me to a document that describes how to do this or something similar?

          The configurations to accomplish this seem to be spread over a number of locations, and I must be missing one or more of them.

          Thanks, Tim

          Show
          tim carroll (Inactive) added a comment - Hi Tim, yes we could set up a code review to go through what you did and see if it makes sense to integrate it. Just get in touch once you are ready. Thanks, Eric On Oct 18, 2010, at 6:47 PM, Carroll, Timothy Dale wrote: Hah... Agreed. Whoever made those comments didn't pull any punches... I'm in that code making some changes to facilitate some of our needs. In the end, I believe it will be incrementally better, although there will still be some work to do per your comments. Would you guys be willing to do a code review and consider it for trunk? I'd rather not have to track and apply the changes again. Thanks, Tim On Oct 15, 2010, at 5:02 PM, Westfall, Eric Curtis wrote: Well now, those are some brutally honest comments Unfortunately it looks like they never made it into a jira issue. I think this code is essentially ensuring the the Rice resource loader stack is "stacked" correctly, as per the diagram on this page: https://wiki.kuali.org/display/KULRICE/Diagram+Scratch+Page Essentially, local services should be loaded first, then those from plugins, and lastly those which are being accessed remotely from the service bus. So it first invokes the method on KEWConfigurer which initializes and starts the plugin registry and then decides it will go ahead and place it on the resource loader stack itself (notice how the addModulesResourceLoaders method on RiceConfigurer doesn't actually do anything with the result of KewConfigurer.getResourceLoaderToRegister). After that it asks the KSB for it's resource loader to register (this is the "RemoteResourceLoader" which knows how to create proxies to remote services) and then it adds that to the resource loader stack. Note that while we call this thing a "stack" the addResourceLoader method on GRL actually puts it on the bottom. I think the main problem with this code is that KEWConfigurer.getResourceLoaderToRegister() is actually side affecting the GRL. If we were going to do that, we should just rename the method to "registerResourceLoaders" and then pass GRL.getRootResourceLoader() into it. Then it could handle publishing to the GRL as it sees fit. The same could be done with the KSB equivalent of this method. There are other problems in the code surrounding Rice configuration (namely, the RiceConfigurer is what I would call a "god object"). I think that some of them will be addressed with some of the work we are doing for Rice 1.1. Thanks, Eric On Oct 15, 2010, at 4:18 PM, Carroll, Timothy Dale wrote: Okay. Related to this thread, can someone help me answer the question and call for help posed in the two TODO: comments in the RiceConfigurer.java source? Here is the snippet that I am referring to: /** This method decides the sequence of module resource loaders to be added to global resource loader (GRL). It asks the individual module configurers for the resource loader they want to register and adds them to GRL. <p>TODO: the implementation of this method seems like a total HACK, it seems like the implementation on RiceConfigurerBase makes more sense since it is more general, also, very strange how the getResourceLoaderToRegister method on KEWConfigurer is side-affecting. This whole thing looks like a mess. Somebody untangle this, please! @throws Exception */ @Override protected void addModulesResourceLoaders() throws Exception { if(getKewConfigurer()!=null) { // TODO: Check - In the method getResourceLoaderToRegister of KewConfigurer, // does the call registry.start() depend on the preceding line GlobalResourceLoader.addResourceLoader(coreResourceLoader)? // Ideally we would like to register the resource loader into GRL over here getKewConfigurer().getResourceLoaderToRegister(); } if(getKsbConfigurer()!=null) { GlobalResourceLoader.addResourceLoader(getKsbConfigurer().getResourceLoaderToRegister()); } } Thanks a bunch. Tim On Oct 13, 2010, at 4:53 PM, Westfall, Eric Curtis wrote: Hi tim, yes this does sound reasonable and you are correct in the observation that the kew thin configured is basically a specialized RiceConfigurer that understands how to configure rice for thin client access. One point of confusion here may be the fact that thin client does not e en connect to the ksb service registry. As an alternative to the presence of the registry, you have to manually map service names to endpoint urls (as part of thin client configuration). It's currently not very "extensible" to services outside the four or so that it requires...I think that's what you are running into. One more thing, you may be able to set a custom rootresourceloader implementation on the thinclientkewconfigurer instead of modifying the thin client RL. Thanks, eric Sent from my iPhone On Oct 13, 2010, at 6:32 AM, "Carroll, Timothy Dale" <tcarroll@illinois.edu> wrote: Thanks. I'll keep this in mind as I move forward. I'm not sure how often we will have the need to add new services to the bus, so I'm inclined to help rework the thin client a bit to make it more configurable in this regard. I see one inconsistency that may hold the key to solving part of this puzzle. Currently, there appear to be three thin client configurers (KIMThinClientConfigurer, KSBThinClientConfigurer, and ThinClientKEWConfigurer). The KEW one is not only named a bit different, but it acts a bit different too. The KIM and KSB configurers fend for themselves, while the KEW configurer goes out of it's way to pull in the KIM and KSB modules as well. It seems like KEW should have a thin client configurer that fends for itself like the other two. Then, the current ThinClientKEWConfigurer should be renamed (removing the KEW specificity) to ThinClientConfigurer to serve as a master thin client configurer, and it should be modified to pull in the new aforementioned KEWThinClientConfigurer. Next, the master ThinClientConfigurer and the ThinClientResourceLoader could/should be spring-afied and/or tied to a config file, which would identify which services the thin client wanted to wire up. Does this sound like a reasonable approach? Regards, Tim On Oct 13, 2010, at 12:55 AM, Scott W. Gibson wrote: If you are going to do this on a larger scale you probably should move away from the thin client and just use the ksb from your clients. Doing so would eliminate all those additional steps. If you are interested, here is an example of the spring config used by Kuali Student to bring up the ksb in a client (there may be more general examples somewhere on the wiki) https://test.kuali.org/svn/student/trunk/ks-core/ks-core-web/src/main/resources/ksb/ks-core-web-context.xml This will require your clients to have a db connection with access to the krsb* tables in the standalone rice database. ________________________________________ From: rice.collab@kuali.org [rice.collab@kuali.org] On Behalf Of Carroll, Timothy Dale [tcarroll@illinois.edu] Sent: Tuesday, October 12, 2010 11:49 PM To: rice.collab@kuali.org Subject: Re: [kuali] Add Service to Bus ANOTHER UPDATE... I ended up writing a service locator as described below and then modifying the ThinClientResourceLoader to include the necessary references to my EDocLite remoting services; however, I don't really like the idea of having to modify the ThinClientResourceLoader each time I add a service. I'm thinking I either need to continue down the path I outlined previously by writing a custom configurer and resource loader for my service... or, perhaps the ThinClientResourceLoader could be a bit more dynamic and configuration based. Anyone have any thoughts on that? Thanks, Tim On Oct 12, 2010, at 10:30 PM, Carroll, Timothy Dale wrote: UPDATE. I believe the new service is posted to the bus correctly (I can see it in the service registry anyway...); however, the service locator code that I put in place is not finding it. It appears that different service locator techniques have to be used when you are running embedded versus thin client mode. Anyway, it looks like exposing EDocLite remotely is going to require me to dig pretty deep. Without piggybacking on KEW, it looks like I'll have to write a configurer, a service locator, and perhaps a resource loader... in the spirit of ThinClientKEWConfigurer, KEWServiceLocator, and ThinClientResourceLoader respectively. Someone please let me know if I'm out in left field. Thanks, Tim On Oct 12, 2010, at 8:04 PM, Carroll, Timothy Dale wrote: Hi All. I'm trying to add a service to the bus for exposing EDocLite functions remotely, and it is proving a bit challenging. Can anyone point me to a document that describes how to do this or something similar? The configurations to accomplish this seem to be spread over a number of locations, and I must be missing one or more of them. Thanks, Tim
          Hide
          tim carroll (Inactive) added a comment - - edited

          (attached – summary.diff and sources.diff) the changes that were made to rice 1.0.1.1 to accomplish these goals.

          Show
          tim carroll (Inactive) added a comment - - edited (attached – summary.diff and sources.diff) the changes that were made to rice 1.0.1.1 to accomplish these goals.
          Hide
          tim carroll (Inactive) added a comment -

          (attached – sample-thinclient-beans.xml and sample-thinclient-config.xml) configs required on the rice-application client-side

          Show
          tim carroll (Inactive) added a comment - (attached – sample-thinclient-beans.xml and sample-thinclient-config.xml) configs required on the rice-application client-side
          Hide
          Jessica Coltrin (Inactive) added a comment -

          Eric, what are your thoughts on this?

          Show
          Jessica Coltrin (Inactive) added a comment - Eric, what are your thoughts on this?
          Hide
          Jessica Coltrin (Inactive) added a comment -

          Status on this was requested at both the June and August Collaboration meetings. Per the August collaboration meeting, Tim mentioned that he has interest in his portlet source, but would like to have these changes in the mainline Rice code before that. Followed up with Eric and we're putting it on the agenda for the Thursday Team Leads meeting this week so I can get back to Tim by the end of the week.

          Show
          Jessica Coltrin (Inactive) added a comment - Status on this was requested at both the June and August Collaboration meetings. Per the August collaboration meeting, Tim mentioned that he has interest in his portlet source, but would like to have these changes in the mainline Rice code before that. Followed up with Eric and we're putting it on the agenda for the Thursday Team Leads meeting this week so I can get back to Tim by the end of the week.

            People

            • Assignee:
              Unassigned
              Reporter:
              tim carroll (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Start Date:

                Structure Helper Panel