Scott Dunbar

Ranch Hand
+ Follow
since Sep 23, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Scott Dunbar

You will have to include the J2EE jars in your classpath somehow. You can start on the command line with something like:

javac -classpath ,;/path/to/j2ee/jar/file.jar HelloWorldServlet.java

but soon you'll want more and more on the classpath. If you're just experimenting then you can continue with the command line. Otherwise you may want to consider a build tool such as ant to help you manage your build environment easier.
17 years ago
This isn't really Java networking. The first problem you have is that file: expects forward slashes only after the colon like file:/. Next, I think (and this I can't test right now I'm afraid) that you're better off using forward slashes for all of the slashes. Windows will translate it correctly.
17 years ago
You will have to go native to find this. It looks like there are many ways to do this depending on your chosen native language. Java would have no facility to do this.
17 years ago
I would go with what you're familiar with and what you can maintain. If that is Java then great. If that is PHP then great. If that is CGI and Perl then, well, I guess that is great too though we did start a new millenium a while back

But the key isn't that Java is better than PHP is better than CGI. The key is to do what you know. If you're going to be writing and maintaining the site then you are going to be much better off doing something you know. Trying to learn PHP while developing or maintaining a large site will just take longer.

As far as which app server - again, go with what you know. 5k hits/month is only about 7 hits per hour - not exactly big time. I've built sites with Tomcat that handle hundreds of times that volume so that isn't too much of an issue.

Database - same thing. Do you know something like PostgreSQL? Fine, use that. You are unlikely to want a commercial DB here as because of the cost but pick something you know.
17 years ago
Do a "which java" to see which java command the shell thinks it is executing.
17 years ago
I would look at using Apache Commons HttpClient to do this. It has support for SSL along with different login methods.
17 years ago

Originally posted by Keith Lynn:
What about creating an instance of Throwable and looking at the stack trace?



To expand a bit on what Keith said - if you're on 1.4 and above you can use Throwable.getStackTrace() (can't directly link to method in this forum) to get an array of StackTraceElement entries. You could then examine them to see where you came from.
17 years ago
You would have to "go native" to do this. Java itself does not include a way to do this because doing it in Windows vs. Unix is bad enough. Now toss in AS/400's and VMS based systems and the methods and permission issues are very different.
[ June 06, 2006: Message edited by: Scott Dunbar ]
17 years ago
Generally when accessing a JSP I would expect a JSP extension on the URL. Something like "http://localhost:8080/helloworld.jsp" or the like. The exception to this is when the JSP is named index.jsp - Tomcat uses that name as a default when only the directory is specified.

To use Eclipse with Tomcat you'll have to start Tomcat with the JPDA. You will want to export the environment variables JPDA_ADDRESS=8000 and JPDA_TRANSPORT=dt_socket (those are the defaults) to enable this. Then, in Eclipse you can debug with the "remote application" method. You'll want to make sure your source and what Tomcat is running are the same thing.

I don't feel that this is a permission problem. Start with getting Tomcat working for a simple JSP page first. Then you should be able to debug more. A warning though - JSP's are very difficult to debug if you are putting Java code in them. If you call a bean or some other code from a JSP that is easy. But if you want to walk through a scriplet in a JSP that can be difficult. The reason is that a JSP is translated into a servlet and then compiled. The translation generates a ton more code than your JSP has. Once your JSP is working take a look in the Tomcat work directory. That contains what Tomcat did to run the JSP.
17 years ago
web.xml, like many of the other XML based config files must have the tags in a particular order. In your case all of the servlet tags must come first and then the servlet-mapping tags. You've got them mixed together and that isn't correct.
17 years ago
I'm not quite following you. In a HttpServlet has methods that are separated by HTTP method - a doPost() for HTTP POST requests, a doGet() for HTTP GET requests and so on.

As far as where you pull the data out of the HttpServletRequest that is really up to you. Back in the "old days" I just did it in the doGet()/doPost() methods by hand using getParameter() (which I can't link to because of the prehistoric age of the software running Javaranch ). Newer applications may benefit from using something like Java server faces or Struts. A part of these technologies is to make HTML form processing much easier.
17 years ago
Pretty much what it says. If I have a servlet in an app server then, even if there are 1000 users accessing the servlet at one time, only one instance is ever created - like with a new() statement.

All of the user requests are handled by a thread for that user. This is why it is very important to make sure that any data within a servlet is thread safe even though you never create or manage any threads.
17 years ago
I haven't tested the code but you should be able to do something like:



Edit - now that I re-read this I may not fully understand your question - what do you mean "using bit"
[ May 04, 2006: Message edited by: Scott Dunbar ]
17 years ago
You've got a configuration issue of some sort. Do you have the datasource defined in your server.xml? It will be in a Resource tag, perhaps embedded within a Context tag.
17 years ago
Weblogic clustering is handled in much the same way as other app servers like Tomcat. Basically a server of some sort sits in front of a cluster of "real" servers and distributes work based on a variety of parameters. The server in front can be something like Apache, IIS or another instance of WLS.

The BEA clustering documentation is very complete.

I think you'd be well off to do something like this. It sounds like it would be easier to maintain than what you're doing.
17 years ago