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.
Related
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 have created a sample EJB Project and a Dynamic project.
Now I have used the interface of EJBProject inside the client project so that it could use the proxy object and in turn interact with the bean to fetch the data.
However, I have created a blank EAP project and have added both the EJBProject and the DynamicWebproject. Now according to the concept I have bundled the EJB and Web inside EAp and have deployed on JBoss Server, so technically if I hit the jboss url then it should direct me to welcome page of client. However I am not getting as expected.
Am I doing any mistake in deploying it??
When you will deploy EAP then a target must be generated in that target you will have application.xml in that you will have context root now use this context root in your url foreg: localhost:yourport/yourprojectname/contextroot
this must take you to your page
I'm trying to deploy jax-rs client application that use jersey on was 8.5.
I was hoping I won't need to pack jersey jars inside my war, because was will provide them.
But I'm getting this error when trying to invoke my servlet:
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [HelloJAXRSClient]: example.HelloJAXRSClient was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime
Is there something I can do to use was libraries so I won't need to pack them inside my applicaiton?
WebSphere 8.5 includes a JAX-RS implementation, but it's based on Apache Wink, not Jersey. So if you want to use what is already provided, I think you'll need to create a Wink client instead of a Jersey one.
Or, you can disable the WAS JAX-RS implementation which I'd guess will allow you to use Jersey instead, either deployed in your application or as a shared library as zargarf suggests.
You can create a shared library in the was admin console which point to a directory on the server. Then put your jar files in that directory. Associate the deployed application with the shared library. See: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftcws_sharedlib.html
I'm trying to get Tomcat 7 (comes with OpenEJB) to work with Jersey 1.9. I had my Jersey RestFUL service working with Tomcat 6. But as soon as I deployed the war file to Tomcat 7(OpenEJB) I get the following error.
I created a new dynamic web project in Eclipse and added the following jars to WEB-INF/lib folder without adding any extra code but I still got the same error. It seems like Tomcat 7's OpenEJB is not liking Jersey jars.
asm-3.1.jar
jersey-core-1.9-ea04.jar
jersey-server-1.9-ea04.jar
Caused by: org.apache.openejb.OpenEJBException: Unable to instantiate Application class: com.sun.jersey.api.core.ResourceConfig: null at
org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1685)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1482)
at org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:293)
at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:263)
at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:693)
at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:588)
... 23 more
Caused by: java.lang.InstantiationException
at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1682)
Check out Apache TomEE Plus it is Tomcat with JAX-RS already integrated. You can skip the part where you hunt down libraries and try to get them integrated and move on to the writing code part.
Here's a video on how to set it up in Eclipse using the Tomcat web adpater and a simple Dynamic Web Project.
On the note of using EJBs as RESTful services, there are plenty of people that do that especially when JPA is involved. Aside from getting transactions for free, you also don't need a JAX-RS Application subclass or to map any REST servlets. A small perk, but nice.
As well you can expose the same class as a #Remote object and invoke it over RMI, as an JAX-WS #WebService and invoke it over HTTP/SOAP, or just annotate it #LocalBean and you can use the same object internally without the HTTP overhead. Nice to have the flexibility.
This stack trace makes me wonder if ResourceConfig has a no-argument default constructor. You'd see this if the OpenEJB deployment expects on and doesn't find it.
Since REST is an HTTP API for web services, why would you be using it with OpenEJB? I would guess that the two would be mutually exclusive. I'd write services using session EJBs or REST services, but not both.