Tim Holloway

Actually, you don't "call" servlets. You make URL requests to the webapp server. The server then dissects the request, routes it, and eventually calls methods in the appropriate servlet class. I know it sounds pedantic, but how you talk influences how you think. Servlets aren't called, they're invoked.

And you generally should NOT have a "login servlet". The technical term for apps that do that is "hacked". Use the JEE built-in security system whenever possible. It blocks many attacks before they can get routed to, much less exploit, a webapp.

salvin francis wrote:I think any unidentified flying object is a UFO this can include any streak of light outside the space station. They may not be saucer shaped.

Yes, UFO's have been reported as discs, balls, cigars, and other shapes. Although English being what it is, trust some people to use the word "saucer" anyway.

Anyway, found another way to help the Earth today: Waste less food.

A lot of resources go into producing food, and much of what's produced gets wasted. A report by NPR indicated that delivered meals can actually be more efficient than buying stuff yourself at the market, in large part because people buy "economy" packages and end up throwing out stuff when it doesn't all get used up in time.

Of course, they didn't say anything about those of us who pick out and discard the broccoli.

UFO - Unidentified Flying Object - is the highbrow term. "Flying Saucer" is the slang term. Or in Italian, disco volante. I think they like Fliegenplatte in German, but memory is fuzzy and the dictionary isn't close enough.

Oh wait. We have a fly and saucer today.

Applicant rejected. Didn't bother to read basic instructions on how to create a Coderanch account name. Sloppy worker.

D.J. Quavern wrote:Haha I had to google this one. I am not English or American, so my first reaction was, "of course I don't litter, I'm not a cat!".

Ok, noted. I won't litter, cat or human wise.

Why is there a small ufo flying in front of earth and the moose?

I think you mean the fly that buzzes around the moose head.

Some Earth Day suggestions:

