[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cactus-dev
Subject:    Re: setPort is missing on JBoss3xContainer
From:       "Florin Vancea" <fvancea () maxiq ! ro>
Date:       2003-08-11 10:11:38
[Download RAW message or body]

Please read on.

----- Original Message -----
From: "Vincent Massol" <vmassol@pivolis.com>
To: "'Cactus Developers List'" <cactus-dev@jakarta.apache.org>
Cc: <fvancea@maxiq.ro>
Sent: Saturday, August 09, 2003 10:26 PM
Subject: RE: setPort is missing on JBoss3xContainer


[snip]

>
> 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.

As I saw (maybe I'm wrong here), creating the separate env is done in two
steps:
1. Copy some default dir structure from the target container
2. Overwrite some of the files just copied with files provided by Cactus.

What if the dir structure (or intrinsic logic) is not 100% compatible with
the Cactus-provided files?
OK, the container itself is not affected, but the TMP config may hide
unwanted side-effects.
Yet then, I understand that in real life this kind of incompatibility is
unlikely to arise, and if it does it can be corrected by sub(sub)versioning
the particular Container.

>
> 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.
>

Why not create the temporary conf under the "server" dir (sibling to
"default" and "minimal") and let JBoss take care of startup by calling only
the appropriate shell script? By doing this Cactus would be shielded from
variations in JBoss startup configuration, at the minimal expense of
1. dependency on OS (Windows/Unix)
2. "touching" the container's installation tree (this might have
less-than-minimal impact for centralized, security-conscious setups)

>
> > 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.

I was thinking about Cactus _modifying_ the container's original files in
the process of producing the TMP setup.
If the user so chooses, it's still possible for him to play with the
container's original "default" setup.
Yet I see your point and I agree.

>
> > 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?

Actually yes, that's true. Maybe it would be helpful in cases like Maven
use-case, where all the config properties can be grouped. Then I would know
that the only thing I need to "switch" one particular installation from 8080
to 8081 is to change the appropriate Maven property (in contrast with having
to change both the "client" setup and the "server" setup).

>
> > 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... :-)

I get the point.

>
> > 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?

OK, I drop the template idea. Actually now I see: if I can provide a
template I can also provide directly the needed file. That would be however
a cool feature and embedding it in the logic would be far more attractive
than tampering with custom Ant scripts.

I am suggesting something like:
1. Duplicate some "known" default config
2. Adapt (through code), apply XSL or hard-overwrite certain pieces,
according to Cactus's intelligence and already-known parameters (like
cactus.port)
3. If user said so (and only then), overwrite with a user-supplied tree. The
tree might contain additional files or might overwrite existing ones, but
that's user's business.
4. Convince the container to start over the specified config.

Actually I'm using with success the "XSL then overwrite" composite operation
described in steps 2 and 3 and I think it provides a flexible enough method
for adapting any config to particular needs. I would even like to see it as
a specialized task, which I might even engage sometimes on writing. (don't
really believe that - I'm busy enough for now :) )

[snip]

Florin



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]