RE: The FIX - Shutdown not working under SLES8 and FC2

2005-02-03 Thread Al Sutton
Is there any reason why it doesn't try localhost first? Using localhost
before anything else would have the following benefits;

a) Would ensure that only really strange network configs would be affected
(i.e. those where localhost is not the local host).
b) Make use of the speed advantage some OS's have in their implementation of
the loopback address.
c) Avoid any wacky differences in the implementation of
InetAddress.getLocalHost() between JVMs/OSs/etc.

Off the top off my head I can't see the advantages of using the result of
InetAddress.getLocalHost() first.

Al.

-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]
Sent: 03 February 2005 19:11
To: Tomcat Developers List
Subject: Re: The FIX - Shutdown not working under SLES8 and FC2


If no address is configured, ChannelSocket attempts the shutdown on
InetAddress.getLocalHost().  Personally, I'm not inclined to change this as
it points to a network configuration problem if this is unreachable.
However, you might try complaining to Sun about how they have implemented
getLocalHost on SLES8.

- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Cc: tomcat-dev@jakarta.apache.org
Sent: Thursday, February 03, 2005 2:14 AM
Subject: The FIX - Shutdown not working under SLES8 and FC2



After some playing around I think I've tracked down what the fix is, and
I'd like to throw an idea out as to what could be happening.

First the fix. The fix is to explicitly state in the AJP13 connector
that the connector should ONLY bind to the loopback address (i.e. add
address=127.0.0.1). Maybe this should be made the default because;

a) it's a fix to the issue.
and
b) it also enhances security.

Those people who are using AJP13 between machines should have the
knowlege to re-configure the connector to allow connections between
different machines.

Now the suggestion as to why this is happening.

My machine is behind a firewall, and therefore has non-routable IP
addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on
the machine the hosts file resolves it to the private IP, if you look
it up using DNS it resolves to the public IP address of the firewall.
If you lookup the machine name only (a) from on the machine or anywhere
else it resolves via DNS to the public IP of the firewall.

From what I can tell the AJP13 connector looks up the hostname only,
(which resolves it to the public IP address), then tries to connect to
the AJP13 port on the public IP address, and because the firewall
blocks this traffic, does not connect, and then gives up.

To back this up I have put the hostname on it's own into the hosts file
(i.e. a resolves to the private IP), and everything worked again.

Before everyone shouts you've got a strange config, it's your problem,
I'd like to re-iterate that this issue can be avoided in many ways, and
my personal beleif is that the order of preference of fixes would be;

1) Add the address=127.0.0.1 to the default server.xml (which also has
the side effect of increasing security).
2) If no address is specified then make the shutdown system start by
trying to connect to localhost as opposed to what seems to be the
current behaviour of attempting to resolve to an external address
first.
3) Require everyone to have the short hostname configured to resolve to
their local IP.

The reasons for this ordering is that 1 is the least effort by the
fewest people, 2 is more effort but by a small group, 3 has a potential
impact on all users and no matter where you document it will still be
missed by those who beleive in unpack and run.

Regards,

Al.


Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16:
 Ben,

 Thanks for this. I'm not using any settings in JAVA_OPTS as shown below;

 [EMAIL PROTECTED] al]$ env | grep -i JAVA
 JRE_HOME=/usr/java/jdk1.4/jre

PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/
 bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
 JAVA_HOME=/usr/java/jdk1.4
 [EMAIL PROTECTED] al]$

 I've tried this on two machines, one an Athlon XP 2400+ running FC2, and
the
 other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so
 I'm pretty sure it's not hardware. The machines are also geographically
 seperated and do not operate on the network (ones on my LAN at home, the
 others on a LAN at work), so I'm pretty sure it's not related to the
 environment external to the machine.

 I'm going to upgrade to _07 and get the latest kernel and try again, as
 currently the only difference seems to be that your execting startup and
 shutdown from within the bin directory and I'm executing it from the top
 level (i.e. doing bin/startup.sh and bin/shutdown.sh).

 Thanks again,

 Al.


 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED]
 Sent: 02 February 2005 23:32
 To: Tomcat Users List
 Subject: RE: Shutdown not working under SLES8 and FC2


 On Wed, 2005-02-02 at 17:11, Ben Souther wrote:
  On Wed, 2005-02

RE: The FIX - Shutdown not working under SLES8 and FC2

2005-02-03 Thread Al Sutton
Costin,

The answer to your question is all of the above (i.e. start with localhost,
then 127.0.0.1, then try the IPv6 localhost). I'm not saying it's the only
behaviour, just that trying it first may make more stable than trying a
hostname first.

It's als less work by fewer people to change Tomcat than to check, test, and
modify (if neccessary) all the JVMs in existance.

Al.

-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: 04 February 2005 02:28
To: tomcat-dev@jakarta.apache.org
Subject: Re: The FIX - Shutdown not working under SLES8 and FC2


