We Keep Coding

jQuery.post() with URL set as a Java weblet

I have a java app on my server and I can access it with my browser by going to server.com:8080/app.
I've been trying to get my application to access this weblet but because of XSS jQuery.post() gives me errors. Both the app and weblet are on the same server, but since I have to access the weblet through port 8080 Javascript thinks it's another server.
My question: Is there a way to avoid this XSS issue?
I don't want to use a PHP proxy or .htaccess. I also don't want to use the $.getJSON(url + '&callback?') method.
I'm looking for any other solutions.
Thanks in advance.

It' SOP(Same Origin Policy) that's stopping you here, not XSS. XSS is a security vulnerability, which breaks SOP. And yes it limits access so both pages have to run on the same protocol, port and domain.
Can you use a reverse proxy from the webserver on port 80 to 8080? If not you could take a look at easyXDM. Another alternative is to have the 8080 service return rhe access control header mentioned in one of your comments, but this is not supported in older browsers.

How to check if url exists over https in java

I know how to check if a url exists in using, see following posts.
Check if file exists on remote server using its URL
How to check if a URL exists or returns 404 with Java?
The problem is if a ssl https url exists, i tried all suggestions in the above threads, and while they work fine on normal http urls, none of them work on a https file.
Is it not possible?
Suggestions?

The normal methods that work with "http:" URLs should also work with "https:" URLs. If they don't, then the probable cause is not the code but something else:
The URLs might use a SSL certificate that is not acceptable to Java. It might be self-signed, it might use a root certificate that your JVM's certificate store doesn't include. It might be the wrong certificate for the site.
It might be a problem with your JVM's proxy configurations. (You can't proxy HTTPS).
The remote site might simply not be listening for HTTPS requests.
The remote site might filter HTTPS requests based on header fields; e.g. the agent header.
To help us help you find the problem:
tell us what URL you are trying to access,
tell us if the URL works for you using a web browser,
if there are exceptions, show us the stacktraces.

Security matter: are parameters in url secure?

I have developed myself in the last few months about web development in java (servlets and jsp). I am developing a web server, which is mainly serving for an application. Actually it is running on google app engine. My concern is, although I am using SSL connections, sending parameters in the URL (e.g. https://www.xyz.com/server?password=1234&username=uname) may not be secure. Should I use another way or is it really secure? I don't know if this url is delivered as plaint text as whole (with the parameters)?
Any help would be appreciated!

Everything is encrypted, including the URL and its parameters. You might still avoid them because they might be stored in server-side logs and in the browser history, though.

Your problem seems to go further than Web Server and Google App Engine.
Sending a password through a web form to your server is a very common security issue. See this SO threads:
Is either GET or POST more secure than the other? (meaningly, POST will simply not display the parameter in the URL so this is not enough)
Are https URLs encrypted? (describes something similar to what you intend to do)

The complete HTTP request including the request line is encrypted inside SSL.
Example http request for the above URL which will all be contained within the SSL tunnel:
GET /server?password=1234&username=uname HTTP/1.1
Host: www.xyz.com
...
It is possible though that your application will log the requested URL, as this contains the users password this may not be OK.

Well, apart from the issues to do with logging and visibility of URLs (i.e., what happens before and after the secure communication) both GET and POST are equally secure; there is very little information that is exchanged before the encrypted channel is established, not even the first line of the HTTP protocol. But that doesn't mean you should use GET for this.
The issue is that logging in is changing the state of the server and should not be repeated without the user getting properly notified that this is happening (to prevent surprises with Javascript). The state that is being changed is of the user session information on the server, because what logging in does is associate a verified identity with that session. Because it is a (significant) change of state, the operation should not be done by GET; while you could do it by PUT technically, POST is better because of the non-idempotency assumptions associated with it (which in turn encourages browsers to pop up a warning dialog).

servlets behind a proxy: getting un-proxied URL

Is there anything in the Servlet spec, Tomcat, or Wicket that will allow a webapp running behind mod_proxy to determine the non-proxied URL of the request?
We need to send out emails with links in them. I had been using the following bit of Wicket to construct URLs to specific pages in the app:
String relURL = RequestCycle.get().getRequest().getRelativePathPrefixToWicketHandler();
RequestUtils.toAbsolutePath(relURL);
Since the emails don't go back out through the proxy, of course the URLs don't get re-written, and end up looking like http://localhost/....
Right now the best I can do is to hard-code the URLs to our production server, but that's setting us up for some debugging headaches when running on dev/test machines.
Using InetAddress.getLocalHost().getHostName() isn't really a solution, since that's likely to return prod1.mydomain.com or somesuch, rather than mydomain.dom, from which the request likely originated.

As answered for the question Retain original request URL on mod_proxy redirect:
If you're running Apache >= 2.0.31 then you might try to set the
ProxyPreserveHost directive as described here .
This should pass the original Host header trough mod_proxy into your
application, and normally the request URL will be rebuild there (in
your Servlet container) using the Host header, so the schema location
should be build using the host and path infos from "before" the proxy.

Is there anything in the Servlet spec, Tomcat, or Wicket that will allow a webapp running behind mod_proxy to determine the non-proxied URL of the request?
No. If the reverse proxy doesn't put the information that you require into the message headers before passing them on, there's no way to recover it.
You need to look at the Apache Httpd documentation to figure out how to get the front-end to put the information that you need into the HTTP request headers on the way through. (It can be done. I just can't recall the details.)

How to interact with a java servlet running on glassfish with telnet?

I have a servlet hosted in the glassfish server. i want to communicate with it using telnet to understand what is going on behind the scenes when using html form get method.
What should i give in the Host field of the HTTP request?
Get /WebApplication1/NServlet HTTP/1.1
Host: localhost
If i want to send custom properties in the HTTP request as below, is it possible to extract their value using request.getAttribute() method.
Get /WebApplication1/NServlet HTTP/1.1
Host: localhost
Custom-Attribute: xyz
Another doubt is that is javax.servlet package not a part of java SE sdk. i had to install java ee to get it running.

The Host field is just the hostname part of the URL, e.g. Host: google.com for http://google.com/
Custom-Attribute: xyz would be exposed in the HttpServletRequest using getHeader(), not getAttribute().

If you want to use HTTP for your protocol (as you've suggested in your comments), check out HttpClient. As the name suggests, it's the client-side of the client/server HTTP implementation, and it should be relatively easy to determine what to set on the client side such that you see it on the server.
There's a great tutorial here. I would perhaps get a simple page working in the servlet first, and check it via the browser, and then implement the client side.

Based on your question, I don't there's enough information for anyone to answer you. Tomcat/Jetty/etc are basically web servers that contain servlets (and therefore JSP/JSF/Wicket etc etc) processors for dynamically generating content.
So, what is it you're trying to figure out, and why?