[BLOSSOM-241] MnglContext.getJCRSession does not return a valid session Created: 09/Dec/16  Updated: 12/Jan/17

Status: Open
Project: Blossom
Component/s: None
Affects Version/s: 3.1.3
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Ugo La Giorgia Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64
Tomcat 7
Magnolia 5.4.9
Spring 4.2.5


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   

During a request the component's handleRequest method is executed.

In this method, we execute various logic operation and one of them is to obtain a list of products contained in a contentApp's workspace. To do so, we execute these instructions:

Session session = MgnlContext.getJCRSession("validWorkspace");
Node someNode = session.getNode("validPath");

the getNode() throws a node not found exception. In fact, getNode("/") returns the root node but the root node has no children. That's really frustrating because if we dump the root node in the JCR tools app, there is a child node. And the node pointed by the 'validPath' is there too.

Am I missing something or do we have to do things differently than in Magnolia 4.5.2x ?

Thanks!



 Comments   
Comment by Jan Haderka [ 10/Dec/16 ]

Should work just the same.
Can you provide full exception stacktrace?
Also is it possible that user under which you run this has no rights to the node? What happens if you do MgnlContext.getSystemContext().getJCRSession("validWorkspace").getNode("validPath"); ?

Comment by Ugo La Giorgia [ 13/Dec/16 ]

Sorry for the late reply...weekend...and I stumbled on the blossom sample module which helped me debug the situation.

Turns out you are right! The user that ran the request did not have the right to that workspace, not even root.
should that be caught by the getJCRSession() ?

Still I reworked my Blossom configuration after studying the Blossom sample module...particularly the SiteAwareFreemarkerRenderingConfiguration class.

I may have another problem with accessing a Session from bean instances created by Spring/Blossom. I'll validate again the issue. Do I have to inject something in those class to make it work ? many of the start a thread the makes the necessary changes in the JCR...

Comment by Ugo La Giorgia [ 12/Jan/17 ]

I found a workaround.

I'm using this kind of construct:

            MgnlContext.doInSystemContext(new JCRSessionOp<Boolean>("website")
            {
                @Override
                public Boolean exec(Session session) throws RepositoryException
                {
                    ...
                     node.setProperty(PROP_NFO, info.getInfoString());
	              session.save();
                    }
                    return true;
                }
            });

in Magnolia 4.5.x it wasn't necessary.

Generated at Sun Feb 11 23:31:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.