We have a web application (Metro web services on tomcat) and need to handle properties to access remote systems.
Of course the properties are different in test and production environment.
We could deploy a properties file with the WAR file, but this would require manual steps after the deployment of the application. (editing after the deployment)
In other projects we had property files located in directories 'above' the deployed web application, to avoid that the property files are changed - but I'm not sure if this is a good design.
Which is the 'cleanest' way of handling server specific properties with tomcat web applications?
Define the settings in Tomcat's server.xml, then access them in your application with JNDI. See: http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html
Either put it directly it into WEB-INF/classes and if it is made to configure by non technical person then keep it in user.home/appName/
Related
To load different application specific properties files from different manage servers in Jboss, there is an option to call the application specific properties file using:
System.getProperty("jboss.server.config.dir");
Is there any way to load different different properties files from different managed servers in weblogic?
There is batch configured in the application source code which needs to be run from only one manage server.
Is it application specific properties files you are loading? Can you let me know what property file you are trying to load?
Is it possible to deploy a java web application using Hibernate and Spring MVC to a simple website cPanel-> File Manager as we deploy a simple php/mysql application?
Thanks in Advance
With Spring Boot you can build jar with embedded Servlet container, so Java runtime has to be available at minimum.
Amount of RAM available on shared hosting PHP services is often pretty low, so may not be enough for your needs. To find hosting for your Java/Spring application, pick hosting services that specialize on Java/Servlets.
Also if you are planning to rely your business on such application you should avoid shared hosting as same machine is aggregated between various users. So aggregated users can degrade performance of your application.
Yes, it is possible to deploy war file into cPanel-> File Manager as we deploy a simple php/mysql application. But for that you required tomcat in file manager . Just zip the .war file and upload in manager directory and just extract that zip file.thats it!
Please refer this:
https://documentation.cpanel.net/display/CKB/How+to+Deploy+Java+Applications
I've created a dynamic web application and i'd like to deploy it with glassfish. I've successed build my sources to MyProject.jar. But when i deployed it, the following error displayed:
remote failure: Archive type of /home/davenlin/MyProject/build/MyProject.jar was not recognized
My project is just a normal Restful application, not ejb application, so i don't know if i must generate a MyProject.war instead of MyProject.jar.
Please help me. Thanks !
Okay, because my comment was rather unexplanatory:
Web applications are handled by application servers or servlet containers.
Both do quiet a lot of work for you and web applications are not comparable to
desktop or standalone java applications. While your standalone applications are deployed as jar - files and then executed by the JVM, web applications are
executed by the container (application server / servlet container).
So this does require your application to provide additional configuration and affords the archive itself to have a different structure.
So even if you are just exposing some web services to build a restful application, your application server will do things for you such as
forwarding requests to the right classes, translate query and post parameters into java - objects accessable by your own classes respectivly your own objects and returning your response to the clients.
The interesting thing about it is:
The additional files in the web - archive are usually xml - files and web - related files such as html, css, js.
So this does not distinguish war's from jar's as you can also package additional resources within a jar.
The basic but now obsolete requirement on a war - file is that it contains
a deployment descriptor (which is again is an xml - file)
to configure your application , its context and the relative url (more concrete : url - patterns) it uses , but as this requirement is obsolete someone may still think that this distinguishing is obsolete, too.
We are developing a new project (spring, mvc, jdbc, rest) which we are considering to deploy it in JBoss Wildfly 8.1.0. Before we were using the JBoss 5.1.0 where we had datasource and other configurations easily created and configured along with the war file. As I am trying to learn the Wildfly I feel it has datasources and other things to be configured separately through cli or ui console.
Instead every developer in this project configuring the datasource manually on their system-server for development, is there a way to run a script to generate datasource or other way to have a single server configured with everything the project requires so that the developers can deploy their modules (war) and test it?
I see the Wildfly has two modes, domain mode and standalone mode. Is this domain and "5.1.0 domain" are different? Which is the right mode to run the server in production? I am testing my application for now in standalone mode. From the jboss doc, I see this domain is for managing the app if it is deployed in a cluster. (This project under development is non-clustered single node web-application.)
How to deploy more than one web-applications in a single Wildfly server? Do I need to create domains for every application?
How to configure app specific property files in Wildfly? (We had a prop directory created under the jbossserver/default/deploy/prop/application.properties)
You can use CLI to create datasource from command. With CLI commands you can create script also. You can find it on Google. It will be server specific and no need to create in your project.
If you don't want to run jboss in cluster mode then you can use
standalone.
You can deploy any number of web application. You need not to create
domain. Just create WAR files and deploy. You can copy WAR files in {JBOSS_HOME}\standalone\deployments folder.
When deploying an application to JBoss server, for a JAR like ojdbc14.jar (Oracle JDBC), is it better to include this jar in the ear file of the deployment, or should it be deployed to JBoss's server/default/lib folder?
The argument I've been given is that the application needs to support global transactions, hence the datasource must be defined at the application server level (e.g. copied to server/default/lib folder) so it can talk to other app servers, and for that to happen you need the drivers at the app server level.
I'd like to hear what is the correct approach here. Thanks.
I believe this is the correct approach.
You will typically define your datasource outside of your application (outside of your EAR/WAR) using the appropriate configuration files depending upon the application server you are using. Whereas on JBoss, you usually add your configuration to XML files, with WebLogic, you can create a datasource directly using the Admin console.
Given that this datasource will be created on server startup, the necessary libraries (in your case, ojdbc14.jar) must be available on the classpath of the application server.
I have also come across licensing issues where the use of a 3rd party library prevents you from bundling it within your application.
Also, defining your datasource outside of your application means you do not have to perform a rebuild when the datasource configuration needs to change.
So many time I have done that...
I will always put the jar inside the server/default/lib folder if it has something to have about JDBC.
Because your database driver is loaded one time as soon as the server is started, and not each time you deploy/undeploy the webapplication your are working on.
Your datasources will be availiable for any others sub-projects too, and it will be a great advantage when you have a specific project for integration testing purpose.