I need help to run/debug my GWT application on an external server and not using the default jetty server.
I read several related topics to that question, e.g.
Where to write GWT -noserver option to avoid jetty?
How to set up eclipse with GWT and (regular servlet) Jetty backend
Is it possible to debug GWT client code on a REMOTE server using IntelliJ 9 Community Edition?
http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html
and the overall-conclusion is to
add parameter -noserver (either directly or using the google plugin for eclipse)
specify the URL of the desired server within the arguments-tab of the run/debug configuration
in run/debug configuration for a webApplication.
But after doing this, for me it seems that still the default jetty server is tried to be invoked by the provided launch URL:
http://127.0.0.1:8888/ApplicationName.html?gwt.codesvr=127.0.0.1:9997
Of course, the server can not be started due to the -noserver flag, but why is it tried to launch at all?
When following the GWT-guide:
Configure your server however you need to; note the URL which contains the host page for your GWT application.
.......
Add the -noserver command line argument. Change the URL at the end of the argument list to match the URL you recorded in step #1.
How do I change the URL at the end of the argument list? In my project, there is no URL at the end of the argument list which looks like:
-noserver -nosuperDevMode -remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -logLevel INFO -codeServerPort 9997 -war C:...\MyWebApp\war com.mycompany.mywebapp.MyWebApp
Which flag do I use to specify the URL of the desired server, -bindAddress, -server, -startupUrl?
Is my assumption correct, that after proper configuration the provided launch URL must not contain any 127.0.0.1, but (only) the URL of the dedicated server?
Any tipps are very welcome - I'm rather confused at the moment.
Best Regards!
First: The URL that is shown after starting the devmode is just for your convenience(the jetty code server was not started).
You can check that by starting the devmode and then opening the URL to your external server, for example http://localhost:8888/your_app_path/index.html, add just add ?gwt.codesvr=127.0.0.1:9997. Usually the devmode should start now anyway.
By setting up the startup url to http://localhost:8888/your_app_path/index.html the plugin will show you the correct URL: http://localhost:8888/your_app_path/index.html?gwt.codesvr=127.0.0.1:9997
I think one of the best options is to run the GWT Development Mode (CodeServer) instead of DevMode with -noServer to debug with an external web server.
Example of Using a WTP runtime configuration with a GWT Development Mode with Codeserver
https://www.youtube.com/watch?v=LtH4KzmguL0&index=7&list=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT&ab_channel=BrandonDonnelson
Example of using a Simple external web server with GWT Development Mode (CodeServer)
https://www.youtube.com/watch?v=pOwUpBuVtWE&index=5&list=PLBbgqtDgdc_TqzA-qXrjgTFMC_6DKAQyT&ab_channel=BrandonDonnelson
Related
I am using Apache Tomcat 9 server as a Maven dependency in my project. It is working fine and now I need to add a health endpoint so that it will return 200 OK if everything is running fine.
I came to know about HealthCheckValve (https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Health_Check_Valve) option in Tomcat 9 which is helpful. But I am not been able to figure out where to add this and the process of configuring this valve. As I know if server is standalone we can configure in Server.xml but as the Tomcat Server is a maven dependency I don't know how and where I should configure this.
Can somebody please help me in configuring health endpoint in Apache Tomcat 9 (as a maven dependency) ?
See the documentation, then add the HealthCheckerValve to server.xml. Valves go into either the Engine, Host or Context element. In the server.xml packaged with Tomcat you can find comments that should direct you to the right location.
When embedding a version of Tomcat, you won't have this file available, and so you need to assemble instances of these containers programmatically.
Check the launcher application in this example: https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/basic_app_embedded_tomcat/basic_app-tomcat-embedded.html
While I could not find methods like addValve() I found an init() method that you could use to provide a server.xml which will be read by Tomcat.
I saw the documentation of all valves available in Tomcat 9.0.x.
In order to find the solution of this specific task, I tried looking for configuration of other valves such as Remote Address Valve in embedded tomcat.
I found a solution by user967710 after searching a lot.
I did the following to add a Health Check Valve to my Tomcat 9.0.64 :
Tomcat tomcat = new Tomcat();
tomcat.getEngine().setName(UUID.randomUUID().toString());
tomcat.setPort(context.port);
tomcat.setHostname(context.hostname);
tomcat.getHost().setAppBase(".");
Valve valve = new HealthCheckValve();
tomcat.getHost().getPipeline().addValve(valve);
It doesn't matter how you configure the Tomcat for your project i.e from line 1 ~ 5 but actually last 2 lines i.e 6 and 7 are important where you are adding the valve.
The health endpoint can be accessible on host:port/health.
For e.g if it is hosted at http://localhost:4000 then the health endpoint would be http://localhost:4000/health
This endpoint will return 200 OK with a simple JSON response stating the Tomcat server status i.e "UP" if everything is up and running.
I'm using Cloud Endpoints Frameworks (2.0.1) for Java as part of my final year project and have been relatively successful with it so far.
I don't have any problems when deploying to my appspot.com domain, however, I am running into some problems when deploying locally.
(Any references to my-project-id in the following code blocks are aliases for my actual google cloud project id)
I have a valid openapi descriptor (openapi.json) of an annotated #API class which I am deploying to cloud endpoints using "gcloud service-management deploy openapi.json".
The command returns successfully:
Service Configuration [2017-02-23r0] uploaded for service [api.endpoints.<my-project-id>.cloud.goog]
I then map the returned config_id to the correct endpoints_api_service in my app.yaml
endpoints_api_service:
name: api.endpoints.<my-project-id>.cloud.goog
config_id: 2017-02-23r0
This service is listed by the gcloud cli tool using "gcloud service-management list"
NAME TITLE
storage-component.googleapis.com Google Cloud Storage
api.endpoints.<my-project-id>.cloud.goog api.endpoints.<my-project-id>.cloud.goog
etc...
and "gcloud service-management configs list --service api.endpoints.my-project-id.cloud.goog"
CONFIG_ID SERVICE_NAME
2017-02-23r0 api.endpoints.<my-project-id>.cloud.goog
... other version configs
and is accessible on my appspot.com domain (I can call the endpoint and receive the correct response)
I am trying to deploy my project on localhost using the maven appengine plugin for java (mvn appengine:devserver), but upon jetty startup I'm hit with the following Exception:
WARNING: Failed startup of context com.google.appengine.tools.development.DevAppEngineWebAppContext...
com.google.api.config.ServiceConfigException: Failed to fetch default config version for service 'api.endpoints.<my-project-id>.cloud.goog'. No versions exist!
at com.google.api.config.ServiceConfigSupplier.fetchLatestServiceVersion(ServiceConfigSupplier.java:155)
....
The deployment then gets stuck in an endless cycle of trying to start jetty, and being hit with that error message, and restarting etc. Any attempts to access localhost:8080 result in a "503: Service not found" error
I assumed that the local deployment of my app would be able to access the service config that was deployed using "gcloud service-management deploy", in the same way that the appspot.com deployment can, but is this not the case?
Looking at the source for ServiceConfigSupplier.getchLatestServiceVersion() I gather that serviceManagement.services().configs().list(my-service-name).execute().getServiceConfigs() is returning an empty list, but why is this only occurring locally?
Extra Information
my ENDPOINTS_SERVICE_NAME environment variable matches 'api.endpoints.my-project-id.cloud.goog'
I noticed that there was an update (1.0.2) to com.google.api.config a few days ago, and it has a dependency on an older version of com.google.api.services.servicemanagement (dependent on v1-rev14-1.22.0 with the newest version being v1-rev340-1.22.0)
I doubt this is the problem, but I thought I would mention it, as it contains classes relevant to the exception (ServiceManagement is used by ServiceConfigSupplier, which is throwing the exception). Perhaps there is an inconsistency in where they are looking for the service configs?
I'm quite stumped tbh, it's a bit over my head. I would dislike having to remove Endpoints, as I'm starting to like it, but we also can't really lose usage of our devserver either. I hope someone can shed a little bit of light on this issue.
It's not a fix but I was able to work around the problem by using the advice in https://stackoverflow.com/a/41493548/1410035.
Namely, commenting out the ServiceManagementConfigFilter:
b) Comment out the ServiceManagementConfigFilter from web.xml , ie,
<!--
<filter>
<filter-name>endpoints-api-configuration</filter-name>
<filter-class>com.google.api.control.ServiceManagementConfigFilter</filter-class>
</filter>
-->
<!--
<filter-mapping>
<filter-name>endpoints-api-configuration</filter-name>
<servlet-name>EndpointsServlet</servlet-name>
</filter-mapping>
-->
Note that you have to comment out the filter and the filter-mapping and they aren't right next to each other in the file.
I found that I didn't need to remove the scaling block as mentioned in point 'a' in the linked answer.
This may be related to a permission issue if you have pulled all recent updates. git pull Also, check that your Cloud SDK is up-to-date by using: gcloud components update.
Assuming you followed the instructions listed at https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java. To get around this issue you can create a service account with necessary permissions or use the command gcloud auth application-default login.
You can setup a service account using the Cloud SDK gcloud at https://cloud.google.com/sdk/docs/authorizing
Please let me know if you have anymore questions.
As for the command gcloud auth application-default login. According to the help description:
Obtains user access credentials via a web flow and puts them in the
well-known location for Application Default Credentials to use them as
a proxy for a service account.
When you used this command it obtains credentials for gcloud your Gmail Account. something#gmail.com and then stores the credentials in a location known to contain application credentials.
It worked with "gradle appengineRun" but on IntelliJ Idea project I had to replace all the ${endpoints.project.id} in web.xml and appengine-web.xml to run/debug localhost from IntelliJ (imported from gradle sources, installed Google Cloud Tools plugin and set up run/debug configuration from Tools/GoogleCloudTools/Run on a local App Engine Standard dev server).
My error was:
Failed to fetch default config version for service 'echo-api.endpoints.${endpoints.project.id}.cloud.goog'. No versions exist!
cloud.google.com docs only have Maven build example Gradle build is at github.com
Another thing to bare in mind is your service account has the right permission, your service account is something looks like the following
[project ID]#appspot.gserviceaccount.com.
By default, it is Project(Editor), at least you need to provide it as Service Controller role.
If it is gone, then you can follow these instructions to add back in.
This can happen if you've changed the Google Cloud project you're trying to authenticate to (if someone else has changed the project, this can happen when you pull changes from source control). In this case, the service account credentials that you were using for the old project will no longer be valid, and you can authenticate to the new project by running:
gcloud auth application-default login
I was having this fairly similar error,
endpoints.repackaged.com.google.api.config.ServiceConfigException:
Failed to fetch service config (status code 404): The service config
name and config id could not be found. Double check that filter
initialization parameters endpoints.projectId and
endpoints.serviceName are correctly set.
and the issue for me was having ENDPOINTS_SERVICE_VERSION environment variable specified in my appengine-web.xml. So basically, deleting those lines was enough in my case (Since endpoints uses the most recent ENDPOINTS_SERVICE_VERSION if not provided any.):
<env-var name="ENDPOINTS_SERVICE_VERSION" value="1" />
For me, the problem was that I hadn't deployed the open API.
So running the below fixed the issue:
gcloud endpoints services deploy openapi.json
My computer is running behind proxy. I want to access url from JavaFX WebView.
i used methods like System.setProperty() to set proxy for javafx.But it didnt work.Please help.
According to the JavaFX deployment documentation.
3.2.3 Built-In Proxy Support
Properly packaged JavaFX application have proxy settings initialized according to Java Runtime configuration settings. By default, this means proxy settings will be taken from the current browser if the application is embedded into a web page, or system proxy settings will be used. Proxy settings are initialized by default in all execution modes.
Information on how to "properly package JavaFX applications" is in the deployment documentation previously referenced.
You can use
System.setProperty("http.proxyHost","proxy.esrf.fr");
System.setProperty("http.proxyPort","3128");
As said in this answer.
The key idea is that:
"proxy settings will be taken from the current browser if the
application is embedded into a web page, or system proxy settings will
be used"
So, if you need to use custom proxy settings (strings) using:
System.setProperty(
"http.proxyHost",
MY_PROXY_HOST);
System.setProperty(
"http.proxyPort",
MY_PROXY_PORT);
in Netbeans you can disable setting proxy at application start to override it in code, by going to:
Project - Properties - Deployment - Disable proxy detection on
application startup
.
So, I've been developing my first actual site and so far I've been developing it on a local webserver, Apache Tomcat 7.0 along with a MySQL server, and I'm wondering what changes or problems I should be expecting when I go from that testing environment to a live VPN web server which I've been told I'll have to switch over to.
If it makes any difference I'm using struts2 for my action mapping which I've noticed append all my URL's with .action ex: localhost:8080/pm/random.action
However the expected url is, busniessname.com/pm/random
So the tl;dr, what should I be expecting when I switch from a local testing environment to the live website and what should I do to fix the URL's?
You should do nothing, the urls without .action extension should work by default. If you would like to use an empty extension only then you should set the property to the configuration.
<constant name="struts.action.extension" value=",,"/>
I have an application with name test.war.
Because of Apache installed on my server I have to use another port number for Tomcat applications so after deployment this application available at domain.com:8080/test/.
I decided to create a subdomain in order to remove that ugly 8080 from url, so I setted up the server like described here. So now test.domain.com reffers to domain.com:8080/test/.
Everything seems fine except of one problem - because my application is not ROOT.war and I am using spring:url function every url in the application is translated to /test/bla-bla. So I removed that function. But still have a problem with spring security because it still translates an urls relative to app name i.e. /test/bla-bla.
How can I solve that problem?
Thank you
UPD: I don't want to deploy it as a ROOT application because I have two or three such applications and I wanted to create a subdomain for each one of them
Spring Security doesn't "translate" URLs. In fact this isn't specific to Spring Security. You'll run into similar issues with any application which does redirects. If you want to hide the context paths of applications which are behind a proxy, then you need to rewrite the URLs at the proxy.
I'd recommend you read the Tomcat Generic Proxy Howto and the section on URL rewriting in particular, as it specifically addresses this issue.