struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Wannemacher <>
Subject Re: CI for Struts and the Struts Zone
Date Fri, 02 Jan 2009 03:08:42 GMT
Well, it's not a requirement, but I was sort of thinking that the second
instance, that hosts our reference apps might need restarted frequently.
Imagine that it's open to the public and we get offensive names added in
the various people managers. I plan to use it to test. Each time we do a
release, I like to deploy showcase and then go through and click each
link and test it out. But, in reality, if it's open to the public, I'm
guessing we'll see a few f-words, etc. posted in there. Another
possibility is that we inadvertently introduce a memory leak or
something. It will present in the apps, but Hudson won't care about it.
IMO, the memory footprint of tomcat is small enough that we can get by
with two and not have any problems.

Since the build for s2 takes 15 minutes on my machine, I'm guessing that
even on the zone it will take a while. By having two instances, we can
handle problems with the apps, w/o interrupting builds that might be
running on Hudson. 

I'm not against running only one, but just thought that two might be
better. Another choice would be to have more than tomcat for the
reference apps. If we have enough space/memory/etc. I wouldn't mind
setting up Tomcat/Jetty/Resin/JBoss/Whatever we get our hands on. I'm
planning on setting up Apache httpd with mod_proxy so that we can do
something like -

I'm not sure at what point I'll kill the zone, but I figure if I'm not
trying, then we're not testing enough ;)


On Thu, 2009-01-01 at 21:59 -0500, Musachy Barroso wrote:
> why do we need 2 tomcat instances?
> musachy
> On Thu, Jan 1, 2009 at 9:33 PM, Wes Wannemacher <> wrote:
> > So, Martin and I took the discussion off-list briefly about the
> > nightlies and I learned a bunch about what we have and a few more things
> > about what Apache can help us with.
> >
> > First off, I learned about Solaris Zones... It is a virtual machine,
> > like VMWare, but a bit different in the implementation. The main aspect
> > of it is that having a Struts Zone in apache is a lot like having our
> > own Solaris 10 server. After logging in and poking around a bit (thanks
> > to Martin for helping me get in), I am convinced that this is a heavily
> > under-utilized resource for us.
> >
> > Right now, the nightly builds are generated in the struts zone, but I'd
> > really like to enhance this process a bit. I got to thinking about it
> > and I think the problems we've been having with both the nightlies and
> > bamboo are parallel. In both cases, we have a single point of failure.
> > By that, I mean, we depend on individual developers (volunteers in our
> > case) to manage components. So, what I would like to do is utilize this
> > zone to create a CI and test-bed for Struts. Since a zone is a VM, I am
> > not sure yet whether we would load the host machine to a point where
> > infrastructure@a.o will notice, but looking at other zones, I think
> > we'll be okay.
> >
> > The nightly build that we are currently running in the zone is done by
> > shell scripts through cron. Although it works, this makes it impossible
> > for me to change the schedule. I like what was done, but I think we can
> > improve on it quite a bit.
> >
> > In a nutshell, what I would like to do is run two instances of tomcat on
> > the zone. The first instance will host Hudson, which we will configure
> > to perform CI for us. The second instance will host our reference apps
> > (struts2-blank, struts2-showcase, etc.). Hudson can be configured to
> > deploy the apps when they are built. I would also like to setup Archiva,
> > since some of the problems we've been seeing in Bamboo appear to be
> > Maven related.
> >
> > I've already got most of the details worked out in my head and will
> > document the setup in the wiki. But, one thing that I'm looking for
> > feedback on is the users/roles setup for Hudson and Archiva. There are
> > plugins for Hudson allowing for users/roles, but I'm wondering if there
> > is a way for us to set it up so that Hudson just knows that a person is
> > an apache struts committer. Martin mentioned that there has been talk in
> > the past of an ASF-wide ApacheDS instance, which if it exists, would be
> > great as I could just setup Tomcat to use that and then use Container
> > Managed Security.
> >
> > If there is no existing store for account information, we can still
> > setup the accounts ourselves, but I'd like to avoid this since we would
> > likely end up back in the same situation if one or just a few people are
> > owners and no one else is able to massage builds.
> >
> > I don't mind doing the setup myself and I'm not necessarily asking for
> > help, but what I want to do is be conscious of the fact that I may not
> > always be available. Hudson seems like a good choice to me since I was
> > able to set it up with a fresh install of Tomcat last night and
> > successfully build struts2 (all profiles) in a matter of minutes.
> >
> > There are a few other considerations. For instance, apache has a Hudson
> > Zone setup currently that other projects are using. There is some
> > information here -
> >
> >
> >
> > Using this hudson has advantages and disadvantages
> > Adv. - Not our resource, we don't have to worry about updates, outages,
> > restarts, etc.
> > Disadv. - Not our resource, we may or may not be able to make changes to
> > the container, add plugins, etc. Also, The struts builds seem to be
> > pretty complex. I am not sure about the other projects currently in
> > there, but there are some of our artifacts that are pretty big.
> > Currently, is now over 100MB. Lastly, to get an
> > account on the hudson zone, it seems like you might have to be a PMC. I
> > want to make this a usable resource for all committers. Since Martin was
> > able to get me on the struts zone, and I'm not a PMC, it seems like this
> > might make it easier for people to get in and do what might need done
> > for struts.
> >
> > Another consideration is whether or not to publish the builds to
> > people.a.o. I mean, it's nice that the download is available to the
> > public, but if we're setting this up, there may be no need. We could
> > simply point people to
> > and be done.
> >
> > So, I'd like to know what people think and if they have suggestions for
> > how they'd like to see this done. I'm not steadfastly sticking to Hudson
> > at this point, it just seemed easy, so if someone thinks cruisecontrol,
> > continuum or whatever might be a better choice, let me know.
> >
> > -Wes
> >
> > PS. GO BEARCATS! (I don't think there are other Ohio committers on the
> > list, but as an ex-UC student, I'm typing this while watching Bearcats
> > in their first BCS bowl appearance, w00t!)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message