Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!

Kelly Loyd

Greenhorn
+ Follow
since Oct 10, 2005
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 Kelly Loyd

Yep, you sure can!

If you look at what I wrote above, I have defaultwebapp pointing to the 'original' webapp directory.

Then you setup a videos and reverse applications as a separate applications

In application.xml

<web-module id="defaultWebApp" path="../default-web-app" />
<web-module id="videos" path="../applications/videos.war" />
<web-module id="reverse" path="../applications/reverse.war" />

In default-web-site.xml

<default-web-app application="default" name="defaultWebApp" />
<web-app application="default" name="videos" root="/videos/"/>
<-- <web-app application="default" name="reverse" root="/"/> -->

I commented out the reverse servlet stuff to put back the defaultwebapp.

You could also change the reverse servlet stuff to be in it's own directory, like this:-

<web-app application="default" name="reverse" root="/reverse"/>

The problem happens because during the assignments, you 'mask' the root directory with the reverse servlet.

After these changes, you can do this:-

http://localhost/ will go to \orion\default-web-app\index.html

http://localhost/videos will go to \orion\applications\videos\index.html

http://localhost/reverse will go to \orion\applications\reverse\index.html

Orion will unpack the specified .war files into the proper directories.
For example, videos.war will be extracted into \orion\applications\videos

Cool, eh?

Kelly
14 years ago
Hi Carol,

When you edit the config files for orion according to the assignment instructions, it seems to disable the defaultwebapp. So nothing under the root works (e.g. /form.html). Check these files under \orion\config directory.

I went back to default-web-site.xml and made sure these lines were uncommented.


Then I checked application.xml and made sure these lines were uncommented.


