[MGNLRES-206] Uploading a file under folders not yet existing fails with NPE in FileTransformer Created: 31/Aug/15  Updated: 29/Mar/22  Resolved: 03/Sep/15

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Federico Grilli Assignee: Federico Grilli
Resolution: Obsolete Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 0.75d
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLRES-187 Add upload action for new resource files 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:
Epic Link: Phase out in-place templating app
Sprint: Sprint (Basel) 8
Story Points: 5
Team: Nucleus

 Description   

Uploading a file under a not yet existing folder path fails with NPE in FileTransformer
JCR session holding the path (transient, not yet saved) is "lost" upon uploading the file which result in node being null (a new session is used which isn’t aware of the path to the new resource)

Java.lang.NullPointerException
at info.magnolia.ui.form.field.transformer.item.FileTransformer.getOrCreateFileItem(FileTransformer.java:147)


 Comments   
Comment by Federico Grilli [ 01/Sep/15 ]

To summarise:

  • uploading a new file is a process involving multiple requests and after the first one the JCR session holding the transient path to the resource being uploaded is gone. All subsequent requests fail with a NPE which ultimately is thrown by info.magnolia.ui.vaadin.integration.jcr.AbstractJcrAdapter.getJcrItem() #96
    After some investigation I preferred not to mess with JCR sessions (like trying to use a different repo strategy for this use case and have a long lasting session spanning multiple requests) but rather save the folder hierarchy upon creation of the node which will eventually contain the new resource. Should a user cancel the upload action a custom CancelAction will take care of removing the empty folder hierarchy. IMO this is the simplest and safest solution to the issue.
Comment by Aleksandr Pchelintcev [ 02/Sep/15 ]
  • Type in CancelUploadedResourceFileDialogAction javadoc ('imp0licitly')
  • I'd maybe made removeNewNode name a bit more descriptive (smth related to the full path 'clean up' etc).
  • I see that the bootstrap file's modified - what about MVH?

Side notes:

  • Actually JcrResourceOrigin operates over the SystemContext, which is capable of persisting sessions between requests (info.magnolia.context.SystemRepositoryStrategy's JavaDoc)
    • But I guess it is mem-leak prone and just dangerous
  • Still maybe we should consider delegating the new resource creation/deletion operations to JcrResourceOrigin instead of doing that ad hoc in all the actions.
    • Then the origin could cache the new resources in some form (NewJcrNodeAdapter, mere path string or whatnot).
    • Wdyt?
Comment by Mikaël Geljić [ 03/Sep/15 ]

Obsolete. Upload shouldn't go straight to a JCR adapter, we create the path/node in SaveAction in one step instead.

Generated at Mon Feb 12 06:48:26 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.