You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Shevland, Joseph (AU - Hobart)" <js...@deloitte.com.au> on 2001/12/06 02:24:29 UTC
Compiling mod_webapp on FreeBSD 4
Hi all,
Sorry if this has been covered off but I couldn't find anything in the
archives or googling. I'm attempting to compile the latest mod_webapp under
FreeBSD 4.4-STABLE (in conjunction with Apache 1.3.22 and Tomcat 4.0.1).
I've had no success, but differing results trying different options. From
the source download from the Jakarta site, I can run 'sh
./support/buildconf.sh', then 'configure
--with-apxs=/usr/local/apache/bin/apxs ...' and then 'gmake'. This one bombs
out trying to build a libapr.a target or something like that.
I also tried getting the Apache 2 sources and pointing the configure option
for the APR stuff to this. This actually went through and compiled
mod_webapp.so OK... but trying to poke the resultant library into the Apache
1.3 libexec folder results in Apache complaining about an unknown symbol
'mod_webapp' or similar (I guess because I've used Apache 2 sources or
similar).
Sorry about the vagueness of error reports etc I can send detailed ones if
there's light somewhere around the end of the tunnel. A FreeBSD port would
be great, I'd be happy to bundle one up if I can get over the compilation
hurdles.
Cheers,
Joe Shevland
Deloitte Touche Tohmatsu
Phone: +61 3 6237 7029
Fax: +61 3 6237 7001
***********Confidentiality/Limited Liability Statement***************
Have the latest business news and in depth analysis delivered to your
desktop. Subscribe to "Insights", Deloitte's fortnightly email
business bulletin . . .
http://www.deloitte.com.au/preferences/preference.asp
This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message, you must not disseminate, copy or
take any action in reliance on it. If you have received this message
in error, please notify Deloitte Touche Tohmatsu immediately. Any
views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Deloitte.
The liability of Deloitte Touche Tohmatsu, is limited by, and to the
extent of, the Accountants' Scheme under the Professional Standards
Act 1994 (NSW).
The sender cannot guarantee that this email or any attachment to it
is free of computer viruses or other conditions which may damage or
interfere with data, hardware or software with which it might be used.
It is sent on the strict condition that the user carries out and relies
on its own procedures for ensuring that its use will not interfere with
the recipients systems and the recipient assumes all risk of use and
absolves the sender of all responsibility for any consequence of its use.
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Double check idiom broken - Tomcat uses it ?
Posted by Bo Xu <bo...@cybershop.ca>.
I have already forward your 2 emails to TOMCAT-developer, haha :-)
Bo
Dec.06, 2001
----- Original Message -----
From: "Jeff Kilbride" <je...@kilbride.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Thursday, December 06, 2001 2:41 PM
Subject: Re: Double check idiom broken - Tomcat uses it ?
> If you really want the developers to take a look at this, you should
> probably post it to the tomcat-dev list. It's iffy whether or not they
will
> see it here.
>
> Thanks,
> --jeff
>
> ----- Original Message -----
> From: "java programmer" <ja...@yahoo.com>
> To: <to...@jakarta.apache.org>
> Sent: Wednesday, December 05, 2001 10:44 PM
> Subject: Double check idiom broken - Tomcat uses it ?
>
>
> > Hi all:
> >
> > We all know that the lazy-double-check idiom doesn't
> > apply to Java because of the Java Memory Model (JMM).
> >
> > That is to say, look at code such as:
> >
> > Example a)
> > // Set by any other thread other than #1
> > volatile boolean stop = false;
> >
> > // Thread #1 runs this as long as
> > // stop is false. Only T1 will call this
> > // method, so not synchronized. hence
> > // broken due to staleness of 'stop'.
> > // synch for _visbility_ ALSO.
> > void foo() {
> > while (!stop ) { //... }
> > }
> >
> >
> > Example b): The lazy double check idiom
> > public static Foo haha = null;
> > public static getFoo() {
> > if (foo == null ) {
> > sychronized (Foo.class) {
> > if (foo == null )
> > foo = new Foo();
> > }
> > }
> > return foo;
> > }
> >
> > Both examples are *guaranteed* to be incorrect.
> > Note, this is the case, *even* though I am using
> > 'volatile' for the stop variable. For more on the
> > JMM, consult Item #48 in Effective Java (Josh Bloch),
> > look at Bill Pughs' page at:
> > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> > or check out Doug Lea's stuff.
> > Well, here is the thing:
> >
> > Quite idly, and randomly, I was looking at:
> >
> > org.apache.jasper.servlet.JspServlet
> >
> > and I found:
> >
> > <snip>
> > outDated = compiler.isOutDated();
> > if(!jsw.isInstantiated() || outDated ) {
> > synchronized(jsw){
> > outDated = compiler.compile();
> > if(!jsw.isInstantiated() || outDated) {
> > if( null ==ctxt.getServletClassName() ) {
> > <snip>
> >
> > This is a complex use of double check type
> > code and is really hard to analyse because references
> > themselves and what they point to can have
> > different levels of staleness (according to the JMM).
> > So it's a turbo double idiom type usage, possibly
> > incorrect.
> >
> > I just wanted to bring this to the attention of the
> > development team and make sure that *someone* has
> > really analysed this according to the JMM. (and
> > any other code, similar to this).
> >
> > Best regards,
> >
> > javadesigner@yahoo.com
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Send your FREE holiday greetings online!
> > http://greetings.yahoo.com
> >
> > --
> > To unsubscribe: <ma...@jakarta.apache.org>
> > For additional commands: <ma...@jakarta.apache.org>
> > Troubles with the list: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Double check idiom broken - Tomcat uses it ?
Posted by Jeff Kilbride <je...@kilbride.com>.
If you really want the developers to take a look at this, you should
probably post it to the tomcat-dev list. It's iffy whether or not they will
see it here.
Thanks,
--jeff
----- Original Message -----
From: "java programmer" <ja...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Wednesday, December 05, 2001 10:44 PM
Subject: Double check idiom broken - Tomcat uses it ?
> Hi all:
>
> We all know that the lazy-double-check idiom doesn't
> apply to Java because of the Java Memory Model (JMM).
>
> That is to say, look at code such as:
>
> Example a)
> // Set by any other thread other than #1
> volatile boolean stop = false;
>
> // Thread #1 runs this as long as
> // stop is false. Only T1 will call this
> // method, so not synchronized. hence
> // broken due to staleness of 'stop'.
> // synch for _visbility_ ALSO.
> void foo() {
> while (!stop ) { //... }
> }
>
>
> Example b): The lazy double check idiom
> public static Foo haha = null;
> public static getFoo() {
> if (foo == null ) {
> sychronized (Foo.class) {
> if (foo == null )
> foo = new Foo();
> }
> }
> return foo;
> }
>
> Both examples are *guaranteed* to be incorrect.
> Note, this is the case, *even* though I am using
> 'volatile' for the stop variable. For more on the
> JMM, consult Item #48 in Effective Java (Josh Bloch),
> look at Bill Pughs' page at:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> or check out Doug Lea's stuff.
> Well, here is the thing:
>
> Quite idly, and randomly, I was looking at:
>
> org.apache.jasper.servlet.JspServlet
>
> and I found:
>
> <snip>
> outDated = compiler.isOutDated();
> if(!jsw.isInstantiated() || outDated ) {
> synchronized(jsw){
> outDated = compiler.compile();
> if(!jsw.isInstantiated() || outDated) {
> if( null ==ctxt.getServletClassName() ) {
> <snip>
>
> This is a complex use of double check type
> code and is really hard to analyse because references
> themselves and what they point to can have
> different levels of staleness (according to the JMM).
> So it's a turbo double idiom type usage, possibly
> incorrect.
>
> I just wanted to bring this to the attention of the
> development team and make sure that *someone* has
> really analysed this according to the JMM. (and
> any other code, similar to this).
>
> Best regards,
>
> javadesigner@yahoo.com
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Double check idiom broken - Tomcat uses it ?
Posted by java programmer <ja...@yahoo.com>.
Hi all:
We all know that the lazy-double-check idiom doesn't
apply to Java because of the Java Memory Model (JMM).
That is to say, look at code such as:
Example a)
// Set by any other thread other than #1
volatile boolean stop = false;
// Thread #1 runs this as long as
// stop is false. Only T1 will call this
// method, so not synchronized. hence
// broken due to staleness of 'stop'.
// synch for _visbility_ ALSO.
void foo() {
while (!stop ) { //... }
}
Example b): The lazy double check idiom
public static Foo haha = null;
public static getFoo() {
if (foo == null ) {
sychronized (Foo.class) {
if (foo == null )
foo = new Foo();
}
}
return foo;
}
Both examples are *guaranteed* to be incorrect.
Note, this is the case, *even* though I am using
'volatile' for the stop variable. For more on the
JMM, consult Item #48 in Effective Java (Josh Bloch),
look at Bill Pughs' page at:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
or check out Doug Lea's stuff.
Well, here is the thing:
Quite idly, and randomly, I was looking at:
org.apache.jasper.servlet.JspServlet
and I found:
<snip>
outDated = compiler.isOutDated();
if(!jsw.isInstantiated() || outDated ) {
synchronized(jsw){
outDated = compiler.compile();
if(!jsw.isInstantiated() || outDated) {
if( null ==ctxt.getServletClassName() ) {
<snip>
This is a complex use of double check type
code and is really hard to analyse because references
themselves and what they point to can have
different levels of staleness (according to the JMM).
So it's a turbo double idiom type usage, possibly
incorrect.
I just wanted to bring this to the attention of the
development team and make sure that *someone* has
really analysed this according to the JMM. (and
any other code, similar to this).
Best regards,
javadesigner@yahoo.com
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>