[MAGNOLIA-1304] Proper handling of PropertyType.NAME in MgnlNode.setProperty Created: 16/Jan/07 Updated: 19/Dec/16 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core, workflow |
| Affects Version/s: | 3.0.1 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Magnolia International |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoR: |
Empty
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
For some unknown reason, the JcrBeanCoder uses PropertyType.NAME when storing Null values - I've only seen this happening with the "openwfe.org.jcr.beancoder.JcrBeanCoder__instance_class" property. As a result, the related beans can't be deserialized. I've applied to following fix for now, but it's far from elegant: We should: This was working before |
| Comments |
| Comment by John Mettraux [ 17/Jan/07 ] |
|
1). We used NAME and not STRING to explicitely state that we are storing a null value and not "null" the string. Best regards, John |
| Comment by Magnolia International [ 17/Jan/07 ] |
|
John, I had specific problems with JcrBeanCoder, around line 204: if (className == null) if (className.equals("Null")) The currentClassName() method would return null - which is probably what's expected - but then the 1st if would go against that and throw an exception stating the class property is missing - while if we used the Propertype.STRING type, we jump into the 2nd if block. I can't find any clear/concise/explicit reference as to what PropertyType.NAME is supposed to reflect - can you point me to one ? |
| Comment by John Mettraux [ 17/Jan/07 ] |
|
Hi Greg, PropertyType.NAME is some JCR stuff, the document is the JCR spec. I'll put add more comments into the JcrBeanCoder around line 204 to make it clearer. An exception stack trace would help illustrate the problem. Best regards, John |
| Comment by Magnolia International [ 17/Jan/07 ] |
|
The exception I mentionned is the one thrown by |
| Comment by Magnolia International [ 23/Feb/07 ] |
|
I'm tempted to postpone further work on this to 3.1, maybe along with a complete review of the bean encoding mechanism. (need better understanding..) |
| Comment by Magnolia International [ 01/Mar/07 ] |
|
postponing. |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |