I have an Spring based J2EE application which runs well on Weblogic, I wanted to move it to Tomcat.
It seems tomcat doesn't support JTA Transaction Manager without external jar help like Atomikos, JOTM, Bitronix, SimpleJTA.
I am reluctant to make changes into my application where i am already using annotation based JTA transaction manager.
Are there alternatives for JTA Transaction Manager which I can use so that I am able to switch from weblogic to tomcat or tomcat to weblogic or any other server without changing my configuration file each time?
All in all what's best for transaction manager configuration when you want to keep your application (war) independent of server(s).
You could try TomEE.
It's a Java EE 6 server that meets the Web Profile requirements and is based on Tomcat.
So it will support JTA transactions.
You can get it from http://tomitribe.com
Just to give you a more direct link to TomEE: http://tomee.apache.org/download/tomee-1.7.2.html
If your application is configured and developed to use Weblogic then chances are you are using JDNDI to lookup the JTA transaction manager and your datasources.
So any solution that supports the same lookups would work.
For Atomikos, we recently added (commercial) support for Tomcat's JNDI space - check out http://www.atomikos.com/Main/BuyOnline to learn more.
Hope this helps!
Related
The end goal is to have a Spring Boot app that works with an XA transaction coordinator, in particular that coordinator would be Narayana.
We think that since Wildfly uses IronJacamar, Spring Boot could use it too.
Where can we find examples of this, or some instruction to get us there quickly?
The IronJacamar is used as the JCA and pooling library for WildFly but for other projects the Narayana can be configured to used other libraries. IronJacamar is fully fledged implementation of the Java EE JCA specifiation which is often not necessary when running on runtimes like Quarkus or Spring.
For example within Quarkus (https://quarkus.io/) there is used Agroal (https://github.com/agroal/agroal), for Apache Tomcat it could be DBCP2 (https://github.com/web-servers/narayana-tomcat).
For Narayana and Spring integration it could be recommended to work with the Snowdrop extension - https://github.com/snowdrop/narayana-spring-boot - where DBCP2 (instead of IronJacamar) is used.
How to use the IBM WebSphere work manager together with the Spring #Scheduled annotation in my servlet?
Spring provides the WorkManagerTaskExecutor. It allows to configure a work manager as described in the WebSphere docs or in this SO answer. However I don't see a relation to the #Scheduled annotation and can't find any documentation how it works internally.
My goal is to configure scheduled tasks in a convenient way (as given by #Scheduled) but I need the task threads created by the scheduler to be managed by WebSphere.
EDIT: In the original question I confused DefaultManagedTaskExecutor with WorkManagerTaskExecutor as the latter is deprecated in favor of the first. Now I understand that WorkManagerTaskExecutor is Java EE 6 (and therefore required for our WebSphere 8.5 environment) whereas DefaultManagedTaskExecutor belongs to Java EE 7 and can indeed be configured for #Scheduled which is documented with the #EnableScheduling annotation.
I can see what you mean that Spring documentation appears vague as to the relation between task executors that you configure and #Scheduled. Absent that sort of guarantee, you could verify observationally if scheduled tasks are running on WebSphere Application Server threads by printing the stack from one of your methods and confirming the presence of com.ibm.ws.* packages. One easy way to do that is,
new Exception("capturing the stack").printStackTrace(System.out);
Spring's DefaultManagedTaskExecutor is documented to rely on java:comp/DefaultManagedExecutorService, which requires Java EE 8 (or Jakarta EE) and ought to work with version 9 of WebSphere Application Server traditional. It should also work with WebSphere Application Server Liberty.
If you are on 8.5.5 or earlier, you would need the WorkManagerTaskExecutor (referenced in one of the docs that you linked) which is based on the CommonJ WorkManager.
In my theory spring boot is capable of running java web application stand-alone. It says it has a own embedded servlet container and can use JNDI itself.
I built a war file before (spring-mvc, security, gradle built), but Spring boot assemble jar file and it runs on any machine which has JVM.
So my question is, if I made a spring boot based web app (contained JSP files & JNDI for looking up datasource), although it has own embedded servlet container and packaged jar file for running standalone, do I still need to package it as WAR file and deploy it in WAS (Websphere Application Server) or servlet containers for any reasons such as performance, stability, scaling-out etc?
WAS is an full blown Java Enterprise Application Server, on the other hand you have Spring that only requires a Servlet Container (Servlets are a part of full JEE).
Servlet Containers are for example: Tomcat, Jetty, but also WAS.
Spring Boot is able to package the complete application TOGETHER with the code of Tomcat in an JAR, so that this jar contains the Servlet Container and your Application.
Do I need a additional WAS for performance, stability, scaling-out etc?
Performance: No - There should be no important performance differerence between Tomcat and WAS when you run a Spring-Application. (Only that Tomcat needs less memory for itsself)
Stability: Tomcat and WAS are both very mature products.
Scaling: You can build a cluster of Tomcats by your own.
The main features of WAS over Tomcat are:
- WAS supports EJB and CDI (Tomcat would need TomEE for this), but Spring will not use it, because it is its one Dependency Injection container
- WAS has more Monitoring features, but this does not matter, because Spring Boot has Actuator
#See Difference between an application server and a servlet container? for more details
Simple answer is No. You do not need any Full blown application servers for any of the reasons that you mentioned (for performance, stability, scaling-out). You can just do fine with tomcat
Edit
Looks like you are using only JNDI feature from the Application server. Do you really need JNDI when you pack your servlet container along with your application ? I don't think so. That days are long gone.
JNDI really shines when you have to move an application between
environments: development to integration to test to production. If you
configure each app server to use the same JNDI name, you can have
different databases in each environment and not have to change your
code. You just pick up the WAR file and drop it in the new
environment.https://stackoverflow.com/a/7760768/6785908
(If you still need JNDI to be used to look up your data source refer: https://stackoverflow.com/a/24944671/6785908).
No, still I do not really see a reason for packaging your application as WAR and deploy it to traditional application server. That being said, if you have some existing infrastructure lying around and you are being forced to deploy to existing WAS (or WebLogic or JBoss any application server for that matter) server, then I rest my case :).
I am working on a Server Migration Project from Weblogic to Websphere. The problem is that in Weblogic, we are already using a class specified as Startup-class in Weblogic (and arguments to the class like log4j config file) which is present in a jar which is added to Weblogic classpath by editing the startup script. This jar initializes a global log4j file which is for all the apps deployed on the server and not for any particular app. Each app is distinguished by a category of log4j.
Now I could not find a similar thing in Websphere. So what is the best solution? I can create a new application which would do all initializations like that of the startup classes. I thought of using startup-beans but read in some IBM documentation that they are deprecated due to EJB 3.1 Session Beans. Also how to make sure this app loads first? By giving Websphere xml file startup weight 1 like here?
I am using Weblogic 6.3.2 and Websphere 8.5
The WebSphere migration toolkit suggests to replace the WebLogic T3StartupDef and T3ShutdownDef implementations with either a ServletContextListener implementation, session startup bean (Singleton), or a servlet that is configured to load at startup time. If you haven't used the WebLogic to WebSphere migration toolkit, check it out. It provides a lot of help especially with deployment descriptor extensions.
The #Singleton session bean in EJB 3.1 replaces the proprietary WebSphere startup bean.
The best approach depends on the type of module you need the startup logic.
If you are considering the custom services option, note that the com.ibm.websphere.runtime package is not available in Liberty if you are considering the Liberty server.
It sounds like custom services (or a custom feature on Liberty profile) are the best analog if you need to run logic during server startup. Otherwise, if you just need to add a library to every application, then create a shared library and then either associate it with the server or associate it with specific applications or modules.
I want to find out if my thoughts are correct about deploying MDP on JBOSS:
There are definitely advantages of using MDP instead of MDB but all these advantages will only work when you don’t use an EJB Container/App Server. Since, I need to use JBOSS 5 APP server, it would be an overkill to have an MDP running under Spring Context which in turn gets deployed on JBOSS App server.
The second reason is Spring framework releases are very quick whereas JBOSS 5 is old, I believe that there will be issues such as conflicting jars.
The third reason is that I haven’t seen many people doing it.
I've been working on several Spring-based projects with more than a dozen message listeners and those projects were deployed, namely, on JBoss (from Jboss 4.x in the early days to the latest JBoss EAP).
There's nothing wrong with deploying a Spring's message listener container within the JBoss infrastructure. In the past, you could hit some inconsistencies though. The most annoying was that the redelivery options defined on the queue were ignored. But that's history as from JBoss5+
To deploy your message listener container on JBoss, you need to configure a regular JndiTemplate and lookup destinations and the ConnectionFactory using it. To be able to resolve destinations by name, you need to specify a JndiDestinationResolver on the container that uses said JndiTemplate. You could also lookup the queue yourself (and get rid of the DestinationResolver)