Al Sutton wrote:
 Is there any reason why it doesn't try localhost first? Using localhost
 before anything else would have the following benefits;

 a) Would ensure that only really strange network configs would be affected
 (i.e. those where localhost is not the local host).
 b) Make use of the speed advantage some OS's have in their implementation
of
 the loopback address.
 c) Avoid any wacky differences in the implementation of
 InetAddress.getLocalHost() between JVMs/OSs/etc.

 Off the top off my head I can't see the advantages of using the result of
 InetAddress.getLocalHost() first.

What do you mean by 'try localhost first' ? The name 'localhost', or
'127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for
InetAddress.getLocalHost() is the wacky differences between OSes :-),
and if it's broken on a platform - it should be fixed ( by Sun or OS
vendor )

Costin





 Al.

 -Original Message-
 From: Bill Barker [mailto:[EMAIL PROTECTED]
 Sent: 03 February 2005 19:11
 To: Tomcat Developers List
 Subject: Re: The FIX - Shutdown not working under SLES8 and FC2


 If no address is configured, ChannelSocket attempts the shutdown on
 InetAddress.getLocalHost().  Personally, I'm not inclined to change this
as
 it points to a network configuration problem if this is unreachable.
 However, you might try complaining to Sun about how they have implemented
 getLocalHost on SLES8.

 - Original Message -
 From: [EMAIL PROTECTED]
 To: Tomcat Users List tomcat-user@jakarta.apache.org
 Cc: tomcat-dev@jakarta.apache.org
 Sent: Thursday, February 03, 2005 2:14 AM
 Subject: The FIX - Shutdown not working under SLES8 and FC2



 After some playing around I think I've tracked down what the fix is, and
 I'd like to throw an idea out as to what could be happening.

 First the fix. The fix is to explicitly state in the AJP13 connector
 that the connector should ONLY bind to the loopback address (i.e. add
 address=127.0.0.1). Maybe this should be made the default because;

 a) it's a fix to the issue.
 and
 b) it also enhances security.

 Those people who are using AJP13 between machines should have the
 knowlege to re-configure the connector to allow connections between
 different machines.

 Now the suggestion as to why this is happening.

 My machine is behind a firewall, and therefore has non-routable IP
 addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on
 the machine the hosts file resolves it to the private IP, if you look
 it up using DNS it resolves to the public IP address of the firewall.
 If you lookup the machine name only (a) from on the machine or anywhere
 else it resolves via DNS to the public IP of the firewall.

 From what I can tell the AJP13 connector looks up the hostname only,
 (which resolves it to the public IP address), then tries to connect to
 the AJP13 port on the public IP address, and because the firewall
 blocks this traffic, does not connect, and then gives up.

 To back this up I have put the hostname on it's own into the hosts file
 (i.e. a resolves to the private IP), and everything worked again.

 Before everyone shouts you've got a strange config, it's your problem,
 I'd like to re-iterate that this issue can be avoided in many ways, and
 my personal beleif is that the order of preference of fixes would be;

 1) Add the address=127.0.0.1 to the default server.xml (which also has
 the side effect of increasing security).
 2) If no address is specified then make the shutdown system start by
 trying to connect to localhost as opposed to what seems to be the
 current behaviour of attempting to resolve to an external address
 first.
 3) Require everyone to have the short hostname configured to resolve to
 their local IP.

 The reasons for this ordering is that 1 is the least effort by the
 fewest people, 2 is more effort but by a small group, 3 has a potential
 impact on all users and no matter where you document it will still be
 missed by those who beleive in unpack and run.

 Regards,

 Al.


 Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16:

Ben,

Thanks for this. I'm not using any settings in JAVA_OPTS as shown below;

[EMAIL PROTECTED] al]$ env | grep -i JAVA
JRE_HOME=/usr/java/jdk1.4/jre



PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/

bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
JAVA_HOME=/usr/java/jdk1.4

RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work

2005-02-02 Thread Al Sutton
In answer to your points;

on 3) I'm not asking for it tested on all distros, just those where issues
have arisen. If no-one has FC2 installed then thats something the group
should know about and should be able to say Sorry, no-one has FC2, rather
than Closed bug, doesn't work on [insert name of totally different platform
here].

The users mail list has a report from Drew Jorgenson if it not working on
RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a
non-redhat product), so I don't think it's distribution specific.

on 4) It's never good to write that any other groups efforts off as crappy,
I'm sure this group wouldn't be happy if the Fedora group described Tomcat
as crappy. We're all doing our best (yes, I have released some open source
code in the past), and it worried me that the crappy comment was made and
no-one else stepped in to be a bit more helpful.

on 5) Given your response I'm happy to offer help with FC2 related problems.
I wasn't willing to make this offer before because it seemed the only
responses I had were aimed more at getting the bug marked as closed than
investigating where the problem was. I'll keep an eye on the -dev list (but
unfortunatley I don't have time to look at all the bug report comments) and
if I see a problem with FC2 I will attempt to dupluicate it. In case your
wondering what my experience is I've been a Linux sys admin for 11 years,
and have been programming system in Java for about 8 years with the last 5
spent focused on developing high performance server side applications for
Teleco's and Financial institutions, which hopefully will allow me to assist
in some way.

