Tim Holloway

+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Linux
Forum Moderator
Tim Holloway currently moderates these forums:
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
(keep public parts private until JForum day)
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Tim Holloway

The Eclipse Data Source Explorer is an Eclipse plugin. And, as Dave said, it has nothing to do with actually running the webapp. It's strictly a developer's tool.

Database Connection Pools (DataSources) are part of the J2EE spec and are the recommended way to obtain Connections for webapps to do database work. They allow efficient recycling of services in a multi-user environment.

Typically there's a control panel webapp for the webapp server that allows you to configure DataSources, and often it has the ability to import and install a driver JAR. Additionally, you can usually "brute-force" install a driver JAR into the webapp server. Which is how I usually do it in Tomcat. The exact location where the driver JAR must go depends on the webapp server, but can be found by reading the vendor's documentation. It's usually well-defined since datasources are a critical and popular service.
Spring is built entirely on Java. If you don't know Java, you won't know how to use Spring.

Unfortunately, most certifications are more an indication of the holder's ability to briefly memorize-and-regurgitate answers to questions on an exam (and far too many exam questions deal with making sense of things that would get you censured if you actually did them in the workplace).

So it can't hurt to have Java certs, but ultimately, it depends on how well you actually know Java, not how well you passed the exam.
8 hours ago
Welcome to the Ranch, Arpan!

I really can't say, although transactioning is often not quite what you'd expect it to be when you're doing it through an abstract framework.

The bigger question to me is why you're doing a delete and re-create instead of simply updating the row in question. That's usually simpler and a lot more reliable. Among other things, you only have 1 database transaction to roll back, not 2.
8 hours ago
A number of years ago I came to the conclusion that most software projects take about the same amount of time to complete, regardless of what language they are written in. With the probable exception of assembly language, but that's another matter.

What most languages change isn't the total amount of time consumed in the project, but rather where in the project the time is consumer.

Strongly (static) typed languages make you spend more time in the design and coding phase of the project because they won't permit you to proceed until you have satisfied all the static constraints. However, this catches a lot of the coding bugs, so you spend less time in the testing and debugging phase.

Conversely, languages with weak static typing allow you to code quickly, but because your code isn't as rigorously checked at compile time, there's a higher chance of something slipping through and only being discovered at run time.

Run time, in many cases, may mean after it's been running in production for weeks, months, even years.

Personally, I consider bugs embarrassing and would rather catch and deal with them before the world (and my manager) can see them, so I prefer strong static checking.

Unfortunately, most management wants the job done fast (and cheap), so they prefer "instant gratification" platforms where you can start coding on Friday, be demo-ing web pages on Monday and be in production on Wednesday. Even if the end result is that all of your corporate database of customer credit cards ends up in Croatia on Thursday.
8 hours ago
No. The FacesServlet does not search. It takes the URL path as is. So the only possible place for the View Template file welcome.xhtml to be given the URL path /login/main/welcome.jsf is in the WAR location /login/main/welcome.xhtml. If the the resource does not exist, the FacesServlet will look nowhere else and the result will be an error. Either a 404 or a blank page - I don't remember which (and it may depend on which version of JSF. It has been a while).
21 hours ago
This is a common confusion. A URL path is not a file path. but it is often resolved to a file path. Plus Unix file path and URL notations are similar.

But also you are confusing the resource with the resource locator.

The resource locator (Uniform Resource Locator == URL) tells the server that it wants a specified resource. So it's actually more of an address. The webserver then uses rules built into it to route the URL request to a specific webapp (context), and the webapp then further parses the URL to determine what resource resolution mechanism to pass it to.

Here's what actually happens when you submit the URL http://localhost:8080/mywebapp/login/main/welcome.jsf. I've changed your URL to make some features more obvious.

First, the client parses the URL. It determines that it should use the HTTP protocol to formulate the request to the server. It looks up the servername "localhost", and resolves it to it IP address

Then it opens a connection to IP port 8080 and send the URL request.

On the server, the incoming URL request is received by Tomcat (which is listening on port 8080). Tomcat parses the URL and detects that the web application context path is "/mywebapp" (I changed this to make things more obvious). Tomcat extracts request context information, sets up response infrastructure and does other support things and then sends the URL request to mywebapp. To be precise, Tomcat looks in mywebapp's servlet map to see if there's a servlet that matches the URL pattern "*.jsf". Notice I made another change to your URL here to make things clearer.

