Hello Team,
We are currently experiencing our profile forms generating a 404 response. This has been working normally. Not sure when it stopped working.
The code in this area has not be touched for many many months.
This snippet of logs shows the sling servlet resolver doing its normal work but resulting in using the cached servlet for the 404.jsp.
Looking for suggestions as to why this is happening and possible resolutions.
Thanks.
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Ordered list of servlet candidates follows
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Servlet candidate: /libs/foundation/components/primary/sling/servlet/default/form.GET.servlet
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Servlet candidate: /libs/foundation/components/primary/sling/servlet/default/GET.servlet
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Servlet candidate: /libs/foundation/components/primary/sling/servlet/default.servlet
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Checking if candidate resource /libs/foundation/components/primary/sling/servlet/default/form.GET.servlet adapts to servlet and accepts request
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Using servlet provided by candidate resource /libs/foundation/components/primary/sling/servlet/default/form.GET.servlet
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver getServletInternal returns servlet com.day.cq.wcm.foundation.forms.impl.FormChooserServlet
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Servlet com.day.cq.wcm.foundation.forms.impl.FormChooserServlet found for resource=JcrNodeResource, type=cq/security/components/profile, superType=null, path=/home/users/validuser/profile
GET /home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html HTTP/1.1] org.apache.sling.servlets.resolver.internal.SlingServletResolver Using cached servlet /apps/sling/servlet/errorhandler/404.jsp
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Thank you for replying.
I just solved the problem yesterday. Let me share what I found.
As I noted above the url looks like this:
/home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html
I discovered that com.day.cq.wcm.foundation.forms.impl.FormChooserServlet is responsible for handling this url correctly. But in Service Pack 21, possibly 20, the code was changed and the problem became visible.
I went back and decompiled FormChooserServlet from previous service packs and the version in SP19 compared to SP21 showed there was a code change which apparently produced our issue.
Now I don't know why it was changed, not sure if it is truly a defect in SP21. However, I overrode FormChooserServlet with the code from SP19 and the problem is no longer present.
I opened a case with Adobe Support for further discussion.
Thanks again for your thoughts on this.
Tom
@partyush @Himanshu_Jain @anupampat @Sady_Rifat @iamnjain @Preetpal_Bindra @Peter_Puzanovs @ShaileshBassi @Rajumuddana @A_H_M_Imrul Curious to hear your perspectives on this question. Do you all mind sharing your thoughts?
Views
Replies
Total Likes
Hi @Tom_Fought ,
Are you trying to access this from publisher instance?
Can you check whether the content is available in publisher instance.
Also try to clear your dispatcher cache before running this .
Also verify that profile.form.html
is a component or page within the specified content path.
Thanks
Thank you for replying.
I just solved the problem yesterday. Let me share what I found.
As I noted above the url looks like this:
/home/users/validuser/profile.form.html/content/website/publish/en_us/user/view-profile.html
I discovered that com.day.cq.wcm.foundation.forms.impl.FormChooserServlet is responsible for handling this url correctly. But in Service Pack 21, possibly 20, the code was changed and the problem became visible.
I went back and decompiled FormChooserServlet from previous service packs and the version in SP19 compared to SP21 showed there was a code change which apparently produced our issue.
Now I don't know why it was changed, not sure if it is truly a defect in SP21. However, I overrode FormChooserServlet with the code from SP19 and the problem is no longer present.
I opened a case with Adobe Support for further discussion.
Thanks again for your thoughts on this.
Tom
I opened a case with Adobe.
Adobe Response
SP 21 introduces a validation check to ensure that the form resource is of type cq:Page. If the resource does not existor is not of type cq:Page, it logs a warning and returns a 404 error. This update enhances the robustness of the form processing by ensuring that only valid form pages are processed, preventing potential errors from invalid resources.
My response
I understand that. My form, which is the suffix on the request, is type cq:Page. The format of the profile url has the /home/users/x/xxxxxx as the prefix to the URI and the suffix is the profile form which has cq:Page. The logic may work for some forms, but it doesn't work for the profile form. Please show my URI to the engineers. Thanks. The logic needs to take the /home/users/x/xxxx/profile.form.html/suffix-containing-profile-form into account.
So the change was made with the goal of improving forms processing. Can't fault that.
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies