Win a copy of Serverless Applications with Node.js this week in the NodeJS forum!

Tim Holloway

+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Linux
Long-time moderator for the Tomcat and JavaServer Faces forums. Designer and manager for the enterprise server farm, which runs VMs, a private cloud and a whole raft of Docker containers.
These days, doing a lot of IoT stuff with Arduinos and Raspberry Pi's.
Jacksonville, Florida USA
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tim Holloway

Well, it's ironic. The Ranch software automatically added the link. I know nothing about the product myself. But if if proves useful, so be it!
15 hours ago
Not storing session variables is a hallmark of ReST. The advantages of using ReST are twofold:

1. If every user requires "X" bytes of session data, then the amount of server memory required will increase linearly with the number of active sessions (users). By making "X" zero, there's no added memory per-user.

2. If you don't have server-side session data, then you can deploy many servers and use a load-balancer to dispatch work to whatever server is least used at the moment. A session either ties you to only one specific server or requires a back-end session-sharing infrastructure, which adds overhead.

So with ReST you can be elastic and add/remove servers from with relative impunity.

In the case of "serverless" apps, using a ReST-style architecture can make things even more elastic, since only the app needs to have multiple copies - you don't have to spin up servers and then provision them with apps.
It's common practice in Windows to create PDF's via a custom printer driver. So that part isn't really all that hard any more.

Getting HTML to print automatically is a bigger problem. For security reasons, web browsers generally have only limited ability to print web pages without someone pushing a button to approve the print, but different browsers have different options. Using a non-browser "print HTML" app may be a possibility, but I don't know what options are presently available there. Stuff like that is standard on Linux, but Linux comes with a whole raft of standard text utilities thanks, in part, to the fact that Unix was used a lot for text formatting in its early years. In Windows, you have to track down external apps. And often pay and get a license. And all too often, tolerate the app sending back details of what you're doing to its owners.
22 hours ago

Junilu Lacar wrote:Welcome to the Ranch!

If you meant this:

Classic example of why I'm so insistent that one always use braces on conditional/loop clauses. "If".
22 hours ago
Thank you, Slobodon, I was eagerly waiting to hear your reply.

It's true, of course. When I cobble up an app using Node Express, the app is itself a server in the sense that it listens on some designated port. As it happens, I have a very concrete example of such an app. I build an e-ink display with builtin WiFi that's stuck to my kitchen wall, and it polls a Node Express server periodically to obtain time, temperature, and weather forecast for the display. It, in turn queries downstream servers, one of which listens to remote radio weather sensors, and one of which is the National Weather Service. So it's basically an aggregator and reformatter for the display unit's benefit.

I think what we can say in brief, though is that a "server" is a generic service container like Apache, Tomcat, and the like, whereas a "serverless" app is self-contained. Like Node.js or Spring Boot. And thanks to the magic of reverse-proxying, you can set up a "server" (such as Apache, IIS or Nginx) to be the public face for serverless apps, even though the "server" doesn't contain those apps itself.
It sounds like what you probably need is a singleton object that you can obtain the Connection from (have it create the Connection the first time it is called).