on the last paragraph - I completely agree. If people know which platforms
are fully supported (i.e. if bugs are reported someone can test them
easilly) it will make life a lot easier. You'll probably find that in return
for listing a platform as full supported the distributor may be receptive to
including Tomcat in their product.

Costin, I'd like to thank you for the sending the first comprehensive
response which makes me feel that users bugs are taken seriously, and not
treated as something that should be closed at any costs.

Regards,

Al.


-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: 02 February 2005 21:22
To: tomcat-dev@jakarta.apache.org
Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work


[EMAIL PROTECTED] wrote:

 3) Cygwin is definatley NOT a good platform for testing Linux bugs on.

However testing with all possible linux distributions is not a good
choice either.

And distributions based on 'latest' version of everything plus all kind
of experimental/non stable/vendor specific stuff -  like fedora - are
not the best choice for a supported platform.

Can you reproduce it on RHEL or RH9 ?  If not - report the bug on fedora.


 4) Do you want to tell the Fedora guys that the Tomcat developers
 official view of Fedora Core 2 is that its' a crappy distro?

It is not 'official view' - but some developers have issues with FC :-)


 5) Do you expect me to re-install my system just to get Tomcat working?,
 It's easier to replace Tomcat with Jetty than it would be to resintall
 my machine with one of the distros that you don't consider crappy

I believe a lot of products ( and not only java ) officially support
only few distributions. We can't ask you to re-install your system - but
you can't ask us to reinstall and test your favorite distro either.
There are just too many incompatible linux distributions.

If jetty works on your linux distro - just use it. It's a fine open
source product. Or you can use resin or any other server.


 Now I'd like to help resolve this, but at the moment all I'm seeing is a
 wall of not interesting, can't be bothered, lets' mark it as invalid
 because I can't reproduce on my own personal setup. Which kinda

Probably the comments should be more explicit - like 'unsupported
platform / not reproductible on supported platforms '.


Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work

2005-02-02 Thread Al Sutton
Ben,

Please re-read my email. It is discussing the initial response I received
from the -dev list, and then addressing the issue raised about it being
distribution specific.

My critisism was that the bug was initially closed when the only attempt to
re-produce it I was made aware of was made on a completely different
platform and that it initially appeared that the -dev list did not have
developers that were willing to investigate the problem.

Regards,

Al.

-Original Message-
From: Ben Souther [mailto:[EMAIL PROTECTED]
Sent: 02 February 2005 22:25
To: Tomcat Developers List
Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work


On Wed, 2005-02-02 at 16:54, Al Sutton wrote:
 In answer to your points;

 on 3) I'm not asking for it tested on all distros, just those where issues
 have arisen. If no-one has FC2 installed then thats something the group
 should know about and should be able to say Sorry, no-one has FC2,
rather
 than Closed bug, doesn't work on [insert name of totally different
platform
 here].

 The users mail list has a report from Drew Jorgenson if it not working on
 RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a
 non-redhat product), so I don't think it's distribution specific.

Just for the record, I tested on FC2 and posted the shell session on the
users list. You responded to my email before writing this message.
I've also stated that I'm willing to upgrade both the kernel and the JDK
to test under an environment that is closer to yours.

Please don't omit these details when when writing to either list. At the
very least, it's dishonest, at worst it's misleading and could cause
people to waste time repeating things that have already been done.

-Ben


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work

2005-02-01 Thread Al Sutton
So let me get this right, just because you can't reproduce it on your system
you're not willing to leave it open for others to check, despite the fact
you haven't, as yet, told me if your using the same JDK, Linux environment,
and you've not waiting for others to comment.

Guess the easiest way to get round this is to move to Jetty.

Al.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 01 February 2005 22:21
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 9] - Shutdown script down not work


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=9.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=9


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-02-01
23:21 ---
As I said originally, use the mailing list for discussion and to get
suggestions from other users.  This is not a discussion forum, especially
not
once two people (myself being the second) have confirmed that this issue is
not reproducible.  Please don't reopen this issue.

--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Patch to Tomcat 5.0 top level build.xml

2005-01-29 Thread Al Sutton
Please find attached a patch for build.xml properties supplied in the
TOMCAT_5.0 branch of the jakarta-tomcat-5 project which ensures that the
correct versions of supporting projects are checked out when the checkout
target is executed.

This patch has been made against code check on in the morning of 29th Jan
from the public anonymous CVS repository.

Regards,

Al.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Patch to Tomcat 5.0 default build properties

2005-01-29 Thread Al Sutton
Please find attached a patch for the default build properties supplied in
the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which corrects the URL
to obtain struts from.

This patch has been made against code check on in the morning of 29th Jan
from the public anonymous CVS repository.

Regards,

Al.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Patch to Tomcat 5.0

