I want to wrap an executable (Fortran application) as a web service. In order to execute my application I have to generate a bunch of files from the user's input including paths to specific resources (The user may upload resources to be used before starting the service). When done I generate a result file which should be downloadable so I want to return a URL. The paths to the resources should not be accessible but the URL (of course) should enable downloading.
How do I get these paths? Is servlet context the correct approach? My service isn't a servlet and therefore has no context, has it?
Thanks in advance!
I was able to solve this problem with the help of WSContext and the ServletContext which gives me the path to Context root. Everything that is not supposed to be accessed from outside will be placed under WEB-INF, all accessible sources will be placed under COntext root and subfolders. (I am working on the last bit)
Very important: I injected WSContext via #Resource and you have to access the WSContext AFTER the constructor is done. I tried to use the context within the constructor and that gave me a hard time because it was always null then.
Related
I just wrote the description file for my UI5 application.
Now I have these questions:
Where and how can I embed the manifest.json in my project correctly?
How can I test if it's working fine? (correctly embedded)
Is the "start_url": "" similar to initialPage of the index.html?
Many thanks for your guidance,
Chris
Usually, the manifest.json file (aka. "Application Descriptor") is put into the same folder as where the Component.js file is located. The component will look for the file name "manifest.json" in the same folder. If the descriptor is located somewhere else or has a different file name, assign the relative URL of the file to the manifestUrl in the component factory function like this, which is recommended to do so anyway because it ...
loads the descriptor file before creating the component (same as manifestFirst) allowing us to preload dependencies and model data to improve the initial loading time.
makes specifying the name of the component redundant.
You can either pass the name of the component or the URL of the descriptor file to load [the component] via the descriptor.
To see if the file is correctly embedded, run the app and see if e.g.
the rootView is loaded,
models (for example ResourceModel for i18n) are set to the component instance,
custom resources assigned to sap.ui5/resources are loaded, etc. etc..
→ Make sure to include (or in case of manifestFirst/ manifestUrl, don't be tempted to remove) manifest declaration in the component metadata.
The "start_url" is purely advisory and meant for the web standard rather than for UI5. It's telling the browser where to look for the initial page when the user starts the web app.
To learn more about the descriptor file, take a look at the developer guide such as "Descriptor for Applications" or as a summary, here.
I need to upload files in the Workspace:
I dont know which URL i should give as parameter to my file Uploader. Considering that i working with the SAP WebIDE personal Edition and my file are located in the following path:
file:///C:/SAPWebIDE/eclipse/serverworkspace/Al/ALine/OrionContent/testApp/webapp/model/
What should i please set as Url here?
var oFileUploader2 = new sap.ui.commons.FileUploader({
name: "upload2",
uploadOnChange: false,
uploadUrl: "???"
});
I think you have misunderstood how the FileUploader works.
The "uploadUrl" parameter should be used to specify a path on the "web server" (e.g. application server, web container) on which your application is hosted. UI5 is a web user interface framework, it does not know how to handle (server-side) upload requests. This means that the server (backend) itself should have some implementation for handing the file upload.
After you select the file and trigger the upload, a POST HTTP request is made to the path specified in this "uploadUrl" parameter. If you have no web server to know to handle it, then it will invariably give back an error HTTP response.
Based on the title of your question, I understand that you would want to upload the file inside your workspace. IMO, this does not really make sense (as you are mixing in the design time environment with your run-time environment (i.e. your application should never depend on the IDE).
Nevertheless, you can try and import a file via the import menu (right click on package, import, from file system) and see what URL is the request triggered against (using the dev console). I looked around a little and roughly this is the request URL: http://localhost:[Web IDE Port]/xfer/import/[User Name]-OrionContent/[Project Name]. In the Slug header you would have the file name. You might not be able to make a POST request towards this URL directly (because of XSS / CSS limitations), so you might need to create a route mapping for it.
I have a page that contains dynamic content:
/content/foo/bar/baz.jsp
But I want it to be accessible with the .html extension.
What's proper way to do this?
You are confusing some concepts in Apache Sling.
On Sling you have two important directories /apps and /content. In /apps you should put all your JSPs, in /content, as the name suggest, you only put content. Content being resources and their properties.
Nodes in /content have a property sling:resourceType. When a node from /content is requested, Sling looks for the resourceType of that node and invokes a JSP in the matching directory under /apps (and /libs if not found).
So, you must put your JSP under /apps/yourapp/foo/bar/bar.jsp (or with the file named 'bar.html.jsp', if you want to be explicit).
Then create a node /content/page with a prop sling:resourceType="yourapp/foo/bar". When requesting /content/page.html, bar.jsp will be invoked.
The process that Sling chooses to select which JSP invoke at each request is a bit complicated at first, but it follows simple conventions regarding the name of the JSP. Check their documentation regarding URL to script resolution.
Check the Discover Sling in 15 minutes tutorial and the rest of their docs. They are pretty simple.
How do you distribute other files needed by your application that aren't in a jar file? For example, the application at http://www.javabeginner.com/java-swing/java-swing-shuffle-game . The download contains Shuffle.jar, Shuffle.bat, Score.dat, and an images folder with 3 images in it. I can see possibly putting the images directly in Shuffle.jar, but you wouldn't want to put Score.dat in the jar file because it changes. Is there somewhere you could identify this type of file in the jnlp?
The non-java files should be stored as resources. For files that change, you store the original or template file also as a resource in your jar. When the program starts, you have it check the local system to see if that file exists. If not, it creates the local file by copying the template file from the JAR resource. If the file already exists, then it is used as is.
To save files to the local system, even when running in the sandbox (unsigned), you can use the PersistenceService (javadoc / example). If your java application is signed, then you can use the regular File apis to write the file to the local machine, such as in a ".yourgame" subfolder under the user's home folder.
You can put all those files (except the scores file) in your jar file and load the contents using resource loading.
I've just deleted and restarted my reply twice now, changing my answer each time; this is confusing and needs a bit more clarification.
Are you SURE that application is supposed to be a Web Start app? On the site you linked to, it doesn't appear to be. Are you trying to take an application that was not designed as a Web Start application and change it into one that can be Web Start?
If it's not a Web Start app as your tag implies, then this question is open ended. You can distribute it 100 different ways.
If you are indeed trying to convert it into a Web Start app, you can start by packaging the images into the jar and that will alleviate your first headache if you just read them from there instead of from a File(). If it's going to be Web Start, then you need to decide how you want to keep scores. You have to decide what the scoring system is like before you can decide on how to go about it; will all the scores be kept on the web site hosting the Web Start app? Will that part still be local? If you want to get access to the local file system, you need to sign the jar, then you can extract the score.dat to the file system and do whatever you want with it if the end user accepts.
You need to figure out what you want to do before you can do it, or at least clear it up for us if you already know more than we know you know.
I have some JavaScript files, a main HTML file, a main CSS file, and some CSS files that get imported into the main one.
I understand that I can put static files in two places: a) the 'war' folder; or b) the 'public' folder.
Where is the best place to put my static files? Are the two locations treated differently? Is there a 'best practice' on this issue?
The difference between the 2 locations is that files in the public folders are copied by the gwt compiler to the 'your module' folder in the 'war' folder. This is means if you deploy the 'war' (for example via the google plugin to the google appengine) the files from the 'public' folder are not at the toplevel.
For example, if you have an index.html in the 'public' folder with gwt module named 'mymodule' and you deploy it to www.example.com it looks as follows, you need to access it via:
www.example.com/mymodule/index.html
If you have the index.html in the 'war' folder, you get:
www.example.com/index.html
Summarizing. Your landing page should be in the 'war' folder. Resource files used by the landing page can also be stored here (css, images). Any other resource file that is referred to in any gwt module file (or code, like images) should be stored in the 'public' folder related to the gwt module.
The new way of working in GWT is to use the war folder.
But, if you project is a reusable widget library which is used in a GWT application then you should put the resources in the public folder. The compiler will make sure that the files are automatically included in the generated package.
As I see it, it depends on your requirements, but let's start at a speaking example first ...
I find the documentation (should be GWT 2.6.0) about this to be incorrect or at least incomplete/confusing. As I see it (I am not a guru so please correct me if my investigations are wrong!) I am looking at the following example proj structure
myproj/
src/my/gwtproj/
client/
img/
foo1.png
AppClientBundle.java
foo2.png
public/
img/
foo3.png
foo4.png
war/
img/foo5.png
foo6.png
.classpath
.project
Imagine we may (or may not) need to reference such resources in some AppClientBundle interface (or other application reference context):
interfaces AppClientBundle extends ClientBundle {
#Source("img/foo1.png")
ImageResource fooImg();
}
Then it seems to depend on your Requirements, e.g.:
R.a) these resources (like images) are refered to in the application code, e.g. in our AppClientBundle interface via #Source annotations
R.b) these resources are to be grouped by folders, e.g. foo2.png vs. img/foo1.png
R.c) these resources should be available outside some specific application URL context path, e.g. if used as widget library, e.g. http://host1/gwtapp1/foo4.png vs. http://host1/gwtapp2/foo4.png
R.d) these resources need to be application-independently (e.g. externally) URL-referenced, e.g. http://host1/gwtapp1/foo4.png vs. http://host1/foo6.png
Here's what one can do (Possibilities) and it's implications regarding R.* above:
P.1) (generally recommended as I see it) put nicely folder-structured resources under my.gwtproj.client (here e.g. foo1.png)
this way #Source("img/foo1.png")... works fine
in the docs above they speek about some public folder (in my case my.gwtproj.public), but creating it as a package in Eclipse does not me allow this (since public is a reserved Java key word, but creating it via the Navigator view works)
however, this way the #Source above does not work (likely because it's an issue with the relative AppClientBundle file system location)
nevertheless if the resource should be publicly available under the application context one may have to do it via this public folder
P.2) put "ungrouped" resources directly under myproj/war, e.g. projdir/war/foo6.png
this way it can be used/found within annotations, e.g. #Source
and it can be referenced outside the application itself via e.g. http://host1/foo6.png
P.3) put folder-structured resources under myproj/war, e.g. projdir/war/img/foo5.png
in contrast to P.2) #Source("img/foo5.png") would not work anymore