drop wizard - web app directory & edit static files - jetty

I started app development with drop-wizard recently and a bit confusing how the whole thing works.
Where is the web app directory?
Is it possible to edit static files (JS, CSS) without needing to have a redeployment?
Thanks.

I have looked into this a bit more and will attempt to answer your questions:
Where is the web app directory
DW applications are not (meant as) web applications. They are deployed as an embedded system running a jetty embedded server and listening on some port(s). Having said that, there are certainly ways of packaging the application as a web application. (see link in comment)
Is it possible to edit static files (JS, CSS) without needing to have a redeployment? - Yes(ish)
This depends on you, really. There is a thing called an AssetBundle. These can be used to server static resources (from the classpath usually). This however is a mechanism you could use to implement your own AssetBundle that instead of serving files off the classpath, will serve files off the regular path.
Or, you could add your regular path to the classpath on startup so that the AssetBundle works.
Or, you could implement a ServletFilter for the AssetBundle (assets are not part of the jersey ecosystem) and implement your dynamic changes in the Filter.
Most of these will require restart for a reason or another. E.g.a custom implementation of a Filter obviously requires a redeploy. The Servlet returning assets also (I believe) employs a caching strategy that might require a restart (subject to your implementation).
For your UI: There is also a DW-views project that adds the ability to create views (with by default mustache templates) that can be powered from your application and served by the same REST endpoints.
Hope that helps,
After some more checking:
You can serve static resources from the file system and modify them as you go. They will be served correctly. How to do this:
Add an asset bundle with the resource path:
bootstrap.addBundle(new AssetsBundle("/assets2/", "/assets"));
This adds the root classpath resource assets2 and has it served statically from the endpoint assets.
The trick is that you have to add your file system location as a classpath resource. This can be done via arguments (or the classpath tab in the eclipse run configuration). You can google that relatively easy. However, you will have to remember that classpath resources behave differently from file system resources:
In my case I added to the classpath:
/home/artur/tmp/assets/
However, my Asset bundle serves from "assets2". Let's have a look at the file system:
artur#pandaadb:~/tmp/assets$ pwd
/home/artur/tmp/assets
artur#pandaadb:~/tmp/assets$ find .
.
./assets2
./assets2/test.txt
artur#pandaadb:~/tmp/assets$
So, in my file system location has been added as root, but assets are only served from the subfolder assets2
Now, all the resources that are located in assets2 can be modified at runtime and will be served by DW as a static resource.
Have fun playing around,
Artur

Related

Whats a good pattern for a web-application for serving files?

I am working on an angular Web-Application where it's possible to view pdf-files in a pdf-viewer in the browser.
The Web-Application is also consuming a REST-Service in Django.
In the Database the information of the pdf-files is stored. The Web-App is calling the REST-API to check where the files are stored.
As I am still in the Proof-Of-Concept Phase of the project, the PDF-Files are currently stored in the assets folder of the angular web, which of course is not what I want in the end.
When the Files or the Directories change, the Database should be updated automatically (or via a trigger in the app).
I have two questions:
Is there an obvious way to serve the files in this combination? i.e. an apache server? I imagine there are built in solutions in dedicated file servers to detect changes of the watched directory.
For a partly solution would it be reasonable to write a script on the django site, which does the file-serving, the updating and also providing the REST-API?

import projects in build path for web service: server or client?

