TL;DR
Is it necessary to have an HTTP router module when deploying an EJB module containing web service implementations to WebSphere 7?
If so, is there a way to create/manage it without relying on IBM-specific files?
I have an application that is being restructured so that it can be built Maven. Currently, I am using was6-maven-plugin's endptEnabler goal to build an HTTP router module for an EJB module that contains some web services. This works well, but I just found out that the build machine we'll get to use won't actually have WebSphere installed on it. In the past this wouldn't have been a problem, since the router module had been developed manually by someone clicking a "Generate Router Module" button in RAD and then actually checking in the generated code into source control. With the Maven-centric build process, we thought it would be better to generate the module during the build process.
So now I am stuck: generating the router module via Maven seems a much cleaner approach but won't work on the build machine. I have a few options:
Extract the generated WAR and add it to our enterprise repository and then create a dependency from my EJB to the WAR. I really don't like this, but it would probably work.
Go back to having a realized HttpRouterModule project in the workspace. The problem with this is that the IBM-specific binding files have valid module IDs for my server, but I don't know if they'd cause problems on someone else's which is why I'd rather generate these files from Maven.
Keep generating the router module with Maven, but find a way to generate it in a way such that there is no WebSphere dependency.
I'd prefer to go with the third option, but I'm not sure how I can generate the module and the binding files in generic way such that it will still be recognized by WebSphere.
I'm open to hearing about other options too...
As far as I know you need http router module. From my experience I was also unable to create the module manually. Is there no way you could install was7 dev server on your build machine? I believe it is free download from IBM.
All my research so far indicates that this is necessary in WebSphere 7, and in earlier versions. It looks like WebSphere 8 does not require HTTP router modules. We're going with the second option, as the build server won't be able to generate the router modules on its own.
Not ideal, but once we move to WAS8 this won't be necessary.
Related
I am using aws sdk package to access aws api from web application deployed in a websphere application. During build the application doesn't throws any compile time issue. After deployment it throws java.lang.NoSuchFieldError: org/apache/http/conn/ssl/AllowAllHostnameVerifier.INSTANCE
I read some post, it says about jar conflict. Its taking the default httpclient jars from IBM. I want to point my code to take my version of httpclient which I have given in lib folder. Can someone help me to point my code to pick my version of jars added manually.
In order to make your app use its own version of something that's included in the server, you'll need to use parent-last class loader delegation. Assuming the Apache HTTP client is in your web module's WEB-INF/lib directory, you'll want to make that change to the web module's class loader setting (this doc is specifically from 8.5.5 but should work on any version from the last decade or so): https://www.ibm.com/docs/en/was-nd/8.5.5?topic=loading-configuring-web-module-class-loaders
Note that parent-last delegation comes with its own set of risks, as there are some things that don't play well with the server if you try and use a version in your app (the Servlet API is one of the more notable ones). If you try this but run into things like ClassCastExceptions or LinkageErrors, you may instead want to put the HTTP client into an isolated shared library (selecting the "use an isolated class loader for this shared library" option) and associate the shared library with your web module or application: https://www.ibm.com/docs/en/was-nd/8.5.5?topic=servers-managing-shared-libraries
All that said, the simplest solution might just be to update your server. An APAR several years ago (PI50993, included in fixpack 8.5.5.9) removed the application visibility to the server's version of the Apache HTTP client. Moving to a recent fixpack would probably resolve the issue as well.
I am building microservices(approx 15 to microservices) project for huge organization, I wants to know is it recommended to go for external tomcat with war file or just use the embedded tomcat of spring boot with jar file. Also I am facing issue after building my project on jenkins how to copy the file from jekins server to my server and run the file there and create and automatic build and deployment pipeline i.e. everytime I push the code it should be automatically deployed.
You need to identify what compels you to go for external tomcat deployment. As SpringBoot provides out of box facility to deploy within the container, it is not required to go for external tomcat deployment.
Besides, if you are going for many microservices, it will be good to have with built in springboot with embeded tomcat. Springboot also provides the facility to use undertow or jetty. I would recommend to use SpringBoot with either embeded tomcat or undertow with docker container for more flexibility.
It will be good if you provide the issues you are facing.
You can check the below link for reference.
https://dzone.com/articles/spring-boot-with-external-tomcat
I didn't encourage until today companies using Spring Boot and deploying in an external Tomcat.
If there is no requirements from your Infrastructure department, I would go with the embedded tomcat.
JARs vs WARs
I think both have their use cases, like a car vs a truck.
Getting started with jar files is definitely easier, it's provided out of the box. However, using war files in a tomcat has a few perks too:
You can use the "manager" UI to update/redeploy a webapp easely
You can monitor server status, inspect sessions, basically have a look under the hood
You can deploy/update multiple wars independently, which might be handy for larger project
...but there is definitely some learning curve to set things up, and it feels a bit ...old. So it's up to you if you want an easy "jar car" or a whole "servlet container truck". ...or you can also have multiple cars. ;) Each has ups and downs.
Pipelines
Like for any other topic, there are very different ways to achieve this. If you use an extern tomcat, you may configure a "script" user and deploy it like this (or similar):
curl -u username:pwd -d path=/something -d war=file:target/someWar.war https://someurl.com/manager/deploy
...or you can go the other way round and create Docker images, or cloud-init VMs or whatever. Or just a shell script to stop it remotely, upload it and start it.
Depending on your situation, the know how of your team mates, etc, one or the other may be easier.
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
We want to evaluate OpenEJB for our application. We have already performed some tests and now we need to start a pilot project.
While I've seen how to use OpenEJB for testing purposes (mainly for JUnit tests), I have not seen how to set up an EJB 3.X project inside Netbeans for deployment in OpenEJB.
The way we did for testing purposes was to create a new Java EE project, select JBOSS as the Application Server and then manually copy the JARs to OpenEJB. However, we want to be able to debug the code in Netbeans. If I try to do that, NB launches JBOSS or other application servers. I couldn't figure out how to install OpenEJB as a server in Netbeans, I didn't find anything enlightening in Java forums and there were no answers from stackoverflow.
We know we can use an embedded version of OpenEJB, but that is not what we are looking for. So:
What is the suggested project structure for an EJB application for Netbeans + OpenEJB?
Is it possible to use Netbeans' Java EE knowledge (wizards, build system, client applications) with OpenEJB?
If we need to use OpenEJB just as libraries in the classpath, what is the correct approach to generate EJBs and client applications that can work with other EJB containers later (stay Java EE compatible)?
Unfortunately, the folks behind the OpenEJB project have not contributed a server integration plugin for OpenEJB to the NetBeans project... It looks like they haven't published one on the NetBean Plugin Portal, either.
That means that you will need to be creative with your development and debugging.
I guess you could...
register GlassFish Server 3
create an ejb project that targets that server.
code, code, code.
build the project archive (dot-jar file)
start the openejb server in debug mode
copy the jar file created in step 4 to the appropriate location.
Use the 'Attach debugger...' item of the Debug menu to attach to the openejb server that you started in step 5.
If starting openejb requires that you start multiple processes (one for Tomcat and one for the ejb container), you can attach NB to multiple processes at the same time.
I am searching any way for embedding Weblogic server in Java , I know its possible because we have maven plugins for Weblogic which embeds Weblogic in maven, But googling for it did'nt gave me useful output, Does anybody know how can we embed wemlogic in java program ?
WebLogic doesn't provide an embedded API so, even if it's a pure Java Server and if you can thus call weblogic.Server from Java code, you will have to handle everything yourself (starting the container, waiting until it's started, deploying things, waiting until they are deployed, etc). In other words, this will require some work.
Maybe have a look at the sources of Cargo, although Cargo isn't really starting an embedded Weblogic (i.e. running weblogic.Server in the same JVM). This will give you an idea of what has to be done. Or, depending on your needs, use Cargo Java API.
But if you need a full Java EE server and if this is an option, I would use GlassFish v3 in embedded mode instead of WebLogic, it will be much simpler. Check the following links and see yourself:
Embedding Glassfish V3 in Unit Test - Two Jars, Three Lines Of Code And Five Seconds Start With Deployment
Embedding EJB 3.1 Container Into Your Unit Tests - Boot Time: 5 Seconds
Using the EJBContainer API with or without Maven (but with GlassFish v3)
TOTD #128: EJBContainer.createEJBContainer: Embedded EJB using GlassFish v3
Do you need WLS specifically, of any servlet container would do? If the latter is OK, then use Jetty.
WLS is not designed to be embeddable. But you can do it. After all, WLS is just a class named weblogic.Server. Setup classpath correctly, setup PATH and other environment variables (see setDomainEnv.sh and startWeblogic.sh), start that class from Java, and you have an "embedded" WLS.
There is probably a way, but I don't know it. My experience from writing maven plugins tells me that the most likely way that the plugin works is that it starts up a new command line process just like you would normally start up the server. So in a sense, not really embedded it.
The best way to see is to track down the source of the plugin and see how they did it.
WebLogic doesn't support embedded mode like Glassfish but you can have control over your Weblogic using "WebLogic Maven Plugin", this provide several maven goals for managing and working with Weblogic instance.
See this link for further information.