Tim Holloway

Roman Vilensky wrote:
Right. I was mistaken about the order in which these happen. I thought it was assign old value, then increment, but it is the other way around.

That's the difference between post-increment (i++) and pre-increment (++i), as Liutauras pointed out. I'm repeating him, just using the formal names of those operators.

pre/post increment/decrement have a fairly high operator precedence - as is common with unary operators. Assignment has a very low operator precedence. If it didn't a lot of equations wouldn't, er, "equate".

If you can make the JAR execute properly from the command line (Windows or Linux) with the command "java -jar myjarname.jar", then the JAR is as executable as it gets.

To make it possible to execute by double-clicking on an JAR icon, each and every computer that the JAR is installed on must have its default desktop preferences overridden. Because, as Matt said, the default action when you click on a JAR file's icon is that the OS is going to look for a ZIP display application and open the JAR with that application and not with the Java runtime (JVM).

Since that's a rather extreme measure, a lot of executable-JAR apps are distributed with an accompanying shell script(s). These scripts are simple Windows .BAT files and Unix shell scripts whose sole action is to launch the JAR using a command format like the one I just gave. Maybe they'll also select which installed JVM on the user's computer to run under, but that's generally about it, unless it's a really complex app like the Tomcat server.

Since the default action on most user's GUI desktops when they click on an icon representing a shell script is to run that script, no overriding of the user's desktop settings is needed. Note, however, that on Unix/Linux/MacOS systems, a script won't execute from the GUI unless its "x" (executable) file attribute is set.

Welcome to the Ranch, Basil!

I've added code tags to make your examples more readable. The Code button is part of the Ranch message editor, incidentally.

Your discussion is so long and complicated that I would have to print it out and read it carefully to fully understand it, and since I don't get paid for this, I'll give you the next best thing which is to work back from what you're apparently trying to do and explain it that way.

Enterprise Java supports JDBC Connection Pools. Connection Pools allow efficient use of database resources by keeping previously-created instances of Connection objects and handing them out on demand. The webapp(s) using that pool would acquire a Connection, use it to do database operations and then return it to the pool as soon as possible so that other users could make use of that Connection. Creating a Connection is expensive. Re-using an existing one is much more efficient.

PGSimpleDataSource is not a good choice here. It doesn't support pooling. You should just use the standard Tomcat dbcp connection pool datasource instead.

A common convention for a datasource is to define it to Tomcat with a JNDI relative name of something like "jdbc/mydata". Doesn't have to be done that way, but since Tomcat can hold lots of different types of things in its JNDI directories, it's a bit self-documenting. In your example, I see you used "jdbc/postgres". That's fine.

So in your webapp, to get a connection, you'd do a JNDI lookup to get the pool you defined under the name jdbc/postgres, cast it to a DataSource, then use the DataSource getConnection() method to get your Connection to the PostgreSQL database. That's all you need. All the extra stuff you covered is unnecessary. Again, once the app is done, return (close) the Connection as soon as possible and NEVER hold onto it between requests.

The connection pool isn't owned by the webapp. It's created and owned by Tomcat. It's possible, though not common to share a single pool across multiple webapps, since the Connections are used in isolation from each other even within a single webapp. That's why you need JNDI to find it for you.

Connection pools are the recommended way to access databases in almost all cases. It's generally not very efficient for a webapp to create its own Connections. Plus you end up having to hard-code things like user IDs, passwords, and connection URLs right into the WAR, which is a Bad Thing. Not only would it require making a  separate copy of the WAR for testing and production (I HOPE you don't test using production databases!), it also makes it much easier for unauthorized people to find out userids/passwords.

X2Go is to allow remote GUI access to a VM running X in a VirtualBox.

There are a lot of better ways to do this. For one thing, Tomcat doesn't need GUI at all.

In fact, if your VirtualBox is running CentOS, I don't even know what X2go is going to do for you. You would be far better off running Tomcat as a systemd service, which would launch Tomcat when the box was started and keep it running until the box was shut down.

You can do everything you need to do for Tomcat under CentOS using ordinary SSH without X.

Actually, X2Go is a remote user login, and like any remote user login, whether GUI or command line, any apps launched by that login will terminate when you log out. But you can avoid that by using screen or nohup. Although, as I said, a Tomcat server is better off being run as a system service rather than as a remote user app.

I don't know what you mean by "the box is closed but the server is running". To me, the virtual box is the server, and "closed" means shut down, so absolutely no programs in the box can be running, since the box that contains them isn't running.

Tim Moores wrote:Single quotes can be escaped by replacing them with two single quotes:

However, this is how you do an SQL Injection Attack if the SQL is built from substrings.

Tim Moores wrote:Or you can use a PreparedStatement which takes care of this for you.

Which avoids that particular security loophole.

Bear Bibeault wrote:Correct. Setting a value into the application context will not affect any session.

Actually, I prefer saying "Application Scope Object."

