Tim Holloway

Something to bear in mind in JSF is that it's based on Inversion of Control.

That means that backing beans don't "get" data from the View form, instead JSF itself transfers the data to the backing beans. In MVC terms, the backing beans are the Models and all the Controllers are in the FacesServlet and the internal logic that implements the JSF tags. So you virtually never write a Controller in JSF.

When a JSF action method fires as a result of a command submit, the data from the form fields will already have been validated and transferred into the backing bean. In fact, unless each and every form field has a valid value, JSF will neither update the bean nor fire the action method. You are 100% guaranteed that the data will be all present and valid when the action method is called. This is also true of JSF AJAX listener methods.

I would not adapt the PHP logic too slavishly. While I really like PHP for quick-and-dirty stuff, accent the "dirty" part. PHP is notoriously bad at security.

1-16 11:32:39 [main] DEBUG net.sf.ehcache.Cache - Initialised cache: bank 2 n.s.e.config.ConfigurationHelper - CacheDecoratorFactory  not configured for defaultCache. Skipping for 'bank'.
I believe this is your answer. You need to configure your defaultCache.

Instead of}catch(ClassNotFoundException e) { System.out.println(e.getMessage()); } Consider} catch(ClassNotFoundException e) {    e.printStackTrace(); } It gives you more information. Although in this case, it's pretty obvious that class server.Guest was not defined in the classpath of the client.

When you serialize java objects, the serialized data does not include the class itself, only the class data. So if the client doesn't understand the class, it can't instantiate a copy of it to load up with the incoming class data.

Welcome to the Ranch, Maxine!

It's not well-defined how large a header a client will accept nor how large a header a server may send. Or, for that matter, how large a URL a server will accept. Originally, 1024 was thought to be a good number, but different software implementers quickly upscaled that as large headers and URLs became common. Unfortunately, the amount to which they upscaled was never agreed on for a standard.

There is no virtue in sending general data in a header. HTTP is a text-based protocol consisting of a series of text lines. The only difference made between a header and the body is that you have 2 newlines (that is, a blank line) after the last header to indicate to the client that the remaining text is body. Of course, if the header section contains lines that don't look like headers, the client may choke on them, but that's secondary.

