Mario Minutolo

You cannot put you return code only inside the 'try' block.
Either you put it at the end of the member function or both inside try and catch block.

Originally posted by Bear Bibeault:

It comes down to which to use... a light-weight, well-behaved on-page citizen like jQuery, or a hyper-invasive library such as Prototype. The choice comes down to an engineering decision on the part of the page authors.

As I said before, what I like best is YUI, because it's quite simple and (as you said) lightweight, and it takles with CSS too.

jQuery is becoming a sort of standard, being JBoss javascript library of choice... and then you have the google APIs.

I would not get stuck with javascript 'framework' bigger then those cited before, because you will quite often have to merge different libraries and use javascript apis by various vendors.

Libraries which redefine 'objects' or relies too heavily on events, tends to become a square peg on a round hole, when mixed with other libraries/APIs.

Try tcpview TCP View (download), I suspect you have rather some TCP problem then eclipse/tomcat problem.
With tcp view you can 'see' what socket your apps try to open, so you may understand what is failing.

Other then that I think I can't help much more, being a problem of a specific machine, you can do so much without having access to the machine itself.

Originally posted by Bear Bibeault:
You seem to think that all frameworks "hide" JavaScript. Not so. Some are more intrusive than others.

I don't think most of the library/frameworks hide javascript, but they do hide the 'grisly details', the worst of which are ... browser compatibility.

It's not so difficult to implement something in javascript for Firefox 2 for example, but if it must work for IE6, IE7, Firefox 1,2,3 and maybe Opera ... then you are in for a lot of pain.

Both for javascript and CSS. YUI , jQuery and others, at least secure you against most of the pitfall of browser compatibility.

YUI and jQuery don't hide the javscript, but at lest they try to hide the browser.
[ August 26, 2008: Message edited by: Mario Minutolo ]

Originally posted by Ulf Dittmer:

... which is of course precisely what the article I linked to explains in detail.

I saw, and I concord with you, but, I still like to explain, even briefly in post, what is all about because too many time I found a post with a solution I needed and the link pointing to the solution was broken (so frustrating!!!).
[ August 26, 2008: Message edited by: Mario Minutolo ]

Originally posted by Michael DeChirico:
Mario Minutolo,

Ok I'll bite, how does one "flush the buffer"???

Michael

out.flush();

... still I would advise you against reading 'lines' , a missing terminator could get your whole application stuck.

Originally posted by george st. clair:
Hi Mario,
before i start the tomcat server netstat shows that nothing is using 8080 in any way. After I've started tomcat then the following is happening on those ports:

TCP MAGNESIUM:8009 magnesium:0 LISTENING
TCP MAGNESIUM:8080 magnesium:0 LISTENING

Then, if port 8080 is listening, you should be able to open http://localhost:8080/[webapp-name]

If you have not deployed an application yet you should get a 404 error, which is fine (means tomcat is working, even if you don't find the page).

I cannot give you an answer without inspecting (sniffing) the conversation between client and server ... but 99% of the time the problem is about buffering.

When you write on a socket you normally flush the stream on need, or the stream get flushed onto the socket when the buffer has reached capacity.

If you have a sniffer you can check what is going on, if not, this are the most frequent pitfalls of socket communication.

1) The outputstream is buffered, but is not flushed.
If you use buffered streams you must be certain to flush them after completing a 'message'.

2) The inputstream uses 'line-terminators' which are not sent.
Some stream expect some kind of line terminators, (for example CR LF) which are not sent, the 'reader' in this case will lock, waiting for those markers.

Both this error applies to server and/or client, so sometimes the client is not flushing or viceversa, or the client waits for 'line-termination' or is the server waiting.

Without a sniffer, it is diffucult to understand what is going on, but you can guess what's happening reading one byte at a time.

Be sure to flush buffered stream.

Best Luck
(with sockets you need it)
[ August 26, 2008: Message edited by: Mario Minutolo ]

Originally posted by aadhar sharma:
Tried doing the same as you have suggested.
I have used the same format cal.set(2008, Calendar.SEPTEMBER, 1);
but still the problem exists


This is like 1==1 returning false.

this code I tried and it worked.

package it.minus; import java.util.Calendar; import java.util.Date; public class Test1 { public static void main(String[] args) { Calendar cal = Calendar.getInstance(); cal.clear(); cal.set(2008, 8, 01); Date dateConstant = cal.getTime(); System.out.println(dateConstant.getTime()); System.out.println(compareDates(dateConstant)); } private static boolean compareDates(Date effectiveDate){ Calendar cal = Calendar.getInstance(); cal.clear(); cal.set(2008, 8, 01); Date dateConstant = cal.getTime(); if (dateConstant.compareTo(effectiveDate) == 0) return true; return false; } }

Try :
netstat -a
At least we can be sure no ports are already in use.

Originally posted by aadhar sharma:

Calendar cal = Calendar.getInstance();
cal.set(2008, 8, 01,0,0,0);
Date dateConstant = cal.getTime();

I do it like this, seconds and milliseconds are differnent things.

Calendar cal = Calendar.getInstance(); cal.clear(); cal.set(2008, 8, 01);

Originally posted by Lanny Gilbert:
[...]
why would one want to trouble oneself to learn the gritty details of JavaScript when you can use a framework to hide all that stuff?? [...]

I use solid javascript frameworks whenever I can. There are a few around, just check they are being still developed, and have a solid userbase.

The trouble is that no frameworks does all, and even if it does... it not just exactly what you need.

So sometimes you need to use 2 frameworks or 2 libraries, or just do a bit of coding yourself.

When you do so, you need to code quite a bit to merge different libaries or to use a certain framework in a situation which is not quite the one on the demo page.

For what I'm concerned I like YUI, which is agnostic, so you can adapt it easyly.

Originally posted by Devasia Manuel:
How do I make networked programs work across countries or at least in the same city. I just want to know how I can make networked programs work outside my network.

The same way you make local network programs (more or less).
Probably your problem is not a java problem, but an IP problem.

If your address is a private one, which most cerainly is, you simply cannot be reached from outside.

The same applies to the other side of the communication (if it has a private address, cannot be reached).

You need to develop a chat server a publish it.

Originally posted by Abhi Bhutani:


So i need an explanation that 'Why is c3 not eligible for gc since it references a null object that it obtained from the method go'.

c3 is not eligible for garbage collection because it does not refer to any instance of an object.

c3 is just a reference to null, so nothing can be garbage collected.
[ August 26, 2008: Message edited by: Mario Minutolo ]

Originally posted by satish bodas:

My only query is - so what really does the class loader do ?
what would have happened if only one classloader did the loading of all three ( two apps and one jar )

Classloaders in a webapp are arranged into a tree structure.
There is a root classloader which belongs to the 'server' and then there is the common classloader, which is shared between apps, and then there is a classloader for each webapp.

Since webapp are distinct entities, must keep their resource 'private', using a classloader per webapp enforce this policiy.

You should not access resouces of a webapp from another, using differnt instance of a class loader you cannot do this, so you can't violate this fundamental policy of a web-application.