Fletcher Estes

Ranch Hand
+ Follow
since Jul 01, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Fletcher Estes

People don't generally use Vector anymore because synchronization is slow and because in Vectors every method is synchronized, you can take a serious performance hit. Not only that, but as we've discussed, Vectors are synchronized at the wrong level.

Of course you still want thread safety with ArrayLists, but you can achieve it by synchronizing at a more appropriate level, depending on your needs (perhaps by synchronizing the method in your class that uses the ArrayList). If you want an ArrayList to perform exactly as a Vector, you can add a wrapper (using Collections.synchronizedCollection()).
[ February 15, 2005: Message edited by: Fletcher Estes ]
Thread safety is a rather large concern affecting applications, and that is why there is no simple trick to ensuring it. Hence the caution "using Vectors does not guarantee thread safety".

Absolutely, if you have a single Vector, you are guaranteed that only one method is called at a time on that Vector. At that very fine level, it is thread safe. The problem is that you generally want to perform groups of operations which count as a single logical action (let's say transaction). Problems will occur if multiple threads try to execute these transactions on the same Vector at the same time, unless things are synchronized properly at a coarser level.

Your problems may be exacerbated when you involve multiple vectors, all being accessed simultaneously by multiple threads. Remember - multi-threaded applications are complicated for us humans to grasp properly, and we need to think long and hard about how they will function.

"Thread safety" is a somewhat misleading term. Instead think "will my program do exactly what I think it will, in all circumstances?"
Any time you use the '+' operator on Strings, you're creating a new object. Creating new objects is much slower than manipulating existing objects, so for that reason it is recommended to use a StringBuffer if you are performing multiple String concatenations in your code.

Using the append() method of StringBuffer, you do not create any new objects, but simply fill out spaces in an already-existing array.

There is mountains of info about this on the web, check out Google
19 years ago
I will do your homework if you give me $800. Make that $900. Still interested?
19 years ago
I whole-heartedly agree that the WA threads are little short of autistic. If you really want to spend your time on such endeavors, is it really fair to inflict it on the rest of the JavaRanch community? Can't you just write a program that will spit back a word at you every time you input one?

You can print out the lists and post them around your room at home. It'll be ever so much fun! Go and play now, go on... :roll:
[ February 02, 2005: Message edited by: Fletcher Estes ]
19 years ago
The only similarity between HTML and JSTL is that the tags are surrounded by angle brackets, so, no, I don't think it is an easier extension than using Java code.

My main point though is that it is developers, not web designers, who write JSPs...
Your project sounds like a perfect fit for Struts. Here's a good step-by-step guide. The best book I've read on Struts is Programming Jakarta Struts. Also there's reams of info from the horse's mouth.

You need to think about where you're going to store your data (here's good) and how you're going to access it. Straight JDBC access is outdated and difficult to work with - take a look at some alternatives (out of which I'd recommend Hibernate).

The best thing about all of this is it's free!

[ January 21, 2005: Message edited by: Fletcher Estes ]
This seems to be a serious flaw - could any of the Bartenders with Sun connections investigate this???
For the DHTML, you will need to write HTML code, CSS files and JavaScript. You may find it faster to throw something together in Dreamweaver - it just depends on your preference. The user will be able to click through one static .HTML page to the next, get to see client-side validation (eg. pop-up boxes like: 'User ID is required'), and be presented with dummy data that looks like the type of data drawn from a database. This is how you achieve the look and feel, and it is a bit of work to produce the demo, but it's much faster than actually writing the application. Keep in mind that you don't have to do any of this, but if your customer wants to see what they will be getting ahead of time, it's a great technique. If you suspect the HTML will change in the future, it doesn't matter - it's easy to change, and anyway the customer will have agreed on something at the start.

As for the data: you need to document what DB tables and fields in those tables are used to produce any dynamic content on the JSPs (eg. the text box customerID is populated from CUSTOMER_TABLE.CUST_ID) and also specify where any user-entered data will be stored when they hit 'Submit' or whatever.

People use technologies like Struts and EJBs because it makes application loosely coupled (altering one part does not affect any other part) and highly extensible (easy to modify/adapt to new needs in the future). How many of these frameworks and technologies you use depends on the size of the application, and your future needs. I would recommend Struts over developing your own MVC model if your application caters for more than 5/6 use cases. It introduces rigour and consistency into your design and will reduce development time (once you learn it), while also externalising as much as possible to XML files. How do you intend accessing the DB?

I use Eclipse 3.0 for development - it's second to none.
In your struts-config.xml, you can specify what users (roles) have access to certain actions as follows:

<action path="/Whatever" roles="admin,manager" etc....>

If the logged in user is not in the specified role (as determined by request.isUserInRole(roleName)), or not logged in at all, then the server will generate an HTML 401/403 error and go to the appropriate error page as specified in your web.xml (that's an assumption - I'm not sure exactly what happens)
19 years ago
I have to take issue with Sun's suggestion that JSTL and EL makes JSPs "scriptless" and "easy". The JSTL is so finely grained, and mirrors straight code so closely, that all it does is double the amount of learning required. Sun would suggest that web-designers find it easier to use tags instead of straight Java code - is there any evidence to support this?

