Tim Holloway

Hmm. I mostly just launch Mediaplayer straight from the File Manager app actually. I think VLC can create playlists on Android devices, and you can use File Manager to create a media "save list" directory as well.

The File Manager is kind of quirky, as it has to deal with both built-in (permanent) storage and swappable (SD card) storage, so that's also a consideration.

The Pi has become available again in the past few months. I believe that some of the shopping sites I frequent have posted availability of at least the Pi 4 at its nominal price instead of pandemic gouge-pricing.

Bear in mind that the original $35 Pi 4 is at the bottom of its line and mostly just good for utility machines. The larger-memory Pi 4 models were always more expensive, bit with 8GB, make a decent desktop without being killed by memory thrashing.

The Pi 5 is a different beast really. While software-compatible with earlier Pi models, it is significantly more powerful as well. So it does carry a higher base price.

It also demands more electrical power to run, so while it's definitely shaping up to be a compact desktop computer or server, I hope that the more electrically frugal models will continue to be produced as well.

Paul Clapham wrote:

Esteban Estupinan wrote:It appears in my file explorer as food.txt, but the file is actually called food.txt.txt.

Argh. One of Windows's more stupid defaults. It's supposed to help people by automatically appending suitable suffixes to files based on what type of file they are - for example having Adobe append ".pdf" to files that they output - and then to hide that action from the user. So when you have Adobe save "arrrghhh.pdf" to a directory, you only see "arrrghhh" in Windows Explorer. That's fine for casual users but definitely NOT fine for programmers. But you can turn that setting off somewhere in Explorer, I strongly advise doing that.

Yeah. This comes from Macintosh Envy.

The original Macintosh computer had two 4-character fields in its file directory entries. I forget their exact names, but one served essentially the same purpose as file extensions do on Windows and Unix-like OS's. Except that they were invisible unless you opened up a file details dialog on the file. They weren't actually part of the filename itself, but meta-data about the file.

So Microsoft, hoping to look cool, did something intended to resemble that by hacking the UI filename displays.

One of the first things I do when an Windows computer is inflicted on me is turn that feature off. As noted, it's more trouble than it is worth,

S Connor wrote:Thanks.  Do you know how I could rotate or reflect the image somehow?

Graphics2d has a translation function. I think that's what you use in such cases. Also for scaling.

A word of caution.

Android isn't really designed to work with files. Persistent data is commonly kept in (MySQL) databases.

Android itself runs under Linux, so what you would be doing is effectively dropping from Android into the Linux OS. Significantly, Android doesn't run as a privileged user in its host OS, so in many cases Android apps cannot access files/directories as they are owned by a different userID.

Pædantry time again.

You don't store data in a "class", you store it in a "class instance", a/k/a an Object. Objects in a JEE HttpSession are session-scope objects.

JavaScript runs on the client. The HttpSession object and the session scoped objects named in its Map are entirely located in the server so the only way to get their values in JavaScript is to have the JavaScript request that the server return them — e.g., via AJAX,

Now if you want specifically to get the session property when the page is first rendered to the client, that's trivial:

var indentedBillRequestParmsObjProperty = ${indentedBillRequestParmsObj.property};
Note that I've retrieved only a single property value, however. Java Object instances are binary components with opaque internals and cannot be used on clients at all (especially since Applets are dead now).

If you want the JavaScript equivalent of an object and some/all of its properties. you'd have to have the server return that object as a JSON string*. Meaning that the server needs to construct the JSON either manually or with the aid of a JSON library in the application.

---
* That's why they call it JavaScript Object Notation.

If you ever need to know what your JVM's current working directory is:
       System.out.println(Paths.get(".").toRealPath());

Old-style using java.io.File:
          System.out.println((new File(".")).getAbsolutePath());
Current/working directory is a treacherous thing on the whole since if the app is running multiple threads (for example, as a webapp server), then one thread might change directories and confuse other threads, since current-directory is a JVM-wide, not per-thread.

And, of course, there's what Paul said. In Windows, you can have one "current directory" per drive and the "working directory" depends on which drive you have currently logged to. The Unix-like OS's don't have that concept.

Tha's a little much for an online question-and-answer forum.

However, IBM has all sorts of documentation on their products ranging from what is essentially just sales literature to planning and configuration guides to actual operational manuals. Also, IBM used to be famous for providing customer support, although my impression over the last 2 decades is it's mostly ancient history now.

IBM is also famous for their Redbooks publications, which are sort of practical use guides. Back before they went online, they used to have red cover.

Junilu Lacar wrote:
Why still prepend "test" to test method names? The @Test annotation marks a test method and the "test" prefix is unnecessary and redundant.

Because annotations or no annotation, test framework or no, I like my method names to indicate what they do.

Tim Holloway wrote:
While underscores are sometimes used in Java names to provide a visible appendage to a base name, using them to simply create unwieldy names is not a practice I'd follow.

Examples:

testIsOpen_weekdays()
testIsOpen_weekends()
testIsOpen_late_night() (or testIsOpen_lateNight())