Then I was able to access all of the files from the server root (http://host/)

Give it a spin!

Kelly
[ February 19, 2006: Message edited by: Kelly Loyd ]
14 years ago
Woo hoo! Go the new screen - didja get the cool LCD monitor you wanted?

Um - the above might be Aussie slang. I kinda forget which idioms I am using from time to time...

Nice to have you back mate!

Now get back to work on those servlets
---
Just what makes that little ol' ant
Think he'll build that web servlet code
Anyone knows an ant, can't
build that web servlet code

But he's got high hopes... he's got high hopes
He's got high apple pie in the sky hopes.

So, any time you're gettin' low, 'stead of lettin' go, just remember that ant
Oops, there goes another web servlet code!

-- with apologies to Jimmy Van Heusen and Sammy Cahn
14 years ago
Yep, it feels great to pass another section of the Cattle Drive.

I learned a lot about Servlets that I did not know. The javaranch classes are really useful and help make an easy to implement MVC.

Something I'd like to pass on to my fellow Cattledrivers, If you get really really stuck on something, just ask your friendly nit-picker. They have the full experience of the Cattledrive behind them and they have the instructor's solution for reference.

My nitpicker Marilyn has guided me in the right direction without giving me the answer every time I asked a question. We have even had a couple of good debates.

Remember, the Nitpickers are people too and they have done the Cattledrive themselves.

Cheers,
Kelly
[ February 08, 2006: Message edited by: Kelly Loyd ]
14 years ago
Hi Stuart,

Keep on truckin'! You will succeed. Say 4b is probably one of the toughest assignments. It took me 5 attempts to get it - but boy howdy did it feel like I had accomplished something when I passed!
14 years ago
Stuart,

You are sending to nitpick@javaranch.com ? That is where I have sent all of my assignments.

It will go to the right person. Or I think, a nitpicker will get it from the 'inbox' queue. As it turns out, Marilyn has done all of my assignments, you may get a different nitpicker.

Cheers,
Kelly
14 years ago
Hi Adam,

I second this sentiment - "Just Send It In" - don't fear the nitpick That's what you paid for, right? I have learned lots so far just by letting the nitpickers do their job.

I have learned that Readability is more important. For many years, I enjoyed writing compact, often obfuscated code. With todays optimizing compilers, etc., it is preferrable to have the code be Readable and understandable by others. Too many times I have had to decipher what someone else has written, even by alleged 'professional' software organizations.

So make it easy to read and understand and let the compiler designers worry about the optimizations.

Cheers and Welcome to this big ol' Cattle Drive
Kelly
[ January 01, 2006: Message edited by: Kelly Loyd ]
14 years ago
It was a direct result of the nitpick process. Marilyn 'pointed' me in the right direction and with a little experimenting, I learned something really neat about ActionServlet.

The educational value of the Cattledrive has far surpassed the small amount of the purchase price.

Challenging my assumptions has made me learn more.

--- Now working on Servlets-4b - but no submission as yet.
[ January 01, 2006: Message edited by: Kelly Loyd ]
14 years ago
Hi Stuart,

Here is a hint: I did not use division to calculate the line break, therefore 'divide by zero' exceptions cannot occur.

Cheers,
Kelly
14 years ago
Thanks Pauline!

The Cattle Drive has been very worthwhile. My fellow workers who are "JavaHeads" have never heard of the JavaRanch and now want me 'show' it at a staff presentation. Fancy that!

Cheers,
Kelly
14 years ago

Our more recent students have been less verbose.


Hey! I resemble that remark!

I have just completed the Basic Section and I have posted my comments in the the same thread as above.

Cheers,
Kelly
14 years ago
There are many fine sentiments expressed in this thread, so it feels like 'gilding the lily' to add more. However, I feel that it is important to re-iterate the outstanding value-for-money that is the Cattle Drive.

Firstly, let me state that I have been writing programs since 1977, when I built my first single-board computer. It was programmed in hexadecimal using hand-assembled assembly source code. You keyed in each byte on a hex keypad and viewed your results on a 2 digit hex display. Primitive? You bet! That is when I became fascinated with the idea that you could make a piece of hardware do all kinds of things just by changing the codes.

From FORTRAN to BASIC, thence PASCAL, C and quite a few '4GL' style systems, I have been trying to get a good handle on Java for some years.

Doing the 'Java Tutorial' and trying to learn Java from books was simply not enough. I needed to know that I was doing 'it' the best way I could.

--- Enter the Cattle Drive and the nitpicking process ---

You read the assignment, you write a program, it works. Yay!
Then you submit it and find out what you didn't do right. D'oh!
Repeat until it is right.

This is the embodiment of 'Continuous Improvement'. We get code better by increments. Eventually, it sinks into my brain and soon I begin to remember the lessons every time I start to write some code.

There is also the sense of pride and achievement when you do complete an assignment and finally, the whole series of a section. I passed the Basic Section this week. I mentioned to Marilyn that I felt as if I had really achieved something and not just copied examples from a book and written a few small programs.

Sure, I can write software that works - I do it all the time. So do a lot of other people!

Writing software that works and is efficient and is easy to read and comprehend (for the poor soul who has to maintain it - and yes I have been that monkey.), is the real challenge and I feel that this is where the Cattle Drive is pushing me.

Kudos and Thanks to the nitpickers, I'm looking forward to the next section - OOP(s)

It's all good,
Kelly Loyd
14 years ago
Hi,

My guess is that calling the close() should release any resources associated with the InputStream, but leave the connection open, only if the connection is persistent (and probably shared).

I think what the API is saying is that the Java Virtual Machine won't guarantee what happens to the connection underneath all of this.

If you do a netstat -an | grep :80 , you will see exactly what is happening with the connections.

Your mileage may vary!

Cheers,
Kelly
14 years ago
Hi David,

I suspect that you would be using PrintServiceLookup, which is an abstract class provided with the JRE by default.

This class is not dynamic and only loads the default printer when the JVM starts up.

If you need full dynamic printer lookup, there are two options.

1. Subclass PrintServiceLookup and do your own implementation of lookupDefaultPrintService which checks the Windows printer queues. (Fun)

2. Try a third party print solution like Saffron.

I did a google for 'PrintServiceLookup' and found the Saffron web site. They have a class that overrides PrintServiceLookup amongst other things.

The problem with printing is that it is very very platform specific!

Hope this helps,
Kelly
[ November 02, 2005: Message edited by: Kelly Loyd ]
14 years ago
Hi,

If you are opening an HTTP type of URL like http://java.sun.com, then the method will return an HttpURLConnection object, which will then have it's connect method called when the getInputStream happens.

See HttpURLConnection

Here's what the API has to say about it.

Each HttpURLConnection instance is used to make a single request but the underlying network connection to the HTTP server may be transparently shared by other instances. Calling the close() methods on the InputStream or OutputStream of an HttpURLConnection after a request may free network resources associated with this instance but has no effect on any shared persistent connection. Calling the disconnect() method may close the underlying socket if a persistent connection is otherwise idle at that time.



So the answer is - depends on your particular TCP/IP stack implementation. From experience, the Microsoft stack leaves connections in a 'time wait' state for a long time - yuck.

Treat it like garbage collection - close the stream when you are done with it and then let the JVM and underlying system worry about the network resources.
[ November 02, 2005: Message edited by: Kelly Loyd ]
14 years ago