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)

      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

        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 ]

          People

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

            Dates

            • Created:
              Updated:

              Development