Hi Florin,
> -----Original Message-----
> From: Florin Vancea [mailto:[EMAIL PROTECTED]
> Sent: 11 August 2003 12:12
> To: Vincent Massol; 'Cactus Developers List'
> Subject: Re: setPort is missing on JBoss3xContainer
>
> Please read on.
>
> ----- Original Message -----
> From: "Vincent Massol" <[EMAIL PROTECTED]>
> To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> 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.
Actually it's slightly different. The dir structure and default files
are taken from the cactus-ant jar itself (except for JBoss for which we
haven't done that yet). Thus there is no overwriting at all.
>
> 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.
The strategy that we have been following (but which isn't implemented
yet at 100%) is to provide simple default configuration files to get
users started quickly. Then if a user wants to configure something
specific that isn't supported in the default config, he will provide the
container config files himself and tell the <[container]> element of the
<cactus> task to use his files rather than the default ones.
This is currently supported for some containers but not all. It is
supported by the <jboss3x> one.
>
> >
> > 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)
Agreed. That's a possibility. I'd still prefer this one:
<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}"/>
Which also supports putting the server conf in JBOSS_HOME/server (but
you can put it anywhere you want really).
>
> >
> > > 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.
Cool :-)
>
> >
> > > 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).
Yep. That's possible and that would be implemented in the Maven plugin,
not in Cactus itself. However, if you think about it, it will be real
tedious work as you'll need to expose every single configuration
property. And for all containers... I'd rather let the user provide the
container config files (at least for now).
Now, the idea of common configuration API for all containers project is
interesting and I've been thinking about a commons-container project
that would expose a pure Java API for starting/stopping containers and
for configuring them. I'm going to blog about this soon. Once I finish
JUnit in Action and once Cactus 1.5 is released, I think I'll start
developing this new project... (no promise though :-)).
>
> >
> > > 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
this we already do
> 2. Adapt (through code), apply XSL or hard-overwrite certain pieces,
> according to Cactus's intelligence and already-known parameters (like
> cactus.port)
this we also do although not with XSL but with Ant filters.
> 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.
This we also do (but not finished for all containers). However, we don't
do the overwrite part ATM. That may be a variation we could implement
which may reduce the number of files the user has to provide.
> 4. Convince the container to start over the specified config.
We do this for all containers except JBoss (and this is planned for
jboss, just need the time).
>
> 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 :) )
Funnily enough, I have implemented this on a past project. It was a
subproject in itself called Babylon. We had a master configuration in
XML which contained all kind of information for the whole system (names
of machines, cluster config, container configs, EAI config, etc) and
then we had templates: one template for WebLogic's config.xml, another
one for the EAI subsystem ,etc. Babylon would generate config files by
using the master XML and the template.
There was an Ant task that you were invoking with:
<babylon template="template name" dest="output name"/>
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
