Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

servlet only working on cloud author, not publish instance?

Avatar

Level 9

We created a simple servlet with a fixed path of /bin/demo/querybuilder.

 

 

 

 

 

(service = Servlet.class, property = { Constants.SERVICE_DESCRIPTION + "=Query Builder servlet",
		"sling.servlet.methods=" + HttpConstants.METHOD_GET, "sling.servlet.paths=" + "/bin/demo/querybuilder" })
public class SimonServlet extends SlingSafeMethodsServlet {

 

 

 

 

 

This works great on local sdk, and works hitting the cloud author instance.  However, when we hit the corresponding publish instance, we get:

 

 

 

 

 

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
	<title>404 Not Found</title>
</head>
<body>
	<h1>Not Found</h1>
	<p>The requested URL was not found on this server.</p>
</body>
</html>

 

 

 

 

 

Any ideas how we get them onto publish? Our content gets pushed onto the publish instance automatically.   A servlet which can't be published is of no use.

 

Update:

added the following line:

 

 

/005 { /type "allow" /url "/bin/myapi/*"    }

 

 

to 

 

 

myapp.dispatcher.cloud/src/conf.dispatcher.d/filters/filters.any

 

 

and deployed to dev cloud instance.  This seems to work, EXCEPT its stripping all the request headers. even things like X-Correlation-Token. 

 

How to get AEM to not remove the request headers for serlvets?

12 Replies

Avatar

Community Advisor

Hi @TB3dock 

 

You are trying to access the end user URL which is behind the dispatcher and in dispatcher /bin/*

/bin/demo/querybuilder

the above path will be blocked.

 

You need to allow the above path in filter section in dispatcher config and it will allow you to access the servlet.

 

You can look for ams_publish_filters.any file in your code base under dispatcher folder.

 

# allow non-public content directories if this isn't a production environment by uncommenting the next few lines
# /005 { /type "allow" /url "/bin/*" } # allow bin path access

asutosh_jena_0-1620652545527.png

 

Thanks!

Avatar

Level 9
Thanks for the helpful reply. Where is the dispatcher folder? We dont see it in ui.config for core?

Avatar

Community Advisor

Hi @TB3dock 

It will not be part of ui.config. It's a separate folder parallel to ui.config in codebase named as "dispatcher".

 

asutosh_jena_0-1620652514971.png

 

Avatar

Level 9
great, found it. for us its dispatcher.cloud. There are two sub dirs, conf.d and conf.dispatcher.d. We are guessing the latter. In conf.dispatcher.d, is a dir call filters with a) default_filters.any and b) filters.any. I guess we could just add it to "filters.any"?

Avatar

Community Advisor

You are absolutely right!

You need to add to the filter.any which is inside the conf.dispatcher.d folder.

 

Thanks!

Avatar

Level 9
out of interest, does the number at the start have any meaning?

Avatar

Community Advisor
Yes. It's the sequence in which the rules will be executed/evaluated on dispatcher.

Avatar

Level 9

Ok, I added

/005 { /type "allow" /url "/bin/*"    }

 

to myapp.dispatcher/cloud/src/conf.displatcher.d/filters.any

And deployed, but is has had no effect, still get 404 hitting any /bin servlet on publish, but works on author.

Any ideas

I am guessing as to the right file and right directory.

Avatar

Community Advisor

Hey TB3dock,

 

Are you sure, you have allowed your url in the AEM as a Cloud Dispatcher, so that you're not blocked there?

 

Regards,

Peter

Avatar

Level 9

I have tried adding /005 { /type "allow" /url "/bin/myapi/*" } to myapp.dispatcher.cloud/src/conf.dispatcher.d/filters/filters.any and it does help, although now AEM is removing all the request headers, so is not working. Locally, it doesnt do this.

Avatar

Community Advisor

Hi @TB3dock ,

 

Steps given by @Asutosh_Jena_  should resolve your issue. Also, please consider using resource type based servlets, they are

 

1. More secure

2. You get ACLs with the resource node assigned

3. Avoids the headache of adding custom paths to dispatcher.

Avatar

Level 9

resource types have some advantages, but they are much more complex to setup, and looking at the source code, devs wont know what path to use.  We have not found any end to end tutorials, and expect that trying to get these working first locally, then on the cloud instance, could also take days or weeks.