[MAGNOLIA-2377] Issue with getDate() Created: 18/Sep/08  Updated: 23/Jan/13  Resolved: 07/Jan/09

Status: Closed
Project: Magnolia
Component/s: templating
Affects Version/s: 3.5.4
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Olivier Marti Assignee: Magnolia International
Resolution: Workaround exists Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-2534 Upgrade to Jackrabbit 1.5 Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

It seems that for a Value in the repository of the value "Date" only one copy is existing in the memory, where all queries to it are referencing.
This is bad, in cases I want to manipulate the date (like compare today with a timespan from two weeks before till the actual value in the node).

That's what my code looks like:
Content activeNode= Resource.getLocalContentNode();
Calendar orig = activeNode.getNodeData("date").getDate();
System.out.println("orig: " + orig.getTime());
Calendar moduleDate = activeNode.getNodeData("date").getDate();
moduleDate.add(Calendar.DATE,-14);
System.out.println("modified: " + moduleDate.getTime());
Calendar reloaded = activeNode.getNodeData("date").getDate();
System.out.println("reloaded: " + reloaded.getTime());

Result:
orig: Wed Oct 15 14:30:00 CEST 2008
modified: Wed Oct 01 14:30:00 CEST 2008
reloaded: Wed Oct 01 14:30:00 CEST 2008



 Comments   
Comment by Olivier Marti [ 18/Sep/08 ]

Ok found two ways how it's working:

Calendar orig = (Calendar) activeNode.getNodeData("date").getDate().clone();

or

Calendar orig = new GregorianCalendar();
orig.setTime(activeNode.getNodeData("date").getDate().getTime());

Comment by Magnolia International [ 18/Sep/08 ]

reopening to set status and resolution appropriately

Comment by Magnolia International [ 18/Sep/08 ]

If you look at the Property.getDate() javadoc it says:

The object returned is a copy of the stored value, so changes to it are not reflected in internal storage.

This is misleading, because I would thus expect the above snippet to show that we get a fresh copy every time we do getProperty on the node. Instead, if you look at the Jackrabbit code, you'll see that the Value implementation holds a cache of a Calendar instance, and (I'm only guessing here: ), the Node implementation probably also holds a cache of its associated {{Value}}s.

I'll actually keep this open to gather some feedback - should this be considered a Jackrabbit issue ?

Comment by Magnolia International [ 18/Sep/08 ]

It could indeed be: see https://issues.apache.org/jira/browse/JCR-1396 which is fixed for 1.5
The issue doesn't show up for other types, since they are immutable (at least numbers strings boolean, it's not so clear for references and names)

Comment by Magnolia International [ 07/Jan/09 ]

This is fixed by updating to Jackrabbit 1.5+

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