I want to know how to deploy two different .jar files on the same port using Jenkins.
The two .jar files is build by Jenkins, i just want to know if there are any better options than re-doing the projects to build .war files and deploy them using a single Tomcat container?
edit:
The reason i'm asking the questions is because i'm building a webapp using multiple microservices, therefor i'm interested in how to do this with "best practice".
It sounds like what you want is a common point of access that your clients can use to access your services. You can achieve this by creating an API gateway service that routes requests to the correct service. Your original two services listen on different ports, but your client only has to know about the API gateway endpoints, the API gateway itself will route the requests.
Have a look at Spring-cloud-zuul or this tutorial to see how to do this.
Related
I am building microservices(approx 15 to microservices) project for huge organization, I wants to know is it recommended to go for external tomcat with war file or just use the embedded tomcat of spring boot with jar file. Also I am facing issue after building my project on jenkins how to copy the file from jekins server to my server and run the file there and create and automatic build and deployment pipeline i.e. everytime I push the code it should be automatically deployed.
You need to identify what compels you to go for external tomcat deployment. As SpringBoot provides out of box facility to deploy within the container, it is not required to go for external tomcat deployment.
Besides, if you are going for many microservices, it will be good to have with built in springboot with embeded tomcat. Springboot also provides the facility to use undertow or jetty. I would recommend to use SpringBoot with either embeded tomcat or undertow with docker container for more flexibility.
It will be good if you provide the issues you are facing.
You can check the below link for reference.
https://dzone.com/articles/spring-boot-with-external-tomcat
I didn't encourage until today companies using Spring Boot and deploying in an external Tomcat.
If there is no requirements from your Infrastructure department, I would go with the embedded tomcat.
JARs vs WARs
I think both have their use cases, like a car vs a truck.
Getting started with jar files is definitely easier, it's provided out of the box. However, using war files in a tomcat has a few perks too:
You can use the "manager" UI to update/redeploy a webapp easely
You can monitor server status, inspect sessions, basically have a look under the hood
You can deploy/update multiple wars independently, which might be handy for larger project
...but there is definitely some learning curve to set things up, and it feels a bit ...old. So it's up to you if you want an easy "jar car" or a whole "servlet container truck". ...or you can also have multiple cars. ;) Each has ups and downs.
Pipelines
Like for any other topic, there are very different ways to achieve this. If you use an extern tomcat, you may configure a "script" user and deploy it like this (or similar):
curl -u username:pwd -d path=/something -d war=file:target/someWar.war https://someurl.com/manager/deploy
...or you can go the other way round and create Docker images, or cloud-init VMs or whatever. Or just a shell script to stop it remotely, upload it and start it.
Depending on your situation, the know how of your team mates, etc, one or the other may be easier.
I'm new to Spring Boot.
I have deployed a microservice into port 80 in some server. This service has URL pattern root as '/test'.
Then I will have to deploy another microservice into same port in this same server. Its URL pattern is '/test2' from another different jar.
Is it possible to deploy 2 different jars that point to 2 different URLs into same port?
There’s two different ways to sort of do this:
1, The already mentioned way of using a proxy in front of the services, so users think they are running the same port, but really not. Nginx has a nifty proxy feature for this, and Netflix’s Eureka is 20% this too.
Build your two Spring applications as .war files, and deploy them to an application server like (non-embedded) Tomcat. There’s a good blog article on how to generate a .war and deploy it to a standalone Tomcat.
Put the two services in seperate Docker containers. (But you’ll still need to EXPOSE different ports to the outside world, so this answer is kind of cheating.
Option 2 is probably closest, and you’re still in Javaland... but it’s not the hip new way to deploy things in Spring Boot land in 2018.
Have a third microservice as proxy for the other two. Forward requests to them based on request content, context, URL pattern or anything suitable to your specific application.
If you have the code for both,
Dont need the code, just include the class names (by scanning the jars or asking the dev team)
Can make a new main method that scans all the packages and adds them to the context. Then start that method. I think it will scan all jars in class path. So even if your new main method is in one jar it will scan classes in the other jar. That way wont have to repack to one jar.
This is one way to keep one JVM and one port.
The proxy method suggested by Timir is fine too. Instead of a Java microservice I will suggest use Nginx or apache web server for composing, Run the two Java processes in a different system or different port if same system as the web server.
I want to split a large web app into different sections.
In my case there is a webshop, an api service, and then the main app.
and all of them should share a domain layer.
I'm trying to reproduce an ear layout without using a enterprise server, so the main app would be a war with a shared domain jar, and the admin app would have a contextPath /admin and also share the same domain.jar.
From start they would be deployed together but as the app grows I would simply start deploying the apps on there own ports and use nginx to glue them together.
I've implemented most of it in this demo github repo.
https://github.com/leon/springboot-multiproject
My question is:
How can I map the admin app to a sub directory of the main app?
/admin <- Admin app
/ <- Main app
and do I need to take any special considerations when it comes to the domain layer?
See https://github.com/leon/springboot-multiproject/blob/master/src/main/java/se/radley/main/Application.java#L23
I can't think of a particularly easy way to completely separate the parts of your application. One option might be to create two ApplicationContexts and spin-up two Tomcat servers, but then they will obviously need to run on different ports.
I would be tempted to keep things simple initially. You could create separate jars for your 'main' and 'admin' #Controllers, one for your domain and keep the application jar containing configuration. Component scanning will work withing nested jars so a single DispatcherServlet can happily server both the /admin and / controllers.
Either that, or perhaps just bite the bullet and break-up your applications from the start. At least that way you will be aware of any architectural issues early.
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
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)
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.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!