Re: agradou

[paul]

你好

aly chin <[EMAIL PROTECTED]> 
wrote:你好！来信收到，但是无法打开附件。谢谢你，亲爱的朋友！



[EMAIL PROTECTED] wrote:me diz o queacha?


> ATTACHMENT part 2 application/x-zip-compressed name=:(.zip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




秦焕东 13823139100 












































-
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！



-
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！

Re: I want to learn the source code of Tomcat

[paul]

你好

zhang lan <[EMAIL PROTECTED]> wrote:Dear, warm-hearted experts:
I want to learn the source code of Tomcat, but I don't know where I should 
start? Could you give me some directions, such as jsper, catlina...

by the way, I am a Chinese java programmer and I have developed six web 
projects.

Best Regards
Alan(^_^)

_
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com 


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





-
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！

Re: Clustering and Load balancing

[paul]

hello ,I am at China .

Vinayagam <[EMAIL PROTECTED]> wrote:Hi!,

I didn't get understand this language. Can u pls send it as English!

Regards
Vinayagam

- Original Message - 
From: "aly chin" 
To: "Tomcat Developers List" 
Sent: Wednesday, November 10, 2004 10:25 AM
Subject: Re: Clustering and Load balancing


> 你好！来信收到，但是无法打开附件。谢谢你，亲爱的朋友！
>
> Vinayagam wrote:Hi All!
>
> Can any one help me abt clustering and Loadbalancing using Tomcat 
> 5.0/later.
>
> We have an application, Which is run on Tomcat 4.0.
>
> Now we are going to run this application in Tomcat 5.0.
>
> Also we are going to implements the clustering technology to our appl.
>
> So that i need som help, How to do this.
>
> Thanx & Regards
> Vinayagam
>
>
>
>
> 秦焕东 13823139100
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> Do You Yahoo!?
> 150万曲MP3疯狂搜，带您闯入音乐殿堂
> 美女明星应有尽有，搜遍美图、艳图和酷图
> 1G就是1000兆，雅虎电邮自助扩容！ 


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





-
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！

Re: agradou

[paul]

你好,我不认识你.Good luck !

aly chin <[EMAIL PROTECTED]> 
wrote:你好！来信收到，但是无法打开附件。谢谢你，亲爱的朋友！



[EMAIL PROTECTED] wrote:me diz o queacha?


> ATTACHMENT part 2 application/x-zip-compressed name=:(.zip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




秦焕东 13823139100 












































-
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！



-
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！

Possible mod_jk patch with ap_get_server_name

[paul]

Hi,
  I am a new subscriber and have a potential patch to mod_jk.  It uses 
the apache api to get the s->servername value.  This has a benefit in 
that is pays attention to the UseCanonicalName setting within apache.  
So if a site has lots of ServerAlias entries only 1 entry in 
server.xml is needed if UseCanonicalName is on for that VirtualHost.
  The patch was against the jakarta-tomcat-connectors-4.1.12 source I 
downloaded and I have tested it with Apache/1.3.26 and Tomcat 3.2.3 in 
a virtual hosted situation with some vhosts enabled via 
UseCanonicalName and some not.  
  Comments welcome, it seems to work fine.

--- mod_jk.c.orig   Thu Oct 17 18:06:21 2002
+++ mod_jk.cThu Oct 17 18:07:06 2002
@@ -466,7 +466,7 @@
 s->remote_host  = NULL_FOR_EMPTY(s->remote_host);

 s->remote_addr  = NULL_FOR_EMPTY(r->connection->remote_ip);
-s->server_name  = (char *)(r->hostname ? r->hostname : r->server-
>server_hostname);
+s->server_name  = ap_get_server_name(r);

 s->server_port = htons( r->connection->local_addr.sin_port );
 s->server_software = (char *)ap_get_server_version();



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

MEI Whitelist Dequarantine Notice

[paul]

This message has been dequarantined.  Although the system only
presents the first 55 lines here, the original message was sent
to paul intact.

> From [EMAIL PROTECTED]  Wed Aug 27 17:39:19 2003
> Return-Path: <[EMAIL PROTECTED]>
> Received: from apache.org (daedalus.apache.org [208.185.179.12])
>   by mei.net (8.12.9/8.12.9) with SMTP id h7RLdIHL012871
>   for <[EMAIL PROTECTED]>; Wed, 27 Aug 2003 17:39:19 -0400
> Received: (qmail 13893 invoked by uid 500); 27 Aug 2003 21:13:24 -
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> List-Subscribe: <mailto:[EMAIL PROTECTED]>
> List-Help: <mailto:[EMAIL PROTECTED]>
> List-Post: <mailto:[EMAIL PROTECTED]>
> List-Id: "Tomcat Developers List" 
> Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> Received: (qmail 13329 invoked from network); 27 Aug 2003 21:13:13 -
> Received: from unknown (HELO prv-mail20.provo.novell.com) (137.65.81.122)
>   by daedalus.apache.org with SMTP; 27 Aug 2003 21:13:13 -
> Received: from INET-PRV-MTA by prv-mail20.provo.novell.com
>   with Novell_GroupWise; Wed, 27 Aug 2003 15:13:16 -0600
> Message-Id: <[EMAIL PROTECTED]>
> X-Mailer: Novell GroupWise Internet Agent 6.5.1 
> Date: Wed, 27 Aug 2003 15:13:07 -0600
> From: "Jeff Tulley" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: [Patch] Edit field maxlength in admin app's login.jsp
> Mime-Version: 1.0
> Content-Type: multipart/mixed; boundary="=__PartF7A988F3.0__="
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> BCT-delivery-for: paul
> MEI-wl-code: MEI0128841062020359b1bcCKd7kF6nm5U0kIfHig
> 
> --=__PartF7A988F3.0__=
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> The admin application needlessly sets the maximum size of the username
> and password fields to 16 characters.  It is VERY easy to run into a
> problem with some Realm types (like JNDI, if you are using
> fully-qualified LDAP names).  I know a password of 16 characters is a
> bit pathological, but the limit is arbitrary and needless.
> 
> I have attached a simple patch to this to just get rid of the
> maximums.
> 
> I have seen two or three emails complaining about this and ran into
> this myself today.
> 
> Jeff Tulley  ([EMAIL PROTECTED])
> (801)861-5322
> Novell, Inc., The Leading Provider of Net Business Solutions
> http://www.novell.com
> 
> --=__PartF7A988F3.0__=

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

Re: An alternative to JSP

[Paul Speed]

Mel Martinez wrote:
> 
> Without getting into the larger issue, one problem
> that jumped out at me from your article is (at least
> in your examples) the MLS precompile looks at the
> expression inside the digraphs and replaces line
> terminations in the *.j source with linefeed
> characters ('\n').  That presumes the line termination
> character of choice for the output is a linefeed
> character.  It may be a '\n' is fine for most cases,
> but the truth is that it depends on the platform upon
> which the output is to be used.  In generall, it is
> always best to use the line.separator property instead
> or use a PrintWriter's println() method to insert the
> correct line termination.
> 
> Another issue is that the example creates catenated
> String literals.  I would hope that the actual code
> produced would use appropriately initialized
> StringBuffers or performance could be a problem.

Just thought that I would point out that: 
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties.  In the case
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above.  Since I haven't looked at the
code directly, I don't know how or if this affects your point.

-Paul Speed

> 
> Just some thoughts on the implementation.  On the
> larger issue of this thread, I don't really see the
> benefit of something like MLS over JSP, which
> potentially allows you to completely remove all Java
> code from the html (by using jsp tags and taglibs),
> but take that as an imho.
> 
> Dr. Mel Martinez
> Software Architect
> G1440, Inc.
> [EMAIL PROTECTED]
> 
> --- Brad Cox <[EMAIL PROTECTED]> wrote:
> > At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
> > >I agree with most of your discussion of the
> > disadvantages of JSP/ASP/etc,
> > >but I believe your solution does not address a
> > fundamental problem, which
> > >is the complete separation of presentation
> > resources from presentation logic.
> >
> > That is correct. My goal at this point is to get
> > free of JSP so the
> > goal was only to duplicate what JSP does in a way I
> > can live with.
> >
> > >Having the HTML embedded in a java class may be
> > suitable for small
> > >applications
> > >built by engineers but does not address the vast
> > majority of applications
> > >where designers work on HTML using many different
> > HTML editing tools
> > >while developers work on the application logic in
> > Java using various IDEs and
> > >editors.
> >
> > Perhaps I miscommunicated. The private methods that
> > contain the
> > {{html}} need not be private methods in the
> > controller class,
> > although that is the style I demonstrated in the
> > paper and that I use
> > in my own I-do-it-all work.
> >
> > Also there is nothing that requires these view
> > methods to contain
> > hardcoded strings, other than the crude measurements
> > in the
> > Conclusion section that makes me doubt that the
> > space issue is a
> > primary concern. Each method could aim MLS at an
> > html file at runtime
> > (using the doStream() method that it provides for
> > this purpose but
> > which I didn't mention in the article) and let it do
> > the executable
> > inclusion at runtime. But good point; I'll make this
> > explicit in the
> > article.
> >
> > This would also eliminate the need for the outermost
> > enclosing {{...}}, but
> > the executable inclusion brackets would remain. Do
> > you object to my
> > belief that html experts and their tools couldn't be
> > trained to
> > ignore the {{...}} wrappers around the html? I'd be
> > interested in
> > hearing more about this. After all, JSP has the same
> > problem its <%=
> > ... %> executable inclusion syntax.
> >
> 
> __
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

Re: An alternative to JSP

[Paul Speed]

Jon Stevens wrote:
> 
> on 1/25/01 11:42 AM, "Paul Speed" <[EMAIL PROTECTED]> wrote:
> 
> > Just thought that I would point out that:
> > "My " + "dog " + "has " + "fleas." will be compiled as one String:
> > "My dog has fleas." and incurs no runtime penalties.  In the case
> > of literals it can be more efficient than StringBuffer as long as
> > they are grouped together as above.  Since I haven't looked at the
> > code directly, I don't know how or if this affects your point.
> >
> > -Paul Speed
> 
> True, but not in a loop.
> 
> ie:
> 
> String foo = "";
> for ( int i = 0; i< NUMBER; i++ )
> {
>foo = foo + i;
> }
> 
> That will produce a big mess. Best to use a StringBuffer.append in that
> case.

Agreed.  I was just pointing out that there are cases
where String is indeed better than StringBuffer.  Too many 
developers are beaten over the head with the "StringBuffer is
better" rule. :)  I was just adding a little chaos.

-Paul Speed

> 
> -jon
> 
> --
> Honk if you love peace and quiet.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

Re: Enterprise Tomcat

[Paul Libbrecht]

I think you have more chances with JServ...

Paul



On Friday, December 8, 2000, at 07:41 PM, Michael Kuz wrote:

> Hello all,  
>  
> Does anyone know of Corperate (Fortune 500) companies using Tomcat as their 
> enterprise servlet container?  
> Anything like that at all? Links would be great. 
>  
> We (tech types) want to use it, but have to prove mgmt. that it's in use in 
> the big companies. 
>  
> (Our mandate is no unproven technologies) 
> Don't flame me, that's not my definition of proven technology... 
>  
> I've been trying to find _anything_ about Tomcat and enterprise usage and am 
> having no luck. 
>  
> What percentage of core coders on TC are from Sun? (guesses?) I think this 
> would argue my case... 
>  
> Any help is appreciated. 
> Cheers, 
> mk 
>  

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

Re: Thread-safety

[Paul Speed]

Steve Downey wrote:
> 
> That code has also been found to be _not_ thread safe. Much to the surprise
> and dismay of several experts.
> See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> The "Double-Checked Locking is Broken" Declaration
> 
> -Original Message-
> From: Ethan Wallwork [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Thread-safety
> 
> "When the thread exits the synchonized block, it is required to commit all
> its
> changes to main memory"
> 
> Does this mean that the following code would be thread safe?
> 
> if (_jspx_inited == false) {
> synchronized (this) {
> if (_jspx_inited == false) {
> synchronized(new Object()) {_jspx_init();}
> _jspx_inited = true;
> }
> }
> }

BTW, is the _jspx_init() method private and/or final?  
Otherwise, can compilers really get away with inlining virtual 
methods?  Or is this just a Hotspot runtime compilation issue?

-Paul Speed

> 
> The inner synchronized block should ensure that the initialization gets
> commited before _jpsx_inited gets set to true.
> 
> Fun stuff!
> 
> --
> Ethan
> 
> -Original Message-
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 5:03 AM
> To: [EMAIL PROTECTED]
> Cc: Justyna Horwat
> Subject: Re: Thread-safety
> 
> Luc Vanlerberghe <[EMAIL PROTECTED]> wrote:
> 
> > Thanks for incorporating this change to jasper.  I had suggested it a
> > couple of months ago (22/11/2000 in fact: see
> > http://w6.metronet.com/~wjm/tomcat/2000/Nov/msg00747.html)
> >
> > In the meantime, however, I have been browsing through the sessions of
> > the JavaOne conference of 2000 and there's (at least) one session of
> > particular interest: "Correct and Efficient Synchronization of Threads
> > in the Java Programming Environment" (The complete list including links
> > to realAudio recordings is on
> > http://java.sun.com/javaone/javaone00/replay.html)
> > Here's a direct link to the abstract:
> > http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=754
> >
> > One of the points that is made in that session is that even this
> > 'double-check idiom' is NOT thread-safe!
> > The exact reasons for this are not so easy to understand but basically
> > what I understood is that within the synchronized block, writes to main
> > memory can occur in any order, meaning that the value of _jspx_inited
> > can be commited to main memory while some of the results of the
> > initialisation code are still in e.g. processor registers.  When the
> > thread exits the synchonized block, it is required to commit all its
> > changes to main memory, but if another processor checks the value of
> > _jspx_inited *before* acquiring the lock, it may see _jspx_inited being
> > true while not all other initialisation data has actually been written
> > to main memory.
> > For more details, please follow the links above...
> 
> GOTCHA! I was looking at your post with Justy this afternoon and didn't
> understand why it's not "threadsafe"... What she committed (without the ugly
> writer.println() stuff is:
> 
> if (_jspx_inited == false) {
> synchronized (this) {
> if (_jspx_inited == false) {
> _jspx_init();
> _jspx_inited = true;
> }
> }
> }
> 
> So, if the commit of the _jspx_inited value can occour while _jspx_init() is
> still in progress (let's imagine some weird code optimization techniques),
> to fix this bug, we should simply remove the first line of the commit and
> simply write:
> 
> synchronized (this) {
> if (_jspx_inited == false) {
> _jspx_init();
> _jspx_inited = true;
> }
> }
> 
> So that, no matter what happens, a thread must ALWAYS acquire a lock on the
> synchronized piece of code, and so we are guaranteed that _jspx_init() is
> called at least once all the time...
> 
> Yep, makes sense...
> 
> Pier
> 
> --
> Pier Fumagalli <mailto:[EMAIL PROTECTED]>
> I'm selling my Sony Vaio Z505. Check out <http://www.betaversion.org/~pier/>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional comman

Re: Thread-safety

[Paul Speed]

Marc Saegesser wrote:
> 
> This is a truly fascinating thread of discussion.  However, from reading the
> article _The "Double-Checked Locking is Broken" Declaration_
> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
> 
> It seems to me that the following code is thread safe.
> 
> if (_jspx_inited == false) {
> synchronized (this) {
> if (_jspx_inited == false) {
> _jspx_init();
> _jspx_inited = true;
> }
> }
> }
> 
> The case described in the article is the following
> 
> class Foo {
>   private Helper helper = null;
>   public Helper getHelper() {
> if (helper == null)
>   synchronized(this) {
> if (helper == null)
>   helper = new Helper();
>   }
> return helper;
> }
>   // other functions and members...
>   }
> }
> 
> The problem is that helper may be assigned a value before the Helper
> constructor executes.  Thus another thread may come along and notice a
> non-null value for helper and attempt to use un-initialized values.
> 
> In the _jspx_inited case above the only requirement is that compiler can't
> rewrite the code into the equivalent of
> 
> if (_jspx_inited == false) {
> synchronized (this) {
> if (_jspx_inited == false) {
> _jspx_inited = true;
> _jspx_init();
> }
> }
> }
> 
> Such a re-ordering seems illegal to me (what if jspx_init() uses the value
> of _jspx_inited?).  If, however, it is legal reordering then the example of
> a "correct" double-check mechanism for 32-bit primitive values should work
> here.  It would look something like
> 
> boolean tmpInited = _jspx_inited;
> if (tmpInited == false) {
> synchronized (this) {
> if (tmpInited == false) {
> tmpInited = _jspx_init();  // NOTE:  _jspx_init() needs to
> return true
> _jspx_inited = tmpInited;
> }
> }
> }

The issue as I understand it is that the constructor might
have been inlined and then the inlined instructions may have been
re-ordered.  If _jspx_init() can be inlined then it might exhibit
the same problem.  My question is what the spec says about inlining
virtual methods... I'm pretty sure that _jspx_init() is only a 
candidate for inlining through runtime compilation by Hotspot.  But
I'm not even sure of that.

Otherwise, if it can never be inlined then your original 
assertion is correct.
-Paul Speed

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

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

Re: Thread-safety

[Paul Speed]

Marc Saegesser wrote:
> 
> OK, if _jspx_init() can be inlined and the _jspx_inited=true assignment
> might get interspersed within the inlined code (the fog is lifting now) then
> the second approach I presented where the result of _jspx_init() is used
> should work.

Not really... for the same reason that a constructor has 
problems.  The code that returns the true value would get inlined as
a variable assignment... and could possibly be moved somewhere higher
based on dependencies.

I wonder how likely it is that _jspx_init() will be inlined.
-Paul

> 
> > -Original Message-
> > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 26, 2001 2:12 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> >
> >
> >
> >
> > Marc Saegesser wrote:
> > >
> > > This is a truly fascinating thread of discussion.  However,
> > from reading the
> > > article _The "Double-Checked Locking is Broken" Declaration_
> > > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
> > >
> > > It seems to me that the following code is thread safe.
> > >
> > > if (_jspx_inited == false) {
> > > synchronized (this) {
> > > if (_jspx_inited == false) {
> > > _jspx_init();
> > > _jspx_inited = true;
> > > }
> > > }
> > > }
> > >
> > > The case described in the article is the following
> > >
> > > class Foo {
> > >   private Helper helper = null;
> > >   public Helper getHelper() {
> > > if (helper == null)
> > >   synchronized(this) {
> > > if (helper == null)
> > >   helper = new Helper();
> > >   }
> > > return helper;
> > > }
> > >   // other functions and members...
> > >   }
> > > }
> > >
> > > The problem is that helper may be assigned a value before the Helper
> > > constructor executes.  Thus another thread may come along and notice a
> > > non-null value for helper and attempt to use un-initialized values.
> > >
> > > In the _jspx_inited case above the only requirement is that
> > compiler can't
> > > rewrite the code into the equivalent of
> > >
> > > if (_jspx_inited == false) {
> > > synchronized (this) {
> > > if (_jspx_inited == false) {
> > > _jspx_inited = true;
> > > _jspx_init();
> > > }
> > > }
> > > }
> > >
> > > Such a re-ordering seems illegal to me (what if jspx_init()
> > uses the value
> > > of _jspx_inited?).  If, however, it is legal reordering then
> > the example of
> > > a "correct" double-check mechanism for 32-bit primitive values
> > should work
> > > here.  It would look something like
> > >
> > > boolean tmpInited = _jspx_inited;
> > > if (tmpInited == false) {
> > > synchronized (this) {
> > > if (tmpInited == false) {
> > > tmpInited = _jspx_init();  // NOTE:  _jspx_init() needs to
> > > return true
> > > _jspx_inited = tmpInited;
> > > }
> > > }
> > > }
> >
> >   The issue as I understand it is that the constructor might
> > have been inlined and then the inlined instructions may have been
> > re-ordered.  If _jspx_init() can be inlined then it might exhibit
> > the same problem.  My question is what the spec says about inlining
> > virtual methods... I'm pretty sure that _jspx_init() is only a
> > candidate for inlining through runtime compilation by Hotspot.  But
> > I'm not even sure of that.
> >
> >   Otherwise, if it can never be inlined then your original
> > assertion is correct.
> >   -Paul Speed
> >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

Re: Thread-safety

[Paul Speed]

"Klemme, Robert, myview" wrote:
> 
> hi all!
> 
> > -Original Message-
> > From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 26, 2001 6:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> >
> >
> > > Does this mean that the following code would be thread safe?
> > NO, it's not!
> 
> sorry to intervene here.  i think you are wrong.  look at it again:
> 
> > [...]
> > > Does this mean that the following code would be thread safe?
> > >
> > > if (_jspx_inited == false) {
> > > synchronized (this) {
> > > if (_jspx_inited == false) {
> > > synchronized(new Object()) {_jspx_init();}
> > > _jspx_inited = true;
> > > }
> > > }
> > > }
> 
> this double check is a usual technique to improve performance.  the inner
> check is necessary for proper operation.  the outer check improves
> performance since it does not require a lock on the object to be acquired
> which is relatively costly.

The problem is that the point of the code block is to be
sure that the _jspx_init() method has been completed before 
proceeding.  The problem is that _jspx_inited might appear to other
threads to be set to true before the original thread has completed
executing the _jspx_init() method (or at least before its changes
are available to other threads).

This means that the second thread would come through, see
that _jspx_inited is true, and skip the synchronization block.  That
threads execution would then proceed thinking that everything has
been initialized when it hasn't.

> 
> and, btw. why did they not code this:
> 
> if ( ! _jspx_inited ) {
> synchronized (this) {
> if ( ! _jspx_inited ) {
> // other initialization stuff
> _jspx_inited = true;
> }
> }
> }
> 
> i think it is quite superfluous to compare a boolean with true or false
> (apart from the fact that in other programming languages this might even be
> dangerous, just think of C...)
> 

Check out the article that is referenced in other mail in
this thread or hit JavaWorld and see the references section on the
article about singletons.

-Paul Speed

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

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Paul Speed]

Glenn Nielsen wrote:
> 
> "Craig R. McClanahan" wrote:
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > When Jasper is run in a servlet
> > >   container it no longer puts the class files in a package, they are now
> > >   in the default package.
> > >
> >
> > As was discussed earlier on TOMCAT-DEV, this is going to cause
> > portability problems for people who use beans that are not in packages.
> > With this
> > change, such beans will work in Tomcat but not when the app is moved to
> > a different container that *does* put JSP-generated servlets into a
> > package.
> >
> > The previous behavior (Jasper-generated servlets go into a package)
> > avoided this, because it essentially disallowed non-packaged beans.
> > Therefore, I prefer it.
> >
> > (Also, I seem to remember a discussion on the expert group for JSP 1.2
> > that non-packaged beans and generarted classes should be disallowed, but
> > I have not yet located any reference to this in the 1.2 spec.)
> >
> 
> If you check the code for JasperLoader you will find that it requires
> all classes to be in a package, the only class that does not have to
> be in a package is the JSP page itself.
> 
> Regards,
> 
> Glenn
> 

So, you can't load unpackaged classes from a JSP page?
Even if they are specifically imported?

-Paul Speed

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

Re: [report] Classloading problems between Catalina and Cocoon

[Paul Speed]

Tom Reilly wrote:
> 
> +1
> 
> There's no reason going from .java to a Class object should be any
> harder than going from .class to a Class object.  If the compiler used
> ClassLoader's instead of manually reading .class files in through the
> file system, fast in-memory compilation becomes a possibility (and
> your runtime classpath becomes the same as your compiler classpath).

Possibly.  The thing is that loading classes through a 
ClassLoader has an extreme amount of overhead.  When the compiler
accesses the class, all of its static initializers would be run.
None of this stuff is necessary for basic compilation.  Reading
the .class files as resources (I'm pretty sure) has the same 
problem.  At least, we were never able to resolve the problem when
attempting to do something similar, but things have changed a lot
since then.  Loading .class files as resources might work now.

-Paul

> 
> That said, I think javac is never going to be this compiler, at least
> not any time soon.  They just re-wrote it and I doubt they'll do it
> again.  A more mobile open source project like KJC is probably more
> realistic.
> 
> "Pier P. Fumagalli" <[EMAIL PROTECTED]> writes:
> 
> > James Duncan Davidson <[EMAIL PROTECTED]> wrote:
> >
> > > on 2/15/01 10:12 AM, Stefano Mazzocchi at [EMAIL PROTECTED] wrote:
> > >
> > >> today's java compilation technology stinks!
> > >
> > > Or rather, the method of accessing today's Java compiler stinks.
> >
> > Nono, the whole technology stinks. To include Java classes JAVAC doesn't
> > rely on the classloader, but on single File objects, and that causes
> > problems when compiling stuff like JSP...
> >
> > >> Pier and I started talking about a JSR for Java Compilation API months
> > >> ago and I even wrote a JSR-ignition document but the 'javac' team sucked
> > >> it, well, I don't know anything about it.
> > >
> > > I'll check up on this.
> >
> > We were talking with Bill Maddox, and apparently, he left Sun for Transmeta
> > without saying anything. That's why the whole discussion went down the
> > drain. Just a FYI..
> >
> > Pier
> 
> --
> Tom Reilly
> Allaire Corp.
> http://www.allaire.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

Re: 'Just say no to JSP'

[Paul Speed]

Paulo Gaspar wrote:
> 
> Earl,
> 
> If you think one should not discuss the merits of JSP here, you should
> not take part on it even if to defend JSP.
> 
> If you agree we should talk about the pros and cons of JSPs, it is hard
> to talk about the cons of JSP in a constructive way without pointing
> alternatives. Can one just say it is bad without pointing alternatives
> and still give worthy input?
> 
> Or do you just want to talk about the pros?
> =;o)
> 
> Clearly, there are some problems with JSPs. Supporting a clear
> separation between logic (scripting) and presentation (templating) is
> not easy to enforce with JSPs. And this is a discussion going on in
> many forums.
> 
> Now, JSPs are nice for scripting stuff (when you want to code and see
> the result with no compiling/restarts). I even thought of using JSPs
> for the scripting with Velocity for templating!!! And this is not such
> new idea since there are people using JSPs with XSLT for the same
> purposes.
> 
> But XSLT just makes things too hard. Too much cost for not enough
> profit. I just converted a XSLT based application to Velocity and I
> sure know what I am talking about.
> 
> Maybe JSPs just need something extra for the templating side. Maybe
> JSPs can learn that from Velocity/WebMacro template engines.
> 
> And this list is one of the best spots to talk about this. The right
> people read this. * Isn't Tomcat the reference JSP implementation? *

Is is.  But the tomcat team doesn't set the spec, it just
implements it.

-Paul

> 
> Have fun,
> Paulo Gaspar
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 06, 2001 18:48
> >
> > Why has the tomcat-dev list become a Velocity advocacy list??
> > Isn't the purpose of this list supposed to be for communation between
> > Tomcat developers?  Is velocity recruiting or something?
> >
> > =eas=

Re: JSP re-compile performance under heavy load

[Paul Speed]

Just a thought,

But might you not also just save your query results in some 
intermediate format (serialization might work) that your JSP pages
could then use?  It may not fit in well with your system, but it would
save from having to recompile pages.

At the other end of the spectrum, you could generate the HTML instead
of JSP and also save the intermediate step.

A large amount of JSP compilation overhead is out of tomcat's hands
since it's reliant on the java compiler.

-Paul

[EMAIL PROTECTED] wrote:
> 
> Hi All,
> 
> I'm curious if any of you have code that tests the performance of JSP
> recompiles while tomcat is under load.  I've read that some changes were
> made in this area recently, and it directly effects a design I'm
> considering.
> 
> If performance testing code exists, could someone send it to me?
> 
>   Thanks,
> 
>   Jason Henriksen
> 
> P.S.:  (If you're curious how I got into this sitation, here's the
> rationale: )
> 
> Basically, I'm treating the disk drive as a cache.  I expect to have well
> over 5,000 different query result pages, each of which could take over a
> minute to generate because they require some fairly thick SQL.  The good
> news is that only about 100 of them will be 'active' at any given time.
> The non-active pages, can be built, saved on disk and then safely ignored
> (Thus being served with no database hit). However, when the object in the
> DB changes I should be able to show the update on the JSP page within 15
> minutines of the database change occuring.
> 
> My plan is to generate a page for each of my 5,000 objects up front and
> then wait until a DB object changes.  When it does, I'll regenerate the
> page for just that object.  That way everyone see's the new static page,
> and the database can continue doing it's regular job of managing user
> accounts, and other such non-cacheable business.  (The disk cache is also
> preferable to holding the results for all 5000 object queries in memory
> because the results will be fairly large.  My disk space is near infinite,
> but my memory is not).
> 
> So if I have 1000 people looking at the results for Object A when it needs
> to be re-compiled how will Tomcat respond?  I know it does fine job
> handling updated JSPs in a development environment, I'm curious how it's
> expected to perform doing that kind of operation under load.  (I understand
> that my mileage my vary, I'm just looking for what you guys would expect to
> happen, or do you suggest some other desgin?)  Thus, I'm look for test-code
> and/or result numbers.
> 
> --
> Warning : The information contained in this message may be privileged and 
>confidential and protected from disclosure. If the reader of this message is not the 
>intended recipient, you are hereby notified that any dissemination, distribution or 
>copying of this communication is strictly prohibited. If you have received this 
>communication in error, please notify us immediately by replying to this message and 
>then delete it from your computer. All e-mail sent to this address will be received 
>by the Providian Financial corporate e-mail system and is subject to archiving and 
>review by someone other than the recipient.
> 
> ==

[PATCH] jk_lb_worker patch

[Paul Frieden]

Attached is a patch for the lb worker for mod_jk.  Basically, it changes
the selection behavior slightly and adds some error and debugging
logging where we would find it useful.

The code uses two variables, lb_factor, and lb_value.  lb_factor is the
numerical inverse (1/x) of what is entered into the workers.properties
file.  This causes the lb_factor to become very large if the lb_factor
in workers.properties is 0.  lb_value always starts at 0.

The decision of which worker is used is based on lb_value.  The worker
with the lowest lb_value gets selected to service a request.  After a
worker is used, its lb_value is incremented by lb_factor. 
Unfortunately, this causes the balancer to service at least one request
on each worker before the lb_factor actually has any effect.  This one
request will often lead to an entire session being served off of a
different worker.

This behavior isn't really a problem, but in a scenario where you have
an external load balancer, it is preferable to try to honor its
decisions except where there is an error.  Such an error can happen with
providers that use IP randomizing proxies such as AOL.  Its also nice to
be more deterministic in the normal case.

This patch seeds the lb_value with 1/lb_factor.  This changes the
behavior by causing lb_value to be larger for servers with lower weights
than servers with higher weights.  If the lb_factor in
workers.properties is 0, it becomes very large and should only be
selected in the case of all the regular workers being unavailable or due
to a session route.

I added error logging for if the worker specified by the session route
is unavailable.  I added debug logging for selecting a worker by session
route, and for which worker is selected.

This hasn't been tested much, but its almost a trivial change.  This is
against 3.2.1, but it should apply clean to later versions as well. 
Feedback is welcome.

Paul

--- /tmp/jakarta-tomcat-3.2.1-src/src/native/jk/jk_lb_worker.c  Tue Dec 12 16:51:56 
2000
+++ ../jk/jk_lb_worker.cMon May  7 16:23:20 2001
@@ -244,7 +244,8 @@
 }
 
 static worker_record_t *get_most_suitable_worker(lb_worker_t *p, 
- jk_ws_service_t *s)
+ jk_ws_service_t *s,
+jk_logger_t *l)
 {
 worker_record_t *rc = NULL;
 double lb_min = 0.0;
@@ -255,8 +256,14 @@
 for(i = 0 ; i < p->num_of_workers ; i++) {
 if(0 == strcmp(session_route, p->lb_workers[i].name)) {
 if(p->lb_workers[i].in_error_state) {
-   break;
+   jk_log(l, JK_LOG_ERROR,
+   "In get_most_suitable_worker, requested worker (%s) 
+unavailable, redirecting session\n",
+   p->lb_workers[i].name);
+   break;
 } else {
+   jk_log(l, JK_LOG_DEBUG,
+   "In get_most_suitable_worker, selected %s because of 
+session_route\n",
+   p->lb_workers[i].name);
 return &(p->lb_workers[i]);
 }
 }
@@ -282,13 +289,13 @@
 lb_min = p->lb_workers[i].lb_value;
 rc = &(p->lb_workers[i]);
 }
-}
+}
 }
 
 if(rc) {
 rc->lb_value += rc->lb_factor;
+   jk_log(l, JK_LOG_DEBUG, "In get_most_suitable_worker, selected %s\n", 
+rc->name);
 }
