[Heads up] Grizzly ARP refactoring (AsyncFilter)

[Jeanfrancois Arcand-2]

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@...
For additional commands, e-mail: users-help@...

[Jeanfrancois Arcand-2]

Jeanfrancois Arcand wrote:
> Hi,
>
> Grizzly ARP is not and more popular,

LOL Here I mean:

"more and more" :-)

-- Jeanfrancois

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@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeanfrancois Arcand-2]

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@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeanfrancois Arcand-2]

Salut,

wow that was my best commit ever :-) I've re-added the previous behavior
and API and I got report that breaks ARP applications. So the API will
stay the same with a big @deprecated instead (how should I do stupid
mistakes still!).

To recap, I just renamed from com.sun.grizzly.http.Async* to
com.sun.grizzly.arp.*. If you cannot change the package name, just add
the grizzly-compat.jar to your classpath and everything should works.

Sorry for the trouble.

A+

-- Jeanfrancois

Jeanfrancois Arcand wrote:

> 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@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...