We Keep Coding

Replacing Weblogic with Tomcat?

I am investigating replacing Weblogic 10.x with Apache Tomcat for dev machines and I'd appreciate any insight or recommendations anyone may have.
The reason for replacement is probably known to anybody ever trying to do dev work on a production webapp server monstrosity - to improve dev efficiency. The application is large (several million lines of code), legacy codebase, containing a smorgasbord of technologies (Struts, EJB 2, EJB 3, to name a few) and changes to codebase frequently entail doing a redeploy/restart of web server (even with JRebel) - which takes a long time (to the tune of 5-10 minutes). That obviously wastes time, introduces frustrations and leads to mistakes.
What I'd like to know is - is it even tenable contemplating this replacement? The codebase would later on in dev pipeline be validated against a geniune WL instance but for the dev machines, I'd like it to be as lean as possible. This obviously won't be a trivial transition but I'd hate spiking a week on something that's completely impossible or, at least, absolutely inadvisable.
So obviously I'd need something implementing JavaEE spec (doesn't need to be officially validated - as long as it works :) ), so I've looked at possibilites and, to me, Apache TomEE looks promising. Geronimo is long dead, seems like, Glassfish is in limbo (?) and Jonas an unknown. Working under Java 8 would be a BIG plus (which TomEE 1.7 seems to support).
Lastly, we don't work with XA transactions (two-phased commits), so supporting that at least won't be necessary.
Is this a reasonable approach? Is there an alternative I am missing? Any experience doing the transition? Any thoughts are welcome.

long-time TomEE user here. We have been using TomEE in production for the past 3 years. We started off with bigger SOA on version 1.7 (Java EE 6) and a year ago upgraded to TomEE 7 (Java EE 7) for microservices.
Our stack is Kotlin, JAX-RS, CDI, JSON-B, BVal, mybatis for db (pgsql and db2), elasticsearch, hazelcast, kafka, akka-stream-kafka and akka. TomEE makes for a nice, small application server. On startup and initial garbage collection I think it runs around 30m heap usage (or less). We are starting to run Docker on Kubernetes.
WildFly has some cool stuff happening and seems like they are more active, and obviously they have a huge corporate company behind it.
We concur and run the setup that Adam Bien espouses, which is not going uberjar due to the size of docker images, transferring 128M containers vs smaller 5-20M, running on a full application server.
I've tried out WildFly Swarm, it's cool, and there is also a hollow-jar deployment where instead of a fatjar, you can deploy a war (meecrowave also supports this and I think Payara micro too).
I would put TomEE, WildFly (and Swarm), and Payara on my list of app servers to use to stick with Java EE route. If you consider a different direction, prepare to wade through a ton of information, articles, blogs, etc. Akka-HTTP? Play? Scala? Spring Boot, which just runs on netty/tomcat/etc? vert.x?
So many players out there to choose from. Find one that you like and works. For us right now that is TomEE.

Is it worth upgrading to JBoss 7.1 from JBoss 5.1

Currently our production environment runs JBoss 5.1 and we have been debating whether or not its worth migrating to JBoss 7.1. If it was a simple server upgrade, then it wouldn't be a problem. But, unfortunately, we would have to change configurations and that would take some effort. Also, our server runs in a cluster and I read that JBoss 7.1 has more cluster support.
So is it worth it or not?
Thanks

