> -----Original Message-----
> From: Florin Vancea [mailto:[EMAIL PROTECTED]
> Sent: 08 August 2003 10:36
> To: Cactus Developers List
> Subject: Re: setPort is missing on JBoss3xContainer
>
> 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.
Very cool! :-)
>
> Some thoughts:
> Overwriting the original conf files with other ones coded in Cactus
may be
> a
> risk, due to possible incompatibilities.
At the moment, the JBoss setup is not correct. For all other containers,
we create a full blown configuration environment in a tmp directory.
This means we don't overwrite any file.
I have not been able to do that yet for JBoss but I know it is possible.
I've come very close to it by using something like:
<java classname="org.jboss.Main" fork="yes"
dir="${maven.jboss.home}/bin">
<sysproperty key="program.name"
file="${maven.jboss.home}/bin/run.bat"/>
<sysproperty key="jboss.server.home.dir"
file="${maven.jboss.build.dir}/${maven.jboss.conf.name}"/>
<sysproperty key="jboss.server.home.url"
value="file:/${maven.jboss.build.dir}/${maven.jboss.conf.name}"/>
<arg line="-c ${maven.jboss.conf.name}"/>
<classpath>
<pathelement location="${maven.jboss.home}/bin/run.jar"/>
<pathelement path="${java.home}/../lib/tools.jar"/>
</classpath>
</java>
I think this may even work. Notice the 2 properties:
jboss.server.home.dir and jboss.server.home.url. They are the important
part and are telling JBoss that this is where the JBoss config is
located.
For some reasons, it wasn't fully working but I can't remember the issue
(maybe it was a bug in an older version of JBoss and it may now work
fine). In any case, this is what we need to achieve.
> 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.
Hmmm... This would mean the user has to provide some initial config
files. The approach taken by cactus is even simpler for the end user:
Cactus provides everything out of the box in a default configuration.
That said, I agree it comes short when the user has some different setup
that is required by his application. In this case we're usually
providing the option for the user to provide his own config files.
Cactus usually do not need to modify these files.
> 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?
Sure, but why do you need a template? Why not simply use the port you
wish directly? As a user you certainly know what port you wish to run
under, right?
> 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.
It depends what front end you're using. The idea is to satisfy everyone:
you can use the cactus jar simply and do yourself everything else:
packaging, deployment, etc. This provides ultimate flexibility.
Or you can use some higher level front end, like the Maven one, which
does everything for you, but in a "standard" way.
In the middle ground, you can use the Cactus Ant tasks (cactifywar,
cactus, etc) to have a high level of customization but still be able to
write the build the way you want it.
Maven is indeed an "end-user out-of-the-box packaged app". Ant is not.
> Therefore, some level of "under
> the
> hood" work is acceptable for the target audience, especially if it
buys
> them
> flexibility.
Then go for Ant or Maven but using maven.xml and the cactus task for
example.
That said, I'm not against providing flexibility in the Cactus plugin
for Maven but it must not be harder to use and must not become a
powerhouse... :-)
> 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.
Not convinced yet! :-) We do provide templates already and we do provide
the ability to let the user completely configure his containers. I
personally don't understand yet the need for a user-provided template.
Why not directly the correct configured file?
>
> Man, am I verbose or what?! :)
hehe .... ;-)
Thanks for all these good ideas. We need to discuss more. In any case,
there's some work to do on the jboss configuration!
-Vincent
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
