[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:
relation
is related to MAGNOLIA-1303 Handle different property types in Mg... Closed
is related to MAGNOLIA-1396 Workflow module api/code cleanup Closed
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:
if (type == PropertyType.NAME) {
log.warn("setProperty(" + propertyName + ", " + valueStr + " with type PropertyType.NAME, will switch to PropertyType.STRING ...");
type = PropertyType.STRING;
}

We should:
1) understand why/how PropertyType.NAME was used in the first place
2) if PropertyType.NAME is a valid choice, make it so that the bean can be deserialized anyhow. if not, then fix JcrBeanCoder.

This was working before MAGNOLIA-1303 because the type parameter was ignored and all properties stored as Strings.



 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.
2). We'd be glad to fix that but we need more info.

Best regards,

John

Comment by Magnolia International [ 17/Jan/07 ]

John,

I had specific problems with JcrBeanCoder, around line 204:
protected int currentType ()
// ...
final String className = currentClassName();

if (className == null)
//... throws exception

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
throw new JcrException
("property 'class' is missing "+
"("this.currentItem.getPath()")");
.. no copy of the stacktrace handy at the moment, sorry.

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.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:25:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.