users@grizzly.java.net

Re: Using Grizzly as embedded container for deployed applications

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 06 Apr 2009 09:42:09 -0400

Salut,

Daniel Lopez wrote:
> Hi again,
>
> I found some time to finish and clear up the documentation and make
> the project more easily re-usable, so I published it:
> http://www.jroller.com/greeneyed/entry/wembed_the_embedded_container_launcher
>
> I hope to be able to add Grizzly soon to the list of supported
> containers, so I can test if my applications are 100% portable "as is"
> between Jetty, Tomcat and Grizzly. I'll keep an eye on it :)

Thanks for letting us know. I will ping you once we have implemented the
missing features.

Thanks!

-- Jeanfrancois


>
> Cheers!
> D.
>
>
> 2009/4/2 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>:
>> Salut,
>>
>> Daniel Lopez wrote:
>>> Hi there,
>>>
>>> I'm working on a project to facilitate checking deployed applications
>>> using different embedded containers, so I was quite interested seeing
>>> Sebastien Dionne's blog entry about the ServletAutoDeployer and the
>>> GrizzlyWebServerDeployer
>>>
>>> (http://weblogs.java.net/blog/survivant/archive/2009/04/grizzlywebserve.html).
>>>
>>> So, I thought it might be nice to add Grizzly to the list of supported
>>> containers :).Looking at the other implementations and what one
>>> usually needs, the usual requirements that I ask are: Being able to
>>> set the port, the directory where the application is deployed, the
>>> context name, some way of adding extra classpath for the container.
>>> Why the extra classpath? Because when I want to test an application
>>> under different containers, I want my application to include only the
>>> libraries that are really required, and not the ones that are usually
>>> included by the container itself, and different containers include
>>> different libraries. For example in order to create a DataSource,
>>> Tomcat requires a couple of jakarta libraries, while Jetty can use
>>> C3P0. So, I don't want to bundle all those .jar files in my
>>> WEB-INF/lib and I might not know at deploy time all the jars that
>>> might end up being used, hence the need to add an "extra classpath"
>>> that plays the role of lib or common/lib in some containers.
>> OK thanks for the feedback. We will work pretty soon adding:
>>
>> + library support (today or tomorrow)
>> + directory auto-deploy (we need to discuss the desaign of this).
>>
>> see: https://grizzly.dev.java.net/issues/show_bug.cgi?id=464
>>
>>> I think thats the only feature missing from the
>>> GrizzlyWebServerDeployer to be able to use it.
>>>
>>> I already have implementations for Jetty and Tomcat, while Resin and
>>> GlassFish are "in the works" due to issues in their embedded
>>> components.
>> Great!
>>
>>> The project is hosted here:
>>> http://kenai.com/projects/wembed/pages/Home in case someone wants to
>>> see what I mean. I'm already using it in some projects, but I'm still
>>> working a bit on the documentation and facilitating reusability before
>>> issuing the first official release.
>>>
>> OK keep us posted!
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>
>>> Cheers,
>>> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>