David Gallardo

You don't need to be logged in as root to install/develop/start/stop Tomcat. In fact, running as root is never a good idea.

For development, a regular account is preferable. You can either create a regular user account for Tomcat and use that, or you can use your own account. Either way, install Tomcat in a subdirectory of the user's home directory.

The only difficulty is that you will have to use a port above 1024, such as the default Tomcat port, 8080. If you want to use the standard HTTP port 80, you can get around this by starting Tomcat with sudo.
[ September 12, 2006: Message edited by: David Gallardo ]

Yes, you can instantiate the driver and register it as follows:
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
Yet another way is to use the DataSource API.
@D
[ August 02, 2003: Message edited by: David Gallardo ]

If you can do the data manipulation with SQL in a JDBC Statement (or PreparedStatement), you should do that. For example, you can sort and search using SQL. It's *much* faster and *much* easier that getting unordered, unfiltered data and sorting and searching in Java, because that's what a database is optimized to do.
In the rare instance that you feel you must do something programatically, you might want to double check with someone with more SQL experience, just in case there's are clever way to do it, using unions or nested queries, for example. If there isn't a way to do it with SQL, and performance isn't a big issue, try processing the data in your Java program, rather than adding an additional level of complexity by using stored procedures (either Java or PL/SQL).
If you seriously need performance, only then use stored procedures. (Depending on how much it interacts with the database, and how powerful the db server is, a stored proceduure can be an order of magnitude faster or more than an external program.) Java stored procedures are a bit slower than PL/SQL but they have the benefit that you can develop them outside the database, within your program and then later deploy in the database as stored procedures if it proves necessary for performance.
@D
[ August 02, 2003: Message edited by: David Gallardo ]

