PlayFramework 2.X routing to generated content - java

I have a process within my play app that generates a text file. I would like to copy this text file to a directory where i can then view it from a static route.
In production mode, the public assets folder is jar'd up, Is there a directory I can place my files into where I can route to them in prod mode.

Thanks for confirming m-z, I ended up rolling my own solution which is hopefully secure....
In my Global application class , I store a file location, which is then accessible by my controllers. The controllers simply read the
file(s) into a Buffered REader, then spit them back out.
using OK.sendFile(string).
thanks ,

Related

Generate txt file under /resources and immediatelly read it without rebuilding the app

I have a rather simple question. I have a controller with two endpoints
/newFile
/downloadFile/{fileName}
/newFile endpoint creates a simple .txt file under resources
and my expectation would be to hit /downloadFile/{fileName} and download the newly created resource.
Resource res = new ClassPathResource(fileName);
so as it turned out classpath resource looks under build/resources and the file is not yet there (because I haven't restarted/rebuild the app, once I do it - I can download the file) but the whole idea is to dynamically generate files and access them immediately - is there a quick way to bypass this without having to rebuild?
I too had the same problem when I was working on FACE Recognition API which has the same process of creating a file and and uploading it to analysis.
What java does is It abstracts project to JVM and runs on it, So your newly created file won't be in the JVM, What you need to do is to use a Database or any cloud storage or NFS.
According to my perspective Using Database is the best option. Code Java How to upload files to database with Servlet, JSP and MySQL and Javatpoint store file in Oracle database are some documents you can refer for using a database.
you can refer to this document for implementing your project.

Deploy Flowable workflow programmtically

I am trying to dynamically generate the workflow file for Flowable and deploy it on the go.
There are two challenges:
1. Create BAR file to package the XML that is generated
2. Deploying it dynamically.
Has anyone ever tried this? If yes, could you please help or suggest an alternative
Accomplished this finally. The only thing I needed to understand was that BAR file is nothing by a normal ZIP file. It simply needs to be named with a .bar extension.
To deploy it dynamically, we need to utilise the Repository service in the Flowable engine library. Below code snippet allows you to dynamically deploy the workflow. Once deployed, you can freely delete the workflow file as the workflow is recorded in the database.
String barFileName = "path/to/process-one.bar";
ZipInputStream inputStream = new ZipInputStream(new FileInputStream(barFileName));
repositoryService.createDeployment()
.name("process-one.bar")
.addZipInputStream(inputStream)
.deploy();

Server log rotation

I have an application running in Wildfly 8.2.1. In addition to the server.log file in the log directory, my application creates and uses other log files too (also in the log directory). They all end in .log. This is dynamic and programmatic using org.apache.log4j.FileAppender, since the names, contents, and number of files differs from one client to the next.
What I'd like is for Wildfly to automatically rotate these log files too in addition to its own (i.e. server.log). I see in standalone.xml there is a periodic-rotating-file-handler tag with a file subtag that has a path attribute. From reading the Wildfly logging documentation, it seems like I can't use wild cards here? So, path="*.log"? Is this true? If so, how can I achieve the end goal of Wildfly automatically rotating my log files instead of doing it myself?
If you'd like to rotate log files you'd need to use a rotating file handler. The periodic-rotating-file-handler will only rotate it's own file not other files associated with other file handlers.
Since you seem to be creating a log4j file appender have a look at the org.apache.log4j.RollingFileAppender.

How to recreate nginx's try_files in Play Framework for hosting React site

I am trying to host a React site from a Play Framework server. The React front-end is developed in a separate project and its build artifacts (static html/js/css/etc. files) are copied into my Play project's public folder.
Now I tried navigating to e.g. /page1 (where that's a React route), but I get a 404 because of course the server does not have such a route.
What I want is to replicate nginx's try_files $uri /index.html kind of functionality - if the path that's being asked for can be served (i.e. it corresponds to an asset the server knows about), it is served. Else, serve the contents of index.html without rewriting the url, so that React's routing can work.
I've tried getting this to work with just the routes file and also as a controller (with an if/else). I haven't been able to exactly replicate what in nginx is a one-liner. How could I do this?
As #vdebergue says, you can get a simplified version of what you want by adding a catch-all at the bottom of your conf/routes file.
However if you have other files in public that you'd like to still be served up correctly (for example, image files), you need to use something a little more powerful.
I wrote about this in my blog in July, but as per Stack Overflow convention, I'll expand upon it here as well. Basically, you can copy this Gist, which declares a FrontEndServingController.
The key functionality that this controller gives above the built-in Assets controller is that on first use, it recursively scans your public directory to find real files, so it knows when to serve them up, and when to serve up index.html (your React app).
Then you use it in your routes file like this:
GET / controllers.FrontEndServingController.index
GET /*file controllers.FrontEndServingController.frontEndPath(file)
You can do it simply in the route file. At the bottom of the file, add this catch all rule:
# your other routes above
# ...
GET /$any<.*> controllers.Assets.at(path="/public", file="index.html")

What's the appropriate directory structure for a spring boot web app so that the home page automatically opens when the program is run?

I've created this project through Spring Boot. It's a full stack web app that takes information from a user, validates it, sanitizes it, authorizes it, and then sends it to a database. It also can retrieve data from a database.
The problem is that, when the project runs, it should open the home page automatically. Instead, I have to navigate to it manually through a browser, resulting in Access Control Allow Origin issues (as it appears that AJAX is being sent cross origin).
My current directory structure is like this:
C:\Users\workspace\Repository\Project\src\main\resources\templates
Within this templates folder, I have my webpages and config folders. These config folders contain the Javascript files.
I've looked at other projects I've created, and directory structure is very different, but they all use jsps. They look like this:
C:\Users\workspace\CapstoneProject\src\main\webapp\jsp
This directory has all the jsps in it, and they start with the project.
What is the appropriate directory structure so that they start with the project? I've googled this and looked on Spring's website but have found nothing.
The location is less important and it depends on your ant/maven/gradle/script of building your artifact for example War file which it should be copied to webapps folder and then folder for resource type as jsp/css/js/html
Static resources as html can be outside your war in a separate resource folder.
According to tomcat it depends on your size of the application:
*.html, *.jsp, etc. - The HTML and JSP pages, along with other files that must be visible to the client browser (such as JavaScript,
stylesheet files, and images) for your application. In larger
applications you may choose to divide these files into a subdirectory
hierarchy, but for smaller apps, it is generally much simpler to
maintain only a single directory for these files.

Categories