Hi Christopher, hi all, <cactus> task is cool and moreover, is well integrated in Maven, which I'm using. So I'd prefer using it instead of other techniques.
I do not necessarily know the container is running. In a development cycle it is, more often than not. However, starting the container for each test session is a good thing, especially in an automated environment, because some classloading issues can appear when doing hot-REdeploy for pre-beta code. On topic, but not as a reply to Christopher message: I looked into the code configuring the port for Tomcat. As I understand, the configuration of the container is done by duplicating the confs and then overwriting some files whith Cactus-provided ones. According to my experience, this is perfectly feasible with JBoss, too. I'm talking about the JBoss-Tomcat bundle - cannot say anything about the JBoss-Jetty bundle. However there is an issue similar to the Tomcat situation: There are different versions of JBoss, using different layouts and even slighly different startup logic. Therefore, a full-blown integration of JBoss would look like the Tomcat one - one class for 3.0.x, another for 3.2.x, .... I'd like to do it, but now I cannot afford to. If nobody will jump on it until I get my hands on some spare time, maybe I'll give it a try. Some thoughts: Overwriting the original conf files with other ones coded in Cactus may be a risk, due to possible incompatibilities. 1. Have you considered transforming the original files with Cactus-provided XSL? This would allow the user to configure to his own liking the container, then let Cactus "insert" the bits and pieces it needs. 2. On a more "user-based" line: What about letting the user create manually his own "template" conf, using "@cactus.port@" syntax, then transforming it on the fly while creating the temporary copy? This would need a property specifying where the user template is. In absence of the property, things can go exactly like now, preserving compatibility. Reasoning for the above: As I see it, Cactus is a developer tool rather than an end-user out-of-the-box packaged app. Therefore, some level of "under the hood" work is acceptable for the target audience, especially if it buys them flexibility. IMHO the "template" approach (and as a matter of fact the "prepare the container first" approach, too) is acceptable because it must be done only once when setting up the development/testing environment. Providing samples for how to take advantage of such a feature would be enough for the developer that needs them and still will not force one to go for personal patches directly in Cactus code. Man, am I verbose or what?! :) Yours, Florin ----- Original Message ----- From: "Christopher Lenz" <[EMAIL PROTECTED]> To: "Cactus Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, August 06, 2003 9:51 PM Subject: Re: setPort is missing on JBoss3xContainer > Hi Florin, > > Florin Vancea wrote: > > Cactus waits on the container by polling the URL, which is composed with the > > port, too. > > If I setup a JBoss on 9080 (for the reasons below), I have no means to tell > > Cactus that the JBoss started with the "startup" script should be > > "contacted" at 9080. Cactus will look for it at 8080 and obviously it will > > decide that the startup process failed, even if the startup was successful, > > but on 9080. > > > > Therefore I have to be able to tell Cactus "I've manually taken care of the > > details and be so kind to look for the JBoss you are starting at _this_ > > port" > > If you're using a container that you *know* is already running when you > run the tests, why doesn't a simple <junit> suffice? Granted, you'd have > to pass the Cactus system properties "manually", but that's not so much > of a problem if you know what you're doing... > > If you still want to take advantage of the <cactus> task, you could use > the <generic> container, and provide no-op <startup> and <shutdown> > blocks. If you want to (re-)deploy the WAR/EAR, you can do that in > <startup>. > > > About setting the port (aka configuring JBoss programatically on an > > arbitrary port): > > The method is different in 3.0.x and 3.2.x. > > In 3.0.x, there is a "tomcatX-service.xml" in deploy dir, that holds the > > Tomcat config element. Changing it will change the port, but it's rather > > complicated. JMX is also tricky, because the Web container is tightly bound. > > In 3.2.x , there is jbossweb-tomcat.sar, conatining in META-INF a > > jboss-service.xml rather equivalent to the above "tomcatX-service.xml". Same > > level of difficulty. > > > > In short, I see no easy way to reliably configure the port where JBoss's web > > container is listening and the config sould be done manually (short of > > duplicating entire "default" configuration and translating all occurences of > > "8080" into the value of cactus.port property). > > > > My 2c. > > > > Thanks for replying anyway. > > > > Florin > > > > > > ----- Original Message ----- > > From: "Vincent Massol" <[EMAIL PROTECTED]> > > To: "'Cactus Developers List'" <[EMAIL PROTECTED]> > > Sent: Wednesday, August 06, 2003 6:36 PM > > Subject: RE: setPort is missing on JBoss3xContainer > > > > > > > >>Hi Florin, > >> > >>It's just not done yet. One issue is that setting the port for JBoss is > >>done in one of the config file I think. So we'll need to include this > >>file in the default Cactus config for JBoss. But then, if you provide > >>your own jboss config, how can the Cactus port setting have any effect > >>on it? > >> > >>There may be some Jboss system property that I'm not aware of. > >> > >>Thanks > >>-Vincent > >> > >> > >>>-----Original Message----- > >>>From: Florin Vancea [mailto:[EMAIL PROTECTED] > >>>Sent: 06 August 2003 17:30 > >>>To: 'Cactus Developers List' > >>>Subject: setPort is missing on JBoss3xContainer > >>> > >>>Hi all. > >>> > >>>Why there's no > >>> > >>>public final void setPort(int thePort) > >>> > >>>in org.apache.cactus.integration.ant.container.jboss.JBoss3xContainer? > >>> > >>>About all other sibling Containers have it. > >>> > >>>OK, I understand that currently there's no (simple) way to "move > >> > >>around" > >> > >>>programatically an existing JBoss installation, but one should be able > >> > >>to > >> > >>>move the JBoss installation manually, then specify cactus.port=xxxx . > >>> > >>>I have to run a Cactus setup on a server where 8080 is already taken > >> > >>by > >> > >>>another server and I cannot afford to move it. > >>> > >>>If setPort would be available in JBoss3xContainer, then I could setup > >> > >>my > >> > >>>JBoss on e.g. 9080 (which I actually did) and just tell Cactus to look > >> > >>for > >> > >>>it there. > >>> > >>>If it's acceptable, can some of you kind souls make the addition to > >>>JBoss3xContainer, so it can get into the next nightly jar or such? > >>> > >>>Many thanks, > >>>Florin > > > -- > Christopher Lenz > /=/ cmlenz at gmx.de > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
