So I'm trying to adapt some javax.servlet.Filter t...

# ktor

[Jørund Amsen]

So I'm trying to adapt some javax.servlet.Filter to be used in a interceptor. However it uses thing such as ServletRequest/Response. Are these available somehow? Or does ktor build on someting different?

[cy]

It is available but not recommended because you loose portability

[Jørund Amsen]

Yeah, I was afraid of that. Are there any known ways to work with javax Filters?

[cy]

(call.request as ServletApplicationRequest).servletRequest

[cy]

same for response

[cy]

What filter do you need to adopt?

[Jørund Amsen]

In this case it's an internally made logging and access filter. We've mostly used Spring for now, and a lot of former work would be unusable with Ktor

[cy]

Ah, may be it is slightly more difficult because of routing...

[Jørund Amsen]

How so?

[cy]

Right, routing wraps application calls to provide route property so the original call is hidden

[cy]

However, it you intercept before routing, the code above should work well. Otherwise, you need more tricks

[Jørund Amsen]

Yeah, that was my intention at least. I'll see if I can get it to work. Still way out on a limb when it comes to my understanding of Ktor. Thanks for the quick respons!

[cy]

The idea is to hide the underlying engine details, so you can run your app on any engine

[Jørund Amsen]

Oh, one more thing, while I have you here, heh.
https://kotlinlang.slack.com/archives/C0A974TJ9/p1573808069261300

Could I possibly open an issue on this? Multiple connectors support, that is

[cy]

for example, run on netty locally and deploy as war to Tomcat for prod

[Jørund Amsen]

Yeah, that makes sense..

[Jørund Amsen]

But are these servlet-classes engine-spesific?

[cy]

Yes, of course

[cy]

This is why you need to cast to adopt to javax.servlet

[Jørund Amsen]

Oh shit, yeah I just checked the inheritance. My bad

[cy]

You don't have these classes with no ktor-server-servlet dependency

[Jørund Amsen]

Thanks, that actually clears things up a lot

[cy]

Regarding connectors.. I see no reason for not supporting multiple connectors in config. We just provided two for plain and TLS/SSL since it is the most useful case

[Jørund Amsen]

I don't mind attempting a PR or issue, whatever is best for you. Is there anything in particular I should consider?

[cy]

If you think of PR, a change should be backward-compatible so older configuration files should keep working

[Jørund Amsen]

Yep. Would a "unlimited" amount of connectors be allowed, or are there specific types of connectors, similar to TLS(or metrics?) that should be allowed?

[cy]

There is no limit, only two kinds are supported: pure HTTP and HTTPS

[Jørund Amsen]

Yeah, it was more a question of "a metrics port", or "however many more ports you want"

[cy]

Of course you may configure a dedicated connector for the specific purpose such as administration

[cy]

However, you need to configure your routing to filter by port, otherwise all ports will behave the same

[Jørund Amsen]

Yep, I kind of already adapted the EngineMain in our app to do something similar. From what I understand, the port under deployment{} seems to be the default if I don't use any port(){}
Is that correct?

[cy]

This is no longer true. Either port or sslPort should be specified

[cy]

https://github.com/ktorio/ktor/blob/master/ktor-server/ktor-server-host-common/jvm/src/io/ktor/server/engine/CommandLine.kt#L129

[Jørund Amsen]

Oh, is this a recent change?

[Jørund Amsen]

Oh, no I mean

[Jørund Amsen]

When I just do a normal routing

[Jørund Amsen]

Similar to...

fun Routing.metrics() {
    port(8181) {
        get("/prometheus") {
            call.respondText { prometheusMeterRegistry.scrape() }
        }
    }

[Jørund Amsen]

In this case, I spesify the port. However, if I don't spesify the port here, it defaults to the port in

deployment {
    port = 8080
}

[Jørund Amsen]

So it seems there is a "default" connector, however many connectors I have

[Jørund Amsen]

Does that make sense?

[cy]

These are irrelevant. The port function just adds a filter node

[cy]

If no port() in routing then no filter applied so all ports are handled

[Jørund Amsen]

Aaaah, okay yeah that makes a lot more sense

[Jørund Amsen]

Thanks for being awesome Sergey! 😄 Keep rocking

[cy]

irrelevant -> independent

[cy]

So, if one deploy into a servlet container, you can't control connectors at all

[Jørund Amsen]

Yeah

[cy]

but you can add port routing anyway

[Jørund Amsen]

That makes sense

[cy]

So, a routing is a decision tree. Every node of that tree may have a predicate

[cy]

So when a call is started, it comes though the pipeline, then a routing is called (if installed, it's actually optional). If routing finds a node that matches, the corresponding handler is invoked

[Jørund Amsen]

I see