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.
Related
I am facing an issue in my restlet project where I have to code some operations only if the EAR is deployed in Websphere in a restlet server project. Is there any way we can get information through code to find out where is EAR/WAR deployed? (Is the EAR is deployed in Websphere or Tomcat or other servers).
Try to instantiate some WebSphere API class. If you get a NoClassDefFound, it's probably not running on WebSphere. You might have to do class.forName(Websphere class), so your code will compile outside websphere.
If you only need to check that for example in Servlet/Filter class you can look for servlet context attributes related to WebSphere, for example com.ibm.websphere.servlet.application.name = Default Web Application. You can find some attributes looi=king at the /snoop servlet if you have that installed.
Or, as Bruce suggested try to load some WebSphere class and be prepared for errors when they are not there.
I am trying to understand the implementation difference between creating a local or remote interface for my stateless session bean however I see various solutions and am wondering if there is a certain "standard" or general "preference".
For local interface, I can create everything (servlets, session bean, jsp) within a Java EE Enterprise Application project.
For remote interface, do I need to create the remote interface in a Java Class Library or Java Application or Java Web Application? Then the remaining code is within a Java EE Enterprise Application project...
Also, what is the reason for creating a session bean in a Java EE Enterprise Application Project instead of a Java Web Application Project?
Thank you!
I am trying to understand the implementation difference between
creating a local or remote interface for my stateless session bean
however I see various solutions and am wondering if there is a certain
"standard" or general "preference".
The main difference is that remote interface are coarse grained and the call is by value. While local interface are fine grained and the call is by reference.
For remote interface, do I need to create the remote interface in a
Java Class Library or Java Application or Java Web Application? Then
the remaining code is within a Java EE Enterprise Application
project...
if you have a remote interface, it has to be packed in a separate .jar file. The .jar file has then to be included as a dependency in your main project (on the application server) and distributed to your remote client.
Also, what is the reason for creating a session bean in a Java EE
Enterprise Application Project instead of a Java Web Application
Project?
Since ejb 3.1 specification, an ejb can be packed directly in a .war file.
In the old J2EE days an ejb could only be packed in a .jar to be included in a .ear file.
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 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!
We have an issue, that if you start JBoss 6 with our Java EE 6 applications deployed, where one of them uses a JMS Queue, the related MDB won't consume any messages until you re-deploy the applications. The MDB is using a Singleton with a Startup annotation.
My research so far resulted in the assumption that this is caused by HornetQ being deployed after the application.
I also found some hints to get around this here and here, but I neither was able (and by the way didn't like) to use JBoss specific annotation in my applications due to missing Maven dependency nor am I using any deployment descriptor file so far.
So my question is, how do I ensure, preferrably with standard Java EE annotations or HornetQ/JBossAS configuration file that the queues are deployed before my application gets deployed?