There are a couple of tutorials on developerWorks (one of which I wrote) that provide an introduction:
Java Design Patterns 101, David Gallardo
http://www-106.ibm.com/developerworks/edu/j-dw-javapatt-i.html
Java Design Patterns 201, Paul Monday
http://www-106.ibm.com/developerworks/edu/j-dw-javapatt2-i.html
You need to register to take them, but it's free. (And there are a lot of other good tutorials, too.)
Beyond that, Grand's Patterns in Java is pretty good. The standard, Design Patterns, by Gamma et al. uses C++ but it's still worth reading even if you are a Java programmer (esp. in conjunction with Grand's which will help clear up discrepancies between the languages).
@D

There's not really any advantage. It's just a matter of consistency since you need to use DataSource if you're using JNDI. Sun's hinted that they may deprecate the traditional method of loading/registering the JDBC driver explicitly and leave DataSource as the only technique for connecting to a database.
@D

I'd like to add a little to what Dan said about the CVS "prune directories" option. Selecting this option does not delete directories from the server; it only affects the way CVS checks out directories to your local workspace. If you have this option checked, and there is an empty directory, it will not appear (or will be removed) from you workspace the next time you update.
Since this does not affect the server, it means that if somebody else checks out (or updates) the project, the directory will appear if they don't have this option checked too. It's checked by default when Eclipse is installed, (at least in 2.1), but you might want to double-check that everyone on your team has it selected. Otherwise, someone might mistakenly put a file in it, and it will re-appear that next you update.
Contrary to what Dan said, directories are not put in the ATTIC, only deleted files. There is normally no way to delete a directory within CVS. If you *really* want to remove a directory, it is necessary to delete it from the server at the file system level.
BTW, another good source for additional CVS information is the standard reference, "Version Management with CVS" by Per Cederqvist et al., (usually called "the Cederqvist") available for free download at http://www.cvshome.org.
@D
[ July 23, 2003: Message edited by: David Gallardo ]

It's a piece of cake! Just make your changes and commit. Eclipse and CVS will take care of the details.
For example, I created a new package in a project and moved some existing files from another package into it by dragging and dropping them. Eclipse did the necessary refactoring automatically. I also deleted an obsolete file.
When I committed the changes (on my desktop) and then updated the project on another machine (my laptop) the new structure and file deletion were reflected.
@D
[ July 22, 2003: Message edited by: David Gallardo ]
[ July 22, 2003: Message edited by: David Gallardo ]

I'm not familiar with MyEclipse, but the plugin for JSP/Servlet development that I'm familiar with (and the one that we cover in our book) is the Sysdeo plugin. It lets you debug servlets just like any other classes.
Debugging JSP pages is only a little more complicated. As you're probably aware, JSP pages are converted to servlets and compiled behind the scenes by Tomcat. The corresponding .java (and .class files) can be found in the /work/org/apache/jsp directory. These can be debugged like any other servlet or class and it's easy (and sometimes enlightening) to to see how the Java code relates to the JSP code.
@D
[ July 20, 2003: Message edited by: David Gallardo ]

As I understand, JDeveloper 9i was major improvement over 8i. (I've only used 9i, never 8i, so I can't vouch for this personally.) Where 8i was essentially Borland's JBuilder re-branded, 9i is a thorough and well-done overhaul. It's got lots of features specifically designed for working with Oracle's products, and if you're doing Oracle development--esp. if you are using their application server--it may be your best choice.
If you aren't tied to Oracle, however, (or if you are using Oracle in a fairly generic way, e.g. via JDBC), there are other products with more features you might wish to consider.
[ July 19, 2003: Message edited by: David Gallardo ]

Refactoring is changing the structure of a program without changing its functionality. See here for more information: http://www.refactoring.com/
Eclipse has the ability to perform over a dozen common refactorings automatically, from renaming a Java element (method, attribute, class, package...) to extracting hardcoded strings and placing them in a resource bundle. It's pretty powerful stuff & a little time spent learning about what's available is a worthwhile investment.

There are three things I consider critical in an IDE:
- Open source
- Native look, feel and *response*. (See SWT thread elsewhere.) Java apps that don't respond to shortcuts that work on every other app for the platform really annoy me--I'd rather use vi (seriously).
- Good debugging tools
In my experience only Eclipse meets the first two criteria. Prior to 2.1, Eclipse fell short on the third, but this has been remedied in 2.1.
I was somewhat pre-disposed to like Eclipse because of its roots in Visual Age for Java. There were a couple of Smalltalk-ish things I didn't like about VA4J, (the Envy repository in particular) but Eclipse "fixed" that.
[ July 11, 2003: Message edited by: David Gallardo ]

I'm using TJDO (http://tjdo.sourceforge.net) and as far as I'm aware there is no plugin available for this free implementation. I have compilation set to manual and then use an Ant script (based on on the script shown in the TJDO doc) to run the enhancer after performing a build. It's a little inconvenient, but a serviceable method.
Some of the commercial implementations do have Eclipse plugins--Kodo and Lido, e.g. If you don't mind a non-open source implementation, you might check these out. I've used Libelis Lido in the past (but not with Eclipse) and it seemed a pretty solid JDO implementation. They have a free community edition for non-commercial use with opensource RDMSs.
Check this page out for some db related plugins, including the Kodo and Lido plugins:
http://eclipse-plugins.2y.net/eclipse/plugins.jsp?category=Database&pager.offset=10
If you get a chance to try any of these out, I'd be interested to know what you find!
Thanks --
@D

Tips and tricks are presented throughout the book, where it makes sense. But the best place to get a comprehensive list is in Eclipse. Select Help->Tips and Tricks from the main menu. You can then browse through tips and trick for either the JDT, the platform or the PDE.

The original example I had in mind for the book was a web application using servlets/JSP that lets a user store and manage information of some sort. But this required a persistence mechanism of some sort, and I didn't want to go off on a tangent about databases.
At the time I was planning this book, (end of last year), I was working on a web application for a client and was thinking of using JDO for persistence, but there was no free implementation then, so I was toying with the idea of rolling my own. After playing around a bit with Java's reflection API and creating objects from data dynamically, I decided that while it wasn't a good idea to develop my own implementation of JDO on my client's dime, it would be fun and interesting nonetheless to develop a persistence component, loosely based on JDO, and using files (instead of a database), to use for the book's examples. I know object-relational mapping has been done to death, but I thought if I found it fun and interesting, others might, too.
The resulting persistence component, developed throughout chapters 3-6, turned out to be (in my judgement at least) a good-sized example--not trivial and not overwhelming. It presented some interesting object-oriented design problems and it let us exercise Eclipse features realistically. Throughout, I mostly stayed true to agile development techniques; occasionally I found I had to refactor as I took more considerations into account and expanded the design.
The payoff, of course, is that it provides the persistence for the small web application that is finally developed in Chapter 7.
@D

Eclipse in Action is primarily geared to developers who want to develop *with* Eclipse, and not *for* Eclipse.
Chapters 2--7 essentially walk you through the development process and introduce you to the tools you need to get the job done. (Testing with JUnit; coding, debugging and refactoring; Ant, CVS...). The intention being to show developers how to get up to speed quickly and use Eclipse effectively, using (more or less) real-world examples.
Having said that, we also wanted to provide a least a good introduction to the other two aspects of Eclipse that people would find of benefit: developing plugins and SWT/JFace. Both of these topics clearly deserve books on their own, but I think the chapters on plugins are more than enough to get started.
I've only skimmed through the Shavor book, so I can't comment definitively, but it seems to me complementary to ours. I'd think a potential Eclipse user would want to read ours cover-to-cover to learn Eclipse, but might consider purchasing "The Java Developer's Guide to Eclipse" as a reference, (esp. since the Eclipse online doc is a little bit too terse at times), or to delve more deeply into the details of particular features.
(Not to sell our book short, however; for example, Appendix A, Java perspective menu reference, provides explanations and examples for all the refactorings that Eclipse can perform.)
You asked about plugins. We mention and use a few in the course of the book such as XML Buddy and the Sysdeo Tomcat plugin. (We also discuss how to install and use other third-party software (Tomcat, log4j, CVS server). We don't provide a survey of plugins that are available, but we do mention that by going to the community page on the Eclipse website you can find many more. The plugin scene is pretty volatile and active and some plugins that weren't ready for primetime at the time of writing may be ready now. (And some that were free betas may now be commercial products.)
Hope that contributes to a better understanding of the book!
@D