Re: jsp:include...

I've had a problem with some request dispatcher implementations not passing parameters properly to the underlying page. You may find it necessary to do it with attributes instead set by param tags inside the jsp:include tags. Michael -Original Message- From: A mailing list about Java

Re: Blank lines on JSP

The problem is that everything outside of the directives is sent to the browser - your directives are separated by newline characters: %@ page import="java.lang.*" %\n %@ page import="java.util.*" %\n %@ page import="java.io.*" %\n \n html\n body\n [etc..] If you really want to get rid of the

Re: Query regarding processing a form

Have you tried this? String[] request.getParameterValues(String parameterName) Michael -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of Narayanaswamy, Kumaran (CTS) Sent: Wednesday, August 30, 2000 3:37

Re: Using the include file tag

The %@ include % directive is processed at JSP load time, reading in the contents of the target file and dropping it inline into the body of the JSP. (You can't specify this file name dynamically because this would effectively change the source code of the JSP file, requiring recompilation.) The

Re: highly scalable network server app

If you're going to be doing something along these lines, I highly recommend that you read O'Reilly's "Java Threads" (Oaks Wong). It provides a very comprehensive grounding in threading issues in Java, and - given the nature of your questions - will probably give you more insight into whether

Re: merging technologies

No, that works fine. We had very good results with the WebLogic JDBC drivers for MSSQL 7.0. Michael -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of paresh Sent: Wednesday, August 30, 2000 12:46 PM To:

Re: multiple session instance

Yes, this can happen, and it depends on the browser and in some cases the settings of the browser. I don't recall which version of IE it was, but we found at one point that when it was set to "each browser runs in a different process" we'd get each browser associated with a unique session.

Re: Taglibs - too complicated?

I agree with you completely, Dan. In our last project our servlets were passing beans to JSP pages, and in some of these the simplest way to get data out of them was a few lines of Java code in the JSP. I'm not convinced that the complete separation of HTML and Java is a particularly worthy

Re: Multithreading in servlets.

AFAIK, thread creation is fairly expensive, so a thread pool might be a good idea, or you're going to run into serious problems when you try to scale up to many concurrent requests. 50 threads sounds like a lot. As I recall the Java spec doesn't require the thread scheduler to give equal

Re: Docs explaining what happens under the hood?

Scalability is difficult to achieve The latest versions of the servlet spec specify that, unless a servlet is marked SingleThreadModel, the servlet container should create only one instance of a servlet (or a JSP page once it's compiled as a servlet). Many servlet containers do this now,

Re: WebObjects supplies Model-View-Controller (MVC) Development Today

Some of my colleages have used WebObjects, and I've heard mixed things about it. Once you overcome its learning curve, it's apparently a very rapid way to develop fairly sophisticated functionality. I understand that it consists of a fairly mature O/R persistence layer (EOF) along with a

Re: Model 2: Persistence Layer?

It does seem like a pain in the ass, but your existing model is subject to the same problems, isn't it? You're having to make changes in two places when you add properties (Datastore.saveThingy() being the second place) and your existing Datastore is Oracle-specific from the sounds of things.

Re: Calling servlet

I'm not sure, but off the top of my head it sounds like there should be a better way of doing what you're trying to do. What are you trying to do? Michael -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of

Re: Apache to JRun

Strictly speaking, no, you don't. The JWS is there to serve up the web-accessible administrative interface for JRun. The images will be served off your web server as normal. Have you checked the URL? In IE, you can right-click on an image and get its properties to see the full URL the browser

Re: ASP/MTS/COM vs JSP/EJB

I suggest that it's a bad idea to choose between these technologies on this basis alone. Performance benchmarks are so wildly sensitive to even small changes that they're likely to be almost completely inapplicable to the project that you're designing. Even if you choose the "faster"