Tomcat determines that URLs that end with ".jsf" should be routed to the FacesServlet. So it does so. The FacesServlet received the URL request /login/main/welcome.jsf. The Facelets processor that's part of the JSF version 2 FacesServlet converts the URL extension ".jsf" to the resource extension ".xhtml". This is the default behaviour, although overrides can be configured. So the converted (internal) resource path beomes "/login/main/welcome.xhtml". The FacesServlet then retrieves this resource from the WAR using the convention that /login/main/ are WAR-relative directory names and "welcome.xhtml" is a "file" name. Since a WAR is officially a ZIP file, these are only actual files and directories if Tomcat unzips (explodes) the WAR when it deploys it (by default it does, but the location mechanism works either way). Now that we have located welcome.xhtml, the FacesServlet digests it and build a JSF component tree, which holds incoming data and is used to manage the Controllers and Listeners (and other things) that go into processing a JSF request, finally being used by the JSF Render Response phase to generate the actual HTML response that gets sent back to the client.

So in short, by convention a web page in /dir1/dir2/.../xxxx.jsf should have a JSF View Template (xhtml) "file" at /dir1/dir2/.../xxxx.xhtml and in that sense, the directories do match.
1 day ago
That URL returns "404 Not Found". It's not a lack of authorization, it's because the file doesn't live there.

Actually, I'd expect to find a jar like that at apache.org, not github.

But unless someone has done some questionalble naming, it would appear that you are trying to use Ant to download Ant if Ant isn't already downloaded. 
1 day ago
You're welcome! 

One thing to note: The difference between using getResource on a class versus getResource on the ServletContext is that the class getResource is searching the webapp's classpath. That means not only the WEB-INF/classes and the JARs in WEB-INF/lib, but also classes that come from the webapp server (for example, classes in the Tomcat servlet-api.jar file).

The getResource on ServletContext will not return stuff external to the WAR (like Tomcat's servlet-api.jar), but on the other hand, it will return stuff in the WAR that's not in the servlet's classpath. For example  "/README.md".
3 days ago

Paul Clapham wrote:


This is what "there" means in the context of your Web application when it is running.

Not your day Paul. "Context" as used in Enterprise Java isn't a filesystem context, it's a webapp resource context. A lot of people get confused because a context path in a URL looks a lot like a Unix filesystem path. But it isn't. Not even when the web server maps it to a filesystem path. The syntax is similar, but the mechanisms are very, very different. The context here is "/produto" and the canonical URL path would be "http://host:port/produto/WEB-INF/classes/redes/file.zip". Although again, a web server is not a file server, so Tomcat will refuse to resolve WEB-INF or its contents to external URL requesters. You'd get a 404 Resource Not Found response.

Internally is another story, which is why a servletContext.getResource("/produto/WEB-INF/classes/redes/file.zip") will work even on an unexploded WAR as long as the resource is in the expected place.

J2EE very deliberately does not know about what the directory organization of the webapp server is. It makes things more portable and it makes them much more secure. You cannot walk uphill into sensitive OS resources if the uphill path literally does not exist.

Or to put it another way, by specifying a suitable Tomcat Context definition, you can - and I often do - have my webapps deployed such that that resource would be located in a place such as /opt/com/mousetech/produto.zip. And if J2EE resource resolution methods are used, it will be just as easy to obtain the /produto/WEB-INF/classes/redes/file.zip resources from there as it would be if I deployed my webapp to TOMCAT_HOME/webapps. In both cases, TOMCAT_HOME would actually be something like /usr/local/apache-tomcat on my system, regardless of the filesystem locations of my webapps.
4 days ago
Sorry, Paul.

Maven isn't going to do that unless you are very careful in how you set things up. Its normal course of action when building a WAR is to construct/copy/compile into MAVEN_PROJECT_DIRECTORY/target/goalname and then (assuming you're running the war:war goal), to zip that into a MAVEN_PROJECT_DIRECTORY/target/goalname.war file. Only if you've added a deployment option is it going to then propagate the target war to a server such as Tomcat.

But to repeat myself, using brute-force filesystem and classpath operations to get a webapp resource is not something I recommend. It's too complicated and too breakable. For example, anything that assumes that the current working directory is the WAR root is in for a big disappointment. Or even that the current working directory will always be the same when Tomcat runs. This is why I promote using the J2EE resource access methods.

