I want to see all the sca bindings (imports and exports or atleast imports) associated with an EAR before deploying the EAR to WebSphere Application Server.Is it possible to that.I can observe the bindings after deployment in WebSphere Application Server either from console or using wsadmin scripts.But is there a way to see them before deployment.
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 will ultimately be deploying my Vaadin web app to Tomcat servlet container.
In Tomcat, JDBC drivers generally need to be stored outside of the web app, in a separate Tomcat folder. So I do not want to add any JDBC driver as a dependency within my Maven build settings.
In the meantime, while developing I am running the Vaadin 8 or 8.1 web app (created from the vaadin-archetype-application Maven archetype) from within IntelliJ 2017.1 using the Jetty servlet container that is somewhere mysteriously bundled (“embedded”?) within the project.
Where can I store my JDBC driver jar file(s) while developing with IntelliJ-Jetty combo?
This depends on wether you use Tomcat or Jetty as an "old fashioned" appserver, or if you use it as an embedded component in your application. The archetype you have used probably assumes the latter (adds jetty-plugin to pom), while it sounds like you want the first scenario. In that case, just install the driver in the tomcat or jetty instance you want to use, and create a run configuration in IntelliJ for that instance. If you need the driver compile-time, add it to the pom with scope "provided". If you want to just have it available to the jetty-plugin, add it as a dependency for that plugin (inside the plugin definition).
See this related question for more info about including dependencies only for embedded jetty.
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
Is it Possible to build a simple ear with just one "Hello World" html page to be build just once as ear file and deployed on weblogic, JBoss or any other server?
Means if Ear file is very simple which does not uses any advance services provided by specific container, is it possible this ear to be usable across different application servers?
Yes. If the ear is J2EE compliant it should be able to be deployed to any J2EE compliant platform. If proprietary functionality like Websphere Scheduler is added then that would be different.