My area of expertise is not in Java; I write Java code snippets where needed by my other apps. Others in my organization do work with Java.
For a large browser-based app developed in Java using Eclipse Oxygen and deployed on Tomcat or WildFly on a RedHat 7 server, how does one create a patch? i.e. where a couple of JSP's and classes have changed, must the complete WAR be created and redeployed? Or, is there a way to generate a WAR that only has these changes, and deploy it on target machine via CLI or TC/WF console?
The complete WAR may be a few gigs in size so would take longer to email to client, whereas a 50KB patch would appeal more to a sense of neatness. Also, if I send out monthly updates with full WAR's, the backup size would be much larger.
Is there a tutorial one could follow?
Related
I have been programming in Java for 3 years, but have mostly been deploying Java applications locally, and thus, have not had a need to think about scale, auto-updating, deployment servers, and the like. I simply used a corporate shared file drive for distribution, and wrapped the jar in an Exe wrapper every time I wanted to push an update.
However, the company I work for wants to scale the Java desktop application I made, and deploy it across departments. This calls in the need for automated deployment, updating, and change tracking. So, for the last week, I have been searching and speaking with a lot of people about the process of automating the deployment of Java applications. Of course, I have found a huge amount of response pertaining to Java EE, tomcat servers, and mostly web based applications. But, what I am looking for is a way to manage Desktop based Java applications, that run from an executable on a user's windows machine.
The question then that I have run into, how is it that I would get started setting up automatic builds, updates, and deployment when I the target audience is running the applications from their desktop as an Exe wrapped jar file? I have found a few articles that reference installers with update based capabilities, but I'm trying to figure out how I can utalize a Java server to autocompile and distribute updates, and all that Jazz. Like I said, I am extremely dumb when it comes to this side of Java and would love any direction that there is to offer. Thanks!
I understand the concept of source version control and how it applies to self-contained projects like a Windows application. But for web development, most files are stored on the web server. This has become a headache for development with many people just copying and renaming files and then pushing files over to production is another mess.
I need some kind of source version control that is relatively not too difficult to learn and must be GUI-based or have a GUI as an option. The people who will use this have little or no knowledge of the command line.
How can I integrate source version control with web server files? What software is available for such an endeavor? And is it possible to have the source version control software administer both the production and development web servers or I may only have two separate source version control installs for each web server and manually push over changes?
The web servers are Windows-based and also use Tomcat for Java/JSP.
Any help would be appreciated. Thank you.
I think you are not clear on the idea of version control. Version control is about managing your code. It is about putting your code in a remote server (may be in a central location) and accessing it using a client tool. This way a number of people can work on different part of the code and than push their work to version control server. It has nothing do with the type of the project.
The project can be a windows application, web server application or any application.
While using version control, in regular intervals or whenever needed you build your code from the version control server and deploy it to the web server which means you are deploying code that is already build (a .war for a web application).
You first deploy to your development server and later deploy the same war to the production server.
You can use SVN server for your version control server and Tortoise SVN as client.
You have to split in mind two different but interacting things - Version Control and Deploy Tools:
VCS has to do with any evolving over time items, which you want to have under control
Deploy just deliver correct object into the correct place at the correct time and convert "set of something" into Product.
Deploy isn't a problem per se (almost any job can be automated), main problem in multiDEV environment (2+) with central STAGE (less with PROD) server is question of communication between Devs and synchronizing of their operations, i.e. - workflow and management:
just imagine 2 (or more) devs, performing diferent unrelated tasks, which want to test latest own (and only own) changes on common STAGING server (because they haven't functional local environment). If 1-st deploy "some WIP" on server, he don't want to have own tests be interrupted and code poisoned by deploying third-party changes. They must to communicate and coordinate actions, it can't be dumb "copy to..." in post-commit hook
And is it possible to have the source version control software administer both the production and development web servers
Yes. But VCS does not "administer" web-servers in common sense, rather it's "communicates" or "take into account"
There seems to be a current trend in java space to move away from deploying java web applications to a java servlet container (or application server) in the form of a war file (or ear file) and instead package the application as an executable jar with an embedded servlet/HTTP server like jetty. And I mean this more so in the way newer frameworks are influencing how new applications are developed and deployed rather than how applications are delivered to end users (because, for example, I get why Jenkins uses an embedded container, very easy to grab and go). Examples of frameworks adopting the executable jar option:
Dropwizard, Spring Boot, and Play (well it doesn't run on a servlet container but the HTTP server is embedded).
My question is, coming from an environment where we have deployed our (up to this point mostly Struts2) applications to a single tomcat application server, what changes, best practices, or considerations need to be made if we plan on using an embedded container approach? Currently, we have about 10 homegrown applications running on a single tomcat server and for these smallish applications
the ability to share resources and be managed on one server is nice. Our applications are not intended to be distributed to end users to run within their environment. However, moving forward if we decide to leverage a newer java framework, should this approach change? Is the shift to executable jars spurred on by the increasing use of cloud deployments (e.g., Heroku)?
If you've had experience managing multiple applications in the Play style of deployment versus traditional war file deployment on a single application server, please share your insight.
An interesting question. This is just my view on the topic, so take everything with a grain of salt. I have occasionally deployed and managed applications using both servlet containers and embedded servers. I'm sure there are still many good reasons for using servlet containers but I will try to just focus on why they are less popular today.
Short version: Servlet containers are great to manage multiple applications on a single host but don't seem very useful to manage just one single application. With cloud environments, a single application per virtual machine seems preferable and more common. Modern frameworks want to be cloud compatible, therefore the shift to embedded servers.
So I think cloud services are the main reason for abandoning servlet containers. Just like servlet containers let you manage applications, cloud services let you manage virtual machines, instances, data storage and much more. This sounds more complicated, but with cloud environments, there has been a shift to single app machines. This means you can often treat the whole machine like it is the application. Each application runs on a machine with appropriate size. Cloud instances can pop up and vanish at any time which is great for scaling. If an application needs more resources, you create more instances.
Dedicated servers on the other hand usually are powerful but with a fixed size, so you run multiple applications on a single machine to maximize the use of resources. Managing dozens of application - each with their own configurations, web servers, routes and connections etc. - is not fun, so using a servlet container helps you to keep everything manageable and yourself sane. It is harder to scale though. Servlet containers in the cloud don't seem very useful. They would have to be set up for each tiny instance, without providing much value since they only manage a single application.
Also, clouds are cool and non-cloud stuff is boring (if we still believe the hype). Many frameworks try to be scalable by default, so that they can easily be deployed to the clouds. Embedded servers are fast to deploy and run so they seem like a reasonable solution. Servlet containers are usually still supported but require a more complicated set up.
Some other points:
The embedded server could be optimized for the framework or is better integrated with the frameworks tooling (like the play console for example).
Not all cloud environments come with customizable machine images. Instead of writing initialization scripts to download and set up servlet containers, using dedicated software for cloud application deployments is much simpler.
I have yet to find a Tomcat setup that doesn't greet you with a perm gen space error every few redeployments of your app. Taking a bit longer to (re-)start embedded servers is no problem when you can almost instantly switch between staging and production instances without any downtime.
As already mentioned in the question, it's very convenient for the end user to just run the application.
Embedded servers are portable and convenient for development. Today everything is rapid, prototypes and MVPs need to be created and delivered as fast as possible. No one wants to spend too much time setting up an environment for every developer.
I was handed an application where these two JARs are simply included in the lib directory. As far as I can tell, they aren't actually distributed separate from the Java Enterprise Edition packages. Assuming that they have everything that I need, is this a good idea? It does cut down on the size of the deployment.
Those jar files are just needed in the classpath. If they are you don't need to include them in the deployment.
It's not sane to remove any package for the Java EE installation if that's what you mean. It could affect other apps that do need those packages and the bugs are kinda of hard to track down when they happen.
UPDATE
So the question would be is it OK to run Java EE libs without a Java EE insall?. If there is no Java EE installation and that app is meant to be run with a JRE there is nothing wrong with that. It's just an app that needs the JRE plus 2 libs from the Java EE, just make sure (thats the tricky part) those libs don't have any dependencies from other Java EE libs
UPDATE
Both apparently don't need other dependencies but if you want to make sure download them from the maven repositories.
It depends whether you want to deploy your application on some Java EE application server (Glassfish, JBoss etc.) or keep it outside. In latter case, it is not question if that's good idea or not - you have to include imq.jar and jms.jar in your application to be able to communicate with JMS message broker.
I have used this approach many times, one example is standalone application that sends SMS by putting it on a message queue. On the other side, there is a MDB within application server that listens on particular message queue and sends the SMS.
We want to migrate UI rich application from delphi to java or Web Application.
Reason is that we want application to be portable on all Operating Systems.
Current Components and Modules of Application in Delphi :
In Delphi we are utilizing TWebBrowser component to display HTML content
We are playing mp3 that is extracted from FileStream on clicks in HTML.
All resources for HTML are retrieved from Embeded Database Firebird/Ms Access.
To sync some content we are doing HTTP post to PHP scripts to centralize the data on webserver.
Deployment:
- Application has to be deployed on CD and installed on Desktop computer on Mac OS, Linux, Windows.
I need your help how to approach this migration. Is better to go with Java UI or Web App that will be deployed with WAMP/XAMP and appropriate distributions on Linux and Mac's.
EDIT:
I have some specific requirements for audio functionality. Audio files are separate files distributed on CD or USB. Audio files are one solid file compiled from mp3's inside. Application will have to have ability to extract the mp3 based on offset and size of mp3 stored in index file and to play in real time... How this affects idea of Web App using this approach.
Why don't you give FreePascal a try? It uses the same language as Delphi, and can compile to a native application on Windows / Linux / Mac. Since you already have your app in Delphi, converting it shouldn't be too difficult.
Have a look at the freepascal website
If I had to deploy on a CD, I'd probably go with Adobe's AIR. It is really fulfilling the promise Java made 10 years ago in a reasonable way. It isn't perfect, but it does a pretty good job.
I've heard this internet thing is really taking off.
For all of the reasons that applications have gone online over the past 10 years, there really isn't much discussion to be had.
While Java is reliable, distributing and rolling out subsequent updates to those applications is heavy and time consuming.
I did Delphi development for over 9 years. I resisted the idea of distributing real applications over the web for quite some time. Today, I can't believe anyone would choose to continue in this way.
One nice thing, you can probably reuse some of your Delphi logic on the backend if you get creative. (I would only recommend this for the short term)
But, this answer doesn't really address your issue as you are saying that you must distribute it via CD.
The Java 6u10 release allows for distributing Java WebStart applications on media instead of from a Webserver, which might be exactly what you are looking for. You can also put the JRE installer for Windows on the CD too, if needed.
What exactly are your requirements crossplatformwise?
If most of the application is HTML-based, why not make it a full web application, using Ajax and Java?
I recommend NetBeans, and ICEFaces, which is a Java Server Faces implementation with Ajax support, including concurrent updates - if one user edits a record, all other users will see an update in their web page.
It is possible to package the whole application in a single jar file, including the servlet container (Jetty for example), so a simple java -jar myapp.jar will run the application.
NetBeans allows visual editing of the ICEFaces web pages, and even visual editing of the page relationships. The tutorials on NetBeans.org are excellent, and with tools like Maven, Hudson and others, code quality and development process can reach a very high level.
If you have some Delphi application using Datasnap : you can also re use your server made in Delphi with Datasnap in Delphi Prism and make Silverlight application.
And the same is true for DataAbstract