I'm having a very painful time with WildFly.
I successfully deployed my war and the log said
WFLYUT0021: Registered web context: /myapp
And I can't access the app with 404.
http://192.168.56.101:8080/myapp/index.html
What did I do wrong?
Are you sure, you have an index.html at the right place in your war-file? You must probably post more information on your file structure, web.xml, etc.
Another stumbling block could be in standalone.xml (config file of wildfly): To which IP is the application server bound? 127.0.0.1? Or 0.0.0.0?
Try accessing the app with http://localhost:8080/... (on the machine you deployed it). If this works, you need to change your standalone.xml file (replace all '127.0.0.1' occurrences with '0.0.0.0' is the easiest way)
Hope this helps. Otherwise, try to be more specific.
Related
We let the golem package automatically create a Dockerfile for us and can run the docker image and see the app at the root directory: http://localhost:3838/?...
But we would like the app to appear in a subdirectory like http://localhost:3838/myApp/v1/?... so that we can set up the necessary proxying for Apache and have this and other apps all available from a single server.
We can manually edit the Dockerfile to copy a shiny-server.conf file with the following information:
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location /myApp/v1/ {
# Host the directory of Shiny Apps stored in this directory
site_dir /srv/shiny-server;
# Log all Shiny output to files in this directory
log_dir /var/log/shiny-server;
}
}
The above solution feels like a hack and we are hoping there is functionality inside of golem that will allow us to set the subdirectory at which the app will appear.
Unfortunately there is no way to include an nginx configuration inside the Dockerfile programmatically: {golem} tries to help with the creation of the file, but some things still need to be done manually.
Also, note that {golem} doesn't create a Dockerfile with a shiny server in it, it creates a standalone docker image that launches the app, so there is no shiny server running, just an R process. {shiny} being what it is, there is no way to natively run it on a given path, it's always at the root, on a port.
That being said, what you can do is either edit the dockerfile so that it also bundle nginx (or any other load balancer), so that you can serve the app on a path, or serve your application on another port, using the port argument of add_dockerfile(): that might be easier to configure it with you Apache proxy.
Colin
I get the following error message when I try to open up my application from the web (using 'appname' as my application name, the root name of my application - the error displays my app's actual name):
com.ibm.ws.webcontainer.internal.WebContainer handleRequest SRVE0255E: A WebGroup/Virtual Host to handle /appname has not been defined.
As far as I can tell, my application was installed correctly and is running on our Websphere server (WAS 8.5).
I'm at a loss for what to pursue in order to resolve this issue - what possible issue could my application be having?
Map your web module to /appname in the administration console, or use whatever context-root is specified for the web module.
when I am starting WebLogic admin server with local host:port no/console I am getting the following error:
Console/Management requests or requests with <require-admin-traffic> specified to 'true' can only be made through an administration channel.
How to overcome this error?
You can manualy change your config.xml, find the <require-admin-traffic> element and change it's value to false.
This is because the option administration-port-enabled is set to true in config.xml
(available under ../MW_HOME/user_projects/domains/config)
<administration-port-enabled>false</administration-port-enabled>
Perfect. Or you can use the administration port you entered when configuring the server to use the admin server, which will be different from the default one. The default one 7001, the default for the admin server is 9002 and you can only access it via https.
Not downvoting the answer as it is accepted and maybe useful for users which can't recover their admin port, but this is obviously not best practise.
Once you open config.xml under the folder ../config,
change this row from 'true' to 'false':
true
It should then be ok.
Skender Kollcaku
You are most probably trying to use the administration console on the application port. You need the administration port.
Go to your domain directories (ex. /opt/weblogic/domains/mydomain)
Go into sub-directory config
Run grep "administration-port" config.xml
This will give you a port number, like: <administration-port>12345</administration-port>
Use that port to connect to /console/.
ex: https://YOUR-SERVER:12345/console/
This is much preferable to using the application port for the console, like #Peter pointed out.
I'm dealing with an annoying problem. I have to make some changes to a large website, which source code is not under my control (sub-contracting). As usually I try to rebuild a local copy of the site to test my changes. The problem is now that almost all paths used in URLs for images, css, links etc. are relative paths pointing to the root directory, like
href="/style/main.css"
This is a problem because I develop on an intranet server and I put this project into a nested directory, so the URL to the project files is sth. like
http://myIntranet.com/checkout/project
What happens is that the paths from the first example don't resolve correctly. So I tried using the base tag to set the directory from which links should be resolved as
That works fine when the path is
href="style/main.css"
without the slash at the start, but fails when the slash exists, because (I think) the link is resolved from the server host, not from the URI in the tag.
So... is there any possibility to make the "/dir/file.html" links resolve from a root othe than the server root? Or do I have to manually remove all prepending slashes from the paths (urgh)?
Thanks in advance. :)
If you're doing local development on a web site you can do either of the below. Both involve moving your project in a base folder instead of working with sub folders inside your document root.
Virtual host on different port
In your web server, create another listening port and virtual host.
After restart, you can access your web server as http://localhost:81 or whatever port number you choose.
Virtual host on same port
Only create another virtual host (like above), but make sure to use named virtual hosting.
After restart, you have to add another entry in your hosts file (c:\windows\system32\drivers\etc\hosts or /etc/hosts) using a simple text editor:
127.0.0.1 localhost myproject1.self.com
The above line should already exist, so you can keep adding more names to it:
127.0.0.1 localhost myproject1.self.com myproject2.self.com
Personal preference
I like the second option, because I don't have to mess with ports and stuff like Facebook API keeps working as you expect.
I hope this all makes sense, let me know otherwise.
I am using Glassfish V3 which comes with netbeans only , as there are few servers running on my pc , i have changed the port from 8080 to 8787 of glassfish v3 by altering domain.xml
<http-listener id="http-listener-1" port="8787" address="0.0.0.0" default-virtual-server="server" server-name="" />
<http-listener id="http-listener-2" port="8181" enabled="false" address="0.0.0.0" security-enabled="true" default-virtual-server="server" server-name="">
Now when i deploy the restful webservies over server or click on Test Restful Webservice in netbeans
i am getting a page in a browser which still uses the old port and even there is not webservice option get displayed on it the page is blank. here is the screen shot
note: i tried restarting it may times but still using the old port
In your Netbeans project node there must be a sub node like "Generated sources (rest-test)" or similar (I don't have Netbeans in english).
If you expand this node, there must be a file named test-resbeans.html. Open this file and check the following entry:
var baseURL = "http://localhost:8080/MyFirstWebService/||/resources";
The term MyFirstWebservice needs to be replaced by your services's name.
Change the port there if necessary.
There was an open issue for something similar. I fixed it a while back, but the change will be in NB 7.0. I do not think anybody will backport the change into 6.7... but you never know.