2005-01-29 Thread Al Sutton
Please find attached a patch for default build properties supplied in the
TOMCAT_5.0 branch of the jakarta-tomcat-5 project which alters the location
of the servlet-api to reflect where the jakarta-servletapi-5 project is
placed when the update or checkou targets are used to obtain the source.

This patch has been made against code checked out on the morning of 29th Jan
from the public anonymous CVS repository.

Regards,

Al.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-03-11 Thread Al Banard
Wow,

Thanks Jean you're right :). I still don't understand why I get this error 
when nobody else seems to.
I hope its just a superficial copying thing and that the build process 
wasn't compromised.

Thanks!

From: jean-frederic clere [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot 
install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in 
/usr/lib/apache2
Date: Wed, 10 Mar 2004 09:25:05 +0100

Al Banard wrote:
 mod_jk2.so is there but libjkjni.so isn't, which seems to be what its
 complaining about.
You should have a libjkjni.so in the .libs directory of 
jk/build/jk2/apache2.
When copied in modules it should work.


 From a previous email ...

 make clean build  makeOutput
 - This produces the attached makeOutput file and the following error to
 the terminal:
 libtool: install: warning: remember to run `libtool --finish
 /usr/lib/apache2'
 libtool: install: error: cannot install
 `../../../build/jk2/apache2/libjkjni.la' to a directory not ending in
 /usr/lib/apache2
 make[1]: *** [../../../build/jk2/apache2/libjkjni.so] Error 1
 make: *** [jk2-build] Error 1


 From: Kurt Miller [EMAIL PROTECTED]
 Reply-To: Tomcat Developers List [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error:
 cannot install `../../../build/jk2/apache2/jkjni.la' to a directory
 not ending in /usr/lib/apache2
 Date: Tue, 09 Mar 2004 15:26:00 -0500

 From: Al Banard [EMAIL PROTECTED]
  /bin/sh /usr/lib/apache2/build/libtool --silent  --mode=install
 /bin/cp
  ../../../build/jk2/apache2/mod_jk2.la
 `pwd`/../../../build/jk2/apache2
 ...
  /bin/sh /usr/lib/apache2/build/libtool --silent  --mode=install
 /bin/cp
  ../../../build/jk2/apache2/libjkjni.la
 `pwd`/../../../build/jk2/apache2
  make[1]: Leaving directory
 
 `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apa
 che2'

 This appears to have finished without error. Is mod_jk2.so in
 ../build/jk2/apache2 now?

 -Kurt


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 _
 Personalise your mobile chart ringtones and polyphonics. Go to
 http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 signature.asc 
_
Personalise your mobile chart ringtones and polyphonics. Go to  
http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-03-09 Thread Al Banard
mod_jk2.so is there but libjkjni.so isn't, which seems to be what its 
complaining about.

From a previous email ...
make clean build  makeOutput
- This produces the attached makeOutput file and the following error to the 
terminal:
libtool: install: warning: remember to run `libtool --finish 
/usr/lib/apache2'
libtool: install: error: cannot install 
`../../../build/jk2/apache2/libjkjni.la' to a directory not ending in 
/usr/lib/apache2
make[1]: *** [../../../build/jk2/apache2/libjkjni.so] Error 1
make: *** [jk2-build] Error 1


From: Kurt Miller [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot 
install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in 
/usr/lib/apache2
Date: Tue, 09 Mar 2004 15:26:00 -0500

From: Al Banard [EMAIL PROTECTED]
 /bin/sh /usr/lib/apache2/build/libtool --silent  --mode=install
/bin/cp
 ../../../build/jk2/apache2/mod_jk2.la
`pwd`/../../../build/jk2/apache2
...
 /bin/sh /usr/lib/apache2/build/libtool --silent  --mode=install
/bin/cp
 ../../../build/jk2/apache2/libjkjni.la
`pwd`/../../../build/jk2/apache2
 make[1]: Leaving directory

`/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apa
che2'
This appears to have finished without error. Is mod_jk2.so in
../build/jk2/apache2 now?
-Kurt

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Personalise your mobile chart ringtones and polyphonics. Go to  
http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-03-05 Thread Al Banard
Jean, sorry for the late reply to your previous message, but here is what 
you requested + exactly what I did. However I did not find any jkjni.la file 
in the CVS sources and this file wasn't produced.

STEPS:

tar xzvf jakarta-tomcat-connectors_20040305232049.tar.gz

cd jakarta-tomcat-connectors/jk/native2

chmod 0777 buildconf.sh

./buildconf.sh
- This produces the following output:
rm autom4te.cache
libtoolize --force --automake --copy
aclocal
automake --copy --add-missing
automake: configure.in: installing `scripts/build/unix/install-sh'
automake: configure.in: installing `scripts/build/unix/mkinstalldirs'
automake: configure.in: installing `scripts/build/unix/missing'
autoconf
- End output
./configure --with-java-home=/opt/sun-jdk-1.4.2.03  
--with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat
- This produces the following output:
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ld used by GCC... /usr/i686-pc-linux-gnu/bin/ld
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... 
-r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /bin/sed
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking command to parse /usr/bin/nm -B output... ok
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking whether the linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared 
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking for test... /usr/bin/test
checking for rm... /bin/rm
checking for grep... /bin/grep
checking for echo... /bin/echo
checking for sed... /bin/sed
checking for cp... /bin/cp
checking for mkdir... /bin/mkdir
no apxs given
need to check for Perl first, apxs depends on it...
checking for perl... /usr/bin/perl
building connector for apache-2.0
checking checking for apache13.. not provided
checking checking for apache20.. not provided
checking checking for iis.. not provided
checking checking for iPlanet.. not provided
checking for tomcat33 location... not provided
checking for tomcat40 location... not provided
checking for tomcat41 location... /usr/local/tomcat
configure: creating ./config.status
config.status: creating Makefile
config.status: creating server/apache13/Makefile
config.status: creating server/apache13/Makefile.apxs
config.status: creating server/apache2/Makefile
config.status: creating server/apache2/Makefile.apxs
config.status: creating ../build.properties
config.status: creating scripts/build/unix/dummy
- End output

make clean build  makeOutput
- This produces the attached makeOutput file and the following error to the 
terminal:
libtool: install: warning: remember to run `libtool --finish 
/usr/lib/apache2'
libtool: install: error: cannot install 
`../../../build/jk2/apache2/libjkjni.la' to a directory not ending in 
/usr/lib/apache2
make[1]: *** 

Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-03-05 Thread Al Banard
For some reason the makeOutput file did not attach so here it is in the 
flesh...

list=' server/apache2'; \
for i in $list; do \
	echo Making $target in $i; \
	if test $i != .; then \
	(cd $i  make clean) || exit 1; \
fi; \
done;
Making  in server/apache2
make[1]: Entering directory 
`/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2'
rm -rf ../../../build/jk2/apache2/*.lo ../../../build/jk2/apache2/*.la 
../../../build/jk2/apache2/*.o ../../../build/jk2/apache2/.libs 
../../../build/jk2/apache2/*.so
make[1]: Leaving directory 
`/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2'
list=' server/apache2'; \
for i in $list; do \
	echo Making $target in $i; \
	if test $i != .; then \
	(cd $i  make) || exit 1; \
fi; \
done;
Making  in server/apache2
make[1]: Entering directory 
`/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2'
mkdir -p ../../../build/jk2/apache2
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_channel.c -o ../../../build/jk2/apache2/jk_channel.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_channel_apr_socket.c -o 
../../../build/jk2/apache2/jk_channel_apr_socket.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_channel_jni.c -o 
../../../build/jk2/apache2/jk_channel_jni.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_channel_un.c -o ../../../build/jk2/apache2/jk_channel_un.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_config.c -o ../../../build/jk2/apache2/jk_config.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_config_file.c -o 
../../../build/jk2/apache2/jk_config_file.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  --mode=compile gcc  -O3 
-march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE   -I../../include -I/usr/include/apache2 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include 
-I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include   
-DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE  -c 
../../common/jk_endpoint.c -o ../../../build/jk2/apache2/jk_endpoint.lo
/bin/sh /usr/lib/apache2/build/libtool --silent  

Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-02-29 Thread Al Banard
I tried the latest CVS (using --with-apxs2) on the 25th Feb and got exactly 
the same error, unless things have changed with regard to this between now 
and then.


From: Kurt Miller [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot 
install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in 
/usr/lib/apache2
Date: Thu, 26 Feb 2004 12:27:41 -0500

Are you using the current source from CVS or
http://cvs.apache.org/snapshots/jakarta-tomcat-connectors/ yet?
libtool is set correctly for you in the current version. Simply
configure with --with-apxs2 with current source and it should be
correctly set for you.
From: Al Banard [EMAIL PROTECTED]
 Thanks,

 Unfortunately my OS is Gentoo and after installing there ebuild
(basically
 equivalent to an RPM) directories are all over the place.  The base
location
 of apache is actually /etc/apache2 but when I try using this as a
configure
 option I get this message:

 building connector for apache-2.0
 configure: error: can't locate /etc/apache2/

 and configure dies.

 Here is a list of the more relevant files that were installed with
the
 package.  Do you have any idea as to what I should put as my
argumernt to
 the configure option? libtool is in /usr/lib/apache2/build/libtool
but I've
 tried passing different combinations of this path without any luck.

 bash-2.05b# qpkg -l apache
 net-www/apache-2.0.48-r1 *
 CONTENTS:
(Please view previous email on this topic for file list, I didn't want to 
keep posting this to keep the post size down)



 From: jean-frederic clere [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error:
cannot
 install `../../../build/jk2/apache2/jkjni.la' to a directory not
ending in
 /usr/lib/apache2
 Date: Tue, 24 Feb 2004 16:16:31 +0100
 
 Al Banard wrote:
   Hi Henri,
  
   Thanks for giving me help.
  
   OK,  I have to admit I don't know a lot about libtool. I'm using
apache
   2.0.48 and have also installed apr-0.9.2. How do I specify to
use the
   libtool from Apache 2.0 / APR?
 
 That is what is done when you
use --with-apache2=$HOME/httpd-2.0.48.
 It works for me with the actual CVS and libtool-1.5.2 and
automake-1.6.1 (I
 build and install automake after libtool).
 
  
  
   From: Henri Gomez [EMAIL PROTECTED]
   To: Tomcat Developers List [EMAIL PROTECTED],
   [EMAIL PROTECTED]
   Subject: Re: DO NOT REPLY [Bug 27006]  - libtool: install:
error:
   cannot install `../../../build/jk2/apache2/jkjni.la' to a
directory
   not ending in /usr/lib/apache2
   Date: Tue, 24 Feb 2004 14:57:49 +0100
  
   Continuing this thread on tomcat-dev.
  
   Well you should use the libtool from Apache 2.0 / APR.
  
   Which version of Apache 2.0 are you using ?
  
  
   [EMAIL PROTECTED] wrote:
  
   DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED
COMMENTS
   THROUGH THE WEB INTERFACE AVAILABLE AT
   http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006.
   ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN
   THE BUG DATABASE.
  
   http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006
  
   libtool: install: error: cannot install
   `../../../build/jk2/apache2/jkjni.la' to a directory not
ending in
   /usr/lib/apache2
  
  
  
  
  
   --- Additional Comments From [EMAIL PROTECTED]
2004-02-24
   13:53 ---
   I just tried libtool 1.5.2-r3 and I still get the same error.
Can you
   think of anything else (program versions / configure options /
steps)
   I might be doing differently to you? Here is a recap of my
steps:
  
   cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/
   chmod 0777 buildconf.sh
   ./buildconf.sh
   ./configure --with-java-home=/opt/sun-jdk-1.4.2.03
   --with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat
   make clean build
   libtool --finish /usr/lib/apache2
  
 
 --
_
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-02-26 Thread Al Banard
Thanks,

Unfortunately my OS is Gentoo and after installing there ebuild (basically 
equivalent to an RPM) directories are all over the place.  The base location 
of apache is actually /etc/apache2 but when I try using this as a configure 
option I get this message:

building connector for apache-2.0
configure: error: can't locate /etc/apache2/
and configure dies.

Here is a list of the more relevant files that were installed with the 
package.  Do you have any idea as to what I should put as my argumernt to 
the configure option? libtool is in /usr/lib/apache2/build/libtool but I've 
tried passing different combinations of this path without any luck.

bash-2.05b# qpkg -l apache
net-www/apache-2.0.48-r1 *
CONTENTS:
/usr
/usr/include
/usr/include/apache2
/usr/include/apache2/apr.h
/usr/include/apache2/apr_allocator.h
/usr/include/apache2/apr_atomic.h
...
/usr/include/apache2/ssl_util_ssl.h
/usr/include/apache2/ssl_util_table.h
/usr/include/apache2/pcre.h
/usr/include/apache2/unixd.h
/usr/lib
/usr/lib/libapr-0.so.0.9.5
/usr/lib/libapr-0.so.0 - libapr-0.so.0.9.5
/usr/lib/libapr-0.so - libapr-0.so.0.9.5
/usr/lib/libapr-0.la
/usr/lib/libapr-0.a
/usr/lib/apr.exp
/usr/lib/apache2
/usr/lib/apache2/build
/usr/lib/apache2/build/libtool
/usr/lib/apache2/build/apr_rules.mk
/usr/lib/apache2/build/config_vars.mk
/usr/lib/apache2/build/library.mk
/usr/lib/apache2/build/ltlib.mk
/usr/lib/apache2/build/program.mk
/usr/lib/apache2/build/rules.mk
/usr/lib/apache2/build/special.mk
/usr/lib/apache2/build/instdso.sh
/usr/lib/apache2/build/config.nice
/usr/lib/apache2/build/envvars
/usr/lib/apache2/build/envvars-std
/usr/lib/apache2/mod_access.so
/usr/lib/apache2/mod_auth.so
/usr/lib/apache2/mod_auth_anon.so
...
/usr/lib/apache2/mod_userdir.so
/usr/lib/apache2/mod_alias.so
/usr/lib/apache2/mod_rewrite.so
/usr/lib/apache2/httpd.exp
/usr/lib/libaprutil-0.so.0.9.5
/usr/lib/libaprutil-0.so.0 - libaprutil-0.so.0.9.5
/usr/lib/libaprutil-0.so - libaprutil-0.so.0.9.5
/usr/lib/libaprutil-0.la
/usr/lib/libaprutil-0.a
/usr/lib/aprutil.exp
/usr/lib/ssl
/usr/lib/ssl/apache2-mod_ssl
/usr/lib/ssl/apache2-mod_ssl/gentestcrt.sh
/usr/lib/apache2-extramodules
/usr/lib/apache2-extramodules/mod_ssl.so
/usr/bin
/usr/bin/apr-config
/usr/bin/apu-config
/usr/sbin
/usr/sbin/ab2
/usr/sbin/logresolve2
/usr/sbin/apxs2
/usr/sbin/dbmmanage2
/usr/sbin/ab2-ssl
/usr/sbin/suexec2
/usr/sbin/htdbm
/usr/sbin/htdigest2
/usr/sbin/checkgid2
/usr/sbin/rotatelogs2
/usr/sbin/apache2
/usr/sbin/apache2logserverstatus
/usr/sbin/apache2splitlogfile
/usr/sbin/list_hooks2.pl
/usr/sbin/logresolve2.pl
/usr/sbin/apache2ctl
/usr/sbin/htpasswd2
/usr/sbin/split-logfile2
/usr/sbin/log_server_status2
/usr/share
/usr/share/man
/usr/share/man/man1
...
/usr/share/man/man8/apache2.8.gz
/usr/share/man/man8/apache2ctl.8.gz
/usr/share/man/man8/logresolve2.8.gz
/usr/share/doc
/usr/share/doc/apache-2.0.48-r1
/usr/share/doc/apache-2.0.48-r1/manual
...

From: jean-frederic clere [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot 
install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in 
/usr/lib/apache2
Date: Tue, 24 Feb 2004 16:16:31 +0100

Al Banard wrote:
 Hi Henri,

 Thanks for giving me help.

 OK,  I have to admit I don't know a lot about libtool. I'm using apache
 2.0.48 and have also installed apr-0.9.2. How do I specify to use the
 libtool from Apache 2.0 / APR?
That is what is done when you use --with-apache2=$HOME/httpd-2.0.48.
It works for me with the actual CVS and libtool-1.5.2 and automake-1.6.1 (I
build and install automake after libtool).


 From: Henri Gomez [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED],
 [EMAIL PROTECTED]
 Subject: Re: DO NOT REPLY [Bug 27006]  - libtool: install: error:
 cannot install `../../../build/jk2/apache2/jkjni.la' to a directory
 not ending in /usr/lib/apache2
 Date: Tue, 24 Feb 2004 14:57:49 +0100

 Continuing this thread on tomcat-dev.

 Well you should use the libtool from Apache 2.0 / APR.

 Which version of Apache 2.0 are you using ?


 [EMAIL PROTECTED] wrote:

 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS
 THROUGH THE WEB INTERFACE AVAILABLE AT
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006.
 ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN
 THE BUG DATABASE.

 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006

 libtool: install: error: cannot install
 `../../../build/jk2/apache2/jkjni.la' to a directory not ending in
 /usr/lib/apache2





 --- Additional Comments From [EMAIL PROTECTED]  2004-02-24
 13:53 ---
 I just tried libtool 1.5.2-r3 and I still get the same error. Can you
 think of anything else (program versions / configure options / steps)
 I might be doing differently to you? Here is a recap of my steps:

 cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/
 chmod 0777 buildconf.sh
 ./buildconf.sh
 ./configure

Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2

2004-02-24 Thread Al Banard
Hi Henri,

Thanks for giving me help.

OK,  I have to admit I don't know a lot about libtool. I'm using apache 
2.0.48 and have also installed apr-0.9.2. How do I specify to use the 
libtool from Apache 2.0 / APR?


From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED],  
[EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 27006]  - libtool: install: error: 
cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not 
ending in /usr/lib/apache2
Date: Tue, 24 Feb 2004 14:57:49 +0100

Continuing this thread on tomcat-dev.

Well you should use the libtool from Apache 2.0 / APR.

Which version of Apache 2.0 are you using ?

[EMAIL PROTECTED] wrote:

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS 
THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE 
BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006

libtool: install: error: cannot install 
`../../../build/jk2/apache2/jkjni.la' to a directory not ending in 
/usr/lib/apache2





--- Additional Comments From [EMAIL PROTECTED]  2004-02-24 13:53 
---
I just tried libtool 1.5.2-r3 and I still get the same error. Can you 
think of anything else (program versions / configure options / steps) I 
might be doing differently to you? Here is a recap of my steps:

cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/
chmod 0777 buildconf.sh
./buildconf.sh
./configure --with-java-home=/opt/sun-jdk-1.4.2.03 
--with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat
make clean build
libtool --finish /usr/lib/apache2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



_
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Please Help, Building JK2 failed

2003-03-13 Thread Al
Anonymous CVS from where?  Why checkout from CVS?  I am trying to build
a production JK2, not checkout development code.  My source came from
the jakarta site as a release.

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache
Sent: Wednesday, March 12, 2003 10:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Please Help, Building JK2 failed


Al wrote:


 jkant:
 
 BUILD FAILED 
 file:/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2
 -s
 rc/jk/build.xml:235: Warning: Could not find file

/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-src/jk
 /jkant/ant.tasks to copy.

Where did you got the sources ? 

Try using anonymous CVS - the file should be there.

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Please Help, Building JK2 failed

2003-03-12 Thread Al
Hi.

I am trying to build JK2 on AIX 4.3.3.  I have run ant already and it
has successfully built.  I am getting the error when running ant
native.  It is looking for the file ant.tasks but that file is not on
my machine.  Is the build suppose to make it?  Am I suppose to download
it from somewhere?  

Could someone tell me what I am doing wrong?  

Thanks,
Al
[EMAIL PROTECTED]

The error is ...

 ant native
Buildfile: build.xml

jkant:

BUILD FAILED
file:/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-s
rc/jk/build.xml:235: Warning: Could not find file
/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-src/jk
/jkant/ant.tasks to copy.

Total time: 39 seconds
~~~
Old Chinese proverb says, No use to run,
 Grasshopper, if you are on the wrong road. 




Re: Cocoon 2 Dumps Tomcat 4.1 on Apache1.3.22 SSL

2002-01-26 Thread Al-Qalbel-Mounir

Resubmitting since I can not solve this issue on my
own. 

 Please find the space dump in the attached file.
 
 I am testing new installation of Apache 1.3.22 SSL,
 Tomcat 4.0.1 with mod_webapp on RH Linux 7.1
 
 __
 Do You Yahoo!?
 Great stuff seeking new owners in Yahoo! Auctions! 
 http://auctions.yahoo.com Starting service
Tomcat-Apache
 Apache Tomcat/4.0
 Starting service MackConnector
 Apache Tomcat/4.0
 Server 1.6 is running
 Press [Ctrl]+[C] to abort
 SIGSEGV   11*  segmentation violation
 si_signo [11]: SIGSEGV   11*  segmentation
 violation
 si_errno [0]: Success
 si_code [1]: SEGV_MAPERR [addr: 0x0]
 
 stackpointer=0x448dab88
 
 Full thread dump Classic VM (1.2.2-L, green
 threads):
 Thread-15 (TID:0x40eb3fd0,
 sys_thread_t:0x9602250, state:R) prio=5
 at
 java.lang.ClassLoader.findLoadedClass(Native Method)
 at

java.lang.ClassLoader.loadClass(ClassLoader.java:275)
 at

java.lang.ClassLoader.loadClass(ClassLoader.java:243)
 at

org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(Unknown
 Source)
 at

org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(Unknown
 Source)
 at

org.apache.cocoon.sitemap.AbstractSitemap.compose(AbstractSitemap.java:123)
 at

org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(Unknown
 Source)
 at

org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(Unknown
 Source)
 at

org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:135)
 at

org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.addCompiledComponent(ProgramGeneratorImpl.java:345)
 at

org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:179)
 at

org.apache.cocoon.sitemap.Handler.run(Handler.java:208)
 at java.lang.Thread.run(Thread.java:475)
 Thread-14 (TID:0x40e57510,
 sys_thread_t:0x862f2b0, state:CW) prio=5
 at
 java.net.SocketInputStream.socketRead(Native Method)
 at

java.net.SocketInputStream.read(SocketInputStream.java:86)
 at

java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
 at

java.io.BufferedInputStream.read(BufferedInputStream.java:204)
 at

java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:517)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:494)
 at

org.hsqldb.ServerConnection.run(ServerConnection.java:116)
 Thread-12 (TID:0x40e57668,
 sys_thread_t:0x92ec350, state:CW) prio=5
 at
 java.net.SocketInputStream.socketRead(Native Method)
 at

java.net.SocketInputStream.read(SocketInputStream.java:86)
 at

java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
 at

java.io.BufferedInputStream.read(BufferedInputStream.java:204)
 at

java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:517)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:494)
 at

org.hsqldb.ServerConnection.run(ServerConnection.java:116)
 Thread-10 (TID:0x40e577c0,
 sys_thread_t:0x95bf928, state:CW) prio=5
 at
 java.net.SocketInputStream.socketRead(Native Method)
 at

java.net.SocketInputStream.read(SocketInputStream.java:86)
 at

java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
 at

java.io.BufferedInputStream.read(BufferedInputStream.java:204)
 at

java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:517)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:494)
 at

org.hsqldb.ServerConnection.run(ServerConnection.java:116)
 Thread-8 (TID:0x40e57920,
 sys_thread_t:0x94e4c00, state:CW) prio=5
 at
 java.net.SocketInputStream.socketRead(Native Method)
 at

java.net.SocketInputStream.read(SocketInputStream.java:86)
 at

java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
 at

java.io.BufferedInputStream.read(BufferedInputStream.java:204)
 at

java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:517)
 at

java.io.DataInputStream.readUTF(DataInputStream.java:494)
 at

org.hsqldb.ServerConnection.run(ServerConnection.java:116)
 Thread-6 (TID:0x40ea5510,
 sys_thread_t:0x95c26c0, state:CW) prio=5
 at java.lang.Thread.sleep(Native Method)
 at org.hsqldb.Log.run(Log.java:119)
 at java.lang.Thread.run(Thread.java:475)
 Thread-5 (TID:0x40ee9290,
 sys_thread_t:0x93278c8, state:CW) prio=5
 at