For multi-user applications (Swing apps usually aren't), there are some Database Connection Pool libraries such as Apache dbcp that can be used to manage shared pools with multiple connections in them. Apps like Apache Tomcat use* this instead of inventing their own).

* Actually, up to about Tomcat 7, they used Apache dbcp, I think later versions switched to a different provider. Tomcat's connection pooler was always plug-replaceable though.
1 day ago
I put this in "Other Application Frameworks". It may not be the best forum for it, but it fits. Quartz is a framework for doing scheduled operations, much like the Unix "cron" service does.

I haven't worked with Quartz lately, but I believe it supports both one-shot tasks and regularly repeated tasks. You can keep the task schedule in persistent storage or just in-memory.

There's also a Spring Scheduling module and it supports Quartz.

I think the question was in how to get work done at a regularly-scheduled interval, and yes, Quartz is very much about that. You don't have to manually re-schedule repeated tasks, just set up the time/day(s) that it should do the task and Quartz will handle dispatching that task automatically.
1 day ago

Junilu Lacar wrote:

Tim Holloway wrote:or private scope if there's a chance for subclasses needing them.

You meant protected scope, right?

Oops. Yes!
1 day ago
1. You cannot literally stop someone from typing in any URL they want into their browser, but you can very definitely control what they get back when they do. The easiest and most secure way to do that is to use the Contrainer-Managed security system that's defined as part of the J2EE and JEE standards. This system allows you to assign security roles to users and to map which URLs are allowed access from which roles. So, for example, if I wanted to access http://superwebapp/app/supervisor/delete_account.jsp, but it required an "admin" or "manager" role and I wasn't assigned either of those roles, then the standard response would be a page with "HTTP 403 Forbidden" on it instead the delete_account page.

If you mean "browse urls like a filesystem". web servers are not file servers, so they don't do that anyway. The closest you would get would be if the webapp resource path was mapped to an index-display function and that's no problem to fix.

You might want to read this:

2. If your server runs Microsoft Windows, then security is sort of hit and miss, since any any given time, one and only one user "owns" the server and access to resources is set by the system administrator. On Unix-like systems like MacOS and Linux, which are true multi-user systems, then you can keep people from seeing anything inside of Tomcat including Tomcat itself simply by giving Tomcat its own private userid and security group. If you do that then only people authorized to login or change their user ids to be the Tomcat ID can access those files via the filesystem, and since webapp classes have to be located within the webapp's WAR WEB-INF/classes directory, they can't use HTTP to see them either (since Tomcat will never serve up the WEB-INF folder or directories/files under it). At that point the only way someone could snoop would be if they had root privileges, and not even then if you set up sufficiently nasty selinux controls.
1 day ago

Stephan van Hulst wrote:I don't think what I'm saying is contrary to your point Tim. Accessors are better than direct field access. I was saying that people shouldn't blindly add accessors for every field of an object, if the outside world doesn't need access to those properties at all.

Private properties. Yeah. No User-serviceable parts inside.

Although you might sometimes give them package-scope accessors for the benefit of unit-testing or private scope if there's a chance for subclasses needing them.
1 day ago
Also, something I feel obliged to bring out separately. DON'T mix direct-access and set/get functionality on the same object!

As I mentioned, JPA won't even allow it, but regardless, when you have both kinds of access, you can never really tell where things are being accessed or modified, meaning that you can end up with a real mess.

And finally, using get/set is good for deprecation and maintenance. One of the real turn-offs using Hungarian notation in C++ for me was that I'd often change the types and implementation of properties. For example, from a boolean to an integer to an enumeration and so forth. In which case the very name of the variable became a lie. With access functions, you can outsource a member property and the move is transparent to the callers of the "get" method. Or, delete it entirely and throw an exception on the accessor if the property is no longer used without making compiles fail - just throw an Exception if someone tries to use it anyway (and mark the method as @deprecated. This kind of stuff is invaluable when you have to do emergency fixes and is one of the reasons I dropped Microsoft in favor of Java. I'm in a bad enough mood when I get dragged into work at 3am to begin with!
2 days ago

Stephan van Hulst wrote:
You mean, almost never, unless you meant "always access fields through methods, rather than directly". Simple getters and setters don't really add a lot of behavior to a class. Getters usually are fine, but only add them when you need them.

I'm going to be contrary again. This goes all the way back to my C++ days.

There are two things that explicit set/get methods offer over direct property access.

First, should it be necessary to attach additional functionality to the set/get process, you need a method. In almost all cases, that's something that you shouldn't do - set/get should be both idempotent as well as lacking in side functionality, but there are exceptions to every rule. And, of course, on "set" methods, you might want to assert only certain values as valid "set" values.

The second is a bit shakier. These days, debuggers can be configured to throw breakpoints on both set and get of variables. In less civilized times, that wasn't so, and thus the advantage of using a method, since you could set a code breakpoint.

However, even today you don't always have a debugger when you need it. You don't run production systems under a debugger, you might want to do paranoid value checking in critical code, stuff like that. You might be going crazy because you know that a value's being used, but you don't know what the accessor is, and without a debugger, only a manually-generated stack trace can help.

So, as a rule, I very much recommend avoiding direct access in favor of get/set. Many IDEs can automate the grunt work of creating the code, so it's minimal work and maximal flexibility. And, give modern optimizers, not likely to cost you anything in run-time overhead over direct access.

Incidentally, the Java Persistence Architecture (JPA) offers 2 different ways to access Entity properties - either via direct (field) access or via property method (get/set) access. It's got to be all one or all the other, however, since JPA re-works the access mechanisms internally.

2 days ago
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.
3 days ago

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.
3 days ago
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.
3 days ago