How to make boxfuse create an image containing executable jar and configuration file to be specified in main arg? - cloudcaptain

I'm playing around with boxfuse attempting to "fuse" an image which contains an executable JAR. My executable JAR is given the path to a config file as an argument to it's main method, like so:
java -jar my-executable.jar -conf /some/path/to/my/conf.json
Where the file conf.json is read in by the JAR's process to be configured with e.g. port, database connection properties, etc.
I understand how to pass custom arguments using -jvm.main.args="-conf /some/path/to/my/conf.json", however, I don't know how to get the config file into the image itself. Obviously the path has to point to a valid file that exists within the image.
In dev, test and production, I would want to use the same executable JAR, but a different config file for each environment. I don't currently see a way around having different images for each environment. I see there is some support for packaging specific config with Dropwizard payloads, but no mention of something similar for executable JARs.
Is there a more general way I can package arbitrary files into the image, with predictable paths I can refer to in the jvm.main.args?
P.S. in my case the executable JAR happens to be a Vert.x application, but I think the general case applies.

What you can do is package the configuration for all environments (dev, test & production) within the executable JAR file. So you would have dev.json, test.json and production.json
You can then use a technique like environment detection with for example an environment variable to detect the correct environment at runtime and pick the correct configuration, which can then be loaded from the classpath instead of the file system.
This allows you to build both the jar file and the Boxfuse image only once and run it unchanged on all environments.
P.S.: I've just raised an issue for you to add first class Vert.x support in the near future to make things even easier: https://github.com/cloudcaptainsh/cloudcaptain/issues/28

Related

Where are appsettings after compiled in a dotnet core 2.1

I am trying to understand how the appsettings.json and appsettings.{Environment}.json and the environment variables play along in a dotnet core 2.1 application but I don't know how at runtime the appsettings (whatever the final transformation is) are accessed by the application.
I would expect to have the appsettings among the compiled dll (e.g: MyWebApiApp\bin\Debug\netcoreapp2.1), but I don't see it there.
Understanding this would help me find out the best approach for OpenShift configmaps vs appsettings, because I need to know whether I should rely on appsettings at runtime or whether appsettings is something useful for development but on production I should rely on environment variables rather.
Thanks!
Are you running the code from within Visual Studio? The default CreateDefaultBuilder uses the Directory.GetCurrentDirectory() to determine which folder to load the settings files from. When you are running from within Visual Studio the current directory is your project directory - so when you run/debug the program it finds the correct settings file.
One way to test this is to change to a command line and run your applications using dotnet myapp.dll. If you are loading settings from an appsettings file it will not find the file and the settings will be null.
If you change the properties on your appsettings file to copy if newer and rebuild your app, when you run it from the command line it will correctly find the settings file.
You can take a look at the how the webhost determines which settings to use by looking at the implementation file. But, in short, dotnetcore will use settings in the following order:
appsettings.json
environment variables
command line
The documentation for this is here
So, if there are settings that could change once the app is deployed then you can overwrite them via environment variables. You could redeploy the appsettings files if you want to configure that way but, from my experience, it is much easier to handle production settings via environment variables, possibly using a third party tool e.g. puppet.
Hope that helps.

java.lang.ClassNotFoundException: Could not load requested class : oracle.jdbc.driver.OracleDriver [duplicate]

How should I add JAR libraries to a WAR project in Eclipse without facing java.lang.ClassNotFoundException or java.lang.NoClassDefFoundError?
The CLASSPATH environment variable does not seem to work. In some cases we add JAR files to the Build Path property of Eclipse project to make the code compile. We sometimes need to put JAR files inside /WEB-INF/lib folder of the Java EE web application to make the code to run on classes inside that JAR.
I do not exactly understand why CLASSPATH does not work and in which cases we should add JARs to Build Path and when exactly those JARs should be placed in /WEB-INF/lib.
The CLASSPATH environment variable is only used by the java.exe command and even then only when the command is invoked without any of the -cp, -classpath, -jar arguments. The CLASSPATH environment variable is ignored by IDEs like Eclipse, Netbeans and IDEA. See also java.lang.ClassNotFoundException in spite of using CLASSPATH environment variable.
The Build Path is only for libraries which are required to get the project's code to compile. Manually placing JAR in /WEB-INF/lib, or setting the Deployment Assembly, or letting an external build system like Maven place the <dependency> as JAR in /WEB-INF/lib of produced WAR during the build, is only for libraries which are required to get the code to deploy and run on the target environment too. Do note that you're not supposed to create subfolders in /WEB-INF/lib. The JARs have to be placed in the root.
Some libraries are already provided by the target JEE server or servletcontainer, such as JSP, Servlet, EL, etc. So you do not need put JARs of those libraries in /WEB-INF/lib. Moreover, it would only cause classloading trouble. It's sufficient to (indirectly) specify them in Build Path only. In Eclipse, you normally do that by setting the Targeted Runtime accordingly. It will automatically end up in Build Path. You do not need to manually add them to Build Path. See also How do I import the javax.servlet / jakarta.servlet API in my Eclipse project?
Other libraries, usually 3rd party ones like Apache Commons, JDBC drivers and JEE libraries which are not provided by the target servletcontainer (e.g. Tomcat doesn't support many JEE libraries out the box such as JSF, JSTL, CDI, JPA, EJB, etc), need to end up in /WEB-INF/lib. You can just copy and paste the physical JAR files in there. You do not necessarily need to specify it in Build Path. Only perhaps when you already have it as User Library, but you should then use Deployment assembly setting for this instead. See also ClassNotFoundException when using User Libraries in Eclipse build path.
In case you're using Maven, then you need to make absolutely sure that you mark libraries as <scope>provided</scope> if those are already provided by the target runtime, such as JEE, Servlet, EL, etc in case you deploy to WildFly, TomEE, etc. This way they won't end up in /WEB-INF/lib of produced WAR (and potentially cause conflicts with server-bundled libraries), but they will end up in Eclipse's Build Path (and get the project's code to compile). See also How to properly install and configure JSF libraries via Maven?
Those JARs in the build path are referenced for the build (compile) process only. If you export your Web Application they are not included in the final WAR (give it a try).
If you need the JARs at runtime you must place them in WEB-INF/lib or the server classpath. Placing your JARs in the server classpath does only make sense if several WARs share a common code base and have the need to access shared objects (e.g. a Singleton).
If you are using Maven:
Open the project properties, and under Deployment Assembly click Add...
Then select Java Build Path Entries and select Maven Dependencies
Resolved by setting permissions.
Had related issue using PySpark and Oracle jdbc. The error does not state that the file cannot be accessed, just that the class cannot be loaded.
So if anyone still struggles, check the permissions. Some might find it obvious tho'.
I want to give the answer for the folowing link question ClassNotFoundException oracle.jdbc.driver.OracleDriver only in servlet, using Eclipse
Ans: In Myeclipse go to Server-->left click on Myeclipse Tomcat7-->Configure Server Connector-->(Expand)Myeclipse Tomcat7--> Paths-->Prepend to classpath-->Add jar (add oracle14 jar)-->ok

