Paul Sandoz wrote:
>
> On Apr 14, 2010, at 3:34 PM, James Russo wrote:
>
>>>
>>> That was our focus on the limited design of just building web app
>>> descriptor state just for the Jersey servlet container and
>>> extensions of as a filter or servlet, that has init params, rather
>>> than being a general programatic way of building state of a web app.
>>>
>>> AppDescriptor is extensible so we could do something more general,
>>> that has the concept of zero or more filters each of which may have
>>> zero or more init params, without breaking the existing API.
>>
>> So, maybe I am trying to do more with it then I really should be
>> introducing spring, spring-security and then finally SSL to do some
>> end-to-end testing? Perhaps I should just deploy it to a real
>> container and use the external testing methods of the framework? It
>> is nice to have everything in one self-contained test though.. and it
>> really would be nice to be able test the resources complete.
>>
>
> I do think you have a point about a bit more flexible web app
> descriptor builder. That combined with useful extensions to the
> grizzly web server test container might actually get you most of the
> way there.
>
> Pavel what do you think?
I concur, there is definitely room for improvements and it shouldn't be
hard to improve current WebAppDescriptor.Builder (or do another
AppDescriptor descendant) which will support multiple (named) filters. I
can look into it if you want.
On the other hand, we won't be able to support everything on embedded
containers and I would definitely recommend using external test
container for complicated applications - it is easier to write tests and
its always good when you have testing environment as close as possible
to production.
Pavel