-
 return rc;
 }
 
@@ -309,7 +316,7 @@
 
 
 while(1) {
-worker_record_t *rec = get_most_suitable_worker(p->worker, s);
+worker_record_t *rec = get_most_suitable_worker(p->worker, s, l);
 int rc;
 
 if(rec) {
@@ -347,7 +354,7 @@
  * Error is not recoverable - break with an error.
  */
 jk_log(l, JK_LOG_ERROR, 
-   "In jk_endpoint_t::service, none recoverable error...\n");
+   "In jk_endpoint_t::service, non recoverable error...\n");
 break;
 }
 
@@ -426,7 +433,7 @@
 p->lb_workers[i].lb_factor = jk_get_lb_factor(props, 
worker_names[i]);
 p->lb_workers[i].lb_factor = 1/p->lb_workers[i].lb_factor;
-p->lb_workers[i].lb_value = 0.0;
+p->lb_workers[i].lb_value = p->lb_workers[i].lb_factor;
 p->lb_workers[i].in_error_state = JK_FALSE;
 p->lb_workers[i].in_recovering  = JK_FALSE;
 if(!wc_create_worker(p->lb_workers[i].name, 

Need LoadFile librt.so with mod_jk 2.0.4, Solaris, apache1.3

[Paul Rasmussen]

Hi,

I just built jk 2.0.4.  It seems to work fine in our system (with rudimentary 
testing), but one issue I had that should maybe be added to the documentation 
is that I had to do a "LoadFile /usr/lib/librt.so" to get it to run.  This is 
with Solaris 8 & apache 1.3.  Unless someone thinks this means I did something 
wrong that is...

- paul r.


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

Re: Spam vulnerability at apache

[Paul Speed]

Everyone on the list received these e-mails since they were sent to
the list.  No harvesting was necessary.
As I understand it, the apache mailing lists are promiscuous in a way
and will easily/accidentally let any e-mail address subscribe as long
as it sends a reply to a subscribe confirmation e-mail.
This means script kiddies or whoever can simply pretend to be
[EMAIL PROTECTED] and subscribe to the mailing list.  Since these
kinds of support e-mails get auto-responded and because most sysadmins
can't seem to be bothered to ignore e-mails of type "bulk", these
support addresses get subscribed and can then auto-reply to every
message.
The list moderators are pretty quick about removing the offending
addresses, but it doesn't stop a few e-mails from sneaking through.  The
really painful part is how often this is happening lately.  Some people
seem to have way to much time on their hands and an abnormal sense of
humor.
Just a lurker's two cents.
-Paul
Reshat Sabiq wrote:

Hi,

I extremely apologize for this message, but i think this needs to be 
figured out. I just yesterday registered my new email address with 
tomcat-dev, and i received the spam below almost immediately thereafter. 
Only a few people are aware of this email address, so the origin of spam 
info 99% appears to be tomcat-dev registration. Is there any chance that 
DNS gets resolved to one of several IPs, one of which collects these 
emails and uses them for spam (or perhaps is infected with a virus)? I 
would look for any IPs based in russia as the prime suspects, because 
this email contains russian text and appears to be originated there.

What's worse is that 25 minutes after this spam, i received another one 
of similar content. Please help save me and others from this plague of 
the Internet.
I entrusted apache.org with this address, and hope we can keep it 
between us.

P.S. If there are other people who received similar emails, please let 
me, the admins, or the list know. If you let only me know, i will 
accumulate the number of people affected and forward this to an admin.
P.P.S. I see that emails are protected in the archives publicly 
published, and i think this issue is in the same category.

Thanks,

[EMAIL PROTECTED] wrote:

russian(win-1251):

Приветствуем!

Данное уведомление автоматически создано в ответ на Ваше письмо на тему
"Photo document", приведенное ниже. Вам не надо отвечать на него.
Служба поддержки клиентов получила Ваше письмо, и ему присвоен 
идентификатор
[TID#4977]. Пожалуйста, включайте следующий блок:

 [TID#4977]

в заголовок (subject) всей последующей корреспонденции на эту тему. 
Это можно сделать отвечая на это письмо (reply).

C уважением,
служба технической поддержки клиентов
Хостинг оператор М-10
http://www.m-10.ru

english:
Greetings,

This message has been automatically generated in response to your message
regarding "Photo document", the content of which appears below.  There
is no need to reply to it now. Support has received your message and 
it has
been assigned a ticket ID of [TID#4977]. Please include the string:

 [TID#4977]

in the subject line of all future correspondence about this problem. 
To do so, you may reply to this message.

WBR,
Support Team
Hosting Operator M-10 http://www.m-10.ru
Original Message-
Please, photo document.
Yours sincerely
+++ X-Attachment-Type: document
+++ X-Attachment-Status: no virus found
+++ Powered by the new F-Secure OnlineAntiVirus
+++ Visit us: www.f-secure.com


-Headers Follow--
Received: from [EMAIL PROTECTED]
 by office.m-10.ru (CommuniGate Pro GROUP 4.1.8)
 with GROUP id 1745058; Mon, 12 Apr 2004 17:13:05 +0400
Received: from [62.5.188.222] (HELO office.m-10.ru)
 by office.m-10.ru (CommuniGate Pro SMTP 4.1.8)
 with ESMTP id 1745042 for [EMAIL PROTECTED]; Mon, 12 Apr 
2004 17:12:58 +0400
X-Antivirus: Checked by Dr.Web (http://www.drweb.net)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Photo document
Date: Mon, 12 Apr 2004 17:11:48 +0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_NextPart_000_0016=_NextPart_000_0016"
X-Priority: 3
X-Msmail-Priority: Normal
Message-Id: <[EMAIL PROTECTED]>

-
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: Spam vulnerability at apache

[Paul Speed]

I think this is a combination of a misconfigured mail server at
one800.net and a bad e-mail address subscribed to the list.  The mail
server is badly configured because it replied to sender instead of the
reply-to address.  If it had replied to the reply-to address you would
never have seen it and the mailing list software would likely have
disabled the address.
It's probably also a recent thing.
-Paul
Reshat Sabiq wrote:

I'm sorry to report that sending the message below, caused the following 
to show up in my mail box. There is definitely something fishy with the 
apache mail servers. This does not happen when i send an email to a 
non-apache address. Please, let's fix this:

Your Mail has been bounced from the OutPost/1.800eMail Server
Because "[EMAIL PROTECTED]" is not a valid username
Original message, less any attachments, follows:


...
Reshat Sabiq wrote:

Hi,

I extremely apologize for this message, but i think this needs to be 
figured out. I just yesterday registered my new email address with 
tomcat-dev, and i received the spam below almost immediately 
thereafter. Only a few people are aware of this email address, so the 
origin of spam info 99% appears to be tomcat-dev registration. Is 
there any chance that DNS gets resolved to one of several IPs, one of 
which collects these emails and uses them for spam (or perhaps is 
infected with a virus)? I would look for any IPs based in russia as 
the prime suspects, because this email contains russian text and 
appears to be originated there.

What's worse is that 25 minutes after this spam, i received another 
one of similar content. Please help save me and others from this 
plague of the Internet.
I entrusted apache.org with this address, and hope we can keep it 
between us.

P.S. If there are other people who received similar emails, please let 
me, the admins, or the list know. If you let only me know, i will 
accumulate the number of people affected and forward this to an admin.
P.P.S. I see that emails are protected in the archives publicly 
published, and i think this issue is in the same category.

Thanks,

[EMAIL PROTECTED] wrote:

russian(win-1251):

Приветствуем!

Данное уведомление автоматически создано в ответ на Ваше письмо на тему
"Photo document", приведенное ниже. Вам не надо отвечать на него.
Служба поддержки клиентов получила Ваше письмо, и ему присвоен 
идентификатор
[TID#4977]. Пожалуйста, включайте следующий блок:

 [TID#4977]

в заголовок (subject) всей последующей корреспонденции на эту тему. 
Это можно сделать отвечая на это письмо (reply).

C уважением,
служба технической поддержки клиентов
Хостинг оператор М-10
http://www.m-10.ru

english:
Greetings,

This message has been automatically generated in response to your 
message
regarding "Photo document", the content of which appears below.  There
is no need to reply to it now. Support has received your message and 
it has
been assigned a ticket ID of [TID#4977]. Please include the string:

 [TID#4977]

in the subject line of all future correspondence about this problem. 
To do so, you may reply to this message.

WBR,
Support Team
Hosting Operator M-10 http://www.m-10.ru
Original 
Message-

Please, photo document.
Yours sincerely
+++ X-Attachment-Type: document
+++ X-Attachment-Status: no virus found
+++ Powered by the new F-Secure OnlineAntiVirus
+++ Visit us: www.f-secure.com


-Headers 
Follow--
Received: from [EMAIL PROTECTED]
 by office.m-10.ru (CommuniGate Pro GROUP 4.1.8)
 with GROUP id 1745058; Mon, 12 Apr 2004 17:13:05 +0400
Received: from [62.5.188.222] (HELO office.m-10.ru)
 by office.m-10.ru (CommuniGate Pro SMTP 4.1.8)
 with ESMTP id 1745042 for [EMAIL PROTECTED]; Mon, 12 Apr 
2004 17:12:58 +0400
X-Antivirus: Checked by Dr.Web (http://www.drweb.net)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Photo document
Date: Mon, 12 Apr 2004 17:11:48 +0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_NextPart_000_0016=_NextPart_000_0016"
X-Priority: 3
X-Msmail-Priority: Normal
Message-Id: <[EMAIL PROTECTED]>

-
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: WYSIWYG Portal/Weblog Server based on Jakarta/Tomcat

[Paul Mansfield]

>From: Bernhard Fastenrath [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, April 08, 2004 11:39 AM
> >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >Subject: WYSIWYG Portal/Weblog Server based on Jakarta/Tomcat
> >
> >
> >I'd like to write a WYSIWYG Portal/Weblog Server based on
> Jakarta/Tomcat.

On Thu, 2004-04-08 at 16:53, Shapira, Yoav wrote:
> Hi,
> Well, there's Jetspeed (http://jakarta.apache.org/jetspeed/site/) which
> is a nice portal implementation running on top of tomcat.


jetspeed is a resource monster. don't even think about develop for it on
anything less than a 1.5GHz CPU with 512MB memory, preferably a 3GHz P4
with 1GB memory or more!

Paul


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

RE: WYSIWYG Portal/Weblog Server based on Jakarta/Tomcat

[Paul Mansfield]

On Tue, 2004-04-13 at 14:31, Shapira, Yoav wrote:
> >jetspeed is a resource monster. don't even think about develop for it
> on
> >anything less than a 1.5GHz CPU with 512MB memory, preferably a 3GHz P4
> >with 1GB memory or more!
> 
> Good to know.  You should contact its developers with suggestions for
> improvement.  The mailing list links are here among other places:
> http://jakarta.apache.org/jetspeed/site/faq.html.

he he, I was active on the jetspeed mailing lists for a while, and it's
a known "feature". 

Jetspeed also "leaks" processes and memory badly when reloading the
app... our dual 4GHz Zeon box with 2GB of RAM would run out of memory
every half hour with just two developers, requiring full tomcat restart
which takes quite a while.

we simply turned out jetspeed portlets into JSPs and back-end classes,
and can now turn pages round in less than 200ms, as opposed to more than
a second with jetspeed.

Paul


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

Like to play chess? Never have time?

[Paul Rowe]

Then sign up for e-mail chess!  This is an application
built on JBoss/Tomcat technology that lets you play
chess when you want to.  Check out http://www.paulrowe.com/game.cgi";>http://www.paulrowe.com/game.cgi

Sincerely, paulrowe.com




__
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

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

Re: Hin Kan Lee/Prymnewey is out of the office.

[Paul Speed]

And give his auto-responder admin a big wedgie too.
-Paul
Mladen Turk wrote:
Can someone kill this guy? 


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

Re: tomcat build broken with strange javac error(never seen this one before)

[Joshua Paul]

Stop sending me e-mail.
- Original Message - 
From: "Hiller, Dean D (Dean)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 12, 2004 3:00 PM
Subject: tomcat build broken with strange javac error(never seen this one
before)


I have never seen an error from javac like this before(and I am by no
means new to java).  I have even read the JLS and am not sure what in
the world this is.  Can anyone point me somewhere on how to resolve this
issue?  Or possibly point me to a build.xml for tomcat5 that works?  The
one on the website does not work as I get the below.  I am using
1.4.2_05.  Does the build.xml file work for anyone else?  If so, what
version of java are you using?





build-catalina-core:

[javac] Compiling 302 source files to
C:\ROOT\views\jakartaviews\tomcatTry\jakarta-tomcat-5\build\classes

[javac]
C:\ROOT\views\jakartaviews\tomcatTry\jakarta-tomcat-catalina\catalina\sr
c\share\org\apache\catalina\Container.java:23: cannot access
javax.servlet.ServletException

[javac] bad class file:
C:\usr\share\java\servlet-api-2.4\lib\servlet-api.jar(javax/servlet/Serv
letException.class)

[javac] class file has wrong version 49.0, should be 48.0

[javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.

[javac] import javax.servlet.ServletException;

[javac]  ^

[javac] 1 error



Also, I really want to know more about this error and how it is
possible.  Does anyone know what this means?  Ps.  Am I on the wrong
list?  Is this really a problem with the servlet api jar?, but which
project is that and who do I talk to???

thanks,

dean




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

Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config context.xml

[Paul Speed]

To configure space tabs on Emacs... quoted from:
http://www.student.northpark.edu/pemente/emacs_tabs.htm
> For this session, force Emacs to indent with spaces, never with TABs:
>
> M-x set-variable indent-tabs-mode nil
>
> Permanently force Emacs to indent with spaces, never with TABs:
>
> (setq-default indent-tabs-mode nil);   # put this in your .emacs file
Or, to just one spot convert tabs to spaces for a given selection:
M-x untabify
I don't have an emacs up and running at the moment so can't verify, but 
it sounds right from what I remember.  As I recall, untabify requires 
selecting the contents of the buffer first.

-Paul
Shapira, Yoav wrote:
Hi,
I'm actually working in emacs over PuTTY due to some weird network/firewall 
(mis)configuration issues here at work, so it's a pain for me to fix the tabs at this 
time ;(
Yoav Shapira
Millennium Research Informatics

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 31, 2004 10:53 AM
To: Tomcat Developers List
Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config
context.xml
[EMAIL PROTECTED] wrote:

yoavs   2004/08/31 07:50:41
Modified:catalina/src/share/org/apache/catalina/core Tag: TOMCAT_5_0
  StandardContext.java
 webapps/docs Tag: TOMCAT_5_0 changelog.xml
 webapps/docs/config Tag: TOMCAT_5_0 context.xml
Log:
Added StandardContext processTlds attribute, added context configuration
references docs for processTlds, tldValidation, tldNamespaceAware.

I can feel two more commits are coming in shortly ;)
Can you fix the tabs at the same time ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


This e-mail, including any attachments, is a confidential business communication, 
and may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi ExpressionParseTree.java ExpressionTokenizer.java SSIConditional.java SSIConditionalState.java ByteArrayServletOutputStream.java ResponseIncludeWrapper.java SSICommand.java SSIConfig.java SSIEcho.java SSIExec.java SSIExternalResolver.java SSIFlastmod.java SSIFsize.java SSIInclude.java SSIMediator.java SSIPrintenv.java SSIProcessor.java SSIServlet.java SSIServletExternalResolver.java SSIServletRequestUtil.java SSISet.java SSIStopProcessingException.java

[Paul Speed]

Yay!  My code is back. :)
-Paul
[EMAIL PROTECTED] wrote:
funkman 2004/09/01 11:33:34
  Modified:catalina/src/share/org/apache/catalina Globals.java
   catalina/src/share/org/apache/catalina/ssi
ByteArrayServletOutputStream.java
ResponseIncludeWrapper.java SSICommand.java
SSIConfig.java SSIEcho.java SSIExec.java
SSIExternalResolver.java SSIFlastmod.java
SSIFsize.java SSIInclude.java SSIMediator.java
SSIPrintenv.java SSIProcessor.java SSIServlet.java
SSIServletExternalResolver.java
SSIServletRequestUtil.java SSISet.java
SSIStopProcessingException.java
  Added:   catalina/src/share/org/apache/catalina/ssi
ExpressionParseTree.java ExpressionTokenizer.java
SSIConditional.java SSIConditionalState.java
  Log:
  Backport from 4.1 the ssi if else logic
  
  Revision  ChangesPath
  1.11  +12 -1 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Globals.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Globals.java.diff?r1=1.10&r2=1.11
  
  
  1.5   +23 -21jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ByteArrayServletOutputStream.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ByteArrayServletOutputStream.java.diff?r1=1.4&r2=1.5
  
  
  1.5   +57 -57jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ResponseIncludeWrapper.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ResponseIncludeWrapper.java.diff?r1=1.4&r2=1.5
  
  
  1.4   +29 -28jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSICommand.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSICommand.java.diff?r1=1.3&r2=1.4
  
  
  1.4   +34 -40jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java.diff?r1=1.3&r2=1.4
  
  
  1.3   +44 -53jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIEcho.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIEcho.java.diff?r1=1.2&r2=1.3
  
  
  1.4   +49 -55jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExec.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExec.java.diff?r1=1.3&r2=1.4
  
  
  1.4   +46 -39jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExternalResolver.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExternalResolver.java.diff?r1=1.3&r2=1.4
  
  
  1.4   +47 -52jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFlastmod.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFlastmod.java.diff?r1=1.3&r2=1.4
  
  
  1.3   +76 -82jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFsize.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFsize.java.diff?r1=1.2&r2=1.3
  
  
  1.4   +39 -45jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIInclude.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIInclude.java.diff?r1=1.3&r2=1.4
  
  
  1.4   +258 -176  jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIMediator.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIMediator.java.diff?r1=1.3&r2=1.4
  
  
  1.3   +36 -43jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIPrintenv.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIPrintenv.java.diff?r1=1.2&r2=1.3
  
  
  1.4   +224 -193  jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIProcessor.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIProcessor.java.diff?r1=1.3&r2=1.4
  
  
  1.8   +87 -99jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java.diff?r1=1.7&r2=1.8
  
  
  1.4   +379 -356  jakarta-tomcat-catalina/catalina/src/share/org/a

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler SmapUtil.java

[Paul Speed]

Amy Roh wrote:
[EMAIL PROTECTED] wrote:
amyroh  2004/09/20 10:51:28
 Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
 Log:
 Remove verbose.
 -if (verbose) {
 -if (log.isDebugEnabled())
 -log.debug("constant pool count: " + 
constantPoolCount);
 -}
 +log("constant pool count: " + constantPoolCount);

You need to keep if (log.isDebugEnabled()), otherwise, zillions of 
Strings will be created for no reason (as the parameter of your method 
will have to be created).

I have added the following log helper method so I don't have to do if 
(log.isDebugEnabled()) everytime I use log.debug()

 +
 +private static void log(String msg) {
 +if (log.isDebugEnabled())
 +log.debug(msg);
 +}
 +
  }
Amy
>>>  +log("constant pool count: " + constantPoolCount);
But even to call your log() method, a String will need to be created 
that combines the "constant pool count:" with a 
String.valueOf(constantPoolCount).  Even if it's just going to be thrown 
away.
-Paul

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

Re: Configure Teradata data source connection

[Paul Speed]

http://jakarta.apache.org/site/mail.html
See the first bulleted section.
-Paul
Prabhjot Sodhi wrote:
Hi:
I am new to Java and this forum, so my apologies for asking novice 
queries (but u have to start one day)!!!

I am working on creating a database management site using JSDK and 
Apache Tomcat server on my WinXp laptop.

I have got a dummy test file using an applet to connect to the 
Teradata database. But it is failing in dearth of proper drivers.

Can you please guide me set up the Teradata drivers information in 
the conf files, etc so that the applet can sonnect to the RDBMS and submit 
the query?

Thanks in advance!!! Hoping for an early response.
Thanks & Regards,
Pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Configure Teradata data source connection

[Paul Speed]

Prabhjot Sodhi wrote:
Yep it says...
The "User" lists where you can send questions and comments about 
configuration, setup, usage and other "user" types of questions. 

I wish to know about the server configuration. 
So send it to the user's list.  Since that's where "configuration" would 
be discussed.

This is the developer list, where people discuss bugs and other internal 
tomcatty goodness.

-Paul
Thanks & Regards,
Pete
Senior System Analyst,
IBM Global Services,
202 Coward Street, Mascot.
Ph (O) : +61 2 9691 3589
mail-id: [EMAIL PROTECTED]
**
This communication may contain CONFIDENTIAL or copyright information of 
IBM Australia Limited, (ABN 79 000 024 733). If you are not an intended 
recipient, you MUST NOT keep, forward, copy, use, save or rely on this 
communication, and any such action is unauthorised and prohibited. If you 
have received this communication in error, please reply to this e-mail to 
notify the sender of its incorrect delivery, and then delete both it and 
your reply. Thank you.
**


Paul Speed <[EMAIL PROTECTED]> 
22/09/2004 02:15 PM
Please respond to
"Tomcat Developers List"

To
Tomcat Developers List <[EMAIL PROTECTED]>
cc
Subject
Re: Configure Teradata data source connection


http://jakarta.apache.org/site/mail.html
See the first bulleted section.
-Paul
Prabhjot Sodhi wrote:

Hi:
   I am new to Java and this forum, so my apologies for asking 
novice 

queries (but u have to start one day)!!!
   I am working on creating a database management site using JSDK 
and 

Apache Tomcat server on my WinXp laptop.
   I have got a dummy test file using an applet to connect to the 
Teradata database. But it is failing in dearth of proper drivers.

   Can you please guide me set up the Teradata drivers information 
in 

the conf files, etc so that the applet can sonnect to the RDBMS and 
submit 

the query?
   Thanks in advance!!! Hoping for an early response.
Thanks & Regards,
Pete

-
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]

[Off-Topic] Re: java.io.tempdir Problems

[Paul Speed]

It sounds like maybe there is some confusion between environment 
variables and system properties.

java.io.tempdir is a system property which presumably means it can be 
set on the Java command line using -Djava.io.tempdir="foo"

This is different then anything getenv() would return since those would 
be environment variables.  Some of which are reflected as differently 
named system properties.  For example, I think java.io.tempdir defaults 
to the TEMP environment variable under Windows and perhaps TMP under 
Unix or something like that.  I'd have to drill into javadocs to be sure.

-Paul
Michael McGrady wrote:
I don't know if this is helpful or not, Martin, but if you attempt 
System.getenv("java.io.tempdir") [which is deprecated], you get as part 
of the error message
"getenv no longer supported, use properties and -D instead: 
java.io.tempdir".  Is that helpful?  Does the -D there mean as in 
-Djava.io.tempdir?

Michael
Martin Gainty wrote:
Good Afternoon Michael
Perusing the Manual for Jspc at
http://64.233.167.104/search?q=cache:pfbfEPvvvHUJ:www.gefionsoftware.com/Lit 

eWebServer/lws-jsp/ReferenceManual.pdf+TOMCAT+java.io.tempDir+-Djava.io.temp 

Dir&hl=en
formal syntax for the JSPC command
jspc [options] -webapp web-app-root-dir
Where option
-d output-dir specifies
The -d output-dir specification is the directory specified by the
java.io.tempdir system property
I see that there are 2 ways to specify java.io.tempdir System Property
Anyone else
The directory specified by the java.io.tempdirsystem property The 
directory
specified by the java.io.tempdirsystem property The directory 
specified by
the java.io.tempdirsystem property The directory specified by the
java.io.tempdir???
Martin
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 11:46 AM
Subject: Re: java.io.tempdir Problems

 

Martin,
Perhaps I should add, Martin, that if I set the environment variables
for java.io.tempdir and -Djava.io.tempdir in the application but not in
Tomcat startup, I don't have the problem.  I am a bit confused about
whether to use java.io.tempdir or -Djava.io.tempdir.  Can you explain a
bit about that?
Michael McGrady
Martin Gainty wrote:
  

Michael
createTempFile employs 3 steps algorithm to locate/create "tempDir"
1) Attempt to retrieve the value of "javax.servlet.context.tempdir" 
from

the
 

 ServletContext
2) If that's not found, attempt to retrieve the value of the

init-parameter
 

 "tempDir"
3) If that's not found, default to the system-wide temp directory

specified
 

 by the system property "java.io.tempdir"
A)what is the value of "javax.servlet.context.tempdir" from the
ServletContext?
B)what is the value of the init-parameter   "tempDir"?
Martin-
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 3:16 AM
Subject: java.io.tempdir Problems



I hope this is Tomcat related.  If not, please accept my apologies, 
and
give me direction.  I have removed from my Tomcat 5 (Struts 1.2 
using a
custom taglib) service the java.io.tempdir setting because when I use
the following code:

   File file = new File(Classpath.WEB_INF +
   "resource"+ File.separator +
   "content_type"+ File.separator +
   "ttf" + File.separator +
physicalName);
   FileInputStream fontStream = new FileInputStream(file);
   Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream);
   font = font.deriveFont(attributes);
   fontStream.close();
I get temp files of around 50 - 150 kilobytes each written to the temp
directory.  I requested assistance on Tomcat User without an answer.
Anyway, I assume that there may be a concurrency issue of 
somekind.  Is
that right?  Anyone with any assistance out there?

Michael McGrady
-
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]



  

-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Embedded use : How to programmatically add a servlet instance.

[Paul Hammant]

I've been looking at Embedded, Context, StandardContext, Wrapper and 
StandardWrapper and want a way participating in the instantiation of a 
servlet.  i.e. ...

  context = embedded.createContext("fooContext");
  context.addServlet("barServlet", myServlet);
I know there are mechanisms for adding a servlet by classname, but it 
seems logical to allow adding my instance if TC5 is allowed to be 
embedded at all.  Is this feasable? Is there appetite for it?

Regards,
- Paul
--
ThoughtWorks - recruiting Java/.Net OSS* Architects/Developers worldwide
Speak to the ThoughtWorker(s) you know best/longest about ThoughtWorks..
* Also recruiting non-OSS developers, PMs, BAs, Agilists, Testers

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

communication from jsp to valve

[Paul Moore]

I have a valve that does various valve type things, mess with requests,
twiddle cookies, etc.
I need a JSP to be able to communicate with the valve (generate URLS
based on the result of some of the twiddling for example).
The class loaders are doing their best to stonewall me. I have tried
putting my TwiddlyValveInterface instance in
A) thread locals - get null out (different ThreadLocal class with
different static map?)
B) appContext attribute - class cast error (clear sign that I loaded
through different loaders)
What is the recommended way to do this?


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

RE: communication from jsp to valve

[Paul Moore]

I will reply to myself since I have worked out the solution and other
might find it useful 

Valve itself must go in /server
Supporting code for valve and classes exposed to the jsp must go in
/common 

-Original Message-
From: Paul Moore [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 11, 2005 1:32 PM
To: tomcat-dev@jakarta.apache.org
Subject: communication from jsp to valve


I have a valve that does various valve type things, mess with requests,
twiddle cookies, etc.
I need a JSP to be able to communicate with the valve (generate URLS
based on the result of some of the twiddling for example).
The class loaders are doing their best to stonewall me. I have tried
putting my TwiddlyValveInterface instance in
A) thread locals - get null out (different ThreadLocal class with
different static map?)
B) appContext attribute - class cast error (clear sign that I loaded
through different loaders) What is the recommended way to do this?


-
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]

