Does anyone know why my "generate.py build" works just fine, but when I run "generate.py source" it cannot find:
"http://localhost/qooxdoo-1.6-sdk/framework/source/class/qx/Bootstrap.js?nocache=0.39702596611879537"
this is because it should be:
http://localhost/*username/*qooxdoo-1.6-sdk/framework/source/class/qx/Bootstrap.js?nocache=0.39702596611879537"
but I cannot find where this setting is.
I tried editing the variable "QOOXDOO_PATH" in config.json, but that didn't seem to work.
Please help, thanks!
You cannot just run a source version through a web server without taking some precautions. The generator generates relative URIs which work nicely on the file-system level (i.e. when you open your app with the file:// protocol in the browser). But relative paths are not stable under a web server.
As a simple example, if you have a file /foo/bar/baz/index.html which references ../../bong/other.png, other.png will be found on the file system in /foo/bong/. But if you have a web server on this machine with a DocumentRoot of /foo/bar/, the URL to load the index.html is http://localhost/baz/index.html and the above relative reference is overstepping the web server's root and will cause an error.
One way to make this work is to make sure that your web server's DocumentRoot is above the root directories of all involved libraries your app is using (i.e. your app itself, the qooxdoo SDK, other lib/contribs you are using, etc.). See here for a fuller explanation.
Don't fiddle with QOOXDOO_PATH, as this is necessary to find the framework classes and build your app in the first place.
make sure you use a relative path when setting the source location:
../../../../../../../../home/*user*/qooxdoo-1.6-sdk
if you are working with perl, I would recommend using the the mojo bindings http://qooxdoo.org/contrib/project/rpcperl-mojo they allow you to run both the build and the source version through the built in web server, taking care of all the path magic.
Related
Tesseract initializes fine until it needs to load the language files, and it just stops working. See the attached picture for reference on the error..
The npm package(?) installs fine, I also downloaded offline files (worker and wasm files) and made it work as I have seen that it loads them correctly.. Well, at least until it starts loading the language files and breaks my app..
Worker and wasm files are put in the
/public
folder so it can be read by the jsx. I tried not using the offline files, by removing these lines
workerPath: '/External/tesseractjs_data/js/worker.min.js',
corePath: '/External/tesseractjs_data/js/tesseract-core.wasm.js',
but I am still having the same error. All of the solutions I have seen online that is connected to this problem are almost all in java, and one of the solution needs to install some kind of tesseract software, but what I would want to avoid this as I wanted no installations, why I have picked web programming so the installation would be minimal..
I don't think anyone will need this but here is how I fixed my issue:
Seems like my downloader (IDM) was capturing the language files (traineddata.gz) and then sets a key with 0 value in indexed db on the domain / browser.
Clear browser cache, or just delete the key/value pair thingy in the Indexed DB, which can be found on the developer tools / console thingy, at the "Storage" of the browser
Disable downloader or just remove ".gz" on the file types capturing section of the downloader
It should now work
I'm trying to start my first web project. My experience is with .NET desktop development and I'm very new to the Java/Kotlin world. Client side I want to use React and write the code in Kotlin, then transpile to JavaScript. Server side I would like to use Ktor both to serve the static content (React app + various assets) and REST endpoints for the SPA. I would like to use the Multiplatform feature to be able to share as much code as possible. My IDE is IntelliJ IDEA.
I would like to have auto-reload and be able to debug both React and server code for development and I would like to be able to create a single fat jar with the complete application (frontend+backend).
I started with the template that IntelliJ provides for multiplatform JS+JVM. I have been working on it for more than one day with little success and also haven't been able to find any sample online with all the features, and also haven't been able to combine various samples due to insufficient knowledge. Only thing I got is either running the application without autoreload or creating the jar file by adding "manifest" to the build.gradle file which breaks my run configuration.
I would very much appreciate if someone could provide or point me to an example with these features which I can use as an starting point for my application.
Here is a link to an example to get you started.
https://play.kotlinlang.org/hands-on/Full%20Stack%20Web%20App%20with%20Kotlin%20Multiplatform/01_Introduction
I'm new to qooxdoo. I'd like to use it for an embedded web interface for an application I'm developing right now.
To keep building my application as easy as possible I'd like to stay away from using the python build scripts after every change if possible. Because the website will only be used once in a while by a single user load times etc. are also not a big concern for me.
I've read about the "build-all" target but could not find a detailed description on how to activate it with the current release. Can someone explain how I can get a complete desktop build of qooxdoo?
You don't have to run generate.py every time you change the code, only every time you reference a new class. During development it's usually relatively infrequent that you have to re-run the generator, compared to how often you will do the edit/save/alt-tab/refresh/test cycle.
But you can do what you're asking during development by using the "source-all" target, eg:
./generate.py source-all
When loading an app from a file:// url this is fine because file:// URLs are very fast, but you can optimise this manually by modifying your config.json to incorporate specific sets of classes.
To do this, in your application's config.json, add (or edit) a job called "source" and add:
"jobs": {
"source": {
"include": [ "qx.ui.*" ]
}
This will cause all of the qx.ui.* classes to be included into the ./generate.py source build of your application; obviously you can fine tune this further.
When it comes to deploying your application, use ./generate.py build because this will produce a minimised, optimised version (with debug code removed etc) which uses only those classes that are required.
If you are still looking for a build version of Qooxdoo, here is my qxSimple project. It includes some examples.
http://adeliz.github.io/qxsimple/
You can also generate your own build version following these steps :
Dowload the latest qooxdoo release
Go in the framework folder
Edit the config.json file
uncomment the //build-all line
run generate.py build-all
I have created a GWT project which is successfully using an external jar file (see GWT - Using external jars / Java Projects by Lars Vogel‎ and Adding external jar in GWT).
When I use a library file like this, what happens when I compile the project and upload it to AppEngine? Does the jar file get uploaded as it is, or does it get compiled into something else first? And if the former, is it at any security risk of being downloaded without my control?
Let's drop the "google-app-engine" part, it doesn't matter here. You use the library in GWT, on client side. App Engine is server side, with no direct connection to GWT (but due to the volume restrictions it is quite useful to utilize some client side execution like GWT).
Everything you use in GWT will be compiled to JavaScript, transferred to the client and executed there. Obviously you have no control over the result and what the client does with it.
But it will be next to unreadable. Plus the client does not get the JAR per se and he does not get everything that is inside the JAR.
So what really matters is if the library's license allows this and if there are secrets in the library code that are only intended to be used on server side.
Actually, his's answer is not quite correct. The "google-app-engine"-part matters a lot here. Technically, GWT compiles and obfuscates all of the Java code it needs. And it strips out everything that it doesn't need. So, from the JavaScript generated by GWT, it should indeed be quite impossible to reconstruct or maybe even recognize the library. But it turns out that if you use the Eclipse plugin to deploy your app, appcfg uploads all sorts of random stuff to the AppEngine servers, sometimes including the entire Java source of the project (client side code included).
To see what exactly it uploads when you do a deploy, check in your system's temp-directory while the upload is running. You will find an AppEngine staging directory there that contains everything to be sent.
For suggestions for ways around this, you can refer to the answers to a question that I asked earlier: Removing unwanted uploads from AppEngine deployment
What I haven't checked is whether all the unwanted uploaded files end up in directories that are actually directly accessible from the internet.
Is it okay to place an oracle driver jar within the web application's /lib directory, or is it better practice to place it in tomcat's lib directory?
I'm wondering about this because on my local host, my web app runs fine with the jar in the web app's /lib directory, but when I move the web app to a real development server, I continue to receive null pointer exceptions when trying to close a connection pool object. I thought this issue may be why I'm unable to free the connection.
Thanks.
To answer the initial question, about placement of the .jar file, there are some things to consider:
Are there other apps on the same server that use this? If yes, and you want to ensure all of them use the same version, the placing on the server/lib folder would be better
If you want some flexibility in terms of what version of the .jar each app uses, then webapp/lib is better
If you are packaging your app as an ear or war, and there are size considerations, then the server/lib option has some advantages, given it makes sense considering the two points above.
If you run into classloader issues from dependencies, you may have to consider other jars when deciding on placement.
Whatever you decide, its best to make sure each jar exists only once in each apps classpath.