We Keep Coding

What is the appropriate embedding mechanism for jetty, felix, bundles and webapps

After looking for a long time without finding a good answer, I come to the place where good answers are found.
I'm creating en ecosystem of independent applications (modeled as a WebApp in a WAR) and service modules (plugins) that those WebApps can consume (modeled as an OSGI bundle). I'm having trouble getting my head around how to architect those elements with Apache Felix and Jetty. The way I understand it I have three possible ways of doing it, but I have no idea of the implication of each.
Create a felix container that brings up the plugins, and also brings jetty who eventually bring up the WebApps.
Create a jetty server with embedded felix to provide the plugins, and use Jetty's deployer to manage the WebApps.
Create a jetty server with a less complicated framework than OSGI to manage the plugins, and use Jetty's deployer to manage the WebApps.
Option 1 seems to be a very orthogonal solution, everything is an osgi module (assuming the wars are a module), and managing the whole thing would be just a matter of creating the felix infrastructure and bringing everything up. From my early testing, managing all these osgi modules in development is not an easy or fast task (but most likely I'm doing something wrong).
Option 2 seems that it would work (is the one that I have managed to get further from the two) and is simpler to manage my head around, since the OSGI is limited to managing only the plugin infrastructure and not the applications or the server.
Option 3 I haven't even started to explore.
I'm expecting to have several independent applications (WebApps) and many many plugins (OSGI modules) and I would like to hear from you on the pros and cons of each option, in terms of maintainability and ease of development.

One of the problems here is that 1 and 2 are both valid use cases of osgi frameworks.
I would recommend having a detailed look at JBoss Fuse, as this is a very mature implementation of option 1 (ignoring the container based, openshift stuff and focus on the on prem version). The basics of it are:
a single JVM that hosts an OSGI container based on Apache Felix. (It's really Apache Camel, repackaged from Apache Servicemix, which uses Apache Karaf, which can either use felix or the Eclipse OSGi framework. Turtles all the way down).
Applications are packaged as osgi bundles that can include a servlet engine.
The servlet engine can then also utilise osgi to run a plugin / framework system.
You will probably not be surprised at the huge amount of house of cards tooling it requires to get this stuff up and running, and then maintaining it. You wont suffer from classpath dependency clashes, but the cost is an extremely complicated toolchain for creating and deploying bundles. This also makes unit and component testing very difficult. Some of this is just due to how complex fuse is, but trying to seperate the unnecessary complexity from the necessary is a hard problem.
A hello world on Fuse, where you are digging into each part of the platform and really getting to know what's happening, would probably take a week.
Leaving fuse aside, there are plenty of issues with either option 1 or 2
you are still limited by the JVM and its threads. You need to take some care to ensure everything works together as it is very easy for a single bundle or plugin to happily consume the entire CPU and block other applications from doing work.
plugins have a lifecycle that needs to be managed - start, stop, load, reload, unload. There are a number of management issues that will bite right away - How do you force stop a plugin? When do you give up and restart the JVM?
who is writing the plugins, where are they hosted or built, how do you trust them and so on.
OSGi is pretty successful client side, but IMHO the reason there's not many really well known server side OSGi implementations is because it's really difficult to manage with lots of threads and unpredictable request flow and people just don't get the results they want - run code from different sources in varying configurations, as decided by a user - from the pain of making it work.
So are there any other mature plugin frameworks that solve these issues in a simple reliable way? Not that I'm aware of! There's plenty around on github and google, but they always end up foundering on the same rocks of coming up with a reliable way of managing the plugins and making them play nice with the other things running in the JVM.
I would much prefer to keep the independent applications independent via their own docker container and then maybe look at felix if you really need to be able to load plugins at runtime.

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

java ee server similar to cassini

I primarily use Tomcat and Glassfish for Java EE development at work, but was wondering if anyone knew of any small application servers like Cassini for ASP.NET that would make building and testing faster? I would still eventually deploy to one of our production tomcat/glassfish servers, but would prefer something that is simpler and quicker.
I am probably going to take jetty and geronimo for a spin, any others I should check out?

You might want to check out JRebel which eliminates the need to do a redeploy on ~80% of the cases, making the development quicker.

jetty is good for testing, because it's very easy to start a jetty instance in your tests. if you're also concerned about faster development, then the choice of server is not the only factor.
there's also jonas and resin

This may not answer your question directly, but you may want to consider alternative Framework/Server combinations.
Here are a few Java RAD stacks that I have used in the past and work very well when trying to achieve a rapid development -> build -> test loop:
Spring Roo
Grails
Play Framework
Granted, these are not application servers in their own right, but each of them are frameworks/servers that can be used to achieve the results you are looking for. Roo and Play are both Java based, and Grails is Groovy based.
None of these solutions will work if you are looking for a plain container to deploy your application in to. These are more like all in one solutions.

(...) but was wondering if anyone knew of any small application servers like Cassini for ASP.NET that would make building and testing faster?
You should have a look at this Short screencast on GlassFish v3 session redeployment that shows the session state preservation across redeployments in GlassFish v3. Combined with the "deploy-on-save" feature (vs build and redeploy) offered by the GFv3 IDE plugins for NetBeans or Eclipse, Java EE development is very productive (even if GlassFish is not the fastest to start but well, you don't have to start it that often).
I was a big fan of Jetty but I must say that I just love these two features and consider them as direct answers to your concerns.

Break-even point for OSGi

It seems that OSGi is a hot term these days. Many benefits are invoked:
Reduced Complexity
Reuse
Easy deployment
Versioning
(etc)
I'm asking for a very specific use case - small to medium-sized web applications. What benefits would OSGi bring for those? It is actually worth it?

I would say as always "it depends".
Your environment
Consider an existing team with no OSGI experience(who proudly consider themselves as experienced developers who "get things done". There's a chance that they'll experience a major pain or a slow start.
MANY(more than you might think) developers are not familiar with build tools such as Ant or Maven, and when they are they only use limited features of those build tools.
Creating OSGI bundles is best accomplished with Eclipse, Ant tasks or Maven BND plugin VS a script or a manually written manifest for the jar archive.
Small applications
For small applications, OSGI introduces unnecessary complexity while you could use dynamic languages such as Jython, etc. or a plugin framework such as JPF or the SPI. You could also go directly with reflection and a simple custom classloader.
Big applications
Big applications might benefit from OSGI, especially when they are written from scratch. IMHO integrating OSGI in an existing application is more like introducing a patch for provide a modular architecture.
From my experience, after rewriting many applications, it's better to think about the modularity at the early days of a project.
Other concerns
Deployment :
It is the same in any applications. If you're used to deploy Java Web Start applications, deployment is not a concern. If you're used to OSGI, deployment shouldn't be a concern.
There are always problems once in a while in any application when it comes to deploying it in production, which is natural.
Versioning :
There are many ways to provide versioning in an application. But if you only use versioning as "information" vs as a tool(manage dependencies requirement), versioning is not a concern.
Reuse :
When using OSGI you tend to write your code for reuse, but any well written API is designed with code reuse in mind.
Eclipse is a number one example of a successful big application written with OSGI. There are other big/nice tools which don't use OSGI and are modular.
Conclusion
In many modular frameworks, it's difficult to handle dependencies, stop/start/uninstall/install features at runtime, without restarting the application. You play with a custom classloader, shutdown and startup hooks, etc.
OSGI gives you such flexibility at a minor cost IMHO.

I'll hazard a NO, even though I'm a big fan of OSGi. Unless you're working with other OSGi bundles or you have a specific problem that you can't easily solve without this sledgehammer.
The benefit is elegant classpath separation (IMHO). If you need different versions of the same JAR/class, say because you're upgrading certain portions of an app while it's running, or because you are combining a lot of 3rd party modules, then OSGi is great.
That's not an easy thing to achieve, and it's not made easy with OSGi. It's made clean, but at a cost of another layer in the environment stack. And a lot of work to learn and maintain.
Not to mention the documentation isn't particularly beginner-friendly.
I suggest learning about it -- building Eclipse plugins is one very good way -- but not building it in to your dev plan until you know it well.