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 mousetech.com 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

I'm going to have to assume that you're doing that weird thing where a webapp uses Glassfish resources even though the webapp server itself is Tomcat.

It sounds like you are spawning threads in your webapp. The J2EE standard expressly forbids that in any code that's being executed in response to a servlet request - and that includes servlet code itself. Servlets run under threads that are pulled from a pool, used just long enough to service the request, then returned to the pool. If you spawn a subthread of that thread, you end up polluting the thread pool, which can randomly crash Tomcat.

In the event that you spawn a thread(s) in ServletContextListener - which, unlike servlets, is allowed to spawn child threads, you are obligated to terminate those threads in a corresponding shutdown ServletContextListener method. Failing to do so will annoy Tomcat and delay its termination, since a JVM cannot exit to the OS until all of its threads have terminated.
1 day ago
Is this for a stand-alone Tomcat, or a Spring Boot Tomcat?

Not that I expect that much difference, but obviously there's some - Spring Boot webapps are self-deploying.
1 day ago
Helpful hint:

And yes, this is from a project that hasn't been updated in a LONG time.

But if I ever did, I only need to change the Spring version ID in one place!
1 day ago

Ling-yuan Tai wrote:Tim,

Thank you for the explanation.  I recalled an online post mentions that a certificate needs to be installed on Tomcat server for the ldaps connection, is that right?  I'm not sure if we have the certificate installed on Tomcat server.

To the best of my knowledge, the only certs that need to be installed are the certs that might have been generated when the server OS was installed. And I might be thinking of the host's own certs for its SSL clients.

I think maybe someone's thinking of a client-side certificate, but that would not be the standard option. A client-side cert is what you use when you don't want to use userid and password to authenticate, but instead want the server to challenge for a cert over an encrypted channel, and therefore, probably would need the LDAP server to have been specially configured. At least that's how client-side certs work with webapp servers like Tomcat and Apache - they won't use a client-side cert unless you set them up to use client-side certs.

Client-side certs for desktop machines are, in my opinion, not a good idea - steal the machine and you've stolen the keys as well. For in-house DMZ servers, there's not much probability that someone will steal a machine, so they work better in that environment. But again, only when the other machine is willing to use that authentication channel.
2 days ago
No, you must build a WAR and deploy the WAR to Tomcat.

You're trying to let your IDE (Eclipse) do all the thinking for you. If you understood how Java webapps and webapp servers work, you could make everything work without using Eclipse at all.

In fact, you have to do so in the Real World. No sane IT shop is going to run an IDE on a production server machine.
2 days ago
Anybody can write a framework.

Basically, a framework is just something to support common functions for an application. I've dealt with uncounted user-designed frameworks (some of them pretty awful, alas!) over a long and evil career. As I think I said earlier, they prevent you from having to code - and debug! the same code over and over again.

Spring is certainly one of the more popular frameworks, and it seems to be one of the most intimidating, but as I've said before, it's a simple core plus a number of extensions ("projects"). And likely 90% of the projects in Spring I've never used, but some, like Spring JPA I use extensively. And, incidentally, JPA, although officially an API, can also be considered as a framework.

My copy of Manning Publication's Spring In Action is pretty old now, but I think it's a good introduction to Spring.
There are 2 common ways to determine what format a file has.

One is by looking at its file extension. For example, ".jpg".

The other is by looking inside the file for a "magic" identifying sequence. In fact, the Unix/Linux file /etc/magic was originally designed to hold prototype patterns specifically to be able to tell what type of file was being seen. This is especially important when all you have is a data stream and no file name (hence, no extension).

With the rise of the Internet, a lot of the magic has been taken over by MIME definitions. And to help carry information over channels such as HTTP or email, where you again don't have reliable filenames (if any), there's MIME headers.

As I recall, there's a core set of image types that Java knows how to deal with out of the box. However, for image types that are not included in that core set, I think you can plug in additional processors from external sources.
3 days ago

Dave Tolls wrote:

Philippe Ponceblanc wrote:eclipse == /src/webcart/WebCartServlet.class

That's not Tomcat.
That's your IDE.

How are you deploying your web application to Tomcat?
Also, what Tomcat is it?  Is it embedded as part of Eclipse or standalone?

These are the important questions. You need to understand what a WAR is and how it is used.
3 days ago
It depends on where in the process the "clear text password" is. It's clear text inside Tomcat (including on the Tomcat Realm definition), it's probably briefly clear text inside the LDAP server, but on the LAN, ldaps should have it encrypted.

Note that in a real-world production environment, the fact that the Tomcat server has the password in plain text matters little. Unauthorized users should not have the ability to see the Tomcat configuration files. And encrypting the password here is meaningless, since the same encrypted password could be copied and used for malicious purposes without ever knowing its unencrypted value. However, best practices say that the credentials used to access LDAP should not be the LDAP administrator credentials, where anyone can do anything. Instead your connection should be done using a connection whose access rights are limited to only the parts of the LDAP server needed for authentication and authorization.
3 days ago
Custom Realms are fun, but I don't think you need one here.