SOA MDS Target folder

I would like to understand what role the target folder plays in a SOA MDS project.
I am using JDeveloper and the target folder keeps getting populated with 2 .jar files. I am not sure where these jar files are coming from, but they contain old data which should be changed.
Can somebody please help me understand what is behind the making of these files?
The target folder is the default build output directory used by maven.
If working correctly, the builds should be generated there by maven using the configuration specified in the pom.xml file. In your case, the maven build might not have been run recently, which is why you see old content in the jars.
Have a look inside the pom.xml and see what build configuration has been specified there (it is likely to be no different from a SOA composite maven build file/pom file). If it's all built correctly, you should be able to deploy that jar directly to the MDS runtime (either manually or via maven).
In the pom file, you should be able to override most things there including the name, version, bundle type, target directory etc.
You can also use maven to keep track of your MDS changes - i.e. version it like any other build artifact/SOA composite. The versioned jars can also be uploaded to an artifact repository (such as nexus), in addition to being deployed to MDS runtime, so you have good level of traceability of MDS changes
PS -
This might help explain more: http://weblog.singhpora.com/2016/10/managing-shared-metadata-mds-in-ci.html

Want to Make a Jar file

I've made a java application(it extends JPanel) and want to make it into a jar file.I have BlueJ and I used it to do so but after I make the jar file it doesn't open. Can anyone help?
Jar files are PKZIP packaged files which have specific folder structure and convention in it. It contains the compiled version of your java sources (*.java -> *.class) plus meta data. You can "open" it with any archive which can handle zip files especially if you append the ".zip" extension to the file name.
If you mean executing your jar by "opening" it, that's a different thing. You have to have a standard static main method in one of your classes so the JVM can find the execution entrance point. If you have that you can say "java -jar yourjarfile.jar", which will execute your class starting from your main. Note, that I assume that you have JVM setup well (I guess you have) and your environment variables should be configured too. In most cases, your jar refers to other jar files. You can provide access for those for the JVM through classpath.
Do you use Eclipse to write code? If you do, then it is easy to use Eclipse to create an executable jarfile.
Do you use a JFrame to present your JPanel? If you do not, you may have a JFrame, it is the "application window" where the JPanel will be presented.
JFrame tutorial:
http://docs.oracle.com/javase/tutorial/uiswing/components/frame.html
/Johan

How Can I Stop the Enterprise Library Configuration Tool from Inserting an Absolute Path in the Environment Configuration File field?

I'm trying to learn/use the Enterprise Library 5.0 Configuration tool and it seems like it would work perfectly with a few minor exceptions. The problem I am currently having is when it comes to working with different environments. We have 3 environments for one of our web sites, so I can create the 3 different environments within the configuration tool and I can set up the delta files and which properties to overwrite and when.
All is well until I Export Merged Environment Configuration File. When I do this, it creates the file as intended, however it changes the Environment Configuration File field to now include the absolute path.
Also, the delta file now contains a reference to the absolute path.
We use source control (VSTS) - so absolute paths are no good. Our build process consists of creating branches and then merging the code back into a root. We can't have absolute paths when the branches are created by different team members having their code in a different local folder structure.
Is there any way to stop the absolute path from automatically being added? Or any other suggestions?
My research indicates that there does not seem to be a way to make the GUI tool not override the Environment Configuration File value. The solution I am going with is to use the command line tool provided when installing the Enterprise Library. The command line tool is MergeConfiguration.exe.

Resources