|
From: Jason v. Z. <ja...@ze...> - 2003-02-04 08:29:01
|
On Tue, 2003-02-04 at 03:02, Patrick Yee wrote:
> Hi Jason,
>
> Thanks for the suggestion. However, after some discussion, we think the
> change is not quite necessary because:
>
> 1. Hermes deployment is not a day-to-day work. We expect the configuration
> will not be changed frequently. So using static values will be adequate for
> most of the time.
I have integrated Hermes into our application server which might be
installed anywhere in the filesystem on machines with various operating
systems. I need to be able to dynamically configure Hermes because I
don't know where the installation is going to land. Something like
"/tmp/hermes" might possibly work on unix machines but it certainly
wouldn't work on other platforms. In addition, we like to keep all the
files for our application grouped together. We don't care where they are
grouped together. Without interpolation I can't provide the type of
installation that we require. I do not know ahead of time where our
clients will install our product.
> 2. In the scenario that you suggest, we are only transferring the
> "hard-wiring" of property values from Hermes's configuraiton file to the
> application server's configuration files.
We don't hardwire anything. Everything is dynamic. Our application
server works from the directory where it is installed. We don't know
where ahead of time but when our container starts up it gathers
information from the environment and makes that available to all our
components running in the container.
> There is anyway a file which
> should "hard-wire" the property values, which is not portable from file
> system to file system. Under this basis, we believe to "hard-wire" the value
> in Hermes property file is acceptable.
You can't make an installer with Hermes in it without variable
interpolation or some sort of runtime configurability. Variable
interpolation is a very simple solution to the general problem of
relocatable applications.
> 3. We need some extra exception handling when trying to interpolating a
> non-existing system property. In this angle, this makes the configuration
> more complicated. Our design philosophy is to keep every behaviour
> deterministic. Of course, we may not be doing very well, but at least that
> is our direction.
I can add any exception handling if I missed something, more than happy
to make things as robust as possible.
Allow a form of runtime configurability has no down side and is of great
value to users trying to integrate Hermes into various products. It
allows Hermes to be used in unforseen circumstances. For example the way
I have Hermes working now inside our container it could be stopped,
package up because it's all in a single directory, moved to another
machine in a completely different path, started up and Hermes would work
just as it did. This might need to be done because of hardware failure
or just because someone wants to move it. Providing this kind of
flexibility, I believe, is well worth any extra work that needs to be
done internally in Hermes. And I volunteer to do the work :-) For me
this feature is essential for the operation of our container and
necessary to satisfy our user requirements.
> What do you think? Let's discuss about this. Thank you for your continuous
> input.
Happy to help, you've saved me months of development time so I'll
contribute however I can.
> Regards, -Patrick
>
> ----- Original Message -----
> From: "Jason van Zyl" <ja...@ze...>
> To: <ebx...@li...>
> Sent: Sunday, February 02, 2003 12:45 AM
> Subject: [ebxmlms-develop] Variable interpolation in configuration
>
>
> > Hi,
> >
> > I've added variable interpolation in the XMLProperty.java file so that I
> > can more easily integrate Hermes into our application server. The
> > interpolation only works with system properties with the "ebxmlms"
> > prefix.
> >
> > So I'm setting a system property in our application server with:
> >
> > <system-properties>
> > <property name="ebxmlms.basedir" value="${plexus.work}/ebxmlms"/>
> > </system-properties>
> >
> > And then I can do something like the following in the
> > msh.properties.xml:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <Property>
> > <MSH>
> > <Log>
> > <!-- "JDK" or "LOG4J" -->
> > <UseLogger>LOG4J</UseLogger>
> > <!-- empty path: user.home -->
> > <LogPath>${ebxmlms.basedir}</LogPath>
> > <LogFile>msh.log</LogFile>
> > ...
> > </Log>
> > </MSH>
> > </Property>
> >
> > This makes it very easy for integrators, like myself, to move the
> > application server around the filesystem and have things completely
> > self-contained.
> >
> > So this means we can deploy Hermes and not have to deal with absolute
> > paths which is essential for our installation setup.
> >
> > You can find the file here:
> >
> > http://www.apache.org/~jvanzyl/ebxmlms/XMLProperty.java
> >
> > I'll send changes in whatever form you like. Do you prefer patches or
> > whole files?
> >
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > ja...@ze...
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > ebxmlms-develop mailing list
> > ebx...@li...
> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> >
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
--
jvz.
Jason van Zyl
ja...@ze...
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
|