I have installed Oracle Developer Suite 10g release 2(Complete), which leaded to installed standalone OC4J. Now I am trying to Testing OC4J's default configuration.
I started the OC4J instance through Start> Search for oc4j> clicked oc4j batch file. OC4J is initialized now.
According to the docs...
https://docs.oracle.com/cd/B14099_19/web.1012/b14361/config.htm#i1049203
I tried to test it by accessing http://localhost:8888/ from a Web browser.
Unfortunately, the result is...
localhost refused to connect.Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
According to the docs, I also tried...
http://localhost:8888/servlet/HelloWorldServlet, which should return a "Hello World" page.
Unfortunately, same result was produced...
localhost refused to connect.Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
I also tried starting the server using...
java -jar oc4j.jar
from J2EE>Home directory, and tried both links mentioned above...
http://localhost:8888/
and
http://localhost:8888/servlet/HelloWorldServlet
And the result was...
404 Not Found
Resource / not found on this server
and
404 Not Found
Resource /servlet/HelloWorldServlet not found on this server
respectively.
P.S. I have a static IP address.
What could be the cause for that?
Related
I am new to node.js and am trying to get into the hang of actually using it. I am very familiar with JavaScript so the language itself is self-explanatory but the use of Node.js is quite different from the browser implementation.
I have my own remote virtual server and have installed Node and the Package Manager and everything works as expected. I am not exactly a server extraordinaire and have limited experience with the Terminal and Apache Configurations.
I can run my server using:
nodejs index.js
Which gives me: listening on *:3300 as expected.
I can then access my localhost from the terminal using: curl http://localhost:3300/ which gives me the response I expect.
Given that the website that links to my server is https://example.com, how do I allow this link to access: http://localhost:3300/ so that I can actually use my node server in production? For example, http://localhost:3300/ runs a Socket Server that I would like to use using Socket.io on https://example.com/chat.html with the JavaScript:
var socket = io.connect('http://localhost:3300/', {transports: ['websocket'], upgrade: false});
Ok, this question has nothing to do with nodeJS.
localhost is a hostname that means this computer. it's equivalent to 127.0.0.1 or whatever IP address you can refer to your computer.
After the double colon (:) you enter the port number.
So if you want to make an HTTP call to a web-server running on your server, you have to know what is the IP address of your server, or the domain name, and then you call it with the port number where the server is running.
For Instance, you would call https://example.com:3300/chat.html to make an HTTP call to a server running on example.com with port 3300.
Keep in mind, that you have to make sure with your firewall configuration, that the specific port is open for incoming HTTP requests.
I am trying to setup the basic hello world example.
I am using a t2.micro instance with Ubuntu 14.04 LTS and I have the github code for the example on my local machine.
The url I am using is:
https://localhost:8443/index.html?ws_uri=wss://ec2INSTANCE:8888&ice_servers=[{"urls":"stun:stun.l.google.com"}]#
I do not have the stun or turn configured on the server, but it should be ok since I am passing the stun server to use in the url.
Any advice on this?
I just checked my console and I see this, even though port 8888 is open in AWS Security group that this instance is in
VM8812:35 WebSocket connection to 'wss://ec2Instance:8888/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
I was able to get past the issues that I was seeing
Follow basic instructions on a fresh EC2 (Ubuntu 14.04 LTS), using http://doc-kurento.readthedocs.io/en/stable/installation_guide.html
Add a STUN server in conf
Using stun:173.194.66.127:19302
Tested with http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Secure WS to use WSS, which is required due to HTTPS requirement since Chrome 47, using http://doc-kurento.readthedocs.io/en/stable/mastering/securing-kurento-applications.html#configure-javascript-applications-to-use-https
Uncomment secure section of /etc/kurento/kurento.conf.js
Create the self signed certificate, and placed in /etc/kurento
Go to https://ec2InstanceUrl:8433/kurento and accept insecure connection
Go to example https://ec2InstanceUrl:8443
You must verify that your STUN server is working by seeing something similar to the below image, with the srflx under Component Type.
I'm using Vagrant with apache2 and specifically the command
vagrant share --https 443
It all starts fine and provides a URL. When I access that URL I'm presented with a 400 error:
Bad Request
Your browser sent a request that this server could not understand.
Apache/2.4.12 (Ubuntu) Server at *.vagrantshare.com Port 443
I have been accessing the vagrant machine using https just fine, but it doesn't seem to like to work with vagrant share.
This is a known Vagrant Share bug: https://github.com/webdevops/vagrant-docker-vm/issues/51
The only workarounds I've seen discussed are to use a custom domain or to use another product entirely (e.g. ngrok) to create the share. See the bug discussion here: https://github.com/mitchellh/vagrant/issues/5493#issuecomment-159792794
Vagrant Share docs for custom domains are here: https://atlas.hashicorp.com/help/vagrant/shares/custom-domains
We are using NSS as SSL engine in Apache server. Recently we applied latest SUSE Linux Enterprise server patches on Apache server which is hosting two IP based virtual hosts. After upgrade the first virtual host is working fine but the second one is not working.
Error log shows "Hostname vhost1.xxyyzz.com provided via SNI and hostname vhost2.xxyyzz.com provided via HTTP are different" when accessing vhost2.xxyyzz.com.
If we switch back to use mod_ssl the issue was gone. Obviously the issue is related to the following patches. Any help would be appreciated.
mozilla-nss 3.16.4-0.8.1
mozilla-nss-tools 3.16.4-0.8.1
apache2-mod_nss 1.0.8-0.4.9.1
Check your /etc/hosts file to see if you might be assigning the domain name to a local internal IP address or interface.
This caused the same error message for me and many 400 errors.
After changing /etc/hosts don't forget to restart the name service cache daemon ( service nscd restart ).
SNI isn't technically fully supported in that version of mod_nss but it has since been added: https://www.suse.com/support/update/announcement/2015/suse-ru-20150591-1.html
Saw the same error and saw it go away after applying the referenced patch.
I am trying to run to tomcat on linux where glassfish is already running on port 8080 ( you can check here - vhost2.cs.rit.edu:8080 . So i changed the tomcat port to 8181 by editing the server.xml file. NOw with the command startup.sh and i get the following output
Using CATALINA_BASE: /home/krs8785/apache-tomcat-7.0.54
Using CATALINA_HOME: /home/krs8785/apache-tomcat-7.0.54
Using CATALINA_TMPDIR: /home/krs8785/apache-tomcat-7.0.54/temp
Using JRE_HOME: /usr
Using CLASSPATH: /home/krs8785/apache-tomcat-7.0.54/bin/bootstrap.jar:/home/krs8785/apache-tomcat-7.0.54/bin/tomcat-juli.jar
Tomcat started.
I am assuming that tomcat is now working. Now when i test the server by - vhost3.cs.rit.edu:8181 I get
No data received on the browser.
What is the problem here and how do i solve it?
The problem may be unrelated to tomcat. I think your first step should be to exclude networking issues.
I have assumed you are accessing vhost3.cs.rit.edu:8181 from another machine. If that is the case, try to access localhost:8181 from vhost3.cs.rit.edu. If this is not possible in a conventional browser, perhaps because it is a headless server with X forwarding disabled then use a terminal based browser. Try typing the following in the terminal on vhost3.cs.rit.edu
lynx localhost:8181
If you are able to see a representation of a tomcat splash page then you can attribute it to networking issues. This could be firewall related (perhaps even an issue with iptables on linux).