Generating EJB stub classes on liberty - websphere-liberty

I am working on migrating application from WAS 8.5 to liberty.
There is a java standalone application which uses stub classes to communicate with the remote ejb.
The stubs were generated previously using the createStubs.bat script available on WAS 8.5
As the script is not available on liberty, how will the stubs be generated?
I read about the java rmic command but not sure if it will generate all required stubs
Let me know if there is any other way to create the stubs

Liberty has the ability to generate the stubs during runtime and not require you to generate them to put them into your application. It depends on the version of EJBs that you are using in your application. You can read about the details here: https://www.ibm.com/support/knowledgecenter/SSD28V_liberty/com.ibm.websphere.wlp.core.doc/ae/twlp_ejb_remote.html under the Stub classes section

Related

Is there any way we could figure out in code the environment where EAR is deployed?

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.

WAS is using Axis2 for Webservice client instead of JAXWS

we have to use a third party system which exposes SOAP Services. We developed and tested locally using JAXWS and Jetty. All is working fine. when the same is deployed with in WAS 7.0, it seems, it is using Axis2 library the same is throwing few errors.
Any help\idea on what configuration needs change to make our EAR to use JAXWS instead of Axis2?
Regards,
Axis2 is the JAX-WS implementation used by WAS 7, and it'll be picked up for any JAX-WS operations run on the server by default.
If your application is dependent on your own JAX-WS provider, as it sounds like you are, the procedure for using third-party web services engines is documented at https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_thirdparty.html
I happened to find the 8.5.5 document first, but the procedure is applicable to version 7 as well.

Stateless Session Bean with Local / Remote Interface

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.

Best alternative to Weblogic startup classes in Websphere?

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.

JAX-RS Jersey Client on Websphere 8.5

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

Resources