On Thu, Jan 22, 2009 at 8:33 AM, James Holmes <ja...@jamesholmes.com> wrote:

> Great work!
>
> I think it would be good if we linked to the zone from the Struts website
> under the developer section. That way we have one central place to go to
> find all this stuff. I know I tend to lose track of these things as there
> all in my older emails.


I think the appropriate page for a section on, and link to, the zone and the
apps on it, is this one:

http://struts.apache.org/dev/builds.html

which is, unfortunately, referred to as 'Source Code' in the Development
section of the web site menu. We should rename that to something a bit more
representative of what is actually there.

--
Martin Cooper


On Thu, Jan 22, 2009 at 11:20 AM, Wes Wannemacher <w...@wantii.com> wrote:
>
> > Okay, so after goofing around with Hudson, I decided to take a crack at
> > setting up the zone for app testing. Since I don't want to do things
> > half-way,
> > and I want to keep in mind the lessons of previous nighly attempts, etc.
> I
> > decided to really go all out and make this as automated as possible.
> >
> > First off, zones are a part of Solaris 10, and another thing Sun
> introduced
> > to
> > Solaris 10 is a facility called Service Management Framework (SMF for
> > short).
> > If you haven't used or heard of it, it is a replacement for /etc/init.d
> > scripts. It is different than /etc/init.d/* in a lot of good ways. First
> > off,
> > it has dependency management... Meaning, one service can depend on one or
> > more
> > other services being launched (no more runlevel crap). Second, because
> you
> > configure dependencies, rather than run order, services are launched in
> > parallel, which decreases Solaris startup time quite dramatically.
> >
> > The downside is that almost everything in the *nix world has /etc/init.d
> > scripts and SMF is new. So, I had to learn how to use and embrace SMF.
> The
> > good news is that it is fairly easy. I was able to create and configure
> SMF
> > to
> > understand both Tomcat 5 and Jetty 6. I'll document in the wiki how to
> > setup
> > new app servers, but at this point, it's pretty much down to unzipping
> and
> > copying/updating a few files then the app server will be ready to go.  I
> > also
> > configured Apache httpd to proxy requests to the running app servers, so
> > that
> > we can see the apps in action by going to http://struts.zones.apache.org
> >
> > Next, I wanted the site to just keep up to date with the latest snapshot.
> > This
> > should be easy now that we have Hudson running within the ASF. To make
> > deployment happen, I had to write a daemon process that watches for the
> > assembly apps zip file to be dropped into a specific directory. I wrote
> it
> > in
> > Perl, which may not be the best language, but works well for these sorts
> of
> > tasks. This perl script is run and monitored by SMF just like httpd,
> jetty
> > and
> > tomcat.
> >
> > So, right now, we have Tomcat and Jetty running all the struts2 sample
> apps
> > and they are available to test at http://struts.zones.apache.org . You
> > should
> > be able to infer what is running and how it is running by looking at the
> > app
> > name.
> >
> > So, I would like to know, which app servers do people want to see? I'm
> > thinking that when we get things worked out with IBM, we'll put WebSphere
> > up
> > there, but do we want JBoss and Resin as well? Also, isn't there an
> apache
> > load-testing app? Maybe we can pound the heck out of that server to start
> > getting metrics on s2 performance as we make changes. Lastly, should I
> > check
> > in the script somewhere? Is there a good spot in our SVN that I can drop
> it
> > and not end up having it copied into zip files, etc.
> >
> > -Wes
> >
> > --
> >
> > Wes Wannemacher
> > Author - Struts 2 In Practice
> > Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> > http://www.manning.com/wannemacher
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> > For additional commands, e-mail: dev-h...@struts.apache.org
> >
> >
>

Reply via email to