I am wondering if there is a simple wrapper class/library for the Tomcat Manager application. I am writing a script to deploy my war to a remote instance of Tomcat (hosted on AWS).
I know I can directly use HTTP to communicate with the manager script interface, but I thought this would be a common problem, so I do not want to re-invent the wheel. I found a python solution here, and this question talks about using curl, but I can't find a java solution (which is funny, Tomcat is used by Java developers, not bash developers!) Can someone please point me in the right direction?
I found what I needed in this answer. I can use the Tomcat Ant library. In order to do so, all I need is the catalina-ant.jar from $CATALINA_HOME/lib in my project's dependencies.
org.apache.catalina.ant.DeployTask task = new org.apache.catalina.ant.DeployTask();
task.setUrl("http://localhost:8084/manager");
task.setUsername("managerLogin");
task.setPassword("managerPassword");
task.setPath("/UrlToYourDeploadingProject");
task.setWar(new File("c:/Project.war").getAbsolutePath());
task.execute();
Related
If i want to deploy one application on different servers like Open Source Glassfish or TomEE. How can I achieve that without having to include different libraries for each application server? As an example if would like to use Jersey as the rest framework and eclipselink as the persistence framework i have to make sure both support these frameworks. But in case of TomEE it's shipped with other implementations like OpenJPA.
Is it possible to ship the dependencies only with the project and not in combination of server libraries + project libraries?
What is a good way to achieve server compatibility?
Any information or link which describes a solution or help me understand why it's done this way would be great.
Thanks in advance
This is more of a application server classloading issue and usually all application servers have a provision for a configuration file which you can put in your application and instruct the server to load the libraries included in the web application instead of the one present in application server. For e.g., Weblogic has a weblogic.xml file which is put in WEB-INF of war application and where you can instruct server to prefer the application packaged libraries. For JBoss there is similar configuration file jboss-deployment-structure.xml. This way it is easier to have a self contained application which contains all dependencies even if the server has equivalent libraries. Also you can upgrade to higher version of libraries than supported by application server otherwise you have to resort to all sort of hacks.
Easy solution I can think of is using ant task to create war file for each servers. You can have at most 2-3 servers in reality like tomcat ee, jboss and glasfish. So create 3 ant tasks for each like tomcatWar, jbossWar and glassfishWar and each ant task makes sure required jars are shipped as well in the war. This is more easy and extendable solution, also easy to understand and modify for new requirements.
The idea is to embed jboss AS7 to my project and add it to version control. Additionally to check the ability of start the server using mvn jboss:devserver (similar to how we run mvn appengine:devserver) So does it makes sense to write my own archtype ?
To my client this reduce lot of complexities so we can create our own jboss configuration to work with and the client's C# developers who will be going to work on java project development. find it easier to setup their local machines to run their changes locally. using similar command mentioned above.(mvn jboss:devserver) I wonder if anyone ever had this idea to work by?
I would probably look into using something like Puppet, instead of checking in all of JBoss.
Puppet uses a custom declarative language to define system configurations. Your puppet script would probably do the following:
Download JBoss from a public server, and unzip it to your desired location
Copy custom configuration files from your version control repo into JBoss
Copy your applications into JBoss
Puppet is a lot more powerful than the simple scenario that I have just described, but this scenario is a start.
With this solution, you would only end up checking in your puppet script and any custom JBoss configuration files you might need. In addition, I believe it would make your JBoss upgrade path a lot simpler, as you would only need to change the version of JBoss in your puppet script, and re-run puppet.
I think the ideal way to deal with situations like this is through packaging. If your client is deploying on some sort of unix server (i include Linux in that), then they are already using a package manager to manage system software on their servers. A package manager has the ability to install software, remove it, upgrade it, and, crucially for you, to install other packages on which some package depends.
You could therefore package JBoss, so that the package manager could install it, then package your application, specifying a dependency on JBoss. When the client installs your application package, JBoss will automatically be installed.
However, this plan only works if you client has a certain degree of infrastructure set up. They need to be using a system with a package manager. They need to have a way of managing package installation (a configuration management tool like Puppet, Chef, Ansible, or something vendor-proprietary is ideal for this). They need to be able to distribute custom packages inside their environment. They need to have either a way of accepting custom packages from you, or of accepting package build scripts and then building packages themselves.
In a server environment of any size, the sysadmins should and probably will have all this infrastructure anyway, because it's fundamental to managing a fleet of servers. But if your client doesn't have it, it may be too much effort to set up.
That said, the absolutely minimal version of this approach would be for you to send them the package files for the application and JBoss by email or SFTP or whatever, and then for the sysadmins to install them manually (eg with yum localinstall). This is not a lot better than having them install JBoss manually, but it's a step in the right direction.
I have created an entire site which includes Jsp and html pages,servlets,java files,and i have used msaccess as the db.All thse have been created using eclipse.What is the best way to deploy this on the web?and how do i do it?
Any help is appreciated.
Thanks
This is what the WAR-format is designed for.
Look into how to package your stuff in a WAR form and use that. Note that very few sites offer both Java and Access. You may want to consider being database agnostic.
do you already have a "java-capable" webserver running somewhere? Are you going to host it yourself or are you going to deploy it to some server hosted by some company?
As YK-47 already said tomcat (http://tomcat.apache.org/) in conjunction with apache webserver is a good choice. You might also want to have a look at jetty (http://jetty.codehaus.org/jetty/)
As soon as you have the server running and accessible over the web you can deploy any java based web application there (i.e. a war-file).
A War file is definitely the easiest method.
If you turn your project into a Maven project it can automatically generate a war file for you, and even deploy it to a webserver if you set it up to do so.
m2eclipse is the plugin you need to get for eclipse, you can then right click your project and go to Configure>Convert to Maven Project. Once this is done look in the Pom file it generates for you and select your output to war (I think by default it might be jar)
If you are new to Maven their website has a quick start guide which may be worth running through which will get you up to speed fast
5 Minute Test
It is worth he effort to learn how to use Maven as in the long run will save you a lot of time... as you wont have to write build scripts
Are there ready solutions (gems, plugins, libraries, etc) for integration ruby (rails) applications and jbilling?
I didn't find even api client for ruby.
I need someone to share his experience with integration. Jbilling has web-service (SOAP ,Java RMI, Burlap) but there is no specific gem for easy accessing and editing data via API.
JRuby 1.6.0 was Released yesterday.
Lines from jbilling manual "All of the API classes are located in the jbilling_api.jar file located in your jBilling
distribution.
The API also makes use of several third-party libraries, such as the Log4j library and
Commons Logging, which provides a powerful logging infrastructure; Spring, which
handles configuration and remoting; CXF, a SOAP library; and Hessian, for
Hessian/Burlap support. You'll therefore need to provide the log4j.jar, commons-
logging.jar and spring.jar files in your class path, if your project does not already
include them.
"
Is that good practice to include so many jars in jruby rails application ?
You can try making your app run on JRuby and using the Java libraries directly. We did an experimental branch of our own app for a similar reason and found some useful projects in the process:
https://github.com/nicksieger/warbler/
https://github.com/calavera/trinidad
In the end we didn't go for JRuby, for various reasons that weren't necessarily of a technical nature.
What version of jB are you using? You could use this project as an example to do your integration.
You can also build such a project from scratch using wsdl2 java utility. Typically, you can access jBilling wsdl at localhost:8080/jbilling/services/jbilling?wsdl assuming jb is running on your local at port 8080.
I would like to run a Java application as a service. Unfortunately, I am limited in that I can't use something like the Java Service Wrapper (which does appear to be an excellent tool).
Is there any way of running an executable JAR, as a service, without relying on external applications? I currently have the service installed, but it fails to start. This is where I am getting stuck and I haven't been able to find anything on Google other than information about the JSW.
There's an LGPL clone of the Java Service Wrapper: http://yajsw.sourceforge.net
BTW, IANAL, but I suspect that JSW people are spreading FUD, and their software can be used to service-enable commercial applications under GPL license, just like one can gzip a commercial app for redistribution. I could be completely wrong about this, though :)
Another option, Apache Commons Daemon's procrun.
See http://commons.apache.org/daemon/
A program that should run as windows service must provide certain functions that the windows service manager uses to communicate with that service.
As long as there is no JVM that implements this functions directly (and I know of none) you will need some kind of wrapper.
I have successfully used srvany for a java based windows service (Basically it allows to run any program as windows service and it works fine with java)
You can use NSSM like this:
nssm install MyService "%JAVA_HOME%\bin\java.exe" -jar "path\to\the\file.jar"
I haven't tried it (yet), but Launch4j looks like it could suit your needs.
one more option winrun4j. the license is eclipse's CPL.
The most simple way I found was RunAsService.
A co-worker recommended a tool called SC, but I did not try it.
JSmooth can do it, and it is scriptable with ant.