You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dakota Jack <da...@gmail.com> on 2005/01/29 07:53:02 UTC
Re: JSP under /WEB-INF folder
<snip>
On Tue, 28 Dec 2004 13:57:33 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> I think his problem is probably linking to stylesheets and such...
> Actually, now I have to ask you... if you put *everything* under
> WEB-INF, I assume you are serving all graphics from a fronting web
> server then? Otherwise, any document returned to the user that links
> back to a resource under WEB-INF won't be reachable, which was the crux
> of his problem as I understood it, that's why he was talking about
> includes and such all over the place. But, if you really are serving
> everything from there, how are you doing it? Just curious at this point :)
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> Dakota Jack wrote:
> > I don't know why you are saying that css and/or js must be placed
> > directly under "WebRoot". Why do you? I can give you various
> > solutions, once I find out what the problem is supposed to be. There
> > is no issue, by the way, with putting your JSP files under WEB-INF.
> > There are other ways to protect access, but this is, I think, a good
> > one too.
> >
> > Jack
</snip>
Frank, are you still interested in this? I just noticed it.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
In regard to our caching discussion, Frank, I think you will like the
following article. The prior article about two essential filters is
interesting too.
http://www.onjava.com/pub/a/onjava/2004/03/03/filters.html?page=1
One thing seems certain: there is complete serverside cache control.
--
"You can lead a horse to water but you cannot make it float on its back."
"Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> The good is that the web site designer knows when a change has been
> made and the assumption is that you are going to see what the web site
> designer has to offer. No?
> Jack
I concur with the assumption, but I don't see it making any
difference... Remember that what we affectionately refer to as "the web"
these days is really a lot more than what it was originally. One of the
things that was originally intended is that the client is in complete
control. If the user wants to request a resource from a server, and
they tell their browser via a setting that "no, I WANT you to go ask
that server EVERY SINGLE TIME for the resources, NEVER use what you
might have in the local cache", then they should be allowed to do that,
and whatever the web site creator wants you to do is irrelevant. Same
idea when the user can override fonts and colors and the like with their
own local settings.
Nowadays though, us web app/site designers think WE know how best a
client should view our site, and we actually go out of our way to make
it so... how many times have you visited a site where the font is too
small and the usual font size adjustments don't make any difference? So
you have to go in to setting and uncheck that "User Font Sizes Specified
By Site" option. Annoying, and not what was originally intended.
This is of course all only relevant to the extent that it supports my
point, that anything you do on the server side to try and control
caching is either (a) useless because the end user can override it
anyway or (b) not in keeping with the "spirit" of the web, at least, not
as originally intended.
Now I'm off on a bit of a tangent though :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
<snip>
> The question that's in my mind though is what happens when you have a
> web server in front of Tomcat? Just "rendering to the response" in a
> servlet might not be enough in that case...
</snip>
*Before* ResourceAction returns null, the response output stream has
been written, flushed, and closed. The only thing that the app
server or the web server have left to deal with is that null. There
is no wrapper in this case and no proxy in the sense you are talking.
The OutputStream from an HttpResponse object writes to the client.
<snip>
> The point being, just because the app server CAN serve everything,
> doesn't necasserily mean it WILL with a web server in front.
</snip>
But, in this case, the OutputStream does and there is no "pass it on"
functionality in there that would incorporate any reference or use of
the web or app server. The fact that this OutputStream ends the
process might be one of the factors favoring ResourceAction.
<snip>
> >>ceteris paribus
> >
> > </snip>
> >
> > Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-)
>
> Really?? Well, I have something to yell at my Macroeconomics professor
> for then! I know for sure she said it was Greek! :)
>
> Funny aside... My Macroeconomics professor... her last name, and I
> couldn't have made this up, is Economopolous. That just rules!
</snip>
LOL Economopolous! Hilarious Remember "My Big Fat Greek Wedding"
where the Greek guy has a way of turning everything to Greek history,
etc.? Well, Ms. "Economopolous" is clearly Greek and her name is
Economic-city. (Plato's "Republic" was really "Politia" which means
"The City". "Republic" comes from "Republica" which was a Latin
translation.) Anyway, this is ALL ceteris paribus. (You can tell
Latin from the endings, "ibus" is the dative plural.)
<snip>
> I did notice, but my point is that the browser settings would override
> any tags or headers you set. I might be wrong about that, but that
> would be my expectation. After all, what good is a setting in my
> browser that says don't cache anything if a web site designer can come
> along and overrule that? Surely the FOSS community would be up in arms
> over their loss of freedom, right?!? ;)
</snip>
The good is that the web site designer knows when a change has been
made and the assumption is that you are going to see what the web site
designer has to offer. No?
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> I am certain on this one, because you can do this sort of thing
> *without* the web or app servers at all. I do this fairly frequently
> with code not unlike and heavily borrowing in principle from Jason
> Hunters HttpMessage and HttpsMessage in COS. The ResourceAction sends
> the response and ends the whole process by returning null.
I agree, obviously you can take Tomcat for instance and use it to serve
everything... I have a production app that is a single server running
Tomcat and Oracle and that's it, no web server anywhere, everything is
served from Tomcat whether it's a JSP, an image, an HTML document or
whatever else.
The question that's in my mind though is what happens when you have a
web server in front of Tomcat? Just "rendering to the response" in a
servlet might not be enough in that case... Think of a proxy analogy...
Does the web server almost appear like a proxy? In other words, a
request comes in to the web server, does it (a) pass the connection to
the app server to fulfill, at which point it's done and can service more
requests, or (b) does it ask the app server for the resource, whatever
it is, wait for the response from the app server and send it along to
the client when the app server is done responding? Same idea as a
network proxy.
The point being, just because the app server CAN serve everything,
doesn't necasserily mean it WILL with a web server in front.
But again, I don't know the answer here, it's just a question in my mind.
>>ceteris paribus
>
> </snip>
>
> Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-)
Really?? Well, I have something to yell at my Macroeconomics professor
for then! I know for sure she said it was Greek! :)
Funny aside... My Macroeconomics professor... her last name, and I
couldn't have made this up, is Economopolous. That just rules!
>>But now your pushing those caching decisions back on the browser, right?
>> I thought one of your basic premises was to not trust the browser to
>>construct URLs and such? Wouldn't you have the same distrust for
>>caching? (and probably worse since that is at least at the users'
>>discrection)
>
> </snip>
>
> The answers are no, yes, no. Setting caching in the response object
> is not equivalent to setting caching in the <meta> tags. This is why
> the ResourceAction has an edge. Note also that the setting of cache,
> pragma and expires are runtime alterable, and can override the <meta>
> tags, in ResourceAction. I left those decisions out of the code I
> sent you. Did you notice where I added in it response to someone's
> query on that?
I did notice, but my point is that the browser settings would override
any tags or headers you set. I might be wrong about that, but that
would be my expectation. After all, what good is a setting in my
browser that says don't cache anything if a web site designer can come
along and overrule that? Surely the FOSS community would be up in arms
over their loss of freedom, right?!? ;)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
<snip>
> > I think that the ResourceAction class actually acts as the web server
> > and that is why the return is null. The class writes to the responses
> > output stream and that is all the server does, right?
>
> I thought so too at first, but upon further reflection I'm not so
> sure... If a request comes in to the web server and then it forwards it
> on to the app server, that would mean at some very low level that the
> web server was passing along the connection to the app server... I'm not
> so sure it's anything that complex... It may be that the app server
> "renders" the response stream, but then passes it back to the web server
> to return to the client. The bottom line though is that we're talking a
> level low enough that I don't know the answer for sure.
</snip>
I am certain on this one, because you can do this sort of thing
*without* the web or app servers at all. I do this fairly frequently
with code not unlike and heavily borrowing in principle from Jason
Hunters HttpMessage and HttpsMessage in COS. The ResourceAction sends
the response and ends the whole process by returning null.
<snip>
> I too await the data :) But, I think you'd have to agree that for your
> approach to wind up being faster, much like when Java programs are
> faster than C programs, it must be due to some hidden optimization going
> on. I mean, on an operation-per-operation basis, C will ALWAYS beat
> Java...
</snip>
Well, maybe on on an "operation" basis. An operation by any other
name is still an operation. However, I don't disagree and would
merely quibble about the language and the description.
<snip>
> Simply put, there will always be less machine code ops going on
> with a C program at the lowest levels (assuming they algorithmically
> equivalent) than a Java program.
</snip>
Well put! Yes!
<snip>
> But, because a Java program can be
> optimized at runtime, that's where the speed gains occur that you can't
> get with C.
</snip>
At the very least this is a main place to gain speed: the Tortoise and
the Hare come to mind.
<snip>
>ceteris paribus
</snip>
Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-)
www.m-w.com
Main Entry: ce·te·ris pa·ri·bus
Pronunciation: 'kA-t&r-&s-'par-&-b&s, 'ke-, 'se-
Function: adverb
Etymology: New Latin, other things being equal
: if all other relevant things, factors, or elements remain unaltered
<snip>
> But now your pushing those caching decisions back on the browser, right?
> I thought one of your basic premises was to not trust the browser to
> construct URLs and such? Wouldn't you have the same distrust for
> caching? (and probably worse since that is at least at the users'
> discrection)
</snip>
The answers are no, yes, no. Setting caching in the response object
is not equivalent to setting caching in the <meta> tags. This is why
the ResourceAction has an edge. Note also that the setting of cache,
pragma and expires are runtime alterable, and can override the <meta>
tags, in ResourceAction. I left those decisions out of the code I
sent you. Did you notice where I added in it response to someone's
query on that?
<snip>
> Granted, some additional flexibility might outweigh any problems. If
> you rolled my BLOBServerAction into your ResourceAction, then you could
> transparently serve images from WEB-INF *or* a database, transparently
> to the user and front-end. That's a nice bit of flexibility to be sure.
</snip>
And, if you imagined more radical uses of images for whole pages,
etc., then you might start thinking about BufferedImages cached in
sessions, etc.
<snip>
> I leave the leg-work to you :)
</snip>
You got it!
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> I just mean the more complicated parsing rules that go with JSP, as
> well as everything else.
Ok, gotcha. But, this only applies for the first access to the JSP,
right? From then on it's a servlet invocation (which is more expensive
than returning just a plain'old HTML document, right? But now I am
splitting hairs)
> Heh, heh! Remind me never to fence with you, Frank. Actually, and
> this is really off topic, in my milieu I am dearly loved because I
> have really learned how to be a friend, husband, etc. This has been
> the largest accomplishment by far in my life and the one I most
> cherish.
That's all that counts in the end. I have a wife of ten years and two
great kids (well, most of the time they are great anyway), and although
I have to remind myself of it sometimes because I get so wrapped up in
other things that aren't as important, they are without a doubt my
greatest accomplishment.
> I think that the ResourceAction class actually acts as the web server
> and that is why the return is null. The class writes to the responses
> output stream and that is all the server does, right?
I thought so too at first, but upon further reflection I'm not so
sure... If a request comes in to the web server and then it forwards it
on to the app server, that would mean at some very low level that the
web server was passing along the connection to the app server... I'm not
so sure it's anything that complex... It may be that the app server
"renders" the response stream, but then passes it back to the web server
to return to the client. The bottom line though is that we're talking a
level low enough that I don't know the answer for sure.
> Again, I am not sure about this, and it is the sort of thing that one
> typically makes mistakes about if one does not go by the data. So, I
> am going to hold judgment on it, but my intuitions are not running in
> the same direction as yours. I keep remembering how the following of
> good OOP principles can make Java applications faster that C
> applications doing the exact same thing, although most think that
> would not be the case. Just the other day I was reading about a guy
> who tried and failed to do some imaging work in early Java and had to
> go to C. Now Java is faster in that area.
> <snip>
I too await the data :) But, I think you'd have to agree that for your
approach to wind up being faster, much like when Java programs are
faster than C programs, it must be due to some hidden optimization going
on. I mean, on an operation-per-operation basis, C will ALWAYS beat
Java... Simply put, there will always be less machine code ops going on
with a C program at the lowest levels (assuming they algorithmically
equivalent) than a Java program. But, because a Java program can be
optimized at runtime, that's where the speed gains occur that you can't
get with C.
Something similar must be happening if your approach winds up being
faster. All things being equal (ceteris paribus), that's the only
logical conclusion to reach. That doesn't make it the right one of
course :) The data will be the decider...
> I think there are trade-offs that will need to be measured. For
> example, I can envision with some of the stuff I do creating whole
> pages dynamically with images. The new Java imaging stuff is really,
> really, cool on this. Flash has its side too.
No argument there... it's the same with OOP vs. strictly procedural
code... if we assume we're always talking a straight compile to machine
code and similar optimizations in both, procedural code should generally
be faster for the same reason I talked about above. Clearly though, the
benefits of an OOP approach outweigh any difference. Same could be true
here.
> Now just one moment, Bub! LOL ;-) You really are not seeing the
> ways you can save time here. For example, there is such a thing as
> caching, pragmas and expiry headers which can be set with a response
> in a way that the meta tags just cannot handle.
But now your pushing those caching decisions back on the browser, right?
I thought one of your basic premises was to not trust the browser to
construct URLs and such? Wouldn't you have the same distrust for
caching? (and probably worse since that is at least at the users'
discrection)
> There will be savings
> of creating no calls where pure HTML would be lost. There will be
> other things like this too. Remember too that the ResourceAction
> class is acting as a multithreaded alternative mini-server. Indeed,
> the approach allows us to get the images, for example, from some other
> server that is maximized to do just this. Conceivably that could be
> quicker for cached images. Remember I said "conceivably". The
> ability to be flexible can make for great rewards in efficiency and
> fluidity that are not immediately obvious.
Granted, some additional flexibility might outweigh any problems. If
you rolled my BLOBServerAction into your ResourceAction, then you could
transparently serve images from WEB-INF *or* a database, transparently
to the user and front-end. That's a nice bit of flexibility to be sure.
> I don't say you are mistaken. I just think that this is going to be
> an interesting little inquiry, if you want to chase it to its end,
> which is my normal proclivity.
At this point I don't think either of us could walk away with an actual
answer :)
> I understand. All your comments are quite fair, in my opinion. We'll
> look around and learn a bit here.
I leave the leg-work to you :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
<snip>
> > I suspect that it is relatively small and, when you
> > introduce sophisticated state and caching options, it may be faster.
>
> Relative to what? To the web server dealing with it? I would suspect
> it's actually relatively BIG compared to that. I'm certainly willing to
> be proved wrong though.
</snip>
As we agree, we just need to get the data. I think there should be a
lot of standard testing out there that is more reliable than I am
probably going to do off the top. I will look around a bit and maybe
someone will chime in with some help here.
<snip>
> That might be true... one other point to remember though is that the
> more "unusual" things you do, the harder it will be to get people able
> to maintain it. I fight standards at work as much as the next guy just
> because creative people don't like standards forced on them, but clever
> solutions usual equal difficult to maintain solutions. I don't think
> I'm telling you something you don't know :) But, that's not my
> argument, so don't spend any time on it. Just another side track we
> could go down :)
</snip>
I am 100% in favor of keeping maintenance low. That was my original
primary objective going here. I could not believe how much time was
being spent on URLs, base tags, etc., etc., with all the concomittant
confusion throughout the development process.
<snip>
> > I think the bigger hit is reading the danged thing. This obviously is
> > especially so when there is an ongoing use of changing the JSP page.
> > This has no penalty with ProtocolPages.
</snip>
I just mean the more complicated parsing rules that go with JSP, as
well as everything else.
<snip>
> That's what I like, woman that are easy to please :) (You were left SO
> wide open there I just couldn't resist!)
</snip>
Heh, heh! Remind me never to fence with you, Frank. Actually, and
this is really off topic, in my milieu I am dearly loved because I
have really learned how to be a friend, husband, etc. This has been
the largest accomplishment by far in my life and the one I most
cherish.
<snip>
> * (Does the app server pass the response back to the web server to
> serve, or does it serve it directly to the client at that point? I'm
> actually not sure, but let's be optimistic and say the web server is out
> of the equation at this point, although I suspect that's NOT the case)
> In any case, images are returned to client<-
</snip>
I think that the ResourceAction class actually acts as the web server
and that is why the return is null. The class writes to the responses
output stream and that is all the server does, right?
FileInputStream fis = new FileInputStream(fileName);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStream os = response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
<snip>
> There is clearly more work done with the second chart because the app
> server is now involved. How costly is all that work?
</snip>
Again, I am not sure about this, and it is the sort of thing that one
typically makes mistakes about if one does not go by the data. So, I
am going to hold judgment on it, but my intuitions are not running in
the same direction as yours. I keep remembering how the following of
good OOP principles can make Java applications faster that C
applications doing the exact same thing, although most think that
would not be the case. Just the other day I was reading about a guy
who tried and failed to do some imaging work in early Java and had to
go to C. Now Java is faster in that area.
<snip>
> You could make the argument that because any servlet-based application
> is incurring those costs with most requests, what's the big deal about
> adding a few more? To a degree that would be a reasonable argument, but
> scalability is most certainly at risk because viewed from the point of
> view of the app server, a single page really corresponds to 10 app
> server requests.
</snip>
I think there are trade-offs that will need to be measured. For
example, I can envision with some of the stuff I do creating whole
pages dynamically with images. The new Java imaging stuff is really,
really, cool on this. Flash has its side too.
<snip>
> Even if it's all done in the most efficient way, those ten requests
> look, for all intents and purposes, like 10 simultaneous USERS (assuming
> 1 request per user). So, maybe your app server can handle 100
> concurrent requests... If the web server was allowed to serve the
> images, your app server still has 100 slots available to service
> requests, which corresponds generally to 100 concurrent users... If it's
> serving 10 images for each physical user though, now you can only
> service 10 concurrent users, so you've reduced your overall server
> capacity (as viewed by outside clients) by 90%. Ouch.
</snip>
Now just one moment, Bub! LOL ;-) You really are not seeing the
ways you can save time here. For example, there is such a thing as
caching, pragmas and expiry headers which can be set with a response
in a way that the meta tags just cannot handle. There will be savings
of creating no calls where pure HTML would be lost. There will be
other things like this too. Remember too that the ResourceAction
class is acting as a multithreaded alternative mini-server. Indeed,
the approach allows us to get the images, for example, from some other
server that is maximized to do just this. Conceivably that could be
quicker for cached images. Remember I said "conceivably". The
ability to be flexible can make for great rewards in efficiency and
fluidity that are not immediately obvious.
I don't say you are mistaken. I just think that this is going to be
an interesting little inquiry, if you want to chase it to its end,
which is my normal proclivity.
<snip>
> I fully acknowledge those are rough, worst-case numbers... I certainly
> don't mean to imply that your approach is 90% worse. Not at all! Just
> trying to illustrate the problem, as I see it, in certain environments.
</snip>
I understand. All your comments are quite fair, in my opinion. We'll
look around and learn a bit here.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
<snip>
On Sun, 30 Jan 2005 14:11:24 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> I still don't understanding the 32 and 22... What do the [2] and [3]'s
> represent?
</snip>
A total of three possible processes (1) getting the request; (2)
passing the request to another server; (3) handling the response.
If you have them all, you have a three. If only 1 and 3, then you have a two.
<snip>
> If we are talking about dynamically-created resources, then I would tend
> to agree with your view. But we have, at least as far as I was
> concerned, been talking about strictly static resources.
</snip>
If there are static resources, then we can get it down to 22 versus 22
by sending the images to a separate server. Not only can we do this,
but we can send the images to a super efficient separate server if we
are talking about static images only.
<snip>
> An app server running ResourceAction can serve resources more
> efficiently than a web server.
</snip>
Not that an app server is faster under any circumstances tha a web
server. That really is not close to true. I've seen the stats on
that one and I would doubt that they will ever be the same or close to
the same. I would be as SCHOCKED as you (is this an Italian-Jewish
SHOCKED? ///;-) ) in that case. What I am talking about is a custom
server for images which gets rid of a LOT of baggage, including
WEB-INF but having the same protections as being under WEB-INF.
<snip>
> Again, strictly talking about static resources, I would be absolutely
> SCHOCKED to learn this is the case under most circumstances. That would
> be like saying a Cadillac could beat a NASCAR vehicle in 1 ten-lap
> race... It might be able to under some circumstances, like the NASCAR
> driver being drunk!, and certainly there are some very nice trade-offs
> to driving the Caddy like more room and a better stereo, but in general
> you wouldn't expect the Caddy to lose.
</snip>
In this case the analogy, IF apt, is the reverse. The custom server
is the NASCAR. All the doodads needed on an app or a web server can
be pealed off and serious savings with multithreading, parsing
presumptions, etc. can be realized.
<snip>
> A bit of hyperbole there, but the underlying point is what's important.
</snip>
I enjoyed the ride in the caddy. Had the stereo on a good jazz
station in my mind with Lead Belly growling at me. The metaphor is
apt but really, when you are talking a mini-quick-custom server,
reversed. I am actually surprised that there are not more of these
little speedy and specialized servers around.
Jack
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I still don't understanding the 32 and 22... What do the [2] and [3]'s
represent?
Dakota Jack wrote:
> Too late when I sent this. Let me make the necessary alterations to
> the nomenclature. Sorry!
>
> web server = df. (WS)
> app server = df. (AS)
> request = df. req
> response = df. res
> ----> = df. passing the control
>
> With ResourceAction
>
> 1.0 WS req WS res HTML [2]
> 1.1 WS req ----> AS res [3]
> 1.2 WS req ----> AS res [3]
> 1.3 WS req ----> AS res [3]
> 1.4 WS req ----> AS res [3]
> 1.5 WS req ----> AS res [3]
> 1.6 WS req ----> AS res [3]
> 1.7 WS req ----> AS res [3]
> 1.8 WS req ----> AS res [3]
> 1.9 WS req ----> AS res [3]
> 1.10 WS req ----> AS res [3]
>
> Total 32
>
> Without ResourceAction
>
> 1.0 WS req WS res HTML [2]
> 1.1 WS req AS res [2]
> 1.2 WS req AS res [2]
> 1.3 WS req AS res [2]
> 1.4 WS req AS res [2]
> 1.5 WS req AS res [2]
> 1.6 WS req AS res [2]
> 1.7 WS req AS res [2]
> 1.8 WS req AS res [2]
> 1.9 WS req AS res [2]
> 1.10 WS req AS res [2]
>
> Total 22
>
> However, let me note, once again, that we can make it 22 to 22 by
> simply sending the attributes that are relevant back to a different
> server. For example, we could have
>
> <img src='http://blahblahblah.com/ResourceAction.do?file=whatever.gif'>
>
> Doing this, if we are talking about serving images to a large-scale
> site, we could get rid of both the WS and the AS and use a SCS (small
> custom server) optimized for this situation. I do this sort of thing
> constantly, *sub rosa*, on my sites. This is probably quicker than
> using WS to serve the images, and certainly so if the images are in
> any way dynamic in nature and if we make use of the multithreading
> opportunities that crop up in this situation. But, this is going
> afield. And, this is only looking at the upside too.
>
> Jack
>
>
If we are talking about dynamically-created resources, then I would tend
to agree with your view. But we have, at least as far as I was
concerned, been talking about strictly static resources.
In that case, your basic premise boils down to, as I see it:
An app server running ResourceAction can serve resources more
efficiently than a web server.
Again, strictly talking about static resources, I would be absolutely
SCHOCKED to learn this is the case under most circumstances. That would
be like saying a Cadillac could beat a NASCAR vehicle in 1 ten-lap
race... It might be able to under some circumstances, like the NASCAR
driver being drunk!, and certainly there are some very nice trade-offs
to driving the Caddy like more room and a better stereo, but in general
you wouldn't expect the Caddy to lose.
A bit of hyperbole there, but the underlying point is what's important.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
Too late when I sent this. Let me make the necessary alterations to
the nomenclature. Sorry!
web server = df. (WS)
app server = df. (AS)
request = df. req
response = df. res
----> = df. passing the control
With ResourceAction
1.0 WS req WS res HTML [2]
1.1 WS req ----> AS res [3]
1.2 WS req ----> AS res [3]
1.3 WS req ----> AS res [3]
1.4 WS req ----> AS res [3]
1.5 WS req ----> AS res [3]
1.6 WS req ----> AS res [3]
1.7 WS req ----> AS res [3]
1.8 WS req ----> AS res [3]
1.9 WS req ----> AS res [3]
1.10 WS req ----> AS res [3]
Total 32
Without ResourceAction
1.0 WS req WS res HTML [2]
1.1 WS req AS res [2]
1.2 WS req AS res [2]
1.3 WS req AS res [2]
1.4 WS req AS res [2]
1.5 WS req AS res [2]
1.6 WS req AS res [2]
1.7 WS req AS res [2]
1.8 WS req AS res [2]
1.9 WS req AS res [2]
1.10 WS req AS res [2]
Total 22
However, let me note, once again, that we can make it 22 to 22 by
simply sending the attributes that are relevant back to a different
server. For example, we could have
<img src='http://blahblahblah.com/ResourceAction.do?file=whatever.gif'>
Doing this, if we are talking about serving images to a large-scale
site, we could get rid of both the WS and the AS and use a SCS (small
custom server) optimized for this situation. I do this sort of thing
constantly, *sub rosa*, on my sites. This is probably quicker than
using WS to serve the images, and certainly so if the images are in
any way dynamic in nature and if we make use of the multithreading
opportunities that crop up in this situation. But, this is going
afield. And, this is only looking at the upside too.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> app server = (AS)
> struts server = (SS)
> req = request
> --> = pass
> res = response
You lost me here already... What's the difference between the app server
and the struts server? Isn't Struts running IN your app server?
> With ResourceAction
> ___________________________________________
> First case HTML = req (AS) res (AS) = 2
> Second image JPEG (say) = req (AS) --> res (SS) = 3
> .....
> Tenth image JPEG (say) = req (AS) --> res (SS) = 3
>
> WIthout ResourceAction
> ___________________________________________
> First case HTML = req (AS) res (AS) = 2
> First image JPEG (say) = req (AS) res (AS) = 2
> Second image JPEG (say) = req (AS) res (AS) = 2
> .....
> Tenth image JPEG (say) = req (AS) res (AS) = 2
>
> This is 22 versus 32. Apparently you "forgot" (I think?) that the app
> server has to handle ten images too. They don't just go out with the
> page, although we are looking at this in a very oversimplified sense.
I don't see how you got 22 OR 32! :) The first request from the client
is for the HTML document, right? So that's one request. The browser
then sees ten <img> tags, regardless of what they point to. So for each
one it makes a request. That's 10 requests, right? So it's 11 in all
from the client to the "server" (ignoring for the moment whether
"server" means app server alone or web server in front of app server, or
whatever other configuration you might dream up).
The only different between the two approaches we've been discussing is
what on the "server" is going to handle each of those 11 requests... Is
it a web server sending back a static HTML page for the first request,
and then an image for each of the subsequent 10 image requests, or is it
a web server returning the HTML page and then an app server returning
the images, or an app server returning the page AND the images?
> There is no question that the AS is quicker with HTML than the SS, but
> I am not so sure about the images. The SS may be faster. There is
> lots of room here for tuning.
Let me ask you this question... If you are accessing a web site, and you
connect "directly" to the Internet, is that, ignoring things like
caching and such, generally going to be faster than going through a
proxy? I'd hope you would say yes. Now, clearly, if the proxy is doing
caching and/or other optimizations, it might turn out to be faster, but
that further proves my point: the web server is like the proxy in this
example.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
I think the worst case is 22 versus 32, Frank. with 10 images. See
your note and then my reasoning below that.
<snip>
> Even if it's all done in the most efficient way, those ten requests
> look, for all intents and purposes, like 10 simultaneous USERS (assuming
> 1 request per user). So, maybe your app server can handle 100
> concurrent requests... If the web server was allowed to serve the
> images, your app server still has 100 slots available to service
> requests, which corresponds generally to 100 concurrent users... If it's
> serving 10 images for each physical user though, now you can only
> service 10 concurrent users, so you've reduced your overall server
> capacity (as viewed by outside clients) by 90%. Ouch.
>
> I fully acknowledge those are rough, worst-case numbers... I certainly
> don't mean to imply that your approach is 90% worse. Not at all! Just
> trying to illustrate the problem, as I see it, in certain environments.
</snip>
app server = (AS)
struts server = (SS)
req = request
--> = pass
res = response
With ResourceAction
___________________________________________
First case HTML = req (AS) res (AS) = 2
Second image JPEG (say) = req (AS) --> res (SS) = 3
.....
Tenth image JPEG (say) = req (AS) --> res (SS) = 3
WIthout ResourceAction
___________________________________________
First case HTML = req (AS) res (AS) = 2
First image JPEG (say) = req (AS) res (AS) = 2
Second image JPEG (say) = req (AS) res (AS) = 2
.....
Tenth image JPEG (say) = req (AS) res (AS) = 2
This is 22 versus 32. Apparently you "forgot" (I think?) that the app
server has to handle ten images too. They don't just go out with the
page, although we are looking at this in a very oversimplified sense.
There is no question that the AS is quicker with HTML than the SS, but
I am not so sure about the images. The SS may be faster. There is
lots of room here for tuning.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
[OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I marked my response as OT, I think we're going down that road (not
exactly unusual for us)...
Dakota Jack wrote:
>>What I was getting at is the fact that if I return a page to the browser
>>that have ten images, all referencing ResourceAction, what's happening
>>is that the browser is making ten separate requests TO THE APP SERVER,
>>whereas in a "typical" setup, these requests would be handled by the
>>fronting web servers. It's clearly more resource-intensive in your
>>approach.
>
> </snip>
>
> I am not clear what part of the process you are referring to, Frank.
> We both agree that the first delivery of the page is via the "front
> server" (I tend to only use the "back server" anyway).
I wasn't clear on that part I guess, but it doesn't change my argument.
I guess your saying the pages aren't even JSPs, which is fine.
Doesn't really change anything though except that there's no servlet
involvement to serve the initial page, which is slightly better. That's
cool...
> If there are
> ten calls to ten images, as you assume for discussion purposes, then
> there will be ten calls either way.
That's correct. Just basic HTTP here :)
> I think you are saying that in
> addition there will be a penalty of a pass to a server that can handle
> Servlets or an equivalent technology that will respond to the
> ProtocolPage by routing the call to some Action, Command, or whatever
> in some language, in the way I suggest. Is that right? If so, let me
> know and we will go from there after you confirm.
That's it exactly. The web server has to forward the .do request to the
app server, which then serves the images, 10 total servlet invocations
in all. Yes, there would be ten requests either way, but one assumes
that the web server can serve static content more efficiently than any
Action you can devise. Perfectly logical argument, ceteris paribus (I
love using Greek in real conversations!), because that's exactly what
web servers are optimized to do.
> I wouild need, as you would too I assume, more information on the
> actual penalty.
Absolutely. The only assumption I'm making is that there IS a penalty.
There are any number of factors that would go into how big or small it
is, whether it's enough to outweigh the benefits of the approach. I
make no attempt here to reach any conclusion on the magnitude of the
problem, if it is a problem at all.
> I suspect that it is relatively small and, when you
> introduce sophisticated state and caching options, it may be faster.
Relative to what? To the web server dealing with it? I would suspect
it's actually relatively BIG compared to that. I'm certainly willing to
be proved wrong though.
> I don't dismiss what you are saying. Don't get me wrong. I just have
> learned to get the data and then to see what the real difference is.
And I would agree that's the right frame of mind in all things :) It
may in fact be such a small penalty that it's worth ignoring. I have a
suspicion it's not, but without empirical data, it's just a hypothesis.
> When considering costs and so on, I am not sure whether the balance
> goes to which side. I would suspect, from my experience, that
> software maintenance and so on would clearly outweigh the hardware and
> associated requirements.
That might be true... one other point to remember though is that the
more "unusual" things you do, the harder it will be to get people able
to maintain it. I fight standards at work as much as the next guy just
because creative people don't like standards forced on them, but clever
solutions usual equal difficult to maintain solutions. I don't think
I'm telling you something you don't know :) But, that's not my
argument, so don't spend any time on it. Just another side track we
could go down :)
> I am surprised at this. You may be right, but my sense is that this
> difference is not really that important when everything else is taken
> into account. Even if you had to cluster multiple machines instead of
> one, say, as a ratio, that would seem to be *probably* cheaper as a
> GUESS. I don't know. We could look at some data and if you have any
> handy I would love to see it.
I don't have any handy, but I agree, some real data here would be better
than us bantering back and forth for the next week :) I suppose the
simplest thing to do is set up a test where you serve 10 static images
from a web server vs. 10 images from your ResourceAction with a web
server in front of the app server and see what the overall response time
is. It would be a little rough, but at least we could tell if there is
a perceivable difference or not.
Then we get into whether thousands of imperceivable hits accumulate
enough over time to hurt us. That's obviously far trickier to guage,
but that's the kind of things us enterprise architects have to bother
about. :)
> I think the bigger hit is reading the danged thing. This obviously is
> especially so when there is an ongoing use of changing the JSP page.
> This has no penalty with ProtocolPages.
Not following... reading from where?
> Well, I bet you are being too humble. I am happy to say that my wife
> just thinks I am the most adorable, wonderful, guy. Go figure, eh?
That's what I like, woman that are easy to please :) (You were left SO
wide open there I just couldn't resist!)
> Technology seems to get ahead of rumor in our little world of web
> work. So, I definitely would like to revisit this. I am going to
> squeeze getting the *facts* in here soon.
I look forward to your test results :)
> This seems to be false to me. Maybe I misunderstand you. I don't
> think the browser has a clue whether we are looking at src='myCss.css'
> or src='resource.do?file=myCss.css'. Right?
> Jack
That's right, the browser doesn't know the difference, but the "server
side" does, and I put that in quotes because it's a little tricker in
this discussion to define it.
Here's a typical sequence chart, simplified a bit:
* Browser requests page from web server->
* Web server returns HTML page<-
* Browser parses page and constructs list of resources to retrieve...
* Each image is requested from web server (in parallel, one hopes!)->
* Web server returns images, in many cases from a memory cache<-
* Browser renders page.
Nothing unusual there. So you have 11 total round-trips to the
"server", one for the document, 10 for the images... It might be the
same HTTP connection, but that's not definite (in fact I think it's
definitely NOT the case, HTTP being stateless and all, but there could
be something I don't know there at a very low level), and ultimately not
relevant to this discussion anyway because it's still 11 requests,
whether the actual connection is torn down between them and rebuilt anew
for each or not.
Now, let's see what happens using ResourceAction, and I'll take the
simpler case of the page being straight HTML and not a JSP...
* Browser requests page from web server...
* Web server returns HTML page<-
* Browser parses page and constructs list of resources to retrieve...
* Each image is requested from web server->
* Web server recognizes .do and passes the request on to app server->
* App server performs whatever functions it needs to in order to fulfill
the request (in this case we're talking the whole litany of Struts
functionality, including your Action of course)<-
* (Does the app server pass the response back to the web server to
serve, or does it serve it directly to the client at that point? I'm
actually not sure, but let's be optimistic and say the web server is out
of the equation at this point, although I suspect that's NOT the case)
In any case, images are returned to client<-
* Browser renders page.
There is clearly more work done with the second chart because the app
server is now involved. How costly is all that work?
You could make the argument that because any servlet-based application
is incurring those costs with most requests, what's the big deal about
adding a few more? To a degree that would be a reasonable argument, but
scalability is most certainly at risk because viewed from the point of
view of the app server, a single page really corresponds to 10 app
server requests.
Even if it's all done in the most efficient way, those ten requests
look, for all intents and purposes, like 10 simultaneous USERS (assuming
1 request per user). So, maybe your app server can handle 100
concurrent requests... If the web server was allowed to serve the
images, your app server still has 100 slots available to service
requests, which corresponds generally to 100 concurrent users... If it's
serving 10 images for each physical user though, now you can only
service 10 concurrent users, so you've reduced your overall server
capacity (as viewed by outside clients) by 90%. Ouch.
I fully acknowledge those are rough, worst-case numbers... I certainly
don't mean to imply that your approach is 90% worse. Not at all! Just
trying to illustrate the problem, as I see it, in certain environments.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
Well, I sure got excited, though. Back to reality! ;-)
<snip>
> What I was getting at is the fact that if I return a page to the browser
> that have ten images, all referencing ResourceAction, what's happening
> is that the browser is making ten separate requests TO THE APP SERVER,
> whereas in a "typical" setup, these requests would be handled by the
> fronting web servers. It's clearly more resource-intensive in your
> approach.
</snip>
I am not clear what part of the process you are referring to, Frank.
We both agree that the first delivery of the page is via the "front
server" (I tend to only use the "back server" anyway). If there are
ten calls to ten images, as you assume for discussion purposes, then
there will be ten calls either way. I think you are saying that in
addition there will be a penalty of a pass to a server that can handle
Servlets or an equivalent technology that will respond to the
ProtocolPage by routing the call to some Action, Command, or whatever
in some language, in the way I suggest. Is that right? If so, let me
know and we will go from there after you confirm.
<snip>
> Agreed. I do see the advantage of this approach, but it's the minuses
> I'm more concerned with. No matter which way you slice it, there's more
> server resources being utilized. That's a big minus when your talking
> about scalability.
</snip>
I wouild need, as you would too I assume, more information on the
actual penalty. I suspect that it is relatively small and, when you
introduce sophisticated state and caching options, it may be faster.
I don't dismiss what you are saying. Don't get me wrong. I just have
learned to get the data and then to see what the real difference is.
When considering costs and so on, I am not sure whether the balance
goes to which side. I would suspect, from my experience, that
software maintenance and so on would clearly outweigh the hardware and
associated requirements.
<snip>
> I think you point out some valid advantages... if nothing else, just
> doing away with having to deal with URLs is a very good thing. But I
> think the performance hit, and certainly the server load, in a "typical"
> Enterprise environment, would make this not a great idea.
</snip>
I am surprised at this. You may be right, but my sense is that this
difference is not really that important when everything else is taken
into account. Even if you had to cluster multiple machines instead of
one, say, as a ratio, that would seem to be *probably* cheaper as a
GUESS. I don't know. We could look at some data and if you have any
handy I would love to see it.
<snip>
> Then again, I say the exact same thing about ASP.Net and JSF because the
> whole idea of calling a server for relatively simple UI events strikes
> me as a horrible idea until we have far better networks than we have
> today, and I seem to be in the minority there, so if I might be wrong
> there, I might be wrong here too :)
</snip>
I think the bigger hit is reading the danged thing. This obviously is
especially so when there is an ongoing use of changing the JSP page.
This has no penalty with ProtocolPages.
<snip>
> My wife wouldn't agree with the listening part :)
</snip>
Well, I bet you are being too humble. I am happy to say that my wife
just thinks I am the most adorable, wonderful, guy. Go figure, eh?
<snip>
> I think in enterprise-type environments this is a pretty standard
> approach with fairly well agreed upon benefits. Anything that breaks it
> has to exceed those benefits. As my father used to say, that's a tough
> nut to crack! Nothing wrong with trying to build the hammer though :)
</snip>
Technology seems to get ahead of rumor in our little world of web
work. So, I definitely would like to revisit this. I am going to
squeeze getting the *facts* in here soon.
<snip>
> Absolutely it is, but as I pointed out, it's being interpreted on the
> browser side. That's where the issue comes in to play I think,
> especially in a distributed environment. I'd be interested to hear your
> thoughts on this point...
</snip>
This seems to be false to me. Maybe I misunderstand you. I don't
think the browser has a clue whether we are looking at src='myCss.css'
or src='resource.do?file=myCss.css'. Right?
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> I am going to tell you something that you might have missed. There is
> no need to have a JSP page to do this. This is NOT dynamic content.
> This is strictly HTML.
I fully understand that. Keep in mind that a recent project I did
required that images be served out of a database. To do this I wrote a
BLOBServerAction that results in tags like this:
<img src="BLOBServer.do?table=logos%field=logo&query=where id='123'">
(with the query URL encoded of course). This is very much like what you
do, except that my BLOBServerAction allows me to serve any BLOB-type
from a database. Very similar concept, which is why I know where you
are coming from full well.
> The key here is the use of a PROTOCOL instead of a URL. What happens
> when you do that is not immediately obvious. Personally, I avoid URLs
> whenever possible as they merely couple your work to options you
> probably will frequently wish you did not have to take. Read on!
I can't say I understand what your saying here. Can you dumb it down a
bit for an old man? :)
> The ResourceAction requires Struts but does not require JSP. Cool?
> Remember that Struts has nothing to do with JSP, Velocity, etc. This
> is pure HTML requiring Struts.
Absolutely.
> <snip>
>
>>Putting everything under WEB-INF removes this choice because every
>>request has to be routed to your app servers now.
>
> </snip>
>
> Surprisingly, perhaps, not so! There is nothing in an HTML page that
> has the Struts protocol for the ResourceAction code which makes that
> page dynamic, even though the content is. This is pure HTML. That is
> why it works so great inside Flash ActionScript too. You cannot,
> after all, put JSP inside Flash ActionScript.
What I was getting at is the fact that if I return a page to the browser
that have ten images, all referencing ResourceAction, what's happening
is that the browser is making ten separate requests TO THE APP SERVER,
whereas in a "typical" setup, these requests would be handled by the
fronting web servers. It's clearly more resource-intensive in your
approach.
As I said before, if your environment is a single server anyway, even if
you have a web server in front of an app server, this probably doesn't
make much difference, although it will always make some becuase the app
server is involved instead of just the web server. That was my original
point.
> Frankly, no pun intended, Frank, I have considered doing all tags via
> something like this and through Struts Actions. That would mean that
> your page designers would have freedom you could not believe and that
> the same pages could work for any backend language.
Agreed. I do see the advantage of this approach, but it's the minuses
I'm more concerned with. No matter which way you slice it, there's more
server resources being utilized. That's a big minus when your talking
about scalability.
> What do you think?
I think you point out some valid advantages... if nothing else, just
doing away with having to deal with URLs is a very good thing. But I
think the performance hit, and certainly the server load, in a "typical"
Enterprise environment, would make this not a great idea.
Then again, I say the exact same thing about ASP.Net and JSF because the
whole idea of calling a server for relatively simple UI events strikes
me as a horrible idea until we have far better networks than we have
today, and I seem to be in the minority there, so if I might be wrong
there, I might be wrong here too :)
> Don't you know better than to get me talking? ;-) LOL That's why I
> love talking to you. You not only have a lot to say, you also listen.
> Nice combination!
My wife wouldn't agree with the listening part :)
> <snip>
>
>>In larger scenarios,
>>the whole point of the web servers (well, most of the point anyway) is
>>to offload that work from the app servers and gain efficiency. Division
>>of labor and all that jazz. :)
>
> </snip>
>
> Agreed, although I would certainly love to see a huge discussion by
> the mavens in the area on that one. I think that there is more than
> meets the eye to that. Still, however, agreed!
>
> <snip>
I think in enterprise-type environments this is a pretty standard
approach with fairly well agreed upon benefits. Anything that breaks it
has to exceed those benefits. As my father used to say, that's a tough
nut to crack! Nothing wrong with trying to build the hammer though :)
> Certainly there are things one would have to do in a distributed
> environment, but the fact that there is a complete decoupling by using
> a protocol rather than a URL makes all these problems easily
> solveable. You can do wonders with this sort of thing which you would
> never consider prior to doing this. You ought to try it on some
> project and watch where you will be surprised. This is so efficient
> and flexible. Remember, the code src='resource.do?file='my.css' is
> stricly HTML.
Absolutely it is, but as I pointed out, it's being interpreted on the
browser side. That's where the issue comes in to play I think,
especially in a distributed environment. I'd be interested to hear your
thoughts on this point...
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Posted by Dakota Jack <da...@gmail.com>.
Hi, Frank,
Always good discussing these matters with you. I think you are going
to get a kick out of the turn this reply to your response will get. I
AM GOING TO REVEAL WHY I THINK THAT THE BASIC STRUTS ARCHITECTURE, AND
.do IN PARTICULAR, IS THE WAVE OF THE FUTURE, NOT THE PAST. [Imagine
"Mission Impossible" music in the background.] I have great faith in
the Servlet, but not the JSP, idea.
I am going to tell you something that you might have missed. There is
no need to have a JSP page to do this. This is NOT dynamic content.
This is strictly HTML. So, the page that has this is not thereby
crippled at all in this sense. There is nothing in using this that
changes HTML to JSP or any other dynamic pages. That is the miracle
of "returns null;" This is a different kettle of fish. Please note,
also that the HTML for the ResourceAction can access any server it
wants. This is highly flexible, not staid and bound. '
The key here is the use of a PROTOCOL instead of a URL. What happens
when you do that is not immediately obvious. Personally, I avoid URLs
whenever possible as they merely couple your work to options you
probably will frequently wish you did not have to take. Read on!
<snip>
On Sat, 29 Jan 2005 20:10:08 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> > Lo, Frank. You really don't lose anything. You just gain a choice.
> > There is a lot more to be said on this, but you probably would know
> > everything on this anyway, so I will leave it at that.
>
> That's not strictly true though Jack (neither your premise that you
> don't lose anything or that I know everything about this, I almost
> certainly don't!)...
>
> In some environments, as I'm sure you know and probably have even dealt
> with, you have a bunch of web servers in front of a bunch of app
> servers. The web servers serve static content like images, stylesheets
> and usually server-side includes, things like that, while the app server
> handles JSPs and actual server-side (servlet) code.
</snip>
The ResourceAction requires Struts but does not require JSP. Cool?
Remember that Struts has nothing to do with JSP, Velocity, etc. This
is pure HTML requiring Struts.
<snip>
> Putting everything under WEB-INF removes this choice because every
> request has to be routed to your app servers now.
</snip>
Surprisingly, perhaps, not so! There is nothing in an HTML page that
has the Struts protocol for the ResourceAction code which makes that
page dynamic, even though the content is. This is pure HTML. That is
why it works so great inside Flash ActionScript too. You cannot,
after all, put JSP inside Flash ActionScript.
Frankly, no pun intended, Frank, I have considered doing all tags via
something like this and through Struts Actions. That would mean that
your page designers would have freedom you could not believe and that
the same pages could work for any backend language. I have done some
dabbling with this and have internally called them ProtoCallPages. I
suspect the use of JPP (a sort of Action page language which is based
on having to have the code off the page) in conjunction with Servlets
is much better than in conjunction with JSP or other tag based ideas.
We'll see in time.
What do you think? I am sure that there are huge issues to consider
but my experience with ResoureAction tells me that things might work
out fine. I actually sort of compound JPP with some Struts form tags
to get dynamic images with language, size, background and foreground
colors (or images), fonts, etc. all dynamic but requiring only a
protocol for my part. I have considered just droping the Struts part
altogether and keeping JPP doing all the form stuff with pure HTML but
with all the dynamic results you get from things like JSP, ASP, etc.
Anyway, enough of this.
Don't you know better than to get me talking? ;-) LOL That's why I
love talking to you. You not only have a lot to say, you also listen.
Nice combination!
<snip>
>In larger scenarios,
> the whole point of the web servers (well, most of the point anyway) is
> to offload that work from the app servers and gain efficiency. Division
> of labor and all that jazz. :)
</snip>
Agreed, although I would certainly love to see a huge discussion by
the mavens in the area on that one. I think that there is more than
meets the eye to that. Still, however, agreed!
<snip>
> I'd certainly agree that if a particular situation doesn't call for such
> a distributed environment in the first place, than it's a moot point,
> and what you suggest certainly has some benefits. But if that's not the
> case, or if it some day might not be the case (i.e., your app might have
> to scale into such an environment), then it could become an issue and
> people should be aware of it before they make their decision.
>
> I also don't know what effect this might have in a true distributed
> environment (i.e., might it be a problem if one request, say for an
> image, is serviced by one machine, while another services the JSP
> execuetion itself?). This might never arise, or it might not be a
> problem at all even if it does, but it could be something for someone to
> explore is my point.
</snip>
Certainly there are things one would have to do in a distributed
environment, but the fact that there is a complete decoupling by using
a protocol rather than a URL makes all these problems easily
solveable. You can do wonders with this sort of thing which you would
never consider prior to doing this. You ought to try it on some
project and watch where you will be surprised. This is so efficient
and flexible. Remember, the code src='resource.do?file='my.css' is
stricly HTML.
Now, if someone wants to get in a fight, they will jump into the
semantic heaven of debating what "strictly" means. However, please
note that I am talking about syntax and not semantics.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
> Lo, Frank. You really don't lose anything. You just gain a choice.
> There is a lot more to be said on this, but you probably would know
> everything on this anyway, so I will leave it at that.
That's not strictly true though Jack (neither your premise that you
don't lose anything or that I know everything about this, I almost
certainly don't!)...
In some environments, as I'm sure you know and probably have even dealt
with, you have a bunch of web servers in front of a bunch of app
servers. The web servers serve static content like images, stylesheets
and usually server-side includes, things like that, while the app server
handles JSPs and actual server-side (servlet) code.
Putting everything under WEB-INF removes this choice because every
request has to be routed to your app servers now. In larger scenarios,
the whole point of the web servers (well, most of the point anyway) is
to offload that work from the app servers and gain efficiency. Division
of labor and all that jazz. :)
I'd certainly agree that if a particular situation doesn't call for such
a distributed environment in the first place, than it's a moot point,
and what you suggest certainly has some benefits. But if that's not the
case, or if it some day might not be the case (i.e., your app might have
to scale into such an environment), then it could become an issue and
people should be aware of it before they make their decision.
I also don't know what effect this might have in a true distributed
environment (i.e., might it be a problem if one request, say for an
image, is serviced by one machine, while another services the JSP
execuetion itself?). This might never arise, or it might not be a
problem at all even if it does, but it could be something for someone to
explore is my point.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
> <snip>
> On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>One thing worth pointing out about this is that you'll lose the benefit
>>of fronting your app server with a web server... You won't be able to
>>offload the serving of images, stylesheets and such, from the app server
>>to the web server. That's probably not a big problem in many cases
>>where a single server with a decent set of specs can handle the load
>>anyway, but in a more robust "enterprise" environment, your really kind
>>of defeating the purpose of a fleet of web servers in front of a number
>>of app servers.
>
> </snip>
>
> Lo, Frank. You really don't lose anything. You just gain a choice.
> There is a lot more to be said on this, but you probably would know
> everything on this anyway, so I will leave it at that.
>
> Jack
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder
Posted by Dakota Jack <da...@gmail.com>.
<snip>
On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> One thing worth pointing out about this is that you'll lose the benefit
> of fronting your app server with a web server... You won't be able to
> offload the serving of images, stylesheets and such, from the app server
> to the web server. That's probably not a big problem in many cases
> where a single server with a decent set of specs can handle the load
> anyway, but in a more robust "enterprise" environment, your really kind
> of defeating the purpose of a fleet of web servers in front of a number
> of app servers.
</snip>
Lo, Frank. You really don't lose anything. You just gain a choice.
There is a lot more to be said on this, but you probably would know
everything on this anyway, so I will leave it at that.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
One thing worth pointing out about this is that you'll lose the benefit
of fronting your app server with a web server... You won't be able to
offload the serving of images, stylesheets and such, from the app server
to the web server. That's probably not a big problem in many cases
where a single server with a decent set of specs can handle the load
anyway, but in a more robust "enterprise" environment, your really kind
of defeating the purpose of a fleet of web servers in front of a number
of app servers.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
> <snip>
> On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>Just from a curiosity standpoint Jack... I've already decided it's not
>>an approach I'd advocate, but I am interested to know how you serve
>>things like graphics and stylesheets from under WEB-INF. I assume all
>>your graphics are actually server by an Action (a trick I've pulled when
>>serving images from a database), and I further assume your stylesheets
>>aren't just linked in...
>
> </snip>
>
>
> <img src='resource.do?file=whatever.jpg'>
>
> <link
> href='resource.do?file=whatever.css'
> rel='stylesheet'
> type='text/css'>
>
> You can also put this sort of Struts protocol into Flash ActionScript, etc.
>
> To be complete on this list:
>
> public final class ResourceAction
> extends Action {
>
> public ActionForward execute(ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response)
> throws IOException,
> ServletException {
> String file = request.getParameter("file");
> String ext = file.substring(file.lastIndexOf('.') + 1);
> String type = null;
> String path = null;
>
> if ("gif".equals(ext)) {
> type = "image/gif";
> path = path("gif");
> } else if ("jpg".equals(ext)) {
> type = "image/jpeg";
> path = path("jpeg");
> } else if ("css".equals(ext)) {
> type = "text/css";
> path = path("css");
> } else if ("flash".equals(ext)) {
> type = "application/x-shockwave-flash";
> path = path("flash");
> } else if ("text".equals(ext)) {
> type = "text/plain";
> path = path("text");
> } else if ("js".equals(ext)) {
> type = "text/javascript";
> path = path("js");
> } else if ("png".equals(ext)) {
> type = "image/png";
> path = path("png");
> } else if ("html".equals(ext)) {
> type = "text/html";
> path = path("html");
> } else if ("applet".equals(ext)) {
> type = "application/x-java-applet";
> path = "classes" + File.separator + "com" + File.separator +
> "crackwillow" + File.separator + "applet";
> }
>
> String name = Classpath.WEB_INF + path + file;
>
> response.setContentType(type);
> response.setHeader("Cache-Control", "");
> response.setHeader("Pragma", "");
> response.setHeader("Expires", "");
> response.addHeader("Content-Disposition","filename=" + name);
>
> try {
> FileInputStream fis = new FileInputStream(name);
> BufferedInputStream bis = new BufferedInputStream(fis);
> byte[] bytes = new byte[bis.available()];
> OutputStream os = response.getOutputStream();
> bis.read(bytes);
> os.write(bytes);
> os.flush();
> os.close();
> } catch (IOException ioe) {
> StdOut.log(SiteConstant.ERROR_LOG,"ResourceAction: problem file
> is: " + name + "\n" + StackTrace.trace(ioe) + "\n" +
> ioe.getMessage());
> }
>
> return null;
> }
>
> private String path(String fileType) {
> return "resource" + File.separator + "content_type" +
> File.separator + fileType + File.separator;
> }
> } ///;-)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder
Posted by Dakota Jack <da...@gmail.com>.
<snip>
On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Just from a curiosity standpoint Jack... I've already decided it's not
> an approach I'd advocate, but I am interested to know how you serve
> things like graphics and stylesheets from under WEB-INF. I assume all
> your graphics are actually server by an Action (a trick I've pulled when
> serving images from a database), and I further assume your stylesheets
> aren't just linked in...
</snip>
<img src='resource.do?file=whatever.jpg'>
<link
href='resource.do?file=whatever.css'
rel='stylesheet'
type='text/css'>
You can also put this sort of Struts protocol into Flash ActionScript, etc.
To be complete on this list:
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file = request.getParameter("file");
String ext = file.substring(file.lastIndexOf('.') + 1);
String type = null;
String path = null;
if ("gif".equals(ext)) {
type = "image/gif";
path = path("gif");
} else if ("jpg".equals(ext)) {
type = "image/jpeg";
path = path("jpeg");
} else if ("css".equals(ext)) {
type = "text/css";
path = path("css");
} else if ("flash".equals(ext)) {
type = "application/x-shockwave-flash";
path = path("flash");
} else if ("text".equals(ext)) {
type = "text/plain";
path = path("text");
} else if ("js".equals(ext)) {
type = "text/javascript";
path = path("js");
} else if ("png".equals(ext)) {
type = "image/png";
path = path("png");
} else if ("html".equals(ext)) {
type = "text/html";
path = path("html");
} else if ("applet".equals(ext)) {
type = "application/x-java-applet";
path = "classes" + File.separator + "com" + File.separator +
"crackwillow" + File.separator + "applet";
}
String name = Classpath.WEB_INF + path + file;
response.setContentType(type);
response.setHeader("Cache-Control", "");
response.setHeader("Pragma", "");
response.setHeader("Expires", "");
response.addHeader("Content-Disposition","filename=" + name);
try {
FileInputStream fis = new FileInputStream(name);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStream os = response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,"ResourceAction: problem file
is: " + name + "\n" + StackTrace.trace(ioe) + "\n" +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return "resource" + File.separator + "content_type" +
File.separator + fileType + File.separator;
}
} ///;-)
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: JSP under /WEB-INF folder
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Just from a curiosity standpoint Jack... I've already decided it's not
an approach I'd advocate, but I am interested to know how you serve
things like graphics and stylesheets from under WEB-INF. I assume all
your graphics are actually server by an Action (a trick I've pulled when
serving images from a database), and I further assume your stylesheets
aren't just linked in...
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
> <snip>
> On Tue, 28 Dec 2004 13:57:33 -0500, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>I think his problem is probably linking to stylesheets and such...
>>Actually, now I have to ask you... if you put *everything* under
>>WEB-INF, I assume you are serving all graphics from a fronting web
>>server then? Otherwise, any document returned to the user that links
>>back to a resource under WEB-INF won't be reachable, which was the crux
>>of his problem as I understood it, that's why he was talking about
>>includes and such all over the place. But, if you really are serving
>>everything from there, how are you doing it? Just curious at this point :)
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>Dakota Jack wrote:
>>
>>>I don't know why you are saying that css and/or js must be placed
>>>directly under "WebRoot". Why do you? I can give you various
>>>solutions, once I find out what the problem is supposed to be. There
>>>is no issue, by the way, with putting your JSP files under WEB-INF.
>>>There are other ways to protect access, but this is, I think, a good
>>>one too.
>>>
>>>Jack
>
> </snip>
>
> Frank, are you still interested in this? I just noticed it.
>
> Jack
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org