Adding multiple filters

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding multiple filters

Ivan
Been having issues with adding multiple filters with similar methods. An example:
val planA = unfiltered.Planify{
    case GET(Path(Seg("aplan" :: Nil), r)) =>
        Ok ~> ContentType("text/html") ~> ResponseString("Plan A")
}

val planB = unfiltered.Planify{
    case GET(Path(Seg("bplan" :: Nil), r)) =>
        Ok ~> ContentType("text/html") ~> ResponseString("Plan B")
}

unfiltered.server.Http(8080)
    .filter(planA)
    .filter(planB)
    .run()
In this example, only the later filter (planB) is valid. Attempting to call /aplan results in a jetty 404 error. Haven't traced through the code since it ends up almost straight away into Jetty code. Is this behavior normal for filters or is there an error?
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

n8han
Administrator
  On 9/28/10 10:16 AM, Ivan [via Databinder] wrote:
> this example, only the later filter (planB) is valid. Attempting to
> call /aplan results in a jetty 404 error. Haven't traced through the
> code since it ends up almost straight away into Jetty code. Is this
> behavior normal for filters or is there an error?

It may help to specify an explicit context

unfiltered.server.Http(8080).context("/*") {
     _.filter(planA).filter(planB)
}.run()

I thought we made it work as you expected with the default context, but
maybe not. I also thought PlanSpec was testing this and it's not, so we
should really beef that up.

Nathan
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

Ivan
I upgraded from 0.1.4 to 0.2.0 before attempting to try again with an explicit context.
unfiltered.jetty.Http(8080).context("/*") {
    _.filter(planA)
     .filter(planB)
}.run()
Both plans now return a 404. Let me dig a bit deeper.
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

soft_props
This is now officially a bug. See http://github.com/n8han/unfiltered/issues/issue/3. I'm working on this now. I'll post back when its fixed.
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

soft_props
fixed in http://github.com/n8han/Unfiltered/commit/b80763e508209d5399d6ba26b93dbaa702c9d51b.

It took a while to realize this but what would you expect in a traditional web.xml with a configureation like

<filter>
    <filter-name>com.foo.FooFilter</filter-name>
    <filter-class>com.foo.FooFilter</filter-class>
</filter>
<filter>
    <filter-name>com.foo.FooFilter</filter-name>
    <filter-class>com.foo.FooFilter</filter-class>
</filter>
<filter>
    <filter-name>com.foo.FooFilter</filter-name>
    <filter-class>com.foo.FooFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>com.foo.FooFilter</filter-name>
   <url-pattern>/foo/*</url-pattern>
</filter-mapping>
<filter-mapping>
   <filter-name>com.foo.FooFilter</filter-name>
   <url-pattern>/foo/*</url-pattern>
</filter-mapping>
<filter-mapping>
   <filter-name>com.foo.FooFilter</filter-name>
   <url-pattern>/foo/*</url-pattern>
</filter-mapping>

:)

What was actually happening was you were adding multiple instances of the same filter class keyed by the same filter `name` and only the last filter instance added was actually serving the requests on the same context path.

I realized this after noticing that using the Plan trait in the same use case worked. That's because creating a new instance of those created a unique anonymous class name which allowed the server to differentiate between instances of them.

Unique Filter (and server) names are now generated when they added to the server so that the server can differentiate between both instances of Plans and instances of the Planify class.
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

n8han
Administrator
  On 10/3/10 12:55 AM, soft_props [via Databinder] wrote:
> fixed in
> http://github.com/n8han/Unfiltered/commit/b80763e508209d5399d6ba26b93dbaa702c9d51b.
>

Only reason I haven't released this as 0.2.1 yet is the plan tests
sometimes fail. It's probably something to do with the parallel test
runner, but this code really should be thread-safe and it looks like it
is, so, .... ? I want to figure that out before doing a release.

Nathan
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

soft_props
I'll take a look at this tonight and see if I can find a threading issue.
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

soft_props
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiple filters

n8han
Administrator
Yay. I might release this tonight, or I might just try to get some sleep. Sorry I had to run out. I'm not feeling well and was hoping to be out of there by 8.

That it could have been a millisecond collision occurred to be at one point before, but I ruled it out for no good reason. Guess the processors have gotten faster underneath us. :) But also, a good reminder not to leave anything up to chance when there are safe options. The atomic int will block, but it's not like you would ever have enough filters for that to matter. At least, I *think* that is a safe assumption!

It seems like with FP the bugs are usually bad assumptions, since you rule out all those horrible accidental things that happen all the time with variables.

Nathan


On 10/05/2010 09:42 PM, soft_props [via Databinder] wrote:
bada bing, atomic boom http://github.com/n8han/Unfiltered/commit/22ea542a96d4d312f2389650839f4a52f400708d


View message @ http://databinder.3617998.n2.nabble.com/Adding-multiple-filters-tp5579600p5605491.html
To start a new topic under Databinder, email [hidden email]
To unsubscribe from Databinder, click here.