1. Turn off excess lighting (doesn't help much, but every little bit)

2. Adjust the thermostat to reduce the amount of times the heat/cooling comes on.

3. Avoid driving if you can walk or bicycle

4. Don't litter. Better yet, pick up some of the litter that all the other   s have already dropped

5. Plant a tree. If you can't plant a tree, plant something is a pot. Anything to keep the world cooler and capture CO2, no matter how miniscule. Besides, it helps reduce stress.

6. Shop with an eye towards the environment. Look for stull that lasts, can be repaired, doesn't produce a lot of waste or waste packaging, can be recycled easily. These are sometimes conflicting goals, and sometimes illogical, like when repairing something pollutes more than replacing it, but be mindful, anyway.

7. Be sparing with chemicals.

What can I say. Use some common sense. Don't make a mess of things, try to leave the planet more habitable than you found it, because generations of ignorant people have a lot of damage that needs undoing and the current generation of (often willfully) ignorant people are going to do stupid things, including deliberately trying to make the place only habitable by rats and cockroaches. Make every day a bit of Earth Day. Despite Elon Musk, we're not likely to be able to flee to Mars if we trash this planet, and only a complete idiot thinks that the Earth is too big to make a ruin considering the leverage that modern technology can bring to bear and the amplifying effects of adverse catalytic reactions when we upset the balance of Nature.

And finally, don't buy into the propaganda that a habitable Earth is less important than jobs or the economy. If you're marooned in a wasteland, it doesn't matter if you have a job, and the "job creators" (who outsourced and automated rather than actually creating) aren't going to let you into their little climate-controlled bubble shelters.

Read the Tomcat instructions. There's a management webapp, that's installed by default in many Tomcat distros. There are management web services. There's MBeans, I believe. And several other APIs, depending on which version and configuration of Tomcat you're using.

Stephan van Hulst wrote:I'm afraid there's not a single base implementation that will work for all. Some pairs need to be immutable. Others don't. Some may allow null elements and others need to reject them. Some pairs need to be thread-safe. Some might need to be Serializable or Cloneable.

Maybe I'm thinking Java can do abstractions better than it actually can, but it seems to me that a conceptual Abstract Pair is not a class that should be worrying about any of these. They're all things that should be in derived subclasses or even in derived abstract subclasses. A Pair basically needs to standardize the template for construction and define left and right accesssors (CAR and CDR, if you're into LiSP). That's it. Java's Collection classes have dealt with these problems before and managed to resolve most of them. And by definition, all Tuples are collections.

Stephan van Hulst wrote:
You can't provide base implementations for equals() and hashCode(), and you can't implement Comparable, because then you would not be able to override those methods in sub-types without breaking the general contract.

I can but repeat the previous statement and ask for examples of why it isn't possible.

Stephan van Hulst wrote:
The only things that a widely usable Pair class could implement are the toString() method and the fields that hold the elements, and the fields must have protected access so that sub-classes can implement accessors. The accessors can not be declared in the abstract base class, because then you're once again stuck with meaningless identifiers such as item1() and item2().

And here, I'll take the opposite view. That toString() isn't something that a conceptual Pair can safely implement. Depending on needs, it might simply defer to Object.toString, Or, regardless of whether the pair components are stored as named members or in an array or something weirder, there are a ton of ways to output invocations on their own toString methods, plus in how you'd separate the values (command, semi/colons, pipes. etc., etc.). That's best done by more specific sub-classes of the general case.

Stephan van Hulst wrote:
A general purpose Tuple class would be even worse. What information could such a class possibly contain? The only thing I can think of is the size of the tuple. Either you don't know what kind of tuple you're dealing with and the only thing you can do with it is get the size, or you do know what kind of tuple you're dealing with and the size is useless.

Tell that to the Perl and Python people, who throw around indeterminate-sized tuples right and left. On the contrary, if you know something is a Tuple, you know it's an ordered collection. Very similar to, if not identical to the equally abstract concept of the Java List. You know that it's sequentially enumerable in an idempotent way. If it's the base for Pair or Triple, you can convert from the general to the specific or vice versa in a simpler and safer way. And you remove some of the "magic" that special-case implementations carries, allowing the whole project to be viewed in a more abstract and flexible way.

Sei ton wrote:
So on the log file i should get any request if used that is referred to the name of the War/Webapp deployed?

No, I don't think so. I believe that this Valve is invoked before the URL gets sent to a webapp, so the WAR isn't directly known yet.

But since the context path part of the URL does determine which WAR will ultimately be used, you can record the incoming URL context paths and use them to determine what WARs are being invoked.

You can determine what context path has been assigned to which WAR(s) by looking at how the WARs were deployed into Tomcat. This can be done by manual inspection, but with that many WARs, I'd use one of the Tomcat management interfaces to automate the process of generating the context-to-WAR map.

I'm going to swim against the stream and argue that having a language-defined abstract template for tuples would be a good thing. Specifically, it would probably be desirable to have an abstract Tuple class, an abstract Pair class and maybe even an abstract Triple class (all subclasses of Tuple).

There are 3 reasons why I advocate this.

First, having something in the core of a language enviroment definition draws attention to the concept. You don't have to explain what a Pair is to the unlearned if it's in the JavaDocs (well, you do,  but at least you can growl at them). You can talk abstract design in terms of concretely-realizable objects.

Secondly, it allows for a standard base implementation. Instead of a mish-mash of individual Pair classes where some contain 2-element arrays, some contain unique members and the member functions can vary per-class, you have a common standard. Less to worry about when designing, less to argue about when you're ordered to implement.

And finally, simply having a common base class has its own advantages. Sure, a HashPair might normally be something buried in the innards of HashMap, but sometimes you might want to work with it as an abstract Pair - after all, you can have one returned to you via the standard HashMap methods. With free-for-all pair class implementations, you have to spend time coding -- and debugging -- stuff to access the pair's elements and possibly to forward the pair to some unspecified distant mechanism. With a common abstract base class for Pair, you are most likely to have to do some casting at worst. And while I really, really hate casting, thanks to years in the C/C++ realm, I still prefer it to uglier alternatives.


As for popular opinion, yeah. Just because more people get their news from the Ministry of Truth, that doesn't mean that MiniTrue is actually telling the truth, the whole truth, and nothing but the truth.

If a WAR is deployed in Tomcat, it is "used". What you really need to know is how many webapps are being used. A webapp is not the same thing as a WAR, since you can use the same WAR for multiple instances of a webapp. You might do that, for example, if you are running a multi-client webserver and you want to keep the clients' usage of the webapps totally isolated.

It's fairly easy to track what webapps are being used. Every webapp is deployed with a context path, and by activating the Tomcat request logging Valve, you can see the URLs as they come in and examine the logs for context paths. If a WAR is not being used, the context path(s) it was deployed under will see no URL requests.

This isn't foolproof. Some apps might only be used at month- or year- end. Some might be used even more infrequently. So the best approach would be to setup a secondary server, move the unreferenced webapps over there and leave the primary server for the active stuff.

You might also want to measure some stats on those apps and do some load balancing while you're at it. There's no law that says a single instance of a Tomcat server has to contain everything. You can balance by app and/or balance by Tomcat cluster.

Process management is just about the polar opposite of "write once, run anywhere". Java is one of the worst language platforms I can think of to do that in, and it shows in that you have to use a rathole interface to even try.

Bill Platt wrote:
My choice of using "implicit parameter is based on what my textbook was calling it (see screenshot below). I am willing to admit that the textbook may not be 100% correct in the terminology that it uses, but I tend to go with what I have been given and expand from there.

Actually, I changed my opinion when later posts showed why it acts more like a parameter than a member. My ego is sufficiently strong enough to allow correction.

A null result from getRemoteUser or getUserPrincipal indicates that the remote user is not logged in.

A login will not occur unless the remote user attempts to access a URL designated as protected in web.xml or if server logic invokes the login() method (which was added somewhere around JEE 5 or 6). You cannot simply steer the user to a page designated as loginPage in web.xml - any direct attempt to access that page will not have had the proper login environment set up by the server before it was displayed, and the login code is part of the server, not the web application.

Finally, be very careful using "/*" as a protected URL pattern. If the login page contains references to protected URLs (for example, images, javascript files and the like), then you end up with a vicious cycle because the login page cannot be fully displayed until you're already logged in, since attempting to access image URLs etc. will itself trigger a login.

I thought I'd answered this question already.

It is very NOT SAFE for a remote client to access a database via the open Internet. That's what was at the root of the infamous "SQL Slammer" exploit for Microsoft Windows/SQL Server where cashpoint (ATM) machines got hacked right and left - in addition to lots of other damage.

It's more likely that your have a cloud host with a MySQL server available and in that case, apps that also run in that same cloud are OK, since traffic between client and database does not occur over the open Internet - just the cloud LAN (which is often using a VPN isolated from other cloud clients).