Deploying a WebJob with a static Content file - azure-webjobs

A WebJob running on Azure does not seem to drop the <Content> files (Copy if Newer) into the correct directory.
I get the following error:
System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\local\Temp\jobs\continuous\LongTasks\lprysn1r.tsv\Content\File.cshtml
And I try to access that file as such:
File.ReadAllText("Content/File.cshtml");
When running locally, it works just fine.
Is there a way to get this static file dropped appropriately?

After doing some tests, the convention is they do a shallow copy of the /bin/Release folder to App_Data/jobs/continuous/LongTasks/
Which means, if there are any folders, they are not being copied.
Moving the "File.cshtml" to the root directory fixes this problem.
I know this is not fully related to the Azure WebJobs SDK, but this is happening on 6/22/2015 with version 1.0.0.

You should use WEBJOBS_PATH environment variable for currently running webjob.
var webjobPath = Environment.GetEnvironmentVariable("WEBJOBS_PATH");
if (string.IsNullOrWhiteSpace(webjobPath))
{
// Handle dev environment
webjobPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
}
This will return some path like D:\local\Temp\jobs\triggered\\xxeeeexxx.qzx\, which contains your content files and folders.

Related

Error while building WSO2 Microgateway project on Windows 10

I’ve been trying to explore WSO2 Microgateway and set up a Microgateway project. Building the project in Windows 10 with the command “micro-gw build project-name” is giving this error: “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”.
I’ve downloaded the Toolkit and Runtime from https://wso2.com/api-management/api-microgateway/. I've set the Path environment variable to the /bin directory of the Toolkit and Runtime extracted folders, but still the “micro-gw build project-name” command is giving error “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”. I’ve also cloned the source code from Github (https://github.com/wso2/product-microgateway/) which has the Main.java class and tried setting environment variables to its path.
I also tried setting the environment variables to the path where Toolkit batch file is present. I also followed the steps mentioned here, https://github.com/wso2/product-microgateway/#running-the-microgateway.
I'm assuming the Toolkit batch file (micro-gw) would execute the Main.java class coming up in the error.
These steps did not resolve the error. I'm new to Java based product, and I'm sure I'm missing something here.
Problem is with the init command not the build command. Init command is suppose to setup the TOOLKIT after the first use. It should extract the platform.zip file and copy all of the required resources to relevant places for you.
I hope you get the Project ___ successfully initialized message after running the init command. Just check $TOOLKIT_HOME/logs/ directory to see if there are any information on the log file.
If the log file also doesn't help, as a workaround, copy all the .jar files inside $TOOLKIT_HOME/lib/gateway/platform and $TOOLKIT_HOME/lib/gateway/cli to $TOOLKIT_HOME/lib/platform/bre/lib and try again, that should work.
Also please report this issue at https://github.com/wso2/product-microgateway/issues

External jars with Dropwizard

I am trying to write a Dropwizard application and its doc tells me that I need to ship everything as an uber jar.
However, in my application I need to support multiple databases and this requires multiple database JDBC driver jars in my classpath, all of which are not expected to be shipped together with my application. Users are expected to place the corresponding JDBC jar like mysql-connector-java-5.1.39.jar in a particular folder by their own.
After reading Dropwizard's documentation I am not sure if this kind of usage is supported. Does anyone have experience making it to work this way?
Since java 6, you can wildcard classpaths.
Using the application plugin, the generated bin folder will have a start script that contains the classpath. What we want to do, is to instead of listing every possible jar in the bin folder, we simply include all of them.
Note: You can also do the same thing with different folders if you want the classpath in a different location.
This can be achieved (in a workaround manner since there are problems with this plugin in my version) in the easiest way as follows. In build.gradle you do:
startScripts {
doLast {
def windowsScriptFile = file getWindowsScript()
def unixScriptFile = file getUnixScript()
windowsScriptFile.text = windowsScriptFile.text.replaceAll('CLASSPATH=.*', 'CLASSPATH=\\$APP_HOME/lib/*')
unixScriptFile.text = unixScriptFile.text.replaceAll('CLASSPATH=.*', 'CLASSPATH=\\$APP_HOME/lib/*')
}
}
This will wildcard your lib folder in the start scripts. When starting up, your classpath will simply be
lib/*
When you drop jars into that folder, they will automatically be picked up (on startup, not on runtime).
I hope this helps,
Artur

Creating a file via python on OpenShift application

with io.open("filepath/filename",mode="w",encoding="utf8") as file:
file.write(jsondata)
But it seems something wrong.
my flaskapp return 500 and no error logs
But when i remove it everything can run as normal.
what should i do?
If you are using OpenShift 2, it is likely your web application is running under Apache/mod_wsgi. You shouldn't in that case be using relative path names as the current working directory of the application is effectively undefined and likely not writable. Instead construct an absolute path name. Depending on what file is for, you may be best to write files into the data directory provided to you and specified by the OPENSHIFT_DATA_DIR environment variable, if it potentially needs to persist. Or OPENSHIFT_TMP_DIR if a temporary file. Details of important variables for directories can be found in:
https://developers.openshift.com/managing-your-applications/environment-variables.html#directory-variables
As to why you aren't seeing any error, this is likely because Flask is swallowing the error up when generating the 500 response. You would need to configure Flask to log details of the error.

How to write a file in to an OS X app Resources folder?

I have an xcode project, the used language is C++. while my program is running writes a txt file in to
My App.app/Contents/Resources/
folder using fstream. After a month pause don't work anymore. Nothing is modified on the project but the OS X is updated. The file path is ok, i can read the file. What is wrong?
You should not write into your app bundle, and instead use one of the following folders to store files, which can be obtained using NSSearchPathForDirectoriesInDomains:
Document folder (NSDocumentDirectory).
Application Support folder (NSApplicationSupportDirectory).
Caches folder (NSCachesDirectory).
If you write to your app bundle you will cause issues with the code signing of the app and might not even have write access, if it's installed in the default location (/Applications).

How to NOT delete a war directory on Jetty server stop()

I am trying to create a "warless" (exploded war, war directory only) deployment of embedded Jetty. I have been able to make it run by passing the path to the war folder to the WebAppContext(...) constructor and making sure that extractWAR, copyWebDir and CopyWebInf are set to false. I do not set a temp directory.
This runs fine. However, after stopping this, the content of the war folder is deleted and replaced with just one empty subfolder - jsp. So, next time this runs there is nothing there to run... and that is the problem.
I would ideally also like to keep any JSP compilation artifacts in place (for various reasons I am not doing build-time precompiled JSPs .... yet).
Does anyone know what causes this? I am assuming Jetty believes that this is a temp folder and that it should be removed... but it isn't.
Found the cause. Something else was setting the temp folder to the same path as the exploded war. Once I changed that to a different folder the deletion no longer happened.
That still leaves my other question though... but I'll live with it.