The hard part about that is that you do need some sort of way to obtain the ServletContext, but then if you're going to get WAR resources, you really should have managed the app so that that's not impossible. Ideally, I suppose, you should be able to go the JSF route and have a static means of getting ServletContext, but such niceties had not been thought of when J2EE was first designed.

I may be mis-reading, but I think that Wellington put the resources in the right place and has done the right call to get at them ("right" meaning functional, though not recommended). But this logic can fail regardless if the WAR was not exploded. Because, as I said initially, a "file" in a WAR isn't necessarily a "real" file.
4 days ago
Actually, you don't need the servlet. What you need is the ServletContext. You can get the ServletContext from the HttpServlet that is currently processing your request or from its HttpServletRequest parameter.

In a JSP, you can use the scriptlet "request.getServletContext();" method call to get the servletContext. Although if you're putting logic in JSPs, the Bear will growl at you.

In pure Java if you are running under some sort of framework, then the framework usually has a way to pass the HttpServletRequest object to your user-defined class if you code your class right. The actual mechanism that's available depends on the framework, so without knowing what's calling your Java classes I cannot say anything specific.
4 days ago
I'm afraid that you are operating with insufficient knowledge.

Servlets are the way webapps work. Even if you don't write your own servlet and use a framework such as JavaServer Faces or Struts, there's at least one servlet that handles the incoming HTTP URL requests (although in such cases the servlet is part of the framework). Even JSPs compile down into servlets. The servlets may call out to simple classes, but the core processing for every web request goes through a servlet.

"/src/main/resources" is not a Tomcat or Enterprise Java directory. It's how you store files in a Maven project where Maven can copy them into the webapp. And if you're doing a Maven WAR build, the proper directory isn't src/main/resources, it's src/main/webapp. There will not be a "/src/main/resources" directory in the WAR.
4 days ago
Yes. Don't copy anything from the JDK/JRE or J2EE directories into your WAR files. They are already where they need to be.
4 days ago
Welcome to the JavaRanch, Wellington!

You should not try to get a "file" in a webapp. Officially, a webapp is part of a WAR, which is a ZIP-format (JAR) file, and thus the "files" inside the WAR are not true files that can be opened via ordinary OS filesystem calls.

Also, it's not good practice to reference anything relative to a WAR's filesystem, for various reasons, most of which boil down to it's unreliable.

If you want to get a "file" (resource) within a webapp, use the getResource() or getResourceAsStream() method calls against the webapp's ServletContext. The getResourceAsStream method is especially useful, since it presents the resource already open for reading. The resource path is always rooted at the base of the WAR, so for example:

Close the resource when you're done with it.

You might notice that there's a getRealPath() servletContext method. Avoid it. It returns the absolute filesystem path of a resource, but if the webapp is in an unexploded WAR, that will return NULL.

As a general rule, if a file is not directly bundled within a WAR, you should reference it by an absolute filesystem path (J2EE does not define a "working directory" for webapps). I recommend putting that path in an injected resource (server JNDI) so you can change it without recompiling the WAR.

And never, absolutely NEVER attempt to write anything into a WAR. Even when it works, it's a ticking bomb.
4 days ago
The problem with technology books is that the instant they are published, they are already out of date. It really doesn't matter whether the format is dead tree, online, or ebook.

One thing that's always been good about O'Reilly books is that once you've bought the book, they keep the online edition updated (at least to a degree). And I did find it convenient to occasionally employ Safari when I had a corporate account. For that matter, I still occasionally grab some useful info when Google brings up a Safari demo page.

I've always preferred to surf the edge of technology, though, so for most day-to-day documents, I'm going straight to the project website. An independently-written book may serve as an introduction - and one reason I really regret the demise of dead-tree magazines is that sometimes a pre-introduction is even better - but the final authority comes from the project itself and I'm happy to say that most quality products have at least one literate person on-board (who may, in fact author one of the published books).

I do my light reading on portable devices. For several years now, that's been a 7-inch tablet. I don't find that size screen to be good for technical docs, however. I'd rather have paper. And I've always found reading long-term on a computer monitor to be hard on the eyes.

I got a 10-inch tablet for XMas and that's big enough to read documents scaled for US Letter/A4, which is what most PDFs are. In fact, I just uploaded one of my own technical documents yesterday, complete with an embedded circuit schematic. I haven't made up my mind yet about how well that would be for a day-to-day tech reading solution.
4 days ago