Tim Holloway

The Datasource is common to all users of the webapp. Well, actually there can be more than one datasource, but Datasources are never "per-user". A multiple datasource app might have one pool connected to the corporate general database and another to a separate Oracle Financials database, as an example.

Because of that, the Datasource credentials have to allow the greatest common denominator of all users and functions of the application. Which is why when you keep webapp user credentials in a database, that you use a separate, more secure webapp to maintain those credentials.

Bear in mind that a Datasource doesn't create Connections on-demand. It creates a pool of identical and interchangeable Connections, which is why individual webapp user IDs cannot be used to get a personalized custom connection. To do that, you'd have to connect for each and every request from each and every user, and that's a lot more overhead than using a Connection Pool. But Connection Pools are safe enough, as long as the webapp itself is secure.

The local maven repository cache is located at (by default) $HOME/.m2/repos and under that, artefacts are cataloged in directory trees organized by groupId, atrifactId, and version. You  can safely delete any of these, and in fact, I've been known to reclaim disk space by doing so. If a maven build needs a deleted artefact, it will simply download a fresh copy into the cache.

If you have copies of the offending log4j  in a project's /target directory, do a "mvn clean" on that project. If you have copies anywhere else, presumably you know what they are and whether they're safe to delete.

Note that if you have a site-local repository server such as Nexus, the server administrator should be able to expunge the offending artefacts from there.

You can expunge the offending log4j JAR by removing its directory subtree from your $HOME/.m2/repos directory. That's perfectly safe.

Make sure, however, that you are using the 3.6.0 version of the javadoc mojo. It was last updated earlier this month.

The javadoc mojo itself does not directly depend on log4j, so it probably got yanked in from an upstream dependency. Which, we hope, has been brought up to date by now.

Marcio Belo wrote:I'm really concerned with the current trend brought by 'no code' or 'low code' tools that claims you don't have any skills to develop a good solution. In my opinion, it will create bad designed products and discredit on our career.
As a teacher, how do you think I should address this in classroom?

That crap has been pushed for longer than I've been in the trade. It never has amounted to anything serious.

I've lost track of all the "silver bullets" that have fallen flat, from 4GLs to products like Nomad, and even Spring Roo.

The fatal problems I've seen is that the all really only know how to write the same apps with minor variations. They cannot envision a new kind of app from scratch. Followed by the inevitable client request: "That looks great, but could you make this one small change?". Which the system can't do.

The code generator did all the thinking, so the monkeydeveloper doesn't understand the principles of the technology and any attempt to add said changes manually results in a broken mess, plus destroys the "round trip" maintenance cycle.

This is why when people post threads starting with "I'm learning Java with (some IDE) we telll them to start  with Windows Notepad for an IDE. Those wizards are dangerous when you're the Sorcerer's Apprentice.

The latest twist is AI code generation. So far the results have been better at addressing that sort of thing, but AI's in their current state are prone to learning and propagating things that they shouldn't. The ones that turned racist are probably the funniest, but there's a real danger of producing code like the infamous Excel spreadsheets where everyone implicitly trusts what they see even if there's actually a fatal flaw inside.

That sounds like the client is making an AJAX request. Sending a request via AJAX in XML format is legal, but cumbersome. Most people prefer to use JSON. I like YAML when it's suitable. XML is a lot of overhead relative to those 2 (and to straight text for the REALLY simple stuff).

If you actually want to send an HTML FORM, I am fairly certain that there's a client request that will do that without the DOM requirements on the server. That is, so that the AJAX request just looks like an ordinary form submit. There certainly is for doing just that via JavaServer Faces, since I do that a lot.

So I suspect that you're taking on more work than you actually need to.

Let's resolve an ambiguity here.

There are two types of DOM processing you're likely to do:

1. Loading an XML file (or its equivalent) into JVM RAM on a host machine.

2. Accessing the DOM that backs a displayed HTML web page on a web client (browser)

In the first case, we're going to be using Java, and all of the advice I've given applies.

In the second case, you're not running Java because Java is deprecated on web clients, thus presumably you're using JavaScript.

Two different languages. Two different component structures.

Values entered into an HTML FORM if the form has been loaded — INCLUDING DATA VALUES!!! — into a JVM DOM will be seen as element body text under the FORM's INPUT elements. With associated infrastructure componets.

Values entered into an HTML FORM on a web client will be accessible by locating the form's INPUT element and getting its value property.

Different processing.

As far as it goes, I know of no good reason to be uploading and processing value elements of an HTML document as a DOM Document in a JVM. If you're trying to brute-force reproduce what happens when an HTML FORM submit is done to a JEE webapp server, you should know that servers like Tomcat do not build a DOM from the submitted form*. Instead they use a digester to extract the essential data as a set of JavaBeans which, in turn are used to build the JEE standard data objects (in particular, HttpServletRequest). The raw HTML never reaches the application code.

---
* DOMs eat a lot of resources. The Digester simply grabs what it needs on the fly.

