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"
Being able to add some extra/contrib .jar files to the container
classpath. (?)
Done with the param --libs
- 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)
.- Being able to define and access data sources (?)
GWS is not a complete WebContainer.. maybe in a next release
2009/4/7 Daniel Lopez <greeneyed_at_dev.java.net>
> He, he, what a coincidence, I just started a new branch some minutes
> ago to do my first tests with it and sent a message about it :).
>
> Well, the very basic things that are needed are:
> .- Being able to set the port (checked)
> .- Being able to deploy an exploded directory/war file (checked)
> .- Being able to set the context name (?)
> .- Being able to add some extra/contrib .jar files to the container
> classpath. (?)
>
> And in order to be useful, so one can check real applications, the
> minimum we expect is
> .- Being able to compile/execute JSPs (checked, I think)
> .- Being able to define and access data sources (?)
>
> This last point is now "optional", I as use a hackish way to add the
> extra .jar files to the classpath myself before starting up the
> container, but it's something pretty much all containers implement so
> I think it would be better for Grizzly to have it.
>
> Your message crossed with mine on the list about my first experiments,
> so you know where I stand :).
> Thanks!
> D.
>
>
> 2009/4/7 Survivant 00 <survivant00_at_gmail.com>:
> > Can just shoot me what you need to implement Wembed for Grizzly ?
> >
> > the project moved from contrib to his own module.. :)
> >
> > I'll add what is missing.
> >
> >
> > Sébastien
> >
> >
> > 2009/4/4 Daniel Lopez <greeneyed_at_dev.java.net>
> >>
> >> 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 :)
> >>
> >> 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
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>