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.
--
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
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
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
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
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
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
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
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
=
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
snip
On Sun, 30 Jan 2005 14:11:24 -0500, Frank W. Zammetti
[EMAIL PROTECTED] 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
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
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
snip
On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
[EMAIL PROTECTED] 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
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
snip
On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti
[EMAIL PROTECTED] 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
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
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
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
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
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
snip
On Tue, 28 Dec 2004 13:57:33 -0500, Frank W. Zammetti
[EMAIL PROTECTED] 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
Hi Hassan ,
yes, the .js and .css are externally-accessible, but the .jsp aren't
so my jsp can't refer to those .js and .css
and after viewing this thread, I think I would take QM approche but u
mentioned I can put all jsp into one folder and protect it. How? Is it
a web container level or
Koon Yue Lam wrote:
yes, the .js and .css are externally-accessible, but the .jsp aren't
so my jsp can't refer to those .js and .css
Of course they can; most of my sites work this way.
Your JSP is sending HTML to *the client UA* with the URL of the CSS
and JavaScript files -- it's the UA that
Quoting Koon Yue Lam [EMAIL PROTECTED]:
Hi Hassan ,
yes, the .js and .css are externally-accessible, but the .jsp aren't
so my jsp can't refer to those .js and .css
Huh? Why would you say that? Let's say I have the following structure...
myapp
/assets
/style/my.css
Quoting Hassan Schroeder [EMAIL PROTECTED]:
Koon Yue Lam wrote:
yes, the .js and .css are externally-accessible, but the .jsp aren't
so my jsp can't refer to those .js and .css
Of course they can; most of my sites work this way.
Your JSP is sending HTML to *the client UA* with the
Laba diena.
Dkojame, kad mums parate.
Js atsista inut isaugota ms duomen bazje.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks for all the reply, I will try it out tonight and let u all know
the result ^^
Regards
On Tue, 28 Dec 2004 18:52:37 +0200 (EET), [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Laba diena.
Dkojame, kad mums parate.
Js atsista inut isaugota ms duomen bazje.
ok, it is really strange that I need to specify full path
/myApp/js/myJS.js
rather then just
js/myJS.js
but if I use full path , everything works fine
I am using Tomcat 5.028 with Struts 1.1
thanks for all the help
Regards
On Wed, 29 Dec 2004 01:08:31 +0800, Koon Yue Lam [EMAIL PROTECTED]
From: Koon Yue Lam [EMAIL PROTECTED]
ok, it is really strange that I need to specify full path
/myApp/js/myJS.js
rather then just
js/myJS.js
You shouldn't. Or, at least... I don't. It's better not to embed the name
of the webapp if you don't have to-- I run the same code under 3 different
I put EVERYTHING under WEB-INF except one index.jsp file, which merely
passes the first incoming request to the secret stash! By
everything I mean everything!
Jack
On Sun, 26 Dec 2004 22:31:32 +0800, Koon Yue Lam [EMAIL PROTECTED] wrote:
Hi, I want to protect my JSP from direct access, so
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
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
Quoting Koon Yue Lam [EMAIL PROTECTED]:
ok, it is really strange that I need to specify full path
/myApp/js/myJS.js
rather then just
js/myJS.js
but if I use full path , everything works fine
I am using Tomcat 5.028 with Struts 1.1
The server does not matter. The application framework
Your problem is almost certainly the base tag. Why do you have it
there? The href in base will skew the way the browser looks at relative
paths and make it so that they are not resolved to the URL in the location
bar of the browser, but to the URL in the href of the base tag. Besides,
the
Yay! That's what I was hoping to hear :-)
Jake
At 02:10 PM 12/29/2004 +0800, Koon Yue Lam wrote:
YES !!! Everything works fine now after remove the base tag and
correct the typo !!
I want to give my deepest thanks to you for helping me out with such
great effort
Regards
Hi, I want to protect my JSP from direct access, so they can only
access by Struts action.
but
If I want to include some Javascript or CSS to a JSP, I can't !
Because .js and .css needed to place directly under WebRoot
My solution is to use jps:include to include all those Javascript
and CSS
On Sun, Dec 26, 2004 at 10:31:32PM +0800, Koon Yue Lam wrote:
: Hi, I want to protect my JSP from direct access, so they can only
: access by Struts action.
So far, so good.
First, you don't want to put your JSPs under WEB-INF (as mentioned in
your subject line). That makes your webapp less
Koon Yue Lam wrote:
Hi, I want to protect my JSP from direct access, so they can only
access by Struts action.
but
If I want to include some Javascript or CSS to a JSP, I can't !
Because .js and .css needed to place directly under WebRoot
I'm afraid I don't understand the issue.
If you're
39 matches
Mail list logo
