[JBoss-dev] deprecations
Hi all, I notice when compiling the HEAD branch out of CVS, there are quite a few deprecation warnings. Is this anything anybody cares about? If so, I'd be happy to have a go at fixing these -- If these are things in the core java.*/javax.* API that have been deprecated since J2SE 1.2.x, I think we can go ahead and upgrade them, since RH requires 1.3.x, right? -jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-docs] Is the build system too complica ted?
Sorry -- been out of town for a few days... The execute bits shouldn't be lost when you tar up a filelook at this output--the executable bit is still set: (using gnu tar --- anybody know if the other versions of UNIX tar behave any differently?) [jason@buford test]$ touch test.txt [jason@buford test]$ ls -l total 0 -rw-rw-r--1 jasonjason 0 Nov 25 18:31 test.txt [jason@buford test]$ chmod +x test.txt [jason@buford test]$ ls -l total 0 -rwxrwxr-x1 jasonjason 0 Nov 25 18:31 test.txt [jason@buford test]$ tar -cvf test.tar test.txt test.txt [jason@buford test]$ ls -l total 20 -rw-rw-r--1 jasonjason 10240 Nov 25 18:32 test.tar -rwxrwxr-x1 jasonjason 0 Nov 25 18:31 test.txt [jason@buford test]$ rm test.txt [jason@buford test]$ tar -xvf test.tar test.txt [jason@buford test]$ ls -la -rw-rw-r--1 jasonjason 10240 Nov 25 18:32 test.tar -rwxrwxr-x1 jasonjason 0 Nov 25 18:31 test.txt Jason Dillon [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/22/2001 12:14 AM To: Dain Sundstrom [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:RE: [JBoss-dev] Re: [jboss-docs] Is the build system too complica ted? On Wed, 21 Nov 2001, Dain Sundstrom wrote: java really pisses me off sometimes. why can't you get file perms from a given platform? all of this platform independence has really dumbed down the file access apis, too much in my oppinon. I think you can with 1.4 That would be nice. I will have to look over the changes again. rant it appears that there is noway with the vanilla jdk to check if a file is executable... which is really *ucking stupid if you ask me... but since you didn't well I am telling you anyways. Afterall who would want to execute a file from Java? Whatever, where do they find the people that design this crap. /rant Doesn't ant have a chmod task. It does, but it is dependent on executing the `chmod` program. We use it to setup the perms for scripts in the output directory. Chmod in this case won't help since once we tar (or zip) up the directory those bits will be lost. --jason ___ 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
RE: [JBoss-dev] Re: [jboss-docs] Is the build system too complica ted?
hrmm...unfortunately no -- I had tried that before, but CVS complains that
I don't have read/write access to the history file.
-jason
Dain Sundstrom [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/21/2001 07:54 PM
To: 'Jason Dillon' [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:RE: [JBoss-dev] Re: [jboss-docs] Is the build system too
complica ted?
I think you can use cvs over ssh to down load the code even if you don't
have rw. All you would need is a sourceforge shell account, and I think
you
get one just by signing up for a sf user account. I'm not completely sure
but I would try.
-dain
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 1:44 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
I see. Let me see if I can fix the snapshots, else I will
fix build.sh.
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
Unfortunately, my firewall currently doesn't let me check
out via cvs
directly unless it's over ssh, and I don't have RW access to the
repository (yet :) -- I've been downloading the nightly
snapshots (ugh)
in .tgz form from http://www.jboss.org/snapshots/. When I
untar that, the
executable bit is not set.(using gnu tar and gzip on
linux with the
command 'tar -xzvf jboss-all.tgz`) Actually, from a few
spot checks, it
looks as if everything comes out '-rw-r--r--', including
build.sh itself.
Yes, I've tried using the -p option with tar to extract permissions
information -- no effect (I think that's the default
anyway, though I'm
not sure)
-jason
Jason Dillon [EMAIL PROTECTED]
11/21/2001 02:09 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: [JBoss-dev] Re: [jboss-docs] Is
the build system too complicated?
The executable bit is set on tools/bin/ant. Why dosen't
your cvs client
set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
I do have a slightly off-topic gripe -- as of late, (in the rh
snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX
systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because
of it. It
looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to
start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the
executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and
attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it
exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is
the build system
too complicated?
I have not found an easy way to provide this common
setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP
parser to read a
resource file when parsing this could be done, but that
would require
the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them
todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication
between
the
setup parts of the module level build.xml files. I
sure haven't
figured
out a clue of a way to reduce this, but if it could be
done, it might
make
the files a little less intimidating. In light of the vast
improvement
over the preceding build system, this is a hardly
visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
Have you had any luck getting this to work with sourceforge? It appears that it requires a little different setup serverside -jason Adam Heath [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/21/2001 07:41 PM To: [EMAIL PROTECTED] cc: Jason Dillon [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated? On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote: Unfortunately, my firewall currently doesn't let me check out via cvs directly unless it's over ssh, and I don't have RW access to the repository (yet :) -- I've been downloading the nightly snapshots (ugh) in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the executable bit is not set.(using gnu tar and gzip on linux with the command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it looks as if everything comes out '-rw-r--r--', including build.sh itself. Yes, I've tried using the -p option with tar to extract permissions information -- no effect (I think that's the default anyway, though I'm not sure) http://kitenet.net/programs/sshcvs/ CVS over anonymous ssh. ___ 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
Re: [JBoss-dev] CVS update: website-snapshots build.xml
Why set permissions to 655? (rw owner, rx for group and world) --- the
owner of the files can't execute these---755 is probably the right choice
here. Really, build.sh is the only one to worry about --- I don't see why
you can't execute the 'ant' program or 'antRun' with calls to sh like 'sh
../tools/bin/ant' (pretty much has to be configured correctly on any UNIX
system for it to function). Even if we are still having trouble getting
build.sh executable properly, it's easy enough to drop in a README or
INSTALL doc to tell the user to execute 'sh build.sh' which should work
regardless.
Why does build.sh need the search() function anyway? Don't we pretty much
know where our version of ant is going to be located? You can just export
ANT_HOME to be whatever you
want
I know that this stuff is probably not JBoss' biggest priority right now,
but I'd like to make this as easy as possible for anybody to build! (Tell
me to shut up about this and I will -- I can make it work for myself
regardless :)
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/21/2001 05:42 PM
To: [EMAIL PROTECTED]
cc:
Subject:[JBoss-dev] CVS update: website-snapshots build.xml
User: user57
Date: 01/11/21 14:42:36
Modified:.build.xml
Log:
o HACKED the build file to make all 'build.sh' and
'tools/bin/ant[Run]' files executable.
! I don't really like it, but don't have much choice. Thanks SUN!
Revision ChangesPath
1.2 +41 -17website-snapshots/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/website-snapshots/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 2001/11/20 00:42:20 1.1
+++ build.xml 2001/11/21 22:42:35 1.2
@@ -10,7 +10,7 @@
!-- --
!--
== --
-!-- $Id: build.xml,v 1.1 2001/11/20 00:42:20 user57 Exp $ --
+!-- $Id: build.xml,v 1.2 2001/11/21 22:42:35 user57 Exp $ --
project default=main name=JBoss Website/Snapshots
@@ -264,9 +264,9 @@
echoExporting CVS modules for snaphots.../echo
-!-- Make sure there is an entry for this cvsroot --
+ !-- Make sure there is an entry for this cvsroot --
- cvspass cvsroot=${snapshot.cvsroot} password=/
+ cvspass cvsroot=${snapshot.cvsroot} password=/
cvs cvsroot=${snapshot.cvsroot}
command=-Q -r -f -z3 export
date=TODAY
@@ -291,10 +291,18 @@
!-- build jboss-all.tgz --
-tar tarfile=${build.snapshots}/jboss-all.tar
- longfile=gnu
- basedir=${build.snapshots.tmp}
- includes=jboss-all/**
+tar tarfile=${build.snapshots}/jboss-all.tar longfile=gnu
+ tarfileset dir=${build.snapshots.tmp} mode=655
+include name=jboss-all/**/build.sh/
+include name=jboss-all/**/tools/bin/ant/
+include name=jboss-all/**/tools/bin/antRun/
+ /tarfileset
+ tarfileset dir=${build.snapshots.tmp} mode=644
+include name=jboss-all/**/
+exclude name=jboss-all/**/build.sh/
+exclude name=jboss-all/**/tools/bin/ant/
+exclude name=jboss-all/**/tools/bin/antRun/
+ /tarfileset
/tar
gzip src=${build.snapshots}/jboss-all.tar
zipfile=${build.snapshots}/jboss-all.tgz/
@@ -309,27 +317,43 @@
!-- build jboss-mq.tgz --
-tar tarfile=${build.snapshots}/jboss-mq.tar
- longfile=gnu
- basedir=${build.snapshots.tmp}
- includes=jboss-mq/**
+tar tarfile=${build.snapshots}/jboss-mq.tar longfile=gnu
+ tarfileset dir=${build.snapshots.tmp} mode=655
+include name=jboss-mq/**/build.sh/
+include name=jboss-mq/**/tools/bin/ant/
+include name=jboss-mq/**/tools/bin/antRun/
+ /tarfileset
+ tarfileset dir=${build.snapshots.tmp} mode=644
+include name=jboss-mq/**/
+exclude name=jboss-mq/**/build.sh/
+exclude name=jboss-mq/**/tools/bin/ant/
+exclude name=jboss-mq/**/tools/bin/antRun/
+ /tarfileset
/tar
gzip src=${build.snapshots}/jboss-mq.tar
zipfile=${build.snapshots}/jboss-mq.tgz/
!-- build jboss-plugins.zip --
-
- zip zipfile=${build.snapshots}/jboss-plugins.zip
+
+zip zipfile=${build.snapshots}/jboss-plugins.zip
fileset dir=${build.snapshots.tmp}
include name=jboss-plugins/**/
/fileset
/zip
!-- build jboss-plugins.tgz --
- tar tarfile=${build.snapshots}/jboss-plugins.tar
- longfile=gnu
- basedir=${build.snapshots.tmp}
-
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
I do have a slightly off-topic gripe -- as of late, (in the rh snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication between
the
setup parts of the module level build.xml files. I sure haven't figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor -~--
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
-~-
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
___
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
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
Unfortunately, my firewall currently doesn't let me check out via cvs
directly unless it's over ssh, and I don't have RW access to the
repository (yet :) -- I've been downloading the nightly snapshots (ugh)
in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
executable bit is not set.(using gnu tar and gzip on linux with the
command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
looks as if everything comes out '-rw-r--r--', including build.sh itself.
Yes, I've tried using the -p option with tar to extract permissions
information -- no effect (I think that's the default anyway, though I'm
not sure)
-jason
Jason Dillon [EMAIL PROTECTED]
11/21/2001 02:09 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client
set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
I do have a slightly off-topic gripe -- as of late, (in the rh
snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It
looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it
exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
too complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require
the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication
between
the
setup parts of the module level build.xml files. I sure haven't
figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast
improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor
-~--
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
-~-
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
[JBoss-dev] Application/Deployment Units
Hi all -- Sorry for such a newbie question, but Is there any place with jboss (working with rh) which stores data about *all* pieces of an application deployment at runtime? For instance, I can get the DeployedApplications attribute from the ContainerFactory MBean, which gives me an Iterator of org.jboss.ejb.Application objects, with which I can in turn retrieve the associated containers for each EJB. But, I haven't seen how to find any associated web applications in the same deployment unit. (I can get the DeployedApplication from the Jetty MBean, but there is no association with each webapp to the rest of its application) Could someone give me a little nudge in the right direction? thanks, jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Application/Deployment Units
thx -- i'll keep an eye out for it... -jason Andreas Schaefer [EMAIL PROTECTED] 11/20/2001 12:46 PM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject:Re: [JBoss-dev] Application/Deployment Units Hi Right now there is no more management information available. But soon the implementation of JSR-77 should provide you with the necessary informations. Have fun - Andy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 8:10 AM Subject: [JBoss-dev] Application/Deployment Units Hi all -- Sorry for such a newbie question, but Is there any place with jboss (working with rh) which stores data about *all* pieces of an application deployment at runtime? For instance, I can get the DeployedApplications attribute from the ContainerFactory MBean, which gives me an Iterator of org.jboss.ejb.Application objects, with which I can in turn retrieve the associated containers for each EJB. But, I haven't seen how to find any associated web applications in the same deployment unit. (I can get the DeployedApplication from the Jetty MBean, but there is no association with each webapp to the rest of its application) Could someone give me a little nudge in the right direction? thanks, jason ___ 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
Re: [JBoss-dev] suggest changing log4j layout patterns
Has there been any thought as to making the log4j component a configurable MBean like the rest of the system? It would be nice to be able to configure the logging properties via some administration interface on the fly via jmx. Right now it looks as if there is only a thin wrapper around starting log4j and pointing at its configuration file.
By the way, has any significant amount of work been done on an administration/monitoring utility? I'd be interested in working on something like this (or starting it if it hasn't been done already)
-jason
Scott M Stark [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/16/2001 01:25 PM
Please respond to Scott M Stark
To:[EMAIL PROTECTED]
cc:
Subject:Re: [JBoss-dev] suggest changing log4j layout patterns
The console output should be short and simple. In any production
envrionment your likely to not even be using it so its just for quick looks
and I don't want excessive info displayed there. The default server.log
format can be more verbose. Its also trival to change these settings if
you know enough about log4j, so I would rather keep the defaults
simpler and let you change them for your specific need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 4:09 PM
Subject: [JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main] () -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.
Any objections?
--jason
___
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
Re: [JBoss-dev] suggest changing log4j layout patterns
From your webapp is it possible to save the configuration changes so that they take affect next time? I haven't looked to see if RH retains that functionality or not, but being able to automatically save the config in jboss-auto is pretty nice for long term maintenance. -jason Rickard Öberg [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/16/2001 01:56 PM To:Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] cc: Subject:Re: [JBoss-dev] suggest changing log4j layout patterns [EMAIL PROTECTED] wrote: Has there been any thought as to making the log4j component a configurable MBean like the rest of the system? It would be nice to be able to configure the logging properties via some administration interface on the fly via jmx. Right now it looks as if there is only a thin wrapper around starting log4j and pointing at its configuration file. I've begun doing a simple log4j console in the WebWork project (sf.net/projects/webwork) which will allow you to see the categories and set debug levels and stuff like that, and also get log output. I'm not doing it as MBean's though, but as a WAR file. The app just hooks directly into log4j without going through JMX. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss-Catalina 2.4.3 / Apache Integration
Or perhaps some documentation to show how to use Apache's proxy capabilities when using TC4.0 (You can simulate *some* of the connector's capabilities that way) -jason Hunter Hillegas [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/05/2001 02:17 PM To: Scott M Stark [EMAIL PROTECTED], Scott M Stark [EMAIL PROTECTED], JBoss Dev [EMAIL PROTECTED] cc: Subject:Re: [JBoss-dev] JBoss-Catalina 2.4.3 / Apache Integration In the meantime, maybe the Tomcat+Apache+JBoss HOWTO should be updated to note that Apache+Tomcat only works with pre-Catalina (pre 4.0) versions of Tomcat to prevent confusion? From: Scott M Stark [EMAIL PROTECTED] Organization: JBoss Group Reply-To: Scott M Stark [EMAIL PROTECTED] Date: Fri, 5 Oct 2001 11:42:03 -0700 To: JBoss Dev [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss-Catalina 2.4.3 / Apache Integration No, and its not a priority for me at this point as I have tasks that generate money for JBoss in my queue. If you want to make it my priority speak with . Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Hunter Hillegas [EMAIL PROTECTED] To: menonv [EMAIL PROTECTED]; JBoss Dev [EMAIL PROTECTED] Sent: Friday, October 05, 2001 10:59 AM Subject: Re: [JBoss-dev] JBoss-Catalina 2.4.3 / Apache Integration We're in the same boat as you as far as needing to be able to put Apache in front of Catalina/JBoss... I haven't tried to do the integration yet but I'm sure there must be a way to link the two... Scott - you seem to be the keeper of the Tomcat integration code... Is this something that's implemented already? If not, from your work do you have any indication of how difficult it would be to add it? Let's figure this out and get it squashed... I'm sure that Apache+JBoss/Tomcat is a pretty common configuration. Hunter From: menonv [EMAIL PROTECTED] Date: Fri, 5 Oct 2001 09:22:57 +0100 To: JBoss Developer List [EMAIL PROTECTED] Subject: [JBoss-dev] JBoss-Catalina 2.4.3 / Apache Integration Hello folks, It's kind of important to our current setup and future directions with JBoss and hence am posting this message to the developer list. The question basically is whether the JBoss-Catalina bundle 2.4.3 [and future versions] will have support for integration with Apache? While all the integration talk is good and will improve performance and features, if it does not support the mod_webapp or mod_jk level integration with Apache it makes the whole this not a feasible solution for us. I have posted this question is several forms on the user list and have not got any concrete answer. If this Catalina MBean can indeed be configured for integration with Apache would really appreciate it if someone could let me know where I can find some documentation/notes on doing this. Kind Regards Vinay Menon ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