Ick,

/** * Test for current time between opening and closing times. * Expect @{code true} for valid test result. */ @Test void testIsOpen() { // TODO: Construct test Restaurant instance   assertTrue("Test for resstaurant open time failed.",        restaurant.isOpen(testCurrentTime); }
Note that I took my own advice and made the time to be checked be a parameter rather than built-in. Typically, I'd have a whole set of tests with different times that would be performed within this method.

While underscores are sometimes used in Java names to provide a visible appendage to a base name, using them to simply create unwieldy names is not a practice I'd follow.

You are mistaken.

There are 2 ways to handle A&A. One is for the application itself to totally handle security. This is the dangerous way. The other is to let the container handle security. This is the safer way.

The JEE standard defines the Container-Based Security System - a set of container implementation specs and API methods that allow an incoming URL to be checked BEFORE it is dispatched to the webapp, to ensure the authenticity of the requester and to forbid access to URLs for which the requester does not possess a valid security role. In other words, there is no login code in the web application itself, it's all in the server (Tomcat, WebSphere, Wildfly or whatever) and forbidden requests never reach the webapp at all. Which means that they cannot reach possibly weak spots to exploit.

Yhe container security system is configured by elements in the webapp's /WEB-INF/web.xml file or annotation equivalents and from the servlet deployment Context, but none of the primary security for the application are in application code. You can fine-tune security using certain API methods such as the HttpServletRequest isUserInRole() method, and you can get the login userId from the getRemoteUser() method, but the primary wall against unauthorized access is completely automatic and done entirely outside of the webapp by Tomcat itself.

So to make that work, you not only have to configure security elements in web.xml, you also have to define a security Realm for the webapp when it is deployed.

Technically speaking, there are two components used to deploy any JEE webapp. There's the server-independent deployment Descriptoi, whic is the web.xml file (again, or annotation equivalents). And there's the server-dependent Deployment Descriptor. The name and media/format of the server-dependent deployment descriptor is uniiquely defined by and for the implmenters of the webapp container, For Tomcat, it's the Context XML which can be located in the WAR's META-INF diretory or in the TOMCAT_HOME/conf/Catalina/localhost directory or one of several other places detailed in the Tomcat documentation.. It is this Context, or in inherited super-context from the TOMCAT_HOME/coonf/server.xml file that determines where and how to validate userid, password and security roles.

By default, no primary or inherited security context (Realm) is configured for Tomcat webapps. Normally you would do this in the Context, just as you would the Database Connection Pool specs.

So our question is, are you using that system, and if so, what kind of Realm do you have configured for it?

There most definitely is a system used for A/A. ALWAYS. I repeat. It's not magic and it's not automatic.

When we started, you said "Tomcat server timeout", which to me implied that you were using the JEE standard Container-Manager Security system that's built into Tomcat. That system has Tomcat (the container) managing authentication and authorization. The container security system looks at the webapp's /WEB-INF/web.xml file (or annotation equivalents to determine transport security, security roles and their mapping to URLs as well as whether to use FORM-based or BASIC security for the login process.

In container-managed security, the webapp has no login code of its own. Instead, when a protected URL is submitted to Tomcat, Tomcat parks the URL request and runs its own login code internally. Until/unless the user presents valid login credentials, the process does not enter application code. Once authenticated, the original URL requeust proceeds to the webapp.

Tomcat handles authentication using Realms, which are plug-in modules that support authentication methods via a standard Realm Interface. The authentication methods simply take in the credentials and return a pass/fail to Tomcat's login logic. The Realms themselves may authenticate against databases, LDAP/Active Directory servers, XML files (reccommended only for testing) or any other soure you can think of. If none of the standard set works, you can implement your own Realm (been there/did that).

Container Security can also jack into meta-security (Simgle Sign-on) systems such as Kerberos or Windows Security. In which case, the Tomcat server may not need a signon because SSO allows the user to come in pre-authenticated. Which is why there is no "login" event defined for JEE webapp containers.

And that's just assuming that you ARE using JEE standard Authentication. It's very important to know how you're authenticating, because while HttpSessions support container security, they are not only applicable to container security. Thus a timeout of the session may not always be equivalent to logging out.

If you don't know what security system you are using for Authentication and Authorization, you are already in trouble.

Security isn't automatic or magic. Someone has to set up an A/A system and properly configure it before you can even begin to worry about what happens after you login.

Actually, no. I am no more enlightened than before. I'm OK with using "they/their" for abstract person of indeterminate/unimportant gender. What gets me is trying to use it when you're referring to a single specific person standing among a group right next to me. They need a more precise word for that.

Anyway, "login" is being presented as an Accomplished Fact here, but SOMETHING has to be handling the login process. That can be Tomcat itself, a third-part security framework such as Spring Security, or something cobbled up in-house (which is almost guaranteed to be actually not very secure, but that's another matter).

So until we know which type of Authentication System (login)) you're talking about, we can't give accurate answers.