data push

[Paul Wallace]

Hi All,

I would like server A (TC 5.5) to 'push' streams of data to server B (TC
5.5) at random points in time, and for server B to accept the data when it
is received. This is not using request / response, hence I am new to this
topic. A couple of questions - what protocol(s) can be used, HTTP? How does
one push data, than than have it requested? Can anyone point me towards a
resource of this nature please? I understand sockets are in the picture -
also new to me.

Thanks

Paul. 

Paul Wallace BSc Hons.
IPTV Specialist
Two Way TV Australia
Level 3, City West Centre
55 Pyrmont Bridge Road
Pyrmont
Sydney, NSW 2009
Australia
 
Tel   +61 2 9017 7000 
Fax  +61 2 9017 7001
Mb   +61 422 538 465
Skype  wallacpaul
 

Input stream

[Paul Wallace]

Hi All,
I have a socket receiving streams of XML. I receive an InputStream,
but short of a dirty hack, do not know when (or how) I pass the
stream/contents to be parsed. Any thoughts/resources on parsing streaming
XML please? 

Thanks

Paul.

RE: Input stream

[Paul Wallace]

Hi & thanks,
Parsing a file would not normally be a problem, but as it is a
stream, there is no EOF and when I parse the stream into:

DocumentBuilder db =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
db.parse(in);

I get: 

org.xml.sax.SAXParseException: The processing instruction target matching
"[xX][mM][lL]" is not allowed.

What I have read on this message means invalid XML. And if there were no EOF
that would be expected? I have tried parsing the simplest of XML files. This
is my dirty hack - I can delimit the 'packet' with some obscure character
while populating say a StringBuffer, write it to File, and re-parse it (I
did say it was dirty;). A packet is the contents of a complete XML file
which are sent randomly. 

So my problem is not the parsing, but capturing the fragment of an
inputstream that will parse as valid XML.

All input appreciated

rgds

Paul.

You can use different things, but directly programming you can use SAX2,
XMLReader, and XMLReaderFactory.createXMLReadersee JDK javax.xml package
documentation.  You could use a DOM object, but I wouldn't recommend it
because of memory usage. 
You can change the underlying XML parser impls for your JDK as well.

Hope it helps,

Wade

--- Chris Lamprecht <[EMAIL PROTECTED]> wrote:

> See XmlPull:
> 
> http://www.xmlpull.org/
> 
> On 8/15/05, Paul Wallace <[EMAIL PROTECTED]>
> wrote:
> > Hi All,
> >I have a socket receiving streams of XML. I
> receive an InputStream,
> > but short of a dirty hack, do not know when (or
> how) I pass the
> > stream/contents to be parsed. Any
> thoughts/resources on parsing streaming
> > XML please?
> > 
> > Thanks
> > 
> > Paul.
> > 
> >
> 
>
-
> 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]

io.File relative path constructor

[Paul Wallace]

 
Hi,
A should-be easy one - I do not wish to define an absolute path
to a File as it will packaged in a JAR, therefore its path will change.
How do I construct a File relative to my src root, something like File
file = new File("/path/myFile.xml");? I tried passing in a URL, URI but
am getting:

Exception in thread "main" java.lang.IllegalArgumentException: URI is
not hierarchical

when I jar and run it. Am using Win XP + Java 1.5.

Thanks

Paul.

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

PreparedStatement & Unicode & MySQL

[Paul Wallace]

Hi,
I am having trouble inserting and retrieving Asian characters in my
MySQL DB using PreparedStatement. I have set up my table thus:
 
CREATE TABLE `messages` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `message_body` text NOT NULL,
  `sender_number` text NOT NULL,
  `shortcode` text NOT NULL,
  `image` longblob,
  PRIMARY KEY  (`id`)
) CHARACTER SET utf8 TYPE=MyISAM; 
 
and am inserting using a PreparedStatement -
pstmt.setString(indexOfColumnInQuestion, asianTextString); to insert in
to message_body. However, when viewing the column in the query browser,
and retrieving it from a ResultSet, it reads ? ???  and
so on (I am attempting to insert Thai characters in this instance).
 
Is there a method of PreparedStatement I am missing?
 
thanks and regards
 
Paul.

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

The Apache Jakarta Tomcat 5 Servlet/JSP Container - MBean Descriptor How To

[Paul Diedericks]

  Hi.   There is just one link that I've found that is incorrect.   The "print-friendly version" link on http://jakarta.apache.org/tomcat/tomcat-5.0-doc/mbeans-descriptor-howto.html should point to http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/mbeans-descriptor-howto.html.  Currently the link goes to /mbean-descriptor-howto.html... (the 's' is missing).   Regards,   Paul Diedericks MagmaTec (Pty) Ltd    e : [EMAIL PROTECTED]tel   : +27 (0)21 670 7926 fax   : +27 (0)21 683 9789 cell  : +27 (0)82 705 1429 www : www.magmatec.co.za       

smime.p7s
Description: S/MIME cryptographic signature

TC4 - Avalon Wrapper.

[Paul Hammant]

Hi Folks,

I have written a wrapper for Catalina that allows it to be deployed as a 
"sar" file into Apache's Avalon/Phoenix server application framework. 
 To some it seems unecessary, but Phoenix can serve multiple server 
applications from one JVM.  Currently these could include :
JAMES (the mail / news server) plus it's DNS server,
FtpServer (new Apache micro-project that's part of Avalon),
HypersonicSQL (waiting in the wings until the HSQLDB team at Sourceforge 
commit some changes).
A SOAP server - publish any API as WSDL (courtesy of Glue, until Axis is 
finished).
Jesktop (my desktop layer)
Acme.Serve (another http server)
HTTP Proxy server (part of Avalon as a demo)

Soon we hope to be followed by an EJB container...

Anyway,  I am here to list some compromises I had to make when I wrap 
Catalina and launch it inside the context of Avalon/Phoenix.  I've 
simulated the processing of "catalina.sh embedded" which launches the 
org.apache.catalina.startup.Embedded class.  All bar the shutdown part 
of main() has been used as inspiration for the wrapper logic.  Problems :

1) Env vars "catalina.home" and "catalina.base" suck (sorry).  It 
basically means that there can't be more than one instace of catalina 
running in the same VM.  Yes, ordinarily that would be undesirable, but 
we don't place such restrictions on other apps (bind-to-port issues 
considered).  Is there anyway that CatalinaHome could be an object that 
it passed into Embedded's constructor?  It then passed around to all 
that needs it.

2) Primordial classloader.  Some components like StandardEngine assume 
they must be loaded from the primordial classloader.  That's not the 
case for the wrapped Catalina.  It's my feeling that that type of thing 
contributes to Catalina not being able to find servlet classes (that are 
definately visible to the launched catalina).  To overcome the issue I 
had to put servlet.jar in Phoenix's lib directory.  That kinda sucks as 
the "sar" is no longer drag and drop installable.  I'd hope that was 
easy to fix, but it's a bit of a black hole for me to pinpoint the 
actual line of code that's wrong.

3) Connection handling.  We're proud to say that the connection manager 
in Phoenix is stolen from Catalina.  We'd like to be able to use that 
connection manager to listen on ports and pass sockets to the innards of 
Catalina.  In so doing it does it's own threadpooling.  Would it be 
possible for us to be inspired by your HttpConnector and have a 
connector that implements Connector and have one that takes Sockets 
handed from our ConnectionManager?

Lastly congrats on TC4, it's in all other senses a really excellent bit 
of coding.  Quality work.

Regards,

- Paul H

Re: TC4 - Avalon Wrapper.

[Paul Hammant]

our HttpConnector and have a
>>connector that implements Connector and have one that takes Sockets
>>handed from our ConnectionManager?
>>
>
>Conceptually, this seems pretty doable -- you could subclass the existing
>classes (so as to reuse most of the protocol processing) but change how
>the connections are grabbed, and how they are communicated to the
>corresponding processor.
>
I've looked at subclassing HttpConnector, it feels wrong to extend 
something that want's to use Thread and then deliberatly not use Thread. 
 Possible but wrong.  I think the best plan would be to create an 
