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.
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.
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:
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.
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:
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.
Sent from my iPhone
On Oct 13, 2010, at 6:32 AM, "Carroll, Timothy Dale" <email@example.com> 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?
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)
This will require your clients to have a db connection with access to the krsb* tables in the standalone rice database.
From: firstname.lastname@example.org [email@example.com] On Behalf Of Carroll, Timothy Dale [firstname.lastname@example.org]
Sent: Tuesday, October 12, 2010 11:49 PM
Subject: Re: [kuali] Add Service to Bus
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?
On Oct 12, 2010, at 10:30 PM, Carroll, Timothy Dale wrote:
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.
On Oct 12, 2010, at 8:04 PM, Carroll, Timothy Dale wrote:
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.