Uploaded image for project: 'jUDDI'
  1. jUDDI
  2. JUDDI-561

Transaction rollback when PersonName Lang is greater than 5 characters

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.4
    • Fix Version/s: 3.1.5
    • Component/s: core
    • Labels:
      None

      Description

      Basically, there's a lack of validation of the input text for the language field of PersonName and possibly others that causes a rather strange soap fault. The following exert is from the catalina log.

      WARNING: Application

      {urn:uddi-org:v3_service}

      UDDIPublicationService#

      {urn:uddi-org:v3_service}

      save_business has thrown exception, unwinding now
      org.apache.cxf.interceptor.Fault: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred.
      at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:155)
      at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:86)
      at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:121)
      at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:60)
      at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
      at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
      at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
      at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
      at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
      at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
      at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
      at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
      at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
      at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
      at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
      at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
      at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:394)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
      at java.lang.Thread.run(Thread.java:722)
      Caused by: <openjpa-1.2.2-r422266:898935 fatal general error> org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred.
      at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2187)
      at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2029)
      at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1927)
      at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1698)
      at org.apache.openjpa.kernel.QueryImpl.isInMemory(QueryImpl.java:956)
      at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
      at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
      at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
      at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:252)
      at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:294)
      at org.apache.juddi.query.EntityQuery.getQueryResult(EntityQuery.java:128)
      at org.apache.juddi.query.FindEntityByPublisherQuery.select(FindEntityByPublisherQuery.java:83)
      at org.apache.juddi.query.FindBusinessByPublisherQuery.select(FindBusinessByPublisherQuery.java:44)
      at org.apache.juddi.validation.ValidatePublish.validateSaveBusinessMax(ValidatePublish.java:295)
      at org.apache.juddi.api.impl.UDDIPublicationImpl.saveBusiness(UDDIPublicationImpl.java:595)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:601)
      at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:173)
      at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:89)
      ... 31 more
      Caused by: <openjpa-1.2.2-r422266:898935 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: A truncation error was encountered trying to shrink VARCHAR 'Click to edit' to length 5.

      {prepstmnt 2037277748 INSERT INTO j3_person_name (id, lang_code, name, contact_id) VALUES (?, ?, ?, ?) [params=(long) 1452, (String) Click to edit, (String) Click to edit, (long) 1202]} [code=20000, state=22001]
      FailedObject: org.apache.juddi.model.PersonName@3b79b2c6
      at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4244)
      at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4211)
      at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
      at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72)
      at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
      at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
      at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
      at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
      at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
      at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
      at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
      at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:721)
      at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
      ... 51 more
      Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: A truncation error was encountered trying to shrink VARCHAR 'Click to edit' to length 5. {prepstmnt 2037277748 INSERT INTO j3_person_name (id, lang_code, name, contact_id) VALUES (?, ?, ?, ?) [params=(long) 1452, (String) Click to edit, (String) Click to edit, (long) 1202]}

      [code=20000, state=22001]
      at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
      at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
      at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
      at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
      at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1590)
      at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
      at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
      ... 59 more

        Issue Links

          Activity

          Hide
          kurtstam Kurt T Stam added a comment -

          It turns out that the spec actually defines the max length to be 26: http://uddi.org/pubs/uddi_v3.htm#_Ref8977786

          Show
          kurtstam Kurt T Stam added a comment - It turns out that the spec actually defines the max length to be 26: http://uddi.org/pubs/uddi_v3.htm#_Ref8977786
          Hide
          spyhunter99 Alex O'Ree added a comment -

          UDDI section 3.3.2.3 max for lang is actually 26 characters. new patch in the works

          Show
          spyhunter99 Alex O'Ree added a comment - UDDI section 3.3.2.3 max for lang is actually 26 characters. new patch in the works
          Hide
          kurtstam Kurt T Stam added a comment -

          I guess we never implemented any validation on field lengths. If we really want to do it right we'd need to consider length validation of the following fields

          · accessPoint[38]

          · addressLine

          · authInfo

          · description

          · discoveryURL

          · email

          · keyName

          · keyValue

          · name

          · personName[39]

          · phone

          · useType

          see: http://uddi.org/pubs/uddi_v3.htm#_Toc85908305

          Show
          kurtstam Kurt T Stam added a comment - I guess we never implemented any validation on field lengths. If we really want to do it right we'd need to consider length validation of the following fields · accessPoint [38] · addressLine · authInfo · description · discoveryURL · email · keyName · keyValue · name · personName [39] · phone · useType see: http://uddi.org/pubs/uddi_v3.htm#_Toc85908305
          Hide
          spyhunter99 Alex O'Ree added a comment -

          So if we were to make some unit tests to validate string lengths for those parameters, which base project should it go in? The current structure of the tck tests do not make these types of tests easy. It's like the tests were simply designed to make sure that the correct test cases work, not for when incorrect tests case work (which would be a failure)

          here's the min-max lengths. If only one number is listed, then the min length is 0
          lang 26
          bindingKey 255
          businessKey 255
          authorizedName 255
          completionStatus 32
          keyName 255
          keyValue 255
          address sort code 10
          useType 255
          findQualifier 1-255
          instanceParms 1-8192
          accessPoint 1-4096
          description 1-255
          discoveryUrl 1-4096
          email address 1-255
          name 1-255
          overviewURL 1-4096
          personname 1-255
          phone 1-50

          from replication
          controlledMessage_type 1-255
          message_type 1-255
          timeOfConfigurationUpdate_type 1-255
          operatorStatus_type 16
          USN_type int 0-9223372036854775807

          Show
          spyhunter99 Alex O'Ree added a comment - So if we were to make some unit tests to validate string lengths for those parameters, which base project should it go in? The current structure of the tck tests do not make these types of tests easy. It's like the tests were simply designed to make sure that the correct test cases work, not for when incorrect tests case work (which would be a failure) here's the min-max lengths. If only one number is listed, then the min length is 0 lang 26 bindingKey 255 businessKey 255 authorizedName 255 completionStatus 32 keyName 255 keyValue 255 address sort code 10 useType 255 findQualifier 1-255 instanceParms 1-8192 accessPoint 1-4096 description 1-255 discoveryUrl 1-4096 email address 1-255 name 1-255 overviewURL 1-4096 personname 1-255 phone 1-50 from replication controlledMessage_type 1-255 message_type 1-255 timeOfConfigurationUpdate_type 1-255 operatorStatus_type 16 USN_type int 0-9223372036854775807
          Hide
          kurtstam Kurt T Stam added a comment - - edited

          Since this would be good case for 'TCK' module i think it should go there.

          If you want to run the same tests in juddi embedded mode to make debugging and fixing easier (fast turn around), then you can also add common functionality in the tck-base module and use then reference that in the juddi-core API tests.

          Oh and regarding negative testing - those are the best . You can have tests to expect a stack trace and fail if it doesn't. We just have to make sure no stacktraces are printed since that IMO would flag an unexpected behavior in the test. If you want you can copy an existing tests and modify them with different data to make them fail due to length issues. If a test is called TCK_020_** just add a TCK_020-1_** if it is a copy.

          Show
          kurtstam Kurt T Stam added a comment - - edited Since this would be good case for 'TCK' module i think it should go there. If you want to run the same tests in juddi embedded mode to make debugging and fixing easier (fast turn around), then you can also add common functionality in the tck-base module and use then reference that in the juddi-core API tests. Oh and regarding negative testing - those are the best . You can have tests to expect a stack trace and fail if it doesn't. We just have to make sure no stacktraces are printed since that IMO would flag an unexpected behavior in the test. If you want you can copy an existing tests and modify them with different data to make them fail due to length issues. If a test is called TCK_020_** just add a TCK_020-1_** if it is a copy.
          Hide
          spyhunter99 Alex O'Ree added a comment -

          Alright, so if that's the procedure, where are the source xml files? I've been trying to backtrace the unit tests (ehem what are the code documentation suggestions for juddi again?) and I think I've figure out where the code is that loads requests from an xml file, but I can't find them. Was there a particular reason the requests were stored externally instead of being built in code?

          Show
          spyhunter99 Alex O'Ree added a comment - Alright, so if that's the procedure, where are the source xml files? I've been trying to backtrace the unit tests (ehem what are the code documentation suggestions for juddi again?) and I think I've figure out where the code is that loads requests from an xml file, but I can't find them. Was there a particular reason the requests were stored externally instead of being built in code?
          Hide
          kurtstam Kurt T Stam added a comment -
          Show
          kurtstam Kurt T Stam added a comment - They are in the uddi-tck-base module, see http://svn.apache.org/repos/asf/juddi/trunk/uddi-tck-base/src/main/resources/uddi_data/
          Hide
          spyhunter99 Alex O'Ree added a comment -

          Is there a reason for having separate modules for the the TCK base vs the TCK tests?

          Show
          spyhunter99 Alex O'Ree added a comment - Is there a reason for having separate modules for the the TCK base vs the TCK tests?
          Hide
          kurtstam Kurt T Stam added a comment -

          Yes .

          OK the longer answer is that jUDDI can use inVM transport; this means that you bypass the WS stack and can run jUDDI in embedded mode. To test both scenarios we run inVMTransport in the juddi-core, while running WSTransport in the tck module.

          inVM:
          http://svn.apache.org/repos/asf/juddi/trunk/juddi-core-openjpa/src/test/java/org/apache/juddi/api/impl/
          WS:
          http://svn.apache.org/repos/asf/juddi/trunk/uddi-tck/src/test/java/org/apache/juddi/v3/tck/

          To break a circular dependency while building the shared code lives in the tck-base module, which includes the test data.

          Show
          kurtstam Kurt T Stam added a comment - Yes . OK the longer answer is that jUDDI can use inVM transport; this means that you bypass the WS stack and can run jUDDI in embedded mode. To test both scenarios we run inVMTransport in the juddi-core, while running WSTransport in the tck module. inVM: http://svn.apache.org/repos/asf/juddi/trunk/juddi-core-openjpa/src/test/java/org/apache/juddi/api/impl/ WS: http://svn.apache.org/repos/asf/juddi/trunk/uddi-tck/src/test/java/org/apache/juddi/v3/tck/ To break a circular dependency while building the shared code lives in the tck-base module, which includes the test data.
          Hide
          kurtstam Kurt T Stam added a comment -

          List of field lengths that get shorter:

          addressLine keyname keyvalue, default > 255
          [6:36pm] spyhunter99: BindingDesc name 1024 > 255
          [6:37pm] spyhunter99: BusinessDesc 1024 > 255
          [6:37pm] spyhunter99: BusinessName from default > 255
          [6:38pm] KurtStam: you are quoting the length as it was defined in the java?
          [6:38pm] spyhunter99: yes
          [6:38pm] KurtStam: k
          [6:38pm] spyhunter99: ContactDesc 1024 > 255
          [6:38pm] spyhunter99: DiscoveryURL useType default to 255
          [6:39pm] spyhunter99: and URL default to 4096 (probably not an issue)
          [6:39pm] KurtStam: yeah we need URL to be large..
          [6:40pm] spyhunter99: Email use type default to 255, email address default to 4096
          [6:40pm] spyhunter99: InstanceDetailsDescr description 1024>255
          [6:41pm] spyhunter99: InstanceDetailsDocDescr desc 1024>255
          [6:41pm] spyhunter99: KeyedReference keyname and value, default to 255
          [6:42pm] spyhunter99: Tmodel name default > 255
          [6:42pm] spyhunter99: TmodelDescr name 1024>255
          [6:43pm] spyhunter99: TmodelIdentifier defaults to 255, 3 fields
          [6:43pm] spyhunter99: TmodelInstanceInfoDescr description 1024>255
          [6:43pm] spyhunter99: the rest are increases

          Show
          kurtstam Kurt T Stam added a comment - List of field lengths that get shorter: addressLine keyname keyvalue, default > 255 [6:36pm] spyhunter99: BindingDesc name 1024 > 255 [6:37pm] spyhunter99: BusinessDesc 1024 > 255 [6:37pm] spyhunter99: BusinessName from default > 255 [6:38pm] KurtStam: you are quoting the length as it was defined in the java? [6:38pm] spyhunter99: yes [6:38pm] KurtStam: k [6:38pm] spyhunter99: ContactDesc 1024 > 255 [6:38pm] spyhunter99: DiscoveryURL useType default to 255 [6:39pm] spyhunter99: and URL default to 4096 (probably not an issue) [6:39pm] KurtStam: yeah we need URL to be large.. [6:40pm] spyhunter99: Email use type default to 255, email address default to 4096 [6:40pm] spyhunter99: InstanceDetailsDescr description 1024>255 [6:41pm] spyhunter99: InstanceDetailsDocDescr desc 1024>255 [6:41pm] spyhunter99: KeyedReference keyname and value, default to 255 [6:42pm] spyhunter99: Tmodel name default > 255 [6:42pm] spyhunter99: TmodelDescr name 1024>255 [6:43pm] spyhunter99: TmodelIdentifier defaults to 255, 3 fields [6:43pm] spyhunter99: TmodelInstanceInfoDescr description 1024>255 [6:43pm] spyhunter99: the rest are increases
          Hide
          spyhunter99 Alex O'Ree added a comment -

          1460511

          Show
          spyhunter99 Alex O'Ree added a comment - 1460511

            People

            • Assignee:
              spyhunter99 Alex O'Ree
              Reporter:
              spyhunter99 Alex O'Ree
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development