I was consulting at a small IT shop here in town many years ago (everything's "many years ago", anymore!). I was talking to one of the people there who mentioned that when he applied for the position he held even though it demanded IBM mainframe assembly language and he didn't hae any experience doing that.

He lied, got the job, and did it quite competently.

More than anything else, the HR  conceit that you're only capable of what you've already done ("hit the ground running"). IT is such a fluid field that what I'm working on now and what I'll need skills for in 6 months will more often than not be vastly different. If you can't become competent in a technology in 2-3 months, you'll never be a good fit for any IT job outside of grunt-level operations where you only load paper into printers or whatever.

Heck, I figure given another month, I might even be able to tame Ceph, and the Ceph documentation for the release I'm working with tells me how to do essential tasks using utilities that no longer exist for that release, utilities that are not yet fully implemented to the needs of the documentation, and OS commands that haven't been available for 5 years now.

Phillip Powell wrote:I'm sorry, but I am unable to follow you.  Everything is being held in the DOM, considering that Javascript can read all of the DOM elements with no problem, including the hidden field.

Turns out the problem was not the fact that it was a hidden field.  the Document object couldn't read any of the form elements (the text fields and textareas, alongside the hidden field) except for the value inside of a text field fed by a datalist.  

The DOM Document doesn't "read" anything. Document is an Object, not a verb and it isn't an executable process.

The DOM holds everything that was parsed into it, and the default parser will indeed parse in all the elements of an HTML form given to it. You do need to be aware, though, that the parse tree held in the DOM isn't a straight rendition of the original document. It also contains infrastructure support elements that have to be dealt with to access your actual XML elements, attributes, and so forth. The Node class in particular serves as base class for many of these infrastructure elements.

Featherless biped

You lie.

I've been rejected because I had experience with JES version 27 when they demanded JES version 26, Had recruiters pressure me to claim Oracle experience because their clients wouldn't accept DB2 as an equivalent.

HR departments are clueless idiots who have no concept of equivalencies or demonstrations that you can pick up a technology fast. And ironically, more often than not, what I end up doing is totally unrelated to what the position was supposed to require. I don't think I've ever been hired via HR in my entire long and very evil career.

Refusing to lie and refusing to move all over the country are the two primary reasons why I didn't get as far in the rat race as I might have. However, I did manage to build up enough of a retirement account that I don't care.

Oh yes, and then there's the food distinctive to Jacksonville. The Camel Rider and Steak-in-a-Sack.

It's actually hard to find them South of Downtown, but they are part of the unique heritage that comes from being one of the diaspora targets of the Palestinian village of Ramallah.

Ramallah is primarily Islamic and troubled now, but a hundred years or so ago, it was majority (Orthodox) Christian. You don't see their names much in places around town, but many of the people have been prominent citizens.  Many becaume lawyers and doctors, and even a former mayor. And some ran sandwich shops, including the local chain known as The Sheikh.

A Camel Rider is definitely not halal, as it's essentially the innards of a submarine sandwich in pita bread. Properly consumed with cherry limeade and optional hot sauce.

The Steak in a Sack is more diverse. One place I used to eat regularly made almost a beef stew in pita, but my favorite version was a chopped beefsteak with a Mediterranean blend of spices (and onion?) that I've never been able to properly re-create. Diced tomato and/or cheese optional. Been years since I had one. They were a speciality of the sandwich shop in the former IBM building on the Southbank.

South of Downtown you can find Lubi's. Their take is quite different and they like to do hot peppers, but good stuff!

kevin Abel wrote:Tim,

Now I want to take a trip to Jacksonville.   I have drove past the city many times and now I wish that I drove inside of it  to explore.
Kevin

Well, as a tourist destination, it reeks. Downtown is pretty lifeless and has been since all the big companies moved to suburban campuses off Southside Blvd and J Turner Butler. Although they're trying to rebuild it. Downtown Dallas in the 1980s was worse, though. Precious little touristy stuff, aside from the zoo, er Jacksonville Zoological Gardens. Haven't been to the Miami Metrozoo, to see how it compares, but it's pretty good. Miami and Tampa (Lowry Park) are the only other really major zoos in the state, since the Central Florida zoo was stuck back in the depressing 1960s last time I was there (supposed to be better now). Mostly Orlando's wildlife is splattered over their tourist attractions, although the area is a wonderful place to meet bears.

The beaches are decent, but the really good beaches are all on Florida's West coast. Night life is allegedly OK, but as a software geek, I couldn't say. Obviously we don't get too many visits from Taylor Swift, but there are some pretty good concerts. And of course, what used to be billed as the "World's Largest Outdoor Cocktail Party" — the Florida-Georgia game — is coming up next month, give or take.  Also the Jazz Festival, which may not be world-famous as in years gone by, but is still a staple in May.

The views of and from the bridges are scenic, and each down bridge is lit with its own distinctive color.

One thing you won't see, alas, is the Jacksonville Landing. It was a cool place, but they demolished it last year. Likely  to become high-rises in the future.

For seriously touristy things, though, St. Augustine is 25 miles from my front door.

Cezar Apulchro wrote:Hi, trying to deploy my project I opened a topic here and Tim Holloway told me that I need a server because Tomcat is not server is only a  container

No I didn't.

It's legal enough, but as a general rule I wouldn't advise it. Constructors are best used for initializing stuff. Once you branch out and start "doing" stuff, you increase the possibility that the constructor will throw an Exception and thus become more fragile. Very definitely avoid doing JDBC operations in a constructor, for example!

More commonly the case you described might be done by a bean management framework, such as Spring, which would be set up to construct the COV8Ext and then auto-wire it into the COV8. Or, if you're not using a bean factory to return the beans as a unit, some frameworks allow a @PostConstruct method, although that's not a big improvement on doing it all in the constructor.

Parsing in XML/Java is done by a SAX parser, whether it's being invoked by DOM loading or stream processing. If memory serves, even the STaX parser has a SAX engine underneath it.

That's also true of the Apache Digester, which uses SAX to convert XML text from places like the TOMCAT__HOME/conf xml files, the Context definitions (both external and in WARs), the web.xml files from WARs being deployed, and essentially any place where XML text needs to be used to construct a network of JavaBeans.

However, an app cannot invoke Tomcat's Digester. If a webapp wants to digest, it must supply its own digester JAR.

SAX is an Interface, and there are indeed multiple implementations, but products that parse XML often include the Sun one and have an option for using an alternate parser if you don't like the builtin one.