I also don't think that the "digest" attribute is what you need. As far as I can tell, that's a general use for pre-encrypted passwords, not an encryption directive itself.

In fact, it seems like merely using the "ldaps:" protocol in your URL should be sufficient to indicate to Tomcat that it should encrypt the connection and lookup requests over the network. Just like using "https:" in a URL indicates that the client should talk to port 443 using TLS, so "ldaps:" should indicate that an encrypted connection should be made to the LDAP server's port 636.

Note that Tomcat internally is passing the password around in clear text, because the user had to type it in in clear text. But Tomcat uses best practices to make it hard to snoop that data internally. Once it talks to LDAP, however, it's a matter of two network clients negotiating security protocols, just like ssh and https do.

There are 2 ways to validate credentials to an LDAP server. One is to connect via a general-purpose login and do an LDAP search. The other is to actually attempt to log to the LDAP server under user credentials directly. If the attempt fails, then the Tomcat Realm will also fail the login attempt. Fair warning: I know that this is a thing, but my knowledge of details is very limited.
4 days ago
You can check the options, but considering how much customization you want done, I suspect that the only way to get what you want is to write your own Maven mojo. You can either make it reformat the XSL itself or make it run XSLT, whichever is easier.

Mojos are simply JavaBeans that conform to Maven's requirements. You should, however read FROM the original XML and output TO a new directory and not simply replace the original XML. That not only violates the spirit of how Maven works, but can make it harder to debug the mojo.

These days I run Maven inside Jenkins and the defaults make nice online reports with red/green indicators that make it easy to zoom in on failing tests.
4 days ago
Welcome to the Ranch, Rahul!

What do you mean by "redundant"?

Are you referring to the detailed stack traces? Because if a test fails, developers are going to need as much information as they can get about why it failed.

The Maven junit mojo does have other report formats, including the ability to render HTML with zoom capabilities, although I forget the name of the facility that it uses.

I'm adding this question to the Maven forum, since it's really about Maven more than it is about junit.
4 days ago
It is because Spring.

It's one of the main reasons I use Spring. I don't use Spring Hibernate, I use Spring JPA (using Hibernate JPA as the JPA persistence mechanism). Spring not only manages the session, it also eliminates the need repeatedly code error handling code for the session.
5 days ago
RMI doesn't need a server (Tomcat). RMI is a server. It has its own protocols and ports separate from those used by a web application server, such as Tomcat.

Long ago I did set up an RMI server that was paired with Tomcat. I had a database process that could take up to 10 hours to run, and running that process within Tomcat would have made it effectively impossible to be able to stop or start Tomcat if there was some need to do so. So I outsourced the long-running process to a method running on an RMI server and developed a client API that Tomcat could use to start, stop, manage and monitor this long process.

RMI is about the most efficient way there is for two separate JVMs (on the same server or on different servers) to communicate. However, it has a lot of restrictions.

First, both the client JVM and the RMI server JVM must be compatible. RMI uses object serialization, and the format of serialized data may change between Java releases and vendors.

Secondly, the RMI ports are generally blocked by most of today's firewalls by default, so in order to use RMI, you have to ensure that all firewalls between client and server allow RMI. That can be especially difficult when attempting to connect over the Internet, so RMI works best when client and server are on the same LAN.

RMI is built into full-stack JEE servers (Not Tomcat), to be used by remote EJBs. Because of the issues I've mentioned about, there's a protocol called RMI-IIOP that's intended to make it easier for remote EJBs to work over the Internet. However, EJBs themselves aren't as popular as they used to be and these days, they're almost always local, so no RMI is required.

Oh. And just to be clear. ReST is an HTTP protocol, so it requires a webapp server. ReST doesn't run over RMI.
5 days ago
PHP is a quick-and-dirty language designed specifically for web applications. It's also notoriously insecure, and they're still struggling to make it object-oriented. It most closely resembles Perl, which in turn looks a lot like C.

Yes, PHP is popular. The Wikipedia software is written in PHP, as is WordPress.

No, you don't need PHP to get online. PHP is useful, if you can tolerate its weaknesses and is still one of my primary choices for knocking out a site quickly. Although my current #1 for that is NodeJS.

You certainly can write social media sites in Java. It's more a matter that social media sites care more about "git 'er dun" in a hurry development and less about security. Java is, in comparison, horrendously slow and expensive to develop in, but its vastly greater security and the large library of services that it can tap into - including high performance - have a special appeal for industrial-grade apps.

JavaScript is actually quite horrible in many ways, but it's virtually the only choice if you need client-side logic and especially AJAX (the "J" in AJAX literally stands for JavaScript). Many Java apps are JavaScript on the client and Java on the server. In fact, popular JavaServer Faces frameworks such as RichFaces and IceFaces actually include the jQuery client-side JavaScript library for their client-side functionality.

jQuery is, in fact, a sterling example of a framework for a non-Java language. Java didn't invent frameworks.