intermediate class below HttpConnector called, say, HttpBase and have 
that extended by the non threaded, non socket server delegate for avalon 
too.

Noted that this is not now.  4.01 or 4.1 as mentioned before.

>Remy is also working on a design for a higher performance HTTP/1.1
>connector.  I saw that he just posted some initial work, in the "coyote"
>directory of the "jakarta-tomcat-connectors" repository.  It would be
>useful to get you plugged in to the development effort to make sure that
>the abstractions you would need will be there.
>
I'll take the hint and dive in that connection pool.

Regards,

- Paul H

Re: DO NOT REPLY [Bug 4339] - Cannot use "//" comments in JSP code

[Paul Speed]

Only partially related to the bug, so I'm replying directly instead
of through bugzilla...

Does this mean that JSP uses a different Java language specification?
If so, where can I find this separate specification?  Are there any
other big things like this that are incompatible with normal Java 
syntax?

Thanks,
-Paul Speed

[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=4339>.
> 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=4339
> 
> Cannot use "//" comments in JSP code
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution||WONTFIX
> 
> --- Additional Comments From [EMAIL PROTECTED]  2001-10-22 10:11 ---
> You should not be using "//" comments.  You have absolutely no control over the
> Java code that is generated for your page, so it is your responsibility to use
> well-formed constructs.  In this particular case, that means to use /* */ style
> comment markers so that you can explicitly close them.  Even if we changed
> Tomcat to do what you suggest, depending on this would not be portable and you'd
> have massive problems as soon as you tried to switch to some other container
> that didn't do it.
> 
> Using scriptlets at all can lead you into lots of other problems (such as
> intermixing business logic and presentation logic that makes it very hard to
> maintain and enhance your applications), but that is a whole separate
> discussion.

Re: DO NOT REPLY [Bug 4339] - Cannot use "//" comments in JSP code

[Paul Speed]

Ah,

Sorry.  _That_ makes perfect sense.

It's what I get for not reading the original bug report in more 
detail.

Although, I would expect in the following case...

> When you do something like this:
> 
>   <% System.out.println(); // Hello %> Some template text
> 
> then this gets translated into
> 
>   System.out.println();  // Hello Some template text

To instead get:

System.out.println(); // Hello 
out.print( "Some template text" );

Since "Some template text" is clearly outside of the <% %>, wouldln't
it be turned into generated output instead of code?  Or am I being
pedantic and what you really meant was:

System.out.println(); // Hello out.print( "Some template text" );

or somesuch?

-Paul Speed

"Craig R. McClanahan" wrote:
> 
> On Mon, 22 Oct 2001, Paul Speed wrote:
> 
> > Date: Mon, 22 Oct 2001 13:48:08 -0400
> > From: Paul Speed <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: DO NOT REPLY [Bug 4339]  - Cannot use "//" comments in JSP
> > code
> >
> > Only partially related to the bug, so I'm replying directly instead
> > of through bugzilla...
> >
> > Does this mean that JSP uses a different Java language specification?
> > If so, where can I find this separate specification?  Are there any
> > other big things like this that are incompatible with normal Java
> > syntax?
> >
> 
> The JSP specification does not mandate the use of Java as a scripting
> language -- you can use any language you want (as specified by the
> "language" attribute of the <%@ page %> directive).  However, many of the
> features related to scripting are defined *only* for Java.
> 
> Note also that Jasper (the JSP page compiler in Tomcat) only supports Java
> as a scripting language at the moment.
> 
> However, more germane to this bug report:
> 
> * Scriptlets are required to be well-formed according to the
>   rules of the scripting language in use (JSP 1.2, Section 2.11.2).
>   Thus, if you mistakenly leave off a semicolon at the end of a
>   Java statement in a scriptlet, the compilation error you get is
>   your fault.  It's also your fault if the scope of your language
>   element extends outside the closing "%>" delimiter in a manner
>   that causes invalid code to be created (such as mismatching "}"
>   brackets), or the case described in the following point.
> 
> * Scriptlets are translated into the generated code according
>   to the following rule (JSP 1.2, Section 6.4.2):
> 
> <% scriptlet %> -->scriptlet
> 
>   In other words, no newline is added after the "%>" by the page
>   compiler (though the developer could certainly put a newline there).
> 
> When you do something like this:
> 
>   <% System.out.println(); // Hello %> Some template text
> 
> then this gets translated into
> 
>   System.out.println();  // Hello Some template text
> 
> and you get what you pay for.  If you want to use // comments, do this
> instead:
> 
>   <% System.out.println(); // Hello
>   %> Some template text
> 
> and it will work fine.
> 
> > Thanks,
> > -Paul Speed
> >
> 
> Craig
> 
> > [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=4339>.
> > > 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=4339
> > >
> > > Cannot use "//" comments in JSP code
> > >
> > > [EMAIL PROTECTED] changed:
> > >
> > >What|Removed |Added
> > > 
> > >  Status|NEW |RESOLVED
> > >  Resolution||WONTFIX
> > >
> > > --- Additional Comments From [EMAIL PROTECTED]  2001-10-22 10:11 
>---
> > > You should not be using "//" comments.  You have absolutely no control over the
> > > Java code that is generated for your page, so it is your responsibility to use
> > > well-formed constructs.  In this particular case, that means to use /* */ style
> > > comment markers so that you can explicitly close them.  Even if we changed
> > > Tomcat to do what you suggest, depending on this would not be portable and you'd
> > > have massive problems as soon as you tried to switch to some other container
> > > that didn't do it.
> > >
> > > Using scriptlets at all can lead you into lots of other problems (such as
> > > intermixing business logic and presentation logic that makes it very hard to
> > > maintain and enhance your applications), but that is a whole separate
> > > discussion.
> >

Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files

[Paul Speed]

On a vaguely related note...

For the curious reader, after looking into this code at some length
it seems clear why the set command was not added.  All SSI requests
share the same environment, which not only makes a set command 
impossible but also means that multiple SSI requests (or even nested
SSI requests) trample all over each other.  A simple shtml file that
includes two other shtml files illustrates this quite nicely.

Since I'm between assignments at the moment, I'm working on a patch
here locally.  It's pretty significant, though, so it may take me a 
few days.  It will include the set command though since that's what
I'm going to use to test it. :)

If noone else beats me to it, I'll post it when I'm done.
-Paul Speed

[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=4361>.
> 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=4361
> 
> SsiServlet potentially leaks files
> 
> --- Additional Comments From [EMAIL PROTECTED]  2001-10-23 12:39 ---
> I can't recreate the error here but I did happen to notice something as I was
> browsing through the code.  Each SsiInvokerServlet request causes it to open the
> requested file as a Resource.  The InputStream that is obtained from this
> Resource is never closed.  I tried to poke around in the Resource classes to see
> if some magic was closing the stream but couldn't find anything.
> 
> I can attach a patch if needed, but the change is pretty simple.  Just a
> try/finally with a close().

Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files

[Paul Speed]

Bip Thelin wrote:
> 
> > -Original Message-
> > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> >
> > For the curious reader, after looking into this code at some length
> > it seems clear why the set command was not added.  All SSI requests
> > share the same environment, which not only makes a set command
> > impossible but also means that multiple SSI requests (or even nested
> > SSI requests) trample all over each other.  A simple shtml file that
> > includes two other shtml files illustrates this quite nicely.
> 
> Do you have a smal testcase? We have unittests with Tomcat that have
> nested includes and several includes in one page. All Ssi directives
> share the same enviroment per page through a mediator, this is due to
> the fact that you can have a config directive that changes the error
> message that you would get for a failed include further down on the same
> page, for instance.

Actually, SsiInvokerServlet has a static reference to SsiMediator.
Furthermore, all of SsiMediators fields are static.  

A simple test case that I use is a .shtml page that includes the same 
.shtml page twice.  Only the first one will actually be included 
because of the way the Request object in SsiMediator is overwritten.

> 
> However if pageA includes pageB, if pageB is also an shtml/ssi file it
> would have a new fresh enviroment and could not tamper with pageA's
> enviroment.
> 
> So you could easily do a set command simmilar to the config command.

Actually, includes should share the environment of the parent...
in fact, if they set server variables the parent will see them.

> 
> > Since I'm between assignments at the moment, I'm working on a patch
> > here locally.  It's pretty significant, though, so it may take me a
> > few days.  It will include the set command though since that's what
> > I'm going to use to test it. :)
> 
> Patches and additions are gladly appreciated.

Cool.  I'm almost done refactoring.  I'm basically replacing the
SsiMediator with an SsiEnvironment that is then stuck into a
request attribute.  In the process, I'm moving some things around 
a little since all of the commands were relying on the fact that 
they were SsiMediator subclasses... and therefore directly accessing 
the static fields of SsiMediator.

Hopefully I'll have something done in the morning.  Even more 
hopeful, it will be worth committing. ;)  We'll see...
-Paul Speed

Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files

[Paul Speed]

I couldn't find alot of info on testing.  I also couldn't find any
tests that included multiple files... so I may be looking in the wrong
place.  I eventually found and played with the tester stuff.

Attached are the files I added to the tester to exploit the include
problem.  SSIInclude09.shtml simply includes another .shtml file 
twice.

Here is the section I added to tester.xml to get the test to run.


I now have this working on my system here.  It currently passes all 
of the tester tests in addition to about 7 more tests that I added 
myself here locally.  I also added the initial support for the "set" 
directive and variable substitution.  I have one more command to get 
working and then some clean-up and I'll see about posting the diffs.  

Actually, while I'm on that subject, the diffs are extensive since
I've pretty much touched every SSI related file in a very significant
way... in addition to removing a few of them.  What is the preferred
way to submit such a large patch?

Thanks,
-Paul Speed

Bip Thelin wrote:
> 
> > -Original Message-
> > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> >
> > For the curious reader, after looking into this code at some length
> > it seems clear why the set command was not added.  All SSI requests
> > share the same environment, which not only makes a set command
> > impossible but also means that multiple SSI requests (or even nested
> > SSI requests) trample all over each other.  A simple shtml file that
> > includes two other shtml files illustrates this quite nicely.
> 
> Do you have a smal testcase? We have unittests with Tomcat that have
> nested includes and several includes in one page. All Ssi directives
> share the same enviroment per page through a mediator, this is due to
> the fact that you can have a config directive that changes the error
> message that you would get for a failed include further down on the same
> page, for instance.
> 
> However if pageA includes pageB, if pageB is also an shtml/ssi file it
> would have a new fresh enviroment and could not tamper with pageA's
> enviroment.
> 
> So you could easily do a set command simmilar to the config command.
> 
> > Since I'm between assignments at the moment, I'm working on a patch
> > here locally.  It's pretty significant, though, so it may take me a
> > few days.  It will include the set command though since that's what
> > I'm going to use to test it. :)
> 
> Patches and additions are gladly appreciated.
> 
> Bip Thelin

This is Content of "includeme.shtml"

This is Content of "includeme.shtml"

Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files

[Paul Speed]

Ok, I'm going to try again with the attachments.  Seems like only
the SSIInclude03.txt file came through before.

-Paul Speed

Paul Speed wrote:
> 
> I couldn't find alot of info on testing.  I also couldn't find any
> tests that included multiple files... so I may be looking in the wrong
> place.  I eventually found and played with the tester stuff.
> 
> Attached are the files I added to the tester to exploit the include
> problem.  SSIInclude09.shtml simply includes another .shtml file
> twice.
> 
> Here is the section I added to tester.xml to get the test to run.
>   request="${context.path}/SSIInclude09.shtml" debug="${debug}"
>   golden="${golden.path}/SSIInclude03.txt"/>
> 
> I now have this working on my system here.  It currently passes all
> of the tester tests in addition to about 7 more tests that I added
> myself here locally.  I also added the initial support for the "set"
> directive and variable substitution.  I have one more command to get
> working and then some clean-up and I'll see about posting the diffs.
> 
> Actually, while I'm on that subject, the diffs are extensive since
> I've pretty much touched every SSI related file in a very significant
> way... in addition to removing a few of them.  What is the preferred
> way to submit such a large patch?
> 
> Thanks,
> -Paul Speed
> 
> Bip Thelin wrote:
> >
> > > -Original Message-
> > > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> > >
> > > For the curious reader, after looking into this code at some length
> > > it seems clear why the set command was not added.  All SSI requests
> > > share the same environment, which not only makes a set command
> > > impossible but also means that multiple SSI requests (or even nested
> > > SSI requests) trample all over each other.  A simple shtml file that
> > > includes two other shtml files illustrates this quite nicely.
> >
> > Do you have a smal testcase? We have unittests with Tomcat that have
> > nested includes and several includes in one page. All Ssi directives
> > share the same enviroment per page through a mediator, this is due to
> > the fact that you can have a config directive that changes the error
> > message that you would get for a failed include further down on the same
> > page, for instance.
> >
> > However if pageA includes pageB, if pageB is also an shtml/ssi file it
> > would have a new fresh enviroment and could not tamper with pageA's
> > enviroment.
> >
> > So you could easily do a set command simmilar to the config command.
> >
> > > Since I'm between assignments at the moment, I'm working on a patch
> > > here locally.  It's pretty significant, though, so it may take me a
> > > few days.  It will include the set command though since that's what
> > > I'm going to use to test it. :)
> >
> > Patches and additions are gladly appreciated.
> >
> > Bip Thelin
> 
>   
> This is Content of "includeme.shtml"
> 
> This is Content of "includeme.shtml"

Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml

[Paul Speed]

Craig,

It looks like this might be due to Bip committing a set of patches
that I sent him.  So I might be able to help figure out why it's 
broken.  What exactly does it complain about?

Thanks.
-Paul Speed

[EMAIL PROTECTED] wrote:
> 
> craigmcc01/10/26 17:50:05
> 
>   Modified:catalina build.xml
>   Log:
>   Add a kludge to avoid compiling the SSI servlet (and associated utilities)
>   because the build is currently broken, and I haven't seen the commit
>   message yet (due to the mail delay) in order to properly revert it.
> 
>   Once the compile problems are fixed, simply uncomment the 
>   setting for compile.ssi, or include a setting like this in
>   build.properties:
> 
> compile.ssi=true
> 
>   Revision  ChangesPath
>   1.81  +8 -0  jakarta-tomcat-4.0/catalina/build.xml
> 
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
>   retrieving revision 1.80
>   retrieving revision 1.81
>   diff -u -r1.80 -r1.81
>   --- build.xml 2001/10/26 02:03:28 1.80
>   +++ build.xml 2001/10/27 00:50:05 1.81
>   @@ -233,6 +233,9 @@
>
>  
>
>   +
>
>  
>
>   @@ -417,6 +420,7 @@
>
>
>
>   +
>
> 
>
>   @@ -568,6 +572,10 @@
>   unless="compile.jmx"/>
> unless="compile.jsse"/>
>   + +   unless="compile.ssi"/>
>   + +   unless="compile.ssi"/>
> unless="compile.jsse"/>
>   
> 
>

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

Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml

[Paul Speed]

Ahah!

This is an easy one to fix.  I just checked out the latest source and
it looks like Bip may have forgotten to "cvs remove" SsiMediator.java.
That's easy to do when you're updating a whole directory.  Nuke this
file and everything should be good.

Let me know if you have any more problems.
-Paul Speed

[EMAIL PROTECTED] wrote:
> 
> craigmcc01/10/26 17:50:05
> 
>   Modified:catalina build.xml
>   Log:
>   Add a kludge to avoid compiling the SSI servlet (and associated utilities)
>   because the build is currently broken, and I haven't seen the commit
>   message yet (due to the mail delay) in order to properly revert it.
> 
>   Once the compile problems are fixed, simply uncomment the 
>   setting for compile.ssi, or include a setting like this in
>   build.properties:
> 
> compile.ssi=true
> 
>   Revision  ChangesPath
>   1.81  +8 -0  jakarta-tomcat-4.0/catalina/build.xml
> 
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
>   retrieving revision 1.80
>   retrieving revision 1.81
>   diff -u -r1.80 -r1.81
>   --- build.xml 2001/10/26 02:03:28 1.80
>   +++ build.xml 2001/10/27 00:50:05 1.81
>   @@ -233,6 +233,9 @@
>
>  
>
>   +
>
>  
>
>   @@ -417,6 +420,7 @@
>
>
>
>   +
>
> 
>
>   @@ -568,6 +572,10 @@
>   unless="compile.jmx"/>
> unless="compile.jsse"/>
>   + +   unless="compile.ssi"/>
>   + +   unless="compile.ssi"/>
> unless="compile.jsse"/>
>   
> 
>

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

Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml

[Paul Speed]

And for what it's worth...

Here is a piece of the e-mail I sent to Bip... just in case anyone
is curious what I changed.  (I sent the e-mail to him directly since
tomcat-dev was on 14 hour delay at that time and he said he was 
going to be out of contact for a while.)

> The patches fix one major issue and include several enhancements.
> 
> The main fix is that concurrent access to the SSI module was broken
> before and would most readily manifest itself as broken nesting.
> But the same problem would occur if two clients hit the server at
> the same time.  One would see the other's output.
> 
> As far as enhancements, I've added support for the "set" directive
> and variable substitution. (i.e.: $someVar and ${someVar} are now 
> allowed in the appropriate places.)  The initial support for 
> conditionals has also been added.  I just need to make the 
> SsiCommands for "if", "else", etc..

So, with the above changes, SSI should be safe to use from multiple
clients.  Locally, I've also finished coding the conditional 
directives and some other fixes to SsiInvokerServlet.  I'll post 
those changes later today just in case someone wants to use or commit 
them.

-Paul Speed

Paul Speed wrote:
> 
> Ahah!
> 
> This is an easy one to fix.  I just checked out the latest source and
> it looks like Bip may have forgotten to "cvs remove" SsiMediator.java.
> That's easy to do when you're updating a whole directory.  Nuke this
> file and everything should be good.
> 
> Let me know if you have any more problems.
> -Paul Speed
> 
> [EMAIL PROTECTED] wrote:
> >
> > craigmcc01/10/26 17:50:05
> >
> >   Modified:catalina build.xml
> >   Log:
> >   Add a kludge to avoid compiling the SSI servlet (and associated utilities)
> >   because the build is currently broken, and I haven't seen the commit
> >   message yet (due to the mail delay) in order to properly revert it.
> >
> >   Once the compile problems are fixed, simply uncomment the 
> >   setting for compile.ssi, or include a setting like this in
> >   build.properties:
> >
> > compile.ssi=true
> >
> >   Revision  ChangesPath
> >   1.81  +8 -0  jakarta-tomcat-4.0/catalina/build.xml
> >
> >   Index: build.xml
> >   ===
> >   RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
> >   retrieving revision 1.80
> >   retrieving revision 1.81
> >   diff -u -r1.80 -r1.81
> >   --- build.xml 2001/10/26 02:03:28 1.80
> >   +++ build.xml 2001/10/27 00:50:05 1.81
> >   @@ -233,6 +233,9 @@
> >
> >  
> >
> >   +
> >
> >  
> >
> >   @@ -417,6 +420,7 @@
> >
> >
> >
> >   +
> >
> >
> >
> >   @@ -568,6 +572,10 @@
> >   unless="compile.jmx"/>
> >   >   unless="compile.jsse"/>
> >   +   >   +   unless="compile.ssi"/>
> >   +   >   +   unless="compile.ssi"/>
> >   >   unless="compile.jsse"/>
> >   >
> >
> >
> 
> --
> To unsubscribe, e-mail:  <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[PATCH] SSI support

[Paul Speed]

Hello,

I realize Bip is away, but I thought I'd post these anyway before I
forget about them.  Since I've had problems with multiple attachments
I went ahead and stuck the files on my web site at:

http://www.progeeks.com/pspeed/tomcat/SSIPatches.html

Each file has a description of what it contains and where it should
go.  If a committer chooses to apply them and has problems then let
me know.

Here is the description of the changes from the above-linked page:

>
> What I did...
> 
> The changes to SsiInvokerServlet should be independent of the other 
> changes. Really, I just improved parsing support to handle escaped
> characters, etc. and be more error-compatible with Apache.
>
> The other SSI commands were modified to be more compatible with 
> Apache SSI. Specifically, I've verified that the supported tags
> should work the same as mod_include in Apache 1.3.22. At least they
> support the same options. The tags were also enhanced to fit with the
> new conditional tags.
>
> I also added the implementation of the conditional tags: "if", 
> "elif", "else", and "endif". This includes an expression parser. 
> It's been a while since I've written a parser and I tried to do it
> with a slant on understandability. There's probably room for
> improvement, but it works the same as Apache on all of the tests
> I've tried... and it passed all of the new tester pages which
> generate identical output to Apache 1.3.22.
>
> So after these patches, the only tags that are missing that
> mod_include has are "printenv" and "perl" (which is conditionally
> included anyway).  Also, the "encoding" parameter on "echo" is
> silently ignored right now.
>

Thanks,
-Paul Speed

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

Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml

[Paul Speed]

:)

At least the lag was shorter this time.
-Paul

"Craig R. McClanahan" wrote:
> 
> On Sat, 27 Oct 2001, Paul Speed wrote:
> 
> > Date: Sat, 27 Oct 2001 11:34:58 -0400
> > From: Paul Speed <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers Mailing List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
> >
> > Craig,
> >
> > It looks like this might be due to Bip committing a set of patches
> > that I sent him.  So I might be able to help figure out why it's
> > broken.  What exactly does it complain about?
> >
> 
> Try compiling the current HEAD branch from source, with the
> "compile.ssi" property set to "true", and you'll see the four errors that
> it creates.  I'm not where I can do this for you right at the moment.
> 
> > Thanks.
> > -Paul Speed
> >
> 
> Craig
> 
> > [EMAIL PROTECTED] wrote:
> > >
> > > craigmcc01/10/26 17:50:05
> > >
> > >   Modified:catalina build.xml
> > >   Log:
> > >   Add a kludge to avoid compiling the SSI servlet (and associated utilities)
> > >   because the build is currently broken, and I haven't seen the commit
> > >   message yet (due to the mail delay) in order to properly revert it.
> > >
> > >   Once the compile problems are fixed, simply uncomment the 
> > >   setting for compile.ssi, or include a setting like this in
> > >   build.properties:
> > >
> > > compile.ssi=true
> > >
> > >   Revision  ChangesPath
> > >   1.81  +8 -0  jakarta-tomcat-4.0/catalina/build.xml
> > >
> > >   Index: build.xml
> > >   ===
> > >   RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
> > >   retrieving revision 1.80
> > >   retrieving revision 1.81
> > >   diff -u -r1.80 -r1.81
> > >   --- build.xml 2001/10/26 02:03:28 1.80
> > >   +++ build.xml 2001/10/27 00:50:05 1.81
> > >   @@ -233,6 +233,9 @@
> > >
> > >  
> > >
> > >   +
> > >
> > >  
> > >
> > >   @@ -417,6 +420,7 @@
> > >
> > >
> > >
> > >   +
> > >
> > >
> > >
> > >   @@ -568,6 +572,10 @@
> > >   unless="compile.jmx"/>
> > >   > >   unless="compile.jsse"/>
> > >   +   > >   +   unless="compile.ssi"/>
> > >   +   > >   +   unless="compile.ssi"/>
> > >   > >   unless="compile.jsse"/>
> > >   > >
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:  <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: Tomcat: Distributed Session Management revisited

[Paul Speed]

Tom Drake wrote:
> 
> - Original Message -
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, November 13, 2001 1:25 PM
> Subject: Re: Tomcat: Distributed Session Management revisited
> 
> ... stuff deleted ...
> 
> | > | It would be possible to do this for the HttpSession methods
> | > | themselves (the container would know what's going on), but what do you
> do
> | > | about session attributes?
> | > |
> | > |   HttpSession session = request.getSession();
> | > |   MyObject mo = (MyObject) session.getAttribute("foo");
> | > |   mo.setName("bar");
> | >
> | > I believe that,  in this case, it is incumbent upon the application to
> call
> | >
> | > session.setAttribute("foo", mo);
> | >
> |
> | This violates the principle that the application programming model should
> | not change, but it's certainly feasible to say "if you want load balancing
> | to work on this container, you have to call HttpSession.setAttribute()
> | whenever you modify an attribute's properties".
> |
> | By itself, though, this doesn't provide any support for locking against
> | simultaneous updates (i.e. what you do in "synchronized" blocks in a
> | single VM).
> |
> | It's a little funny funny ... by the time we invent API to solve all these
> | problems, you've just defined a pretty fair chunk of the functionality of
> | EJBs ...
> |
> 
> Locking issues aside, this presents a fair problem for the servlet
> container. How to know if any session attribute was modified per
> your example.

I'm not saying this is necessarily a "good" idea, but you can byte 
compare the resulting session serialization to see if the session 
objects have changed.  All you have to do is keep a local copy of
the original session during the request.  Not very pretty, but 
is a solution that wasn't discussed.

I tend to agree with Costin that the session API isn't well suited
for failover/distribution.  I don't think it's impossible though.
Plus, if you decide to develop an API separate from the session...
it really starts to look like EJB.

-Paul

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

Re: Tomcat: Distributed Session Management revisited

[Paul Speed]

Mika Goeckel wrote:
> 
[ snip ]
> >
> > I'm not saying this is necessarily a "good" idea, but you can byte
> > compare the resulting session serialization to see if the session
> > objects have changed.  All you have to do is keep a local copy of
> > the original session during the request.  Not very pretty, but
> > is a solution that wasn't discussed.
> >
> > I tend to agree with Costin that the session API isn't well suited
> > for failover/distribution.  I don't think it's impossible though.
> > Plus, if you decide to develop an API separate from the session...
> > it really starts to look like EJB.
> 
> I completely agree, that the API lacks proactive support for things in the
> background that may fail.
> But given the fact, that we support a reference implementation which has
> managed to provide really professional services to users (other ref
> implementations are just for demonstration, nobody would use them in
> production) and there are (commercial) solutions, that provide session
> fail-over in the limitations of this API, we **must** try to provide a
> solution. The API does not specify, how often the container may try to
> provide that service or what means it utilizes to do that. Nothing is 100%
> and I think it is better to live with the uncertaincy we discuss here than
> with the more likely problem that an instance fails and there is no
> potential replacement.

For what it's worth, I completely agree.  Failover is _never_
something that the app developer can completely ignore... no matter
how much functionality the container provides.  Developing 
distributed applications takes a little thought at the very least.
And failover is just a simple distributed model.

I've been reading all of this with great interest and waiting to see
where it settles.  I have alot of experience with various forms of
distributed applications and it's interesting to see where they are
similar.  I'm really tempted to explore how a jini solution might
be architected... just from the curiousity side more than anything.
(I've been looking for a good excuse to dive deeper into jini.)

> 
> Byte-comparison is not the worst solution. If we think about differential
> updates, byte comparison is a good candiate for that and surplus one that
> promises good performance.

Interesting.  I hadn't thought about differential updates using 
serialized streams.  They tend to be kind of random but it might
work.  Also, I have written some classes before that can decode the
binary streams as meta-data and now I'm thinking there might even be 
a clever diff that can be done by actually interpretting the data 
during the diff.  I'll have to think about that some more.

> 
> If the user wants to place things in a session that she does not need to be
> replicated, she has the option to declare them transient and write a getter
> that checks if the Attribute is present, otherwise reconstructs it (in the
> case of a picture, reloads it from disk). The user has the choice to design
> for performance or ease. We only need to document the options.

Agreed.
-Paul

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

Re: Tomcat: Distributed Session Management revisited

[Paul Speed]

[EMAIL PROTECTED] wrote:
> 
> On Tue, 13 Nov 2001, Mika Goeckel wrote:
> 
> > I completely agree, that the API lacks proactive support for things in the
> > background that may fail.
> > But given the fact, that we support a reference implementation which has
> > managed to provide really professional services to users (other ref
> > implementations are just for demonstration, nobody would use them in
> > production) and there are (commercial) solutions, that provide session
> > fail-over in the limitations of this API, we **must** try to provide a
> 
> Well, the cool thing about open source is that we _don't_ need to
> implement all the bloat that commercial solution have.

:)

> 
> > solution. The API does not specify, how often the container may try to
> > provide that service or what means it utilizes to do that. Nothing is 100%
> > and I think it is better to live with the uncertaincy we discuss here than
> > with the more likely problem that an instance fails and there is no
> > potential replacement.
> 
> I think it's better to live with the certaincy that everything can (
> and will ) fail and tomcat can't change this.
> 
> The alternative is to give users the impression the data he puts in a
> session will be safe - and he may rely on that instead of using a
> transaction and a real API.
> 
> Databases, EJB, etc are complex - but there's a reason to that. Well,
> we could argue about how much compexity is actually needed, but
> one thing is certain ( I hope ) - get/setAttribute is not enough, if you
> want data integrity you must use a different API ( in particular
> transactions ).
> 
> > Byte-comparison is not the worst solution. If we think about differential
> > updates, byte comparison is a good candiate for that and surplus one that
> > promises good performance.
> 
> Byte compare every 5 seconds every object in session ? Let's say you just
> displayed the confirmation and charged the credit card, but the machine crashed just
> before you sent the order. ( or reverse - you sent it but didn't charged
> the credit card ). This should happen in below 5 seconds.

I think the idea is that you'd byte compare on "commit" which ideally
would happen at request boundaries.  So in this case a single request
becomes a "transaction"... which indeed opens up its own issues, but
no bigger than the ones that were always there.

The main issue is that the app has no control over this transaction.
The case where things get strange is if the JVM dies in the middle 
of processing a single request.  The request may have already 
committed real data to the DB, app server, whatever... and yet the
session state up to the point of failure would be lost.  Even five
second polling wouldn't fix that case.

In fact, that's the same case that fails in _every_ scenario that
doesn't involve full EJB-like transaction support.  As soon as you
access one single piece of data that isn't covered by the 
transaction support, you lose some amount of failover recovery.

Nothing short of full transaction support will ever cover the case 
of the dying JVM... and in some rare cases I think that will even fail.

That being said, there may still be a place for a session-based
distribution mechanism that can support load balancing, hot-swapping
of tomcats, and basic failover.  It should definitely be an opt-in
sort of thing though, ie: web apps that meet the restrictions can
opt to setup tomcat to provide this feature.

> 
> > If the user wants to place things in a session that she does not need to be
> > replicated, she has the option to declare them transient and write a getter
> > that checks if the Attribute is present, otherwise reconstructs it (in the
> > case of a picture, reloads it from disk). The user has the choice to design
> > for performance or ease. We only need to document the options.
> 
> So the user should change all his objects to implement some arbitrary
> pattern just to fit this into our solution ?
> 
> What if the object is not user defined ( like most are ) ? Well, we
> have to create  wrappers for each objects you store in a session. Try to
> explain this on tomcat-user ( or tomcat-dev ) ...

I agree... in these cases, the webapp could not be used with a 
distributed session environment.  I think that's a given.  Personally,
I'm still trying to figure out if there are a large enough number
of webapps that could be supported to make it worth the effort.
(Heavy emphasis on effort.)
-Paul

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

Re: Portable SSL Support

[Paul Speed]

Eric Rescorla wrote:
> 
[snip]
> >
> > To be consistant with 2.3 containers, I'd go with individually named
> > attributes.
> Fine with me. Anyone object to this?
> 
> -Ekr

I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
was the former, but all of the servlet 2.3 comments recently make
me now think it's the latter.
-Paul

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

Re: Recycle objects in TomCat, Performance gain?

[Paul Speed]

There are several reasons to use pooling, including (but not limited
to):
-Eliminating object creation time
-Managing expensive resources (really same as first)
-Keeping memory usage constant (popular in embedded environments)
-Reducing garbage collection

Only the last one is addressed by the quotes below.  And is especially
visible in cases where a program may create, for example, 5000 
Rectangle objects and then manage the pool as needed.  The current
GCs will be much better at managing these objects than a pool would.

Tomcat benefits from all of the above reasons, but from a performance
perspective, probably mostly from the first two.  (Costin's analysis
in the other response seems to bear proof of this.)

-Paul

Samuel Cheung wrote:
> 
> Hi,
> 
> In TomCat's source code, I notice it recycles objects (e.g. RequestBase,
> StandardSession). But in Sun's documentation, with HotSpot Virtual machine,
> pooling objects will hinder performance (see below). Could someone please
> tell me are there advantages of using object pooling in TomCat?
> 
> Thank you.
> 
> Sam
> 
> <<<<< From Sun's Web Page.
> http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 >>>>>>>>
> Should I pool objects to help GC? Should I call System.gc() periodically?
> Should I warm up my loops first so that Hotspot will compile them?
> 
> The answer to all of these is No!
> 
> Pooling objects will cause them to live longer than necessary. The garbage
> collection methods will be much more efficient if you let it do the memory
> management. We strongly advise taking out object pools.
> 
> Don't call System.gc(), HotSpot will make the determination of when its
> appropriate and will generally do a much better job. If you are having
> problems with the pause times for garbage collection or it taking too long,
> then see the pause time question above.
> 
> Warming up loops for HotSpot is not necessary. HotSpot now contains On Stack
> Replacement technology which will compile a running (interpreted) method and
> replace it while it is still running in a loop. No need to waste your
> applications time warming up seemingly infinite (or very long running) loops
> in order to get better application performance.
> 
> See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: Distributed Session Management

