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
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.
Our appengine application consists of several microservices deployed in a mix of standard and flex environments. Since we are using both flex and standard we chose jerse to implement our backend services as endpoint framework does not work with flex. We are not able to make this combination of Jersey + Appengine Standard + Endpoint work. When we deploy the swagger using gcloud cloud manager, it does not link with the backend services.
I could not find any documentation regarding how to integrate App engine standard and endpoint without using endpoint framework annotations.
Has anybody implemented the rest service backends using the combination
Jersey + App engine Standard + Cloud Endpoints. Is it possible to integrate Cloud endpoints and appengine standard without using endpoint framework annotations.
Pls note : We have tested Jersey + Flex + Endpoints and it works.
This is not tested or documented, so you are playing in a new area. It should work, and I'm happy to try and help you debug it. To use Endpoints on Standard with Flex, you have to do this:
Including this dependency:
<dependency>
<groupId>com.google.endpoints</groupId>
<artifactId>endpoints-management-control-appengine-all</artifactId>
<version>${endpoints.management.version}</version>
</dependency>
Add this configuration to your web.xml, then add a filter-mapping to go in front of jersey:
<filter>
<filter-name>endpoints-api-controller</filter-name>
<filter-class>com.google.api.control.extensions.appengine.GoogleAppEngineControlFilter</filter-class>
<init-param>
<param-name>endpoints.projectId</param-name>
<param-value>${endpoints.project.id}</param-value>
</init-param>
<init-param>
<param-name>endpoints.serviceName</param-name>
<param-value>echo-api.endpoints.${endpoints.project.id}.cloud.goog</param-value>
</init-param>
</filter>
Upload your OpenAPI specification using gcloud service-management deploy.
In appengine-web.xml, add an environment variable definition:
<env-variables>
<env-var name="ENDPOINTS_SERVICE_NAME" value="echo-api.endpoints.${endpoints.project.id}.cloud.goog" />
</env-variables>
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
I've created a solution that contains a Web API 2 project as well as a separate HTML project to house my AngularJS SPA. The latter project contains index.html with app and Scripts folders. When I debug locally, I receive HTTP 403.14 Forbidden. Are there additional configuration steps needed to ensure the app will run locally as well as when deployed to Azure?
Try browsing directly to the index.html and not only to document root.
If that works, add those line to your web.config to set default document.
<system.webServer>
<defaultDocument enabled="true">
<files>
<clear/>
<add value="index.html"/>
</files>
</defaultDocument>
</system.webServer>
I am looking at Hosting angular JS / HTML 5 web app on google app engine as a single page app. All my services are also on google app engine within the same project.
I have generated the basic directory structure for angularJS using yeoman generator.
Just created a directory under the /war/ folder of app engine project and placed the angular code in that.
EVERYTHING IS WORKING FINE !!!
Then Question ?
Is this the right way to place a HTML page directly in the WAR folder of an App engine ? Or should I be placing HTML files under the SRC folder of an app engine project and pull them into war during deploy time ?
Lets say million users try to access this single page web app, will such a hosting model help in scaling up ? Will app engine create more instances to serve this page.html ?
Note: I am 'NOT' using anything GWT for UI. Its just a single page app under a war folder !
Appreciate your inputs.
Srik
I believe this is entirely up to your preferences. I put my angular apps in /src/main/node and copy the output of grunt during maven package phase like so:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<archiveClasses>true</archiveClasses>
<webResources>
<!-- in order to interpolate version from pom into appengine-web.xml -->
<resource>
<directory>${basedir}/src/main/webapp/WEB-INF</directory>
<filtering>true</filtering>
<targetPath>WEB-INF</targetPath>
</resource>
<resource>
<directory>${basedir}/src/main/node/dist</directory>
<filtering>false</filtering>
<targetPath>/</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
While this seems the cleanest solution for me, you may not feel the same way. It really doesn't matter how your static content gets into your war as long as it does.
There will be no instances for this. Static content (like html, js, css files) are served through Google's static content proxy, which is a content delivery network. So yes it will scale but you don't need instances for static content.