Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-4553

KEW is publishing services to the registry with bad service names like "enWorkflowUtilityService", etc.

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.0-m8, 2.0
    • Component/s: Development
    • Labels:
      None
    • Rice Module:
      KEW
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Here's an example from KewServiceBusSpringBeans.xml.

      <bean parent="kewLocalServiceExporter">
      	<property name="remotedServiceRegistry" ref="enServiceInvoker"/>
      	<property name="serviceDefinition">
      		<bean class="org.kuali.rice.ksb.messaging.JavaServiceDefinition">
      			<property name="service">
      				<ref bean="enWorkflowUtilityService" />
      			</property>
      			<property name="localServiceName" value="enWorkflowUtilityService" />
      			<property name="serviceNameSpaceURI" value="" />
      			<property name="priority" value="3" />
      			<property name="retryAttempts" value="0" />
      			<property name="busSecurity" value="${secure.workflowutility.javaservice.endpoint}"/>
      		</bean>
      	</property>
      </bean>
      

      This was added in 1.0.2.1 for KULRICE-3721. This is because the service name in spring is enWorkflowUtilityService (no namespace when it's looked up) but the service is being published to the bus with a QName like the following:

      new QName(<application's service namespace>, "WorkflowUtilityService")

        Attachments

          Activity

          Hide
          ewestfal Eric Westfall added a comment - - edited

          As I mentioned, I'm pretty sure this was done so that the exported/published service names would match the name of the spring beans:

          enWorkflowUtilityService
          enWorkflowDocumentActionsService

          I think the solution here is to get rid of the "en" versions and rename the spring beans in KEWSpringBeans.xml to:

          WorkflowUtilityService
          WorkflowDocumentActionsService

          Which is the name these services have always been published under in the past (and they are still published under that name now).

          However, we still need to deal with the "namespaceUri" portion of the QName. Part of this problem here too is the fact that each application publishes the service with it's own service namespace as the namespaceUri.

          So, for example an application with the service namespace of "TRAVEL" will publish the service as:

          {TRAVEL}

          WorkflowUtilityService

          Where as the standalone server publishes the service as:

          {RICE}

          WorkflowUtilityService

          This allows for the rice standalone server to figure out how to "call back" into the client based on it's service namespace.

          So all of this complicates the situation, in general i think we need to review how we publish, name, and namespace services as part of Rice 1.1.

          Show
          ewestfal Eric Westfall added a comment - - edited As I mentioned, I'm pretty sure this was done so that the exported/published service names would match the name of the spring beans: enWorkflowUtilityService enWorkflowDocumentActionsService I think the solution here is to get rid of the "en" versions and rename the spring beans in KEWSpringBeans.xml to: WorkflowUtilityService WorkflowDocumentActionsService Which is the name these services have always been published under in the past (and they are still published under that name now). However, we still need to deal with the "namespaceUri" portion of the QName. Part of this problem here too is the fact that each application publishes the service with it's own service namespace as the namespaceUri. So, for example an application with the service namespace of "TRAVEL" will publish the service as: {TRAVEL} WorkflowUtilityService Where as the standalone server publishes the service as: {RICE} WorkflowUtilityService This allows for the rice standalone server to figure out how to "call back" into the client based on it's service namespace. So all of this complicates the situation, in general i think we need to review how we publish, name, and namespace services as part of Rice 1.1.
          Hide
          ewestfal Eric Westfall added a comment -

          In thinking about this one, we should definately use our URL-based namespace values for the publishing of our services, which would be like the following:

          The issue here is how we acquire services when they aren't deployed locally. It seems what we need to do is have our resource loaders that wrap our spring contexts read the service exporters that are contained therein and make only those services that are exported available through the resource loader interface to the module.

          As part of this though, would need to determine how to deal with non-remoted service beans (like transaction managers, datasources, etc., or even ServiceBus in the KSB module). In those cases, if possible, it would be great if those could be injected as needed or, if they need to be available to other modules, just exporting them locally using the local service definition with a ServiceBusExporter.

          Show
          ewestfal Eric Westfall added a comment - In thinking about this one, we should definately use our URL-based namespace values for the publishing of our services, which would be like the following: http://rice.kuali.org/ksb/v2_0 http://rice.kuali.org/kew/v2_0 http://rice.kuali.org/kim/v2_0 etc... The issue here is how we acquire services when they aren't deployed locally. It seems what we need to do is have our resource loaders that wrap our spring contexts read the service exporters that are contained therein and make only those services that are exported available through the resource loader interface to the module. As part of this though, would need to determine how to deal with non-remoted service beans (like transaction managers, datasources, etc., or even ServiceBus in the KSB module). In those cases, if possible, it would be great if those could be injected as needed or, if they need to be available to other modules, just exporting them locally using the local service definition with a ServiceBusExporter .
          Hide
          ewestfal Eric Westfall added a comment -

          I have fixed workflowdocumentactionservice which is now publishing to the registry under the name:

          {http://rice.kuali.org/kew/v2_0}

          workflowDocumentActionsServiceSoap

          Show
          ewestfal Eric Westfall added a comment - I have fixed workflowdocumentactionservice which is now publishing to the registry under the name: {http://rice.kuali.org/kew/v2_0} workflowDocumentActionsServiceSoap
          Hide
          riceci Rice-CI User (Inactive) added a comment -

          Integrated in rice-trunk-nightly #111 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/111/)
          KULRICE-4555, KULRICE-5005, KULRICE-4553 - ensured that new KEW services are getting published properly to the bus

          Show
          riceci Rice-CI User (Inactive) added a comment - Integrated in rice-trunk-nightly #111 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/111/ ) KULRICE-4555 , KULRICE-5005 , KULRICE-4553 - ensured that new KEW services are getting published properly to the bus
          Hide
          jcoltrin Jessica Coltrin (Inactive) added a comment -

          This appears to be fixed by Jason's commit, but not resolved. So I'm resolving it.

          Show
          jcoltrin Jessica Coltrin (Inactive) added a comment - This appears to be fixed by Jason's commit, but not resolved. So I'm resolving it.
          Hide
          jcoltrin Jessica Coltrin (Inactive) added a comment -

          Closing since these items are now in the release notes.

          Show
          jcoltrin Jessica Coltrin (Inactive) added a comment - Closing since these items are now in the release notes.

            People

            • Assignee:
              ewestfal Eric Westfall
              Reporter:
              ewestfal Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 week
                1w
                Remaining:
                Remaining Estimate - 1 week
                1w
                Logged:
                Time Spent - Not Specified
                Not Specified