[Paul Speed]

The only problem with including the tests right in the same package
is that they can be hard to remove for a test-free distribution.  Also,
since they are in the same package, they have access to some non-public
methods and properties... this can make them a security risk in some
cases (especially since they can't be easily removed).

When opting not to build a separate hierarchy for test classes, we
always created a "test" sub-package.

I can present numerous reasons why it is better to use a separate
hierarchy, but I'm not sure I'd change anyone's mind. :)
-Paul

Tom Drake wrote:
> 
> Mika:
> 
> - Original Message -
> From: "Mika Goeckel" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
> <[EMAIL PROTECTED]>
> Sent: Thursday, November 15, 2001 3:31 AM
> Subject: Re: Distributed Session Management
> 
> | Tom,
> |
> | from my (personal?!) philosophy, tests should be with the tested targets.
> My
> | experience tells me that tests get out of focus if they are in a separate
> | tree.
> 
> I agree, I like to place them in the same package as the code being tested.
> In other projects, I've used a naming convention to distiguish between
> Test classes and other classes (e.g. test classes are named Test?.java)
> 
> | Now when you are going to start hacking, is your approach creating use
> | cases, sequence diagrams etc. before, or something like class
> responsibility
> | cards?
> 
> Usually, I use a combination of things. In my mind the electronic equivalent
> of class responsibility cards are java interface definitions or sparse
> classes
> with some javadoc. The initial message that I sent out that started this
> thread
> had a couple of java interfaces. I'll be sending some more around. I'll may
> also
> send some class diagrams, and sequence or collaboration diagrams.
> 
> Tom
> 
> P.S.
> 
> |
> | M.
> |
> | - Original Message -
> | From: "Tom Drake" <[EMAIL PROTECTED]>
> | To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> | Sent: Wednesday, November 14, 2001 8:39 PM
> | Subject: Distributed Session Management
> |
> |
> | > Tomcat Developers:
> | >
> | > I'm going to try to synthesize the results of yesterdays
> | > discussion on Distributed Session Management into some
> | > working code. From what I can tell, there will be some
> | > changes and new objects in the org.apache.session
> | > package, and possibly some new objects in the
> | > org.apache.cluster package.
> | >
> | > I should have something to share in the next couple of
> | > days. I'll be creating JUnit tests as I write this code. Is there
> | > a standard place to put JUnit tests, or can I simply place
> | > them in the same package as the classes being tested?
> | >
> | > Regards,
> | >
> | > Tom Drake
> | > Email: [EMAIL PROTECTED]
> | >
> | >
> | > --
> | > To unsubscribe, e-mail:
> | <mailto:[EMAIL PROTECTED]>
> | > For additional commands, e-mail:
> | <mailto:[EMAIL PROTECTED]>
> | >
> |
> |
> | --
> | To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> | For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> |
> |
> |
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: Distributed Session Management

[Paul Speed]

"Craig R. McClanahan" wrote:
> 
> On Thu, 15 Nov 2001, Paul Speed wrote:
> 
> > Date: Thu, 15 Nov 2001 14:40:35 -0500
> > From: Paul Speed <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Distributed Session Management
> >
> > The only problem with including the tests right in the same package
> > is that they can be hard to remove for a test-free distribution.  Also,
> > since they are in the same package, they have access to some non-public
> > methods and properties... this can make them a security risk in some
> > cases (especially since they can't be easily removed).
> >
> > When opting not to build a separate hierarchy for test classes, we
> > always created a "test" sub-package.
> >
> > I can present numerous reasons why it is better to use a separate
> > hierarchy, but I'm not sure I'd change anyone's mind. :)
> 
> There's actually a solution that works for both camps:  parallel source
> directory hierarchies.
> 
>   src/java/org/apache/foo   <-- Contains the implementation
>   src/test/org/apache/foo   <-- Contains the tests

Right, that's my preferred approach as well.  The other nice thing
about a separate source hierarchy is that if you decide to one day
change testing methodologies, your real source tree is still pure.
Just create a src/junit/org/apache/foo or src/supertest/org/apache/foo
as needed.

-Paul

> 
> Then, just set up your build scripts to only compile the tests if you need
> them -- a build to create a distribution will omit them.  Yet, the test
> classes will still be in the same Java package, so you can test package
> protected methods without having to modify the implementation classes.
> 
> The existing JUnit tests in jakarta-tomcat-4.0 (plus bunches of other
> Jakarta projects like those in Commons) follow this style.
> 
> > -Paul
> >
> 
> Craig
>

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

[PATCH] SSI support

[Paul Speed]

Hello,

I'm posting my SSI patches again since the CVS versions have changed
since I last posted them.  This latest version has Amy Roh's most
recent changes merged into it.  The description is the same as in the
quoted e-mail.  I'm going ahead and including all.zip which contains
the various patches in case the nice committer that gets to this 
doesn't feel like hitting the web link. :)  Here is the description 
of what all.zip contains (also from the web page linked below):

SsiInvokerServlet.diff
diff -u output for the org.apache.catalina.servlets.SsiInvokerServlet.
This patch should be independent of the others since it just fixes
some SSI directive parsing issues. 

new_classes.zip 
4 new .java files for the org.apache.catalina.util.ssi package. 
Note: I did not add apache headers to these files since I
 didn't think it was appropriate for a non-committer to do so. 

util_ssi.diff 
The diff -u output for many of the other files in the 
org.apache.catalina.util.ssi package. 

tester_web.zip 
New files for the tester/web directory. Includes files for the 
tester/web/golden directory as well... all relative to tester/web. 

tester.diff 
diff -u output for src/bin/tester.xml. It adds the appropriate 
directives for the tests added from tester_web.zip. 

My interest in seeing these changes committed is two-fold:
1) I'd like to know if there are any problems that may require
   my help to resolve.
2) I have some additional changes I'd like to propose at some
   point but I don't want to make my patch set any larger than
   it already is. :)  Specifically, I want to lock down the
   "exec" directive so that SSI can be safely/securely deployed by 
   default.

If someone looks at this stuff and finds something wrong, then
please let me know.  Thanks.
-Paul Speed

Paul Speed wrote:
> 
> Hello,
> 
> I realize Bip is away, but I thought I'd post these anyway before I
> forget about them.  Since I've had problems with multiple attachments
> I went ahead and stuck the files on my web site at:
> 
> http://www.progeeks.com/pspeed/tomcat/SSIPatches.html
> 
> Each file has a description of what it contains and where it should
> go.  If a committer chooses to apply them and has problems then let
> me know.
> 
> Here is the description of the changes from the above-linked page:
> 
> >
> > What I did...
> >
> > The changes to SsiInvokerServlet should be independent of the other
> > changes. Really, I just improved parsing support to handle escaped
> > characters, etc. and be more error-compatible with Apache.
> >
> > The other SSI commands were modified to be more compatible with
> > Apache SSI. Specifically, I've verified that the supported tags
> > should work the same as mod_include in Apache 1.3.22. At least they
> > support the same options. The tags were also enhanced to fit with the
> > new conditional tags.
> >
> > I also added the implementation of the conditional tags: "if",
> > "elif", "else", and "endif". This includes an expression parser.
> > It's been a while since I've written a parser and I tried to do it
> > with a slant on understandability. There's probably room for
> > improvement, but it works the same as Apache on all of the tests
> > I've tried... and it passed all of the new tester pages which
> > generate identical output to Apache 1.3.22.
> >
> > So after these patches, the only tags that are missing that
> > mod_include has are "printenv" and "perl" (which is conditionally
> > included anyway).  Also, the "encoding" parameter on "echo" is
> > silently ignored right now.
> >
> 
> Thanks,
> -Paul Speed
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


all.zip
Description: Zip compressed data

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

servlets-ssi.renametojar

[Paul Speed]

Hello,

I'm currently looking into the security issues pertaining to enabling
this by default.  I followed the conversation for why it is the way
it is, but now that I'm actually in the guts of the thing, I don't
think I fully understand.

The issue as I remember it is that the SsiExec class in servlets-ssi.jar 
could be exploited even if SSI support wasn't enabled in the web.xml 
file.  The part I'm fuzzy on is how this can be true.

Since servlets-ssi.jar is loaded into the server class loader
(server/lib) it seems to me that it would be impossible for a rogue
webapp to access any classes in this jar.

In any case, my solution should protect from these kinds of attacks
also, I'm just not sure they're possible.

I'll be submitting a patch shortly that should allow SSI support to
be enabled by default but would require a specific configuration
change to get the "exec" directive to work.

-Paul Speed

P.S.: I'd be curious to know of anyone actually using the "exec"
directive.  Looking at the code, I'm not sure I see how it works
for non-CGI stuff.

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

[PATCH] SSI Security

[Paul Speed]

As promissed...

I've attached my patches to allow the "exec" directive to be enabled
or disabled (disabled by default).  The extra safety check I've built
in isn't really necessary, but it causes no harm and may prevent some
accidental foot-shootings in the future.

ssi-exec.patch is a diff -u from the catalina/src directory.  (We'll
see if the attachment actually works to the list since I've had 
problems with that before.)

Left up to discussion is the vulnerability of the jar file itself.
I contend that since the jar is in the server/lib class loader that
it is perfectly safe.  Indeed, when I played with moving it into 
shared it resulted in broken dependencies with at least one class 
in server/lib.

If it is not safe then it brings up a larger issue since all 
server/lib class have AllPermission and can therefore do whatever
they want.  If these classes are exploitable by webapps then it seems
to me that security should be set more fine grained (including not
allowing file execute for any file).  Otherwise, there's always risk
that some backdoor will be left open.

-Paul

Index: conf/web.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v
retrieving revision 1.31
diff -u -r1.31 web.xml
--- conf/web.xml2001/11/21 17:36:52 1.31
+++ conf/web.xml2001/11/29 08:05:04
@@ -165,6 +165,12 @@
   
   
   
+  
+  
+  
+  
+  
+  
   
   
   
@@ -194,6 +200,10 @@
 
   ignoreUnsupportedDirective
   1
+
+
+  allowExecDirective
+  0
 
 4
 
Index: share/org/apache/catalina/servlets/SsiInvokerServlet.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
retrieving revision 1.14
diff -u -r1.14 SsiInvokerServlet.java
--- share/org/apache/catalina/servlets/SsiInvokerServlet.java   2001/11/29 03:50:48
 1.14
