+1 also from me.
That way it will be more "code friendly" and easier to manage from
inside another application.
S!
D.
2009/4/7 Hubert Iwaniuk <neotyk_at_kungfoo.pl>:
> +1 for this one
> It will help a lot in creating maven-grizzly-plugin
>
> Hubert
>
>
> On Tue, Apr 7, 2009 at 10:59 PM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>
>> Salut,
>>
>> to add to Sebastien, right now it's module use the command line do
>> internally define everything. After 1.9.11, I would like to refactor his
>> module and start using it under the http-servlet module directly so we can
>> do something like:
>>
>> GrizzlyWebServer gws = new grizzlyWebServer();
>> WarAdapter warAdapter = new WarAdapter();
>> warAdapter.deploy(path-to-web.xml);
>> gsw.addGrizzlyAdapter(warAdapter);
>> gws.start();
>>
>> The WarAdapter will contains all the code Sebastien is using right now to
>> "deploy" the war file. This way you can use the new API with a web.xml, or
>> use the current ServletAdapter API without web.xml.
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>
>> Daniel Lopez wrote:
>>>
>>> Hi,
>>>
>>> 2009/4/7 Survivant 00 <survivant00_at_gmail.com>:
>>>>
>>>> Being able to set the context name (?)
>>>>
>>>> by default it's the war file name or the folder name. The problem will
>>>> be
>>>> when we deploy multiplewar file.
>>>>
>>>> Do you really need to have a context different that the war file ? if
>>>> it's
>>>> only one war at command line.. maybe I could add "-c for context"
>>>
>>> Well, for example when you want to run your embedded container in a
>>> JUnit embedded test, the .war file might have a "weird name" but you
>>> still want to have your tests against the same URLs, so you don't have
>>> to pass that name to the tests code. As that's something one would
>>> want to do just with one .war, the "-c" option looks fine to me.
>>>
>>>> Being able to add some extra/contrib .jar files to the container
>>>> classpath. (?)
>>>>
>>>> Done with the param --libs
>>>
>>> Nice. A list of .jar files using the system classpath separator I guess?
>>>
>>>> - Being able to compile/execute JSPs (checked, I think)
>>>>
>>>> GWS doesn't support JSP by default. I did a blog about how to do it
>>>> manually...(is was for fun.. ) but in the next release Deployer will
>>>> detect automatically if there is a JSP implementation into the classpath
>>>> (hope to release it this weekend)
>>>
>>> Great. If it helps, the Tomcat approach is to ship with a "defaults
>>> web.xml" that includes the file and JSP servlet, and some default
>>> mappings. And the application web.xml adds on top of that. This way
>>> one you wouldn't be tied to one JSP implementation, and you would't
>>> have to try to detect them in the classpath yourself.
>>>
>>>> .- Being able to define and access data sources (?)
>>>>
>>>> GWS is not a complete WebContainer.. maybe in a next release
>>>
>>> I understand. It's just a nice-to-have as many things use them and
>>> once you have it, it opens up a lot of possibilities.
>>>
>>> Thanks your interest, but don't forget to enjoy the Easter holidays! ;)
>>> S!
>>> D.