OFBiz
  1. OFBiz
  2. OFBIZ-4602

Null values are not synchronized in http mode

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Release 4.0, Release 09.04, Release 09.04.01, Release 10.04, Trunk
    • Fix Version/s: None
    • Component/s: framework
    • Labels:
      None
    • Environment:

      Using entity synchronization over HTTP (not RMI)

    • Sprint:
      Bug Crush Event - 21/2/2015

      Description

      In order to send over http the values to create, store and remove, Ofbiz is Xml serializing the values. GenericValue xml serialization is managed in GenericEntity.makeXmlElement, unfortunately this method just don't serialized null valued fields.

      1. patch-OFBIZ-4602.txt
        2 kB
        Patrick Antivackis

        Issue Links

          Activity

          Patrick Antivackis created issue -
          Patrick Antivackis made changes -
          Field Original Value New Value
          Environment Using entity synchronization trough HTTP Using entity synchronization over HTTP (not RMI)
          Hide
          Patrick Antivackis added a comment -

          To solve this issue, I managed null value the same way GenericEntity.setString (which is used for the Xml deserializing). I only managed until case 10, because i'm not sure the setString for the cases 11 to 15 are well managed (not taking care of null value)

          Show
          Patrick Antivackis added a comment - To solve this issue, I managed null value the same way GenericEntity.setString (which is used for the Xml deserializing). I only managed until case 10, because i'm not sure the setString for the cases 11 to 15 are well managed (not taking care of null value)
          Patrick Antivackis made changes -
          Attachment patch-OFBIZ-4602.txt [ 12505856 ]
          Patrick Antivackis made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Jacques Le Roux made changes -
          Assignee Jacques Le Roux [ jacques.le.roux ]
          Hide
          Jacques Le Roux added a comment -

          Thanks Patrick,

          Your modified patch is in
          trunk r1222241
          R11.04 r1222244
          R10.04 r1222243
          R09.04 r1222242
          R4.0 r1222244

          After looking at GenericEntity.setString and initial commit (http://svn.ofbiz.org/viewcvs?rev=7779&view=rev) I see no reasons to not handling cases under 10 the same way. So I added these cases as well using fall through.

          Show
          Jacques Le Roux added a comment - Thanks Patrick, Your modified patch is in trunk r1222241 R11.04 r1222244 R10.04 r1222243 R09.04 r1222242 R4.0 r1222244 After looking at GenericEntity.setString and initial commit ( http://svn.ofbiz.org/viewcvs?rev=7779&view=rev ) I see no reasons to not handling cases under 10 the same way. So I added these cases as well using fall through.
          Jacques Le Roux made changes -
          Status Patch Available [ 10002 ] Closed [ 6 ]
          Fix Version/s Release Branch 4.0 [ 12312469 ]
          Fix Version/s Release Branch 09.04 [ 12313602 ]
          Fix Version/s Release Branch 10.04 [ 12314832 ]
          Fix Version/s Release Branch 11.04 [ 12316420 ]
          Fix Version/s SVN trunk [ 12311928 ]
          Resolution Fixed [ 1 ]
          Hide
          Jacques Le Roux added a comment -

          Reverted because of OFBIZ-4637

          I will see later what the problem was and will try to redo Patrick's work, it's maybe just because
          set(name, "");
          was used, instead
          element.setAttribute(name, "null");

          Show
          Jacques Le Roux added a comment - Reverted because of OFBIZ-4637 I will see later what the problem was and will try to redo Patrick's work, it's maybe just because set(name, ""); was used, instead element.setAttribute(name, "null");
          Jacques Le Roux made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Adrian Crum added a comment -

          As I mentioned on the dev mailing list, this patch and this "solution" does not make sense. It would be best to understand the problem thoroughly so that a proper solution can be designed.

          If I understand correctly, the problem that needs to be solved is this: OFBiz does not serialize field values that are null. That causes a problem with entity sync, because a field's value might have changed from non-null to null. Since null field values are not serialized, the change is not propagated to the entity sync clients.

          So, we need a way to serialize null field values. The patch does this by serializing a null value as the String "null". But the patch only does that for field data types that are not String. Why are String fields excluded?

          From my perspective, null field values should be tokenized and the token should be serialized - in ALL fields, not just non-String fields. A good candidate for the token would be GenericEntity.NULL_FIELD.

          So, the change to GenericEntity.java line 1079 could look something like this:

          
          } else {
            element.setAttribute(name, GenericEntity.NULL_FIELD.toString());
          }
          

          Now null field values are serialized in a predictable manner. But that change could adversely impact other modes of entity serialization. Also, entity sync clients will need to be updated to unmarshall the null value tokens.

          Show
          Adrian Crum added a comment - As I mentioned on the dev mailing list, this patch and this "solution" does not make sense. It would be best to understand the problem thoroughly so that a proper solution can be designed. If I understand correctly, the problem that needs to be solved is this: OFBiz does not serialize field values that are null. That causes a problem with entity sync, because a field's value might have changed from non-null to null. Since null field values are not serialized, the change is not propagated to the entity sync clients. So, we need a way to serialize null field values. The patch does this by serializing a null value as the String "null". But the patch only does that for field data types that are not String. Why are String fields excluded? From my perspective, null field values should be tokenized and the token should be serialized - in ALL fields, not just non-String fields. A good candidate for the token would be GenericEntity.NULL_FIELD. So, the change to GenericEntity.java line 1079 could look something like this: } else { element.setAttribute(name, GenericEntity.NULL_FIELD.toString()); } Now null field values are serialized in a predictable manner. But that change could adversely impact other modes of entity serialization. Also, entity sync clients will need to be updated to unmarshall the null value tokens.
          Hide
          Jacques Le Roux added a comment -

          Hi Adrian,

          Yes I think you are quite right, indeed GenericEntity.NULL_FIELD.toString() sounds like the best answer. I will try to see if it does not disrupt the same than OFBIZ-4637 and will have a look also at the entity sync clients side. Of course your help, Patrick, would be greatly appreciated...

          Show
          Jacques Le Roux added a comment - Hi Adrian, Yes I think you are quite right, indeed GenericEntity.NULL_FIELD.toString() sounds like the best answer. I will try to see if it does not disrupt the same than OFBIZ-4637 and will have a look also at the entity sync clients side. Of course your help, Patrick, would be greatly appreciated...
          Hide
          Jacques Le Roux added a comment -

          Also Patrick,

          Could you confirm that the fix you proposed solved the issue you crossed? Did you do any changes on entity sync clients side?

          Show
          Jacques Le Roux added a comment - Also Patrick, Could you confirm that the fix you proposed solved the issue you crossed? Did you do any changes on entity sync clients side?
          Hide
          Jacques Le Roux added a comment -

          Ankit just told me that, as I supposed, he crossed many more issues with this patch... So yes, it's not a solution at all...

          Show
          Jacques Le Roux added a comment - Ankit just told me that, as I supposed, he crossed many more issues with this patch... So yes, it's not a solution at all...
          Hide
          Jacques Le Roux added a comment -

          Finally this should be fixed in
          trunk r1226055
          R11.04 r1226056
          R10.04 r1226058
          R09.04 r1226057
          R4.0 r1226059

          I followed Adrian's advice. I tried to create an order with a dropship1 item (like in Jira 4637) and it worked perfectly. I guess, as we were suspecting, using
          set(name, "");
          instead of
          element.setAttribute(name, "null");
          had side effects.

          Anyway, as Adrian pointed out, the right returned string should be "[null-field]" and it's now correct/consistent. On the other side (entity sync clients), of course, now "[null-field]" should be handled instead of "" or "null"

          Show
          Jacques Le Roux added a comment - Finally this should be fixed in trunk r1226055 R11.04 r1226056 R10.04 r1226058 R09.04 r1226057 R4.0 r1226059 I followed Adrian's advice. I tried to create an order with a dropship1 item (like in Jira 4637) and it worked perfectly. I guess, as we were suspecting, using set(name, ""); instead of element.setAttribute(name, "null"); had side effects. Anyway, as Adrian pointed out, the right returned string should be " [null-field] " and it's now correct/consistent. On the other side (entity sync clients), of course, now " [null-field] " should be handled instead of "" or "null"
          Jacques Le Roux made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Hide
          Jacques Le Roux added a comment -

          Last sentence above is for you Patrick, as I guess anybody else ever used such thing so far... Thanks for the try , and thanks to Adrian for support

          Show
          Jacques Le Roux added a comment - Last sentence above is for you Patrick, as I guess anybody else ever used such thing so far... Thanks for the try , and thanks to Adrian for support
          Hide
          Jacques Le Roux added a comment -

          After some other issues, I completed in
          trunk r1226065
          R11.04 r1226067
          R10.04 r1226068
          R09.04 r1226066
          R4.0 r12260670

          I better understand Patrick's answer to the issue now...

          Show
          Jacques Le Roux added a comment - After some other issues, I completed in trunk r1226065 R11.04 r1226067 R10.04 r1226068 R09.04 r1226066 R4.0 r12260670 I better understand Patrick's answer to the issue now...
          Hide
          Jacques Le Roux added a comment -

          Seems that http://svn.apache.org/viewvc?rev=1226065&view=rev
          introduced an issue. It seems to be a general issue, I found with automatically reloaded jobs

          2012-01-23 08:58:36,968 (default-invoker-Thread-16) [   GenericDelegator.java:887:ERROR] Failure in create operation for entity [PaymentGatewayResponse]: org.ofbiz.entity.GenericEntityException: Error while i
          nserting: [GenericEntity:PaymentGatewayResponse][altReference,1326713374500(java.lang.String)][amount,50.85(java.math.BigDecimal)][createdStamp,2012-01-23 08:58:36.953(java.sql.Timestamp)][createdTxStamp,2012
          -01-23 08:58:36.953(java.sql.Timestamp)][currencyUomId,USD(java.lang.String)][gatewayAvsResult,[null-field](java.lang.String)][gatewayCode,[null-field](java.lang.String)][gatewayCvResult,[null-field](java.lan
          g.String)][gatewayFlag,C(java.lang.String)][gatewayMessage,This is a test capture; no money was transferred(java.lang.String)][gatewayScoreResult,[null-field](java.lang.String)][lastUpdatedStamp,2012-01-23 08
          :58:36.953(java.sql.Timestamp)][lastUpdatedTxStamp,2012-01-23 08:58:36.953(java.sql.Timestamp)][orderPaymentPreferenceId,9000(java.lang.String)][paymentGatewayResponseId,10031(java.lang.String)][paymentMethod
          Id,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][paymentServiceTypeEnumId,PRDS_PAY_CAPTURE(java.lang.String)][referenceNum,1326713374500(java.lang.String)][resultBadCardNumber,[nu
          ll-field](java.lang.String)][resultBadExpire,[null-field](java.lang.String)][resultDeclined,[null-field](java.lang.String)][resultNsf,[null-field](java.lang.String)][subReference,[null-field](java.lang.String
          )][transCodeEnumId,PGT_CAPTURE(java.lang.String)][transactionDate,2012-01-16 12:29:34.515(java.sql.Timestamp)] (SQL Exception while executing the following:INSERT INTO OFBIZ.PAYMENT_GATEWAY_RESPONSE (PAYMENT_
          GATEWAY_RESPONSE_ID, PAYMENT_SERVICE_TYPE_ENUM_ID, ORDER_PAYMENT_PREFERENCE_ID, PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, TRANS_CODE_ENUM_ID, AMOUNT, CURRENCY_UOM_ID, REFERENCE_NUM, ALT_REFERENCE, SUB_REFERE
          NCE, GATEWAY_CODE, GATEWAY_FLAG, GATEWAY_AVS_RESULT, GATEWAY_CV_RESULT, GATEWAY_SCORE_RESULT, GATEWAY_MESSAGE, TRANSACTION_DATE, RESULT_DECLINED, RESULT_NSF, RESULT_BAD_EXPIRE, RESULT_BAD_CARD_NUMBER, LAST_UP
          DATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (A truncation error was encountered trying to shrink
          CHAR '[null-field]' to length 1.)). Rolling back transaction.
          

          Also there is a problem when reloading jobs, notably those stopped in a non normal way, they are reloaded more than once. Also maxRetry is not taken into account when reloading jobs, . I will create 2 new issues for those cases

          Show
          Jacques Le Roux added a comment - Seems that http://svn.apache.org/viewvc?rev=1226065&view=rev introduced an issue. It seems to be a general issue, I found with automatically reloaded jobs 2012-01-23 08:58:36,968 ( default -invoker- Thread -16) [ GenericDelegator.java:887:ERROR] Failure in create operation for entity [PaymentGatewayResponse]: org.ofbiz.entity.GenericEntityException: Error while i nserting: [GenericEntity:PaymentGatewayResponse][altReference,1326713374500(java.lang. String )][amount,50.85(java.math.BigDecimal)][createdStamp,2012-01-23 08:58:36.953(java.sql.Timestamp)][createdTxStamp,2012 -01-23 08:58:36.953(java.sql.Timestamp)][currencyUomId,USD(java.lang. String )][gatewayAvsResult,[ null -field](java.lang. String )][gatewayCode,[ null -field](java.lang. String )][gatewayCvResult,[ null -field](java.lan g. String )][gatewayFlag,C(java.lang. String )][gatewayMessage,This is a test capture; no money was transferred(java.lang. String )][gatewayScoreResult,[ null -field](java.lang. String )][lastUpdatedStamp,2012-01-23 08 :58:36.953(java.sql.Timestamp)][lastUpdatedTxStamp,2012-01-23 08:58:36.953(java.sql.Timestamp)][orderPaymentPreferenceId,9000(java.lang. String )][paymentGatewayResponseId,10031(java.lang. String )][paymentMethod Id,9015(java.lang. String )][paymentMethodTypeId,CREDIT_CARD(java.lang. String )][paymentServiceTypeEnumId,PRDS_PAY_CAPTURE(java.lang. String )][referenceNum,1326713374500(java.lang. String )][resultBadCardNumber,[nu ll-field](java.lang. String )][resultBadExpire,[ null -field](java.lang. String )][resultDeclined,[ null -field](java.lang. String )][resultNsf,[ null -field](java.lang. String )][subReference,[ null -field](java.lang. String )][transCodeEnumId,PGT_CAPTURE(java.lang. String )][transactionDate,2012-01-16 12:29:34.515(java.sql.Timestamp)] (SQL Exception while executing the following:INSERT INTO OFBIZ.PAYMENT_GATEWAY_RESPONSE (PAYMENT_ GATEWAY_RESPONSE_ID, PAYMENT_SERVICE_TYPE_ENUM_ID, ORDER_PAYMENT_PREFERENCE_ID, PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, TRANS_CODE_ENUM_ID, AMOUNT, CURRENCY_UOM_ID, REFERENCE_NUM, ALT_REFERENCE, SUB_REFERE NCE, GATEWAY_CODE, GATEWAY_FLAG, GATEWAY_AVS_RESULT, GATEWAY_CV_RESULT, GATEWAY_SCORE_RESULT, GATEWAY_MESSAGE, TRANSACTION_DATE, RESULT_DECLINED, RESULT_NSF, RESULT_BAD_EXPIRE, RESULT_BAD_CARD_NUMBER, LAST_UP DATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (A truncation error was encountered trying to shrink CHAR '[ null -field]' to length 1.)). Rolling back transaction. Also there is a problem when reloading jobs, notably those stopped in a non normal way, they are reloaded more than once. Also maxRetry is not taken into account when reloading jobs, . I will create 2 new issues for those cases
          Jacques Le Roux made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Jacques Le Roux added a comment -

          Note that stopped in a non normal way, is not quite clear to me. I observed issues in at least 2 cases: many machines on the same jobs thread-pool, sole machine on Windows where you stop either by ctrl+C or directly by UI (X button).

          Show
          Jacques Le Roux added a comment - Note that stopped in a non normal way, is not quite clear to me. I observed issues in at least 2 cases: many machines on the same jobs thread-pool, sole machine on Windows where you stop either by ctrl+C or directly by UI (X button).
          Hide
          Jacques Le Roux added a comment -

          I finally did not create an issue for JobManager.reloadCrashedJobs() where I wanted to continue in the loop when a job has maxRetry set to 0.

          I believe this case appears (mostly?) when you have multiples instances running on the same DB. So I think it's better to handle this case using unique.instanceId in general.properties.

          The reason I made this choice is because I'm afraid that else we could prevent to reload running (ie crashed) jobs and hence miss them completly.

          Though I still wonder why I got those issues locally with demo instances running on their own DBs...

          Show
          Jacques Le Roux added a comment - I finally did not create an issue for JobManager.reloadCrashedJobs() where I wanted to continue in the loop when a job has maxRetry set to 0. I believe this case appears (mostly?) when you have multiples instances running on the same DB. So I think it's better to handle this case using unique.instanceId in general.properties. The reason I made this choice is because I'm afraid that else we could prevent to reload running (ie crashed) jobs and hence miss them completly. Though I still wonder why I got those issues locally with demo instances running on their own DBs...
          Hide
          Jacques Le Roux added a comment -

          Paul Foxworthy on dev ML

          There is a canonical way from the XML standards to express that an XML
          element is null. Rather than reserving a special value for the data within
          the element, there's a special attribute xsi:nil. Schemas can define a
          corresponding nillable attribute to say it is possible for an element to use
          the xsi:nil attribute.

          Given the problems we've been having with this Jira issue, would using
          xsi:nil be a good idea? The only disadvantage I can see is that this
          solution only works when we are serializing and deserializing to and from
          XML. We would need to solve the problem all over again for other
          serialization formats.

          See http://www.w3.org/TR/xmlschema-0/#Nils and
          http://docstore.mik.ua/orelly/xml/schema/ch11_03.htm .

          Show
          Jacques Le Roux added a comment - Paul Foxworthy on dev ML There is a canonical way from the XML standards to express that an XML element is null. Rather than reserving a special value for the data within the element, there's a special attribute xsi:nil. Schemas can define a corresponding nillable attribute to say it is possible for an element to use the xsi:nil attribute. Given the problems we've been having with this Jira issue, would using xsi:nil be a good idea? The only disadvantage I can see is that this solution only works when we are serializing and deserializing to and from XML. We would need to solve the problem all over again for other serialization formats. See http://www.w3.org/TR/xmlschema-0/#Nils and http://docstore.mik.ua/orelly/xml/schema/ch11_03.htm .
          Hide
          Divesh Dutta added a comment -

          Hello Jacques,

          I was testing credit card transactions and found that in some specific cases, paymentgateway responses are not getting saved. This is due to commits: trunk r1226055
          R11.04 r1226056

          To explain issue in more detail. When we place an Order, and then edit order, and add additional adjustment in Order (say additional shipping and handling.)

          Now order is authorized with original amount . And we set flag ProductStore.shipIfCaptureFails to "Y". Now when we fulfill Order, original amount is captured but additional amount is not yet captured. So ProductStore.shipIfCaptureFails works in PaymentGatewayServices and return error as total amount is not captured yet.

          Now when this error is returned, Original amount is captured by Credit Card but it is not logged in OFBiz.

          Reason behind above bug:

          In savePgr method of PaymentGatewayServices,

          dispatcher.addRollbackService("savePaymentGatewayResponse", context, true);
          

          is written. So this gets triggered when captureOrderPayments return error due to flag ProductStore.shipIfCaptureFails. But above code does not work successfully. Because it schedules a job. And RuntimeData is prepared for this job and "runTimeInfo" is created where xml value of PaymentGatewayResponse is prepared and saved. But when this job gets executed, it fails because it tries to save "null-field" String for fields which are actually null.

          Now because of this we are facing trouble in our current Production systems as we are using 11.04 . It will be great if you look into this and fix this.

          Show
          Divesh Dutta added a comment - Hello Jacques, I was testing credit card transactions and found that in some specific cases, paymentgateway responses are not getting saved. This is due to commits: trunk r1226055 R11.04 r1226056 To explain issue in more detail. When we place an Order, and then edit order, and add additional adjustment in Order (say additional shipping and handling.) Now order is authorized with original amount . And we set flag ProductStore.shipIfCaptureFails to "Y". Now when we fulfill Order, original amount is captured but additional amount is not yet captured. So ProductStore.shipIfCaptureFails works in PaymentGatewayServices and return error as total amount is not captured yet. Now when this error is returned, Original amount is captured by Credit Card but it is not logged in OFBiz. Reason behind above bug: In savePgr method of PaymentGatewayServices, dispatcher.addRollbackService( "savePaymentGatewayResponse" , context, true ); is written. So this gets triggered when captureOrderPayments return error due to flag ProductStore.shipIfCaptureFails. But above code does not work successfully. Because it schedules a job. And RuntimeData is prepared for this job and "runTimeInfo" is created where xml value of PaymentGatewayResponse is prepared and saved. But when this job gets executed, it fails because it tries to save "null-field" String for fields which are actually null. Now because of this we are facing trouble in our current Production systems as we are using 11.04 . It will be great if you look into this and fix this.
          Hide
          Jacques Le Roux added a comment -

          Hi Divesh,

          Sure, I'm looking at it...

          Show
          Jacques Le Roux added a comment - Hi Divesh, Sure, I'm looking at it...
          Hide
          Jacques Le Roux added a comment -

          Paul,

          Thanks to mention the nillable possiblity. Actually, for 2 weeks, I'm considering to use it also in another case but have still to test the changes I did in ModelService.getTypes(). This other case is not directly related. It's when you use an exported service (SOAP) which may return null elements (in my case a list of maps where some elements may be null). When you try to unmarshall the SOAP response from CXF side you get an error like

          Unmarshalling Error: unexpected element (uri:"http://ofbiz.apache.org/service/", local:"null")
          

          As soon as I will have fixed this, I hope to have a better experience of setting nillable attributes and I will consider to use it also in the case at hand.


          Divesh,

          So it's a WIP and I don't want to revert anything for now. If you have an issue with your production system and have not yet reverted the 2 changes above then you may consider to do it in the meantime. Of course, I expect to fix that soon (this week) ... Sorry for the inconvenient...

          Show
          Jacques Le Roux added a comment - Paul, Thanks to mention the nillable possiblity. Actually, for 2 weeks, I'm considering to use it also in another case but have still to test the changes I did in ModelService.getTypes(). This other case is not directly related. It's when you use an exported service (SOAP) which may return null elements (in my case a list of maps where some elements may be null). When you try to unmarshall the SOAP response from CXF side you get an error like Unmarshalling Error: unexpected element (uri: "http: //ofbiz.apache.org/service/" , local: " null " ) As soon as I will have fixed this, I hope to have a better experience of setting nillable attributes and I will consider to use it also in the case at hand. Divesh, So it's a WIP and I don't want to revert anything for now. If you have an issue with your production system and have not yet reverted the 2 changes above then you may consider to do it in the meantime. Of course, I expect to fix that soon (this week) ... Sorry for the inconvenient...
          Hide
          Jacques Le Roux added a comment -

          At r1243026 I introduced the use of the xsi:nil attribute.

          More to come, but unfortunately not this week I think...

          Show
          Jacques Le Roux added a comment - At r1243026 I introduced the use of the xsi:nil attribute. More to come, but unfortunately not this week I think...
          Hide
          Alexander Reelsen added a comment -

          Hi

          some parts of this patch seem to have broken services in the job_sandbox. Suddenly the runtime_data entity with its XML based runtimeInfo field is filled with tons of entity values called foo="[null-field]" which are not serialized back into null, but rather is written as "[null-field]" into the database. Not too cool to cleanup...

          --Alexander

          Show
          Alexander Reelsen added a comment - Hi some parts of this patch seem to have broken services in the job_sandbox. Suddenly the runtime_data entity with its XML based runtimeInfo field is filled with tons of entity values called foo=" [null-field] " which are not serialized back into null, but rather is written as " [null-field] " into the database. Not too cool to cleanup... --Alexander
          Hide
          Jacques Le Roux added a comment -

          Thanks for repor Alexander,

          Unfortunately I don't expect to have a new look before this weekend. Reverting all from start seems the easier way. But I hope to rather follow the same way I did in r1243026 (which is only related to web services and not general)

          Show
          Jacques Le Roux added a comment - Thanks for repor Alexander, Unfortunately I don't expect to have a new look before this weekend. Reverting all from start seems the easier way. But I hope to rather follow the same way I did in r1243026 (which is only related to web services and not general)
          Hide
          Jacques Le Roux added a comment -

          OK, I did not get enough time to completly look at it yet. But I doubt using simply an xsi:nil attribute will solve the problem. Because nullFied (and "[null-field]") has been introduced because of issues with null in (at least) Freemarker...

          I believe the issue I crossed and reported above, has actually been solved by r1226065.

          Divesh, did you test if the same (r1226065) solved your issue?

          Show
          Jacques Le Roux added a comment - OK, I did not get enough time to completly look at it yet. But I doubt using simply an xsi:nil attribute will solve the problem. Because nullFied (and " [null-field] ") has been introduced because of issues with null in (at least) Freemarker... I believe the issue I crossed and reported above, has actually been solved by r1226065. Divesh, did you test if the same (r1226065) solved your issue?
          Show
          Jacques Le Roux added a comment - I let some links here for future possible work: https://fisheye6.atlassian.com/changelog/ofbiz?cs=1222241 https://fisheye6.atlassian.com/changelog/ofbiz?cs=1226065 https://fisheye6.atlassian.com/changelog/ofbiz?cs=1243026
          Hide
          Nicolas Malin added a comment -

          Hi Jacques,

          I tested the entity-sync process, and I confirm the [null-field] break it when an entity field is an other type that String.
          I not solve it, I will check it if I need implement the entity-sync.

          Show
          Nicolas Malin added a comment - Hi Jacques, I tested the entity-sync process, and I confirm the [null-field] break it when an entity field is an other type that String. I not solve it, I will check it if I need implement the entity-sync.
          Hide
          Jacques Le Roux added a comment -

          OK, for now at r1331996 I commented out the line

          element.setAttribute(name, GenericEntity.NULL_FIELD.toString());

          It's not a complete solution and induces more problems thant it solves (notably in RuntimeData for jobs), to be continued...

          Show
          Jacques Le Roux added a comment - OK, for now at r1331996 I commented out the line element.setAttribute(name, GenericEntity.NULL_FIELD.toString()); It's not a complete solution and induces more problems thant it solves (notably in RuntimeData for jobs), to be continued...
          Jacopo Cappellato made changes -
          Fix Version/s Trunk [ 12311928 ]
          Fix Version/s Release Branch 11.04 [ 12316420 ]
          Jacopo Cappellato made changes -
          Fix Version/s Release Branch 4.0 [ 12312469 ]
          Fix Version/s Release Branch 09.04 [ 12313602 ]
          Fix Version/s Release Branch 10.04 [ 12314832 ]
          Sharan Foga made changes -
          Sprint Bug Crush Event - 21/2/2015 [ 91 ]
          Sharan Foga made changes -
          Rank Ranked higher
          Sharan Foga made changes -
          Rank Ranked higher
          Sharan Foga made changes -
          Rank Ranked higher
          Sharan Foga made changes -
          Rank Ranked higher
          Sharan Foga made changes -
          Rank Ranked higher
          Sharan Foga made changes -
          Rank Ranked higher
          Paul Foxworthy made changes -
          Link This issue relates to OFBIZ-293 [ OFBIZ-293 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Patch Available Patch Available
          1h 49m 1 Patrick Antivackis 02/Dec/11 09:51
          Patch Available Patch Available Closed Closed
          20d 4h 36m 1 Jacques Le Roux 22/Dec/11 14:27
          Reopened Reopened Closed Closed
          1d 21h 28m 1 Jacques Le Roux 31/Dec/11 10:17
          Closed Closed Reopened Reopened
          29d 20h 10m 2 Jacques Le Roux 23/Jan/12 08:06

            People

            • Assignee:
              Jacques Le Roux
              Reporter:
              Patrick Antivackis
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development

                  Agile