Actually I think the sar format is good for certain things, bad for others.

For example having to jar and unjar when all you want to do is change the
xml file is silly, really.

I am thinking more and more about the bare xml "sar" that just points to a
repository of files including the class files as our default (already
supported in the current RH base ifrc).

Jar/sar/war/schmar is a distribution thing, a packaging thing, not a
development and/or runtime thing, it is not even really a deployment thingy.
Only the existence of ANT has made the use of Jars bearable in JBoss.

All we want to do it touch an xml file.

KISS

marcf

|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Andreas Schaefer
|Sent: Monday, October 29, 2001 5:46 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: Re: [JBoss-dev] Using system properties in jboss.jcml would
|help net boot
|
|
|I like the idea with the JNDI directory context. On the other hand I would
|prefer if the jetty.xml is added to the SAR file where it belongs from my
|point of view. What we really need is a way to open, change and save
|XML and other properties files in a SAR file otherwise you would have
|to unpack, change and pack it just to change the file.
|Unfortunately neither
|WinZip nor JAR does it for you. Maybe we should come up with a small
|utility to do this.
|
|Andy
|
|----- Original Message -----
|From: "Scott M Stark" <[EMAIL PROTECTED]>
|To: "Jboss-Development@Lists. Sourceforge. Net"
|<[EMAIL PROTECTED]>
|Sent: Monday, October 29, 2001 2:26 PM
|Subject: Re: [JBoss-dev] Using system properties in jboss.jcml would help
|net boot
|
|
|> Your making sense, but for the use cases your talking about I don't agree
|> with the use of system properties. Rather, file paths should be relative
|to
|> a
|> "filesystem" JNDI DirContext so that both the location and implementation
|> of the filesystem is abstracted out. System properties also require setup
|on
|> the target host that I would rather handle on the configuration service.
|> My view of net installs is that I run the same command line on each
|> install target host and I get a properly configured JBoss server without
|> needing to locally configure the target host environment.
|>
|> This potentially requires an ability to take a base configuration and
|apply
|> a target host specific transformation. The install service would be a
|> JBoss servlet instead of a static web server that would handle the target
|> host transformations.
|>
|> ----- Original Message -----
|> From: Bill Burke
|> To: Jboss-Development@Lists. Sourceforge. Net
|> Sent: Monday, October 29, 2001 10:23 AM
|> Subject: [JBoss-dev] Using system properties in jboss.jcml would help net
|> boot
|>
|>
|> Hey,
|>
|> I think it would be nice to be able to access system properties within
|> jboss.jcml or any other MBean XML descriptor.   I think this
|would greatly
|> help the net-boot(--net-install) feature of JBoss 3.0.  For
|example, Jetty
|> is packaged in a .sar in JBoss 3.0.  In that sar is the MBean XML
|descriptor
|> that has a hardcoded path to Jetty's configuration file 'jetty.xml'.
|Since
|> it is hardcoded this sar file cannot be deployed from a net installation
|of
|> jboss.  Instead of putting the url "../conf/default/jetty.xml"
|as the path
|> to jetty's configuration, I think something like
|> "${INSTALL_PATH}/conf/${CONFIG_DIR}/jetty.xml" would make things more
|> flexible.  JBoss would set up the INSTALL_PATH and CONFIG_DIR on startup
|as
|> System Properties.  Am I making any sense?
|>
|> Bill
|>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> https://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to