I've been working for a few years as a software engineer, and anybody I've worked with who is writing JSPs also writes Java classes. Application programmers write JSPs, not web designers. They know Java. Java is strongly typed and easily debugged. JSTL tags are arcane and highly dependent on deployment descriptors, library and container versions. Bottom line - they are harder to work with, and ultimately unnecessary.

${myObj.val} is supposed to be some improvement over <%=myObj.getVal()%>?? :roll: At least there's only one way to write <%=myObj.getVal()%>. With EL, multiple expression styles are provided which result in the same thing. This is complexity, not ease of use.

I appreciate the facility to be able to write custom tags, and the tag files introduced with JSP2.0 are definitely a step in the right direction, but with JSTL and EL, I think Sun may have lost sight of their audience...
[ January 19, 2005: Message edited by: Fletcher Estes ]
Hi Kitty, I've been working as a J2EE software engineer for a couple of years, and this is how the projects usually go:

1. Business users and analaysts get together and discuss what they need the product to do. A list of requirements is drawn up and this becomes the requirements document, e.g. application must provide the facility to edit the text on the following web pages... application must prevent unauthorized access etc. It is also common at this stage to consider the usage/load requirements,development time involved, necessary hardware, support requirements and hence budget available to meet these needs for the forseeable future

2. Using the requirements document the business analysts and UI designers come up with a set of screen shots (often a demo too using dynamic HTML) that show how the application will look and feel, and what the inputs and outputs will be, where the data comes from, and where it goes after the various use cases are complete

3. Using the information from step 2 (this is where I come in!) a detailed design document is drafted. The document first describes the high level architecture, technologies and hardware involved. Next it will specify exactly how all the pretty screen shots will work behind the scenes (through UML sequence, class, and activity diagrams). The UML will explain what exactly happens from the moment a request is received to the time the response is committed. Decisions about every layer of the application must be tied down, such as how is security handled(is there an LDAP server we authenticate against, will we use ceritificate-based encryption), how will DB access be achieved(with a framework like Hibernate maybe, or a straight coded DAO pattern), how will logging take place/what will be logged(Log4J, commons logging), how will the application be configured/initialised, how will input validation occur(commons validator), how will the views be rendered(JSPs, tag libraries), what design patterns are going to be employed etc. etc. etc. The most common patterns I use are the MVC(a la Struts),Session Facade(Sessions EJBs),DAO(Entity EJBs),Value/Transfer Object,Service Locator,Template,Abstract Factory. If any of the design seems unfeasible, we may need to go back to the end user and ask if they really, really need a particular piece of functionality

4. The design document is reviewed by a panel of experts external to the project, and if it passes...

5. Coding begins: the framework is put in place, some prototype code is written to ensure all the layers work individually and are happy with each other, and then coding of the use cases begins. I would usually write the JSPs first (hopefully the CSS files would be provided), then write the Struts action classes, then any DB access code. After each logical module of code is complete, it is unit tested using one of the extensions of JUnit (usually StrutsTestCase for the front end, or Cactus for testing EJBs). Throughout coding there will be communication with the end users to clarify anything that needs more detail

6. When all the code is complete and satisfactorily unit tested (does it do everything we said it would, and in the way we said it would do it?) The application is deployed in a Systems Integration Testing environment where it is picked apart by a QA team. Any bugs thrown up are fixed (if possible) by the coders, and after SIT, it is passed to the end user for the final stage of testing. Hopefully by this stage they like the application and don't demand any extra functionality that they allegedly asked for at the beginning. They usually will make some ridiculous claims at this stage, so it's best to get everything in writing all the way through!

7. Oh yes... someone has to support the application in case anything goes wrong when it has been deployed to the production environment. Hopefully that person isn't me!

Hope this gives a bit of insight - as for a complete example, it would be unusual to find one freely available because it's a lot of work to produce a "medium" sized J2EE project and people need to protect their investment. I'm sure some smaller complete examples are available in books...
[ January 19, 2005: Message edited by: Fletcher Estes ]
The destroy() method will only be called when the application, or the server, is stopped or restarted. When a browser sends a request to a servlet, the container does not actually invoke the service() method directly, but rather creates and starts a Thread whose run() method invokes the service() method of the servlet instance in memory (always the same one, unless, confusingly, the SingleThreadModel interface is implemented by the servlet).

This way, it does not matter how many clients access the servlet at once, the container can just keep creating more threads (within reason).
Steven, can you post your entire web.xml and JSP file? Also, are you sure your JSP is being loaded by Tomcat as a servlet - there should be a log message confirming this when you start the server.
It says the exception was thrown during actionExecute() - but it is possible to step into this method to see exactly what line of code caused the exception. If you don't want to step into all these methods, put a breakpoint at the start of your PAAction (I presume this is the action being called by your test case).

If you get to that breakpoint, then you'll be able to step through to the underlying problem. If you never get to that breakpoint, then you know you have a configuration issue with StrutsTestCase.
19 years ago