+++ share/org/apache/catalina/servlets/SsiInvokerServlet.java   2001/11/29 08:05:05
@@ -161,6 +161,13 @@
 }
 
 try {
+value = getServletConfig().getInitParameter("allowExecDirective");
+
+ssiDispatcher.setAllowExecDirective((Integer.parseInt(value)>0)?true:false);
+} catch (Throwable t) {
+;
+}
+
+try {
 value = getServletConfig().getInitParameter("expires");
 expires = Long.valueOf(value);
 } catch (NumberFormatException e) {
Index: share/org/apache/catalina/util/ssi/SsiDispatcher.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/SsiDispatcher.java,v
retrieving revision 1.2
diff -u -r1.2 SsiDispatcher.java
--- share/org/apache/catalina/util/ssi/SsiDispatcher.java   2001/11/29 03:41:26
 1.2
+++ share/org/apache/catalina/util/ssi/SsiDispatcher.java   2001/11/29 08:05:06
@@ -76,7 +76,7 @@
  *  @version   $Revision: 1.2 $, $Date: 2001/11/29 03:41:26 $
  *  @authorPaul Speed
  */
-public class SsiDispatcher {
+public final class SsiDispatcher {
 
 /**
  *  Determines how to treate unknown command references.
@@ -84,6 +84,11 @@
 private boolean ignoreUnsupportedDirective = true;
 
 /**
+ *  True if the exec command is allowed.
+ */
+private boolean allowExec = false;
+
+/**
  *  Contains the SSI command instances.  This is shared
  *  across all dispatcher instances.
  */
@@ -99,7 +104,6 @@
 ssiCommands.put("echo", new SsiEcho());
 ssiCommands.put("fsize", new SsiFsize());
 ssiCommands.put("flastmod", new SsiFlastmod());
-ssiCommands.put("exec", new SsiExec());
 ssiCommands.put("set", new SsiSet());
 
 SsiConditional cond = new SsiConditional();
@@ -107,6 +111,29 @@
 ssiCommands.put("elif", cond);
 ssiCommands.put("else", cond);
 ssiCommands.put("endif", cond);
+}
+
+/**
+ *  Set to true if the "exec" directive is allowed, false otherwise.
+ */
+public void setAllowExecDirective( boolean flag ) {
+this.allowExec = flag;
+
+if (this.allowExec) {
+// For extra safety, the exec object makes sure that
+// the flag is set on the dispatcher that is passed.
+ssiCommands.put("exec", new SsiExec(this));
+} else {
+// Just in case
+ssiCommands.remove("exec");
+}
+}
+
+/**
+ *  Returns true if the "exec" directive is allowed.
+ */
+public boolean allowExecDirective() {
+return allowExec;
 }
 
 /**
Index: share/org/apache/catalina/

Re: servlets-ssi.renametojar

[Paul Speed]

Glenn Nielsen wrote:
> 
> I am pleased to see the interest in security issues.
> 
> But when developing solutions for security issues we need to remember
> that Tomcat4 can use the Java SecurityManager.  And in almost all
> cases the security needed can be achieved by using catalina.policy.
> We should leverarge the Java SecurityManager as much as possible to
> solve these types of security issues rather than writing and relying
> on our own code to enforce security.
> 
> The issue you are addressing Paul can also be addressed by my
> PROPOSAL a week ago.  If Tomcat is running with the Java SecurityManager
> the SSI servlet can't perform an exec unless it has been granted permission
> to do so.

Yes.  I like it.  I hadn't thought about creating yet another class
area to provide finer grain security for just the catalina servlets. 
I'll have to search for your original proposal and take a look.  More 
below...

> 
> --
> 1.  Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes.
> This is where global servlets provided with Tomcat 4 can be installed.
> 
> 2.  Move the following jar files into $CATALINA_HOME/servlets/lib
> 
> servlets-cgi.renametojar
> servlets-common.jar
> servlets-default.jar
> servlets-invoker.jar
> servlets-manager.jar
> servlets-snoop.jar
> servlets-ssi.jar
> servlets-webdav.jar
> 
> 3.  Update the class loader creation in Bootstrap.java for the catalina loader
> to look for jar files and classes in $CATALINA_HOME/servlets in addition
> to $CATALINA_HOME/server.
> 
> 4.  Update the default catalina.policy so that it provides explicit
> permissions for each jar file in $CATALINA_HOME/servlets/lib.
> 
> 5.  Update the documentation regarding the above changes.
> 
> Please vote +1 so I can implement the above changes.
> --

I'm not a committer but I'm willing to help with this.  So that's my
+1 for what it's worth.

> 
> It is time to consider making use of the Java SecurityManager the
> default startup option for Tomcat, or even require that Tomcat be
> run with the Java SecurityManager.

I agree.  I had heard horror stories about getting tomcat to run
with the security manager, but I found it very easy.  It took me
a bit to figure out that the server class loader runs with 
AllPermission and that's why Runtime.exec() is allowed in these
servlets.  I think that even with moving the servlets to their own
area that the server policy should probably be finer grained.
AllPermission is convenient but there are clearly a few things that
that even these classes shouldn't be allowed to do. (Runtime.exec
for example)  Having the server area explicitly spell out its 
security needs will also make fine-tuning that security easier for
the more paranoid sys admins.

All that being said, my patches for disabling the exec directive
might still be useful.  Since it simply removes the directive from
consideration it causes it to be treated as an unknown command
rather than a security error.  Currently, unknown commands can be
ignored with the correct option.  In an ideal world, all of the
directives would be configurable but that seemed like overkill.

Anyway, I'm going to try and setup your proposal here locally
and see if I find any problems.
-Paul

> 
> Regards,
> 
> Glenn
> 
> Paul Speed wrote:
> >
> > Hello,
> >
> > I'm currently looking into the security issues pertaining to enabling
> > this by default.  I followed the conversation for why it is the way
> > it is, but now that I'm actually in the guts of the thing, I don't
> > think I fully understand.
> >
> > The issue as I remember it is that the SsiExec class in servlets-ssi.jar
> > could be exploited even if SSI support wasn't enabled in the web.xml
> > file.  The part I'm fuzzy on is how this can be true.
> >
> > Since servlets-ssi.jar is loaded into the server class loader
> > (server/lib) it seems to me that it would be impossible for a rogue
> > webapp to access any classes in this jar.
> >
> > In any case, my solution should protect from these kinds of attacks
> > also, I'm just not sure they're possible.
> >
> > I'll be submitting a patch shortly that should allow SSI support to
> > be enabled by default but would require a specific configuration
> > change to get the "exec" directive to work.
> >
> > -Paul Speed
> >
> > P.S.: I'd be curious to know of anyone actually using the "exec"
> > directive.  Looking at the code, I'm not sure I 

Re: servlets-ssi.renametojar

[Paul Speed]

Glenn Nielsen wrote:
[snip]
> 
> Glad to hear you had success using Tomcat with the Java SecurityManager.
> Where I work we have several different installs of Tomcat.  All of them
> use a much more restrictive policy file than the default catalina.policy.
> At one point the Tomcat 4 Security Manager docs included an example
> of a more restrictive policy than the default catalina.policy that
> Tomcat 4 is distributed with.  If I have time, I will update those docs
> for the Tomcat 4.0.2 release.  And perhaps add an example catalina.policy
> to the distribution which is more restrictive.  Hmmm, now that the
> framework is there for the admin web application, perhaps an easier
> to understand interface could be added to if for configuring the catalina.policy
> file.

I may have to take a look at these examples.  Trying to whittle down
AllPermission by guess work is a daunting task to say the least. ;)
I'll RTFM before I complain too loudly. :)

> 
> > All that being said, my patches for disabling the exec directive
> > might still be useful.  Since it simply removes the directive from
> > consideration it causes it to be treated as an unknown command
> > rather than a security error.  Currently, unknown commands can be
> > ignored with the correct option.  In an ideal world, all of the
> > directives would be configurable but that seemed like overkill.
> >
> 
> Yes, that might be useful.  I just don't want to see Tomcat 4
> littered with alot of 'security' code when security can be enforced
> using the Java SecurityManager and a policy file.

I whole-heartedly agree with that.
-Paul

> 
> > Anyway, I'm going to try and setup your proposal here locally
> > and see if I find any problems.
> 
> Let me know how it works out.
> 
> Thanks,
> 
> Glenn
>

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

Re: servlets-ssi.renametojar

[Paul Speed]

Hello,

In my playing around with security, I've been attempting to break-out
the AllPermission for the $(catalina.home}/server classes into 
something more granular to allow more refined tweaking.  Here's what I 
have so far:

grant codeBase "file:${catalina.home}/server/-" {
permission java.lang.RuntimePermission "*";
permission java.io.FilePermission "<>",
"read,write,delete";
permission java.util.PropertyPermission "*", "read,write";
permission java.security.SecurityPermission "*";
permission java.net.SocketPermission "*:0-",
"accept,connect,listen,resolve";
permission java.net.NetPermission "*";
permission java.io.SerializablePermission "*";
permission org.apache.naming.JndiPermission "*";
};

I've already removed the execute from the FilePermission and I've
left out the reflection permission since that's a really really ugly
one.  Some of the above are probably way too broad... but certainly
no broader than AllPermission.  I decided to start from the other
end of the spectrum and work backwards.  With the above, I can still
run my own stuff and the tester stuff.

Incidentally, the tester webapp fails to initialize when the security
manager is enabled.  Since it uses PropertyEditorManager in one of
its files, it requires PropertyPermission "*", "read,write" in order
to run.  I'm still trying to figure out how to enabled this just for
the tester app (I have it working if I stick it in the general grant
section).  The docs in catalina.policy don't seem to be helping much.
The other curious thing about this particular error is that it doesn't
show up as an access failure when using the debugging built into the
security manager.

-Paul

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

Re: [SSI] initial environment?

[Paul Speed]

Brian Zhou wrote:
> 
> Hi tomcat-developers,
> 
> Is there a prefered way to set the initial env for an SSI page? I'm working
> on a simple template servlet using SSI to allow something like:
> 
> 
> 
> 
> 
> Most of the support are there, but how does one set the initial env
> programatically from a servlet? I know probably I can add a
> "tomcat.ssi.environment" SsiEnvironment instance as attribute of the
> HttpServletRequest, but it seems to involve the whole catalina.jar and
> servlets-ssi.jar (and maybe more) being copied into
> servletContext/WEB-INF/lib. Is it possible we leave a light-weight,
> loosly-coupled hook for this purpose? I give an example below just using
> Hashtable, of course we can change the attribute name.
> 
> JSP and taglib can achieve the same thing, but I just like the
> non-invasiveness of SSI better - everything still in valid HTML.

That's an interesting idea.  I hadn't thought of that when I wrote 
that stuff.  The problem with using SsiEnvironment directly is, as
you noticed, that it is in the catalina class loader and relies on
at least one other catalina.jar class.  (This was true even before
my SsiEnvironment changes.)

Your code snippet below works, of course.  I'm not a committer, just
an interested party that recently refactored most of the SSI stuff as
a simple contributor ;) ... so I can't actually do anything about any
suggestions along these lines.  The only hesitation that I think a 
committer would have is that your changes are non-standard.  I'm 
pretty sure that there is no standard way to set SSI variables from 
a servlet... and certainly no pre-defined way in the SSI support in 
catalina.  My "pretty sure" also comes from the experience of looking
through the apache module to make sure the tomcat version is as 
compatable as possible.

The reason I enhanced the SSI support in the first place is because
I frequently do something similar myself.  However, in my case, 
my pages contain the body and just include the header and footer.
That way I still have unique URLs for my content... they just pull
in the standard parts from other files.  I don't know if that will
work in your case, though.

Otherwise, your custom mods are probably the only way to solve your
needs.
-Paul

> 
> Thanks,
> 
> -Brian
> 
> diff -r1.2 SsiEnvironment.java
> 69d68
> < import java.util.Date;
> 72a72,73
> > import java.util.Date;
> > import java.util.Enumeration;
> 257a259,267
> >
> > Hashtable initialEnv = (Hashtable)
> request.getAttribute("initial.env");
> > if (initialEnv != null) {
> > Enumeration e = initialEnv.keys();
> > while (e.hasMoreElements()) {
> > String key = (String) e.nextElement();
> > this.setVariable(key, (String) initialEnv.get(key));
> > }
> > }
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: org.apache.tomcat.util.net package in tomcat 3.x

[Paul Speed]

Kevin Seguin wrote:
> 
> >
> > If we move more and more logic and code in j-t-c, we may need
> > to have soon a specific jakarta-tomcat-connectors dev-list ?
> >
> > There is today low java in jtc, mainly native code.
> > If all the 'ORB' java code is moved to j-t-c, for jk,
> > next maybe warp, and coyote also, we'll need to split
> > the current tomcat-dev list.
> >
> > What do you think about ?
> >
> 
> it does seem like j-t-c might be reaching the critical mass where it
> warrants its own list.
> 

Catch me if I'm wrong, but currently j-t-c is dependent on tomcat
code, right?  I make this statement without having actually looked at 
the code for the connectors.  I'm going by recent discussions about
how an API change in Catalina broke the build for a connector.

If this is true, then I think it would be a mistake to separate it
into its own list.  Assuming the above paragraph is true, then
j-t-c isn't really a separate module, it's part of the tomcat 
container, it just happens to be in its own CVS directory.

Personally, I think it should be a separate module buildable without
a tomcat container.  Once it was split out, it should have defined its
own API for a containter interface.  The containers could then 
implement j-t-c adapters in their own areas.  Of course, like I said, 
since I don't know the code it may already be this way.  Also, since 
I run tomcat stand-alone, it would be tough for me to develop and test 
such as thing and I try not to make suggestions I wouldn't be willing
to help develop.

-Paul

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

Re: org.apache.tomcat.util.net package in tomcat 3.x

[Paul Speed]

Kevin Seguin wrote:
> 
> >
> > Catch me if I'm wrong, but currently j-t-c is dependent on tomcat
> > code, right?  I make this statement without having actually looked at
> > the code for the connectors.  I'm going by recent discussions about
> > how an API change in Catalina broke the build for a connector.
> >
> 
> some very small parts of jtc are dependent on tomcat.  these are the
> adapters/connectors for tomcat.  much of what is in jtc is totally
> tomcat-agnostic, and is buildable without tomcat.
> 
> personally, i believe the adapters/connectors for each servlet container
> (tomcat3, tomcat4, perhaps jetty someday) should exist in the container
> module, and the container modules should depend on jtc, not the other way
> around.

Yeah, that's what I was getting at.
-Paul

> 
> just my $0.02.
> 
> -kevin.
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: Connector compatibility between TC 4.0 and 4.1

[Paul Speed]

[EMAIL PROTECTED] wrote:
> 
> On Thu, 20 Dec 2001, Kevin Seguin wrote:
> 
> > perhaps now is the time to do some rethinking of where the connectors for
> > each serlvet container live.
> >
> > today, in j-t-c, there is the framework (for lack of a better word) for
> > connectors plus the individual connectors or adapters for tomcat 3 and
> > tomcat 4.
> >
> > personally, i think it would be better to have the individual
> > connectors/adapters live with the servlet container itself.  i.e. put the
> > ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree.  this
> > way, j-t-c can build without having dependencies on any servlet containers,
> > and servlet containers that want to provide connectors that make use of
> > j-t-c can (optionally) depend on j-t-c.
> 
> My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> 'standalone module', a trusted/priviledged webapp that can be deployed and
> is self-contained.
> 
> Keeping all container adapters in j-t-c has the extra benefit that we can
> share more code among them. 

It still feels wierd to me.  Imagine if JNDI did things this way...
we'd have to have every provider installed just to build it. :)

I think if the layer of abstraction is at the right point you can
get a compromise between code reuse and modularity.  Otherwise, since
the container adapters are in a different module than the containers
themselves, there are always going to be cases where container 
improvements break the connector build.  This is because they are
tagged differently, etc..

Right now it seems to be structured that j-t-c is the application
and the containers are its libraries.  It seems like it should
really be the other way around.  But that's just my non-committer
$0.02.  And I run Tomcat stand-alone anyway... the engineer in me
just had to say something. :)

> And the build changes I'm trying to make
> should simplify building for all or just individual containers.
> 
> For the current release - I don't think we should move the code.
> For jk2 - I also think we should wait until it's in a more concrete shape.

So are you saying that the dependencies should be restructured as
discussed above, but just not yet?

-Paul

> 
> Costin
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: Default classes loaded by Tocmat

[Paul Speed]

Kevin Jones wrote:
> 
> Why not implement your own JSP base class that imports the
> classes/packages you need and have all your pages extend that new class.
> This would also be portable across implementations!

It would also not work.  "import" statements are only for the compiler.
They have nothing to do with the compiled classes.  The subclass must 
define its own imports if it wants to reference the classes in source.

-Paul

> 
> Kevin Jones
> Developmentor
> www.develop.com
> 
> > -Original Message-
> > From: Anand Bashyam Narasimham [mailto:[EMAIL PROTECTED]]
> > Sent: 26 December 2001 21:35
> > To: 'Tomcat Developers List'
> > Subject: RE: Default classes loaded by Tocmat
> >
> >
> > I agree and that's why I still stick to Tomcat :)
> >
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, December 26, 2001 1:34 PM
> > To: Tomcat Developers List
> > Subject: RE: Default classes loaded by Tocmat
> >
> >
> >
> >
> > On Wed, 26 Dec 2001, Anand Bashyam Narasimham wrote:
> >
> > > Date: Wed, 26 Dec 2001 12:31:26 -0800
> > > From: Anand Bashyam Narasimham <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: 'Tomcat Developers List' <[EMAIL PROTECTED]>
> > > Subject: RE: Default classes loaded by Tocmat
> > >
> > > Craig,
> > >
> > > I know Tomcat has always been a standards compliant implementation.
> > > But
> > will
> > > it be possible say for developers to have extensions where
> > instead of
> > > writing the import statements in a whole lot of JSPs we
> > make sure the
> > Class
> > > loader loads this as a extension to the list you've mentioned using
> > > some config file read at startup.
> > >
> > > I do agree that this make it a non-portable JSP, going against the
> > > spirit
> > of
> > > Java and J2EE but today everything written on J2EE though Java is
> > > almost
> > 60%
> > > not portable onto a different implementation :)
> > >
> > > Can this be done?
> > >
> >
> > Sure it can ... by you, modifying the source code yourself
> > and supporting it yourself.  I'm not going to help you,
> > however, do something this crazy.
> >
> > It's one thing when vendors lock you in with non-portable
> > features.  It's a different, and much sadder thing, to see
> > people willing to paint themselves into a corner like this :-(.
> >
> > > Anand
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: <mailto:[EMAIL PROTECTED]>
> >
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Catalina interface/impl separations

[Paul Hammant]

Folks,

Back in a thread that ended on the 16th October we talked of some fixes 
to the code that makes the interface abstractions ( interfaces & classes 
in org.apache.catalina package ) no longer dependant on implementation 
of Catalina.

The reason we needed this is that it will make Catalina more mountable 
in other applications.  Interface/Impl separation allows classloader 
hiding of impl from potentially hostile code.

I guess many issues that were identified were fixed immediately.  Here 
is my view of what is left:

  org.apache.catalina.Cluster -> dependant on classes from 
org.apache.catalina.cluster package
  org.apache.catalina.Connector -> dependant on 
org.apache.catalina.net.ServerSocketFactory
  org.apache.catalina.Context -> dependant on many classes from 
org.apache.catalina.deploy
  org.apache.catalina.DefaultContext -> ditto
  org.apache.catalina.Server -> ditto

The consensus of opinion was to do nothing at that stage that might 
break the API.

What is the feeling nearly three months on?  Are we still aiming at full 
separation in terms both of dependancy and Jar?  Are these five fixable?

Regards,

- Paul H



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

Re: Catalina interface/impl separations

[Paul Hammant]

Tom, Folks,

Thanks for that.  I can't comment really either as I am not a committer. 
 Bip's last revision to Cluster is from July.

I think there are a couple more classes in org.apache.catalina.startup 
that should have interfaces extracted from them and placed in 
org.apache.catalina.  These are:

* Embedded
* EmbeddedManager

Interface extraction should be easy and not break any backwards 
compatability.  Changing over return types might.

Regards,

- Paul H

>I'm not a tomcat developer (yet), but, I've been writing code that provides
>fail-over capability by providing distributed (cluster) session managment.
>
>My review of the catalina code indicates that org.apache.catalina.Cluster is
>not currently useful. The distributed session store does not 'work' and has
>some design issues that must be addressed before it can be made to work.
>
>Tom
>



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

Re: Catalina interface/impl separations

[Paul Hammant]

Thanks Remy,

This is really great news.

>>What is the feeling nearly three months on?  Are we still aiming at full
>>separation in terms both of dependancy and Jar?  Are these five fixable?
>>
>
>No. Just package your JARs differently.
>cluster, deploy and net are self-contained packages, so just integrate them
>in the base package.
>
Could we change the relevant  line in build.xml from



  












  


... to ...



  







  















  


It would be a great help.  In the lifetime of Catalina following the 
first 4.x releases there have been some jar name changes so it is not 
without precident.

Regards,

- Paul H


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

[Patch] new Embedded interface

[Paul Hammant]

As extracted by IDEA/2 an Embedded interface is attached.

There is also a one line change to Embedded (the class).  From

   public class Embedded implements Lifecycle {

... to ...

   public class Embedded implements Lifecycle, 
org.apache.catalina.Embedded {

At some convenient point in the future, it may be best to rename 
Embedded (the class) to DefaultEmbedded.

Regards,

- Paul H




/*
 * $Header: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Deployer.java,v
 1.5 2001/10/25 00:23:02 craigmcc Exp $
 * $Revision: 1.5 $
 * $Date: 2001/10/25 00:23:02 $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * <http://www.apache.org/>.
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */
package org.apache.catalina;

import java.beans.PropertyChangeListener;
import java.net.InetAddress;

/**
 * Convenience interface to embed a Catalina servlet container environment
 * inside another application.  You must call the methods of this class in the
 * following order to ensure correct operation.
 *
 * Prese refer to the reference impl -> org.apache.catalina.startup.Embedded
 *
 * @author Craig R. McClanahan
 * @version $Revision: 1.14 $ $Date: 2001/11/09 19:40:44 $
 */

public interface Embedded {
/**
 * Return the debugging detail level for this component.
 */
int getDebug();

/**
 * Set the debugging detail level for this component.
 *
 * @param debug The new debugging detail level
 */
void setDebug(int debug);

/**
 * Return true if naming is enabled.
 */
boolean isUseNaming();

/**
 * Enables or disables naming support.
 *
 * @param useNaming The new use naming value
 */
void setUseNaming(boolean useNaming);

/**
 * Return the Logger for this component.
 */
Logger getLogger();

/**
 * Set the Logger for this component.
 *
 * @param logger The new logger
 */
void setLogger(Logger logger);

/**
 * Return the default Realm for our Containers.
 */
Realm getRealm();

/**
 * Set the default Realm for our Containers.
 *
 * @param realm The new default realm
 */
void setRealm(Realm realm);

/**
 * Return the secure socket factory class name.
 */
String getSocketFactory();

/**
 * Set t

Re: Todo list for 4.0.2 b2

[Paul Hammant]

Remy, Kevin, Jena-Frederic, Bill, Craig et al,

Could we also do...

* the jar split (my email Jan 7th, 14:28)
* Embbeded interface (my email Jan 7th, 18:51)

Regards,

- Paul H

>Hi,
>
>Here goes the list:
>- Tag the JK + util directories in j-t-c with some tag (Costin proposed
>jk_14)
>- Build the corresponding JK binaries
>- Write some documentation about the new auto-configuration mechanism (but
>it can wait until 4.0.2 Final)
>- Update the AJP page in the docs with other changes for AJP 1.4, if any
>- Tag the warp directories in j-t-c (JF or Pier can you do that ?)
>- Build the corresponding mod_webapp binaries
>- And of course build the main binaries and upload them
>
>According to Costin, JK 1.4 is ready or almost ready. If it's not done yet,
>is it doable by the end of the week ?
>
>Thanks,
>Remy
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>




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

Re: Todo list for 4.0.2 b2

[Paul Hammant]

Remy,

>>* Embbeded interface (my email Jan 7th, 18:51)
>>
>
>-1, because it's an API change for cosmetic reasons only.
>
In the head branch again then?  It of course changes nothing if the 
class is not renamed.  It is not for cosmetic reasons, it will help 
third party applications instantiate Catalina and cast to an interface. 
 Easy and harmless.

Regards,

- Paul H


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

Re: Todo list for 4.0.2 b2

[Paul Hammant]

Remy,

>Only the core objects have interfaces. Embedded is a helper object, so it's
>not an interface. Just like Catalina is not an interface.
>By the way, I don't see how having an interface makes it easier to work with
>Catalina. The only useful thing with interfaces is if you want to extend or
>reimplement something, because of Java's lack of multiple inheritance.
>
Not true.  If you want to *secure* your impl from other code.  You could 
use three schemes:

1) seperate classloaders for the interfaces and impl

  Catalina ImplOther Application*
  |  |
  
   |
 System/Boot/Primordial & Catalina 'interfaces'

* that might want to invoke methods in Catalina via its interfaces.

2) Run the Object implementing the interfaces through a DynamicProxy 
generator, such that the
Other Application cannot cast to the impl.

3) Combination of (1) and (2) to overcome introspection/serialization 
tricks for hacking.

>Also, if you only want to use Catalina as a service inside a bigger
>framework, you should use CatalinaService, not Embedded (and no, there's no
>need for an interface for that either ;-)).
>
I will try with this.  Two things though:

1) For exactly the same reason, it needs an interface.  I *really* 
*need* an interface.

2) CatalinaService exposes less methods than Embedded.  Way less.  I 
guess the idea is that to add hosts and webapps, you should not being 
doing it inVM via method calls but via a connector.

Regards,

- Paul H


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

Re: Todo list for 4.0.2 b2

[Paul Hammant]

Remy,

>If our helper object for embedding doesn't fit your needs, I suggest you
>write your own instead. It doesn't take long, and it will do what you want
>(including having an interface, so it fits into your virtual OS dream).
>
I am talking about Avalon (another Jakarta project).  It is not a 
'dream'  We already have a third-party web server running in it - 
Hendrik Schreiber's most excellent 'Jo!'.  It is quite embarrasing that 
we do not yet (but are so close) have Catalina running in it.

>There are real world users of the current Embedded class (including JBoss
>and the J2EE RI), and none of them would see any benefit about having an
>interface instead of object. Since I'd like to avoid unseless changes for
>the users and also keep the design simpler if I can, I will NOT change the
>current Embedded object to do what you propose, and I vote -1 to the
>associated patch.
>
I am going ask ask you again, *Please* consider the merit for this,  It 
is not unreasonable.  The change is not useless as you say. I was not 
incorrect suggesting another reason for interface/impl separation (it 
was not new to you dude, it had just slipped your mind) was I?.  It is 
such a small thing to do.  Please dude.

Regards,

- Paul H




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

Re: Todo list for 4.0.2 b2

[Paul Hammant]

Remy,

>And why don't you want to write your own wrapper (I doubt Embedded is
>adapted to your use case anyway), and put it in the Avalon tree ? That's why
>I do with the various Catalina wrappers Slide has, and it doesn't cause any
>problems.
>
>Also, not having separated interfaces and implementations doesn't prevent
>from running under Avalon, it only removes the inter-application security,
>which isn't very useful (unless you have a Java mail server which routinely
>tries to hack your Java web server using its internal Java APIs).
>
OK, I'll just write a wrapper that exposes no methods to other 'blocks' 
If we are being asked to use CatalinaService instead of Embedded, then 
there were no useful (internally published) methods available anyway. 
 As such if there are no methods to expose there is no need for *any* 
interface/impl separation.  Therefore I can go ahead as is with the 
currently available Catalina (I guess).

Regards,

- Paul H



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

Re: Todo list for 4.0.2 b2

[Paul Hammant]

Craig,

>Paul, this needs to be turned around as well.  *Please* consider that what
>you are asking for has a very substantial backwards compatibility cost --
>making this change would mean it's impossible to have compiled Java code
>that works with both 4.0.1 and 4.0.2, because the class inheritance of the
>Embedded class would change.  We just went through this trying to undo the
>poor factoring of org.apache.net.ServerSocketFactory -- in the end, we had
>to undo an obviously beneficial change for this reason.
>
Sorry dude, I was only considering the rolling forward of features.  I 
did not realise that 4.0.1 was still a factor.  I thought that the 
additon of an interface (without renaming anything) was completely safe. 
 I stand corrected.

>It is not appropriate to break binary compatibility in the 4.0 branch.
>Breaking it between 4.0 and 4.1-dev is not necessarily as absolute, but
>the penalty is still severe.
>
I'll check back again in some months.  For now, I'll put my "must 
sepserate interface and impl' axe away and let you dude get on with the 
flagship effort.

Keep up the good work...

Regards,

- Paul H


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

Re: synchronize keyword may produce deadlocks.

[Paul Speed]

You do know your code has a typo that will cause deadlocks, don't
you?  See below...

[EMAIL PROTECTED] wrote:
> 
> Hi,
>The synchronize call may deadlock due to thread starvation. This is present
> in all versions of java on all platforms i could test (jdk 1.1 thru 1.4b
> on win/sol/lin)
> Example code for interlock.java is as follows :
> import java.io.*;
> import java.lang.*;
> public class interlock{
> public static int test=0; // 0 - test java synchronize. 1 - test java regular
> private static boolean atomic_spinlock1=false;
> private static boolean atomic_spinlock2=false; public interlock(){}
> public static void main(String[] args) throws InterruptedException {
> log("InterlockTest : If this code completes test was a success."); 
>if(args.length==1){test=Integer.valueOf(args[0]).intValue();}
> new interlock().startup();}
> public static void log(String s){ System.err.println(">"+s); }
> public static void blink(int 
>i){try{Thread.currentThread().sleep(10+i);}catch(Exception
> e){}}
> public static void spinlock1_rel(){atomic_spinlock1=false;}
> public static boolean spinlock1_set(){
> if (atomic_spinlock1==false) { atomic_spinlock1=true; return true; } else
> { return false; } }
> public static void spinlock2_rel(){atomic_spinlock2=false;}
> public static boolean spinlock2_set(){
> if (atomic_spinlock2==false) { atomic_spinlock2=true; return true; } else
> { return false; } }
> public static synchronized void s_spinlock1_rel(){atomic_spinlock1=false;}
> public static synchronized boolean s_spinlock1_set(){
> if (atomic_spinlock1==false) { atomic_spinlock1=true; return true; } else
> { return false; } }
> public static synchronized void s_spinlock2_rel(){atomic_spinlock2=false;}
> public static synchronized boolean s_spinlock2_set(){
> if (atomic_spinlock2==false) { atomic_spinlock2=true; return true; } else
> { return false; } }
> private void startup() { if (test==0) {log("Testing atomic spinlocks with
> Java Virtual Machine sync "); }
> else {log(" Testing atomic spinlocks without Java Virtual Machine sync...");}
> Runner y=new Runner(0);Runner s=new Runner(1); y.start();blink(100);s.start();
> }
> class Runner extends Thread implements Runnable{ private int runr=0;
> Runner(int seq) { runr=seq; } public void run() { log(" Started runner "+runr+"
> -- ");
> log(runr+": Setting atomic spinlock 1...");
> if (test!=0){while(spinlock1_set()==false){}} else { 
>while(s_spinlock2_set()==false){}

Note in the line above that test!=0 is setting spinlock 1 and the else
branch is setting spinlock 2.  So, whenever you test the synchronized
version you are going to get a deadlock since your locking has no
thread identity... a thread can block itself by checking the lock
after setting it.

-Paul Speed

> }
> log(runr+": Set spinlock 1. Now sleeping... ");
> blink(1000); log(runr+": Finished sleeping. Now setting spinlock 2... (if
> bug exists it will hang here...) ");
> if (test!=0){while(spinlock2_set()==false){}} else { while(spinlock2_set()==false){}
> }
> log(runr+": Spinlock 2 set. Now unsetting both spinlocks... ");
> if (test!=0){spinlock2_rel(); spinlock1_rel();}else{s_spinlock2_rel(); 
>s_spinlock1_rel();}
> log(runr+": Completed. ");  }}  }
> 
> BTW, my email has changed.
> [EMAIL PROTECTED] --> [EMAIL PROTECTED]
> Thanks.
> -Ys-
> 
> Free, encrypted, secure Web-based email at www.hushmail.com

RE: Filter Chains slow first time it is called

[Paul Butcher]

All,

Many apologies if this isn't the correct list for this message. Please
point me in the right direction if I've made a mistake.

I've been experiencing problems with latency and filters in Tomcat 4
(both beta 1 and beta 5). A search of the mailing list archives showed
up the exchange summarised below, which I believe relates to the same
problem that I've been experiencing. I've done some further research,
however, and I have reason to believe that the problem may be a little
more serious than this exchange implies. I have an example which
demonstrates the problem reliably which I would be delighted to make
available if someone can tell me how to do so (I assume that attaching a
.war file to this message isn't the right way!).

Like Kevin, I've been experiencing approximately a 30 second latency
when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to
set up my filters, rather than filter chains. I experience the problem
reliably every time.

Also like Kevin, I experience different behaviour when connecting via IE
and Netscape. I have reason to believe that the problem is not with IE,
however; Netscape just copes with it slightly more gracefully. I have
also been using WAP 'phones to connect (my main aim is serving WML pages
to WAP 'phones) and they also experience latency problems.

When connecting to a filtered JSP with IE, the result isn't displayed
for approximately 30 seconds. Something then obviously times out and the
page is displayed correctly. The problem is definitely "after" the
filter has been called - I've added simple logging to my example filter
and its doFilter function completes almost immediately.

When connecting to the same page with Netscape 6, the results display
almost immediately. The connection to the server isn't closed, however
(the "N" in the top right continues to animate and the progress bar at
the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem
to time out after 30 seconds. I've not had the patience to wait long
enough to see when it does time out (its certainly in excess of a
minute).

When using a WAP 'phone, the 'phone times out with an error.

The problem only occurs if I use my filter on a JSP file. It does not
occur when the filter is used on a "plain" HTML file.

If there are any more details that I can provide, please let me know and
I'll do my best.

Thanks,

pbutcher->msgCount++

--
Team Leader, Argogroup plc
http://www.argogroup.com/


>From: "Kevin Jones" <[EMAIL PROTECTED]> 
>Date: Wed, 31 Jan 2001 20:27:34 - >To:
<[EMAIL PROTECTED]> 
>Subject: RE: Filter Chains slow first time it is called 
>
>I've just taken a closer look at this, it's a browser problem.
>
>IE 5.5 has really trouble with content types. Even though I'm setting
the
>type to text/html (in a filter) but at some point I've used IE 5.5 to
get
>the data without the filter. The servlet returns text/xml. It seems
that
>IE5.5 is struggling to reconcile this (that's all I can think of).
>
>Netscape has no problems (for once :-) ),
>
>Kevin Jones
>DevelopMentor
>www.develop.com
>
> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 31 January 2001 19:21
> To: [EMAIL PROTECTED]
> Subject: Re: Filter Chains slow first time it is called
>
>
> Kevin Jones wrote:
>
> > Subject says it all really.
> >
> > The first time a filter chain is executed for a servlet, it
> takes about 30
> > seconds for the response to get back to the client.
> >
>
> It would be surprising if this is related to initializing the
> filter chain --
> after all, the chain is constructed for every single request (not just
the
> first one).  Are you sure there isn't anything application
> specific that takes
> a long time to initialize?
>
> >
> > This doesn't happen everytime but enough to be repeatable.
> >
> > I'm using Beta 1. I've set the app to be reloadable (with a
> reload time of
> > 3) and I'm logging to the console if that helps,
> >
>
> Logs and a test case (even if it doesn't repeat evey single time)
would be
> quite useful in investigating this.

RE: Filter Chains slow first time it is called

[Paul Butcher]

Craig,

Thanks for your prompt reply, and sorry for my delayed reply (I was out
of the office yesterday).

> * Do you have a small test case we can use to investigate this?
>   If so, you can send it either to TOMCAT-DEV or to me in private
mail.

A .war file containing an example is attached to this mail.

> * Are your clients using HTTP/1.0 or HTTP/1.1?

IE 5.5 and Netscape 6 are both 1.1, I believe. The protocol used by a
WAP 'phone depends on the gateway, not the handset, and I'm afraid that
I don't know the answer for the particular gateway that I'm using.

> * Does your filter create a wrapper on the servlet response, or is it
>   just passing things through?

Yes, I create a wrapper (although in the example, the wrapper doesn't
actually *do* anything ;-)

> I suspect that somewhere along the line the output stream 
> isn't getting flushed or closed in a timely manner

I agree. As you can see from my code, I've added as many "flush" and
"close" statements as I can, with no effect unfortunately!

Thanks again,

pbutcher->msgCount++

--
Team Leader, Argogroup plc
http://www.argogroup.com/

 filterbug.war

Re: FYI: Comment on DOXYGEN...

[Paul Speed]

In another thread on this subject it was mentioned that someone was
looking for a replacement to these tools.  I, too, poked around a 
little but it occurred to me that I don't even know what the specific 
requirements for such a tool are.

Might be worth discussion.  Clearly both of the current tools have
their problems.
-Paul Speed

"Pier P. Fumagalli" wrote:
> 
> Even though DOXYGEN is used by APR right now to build their API docs, today,
> when I asked Ben about it he replied that "It's written in bloody C++ and
> you need always the later version of the compiler to make it run"... And
> given the current situation, I totally withdraw my idea of using it _at_all_
> 
> Pier (feeling bloody stupid :)

Re: FYI: Comment on DOXYGEN...

[Paul Speed]

"Pier P. Fumagalli" wrote:
> 
> Paul Speed at [EMAIL PROTECTED] wrote:
> 
> > In another thread on this subject it was mentioned that someone was
> > looking for a replacement to these tools.  I, too, poked around a
> > little but it occurred to me that I don't even know what the specific
> > requirements for such a tool are.
> >
> > Might be worth discussion.  Clearly both of the current tools have
> > their problems.
> 
> Requirements?
> 
> - Parse C (and optionally C++)
> - Derive documentation from JavaDoc style comments in sources

Right, that's the part where it gets wierd.  Assumptions can be made,
like I assume you break down the docs based on file (in the case of
C) since there are no classes.  Ages ago I used a tool that required
section "tags" in the comments.  Ugly tool.

For C++, it's a little more straight forward from an organizational
standpoint.

> - Portable on any platform (no weird C++ code, Perl, Java, or ANSI-C)
> - Maybe have a decent abstraction for the generated documentation
>   (kinda like the Doclet thinghie in JavaDoc, maybe even reusing that)
> 
> Seems easy enough, but NOBODY ever thought about putting all those
> toghether...

I agree.  If I wasn't in poor, start-up company, working my butt
off mode, I'd throw one together myself.

> 
> Pier
> 
> BTW, I checked out ANTLR (as someone suggested, a parser generator) and
> their GNU-C grammar, and the modification would be really huge, up to the
> point that it might be worth rewriting a new grammar, only for the JavaDOC
> style comments in source codes

Yeah, in general, I prefer JavaCC.  No tangible reasons, just warm
and fuzzy ones.

-Paul Speed

Re: fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll => [j-t-c] webserver poll

[Paul Frieden]

Henri,

This is actually very easy with the existing code and a tiny patch I
submitted a few weeks ago.  We're using it in production mode, so it is
known to be stable.  The first version I submitted had some additional
logging added, but I'm attaching a minimal patch.

All you have to do is set the lbfactor in workers.properties to 0, and
it should never select that worker unless the session route points to
it, or the primary worker is down.

This also has the added benefit of making externally load balanced
clusters behave properly for AOL/Compuserve users without special
configuration of the load balancer.  Those services use IP randomizing
proxies which break generic IP-based sticky.  This will cause the
sessions to be re-routed from the Apache that receives the request to
the Tomcat that initiated the session.  This actually works, because we
were able to remove all of our special configurations to deal with this
from our load balancers.  The problem is described at
http://webmaster.info.aol.com/index.cfm?article=15

This patch changes the behavior by pre-initializing lb_value for each
worker.  The selection algorithm searches for the worker with the lowest
lb_value that is not in a failed state.  It then increments the lb_value
by the lb_factor.  lb_factor is set to the inverse (1/x) of the
lb_factor specified in the config file.  When lb_factor in the config
file is 0, this number becomes basically MAX_DOUBLE.  That means that
lb_value becomes MAX_DOUBLE, so it will never be selected for any
practical purposes.

This patch has been tested extensivly in production use, and works
perfectly.

Paul Frieden




GOMEZ Henri wrote:
> 
> >On Thu, Jun 14, 2001 at 10:28:47AM +0200, GOMEZ Henri wrote:
> >> mod_jk support Apache 2.0
> >>
> >> And TC 4.0 as preliminary support for ajp13 used
> >> in mod_jk.
> >>
> >> Could you take a look at it ?
> >
> >Okay, what's the difference between mod_webapp and mod_jk?  I thought
> >that mod_webapp was the preferred TC 4.0 connector?  This seems like
> >this is worthy of a FAQ.  We've still got people using mod_jserv...
> 
> One of the goal of j-t-c, is to be the answer to :
> 
> 'how to connect my webserver to tomcat ?'
> 
> A great effort has been deployed in having an easy to use
> build stuff.
> Next effort will be documentation and ... lobbying :)
> 
> >Oh, is it that mod_webapp uses the Warp protocol, not ajp13?  Does
> >ajp13 support the TC 4.0 hot-deploy functionality?  -- justin
> 
> not in ajp13. But it's successor ajp14, have a strongest login
> procedure, and autoconf support (uri handled passed to web-server).
> Also planned is to inform the web-server of context state, ie
> when a context is put down (for admin purpose), the web-servlet
> must learn it and route request to another servlet-engine (if we
> are in load-balancing configuration).
> 
> what make me think we should add a fault-tolerant/backup-mode worker
> in mod_jk. A la load-balancing, having a group of worker (servlet engine),
> with one principal, and many as backup. If the principal could no more
> handle a request (failure or context down), just have the request
> routed to next worker in list.
> 
> What about ?

--- jk_lb_worker.orig   Fri Jun 15 10:23:42 2001
+++ jk_lb_worker.c  Fri Jun 15 10:23:54 2001
@@ -426,7 +426,7 @@
 p->lb_workers[i].lb_factor = jk_get_lb_factor(props, 
worker_names[i]);
 p->lb_workers[i].lb_factor = 1/p->lb_workers[i].lb_factor;
-p->lb_workers[i].lb_value = 0.0;
+p->lb_workers[i].lb_value = p->lb_workers[i].lb_factor;
 p->lb_workers[i].in_error_state = JK_FALSE;
 p->lb_workers[i].in_recovering  = JK_FALSE;
 if(!wc_create_worker(p->lb_workers[i].name, 

Re: [jtc] tabs policy??

[Paul Speed]

[EMAIL PROTECTED] wrote:
> 
> On Sun, 24 Jun 2001, Justin Erenkrantz wrote:
> 
> > That just leads to formatting problems because people don't understand
> > that.  If you must have tabs, they should be the same as the indention
> > level, not some factor of the indention level.  This doesn't have to be
> > complicated.  One tab == one indention level.
> 
> I'm not sure I understand how you reached that conclusion, but this is
> what causes all the curent problems ( and the reason for people to
> consider tabs as "evil" ).
> 
> Tab size is 8 - or at least used to be before the idea that you can
> "configure" this. What's "evil" is the fact that some editors allow you to
> change the size of the tab.
> 
> In a text you can have multiple indentation levels, and it's true that on
> some typewriters you can use the TAB key to move to the next indentation
> level ( the same as you use ^A to move to beginning of line in some
> editors ). That doesn't mean the tab ascii code will have multiple sizes
> ( and change based on the position in the text). It just mean that stupid
> programmers decided it's easier to add a panel that changes the number of
> spaces equivalent with TAB instead of implementing code that uses spaces
> for indentations < 8, and replaces 8 spaces with a tab symbol.
> 
> And because someone decides to "extend" a ( de-facto ) standard, later on
> we have to abandon the standard and say it's "evil". That happens very
> often, and we're so used with it that now it's almost a habit.
> 
> Costin

The way it always boils down on all of the projects I've worked on
is that spaces always look right no matter what.  Tab characters
have the potential to cause problems.

On the projects where we did not dictate that all developers should 
use a specific editor, we did dictate no tabs in source.  Only 
spaces were allowed.  This made sure that we didn't spend days
criticizing each others' choices in editors and could instead
write code.

That could be the reason so many people gravitate towards arguing 
for no tab characters.  It's not like the file space they save is 
as critical as it used to be 15 years ago. :)

I personally don't care.  I've learned to read it with tabs right or
wrong.  It looks just as cryptic to me as K&R style bracing and I 
can read that just fine. ;)

-Paul Speed

Tomcat and Beans

[Paul Hunnisett]

How does Tomcat manage standard Java beans?  I have attempted to use an
application scoped bean ands have included serialization code in the
finalize() method and the code to read up from file in the constructor.  I
assumed that whenever Tomcat thought a bean was unnecesary it would simply
garbage collect it(which would call my finalize() method) but this doesn't
seem to happen.  The bean get's created fine, but not serialized properly.
What is Tomcat doing?

Paul Hunnisett

RE: Tomcat and Beans

[Paul Hunnisett]

I'm not trying to - I only put the serialization code in as a protection
from my bean being "reset".  Originally I put in no serialization code as I
was assured that the server would not be reset and that my application bean
should exist for the duration of the application.  It was, however,
regularly reset so I put in the serialization.  This made no difference.  It
still gets reset.

Paul

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Geir Magnusson Jr.
Sent: 28 June 2001 13:10
To: [EMAIL PROTECTED]
Subject: Re: Tomcat and Beans


Paul Hunnisett wrote:
>
> How does Tomcat manage standard Java beans?  I have attempted to use an
> application scoped bean ands have included serialization code in the
> finalize() method and the code to read up from file in the constructor.  I
> assumed that whenever Tomcat thought a bean was unnecesary it would simply
> garbage collect it(which would call my finalize() method) but this doesn't
> seem to happen.  The bean get's created fine, but not serialized properly.
> What is Tomcat doing?

How do you ensure that the bean is no longer referenced?

--
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!

RE: Tomcat and Beans

[Paul Hunnisett]

The application is not being shut down!  Yet somehow my beans are getting
"reset".

Paul

-Original Message-
From: Robert Slifka [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2001 13:26
To: '[EMAIL PROTECTED]'
Subject: RE: Tomcat and Beans


>From "The Java Programming Language, 3rd. Ed"

"When an application exits, no further GC is performed, so any objects that
have not yet been collected will not have their finalize() methods invoked."

- r

> -Original Message-
> From: Paul Hunnisett [mailto:[EMAIL PROTECTED]]
> Sent: June 28, 2001 8:19 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Tomcat and Beans
>
>
> I'm not trying to - I only put the serialization code in as a
> protection
> from my bean being "reset".  Originally I put in no
> serialization code as I
> was assured that the server would not be reset and that my
> application bean
> should exist for the duration of the application.  It was, however,
> regularly reset so I put in the serialization.  This made no
> difference.  It
> still gets reset.
>
> Paul
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
> Sent: 28 June 2001 13:10
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat and Beans
>
>
> Paul Hunnisett wrote:
> >
> > How does Tomcat manage standard Java beans?  I have
> attempted to use an
> > application scoped bean ands have included serialization code in the
> > finalize() method and the code to read up from file in the
> constructor.  I
> > assumed that whenever Tomcat thought a bean was unnecesary
> it would simply
> > garbage collect it(which would call my finalize() method)
> but this doesn't
> > seem to happen.  The bean get's created fine, but not
> serialized properly.
> > What is Tomcat doing?
>
> How do you ensure that the bean is no longer referenced?
>
> --
> Geir Magnusson Jr.   [EMAIL PROTECTED]
> System and Software Consulting
> Developing for the web?  See http://jakarta.apache.org/velocity/
> You have a genius for suggesting things I've come a cropper with!
>
>

RE: Tomcat and Beans

[Paul Hunnisett]

The bean is a list of gifts (wedding list).  The gifts are supposed to be
displayed on a JSP and as they are selected they are removed from the bean
and therefore the jsp.  This works for a while, but then suddenly all the
gifts are returned to the bean - even though the removed gifts are not
stored anywhere.

they are added using a standard useBean tag: 

Paul

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Geir Magnusson Jr.
Sent: 28 June 2001 13:37
To: [EMAIL PROTECTED]
Subject: Re: Tomcat and Beans


When you say 'reset', what do you mean?

How are these beans being instantiated and added to the application?

Paul Hunnisett wrote:
>
> The application is not being shut down!  Yet somehow my beans are getting
> "reset".
>
> Paul
>
> -Original Message-
> From: Robert Slifka [mailto:[EMAIL PROTECTED]]
> Sent: 28 June 2001 13:26
> To: '[EMAIL PROTECTED]'
> Subject: RE: Tomcat and Beans
>
> >From "The Java Programming Language, 3rd. Ed"
>
> "When an application exits, no further GC is performed, so any objects
that
> have not yet been collected will not have their finalize() methods
invoked."
>
> - r
>
> > -Original Message-
> > From: Paul Hunnisett [mailto:[EMAIL PROTECTED]]
> > Sent: June 28, 2001 8:19 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Tomcat and Beans
> >
> >
> > I'm not trying to - I only put the serialization code in as a
> > protection
> > from my bean being "reset".  Originally I put in no
> > serialization code as I
> > was assured that the server would not be reset and that my
> > application bean
> > should exist for the duration of the application.  It was, however,
> > regularly reset so I put in the serialization.  This made no
> > difference.  It
> > still gets reset.
> >
> > Paul
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Geir Magnusson Jr.
> > Sent: 28 June 2001 13:10
> > To: [EMAIL PROTECTED]
> > Subject: Re: Tomcat and Beans
> >
> >
> > Paul Hunnisett wrote:
> > >
> > > How does Tomcat manage standard Java beans?  I have
> > attempted to use an
> > > application scoped bean ands have included serialization code in the
> > > finalize() method and the code to read up from file in the
> > constructor.  I
> > > assumed that whenever Tomcat thought a bean was unnecesary
> > it would simply
> > > garbage collect it(which would call my finalize() method)
> > but this doesn't
> > > seem to happen.  The bean get's created fine, but not
> > serialized properly.
> > > What is Tomcat doing?
> >
> > How do you ensure that the bean is no longer referenced?
> >
> > --
> > Geir Magnusson Jr.   [EMAIL PROTECTED]
> > System and Software Consulting
> > Developing for the web?  See http://jakarta.apache.org/velocity/
> > You have a genius for suggesting things I've come a cropper with!
> >
> >

--
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!

RE: Tomcat and Beans

[Paul Hunnisett]

definately want only one instance - see previous email

-Original Message-
From: Robert Slifka [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2001 13:52
To: '[EMAIL PROTECTED]'
Subject: RE: Tomcat and Beans


Is this a multiuser app?  Are you aware that only *one* instance of the bean
is created for the entire application?  I think what you might want here is
a session-scoped bean?

We can take this off list if you want; just email me.

- r

> -Original Message-
> From: Paul Hunnisett [mailto:[EMAIL PROTECTED]]
> Sent: June 28, 2001 8:46 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Tomcat and Beans
>
>
> The bean is a list of gifts (wedding list).  The gifts are
> supposed to be
> displayed on a JSP and as they are selected they are removed
> from the bean
> and therefore the jsp.  This works for a while, but then
> suddenly all the
> gifts are returned to the bean - even though the removed gifts are not
> stored anywhere.
>
> they are added using a standard useBean tag:  class="wedding.ListBean" scope="application" />
>
> Paul
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
> Sent: 28 June 2001 13:37
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat and Beans
>
>
> When you say 'reset', what do you mean?
>
> How are these beans being instantiated and added to the application?
>
> Paul Hunnisett wrote:
> >
> > The application is not being shut down!  Yet somehow my
> beans are getting
> > "reset".
> >
> > Paul
> >
> > -Original Message-
> > From: Robert Slifka [mailto:[EMAIL PROTECTED]]
> > Sent: 28 June 2001 13:26
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Tomcat and Beans
> >
> > >From "The Java Programming Language, 3rd. Ed"
> >
> > "When an application exits, no further GC is performed, so
> any objects
> that
> > have not yet been collected will not have their finalize() methods
> invoked."
> >
> > - r
> >
> > > -Original Message-
> > > From: Paul Hunnisett [mailto:[EMAIL PROTECTED]]
> > > Sent: June 28, 2001 8:19 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Tomcat and Beans
> > >
> > >
> > > I'm not trying to - I only put the serialization code in as a
> > > protection
> > > from my bean being "reset".  Originally I put in no
> > > serialization code as I
> > > was assured that the server would not be reset and that my
> > > application bean
> > > should exist for the duration of the application.  It
> was, however,
> > > regularly reset so I put in the serialization.  This made no
> > > difference.  It
> > > still gets reset.
> > >
> > > Paul
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
> > Behalf Of Geir Magnusson Jr.
> > Sent: 28 June 2001 13:10
> > To: [EMAIL PROTECTED]
> > Subject: Re: Tomcat and Beans
> >
> >
> > Paul Hunnisett wrote:
> > >
> > > How does Tomcat manage standard Java beans?  I have
> > attempted to use an
> > > application scoped bean ands have included serialization code in the
> > > finalize() method and the code to read up from file in the
> > constructor.  I
> > > assumed that whenever Tomcat thought a bean was unnecesary
> > it would simply
> > > garbage collect it(which would call my finalize() method)
> > but this doesn't
> > > seem to happen.  The bean get's created fine, but not
> > serialized properly.
> > > What is Tomcat doing?
> >
> > How do you ensure that the bean is no longer referenced?
> >
> > --
> > Geir Magnusson Jr.   [EMAIL PROTECTED]
> > System and Software Consulting
> > Developing for the web?  See http://jakarta.apache.org/velocity/
> > You have a genius for suggesting things I've come a cropper with!
> >
> >

--
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!

Re: sun.tools.javac.Main will be removed from JDK1.4

[Paul Speed]

"Craig R. McClanahan" wrote:
> 
> There are some pretty intense discussions going on about this, and the
> story hasn't yet been finished ...
> 
> On the other hand, the "new" compiler entry point has an absolutely
> horrible feature (from the point of view of Jasper) -- you have to modify
> System.out and System.err to redirect the compiler output.  Unless system
> variables are unique per classloader (they weren't last time I checked),
> that means we can only do one compile at a time :-(.

This concerns me for a lot of reasons.  Mostly because it's a sign
of a poorly architected program.  A compiler that does not abstract its
error reporting is very poorly designed.  What happens when Java has
a logging API and they want to use that instead?

I'm one of the biggest Sun supporters you'll find.  I think a lot of
bright engineers have come up with some very cool stuff.  However,
this "feature" is one of the most boneheaded things I've ever heard. ;)

-Paul Speed

> 
> An additional note of interest to Ant developers - there is evidence that
> running the compiler (either old or new) leaves a fair amount of cruft
> lying around in static variables, after the compile has completed. The
> recommended solution is to load the compiler itself in its own class
> loader, so that you can throw it all away afterwards.  That's the approach
> we'll take when modifying Jasper.
> 
> Craig
> 
> On Fri, 20 Jul 2001, Sam Ruby wrote:
> 
> > FYI.  Bye bye "classic" compiler.
> >
> > Ant looks safe (it uses reflection), but Jasper looks like it will be
> > affected.
> >
> > - Sam Ruby
> >
> > -- Forwarded by Sam Ruby/Raleigh/IBM on 07/20/2001
> > 07:30 AM ---
> >
> > Davanum Srinivas <[EMAIL PROTECTED]> on 07/20/2001 06:16:57 AM
> >
> > Please respond to [EMAIL PROTECTED]
> >
> > To:   [EMAIL PROTECTED]
> > cc:
> > Subject:  sun.tools.javac.Main will be removed from JDK1.4
> >
> >
> >
> > FYI,
> >
> > -Original Message-
> > From: Leclair, Donald
> > Sent: Thursday, July 19, 2001 7:15 PM
> > To: J2EE Communications
> > Subject: Message 14: Class change impact
> >
> >
> > Sent: Thursday, July 19, 2001 7:08 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Class change impact
> >
> >
> > Dear Licensee,
> >
> > The Java(TM) 2 Platform, Standard Edition team will be making
> > a change that might impact you.
> >
> > The change is that the class "sun.tools.javac.Main"
> > (used for compiling java classes) will be removed in J2SE 1.4.
> > This is not a public API change. If you depend on this class
> > you may be impacted.
> >
> > If you have questions, please follow-up with your designated
> > Licensee Engineer.
> >
> > Regards,
> > Jill Smith
> > Java Partner Engineering
> >
> > =
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> >

Re: [VOTE] Sources in Binary Distributions

[Paul Speed]

"Pier P. Fumagalli" wrote:
> 
> Pier P. Fumagalli at [EMAIL PROTECTED] wrote:
> >
> > [ ] - +1 Remove the sources [I will help in the process, meaning do the job]
> > [ ] - +0 Remove the sources [I can't help, won't help]
> > [X] - -0 Leave the sources [But since I don't volunteer this is not binding]
> > [ ] - -1 Are you nuts? Sources are there and there have to remain.
> >
> > Comments: (required for -1)
> 
> It's a totally pointless discussion... Everyone always included sources in
> binary distros... 

Everyone who?  jakarta/apache?  I would agree with that.  Other 
projects seem to name binary and source distributions appropriately.
I would at the very least argue that the name "binary distro" is 
wrong.

> So, I'm for the peace and quiet and leave things as are
> now. But, since I'm a nice guy, I don't make it pending...
> (Pointless to overiterate on the advantages to see the sources with the
> binaries, like the same .class and .java files all toghether..
> Yadayadayada). But I'm just wasting bandwidth (like the rest of this
> thread!)
> 
> On a sidenote... If we have an installer (like under Windows) I vote -1 for
> removing sources from that, and make it an optional component. So, my -0 is
> only for tarballs/zipballs (balls!) bah! (Go Remy!)
> 
> Pier

I personally don't understand what the big deal is.  Some people
want a binary only distribution, some want a binary+source 
distribution.  Why not provide both?  (Easy for me to say as a 
lurker.)

For what it's worth, I would only download the bin+src distro, ie: 
the same one that's misnamed now.

-Paul Speed

Re: Sources in Binary Distributions

[Paul Speed]

Why not have three different downloads?  src, bin, and src + bin.
(ie: can't we all just get along? ;) )
-Paul Speed

"Rob S." wrote:
> 
> So what we have here is a minority of developers who look through the Tomcat
> source, versus the majority of people who have no interest in the /src dir.
> The argument is "leave src in there so that when I want to look at the
> source, i don't have to download a src dist".
> 
> For some reason, the "keep it in there" argument almost makes it sounds like
> the src is unavailable unless it's in the bin build.  Personally, for all of
> the people that could care less about the source, I don't think it's asking
> much for people who want to look at the source to go and get it...?
> 
> - r
> 
> > -Original Message-
> > From: Loïc Lefèvre [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 02, 2001 12:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Sources in Binary Distributions
> >
> >
> > Absolutely agree with you!
> >
> > -Message d'origine-
> > De : Arun Katkere [mailto:[EMAIL PROTECTED]]
> > Envoyé : jeudi 2 août 2001 17:28
> > À : '[EMAIL PROTECTED]'
> > Objet : RE: Sources in Binary Distributions
> >
> >
> > I don't generally throw in my $0.02 into a well worn thread and add to the
> > noise , but there is another issue which I didn't see anyone bring up.
> >
> > Having source around helps you with debugging. And if that
> > results in better
> > bug reports, i.e., instead of "it doesn't work and here is the
> > stack trace",
> > you get "it doesn't work because you didn't check for null around
> > this line
> > of this file", it is probably worth it.   Keep in mind that many of Tomcat
> > users are competent Java developers. And we are not talking about
> > the entire
> > build system here. Just the basic .java files. Not even native components
> > (which don't aid in this purpose). Sun's Java2 SDK includes the
> > source (just
> > the .java files) for I suspect the same reason.
> >
> > Personally, I download the source distribution only when there is
> > a critical
> > issue in Tomcat that we need resolved now, and patch and build with that
> > fix. Source in the binary on the other hand is useful for many
> > reasons even
> > if you discount the "first step towards getting people involved"
> > argument. A
> > quick check of some aspect of servlet/JSP spec(without going
> > through 100s of
> > pages of PDF). Help quickly identify whether the issue is with Tomcat or
> > your code. All on machines where you typically don't have the full
> > development environment set up (when we are talking about JSP and not
> > servlets).
> >
> > Of course, one can always download the "source distribution". So,
> > if you are
> > set on saving folks a few seconds (or minutes) of download time
> > at a slight
> > cost for those of us who do find it invaluable, that's fine.
> >
> > -arun
> >
> > > -Original Message-
> > > From: Rob S. [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, August 02, 2001 4:19 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Sources in Binary Distributions
> > >
> > >
> > > > I'd like to second that.  I am currently not involved in any active
> > > > development, but looking at sources contained in a binary dist is
> > > > certainly the first step towards getting involved (its on
> > > my list (o:  )
> > >
> > > So you *expect* the /src dir in a binary dist?  That's
> > > mind-blowing to me.
> > > If you're interested in TC development, your first thought
> > > isn't "Time to go
> > > d/l the src distro" it's "Time to d/l the bin dist so I can
> > > check out the
> > > src" ?
> > >
> > > I'm not making a huge stand here, I thought bringing up the
> > > suggestion was
> > > almost common sense.  It's a "bin" dist, i.e. !(src
> > > included).  I wouldn't
> > > expect it to be there 
> > >
> > > - r
> > >
> >
> >

Can't get mod_webapp.c to compile

[Paul Smyth]

If there is something really obvious I'm missing please let me know. I just can't get 
mod_webapp.c to compile. Please help!!

make results below.

Regards Paul Smyth.
[EMAIL PROTECTED]

Make results:
Compiling Apache 1.3 WebApp module
mod_webapp.c:77: parse error before `webapp_module'
mod_webapp.c:77: warning: data definition has no type or storage class
mod_webapp.c:90: parse error before `pool'
mod_webapp.c:97: parse error before `pool'
mod_webapp.c: In function `wam_startup':
mod_webapp.c:99: `s' undeclared (first use in this function)
mod_webapp.c:99: (Each undeclared identifier is reported only once
mod_webapp.c:99: for each function it appears in.)
mod_webapp.c: At top level:
mod_webapp.c:104: parse error before `*'
mod_webapp.c: In function `wam_server':
mod_webapp.c:127: request for member `module_index' in something not a structure or 
union
mod_webapp.c:145: request for member `module_index' in something not a structure or 
union
mod_webapp.c: In function `wa_log':
mod_webapp.c:270: warning: passing arg 4 of `ap_log_error' makes integer from pointer 
without a cast
mod_webapp.c:270: warning: passing arg 5 of `ap_log_error' from incompatible pointer 
type
mod_webapp.c: In function `wam_handler_log':
mod_webapp.c:278: warning: passing arg 4 of `ap_log_error' makes integer from pointer 
without a cast
mod_webapp.c:278: warning: passing arg 5 of `ap_log_error' from incompatible pointer 
type
mod_webapp.c: In function `wam_handler_setctype':
mod_webapp.c:294: warning: assignment makes pointer from integer without a cast
mod_webapp.c: In function `wam_match':
mod_webapp.c:386: request for member `module_index' in something not a structure or 
union
mod_webapp.c:401: warning: assignment makes pointer from integer without a cast
mod_webapp.c:404: request for member `module_index' in something not a structure or 
union
mod_webapp.c: In function `wam_invoke':
mod_webapp.c:424: request for member `module_index' in something not a structure or 
union
mod_webapp.c:429: warning: passing arg 4 of `ap_log_error' makes integer from pointer 
without a cast
mod_webapp.c:429: warning: passing arg 5 of `ap_log_error' from incompatible pointer 
type
mod_webapp.c:436: too few arguments to function `ap_get_remote_host'
mod_webapp.c:443: request for member `sin_port' in something not a structure or union
mod_webapp.c:443: request for member `sin_port' in something not a structure or union
mod_webapp.c:443: request for member `sin_port' in something not a structure or union
mod_webapp.c:443: request for member `sin_port' in something not a structure or union
mod_webapp.c:444: request for member `sin_port' in something not a structure or union
mod_webapp.c:444: request for member `sin_port' in something not a structure or union
mod_webapp.c:444: request for member `sin_port' in something not a structure or union
mod_webapp.c:444: request for member `sin_port' in something not a structure or union
mod_webapp.c:452: structure has no member named `user'
mod_webapp.c:453: structure has no member named `ap_auth_type'
mod_webapp.c:460: `array_header' undeclared (first use in this function)
mod_webapp.c:460: `arr' undeclared (first use in this function)
mod_webapp.c:461: `table_entry' undeclared (first use in this function)
mod_webapp.c:461: `ele' undeclared (first use in this function)
mod_webapp.c:461: parse error before `)'
mod_webapp.c:465: `x' undeclared (first use in this function)
mod_webapp.c: At top level:
mod_webapp.c:492: parse error before `wam_handlers'
mod_webapp.c:493: warning: braces around scalar initializer
mod_webapp.c:493: warning: (near initialization for `wam_handlers[0]')
mod_webapp.c:493: warning: initialization makes integer from pointer without a cast
mod_webapp.c:493: warning: excess elements in scalar initializer
mod_webapp.c:493: warning: (near initialization for `wam_handlers[0]')
mod_webapp.c:494: warning: braces around scalar initializer
mod_webapp.c:494: warning: (near initialization for `wam_handlers[1]')
mod_webapp.c:494: warning: initialization makes integer from pointer without a cast
mod_webapp.c:495: warning: data definition has no type or storage class
mod_webapp.c:498: parse error before `webapp_module'
mod_webapp.c:499: `this_module_needs_to_be_ported_to_apache_2_0' undeclared here (not 
in a function)
mod_webapp.c:499: initializer element is not constant
mod_webapp.c:499: (near initialization for `webapp_module')
mod_webapp.c:500: warning: excess elements in scalar initializer
mod_webapp.c:500: warning: (near initialization for `webapp_module')
mod_webapp.c:501: warning: excess elements in scalar initializer
mod_webapp.c:501: warning: (near initialization for `webapp_module')
mod_webapp.c:502: warning: excess elements in scalar initi

Re: Extending Server.xml configurability (foradditionalclasspaths)

[Paul Speed]

Just clarifying, you basically want the exact same functionality 
you'd get by copying the jars into the individual webapp lib 
directories, but you just don't want to have to copy them.  Right?

-Paul Speed

Rick Mann wrote:
> 
> on 8/30/01 4:22 AM, Glenn Nielsen at [EMAIL PROTECTED] wrote:
> 
> > Why won't installing the jar files in $CATALINA_HOME/lib and making them
> > available to all web applications meet your requirements?
> >
> > Is there a security reason why some web applications can use the classes and
> > others should not?
> 
> Yes. In particular, I may have a set of classes I want to make available to
> my contexts an no one else's. Or perhaps I own a limited-use license on some
> common classes. Imagine an ISP running Tomcat in a virtual-host
> configuration.
> 
> > Do the java classes being shared have static methods and data that needs to be
> > shared across this subset of web applications, but not other web apps?
> 
> No, I don't think data need be shared across any contexts, nor do I think
> you'd want to. It really opens up a can of worms to allow contexts to share
> data in memory like that (IMO). I'm assuming individual contexts have
> private data.
> 
> > I am trying to determine what you want to accomplish and why, not how you want
> > to do it.  Once we know what you want to accomplish it will be easier to
> > determine how to do it within Tomcat 4.
> 
> Sure, that makes perfect sense. I don't require being able to extend a
> context's class search path, that just seems to be the most appropriate
> place to do so.
> 
> > Comments:
> >
> > If you need to restrict access to an API for security reasons there are ways
> > to do that using the Java SecurityManager configuration and permissions
> > granted in the security policy file.
> 
> If you tell me how this is done, I'll let you know if that solves my
> problem. Chances are it does not, because I can't give access to a directory
> to the owner of some contexts, and say "put your common classes in here". I
> have to give access to the CATALINA_HOME/lib|classes dir to every owner of a
> context and I don't want to have to do that.
> 
> But I'm always open to suggestion.
> 
> Thanks!
> 
> Roderick Mann   rmann @ latencyzero.com.sansspam

Re: Extending Server.xml configurability (foradditionalclasspaths)

[Paul Speed]

I wasn't trying to be rude.  I was just summing up a fairly large
discussion that touched on everything from classloader sharing to 
security to where any changes would reside.

You want several web apps to have access to the same jar file as
if each had their own private version, ie: no sharing of static data
or security permissions or any of that.

-Paul Speed

Rick Mann wrote:
> 
> on 8/30/01 11:36 PM, Paul Speed at [EMAIL PROTECTED] wrote:
> 
> > Just clarifying, you basically want the exact same functionality
> > you'd get by copying the jars into the individual webapp lib
> > directories, but you just don't want to have to copy them.  Right?
> 
> Look, if it were the exact same functionality as copying the classes/jars
> into the individual webapp's folders, then that's what I'd do.
> 
> However, it's not the same thing. It makes deployment and development more
> difficult, despite the possibility of creating scripts or ant files to
> automate this process, it's still not as easy as being able to put the
> classes in one place once.
> 
> If it makes you happy, yes. I want the exact same functionality as copying a
> set of class files/jar files into a subset of installed webapp's directories
> without copying them or making links from one dir to another.
> 
> 
> Roderick Mann   rmann @ latencyzero.com.sansspam