I have a multi-tier project where the application server that provides an access point to the web should deploy its WAR file only if required remote JNDI resources are available.
The JNDI lookup is performed on a different server within the local network, where no access from the outside world is allowed.
My problem is that right now, there is no way to tell if any of the required EJB modules are in place before starting deployment of the WAR - which will fail miserably if a JNDI lookup is not resolved (the remote services are used with Dependency Injection, so they must be present at startup).
Of course, I could set up a timer in my Maven build to wait for an arbitrary number of seconds between deployment of the modules, to allow the EJBs to start, but that seems like a crude hack to me, and it will not be very reliable, depending on which machine does the build.
I would be happy both if an JNDI check can be done directly on the application server, or within the Maven build, prior to deployment.
Is there something like that? I found this question, but there never was an answer...
I haven't tried it, but this should be possible with #Resource, or by creating WEB_INF/ejb-jar.xml and using lookup-name. See https://community.jboss.org/thread/213106.
Related
I'm complete able to configure spring boot in both cases, the question here is which of them are more robust and is the more recommended, because I didn't find in the spring boot documentation the recommended way to deploy it in a production environment, my concerns about use the embedded container are:
If I want to set it as a Windows or Linux service, is the jar file the best option?
If I use the jar file I'm not going to have access to restart the server.
Maybe in the future I need more applications in the same container.
If I restart the machine I have to execute again the java -jar.
The question in general is which is better use the jar file and execute it as java -jar jarname.jar in production or change the packaging to war set the tomcat as provided and set the generated war in an empty tomcat.
I hope you can help me.
---EDIT---
Many times the answer is depends, this is for a normal web application or REST web service.
jar packaging is perfectly suitable for production and you should rather fallback to war only if you really have to - which is often the case when you cannot control your deployment environment (which is often the case in large enterprises).
There is a chapter in Spring Boot Reference about setting up Spring Boot based application as a Unix/Linux/Windows service: Installing Spring Boot applications.
Regarding your concern:
Maybe in the future I need more applications in the same container.
With embedded containers if you need more applications running on the same machine, you should start two applications separately, each running on different port and effectively you will end up with two containers running - which is good, applications are better isolated from each other.
About a month ago I had the question like yours.
Let me share my conclusion:
1) JAR:
You can run independently every appliction with different ports (in linux, java -jar ... > app_logs.log &) and you can route it (e.g. nginx). Note that, restarting is not problem. You can write custom bash script (like this: ps aux | grep appname and kill by PID)
But there are some problems with configuring production app. Property files will archived into jar.
2) WAR
You can deploy into container and just run it. Easy managing at the server. If you want to re-configure app, open properties file from unarchived folder inside container, change it as need and restart container. So, managing and configuring will be easy.
But, if you want to run another app in this server with another port, then you must install another copy of container and config it.
So, in my practice, using war app easier than jar to manage and re-configure.
I don't know that much about Windows services but on Linux you can add the execution of a jar to a RC-Scripts (and thus make the application start at a certain run-level). For a spring boot app you just have to symlink to the jar and you can start/stop/etc like any other service, see: Spring Boot application as a Service
restart the machine or the JVM? A shutdown mechanism is built into spring boot, you just have to activate it (and you should enable security machanism so that not anybody can do that), see: How to shutdown a Spring Boot Application in a correct way?
Spring-Boot enables microservices - so the idea is to have one embedded webapp-container for each webapp/microservice. This reduces the risk of losing all services when only one is going down.
Yes. and you have to execute catalina.sh|bat start after every restart. Or you add an appropriate startup script (see 1.)
I sense that you'd rather do it the old-fashioned way. Despite the 'matter of taste' answer, there is one argument pro-jar: the only dependency is the JVM! The rest (the web-app-container, db-drivers, other libraries) is all part of the package you deliver. And if you decide to change the container for the next release, so will it be.
One more reason to use "war" file in production.
Springboot masked an error Jetty threw whereas WAR deployed in Jetty correctly caught it ( though issue below is still under review )
https://github.com/spring-projects/spring-boot/issues/8917#issuecomment-294673487
I don't know much about server kind of things, But my recommendation is
If you are using Monolithic application, better to use war with
external tomcat.
If you are using for Micro Service applications, use embedded
tomcat with different port. And each micro service applications are
independent from each other.
I've got a glassfish server with a couple of EJB wars deployed on several different nodes. I want one of the applications (deployed on node1) to be 'visible' to all applications deployed on different nodes, so that they would be able to inject some remote beans from it. However, I am allowed to have only ONE instance of this application for the wole server, so deploying it separately on all nodes is not possible.
Is this kind of setup possible in glassfish 3.1?
This is achievable through deployment descriptors:
https://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#cross-appserverremoteref
In your sun-web.xml (or glassfish-web.xml, both will work in this case) define ejb-ref as follows:
<ejb-ref>
<ejb-ref-name>fooejbref</ejb-ref-name>
<jndi-name>corbaname:iiop:node_name:node_IIOP_port#foo.bar.YourEJBRemote</jndi-name>
</ejb-ref>
It's not exactly convenient - you will need to define that for each remote bean you need, and add such a descriptor in every app that needs it. It should however work, and I don't know of any better way.
I'm running into some issues in deploying my Java EE application, and could use some advice.
I have 3 components to deploy:
Integration layer (Data): POJOs and CDI Beans - JAR file
Application layer (BL): EJBs, CDI Beans and POJOs - JAR file
Presentation layer: Servlets and such - WAR file
Optimally, I would like to be able to deploy both the integration and application layer JARs in the same Java EE server, but as separate JARs (since I might want to change the hardware configuration later on and separate them into two different servers on two separate machines).
The problem, is that I'm unable to get the CDI injection from the integration layer JAR to the application layer JAR to work. The server says (and probably rightfully so) that it's impossible to resolve the injections.
So far I came up with these possible solutions:
Package the two JARs into a single EAR file (maybe throw in the WAR as well ...), and deploy that
Use JNDI between the different layers (possibly create a CDI producer to do a generic injection based on JNDI names or something like that)
In the integration layer, make the objects being injected into the application layer (the DAOs) EJBs instead of CDI beans
I don't like either of these solutions (especially the last), since they restrict my future deployment options. The second solution does not restrict me, but it might become tedious at some point (when I accumulate a lot of code).
Finally, my question is:
Is there an option I didn't find yet, that would allow me to deploy the two JARs on the same server with the CDI injections working ? Possibly something that would still work if at some point I separate the JARs into different servers ?
Yes, there are other options as well.
Use a java EE container that supports OSGi as well, and use OSGi interface for your deployment dependencies. At least Websphere, Glassfish, JBoss (with jbosgi installed), Jonas support deploying OSGi bundles. This means your modules should be converted into OSGi bundles.
Use a container-specific extension that allows modules to communicate between each other. JBoss as jboss-deployment-structure.xml that you can use to have a dependency to another deployment.
Use a server-provided shared classpath for your dependencies. Wouldn't really recommend this.
My vote would go for OSGi.
None of them will work by themselves however if you deploy packages to different servers. A remote technology like remote EJBs, remote JNDI lookups, Spring remoting, HTTP-based api, CORBA or similar is needed between different servers. In Java EE, EJB is the de-facto standard for this, but Spring remoting is not bad either.
Update: you added that you use TomEE servers. Indeed TomEE won't support the first two options I mentioned. I would use EJB in that case - the fact that you're using EJBs can be abstracted away from the business layer using an EJB delegate, and you could use EJB (stateless session bean) only for the interface part, leaving your DAOs as POJOs.
not sure what your goal is but deploying a war is fine, can even be done manually with these commands:
mkdir -p webapps/myapp/WEB-INF/lib
cp myjar*.jar webapps/myapp/WEB-INF/lib/
If your goal is to be able to split them you can use TomEE skinny war feature.
Create a war with a WEB-INF/jars.txt file.
In this jars.txt put one line by dependency/jar. It can be the path to the jar or maven coordinates.
Once setup it will allow you to change jars one by one then simply restart the server. This is great when several teams work on the same binary.
There are some alternative with TomEE but this one has the advantage to be easy to change to a portable one (war).
TL;DR
Is it necessary to have an HTTP router module when deploying an EJB module containing web service implementations to WebSphere 7?
If so, is there a way to create/manage it without relying on IBM-specific files?
I have an application that is being restructured so that it can be built Maven. Currently, I am using was6-maven-plugin's endptEnabler goal to build an HTTP router module for an EJB module that contains some web services. This works well, but I just found out that the build machine we'll get to use won't actually have WebSphere installed on it. In the past this wouldn't have been a problem, since the router module had been developed manually by someone clicking a "Generate Router Module" button in RAD and then actually checking in the generated code into source control. With the Maven-centric build process, we thought it would be better to generate the module during the build process.
So now I am stuck: generating the router module via Maven seems a much cleaner approach but won't work on the build machine. I have a few options:
Extract the generated WAR and add it to our enterprise repository and then create a dependency from my EJB to the WAR. I really don't like this, but it would probably work.
Go back to having a realized HttpRouterModule project in the workspace. The problem with this is that the IBM-specific binding files have valid module IDs for my server, but I don't know if they'd cause problems on someone else's which is why I'd rather generate these files from Maven.
Keep generating the router module with Maven, but find a way to generate it in a way such that there is no WebSphere dependency.
I'd prefer to go with the third option, but I'm not sure how I can generate the module and the binding files in generic way such that it will still be recognized by WebSphere.
I'm open to hearing about other options too...
As far as I know you need http router module. From my experience I was also unable to create the module manually. Is there no way you could install was7 dev server on your build machine? I believe it is free download from IBM.
All my research so far indicates that this is necessary in WebSphere 7, and in earlier versions. It looks like WebSphere 8 does not require HTTP router modules. We're going with the second option, as the build server won't be able to generate the router modules on its own.
Not ideal, but once we move to WAS8 this won't be necessary.
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.