We're currently in the same situation.
There seem to a a lot of things on the positive side:
We'll have to migrate off 5.1 at one point. We need full profile and there are not that many OSS alternatives (GlassFish and maybe Geronimo). That point alone will probably sell the migration since PCI-DSS forbids us to use EoL'd software.
The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files but one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard appreciate this if you've never configured a JBoss.
The EJB remoting no longer uses a thread per socket.
Removing a subsystem you don't need is so much easier.
The class loding model looks sane and you get a lot of control through jboss-deployment-structure.xml
The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
While we're not too excited about Java EE 6 replacing some of our SLSBs with #Singleton beans and some of our SARs with timer EJBs certainly looks interesting.
Faster start up and less memory usage (at least for an empty server or small deployments). We haven't yet tested a large deployment.
The deployments folder is empty by default
Things that we still need to look into:
We're a bit worried about Infinispan performance. We currently use the TreeCache API of JBoss Cache. While there is an adapter for Infinispan that provides the same API some theoretical tests show worse write performance. This only applies to the tree API of Infinispan.
ExternalContext is no longer supported, we currently use it to populate a JNDI tree from a .bindings file
JMX console is gone, if you have anything that builds on this it needs to be adapted, Edit there is actually a port of JMX-Console available AS7-2227
We don't run in a cluster so I can't comment on that.
What will probably be the biggest effort for us is migrating all the shell scripts (installation, integration tests, …) that interact in one way or another with JBoss.
Update
We have migrated and it was definitely worth it. Some updates to the points above:
Even large deployments are fast with minimal amounts of tuning.
The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
7.1 has so many bugs it was unusable for us, so we are on 7.2 / EAP 6.1 and plan to go to 7.3 / EAP 6.2. Still has its fair share of bugs but we can work around them. We're especially looking forward to role-based access control for the management interface which will allows us to run our scripts with minimal privileges.
There will not be a supported version of GlassFish 4 which puts a big question mark on it for production use.
EJB remoting security is a lot less flexible. We had to put in some workarounds since previously we were mixing authenticated and unauthenticated EJB calls — this is no longer possible.
The JEE 6 BOM POM from JBoss is a mixed bag. In theory it is nice because it manages the versions of all you JEE dependencies. In practice the coordinates are horrible with the version in the artifactId which is going to be annoying when we migrate to JEE 7. Also it isn't very helpful when you want to include an implementation of a JEE API for tests.
Infinispan tree API performance was not an issue.
We replaced the JMX-Console scripts with DMR scripts.
Update 2
There is a deadlock when using EJB remoting over SSL. This deadlock is present even in EAP 6.2. We're now at the point when we have quite a patch set of features backported from WildFly to AS 7.

Is everything working on JBoss 5.1.0 for you? Is your performance something you can live with?
I'm currently in the middle of upgrading from JBoss 5.1.0GA to JBoss 7.1.1 and it has not been easy at all. You're basically upgrading to a new application server. You will need to budget a lot of dollars for this effort I'm guessing.
Having said that JBoss 7.1.1 is VERY fast compared to 5.1.0 (start up times at least). I think in the next 6 months (or so) most of the "hard" migration and transition issues will be fleshed out in the jboss forums or through bug fixes. At that point you and your team can reevaluate if you want to do the migration.
Good luck!

If you are using SSL, one advantage to upgrading is that JBoss 7.1.1 runs on jdk 1.7, which has support for TLS 1.1 & 1.2, while jdk 1.6 only supports up to TLS 1.0. JBoss 5 will not run on java 1.7 so you are susceptible to a BEAST attack.

Regardless, I'd wait a bit.
AS 5 is a EE5 server, AS 7.1 is a EE6 server (and EE6 spec came out in 2009). So that's alot of work for an excellent new runtime environment, but it won't give you any hot architectural possibilities.
The WildFly 8.0.0.CR1 is already due and that's EE7 server bringing you a bunch of new interesting developing possibilitites, like WebSockets and JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). New admin features like Single Instance Patching. And it's not sure that AS7-to-WildFly8 will be a super-easy migration since som major new stuff is introduced, like Undertow instead of JBossWeb/Tomcat.
If you gotta go, you gotta go - and if U wind down the dead 7.x path, don't forget to get your hands on the much improved 7.2.0.Final tag (several hundred issues better that 7.1.1). But if you think you can start developing/migrating now using Beta/CR releases and wait some months for a nice production-stable WildFly 8.x.x release, you might be able to sit tight longer before next major update.
br,
Jens

Benefits (and tips) of an upgrade from JBoss 4.2.x to JBoss 5.x, 6.x, 7.x and WildFly 8.x?

Please assume that I do not need to worry about development time and costs: I am interested in general technical benefits (improved performance? improved APIs?) and new features.
I am currently working on products using 4.2.x, and we consider a major shift for versions that are a long time ahead and need to converge.
I had a brief look at the release notes of each version and some articles about each release for 5.x, 6.x, 7.x and 8.x. But I would be glad to have first-hand feedback from people who have made the switch.
I noticed there are some important changes surrounding messaging (switching from JBoss MQ to JBoss Messenging), and that for JBoss 7.x it seems to change a fair bit its configuration layer. Then there's a lot more going on when switching to JBoss/WildFly 8.x.
Please recommend good articles pointing at pitfalls if you can. I found a few for migrations to JBoss 5.x, but not that many for 6.x or even 7.x, and someone else is evaluating 8.x for us now. Feel free to recommend alternatives as well if you think they are relevant, though I'd prefer to focus only on JBoss.
For information, we use a mix of JPF- and OSGi-enabled (using Eclipse Equinox) plugin-based systems, with clients developed in Swing (some deployed via WebStart).
Update: Though this question brought some great answers already, I think it deserves an update for WildFly (and actually, our internal projects delayed making the switch from 4.2.x to 7.x as originally planned to wait for WildFly). New thoughts and answers are welcome.

