Tim Holloway

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.

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.

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.

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.

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.

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.

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.

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.

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.

My condolences to you, youngster.

Spring isn't that hard once you understand that it's formed around a core, which is the Inversion of Control bean factory. This factory is the one-stop shopping point for all Spring-Managed JavaBeans and it not only constructs the beans on demand, but also can wire them together like TinkerToys™, eliminating the need for you to have to manually hard-code links between beans. So the starting point for Spring - as well as quite a few other frameworks - is to understand IoC.

In addition to the fairly small Spring core, there are various functional domains which group related services together and attempt to provide as much commonality of operation as possible - which helps to lower the learning curve. For example, there's Spring Data, which provides services for all types of database programming from simple JDBC to JPA to NoSQL DBMS's such as MongoDB and even the really exotic stuff like Neo4J. Or Spring Batch, which eases the process of creating batch-mode applications. And the increasingly-popular Spring Boot. There's a domain (Project) for almost any common complex function you're likely to need.

As for myself, I've seen so many DDD (drag, drop, drool) visual designers come and go, I can't count them. An assistive design tool such as Eclipse is fine, but once they start thinking they can run your life, look out. One of the things that ultimately pushed me out of the Windows world was having to do late-night panic fixes where the project could only be built properly if you had an obsolete version of Visual Studio (with patches applied) running on an obsolete version of Windows (with fixpacks applied). In other words, a 1-line fix that required 3 hours of building an antiquated custom development environment first.

These days, all of my projects can be build on a non-GUI machine. I use the IDE for development, but if I cannot build the production module without an IDE, it's not acceptable.

I sympathise on Maven, though. I resisted it myself for a long time, because I don't like processes that happen by magic. There is a method to the madness, though. It's basically programming by declaration, and PBD is actually quicker and more reliable than explicit code. It's taking advantage of the idea that projects are more alike than they are different, and once you know what files go where, it's actually easier to hand off a project to a remote contractor on the other side of the planet, because if you do a "mvn clean", zip up the project directory, and pass it on, the person on the other end can completely build an identical copy of that same project without having to do any special adjustments to the recipient's computer. Before Maven, I routinely had to deal with projects that couldn't be safely passed on to another department in the same company.

I've worked in every environment from stand-alone to start-up to the largest shops in town, but more often than not I seem to be the sole person on a very complex project. So I can identify with you. I don't go chasing after every fad - in fact I never bought into Ruby on Rails at all. But I do try to keep up with things that can make me more productive.

Peter Rooke wrote:The Spring IoC does not have much in common with other technologies that use the same term (like docker or JEE). 

Which is why I don't like to call it a container, despite what the official docs say.

As containers go, it's a leaky one. Although technically it can manage beans over their entire lifecycle, in actuality a raw bean, once manufactured and returned to application code is mostly on its own.

No.

Also, the colon character has its own special meanings for a URL.

Good point. As someone who's done a lot of both C/C++ and Java - and assembler, COBOL, Fortran, PL/1, Forth, Smalltalk, ...

Java has been very liberating to me. Because it's very abstract and because I can depend on it doing a high level of optimization at both compile and run times, I like Java because it has less guilt.

In the older languages, I worried about every byte and every machine cycle with each line of code I laid down. It was an especially hard hit for me because I have often worked all the way down to the bare metal doing real-time processors, OS exit routines and interrupt services, and other stuff that gets executed very, very frequently and/or absolutely must not fail. Java's very opacity has set me free, since there's really no way to compute precise memory usage or CPU consumption. I code to the abstraction and then tune - which is ideally how programming should be done. Although it's a lot easier to do when the entire system RAM isn't 1MB of mainframe core!

As I recall, the usual behaviour of a payment gateway involves sending the payment request to the gateway along with a return URL(s). The payment gateway runs on a foreign web application, so it needs that URL to return back to the app. And to tell the app whether the payment was accepted or not. That isolates the money-handling process from the regular application, making it harder to exploit possible app weaknesses to know or access payors and payees accounts directly.

However, RFC 3986 defines what is and isn't valid in a URL, not some genius who thinks that they know what's secure and what isn't. Section 2.2 defines the characters that have special meaning to URLs, and that does include the semicolon character. Also see section 3.3 for information specifically about use of the semicolon in a URL.

Any gateway worth the price should be capable of dealing with that.

I should note that the sessionID is itself secure information, and when you're talking to a payment gateway, you should have already shifted into an SSL/TLS communications mode, meaning that Tomcat will have changed the sessionID at least once already. Indeed, you should enter SSL at a minimum when you first start a shopping process, even before you create a session.

Ivan Jozsef Balazs wrote:

Tim Holloway wrote:__FILE__ and __LINE__

Nobody prevents us from running Java (pre-) code through a C(++) precompiler :-)

Nothing prevents you from running anything through a C(++) precompiler. Although with Java, it's kind of awkward to interject other processes into compiles on account of how the process cross-consults multiple source files.

Still, it's not really __FILE__ and __LINE__ I miss in Java, it's #if/#elif/#endif and the #ifdef.

Although I have more or less reconciled myself to that. With Java, it's hazardous to have multiple incarnations of a class, and if you just want to kill dead logic, the compiler is smart enough to do that off of ordinary Java code. Early C compilers weren't that smart, nor did they have the highly-tunable logging support that modern languages do. So #if frequently handled enabling/disabling debugging, OS dependencies (no write-once/run-anywhere in C!) and other things that Java has more explicit mechanisms for.