I have the live version of my app deployed with its endpoints (no problem with that).
I also want to easily be able to test other versions (e.g. staging).
With endpointV1: no problem.
With endpointV2:
Everything works fine if I deploy to the live version (at https://[PROJECT-ID].appspot.com but does not work for other versions.
After deploying to staging at https://staging-dot-[PROJECT-ID].appspot.com the deployment is successful, but when the frontend calls the backend, the request is received by the backend (I can see it in the GAE logs and trace list), but it does not make it to or though endpointV2 and responds 404 NOT FOUND:
"errors": [
{
"domain": "global",
"reason": "notFound",
"message": "\u003chtml\u003e\u003chead\u003e\n\u003cmeta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\"\u003e\n\u003ctitle\u003e404 NOT_FOUND\u003c/title\u003e\n\u003c/head\u003e\n\u003cbody text=#000000 bgcolor=#ffffff\u003e\n\u003ch1\u003eError: NOT_FOUND\u003c/h1\u003e\n\u003c/body\u003e\u003c/html\u003e\n"
}
I now use the following maven plugins:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.3.1</version>
<configuration>
<!-- deploy configuration -->
</configuration>
</plugin>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>endpoints-framework-maven-plugin</artifactId>
<version>1.0.0</version>
</plugin>
I have adjusted the versions in appengine.xml and in the Google Cloud plugin. How can I configure endpoint to work with a specific module version instead of only the main version?
While not really an answer, I saw this:
When deploying a legacy type endpoint (V1), everything works fine, https://3-dot-xx.appspot.com/_ah/api/discovery/v1/apis will show the APIs deployed to version 3
When deploying a new type endpoint (v2), eg 2-dot-, it depends on the last V1 endpoint deployed on the version.
if it is a new version with no V1 endpoint deployed before, it works and the new endpoint is shown on 2-dot-
if there was a V1 endpoint deployed here before, it will show the old V1 apis and naturally generate a 404 when accessing, as the actually running GAE version is different
if the version was never deployed at all (eg asdf-dot-), or using the default (without the -dot- etc), it will show the default version and access it correctly.
if there never was a V1 service deployed, but a V2 service, it works fine when deploying a new V2 service
So, it seems like there is a bug that will prevent you from using stable names for testing / staging environments if you already had a V1 service running on them. It would be very helpful if someone from Google could confirm this bug and suggest an appropriate workaround before I have to do a lot of costly changes to change URLs.
The short answer for me was: do not reuse version names that were previously used with endpointV1.
E.g. I had a testing-dot-MYPROJECT.appspot.com.
I now use a different version: test-dot-MYPROJECT.appspot.com.
For the long answer, have a look at cputoaster's answer.
Related
I have an existing ASP.NET Core application (that uses razor pages) and I am trying to convert it, one component at a time, to React until I can completely make it a SPA. The idea is to create an entry point for each of my razor pages until I can combine them all into one SPA. I have most of this working except for the use of webpack-dev-server to serve my bundles. The problem I am having is the ASP.NET app runs on port 44321 and the dev server runs on port 8080 so the script tags in my .cshtml files cannot see the bundles that are being hosted from webpack.
I can temporarily change them from:
<script src="./dist/[name].bundle.js"></script>
To something like:
<script src="http://localhost:8080/[name].bundle.js"></script>
To get around this, but this is not long term solution.
I have created a sample application to showcase what I am trying to accomplish here: https://github.com/jkruse24/AspNetReact.
Is there any way to either get my ASP.Net application to listen on the port that webpack-dev-server is serving to (without changing my script tags) or to have my webpack-dev-server serve to the port that my ASP.Net app is running on?
I have tried to use the .NET CORE SPA middleware (Microsoft.AspNetCore.SpaProxy) but either I have not configured it correctly or I am misunderstanding what it is used for. Upon adding in the below code (which is commented out in my github sample) my application still looks at the .\dist directory for my bundles (which are still there from running actual builds).
if (env.IsDevelopment())
{
app.UseSpa(spa =>
{
spa.Options.SourcePath = "./ClientApp";
spa.UseReactDevelopmentServer(npmScript: "start");
spa.UseProxyToSpaDevelopmentServer("http://localhost:8080");
});
}
I ended up getting this working using the .NET Core SPA Middleware. When I originally tried to used the middleware, it was working fine, but I didn't have my webpack dev server configured to serve my bundles to the correct location.
As you can see above, I was serving them to
http://localhost:8080/[name].bundle.js
when they needed to be served to
http://localhost:8080/dist/[name].bundle.js
My problem was that my webpack publicPath was not set correctly. I made an update commit on my repository here. More specifically, this was the file diff that solved my problem.
I just published an Angular app to Azure Web Apps, after confirming general operation locally. However, I now get the following error (HTTP Error 404.0 - Not Found), specifically the D:\home\site\wwwroot\bin\www file:
However, using the Kudu tools, I can see that the file is indeed there:
What could cause this error?
By default, IIS blocks serving content from certain folders, including bin. You can either a) move the www folder out of the bin directory, or b) you could add the following configuration to the web.config:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
The 404.0 Error on bin\www was a bit of a misdirection. After putting a console.log in the www file and watching output, I found out that indeed bin\www was being called properly. The problem was further in and related to the serving of static content, initially the index.html file.
I was previously using the following to serve up index.html:
var serveStatic = require('serve-static');
...
app.use(serveStatic('.', { 'index': ['index.html'] }));
For some reason, while this worked locally, this didn't work once published to Azure Web App. So I decided to use a method that had worked for others. First I moved index.html to /public, and then used express.static:
app.use(express.static(__dirname + '/public'));
It should also be noted, that the associated web.config file must also have information related to the static content, for example: How to enable static files (and less support) when hosting a nodejs app within IIS using IISNode
With a newly scaffolded app generated from "yo jhipster" and started with "mvn spring-boot:run" and "grunt server" I am able to load the app and do operations like login, view metrics, see sessions, settings, logs, and audits. However, whenever I view the "User Tracker" page I don't see anything?
I believe this section is supposed to demonstrate Atmosphere websocket / AngularJS integration? Looking at the browser console logs, I see the following:
Websocket failed. Downgrading to Comet and resending atmosphere.js:2866
GET http://0.0.0.0:9000/websocket/activity?X-Atmosphere-tracking-id=0&X-Atmosph…true&X-Cache-Date=0application%2Fjson&X-atmo-protocol=true&_=1393276976964 404 (Not Found)
It appears that a websocket connection is attempted but eventually times out and the fallback long polling doesn't work? I'm using the latest Chrome (also tried on latest versions of Firefox and Safari as well).
Am I missing something simple?
-- Update 1 --
Deploying it as a WAR to Tomcat 7.0.50 shows data back from Atmosphere in the User Tracker page but it continuously loops trying to get a WebSocket connection (HTTP status code 101: switching protocols) so the user data appears and disappears periodically. I saw an error in Chrome like this:
No suspended connection available. Make sure atmosphere.subscribe has been called and request.onOpen invoked before invoking this method
The Tomcat logs show the following:
[WARN] org.atmosphere.cpr.DefaultAnnotationProcessor - Unable to detect annotations. Application may fail to deploy.
-- Update 2 --
Deploying it as a WAR to Jetty 8.1.14.v20131031 (Jetty 9.1.1.v20140108 throws errors) and testing it with Chrome 32.0.1700.107 appears to work for the fallback transport of long-polling. The initial connection to WebSockets, however, fails because Atmosphere for some reason thinks the servlet container is Tomcat? In the server logs, it throws the following issue:
java.lang.ClassCastException: org.eclipse.jetty.server.Request cannot be cast to org.apache.catalina.connector.RequestFacade
at org.atmosphere.container.TomcatWebSocketUtil.doService(TomcatWebSocketUtil.java:141)
at org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket.service(Tomcat7Servlet30SupportWithWebSocket.java:62)
Thanks again for all your help -- definitely making progress :)
-- Update 3 --
To summarize everything:
Currently "mvn spring-boot:run" and "grunt server" don't work together for Websockets or long-polling
If you deploy the JHipster WAR (mvn package) to Jetty 8.1.14.v20131031 then it works but you need to remove the following dependency from your JHipster pom.xml or else Atmosphere will not provide WebSocket support:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</dependency>
Argh. False alarm -- I had it running using streaming, not websockets, so WebSockets still has the error from update2
No you're not missing anything :-)
If you use the Java server directly it should work: you need to connect to the application with another browser (or another tab) and you will see working.
However, with "grunt server", there is a bug: the Grunt proxy just does not support Websocket, so it doesn't work... There is one strange thing, thus, it's that the fallback transport does not work.
I'm filling this as a bug.
-- update 1 --
Concerning your update, it looks there's another Atmosphere bug:
http://atmosphere-framework.2306103.n4.nabble.com/Log-warning-that-Atmosphere-is-unable-to-detect-annotations-td4658159.html
It seems that Atmopshere can't find its annotation inside a WAR, can you try the same thing in development mode ("mvn spring-boot:run")? That would means it's an issue with WARs in Tomcat
this is a regression. Earlier (than Jan 2014) versions of Android Studio would successfully generate the Endpoint code from a model.
steps: New Project, Tools > Generate App Engine, select any of the endpoint models (DeviceInfo or Message) or add a class file (with #Entity etc). Tools> Generate Endpoint
gets: No JPA #Entity Class found in MessageData2.java in dialog box Failed to Generate Endpoint Class
expected: code generation as in the past
update: rolled back to 0.4.2 (it used to work) and yikes! still getting Dialog Box (really stuck now).
update [not stuck anymore]: rolled back MAVEN to 3.0.5, built new clean project, app{appname}-endpoints succesfully built, then Generate Endpoint worked (still has the bug where client code is not copied to endpoint directory, look for it in {appname}-AppEngine/target and copy by hand to {appname}-endpoint tree
i logged a bug through App Studio to https://code.google.com/p/android/issues/detail?id=65270 if you want to track
(answer from comment on https://code.google.com/p/android/issues/detail?id=65270 )
Tools>Generate Endpoints will work in 0.4.3 by adding this code to pom.xml
trevorjohns#google.com :"
I ran into this problem recently. Adding:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0</version>
</dependency>
to my backend pom.xml seemed to fix it."
yes, fixed!
we would like to improve build configuration/integration of Java + JavaScript projects.
back-end : Java app, Spring framework, REST API + maven as build tool
front-end : HTML + CSS + JavaScript, (based on ng-boilerplate project template - it separates nicely all modules,services,directives,shared assets) and it's using few JavaScript tools like npm, Bower, Karma + Grunt
Workspace configuration is pretty simple - each project in separate directory :
/workspace
/JavaBackend
/JsFrontend
Problem is that developers are dealing with “Origin null is not allowed by Access-Control-Allow-Origin" messages in browsers as they run AJAX queries from front-end (from file://..../JSApp/build/index.hml) and Java App server is on localhost:8080. We could switch browser security off or modify headers to allow cross origin requests but we think it's not good way how to achieve that.
We don't want to have JS resources inside of Java project in /src/main/webapps/ as in production environment apps will be deployed on different machines and each app has it's own build server.
Do you have experience with similar project configuration ? What would you recommend to us ?
Meanwhile we will experiment with Tomcat 7 to check if it can e.g. serve external static resources (js stuff) out of context of java app
For development purposes, I would let Tomcat include the front-end folder in the server.xml by means of a <Context> tag. The folder can be arbitrary and even in another repository (e.g. /GitRepos/ApplicationGui/app).
...
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%h %l %u %t "%r" %s %b" prefix="localhost_access_log." suffix=".txt"/>
<Context docBase="/workspace/JsFrontend" path="/"/>
<Context docBase="FlexibleOrders" path="/FlexibleOrders" reloadable="true" source="org.eclipse.jst.j2ee.server:FlexibleOrders"/>
</Host>
</Engine>
</Service>
</Server>
In production, I would recommend to make a Maven artefact out of the front-end. It can be then included via dependency in the backend like this:
<dependency>
<groupId>org.enterprise</groupId>
<artifactId>application-gui</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
See this blog for a complete configuration for production:
http://wiki.switajski.de/2016/01/24/how-to-create-maven-artifact-with-static-web-resources.html