While you do have to reference the servletContext to get application scope in some instances, in many cases, such as JSPs and injected objects such as JavaServer Faces ManagedBeans, it is sufficient to say "application scoped" via metadata or context and the JEE infrastructure will take care of the details. Using the term "application scope" is a good reminder of that.

Also, if you're using a framework such as Spring, you may also have another, unofficial global scope, which comes from the bean factory. I hesitate to call this "classpath scope", but it is a source of objects not stored within any of the JEE scope dictionaries but still local to that particular webapp instance. Since Spring is an Inversion of Control mechanism, such objects can then be injected directly where they are needed or obtained from the Spring bean factory. That's the case for things like JPA Persistence management (EntityManager) under partial-stack JEE servers such as Tomcat, as an example.

Speaking of JPA and persistence in general, I don't like the idea of using a constructor to get a database connection. It makes it appear as though you're not using connection pooling.

Liutauras Vilda wrote:

Angus Ferguson wrote:The question popup from a brief discussion I had today where this topic got a mention.

Do you remember what was the context in which it was discussed?

Regarding what Tim said and what I meant afterwards is, it could be that two unequal objects produce the same hashcode (hash collision), hence their keys point to the same bucket, in which case to find particular needed object within such bucket, equals() method is used.

So as per contract, if two objects are equal, they must result in the same hashcode. While two unequal objects may or may not produce different hashcode. Of course in ideal scenario, for unequal objects you want them to have different hashcodes.

Also, of course, for hash tables, every possible hash must resolve to a slot in the table. Otherwise you get a cell number without a cell to store the key/value pair/pair chain in!

In that case:

https://db.apache.org/derby/papers/DerbyTut/embedded_intro.html

Note that the JDBC URL used in that document does NOT specify a TCP/IP port number. That's because the embedded copy of Derby does not launch an independent server, but instead directly accesses the derby database data file(s).

Not sure what you mean, but given 2 objects, if objectA.equals(objectB), then objectA.hashValue() MUST equal objectB.hashValue(); Otherwise the hash won't work properly. Then again, few things will.

First, there are two ways for "Eclipse" to connect to a database.

One is when an application is being developed using the Eclipse IDE and the application uses a database. Eclipse doesn't care about the database. When the application is run in a production environment, it's likely - even preferable - that Eclipse should be nowhere in sight.

The second case is if you have a Database Explorer plugin installed to Eclipse and you want the Database Explorer to connect to a database so that you can browse and maintain the database. Here again, Eclipse is not using the database. Only the plugin is. The plugin - as its name indicates is not an integral part of Eclipse.

Eclipse would never embed a copy of Derby in itself. Eclipse isn't in the database business. Anything in Eclipse that deals with databases - as I've indicated above, isn't actually Eclipse doing it.

And more the the point, I know of no Eclipse plug-in that launches a copy of Derby. Always when I've worked with Derby/JDBC in Eclipse, I've launched the Derby server externally. Or I'm running DBUnit, and DBUnit has invoked Derby for testing.

Derby can be run in 2 different ways: as a stand-alone database or as a network-connected server.

In the first case, Derby is usually going to be embedded in the application, initialized by the application, and terminated with the application.

In the second case, Derby is operating as a completely independent process. And Eclipse is not going to launch it, so you would have to start and stop the Derby server yourself.

It appears you are trying to do the second case. You can use the netstat command to check to see if there really is a process (and we'll hope it's Derby) that is listening on tcp port 1527. If not, Derby was not started, or failed to start (in which case, check Derby's error logs).

Angus Ferguson wrote:

So why use double-slashes?

It has not effect in file paths in fact it is treated as a single path, with Linux for me is more stylish...I find value on it.

I don't. In fact, I had to double-check to see if there weren't consequences to the extra clutter.

You might as well have coded "/./marineDigitalJournal/./presentation/../presentation/./swing/./images/../images/./predictions_high_CHL_locations.png"

Redundant syntactic lint is only going to make people waste time on figuring out something unrelated to the main problem.

If you're using the URL format like "http://" you're failing to understand that that particular set of double slashes has a specific meaning and isn't just for decoration. Using one slash or 3 slashes instead of 2 slashes changes the path location, not just the appearance.

I don't know that the classloader is going to repeatedly do I/O, but it's still worth it to create the Image object once and cache it. Even if the image data comes straight from RAM, there's no virtue in repeating the overhead to convert it.

You may not need them. For example, the ultrasonic sensor has its own on-board pull-up. A pull-up is just an ordinary resistor, BTW, so you don't need to buy anything special.

One of the most common uses of pull-ups is actually stuff like pushbutton switches. The switch is normally-open (usually) and connects between the AVR input pin and ground, so it short-circuits whatever voltage is on the AVR input pin. The pull-up resistor supplies voltage from the logic power rail, so normally, that means about 5V when the switch is open and 0V when it shorts to ground. So the resistor is to limit how much current is shorted to ground. Something like 0.5ma, if my math is correct.