Even binary data such as images, videos and ZIP files are actually transmitted as text in the HTTP response. Binary data is MIME-encoded, which is a process that converts 8-bit binary bytes into printable characters by unpacking them 6 bits at a time (in ASCII and EBCDID, control codes are not printable and that's why bytes with those values have to be encoded).

Junilu Lacar wrote:

Rinu Gour wrote:The & operator is applied to the operand when both the boolean and && operator is evaluated. Once an expression involving the && operator is evaluated, the first operand is evaluated. If the first operand returns a value of true then the second operand is evaluated. The && operator in Java is then applied to the first and second operands. If the first operand evaluates to false, the analysis of the second operand is skipped.

No, that is an inaccurate description.

A more accurate description is that the sub-expression to the left of the && is evaluated and IF FALSE, the right-hand sub-expression is bypassed (short-circuited) and the operation returns false. IF AND ONLY IF the left-hand subexpression evaluates to true, THEN the right-hand subexpression will be evaluated and the operation will return true or false depending on which value the right-hand subxpression returned. This has side effects. If the right-hand subexpression includes one or more method calls, then the calls will not be made if the short-circuit is taken. Nor will prefix/postfix increments and decrements (such as i++) be performed.

The "&" operator technically has two meanings. One is the simple boolean operator, where both left and right sub-expressions are boolean expressions. In that case, the logical AND value for the results of the two sub-expressions will be returned as a logical value.

The other meaning of "&" is as a BITWISE operation, where the binary value on the left-hand side is AND'ed to the binary value on the right-hand side bit by bit. For example, 0110 & 1100 results in 0100.

Some might argue that the boolean & is simply the same thing as bitwise & for a pair of one-bit values, but that's assuming internal implementation details and Java is more abstract than that.

Normally I use a mock mail module to test email logic. The mock module replaces the actual mailer. It responds the same way that a real mailer would, but avoids having emails fly around randomly while you test. And, aside from cluttering up the network an mail resource, it can be hard after a while to keep track of which test went with which email if you use a live mailer.

There's no trigger fired as such. No real need for one, since if you're using your own business logic to send the form; just send the admin email as part of the business logic.

JavaMail does have logging, and you could set up a logger to email events from JavaMail, but this probably would not give very satisfying results. And might even end up recursing, if the emailer generates a log email, which, when mailed generated a log email, which...

You can use gmail as a test email server, but an in-house server would be kinder to the Internet.

I can't say for certain, but I'd suspect that the server's TLS certificate isn't trusted by the client.

When you use TLS/SSL in a web client, the client has a set of master certs it trusts (a set is bundled with the JVM). These certs are used to authorize lower-level certs that aren't in the master list, and those certs can in turn authorize lower ones still, forming a chain of trust.

If your client fails with "peer unauthorized", then the likelihood is that the cert provided by the server can't be linked to form such a chain and the solution would be to either change the server cert to one that can be linked or to add a cert that can be linked to the client.

It's also possible that the server is using a self-signed cert in which case the client has to explicitly approve the server cert. On an interactive browser, that's done via a pop-up dialog. On an automated client you have to use other means and unfortunately I can't remember how that's done, so I'm afraid you'll need to do some homework.

I don't think changing the socketFactoryProvider is going to do it, though. If what little memory remains is correct, it's an option of the application code's connection options.

I think I spent about $4.50 back around 1994 when I picked up a CD at a Ham Radio convention. Bought the "Dr. Linux" book, which had a Red Hat 2 disc in the back pocket. At the end I was paying $65 for RH6. RHEL was too expensive, though, so these days I run free distros. I don't need Enterprise support - I am Enterprise support.

Campbell Ritchie wrote:

Tim Holloway wrote:. . . RHEL 7 is the current production release. . . .

RHEL, is it? Aaaaaaaaaaaaaaaaaaaaaaa! And I thought that meant ordinary red hat, which has been superseded by Fedora.
What's ANSI encoding? From this SO post, it would appear to be Windows‑1252. I am surprised that you are getting everything appearing as a square; most fonts should be able to display such text. I still think we need more information, please. As you know, Java® Strings use UTF‑16. That changed slightly with Java11, but I think they still behave as if they used UTF‑16.

The Great Schism happened over a decade ago. The last "pure" Red Hat Linux release was Red Hat 7. I still have the discs. Up to that point, you could buy Red Hat for under $100 at your friendly neighborhood computer store. After that, they switched to Red Hat Enterprise Linux (RHEL), and reset the release numbers (which admittedly got confusing). RHEL ran about $450 per-machine license. Fedora spun off, and became the hobby/test version of the Red Hat world, although I'm not sure if the Fedora Foundation is actually owned by Red Hat. Also spun off at that time were several free versions of RHEL, of which I think only CentOS remains. And CentOS was actually acquired by Red Hat Inc., about a year or so ago - but it's still free.

It's really quite incredible that Red Hat is one of the most profitable software companies around despite the fact that you can obtain most of their products (but not the support) for nothing. This breaks all the things that economic experts and ideologues "know" about how humans are supposed to respond to free stuff. Obviously that support is valued quite highly. And as a shareholder, I'm cackling all the way to the bank. I'm really going to hate it when IBM takes it over.



Back to our regularly-scheduled program:

I've seen this sort of weirdness before. Most common fonts have the basic ASCII character glyphs in them, but some of the symbolic fonts don't, and thus they display even plain English text as all boxes. Or, it's possible that the original text isn't actually ASCII and somehow the Arabic version of the content was presented using a font that doesn't have Arabic characters. Mis-matches between straight ASCII, UniCode and UTF-8 are more likely to display at least some readable text.

The only way to really know is to build a copy of the app that displays what font is being pulled in there and have them run that.

Technical note: When you open a TCP/IP connection to a server, the connection process is a negotiation. The server has the right to refuse the connection attempt as part of that negotiation. It's not simply a case that the client can blast a message to the server and expect the server to accept it automatically. If the server rejects the connection attempt, the client should understand that as a failure to send and handle it in whatever manner it thinks is appropriate.

Full details on how TCP/IP connection process works are outside the scope of this discussion, but you can find plenty of information in just about any book on networking.

OK, this is a Swing app. A very good possibility is that the app is requesting a font that is not installed on the client's system. The actual mechanism for obtaining a font to render in Java/Linux is by building a font definition that outlines the properties of the desired font, including name, point size, style, and so forth. The font manager will then rummage through the set of installed fonts to find what it considers the best match. For example, an app that asks for Microsoft Arial font on a Linux system might actually end up using the Linux FreeSans font, since it's a sans-serif font that resembles Arial. A different machine might actually have a downloaded set of the Microsoft FreeType fonts, which includes the Arial and Times New Roman fonts. Linux can handle FreeType.

So apparently the best match for the font on this particular machine wasn't a very good match.

Congratulations!

Here's the official Maven docs on that: https://maven.apache.org/plugins/maven-war-plugin/faq.html#attached

Note that they, too recommend that you actually build the JAR in a separate POM, but this is for when you can't be bothered to do that.

Angus Ferguson wrote:It is just a small web app I am doing as a hobby, with a new tech stack for me (Spring Boot, Maven and so on)...

I am not using this forum for "professional" questions just for speed up a little bit with the basic stuff on this tech stack, it looks like it is not a way to go

OK, we're still here to help. But you are playing with industrial-grade tools and materials, so if you actually want to understand what you're doing instead of just stumbling around, you owe it to yourself to fill the gaps in your education. We can fill the small ones, but the best way to fill the larger ones is with some good external help. O'Reilly, Manning, and Apress would be happy to oblige you. Also, Oracle has online tutorials. And there are some good blogs out there, although I don't have any to recommend. I suppose a simple Google query "What is a WAR" would offer some starting points. Although the problem with learning from people's blogs is that some of those people have their own misconceptions.   One advantage of formally-published books and vendor-supplied guides is that they've usually been peer-reviewed before publishing. I was one of the reviewers for Pearson back several years ago, in fact.

Campbell Ritchie wrote:Are you still using RedHat 7? Isn't that severely out of date?

No, RHEL 7 is the current production release. RHEL 8 just came into Beta within about the last month.

Rectangles in a GUI display are an indication that the font being used to display the text data does not have graphics (glyphs) defined for those characters. The most common cause of this is that the wrong code page being used by the displaying program.

Unfortunarely, one scrollable textarea looks pretty much like another, so we can't tell what app is giving you trouble.

There's nothing wrong with learning any version of Java. Even Java 1.3 would give you enough feel for the shape of the language. I'd say that the rest is refinements and conveniences, but annotations are a pretty big change and they came in at Java 5. Java 7 is, I think where lambdas came in (Java 8?), and my own favorite, try-with-resources.

Fair warning: I haven't seen that many adverts for Android programmers, and the salaries mentioned for them were fairly dismal. A consequence, perhaps of the fact that android apps generally sell for only a few dollars.

But if you know Java and can't find a good Android job, it's still alive and well for general PC applications.