I have a Spray application that I would like to run against a different configuration file. In my resources folder, I have a set of configuration files as:
resources
application.conf
application.integration.conf
application.uat.conf
With the Play framework, I normally put these files inside the conf folder and I do the following to run the application:
sbt -Dconfig.file=conf/application.uat.conf run
How can I do this with Spray application structure?
Additionally, how could I jar a spray application using sbt so that I can deploy it to a specific environment and just have a script that takes care of starting and stopping the Spray HTTP server?
I don't know exactly how you are packing and deploying your app, but you can try this: by default, application.conf will be picked up. Additionally, you can override it when running your app with the config.resource property in a similar fashion as config.file. Moreover, you can have specific configurations for different environments as you have, and they can include application.conf.
All these details are crystal clear in the Akka documentation: http://doc.akka.io/docs/akka/2.4.1/general/configuration.html#Including_files
As for packaging it, you have several alternatives; two good candidates are sbt assembly and sbt-native-packager plugins.
Related
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.
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
Inside maximo anywhere we have 4 apps out of which i want only work execution app to be build and deployed.
Currently ant build is building and deploying all apps which is time consuming. Please help
It's in the build.properties for the solution.
Check here for some more info on it. The build.properties contains the variable aspects of the build process and defines the target server to which an app is deployed. it can be found here: maximoanywhere_home\AnywhereWorkManager
In order to specify the applications you want to build, you're looking for "appsToBuild" property in build.properties as mentioned.
appsToBuild=WorkExecution
In order to limit what apps are built, you will need to edit the "appsToBuild" property in the build.properties.
However, this does not apply to what apps are deployed. In my experience with Anywhere apps for iOS, all IPA files that are in the bin folder are deployed, not just the ones specified in the appsToBuild property in the build.properties file. This can cause problems (such as deploying an app that was not built for the server you are deploying to). To prevent this, delete the contents of the bin folder before running the all-dist command for the build ant script. Then when the all-deploy command is run, it will only deploy the files that were recently built to the server.
I have almost finished the development of a project developed with Symfony2, and wish to put the project online.
However, I suppose there are a lot of things that need to be done so that everything works ok. I suppose, the dev mode needs to be disabled etc....What needs to be done and how?
What are the most important things to do on a Symfony2 project that will be available to everyone on the web?
I suggest you to use Capifony for deployment. It does a lot of stuff out of the box and you can make it run any custom commands you need. See its documentation for details.
Regarding the dev mode, unless you've removed the IP checks from app_dev.php, you don't have to worry about deploying it. Of course, if you wish, you can tell Capifony to delete it on deployment.
The best way to handle deployment is to create "build" script, which will:
Remove all folders and files with tests from your bundles and vendors.
Remove app_dev.php file
Make sure that app/cache and app/logs are fully writable/readable.
Packs your project into archive (rpm f.e.)
Then, before deployment, you should create tag in your project - so it will mean, that certain version of your application is released (I recommend to follow this git branching model).
Create tag.
Run your build script
Upload archive to host
Unpack
Enjoy your project
Im currently researching the same thing.
The first thing you have to consider is "how professional" you want to deploy. There are a lot of tools you can use:
Continous Integration Server ( e.g. Hudson, Jenkins)
Build Tools (e.g. Phing, Capistrano --> Capifony, Shell scripts)
Versioning Tools (e.g. Git, SVN)
I think the simplest setup is using only a Build tool and i guess you are already using some kind of versioning.
Depending on which tool you use, the setup is different, but I think there are some things you should consider with your application (maybe not all are applicable to your application)
Creating a Tag in your Versioning
Copying the new Code in an folder on production
--> if you are in a new folder you dont need to clear the cache and logs, since these shouldnt be in your versioning the first time.
loading composer (if youre using it)
installing vendors
updating database schema
install assets from your bundles
move symlink from current version to the folder of the new site
These are the things I currently need for my application for production deployment, if you deploy to an test environment you should load fixtures and run your testscripts as well.
One other option that is very well described here is to deploy the Symfony2 application with Apache Ant. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.
The majority of our internal apps are built on a Java EE stack using Ant, and deployed to Tomcat with a WAR file. We have a build box that creates a Production-targeted WAR, and the WAR is then delivered to the Test environment. A script is run to convert the deployed webapp to point to Test data environments.
After a few cycles of Test -> Bug Fix -> Build -> Redeploy to test, the WAR file is then deployed to Production, and is then live.
I've recently inherited some ASP.NET 4.0 webapps, and their Build/Deploy is quite different; the code is built in VS, and then the entire project directory is copied to each environment. It is then tweaked by hand, and is occasionally rebuilt with a VS instance on the server.
This is a bit scary, as there are plenty of opportunities for tweaks in one environment to be forgotten, and thus require that we're playing around with our apps after they're "live", outside the bounds of testing, version control, etc.
So, all of this being said:
Is there an equivalent to the Ant/WAR mechanism in a .NET world? What's the safest way to create an executable artifact from a .NET webapp and move it between environments with minimal modification? I know that "best pratices" is a taboo phrase, but I'd like to dip into some expert knowledge before I remake Ant in .NET. :-)
Three technologies you need to know about to automate web deployments:
MSBuild - This is Microsoft's equivalent of ANT. Project files are basically just a series of MSBuild tasks.
WebDeploy - This is essentially your WAR/Tomcat equivalent, except that it creates deploy packages, and is meant for IIS.
XML Transforms - You should never have to manually edit configuration by hand. Config transforms are essential if you have multiple environments you need to deploy to.
Put all these together with your favorite Build server (I use Jenkins), and you can totally automate your entire deployment process to any environment. Each of these individual topics is too broad to cover in depth here, but you should be able to get started with minimal knowledge of each.
To give you an example of how simple it can be, here is a sample command line build that will deploy a website to a 2003/IIS6 box.
MSBUILD "MyWebSite.csproj"
/p:Configuration=Dev
/p:OutputPath=bin
/t:Rebuild
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/P:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://MyDevServer
/p:DeployIisAppPath="Default Web Site/MyWebSite"
/p:username=deployUser
/p:password=deployPassword