Re: MVC/XML Framework Comments please
Tim, that sounds v.interesting. Forgive my ignorance but what toolkit are you using and what do you mean by precompile the XSL pages? Thanks, Trevor On Thu, 26 Apr 2001, Tim Endres wrote: We do exactly what you propose. A servlet drives lightweight commands. The commands get XML trees containing the HttpServletRequest information, and fill in a subtree with the XML results. This tree is fed into XSLT and the resulting HTML is sent down the wire. I prefer it over JSP by miles. We precompile the XSL pages, so we get really good performance. And the separation of content/presentation could not be better. tim. SNIP
Re: Paged search results
On Wed, 28 Mar 2001, Gary Shea wrote: It seems to me that if you have multiple browsers open and they're sharing an application like Netscape does, they will all have the same session unless you're using URL rewriting. My experience with Netscape and Konqueror (sorry I don't know anything about IE) is that once a cookie is established on any one browser, all the rest will begin submitting it. As a result, if you're using cookie-based sessions, then your browsers are all in the same session. If you're using URL rewriting they'll all have independent sessions. In IE (perhaps only on NT, dunno) you can configure it so that all browser windows are in a separate process space. This means that non-persistent cookies are *not* shared between windows AFAIK. Trevor
Re: Cookie creation bug (?) for servlet-including jsp files
On Tue, 27 Mar 2001, Ostroff, Mike wrote: I am working on a web-app (powered by Orion 1.4.5) that uses a jsp page with several Java servlets included within it that do the more complex computations. The jsp file has lines like: "jsp:include page="/servlet/ExampleServlet" flush="true" /" that load the servlets. This does a request on the servlet and inserts the HTML they return at the include point. The problem is that in one of the servlets I am trying to create some cookies using the standard HttpServletResponse.addCookie(new Cookie(name, val)) code. If I run the servlet directly without embedding do you think this might have something to do with the output of the JSP being committed (and thus the HTTP headers already being sent) by the time you do the jsp include of your servlet? it in a jsp file then the cookies get created just fine. But when I try to execute the servlet from within the jsp file, then the cookies do not get created, even though I know that the addCookie() method is being reached and executed. This same jsp and servlet combination worked and created the cookies without problems when run under Allaire's JRun 2.3. perhaps JRUN has a bigger output buffer for jsp's than orion? Trevor Is this an Orion bug? And can anyone think of a work around that won't involve massive changes to how the code is organized? - Mike
Re: In Orion, are tag handler instances reused or reinstantiated?
Funny, I never managed to get it to *not* re-use tags (haven't rev'd up to latest release tho) regardless of the jsp.reuse.tags setting... Trevor On Thu, 1 Mar 2001, Jonathan James wrote: Actually it's configurable. Just add "-Djsp.reuse.tags=[false|true]" to your command line when you launch the server. Jonathan - Original Message - From: "Randahl Fink Isaksen" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, March 01, 2001 2:47 AM Subject: RE: In Orion, are tag handler instances reused or reinstantiated? Experience tells me they are reused in Orion. If I have an optional tag attribute on a tag and the tag is used multiple times on a page I have found out that I need to make sure that any contents set in the optional attribute must be cleared manually by me, or I will get whatever contents was set by a previous invokation of the tag. Yours Randahl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Blacha, Bart Sent: 28. februar 2001 19:27 To: Orion-Interest Subject: In Orion, are tag handler instances reused or reinstantiated? We are trying to figure out if tag handler objects are re-used, or instantiated-and-destroyed at every request. This is obviously important for performance reasons. There is conflicting information in JSP spec and on JGuru (see references below). So maybe it's an implementation-specific issue. Which brings me to the question: What does Orion do with tag handler instances? Reuse or reinstantiate them? JSP spec 1.1, paragraph 5.4.7: At execution time the implementation of a JSP page will use an available Tag instance with the appropriate prefix and name that is not being used, initialize it, and then follow the protocol described below. Afterwards, it will release the instance and make it available for further use. This approach reduces the number of instances that are needed at a time. http://www.jguru.com/jguru/faq/view.jsp?EID=337618 Question We want to make sure that our JSP development efforts are thread-safe. Is it possible that two threads will access one instance of a JSP custom tag handler concurrently? No it is not possible. There is a defined lifecycle of a custom tag, and during this lifecycle, that instance of the tag will only get called once. Hopefully in newer implementations of JSP engines, the actual tag object will not get reinstantiated each time (as this negatively affects performance), but at least during it's use, it will be thread safe. -- Bart Blacha, Software Developer NetPerceptions Inc. (512) 349-5622 [EMAIL PROTECTED]
Re: Downloading a file via a Servlet
I tend to put the filename as pathinfo - i.e. /myservlet/made-up-name.pdf?param1=yadda If memory serves me, you need to change the servlet mapping to be /myservlet/* for this to work. HTH, Trevor "Van Dooren, Damian" wrote: I was wondering if anyone knew of a way to get around the following situation: We have a servlet that sends back PDFs that are stored in a database. Everything seems to work great but the one oddity/issue that I would like to solve if possible is. When someone wants to save the PDF, instead of viewing, it wants to save the PDF as the name of the servlet. I understand why this is the case, but I wonder if there is anything, perhaps in the content header, that I could set the actual name of the file. Any suggestions would be greatly appreciated. - Damian Van Dooren Information Technology The Investment Centre (519) 672-4389 x718
Re: Re: Port forwarding
ACK I meant host="[ALL]" not port=[ALL] !!! Very tired from skiboarding all day... On Wed, 24 Jan 2001 [EMAIL PROTECTED] wrote: I'm not quite sure what you are saying, but we are getting somewhere...I got orion to bind to port 10080...I have it in 2 places default-web-site.xml and mysite.xml. both with hardcoded IP and port. It is responding as that ip/port and not conflicting with other apache and orion. I've never heard of port="[ALL]".sounds pretty scary to me. it binds to all ports? What do you have in default vs. your virtual hosts? my bad, sorry. It's the "hardcoded ip" that is causing your grief (if your setup looks anything like mine). try host="[ALL]" and port="10080" the frontend and virtual host stuff is only required for redirects and something else which escapes me. Trevor
Re: Port forwarding
Hey David, I have it running on a 4ip host where each interface (ip) is a different web site which is what I think you want to do right? If that's the case then I did exactly the same thing as you wrt the ipchains command. The problem I ran into is that if I configured each site to only listen on the relevant interface (port= in web-site tag) it didn't work. I had to say port="[ALL]". So I gave each site (interface) a different port 1024 and did the ipchains for each, just as you have done. I also hadded a virutal-hosts entry and a frontend tag in the web-site xml for each site - both were important but I can't remember what failed if you didn't include them. Finally I used ipchains to refuse direct connnections to the ports 1024 that the sites were really using - just being picky I guess. I hope that helps. Trevor On Mon, 22 Jan 2001, David Morton wrote: Has anybody gotten port-forwarding to work? I want orion to run as non-root user on Linux.I did see: http://www.orionsupport.com/articles/unixprocess.html The following is an excerpt: IP Chains (ipfw) IP Chains is a program that comes with recent versions of Linux that uses the ipfw library to specify rules for TCP/IP packets. For information about using it, refer to the howto. Here's a simple rule to tell all incoming TCP packets destined for port 80 to be forwarded to port 10080: [root@myhost]$ ipchains -A input --destination-port 80 -p tcp -j REDIRECT 10080 Warning: Use ipchains at own risk... You are recommended to read the documentation first, and have the machine in easy reach. This command needs to be executed each time the system is booted, so you may want to place it in a startup file somewhere. I tried ipchains rule with one change: ipchains -A input -d 192.168.0.4 80 -p tcp -j REDIRECT 10080 it didn't work. any suggestions? If anyone has working on one ip only (on a machine that has multiple ips like mine)...please send output of 'ipchains -L'...and any other ipmasqadm table output... Thanks David