I've upgraded from JBoss 4 to 5 and from experience the following are the most important to note:
JBoss 5 (and 6 and 7) are not as forgiving as JBoss 4 with XML files. You must make sure that all your deployment descriptor XML files are valid. You may be using DTDs in some files - I recommend upgrading these to use XML schema instead.
Some libraries may cause incompatibilities. This can be particularly true if you access web services and/or do XML parsing
If you precompile your JSPs in JBoss 4, you probably won't be able to in JBoss 6/7.
JBoss 4 and 5 use different message queue implementations. If you have any message queues or topics defined you will need to redefine them.
JBoss TreeCache is no longer used. If you use this for caching purposes, you will need to change to use the new JBoss cache instead.
JBoss 5 security is different. If your remote clients require secured access to JBoss, you will need to configure them differently.
Some useful resources are:
https://dzone.com/articles/migrating-jboss-4-jboss-5
http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga
Officially JBoss 6 is only certified for the Java EE Web Profile, so if you use "legacy" features such as EJB 2.x, they will potentially not be supported in the future. Depending on the lifecycle of your application, this may or may not be a problem. JBoss 6 currently supports EJB2.1 fully, but it is not certified against this.
I have also found that JBoss 5 handles memory a lot better that JBoss 4. With JBoss 4 I see a lot more PermGen errors than I do with JBoss 5.

I can only speak from production experience with JBoss 5.1.0 and some investigation of version 6.
JBoss 5 is Java EE 5 and JBoss 6 and 7 are Java EE 6. The disparity in API features is best documented in those specs. JBoss 6 is likely to have a very short shelf-life; it is only certified for the Java EE 6 web profile and bugfixes are being targeted at version 7 (in its 3rd beta at time of writing).
I think you'd get better answers on the JBoss community forum.

We upgraded from JBoss AS 5 to JBoss AS 7 and are eying towards WildFly AS 8.1. Right now we can't migrate to 8 because there is no MQ Series JMS 2 RAR.
Some of the differences:
The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files. Instead everything is one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard to appreciate this if you've never configured a JBoss 5.x.
The class loading model looks sane and you get a lot of control through jboss-deployment-structure.xml
The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
The EJB client maven dependency mess is gone, instead you now get a BOM POM.
You get a BOM POM for the server APIs.
Faster start up and less memory usage. We deploy 80 EJBs and the MQ Series RAR in 6 seconds without much tuning. Our live dataset is somewhere above 200 MB.
The deployments folder is empty by default
The (lack of) quality of XNIO is scary. In 7.x it's only used for EJB remoting and we hit several show stopper bugs (deadlocks, double free, socket handle leaks, …). In 8.x it is used for servlets as well instead of Tomcat. There are still a lot of very basic servlet bugs being fixed in undertow.
Changes that we had to do our application:
change JNDI names to EE 6 standardized names
migrate from JBoss Cache to Infinispan (part of our code has been migrated to the flat API, some parts still use the tree API)
security is slightly less flexible (you can no longer fix authenticated and unauthenticated calls)
some horrible code that relied on details of remote JNDI
the configuration of the EJB client is different
all of you scripts for installing, deploying, starting, stopping, …
ExternalContext is gone, we had to replace it with a different approach
we replaced MBeans in SARs with #StartUp EJBs
some ugly hacks for Cocoon
The AS 7.x series has a lot of bugs with fixes only available in the EAP series. If you want go to with 7.x instead of 8.x we strongly recommend you buy EAP 6.

Here is an interesting thread on JBoss AS 7 compromises and future, also mentioning issues with AS 5 and AS 6:
http://community.jboss.org/message/613171

Just wanted to bring this to anyone's attention who might be facing PermGen bloat issue after upgrading to the latest. The JBoss-6 Microcontainer tries to scan for Jboss specific annotations by loading the classes from all the JARs in the class-path on startup. This causes the PermGen bloating as it starts to load all the unwanted classes. To reduce the amount of scanning, the Microcontainer provides another descriptor hook, by means of jboss-scanning.xml.
Add this 'jboss-scanning.xml' to the WEB-INF inside WARs and ass 'jboss-scanning.xml' to the META-INF inside EARs.
<scanning xmlns="urn:jboss:scanning:1.0">
<!-- Purpose: Disable scanning for annotations in contained deployment. -->
</scanning>

which is best server for developing java web applications?

I'm confused. There are lot of servers(GlassFish, Tomcat, Apache,etc.,). But which one is used to implement easy for developing web application? Please suggest me.
Thanks in advance.

