Hi,
to avoid braking backward compatibility, I've added the classes under
the grizzly-compat modules to avoid breaking any applications. That way
all existing applications continue to work without any breakage. Just
need to compile agains grizzly-compat.
Much better IMO.
A+
- Jeanfrancois
Jeanfrancois Arcand wrote:
> Hi,
>
> Grizzly ARP is not and more popular, both on this list as well as
> private emails. One issue ARP was suffering was that it wasn't working
> when the File Cache for static resources was enabled. First I was under
> the impression it would be easy to fix, but guess what it wasn't at all.
> I haven't touch the ARP code since 2005, so I decided to do some cleanup
> there. Two majors backward compatibility issues:
>
> + com.sun.grizzly.http.AsyncFilter is now under
> com.sun.grizzly.arp.AsyncFilter. The idea here is to isolate all Grizzly
> ARP classes under the same package.
>
> + AsyncProcessorTask.getProcessorTask API is no longer there. This was
> causing a lot of issue and made the programming model way to
> complicated. If you need to manipulate the ProcessorTask, then instead
> use AsyncExecutor.getProcessorTask(), which is the recommended way
> anyway and will prevent concurrency issues.
>
> I always try to not break backward compatibility, but this Grizzly ARP
> needed refactoring works and cleanup from its original 1.0 version.
>
> The new version will be included in 1.8.2.
>
> A+
>
> -- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>