I have created a little example app to test out the CN1 web service functionalities. Following the web service tutorial from CN1 (https://www.codenameone.com/how-do-i---access-remote-webservices-perform-operations-on-the-server.html), I have my Codename one project as client and a dynamic web project running on my Eclipse tomcat server hosting the servlet.
As I have objects that I pass back and forth between client and server, I want both projects to know about these java files. The way to do that is to put the file in one project, and modify the build path of the other to include the first project. This way, the import can resolve the file name just fine.
Question now is: is it better to put the files in one project or the other? Does either way affect the size of the resulting app file that I want to publish in a store? I want to keep the size as small as possible.
Thanks for any tips.
UPDATE: on the preliminary information provided by Shai, files that are to be shared among different projects (either client or server side), do not put your code in either but INSTEAD create a CN1 library for that. This library can then be added to the CN1 buildpath configuration (not the Java build path!) to all required projects.
Here are the details on how and why: https://www.codenameone.com/blog/new-preliminary-library-support.html
Just need to figure out how to do this on Eclipse, as it does not seem to be supported now.
You can use shared code with a cn1lib whose source you can include into the server project manually. In some cases we just copy the shared source files in the build script from one project to the other as it makes the process simpler.

Serving an Angular2 App on aws s3

I have created a Angular 2 form which posts the form data to a postgres DB using a Rest API. Now, I want to serve my Angular 2 app on AWS S3. I googled on this and I found that creating a webpack is a solution but not able to create one. I want to know where to start with, to bundle my code and serve it on s3.
GitHub link for Form: https://github.com/aanirudhraj/Angular2form_signaturepad_API
Thanks for the Help!!
The quickest way is to build the app using angular-cli and then deploy the content of the 'dist' directory as a static site in S3 (an S3 bucket can be configured to host a static site; make sure you assing read permission to 'anybody' to avoid http 4xx return codes).
You just need to host it as a static site on S3.
Check this: http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
I infer from your code that you are using angular-cli.
Create a dev/production build
ng build --dev / ng build --prod
Content of your dist folder will contain bundled files for deployment. Your primary file for refrence will be 'index.html' as this will load you angular app.
You need to decide what kind of server you'll be using to serve you webapp.
For development purpose when we do ng serve , webpack-dev-server is used as a static file server (local development). I'll recommend should go with the most comfortable/cost effective solution you can have when deploying to actual server.
Static file Server
Directly hosting website is aws space as a static website.
Aspnet Core with static file server middleware. (*)
Nodejs Express with static file server middleware.(*)
Java serverlet for serving static files. (*)
(*)Following aproach will also allow you to have some server-side code if you require in future.
When you deploy your ng2-app, you should use AOT(ahead of time) compile.
I guess you are using JIT(just in time) compile.
In angular2 guide page,
With AOT, the browser downloads a pre-compiled version of the application. The browser loads executable code so it can render the application immediately, without waiting to compile the app first.
When you use JIT compile, your browser will download vendor.js which is defined by angular2 compiler and it will compile your app just in time. It will be too slow and your client have to download vendor file. When you use AOT, you dont have to use vendor file, so resources are being smaller.
I recommend to use AOT compile when you deploy your app, and use lazy loading for resource size.
If you are curious about ng2 AOT compile, read this guide.
angualar2-cookbook-AOT
And here is example angular2 app with webpack2 and lazy load.
use file structure and config files in here.
When I tested with example app, files bundled with aot was smaller than 500KB.
angular2-webpack2-aot
When you use aot compile with #ngtools/webpack or whatever,
just put all files in dist directory which have files compiled with aot in your S3 bucket, and I recommend to use aws cloudfront cache for your s3 bucket resources.

django serving media files in production (comparing to PHP frameworks)

I'm a django newbie. I've read that all django projects, deployed in production environment, should serve media files (uploads) through web server such as apache. My question is - why is that?
There are lots of PHP frameworks - eg. symfony 1 and 2 - which don't follow the rule. Once you've made your app accessible through a web server, you don't have to change anything depending on the env you deploy. There is just the DOCUMENT_ROOT configured on the web server and somewhere inside this directory lies the upload directory - that's all. You can be sure that no one will access PHP, sql files and so on - thanks to the proper framework architecture and the document root. Why is it different in django?
edit: besides, preparing different code for different environments (e.g. this) is quite a bad approach, since you can't use exactly the same code to deploy a project in different envs (and the code from the link makes sense only for debug env.
Because with PHP your code is served from web server's public directories together with static and media files. So when you request any of these static files web server serves them directly without executing any PHP code along the way.
In Django your code is running separately and all requests are processed by python code in Django. This is inefficient to serve static files, it's more efficient to serve allow a web server like Apache or Nginx to serve them directly without going through any python code.

Does it matter where the Django project exists on the system?

Aside from not deploying a Django project to the web site root directory, is there any specific benefit to running Django projects from one location, e.g. /var/django-projects/**xxxxx-project/ vs. (in a shared hosting environment) running each Django project in a domain folder, e.g. **/vhost/mydomain.com/xxxxx-project?
Doesn't matter -- choose an organization that fits your needs.
I roughly followed this guide when creating a server to handle several Django sites, and I like the folder organization it uses. A couple of benefits:
All Django sites are in a special django user's home directory
There is a domains folder, then a folder for every site that contains the django projects, logs, wsgi files, and other files
VirtualHost containers are each in the own file, keeing httpd.conf manageable.
Realistically it shouldn't matter where you put them so long as you're consistent.
I think the biggest argument one way or another would boil down to file system permissions and where related files will be. If you are allowing development from different users on the projects but want to limit their scope, this is where the split will make more sense.
No except to extent that you mention, ie., that it shouldn't be under DocumentRoot for any site.
You should also ensure that the WSGI script file is not in the same directory as the Django settings file as doing so would generally see you saying to Apache that that directory can be served up by Apache. This may not happen as there will be no Alias directive mapping a URL to that directory, but you have still removed one layer of protection from Apache security.
So, follow the guidelines in:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
and have the WSGI script file in a directory of its own which has no source code at all under it, or have the WSGI script file in a completely different directory outside of Django project, which again contains only script files of other files that Apache would technically be allowed to serve up.
Basic rule is don't stick source code (except for WSGI script file) in any directory for which:
Allow from all
has been defined by way of Apache configuration.
Of course, above partly assumes you are using mod_wsgi. :-)