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.
Related
I'm at the point in my application where I would like to have an HTTP Server embedded into my project that updates the page in real-time using AJAJ(Similar to AJAX). However, I have no idea where to begin and the amount of tutorials on this subject are fairly limited, so I decided to go with a name that I've heard quite a few times before, Jetty
So, I downloaded Jetty and read through some documentation, and I'm staring at their beginner tutorial asking myself, "Which one of these f*kin jars do I use?" There's like 9,001 of them. Not to mention that there's like 1200 folders that all contain 1500 more jar files each.
Okay, I'm over exaggerating, but take a look.
It's fairly, uhm... confusing. This is much different than most libraries that are a single jar file, this is just... insane.
Anyway, I'm trying to figure out what all I need to be able to use JQuery, AJAX(AJAJ), and basic HTML features.
I'd suggest you to start with this simple tutorial and jetty-all jar
Embedding Jetty Webinar recording
Embedding Jetty docs
jetty-all different versions downlad
To followup on Gas's answer.
jetty-all doesn't have 100% of Jetty.
It used to, hence the name.
However, today its impossible to have 100% of jetty, as many components can conflict with each other.
If you use maven, or gradle, or ant+ivy, then you'll likely want to depend on:
org.eclipse.jetty:jetty-webapp
org.eclipse.jetty.websocket:javax-websocket-server-impl
let the transitive nature of those build tools pull in the rest.
This would get you "started" easily enough.
There are also plenty of example projects that use embedded jetty.
See:
Embedded Jetty: with JSP enabled
Embedded Jetty: with various WebSocket configurations
Embedded Jetty: using Servlet 3.0 features
Embedded Jetty: using Servlet 3.1 features
Embedded Jetty: various Logging configurations
Some use 100% embedded jetty (without a war file, or WEB-INF, or web.xml), some use a war file built elsewhere.
Jetty uses maven so it can participate in the global central artifact repository, and that we have 2 developers on Jetty that are also developers on Maven.
If you want to manage the dependencies yourself, then you will need to know intimately the purpose and role/purpose/relationship/requirements of every jar file that you are going to add into your project. (and answering that is way out of scope for stackoverflow)
You have many build tool options to make managing the dependencies easier:
Apache Maven
Gradle/Grails
Apache Buildr
Apache Ivy (an add-on for Apache ant)
Groovy Grape
Scala SBT (for working with Scala on top of Java)
Leiningen (for working with Clojure on top of Java)
Maven isn't required, you could use any of the above tools.
Tip: Maven and Gradle are the best integrated in various IDEs (like Eclipse IDE and IntelliJ)
I have developed a web application which I am going to sell, but I face some security issues because I am going to provide a .war file to client machines and I found .war files can be easily extracted.
How can one provide security for war files to avoid being copied or extracted?
While searching I found Excelsior jet which converts web apps to native code but it's a trial version and I cannot afford its price so I want to know other alternatives.
A web app container cannot deploy an exe anyway. You can obfuscate your classes and maybe write a licensing module. If you prevent users from extracting your war you'll also prevent the container from deployment.
For example, you might use a Java Bytecode Obfuscater such as
yGuard
ProGuard
JODE
As for a licensing module, you may be able to use
this or this question.
The possible way is to
Use code obfuscator
Code in init() or somewhere check for license/access only one host.
Another option is to code your own classloader and implement it in modified web container
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.
We are currently working on a project for college which we would like to implement as a logic module and UI module. We have little experience deploying web applications, however we came up with the following alternatives:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
We would like to know if any of these alternatives is incorrect, or if any of the alternatives is better than the other. Specifically, why would it be useful (or not) to deploy the project as an EAR module?
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
None of the alternatives are incorrect, though Tomcat is a servlet container, if you want EJBs there you'd need something like TomEE which is Tomcat extended to full EE support. Or use that Glassfish.
What's best depends on your specific requirements: do you need / value more the decoupling of modules or would you rather have the consistency and reliability you get bundling things together. EJBs also have some additional benefits that might be of interest, but they're not relevant for every project. Note that in addition to alternatives mentioned, there are others, such as JMS-based communication, HTTP REST communication and using OSGi to decouple the packages.
About why it would be useful to deploy the project as an EAR module, quoting wikipedia: "EAR (Enterprise ARchive) is a file format used by Java EE for packaging one or more modules into a single archive so that the deployment of the various modules onto an application server happens simultaneously and coherently. It also contains XML files called deployment descriptors which describe how to deploy the modules.". So basically you get the benefits of coupling that boils down to reliability, you'd always know how your modules are deployed in contrast to each other. EAR modules supports EE mechanisms, such as EJB modules, very well and you get a controllable container.
There already exists a thread When is it appropriate to use an EAR and when should your apps be in WARs?, which might be of interest.
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.