users@grizzly.java.net

Re: Using Grizzly as embedded container for deployed applications

From: Hubert Iwaniuk <neotyk_at_kungfoo.pl>
Date: Tue, 7 Apr 2009 23:14:29 +0200

+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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>