Glassfish v3 is a slow starter (~30 secs), but its hotdeployments are fast. It happens in less than a second, regardless of what you've edited: JSP files or Java classes. At least, that was my experience in combination with Eclipse and the Glassfish Eclipse plugin. Things which may matter a lot. And as a bonus, you've the opportunity to play with the awesome Java EE 6 API.
Tomcat 6.0 is quick starter, in ~3 secs it's up and running. Hotdeploys of JSP files is acceptable, after ~3 seconds you can F5 to see the new one in browser. But hotdeploys of Java classes is sometimes troublesome. Sometimes it isn't picked up at all, or sometimes it takes too long that it's actually faster to manually restart Tomcat (which however takes "only" 3 seconds).
Take your pick. I'm just using both.

Tomcat: it's free, and it's easy to work with. It's also very widely used and has lots of documentation and "herd knowledge" e.g. here at SO.
If you don't need EJB then it's a good safe choice.
Edit: Tomcat was until recently the "reference implementation" of the Servlet/JSP, although as pointed out by commenters, Glassfish currently has that accolade.

I would go with either Apache's Tomcat or GlassFish.
Tomcat has the benefit of being around longer and having a broader group of users, but GlassFish comes from Sun itself. I've also heard that GlassFish's performance is above Tomcat.

The more commonly used "lightweight" servlet containers are Tomcat, Resin, and Jetty. They are lightweight because they implement only a few of the specifications (at the heart of which is servlet and JSP)/ The larger enterprise level applications JBoss, Glassfish, etc implement much more specifications on the server side.

I'd just suggest Tomcat. It's quick and easy to install, well documented, a support community behind it and very stable.

By experience i would say:
1.Apache Tomcat is quick in respoding to clients,easy to deploy apps,medium to install.
2.Glassfish is i think less quicj=k in responding,easy to deplu apps,easy to install,configure and use.
So i would suggest glassfish

I've usually used Tomcat with no problems. It's always been easy to setup and quick to deploy for me. Sometimes when using NetBeans I will use Glassfish too.

Running Apache Geronimo in production

If you're running Apache Geronimo in production why did you choose it over other application servers and what are your experiences with running Geronimo in production?
Can you also please share what servlet engine you decided to use (Tomcat/Jetty) and why you made this decision?
UPDATE: So far this question got two up-votes and one star but no answer. I'm starting to wonder, is anyone using Apache Geronimo at all? My logic would be, if you use Geronimo for development you'd also use it for deployment. Right? So, does that mean that no one is using Geronimo at all?

We definitely use Geronimo in production!
We have used the Tomcat version since 1.0, about four years ago as I recall. We are currently running mostly 2.1.1.4.
One of our apps gets about 1 million page views per day. The others are nowhere near that, but they are important apps that need to work well.
Our choice was based primarily on:
Price: At the time our company started using Java, we weren't sure what we needed out of an app server. So we decided to start at free and work our way up, if needed.
Basic features: I had experience with WebSphere (base/ND) and plain old Tomcat. Geronimo had the J2EE features we wanted, all within a lightweight package.
Open Source: Our primary client that we use Java for required Open Source.
Familiarity: Being an Apache-based server, we were already comfortable with Tomcat, OpenJPA, Axis web services, and others. Furthermore, we were comfortable with the Apache community as far as bug tracking and other minor things.
Support: We expected to be mostly on our own, but knowing that the Apache community was active was important. As was the availability of commercial support from IBM, as we are an IBM Business Partner.
Our experience has been great overall. The servers are very reliable. I search our logs once in awhile and sometimes see weird errors with a database connection, an EJB call, but those are pretty rare (and quite possibly our code's fault).
Performance is impressive. I joke that we could run Geronimo from my laptop and the clients wouldn't see a difference. Give it any decent server and it will purr along for months.
I'm not sure how many people actual run Geronimo. I'm rather confused about that. I've seen slides (years ago) that listed some big names like eBay using it. The mailing list is active but sometimes seems like only the Geronimo team communicating with each other.
The only serious bug I've run into is this one. It is a big deal to us, but of course Geronimo is free and I don't expect them to fix bugs that are important just to me.
I've been meaning to check out Apache TomEE server, wondering if it is more actively or openly used. Just to see how the community and usage compares to Geronimo.

WebSphere community edition is Geronimo. So IBM chose it as a platform of choice.
When choosing an application server, you're really choosing the APIs you want to use in your application and maybe the administration interface (but you only use that once in a while).

Answer to your update: It just means that SO users are not using Geronimo or are all busy voting and making witty comments.
There seems to be quite a bit of acivity on Geronimo's mailing list, and I would say that you'll get better results there.