I been here for years. Suffering through inane arguments claiming you don’t need transactions or security or a decent runtime which integrates messaging, database connectivity, and clustering. Let’s start by each making some concessions. I’ll go first.
Java EE Application Servers were tougher on the development lifecycle than POJO frameworks. There, I said it.
Now your turn. I’ll even help you.
You’ve been lazy.
Plain and simple. Lazy. You don’t want to suffer through an involved test setup. You don’t want to write code that fires up some container, you don’t want to switch focus away from your development, you don’t want to deal with Frankenstein’d build setups. Forget that you’re ignoring all the benefits of a proper enterprise environment. So you either punted on Java EE altogether, or just skimped on testing that your stuff works. You’re L-A-Z-Y lazy.
And you’re lazy because you’re smart. You know that crap is getting in the way of your real job – to write business logic. And test logic. Not plumbing and scaffolding. That’s my job.
Luckily for us both, I’m not lazy. And neither is my team. We’ve worked very hard to give you what you want. That’s my job, too.
Over the past two years we’ve taken a hard look at the shortcomings of Java’s Enterprise Platform. And generally-speaking, the pain points have fallen into one of three categories:
* Startup/Deployment/Runtime Performance
* Developer Usability
* Administration and Management
Well holy shit, turns out those aren’t shortcomings of the Platform at all. Nowhere in the specifications does it dictate that an application server should be slow or unwieldy. So we set out to make damn sure that you get the best user experience possible out of anything branded with the JBoss logo.
So we started from scratch. Quite literally, a blank repository for JBoss AS. And then structured the scaffolding bits to work around 7 key problem areas.
Startup should be fast. Deployment should be fast. After all, we’re doing these tasks pretty regularly as part of the development lifecycle. So we kept a fine focus here, and delivered something which approximates the following results:
With flushed filesystem disk cache in blue; using FS cache in red
Not bad.
Quite simply put, two objects cannot occupy the same space at the same time. Take the following case: The Application Server ships with Hibernate version X in order to provide a JPA runtime. Say your deployment wants to use version Y. In a traditional hierarchical classloading model, classloading delegation would take over and the deployment would actually see the server’s version of these classes, which probably isn’t the intended move. We’ve offered configurable classloading in the past, sure, but this time we’ve moved to a truly modular system which isolates visibility by default. It’s called JBoss Modules, and it’s slimmer than systems like OSGi by limiting scope to fast (O(1)), concurrent classloading and leaving concerns like service installation elsewhere (like our OSGi integration project).
RAM consumption. It just needs to be curbed. Especially when you consider this cloud movement we’re having – consuming fewer resources very simply means fewer VMs, and this directly affects your bottom line. So in line with the minimalistic approach we’ve taken with ClassLoading, we’ve introduced the Modular Service Container to act as the kernel wiring together the services which comprise JBoss AS. It’s not a general-purpose programming model; it’s an intentionally feature-restricted state machine with, again, a huge emphasis on concurrency.
This is likely the biggest gap in Java EE development. The development lifecycle has us doing:
- Code code code
- Run a build
- Start a server
- Deploy the stuff from our build
- Run our tests
- Repeat
It’s disgusting. And we’ve got a way to take us to this:
- Code code code
- Run our tests
So what we built was the testing platform Arquillian.
We abstract out all container interaction from the test logic. Leaving us to write only:
@RunWith(Arquillian.class)
public class GreeterManagedBeanTestCase {
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class)
.addClass(Greeter.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}
@Inject
Greeter greeter;
@Test
public void should_greet_earthlings() throws Exception {
String name = "Earthlings";
Assert.assertEquals("Hello, " + name, greeter.greet(name));
}
}
What’s best is that Arquillian relies on no build or IDE plugins; if you can run JUnit or TestNG, you can run Arquillian. From the command-line, from the IDE.
This will be the topic of another post I’ll write in this space, to be released shortly.
Prior versions of the Application Server have had configuration-per-subsystem, which has amounted to a series of XML files scattered about the installation. We’ve unified these into a singular entry point, with natural-language syntax like:
<socket-binding-group name="standard-sockets" default-interface="public">
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8443"/>
<socket-binding name="jmx-connector-registry" interface="management" port="1090"/>
<socket-binding name="jmx-connector-server" interface="management" port="1091"/>
<socket-binding name="jndi" port="1099"/>
<socket-binding name="osgi-http" interface="management" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
</socket-binding-group>
So there’s no more relying upon implementation internals for configuration. And everything is backed by XSD, so you’ll get helpful IDE completion.
A new concept in JBoss AS7 is the notion of a Domain, a series of instances which may be managed together through one process called the Domain Controller. In effect this provides one-stop shopping to configure independent servers and manage their lifecycle, limiting the maintenance burden especially for administrators of larger server farms. And helping you to keep. Costs. Down.
And as always, we aim to provide you with a host of killer services, out of the box. Java EE and beyond.
- Hibernate: JPA Provider
- RESTEasy: JAX-RS
- Infinispan: Data Grids
- Snowdrop: Spring Integration
- JBoss OSGi
- TorqueBox: Ruby on the JBossAS Runtime
- Weld: JSR-299 / Contexts and Dependency Injection
JBoss AS made its name in being the developers’ choice. Because it’s free, and it doesn’t suck.
So don’t call it a comeback.
S,
ALR
Are there any tutorials or books available on upgrading applications from Jboss6 to 7?
AS 7 looks really great. I’m sold on everything but Arquillian.
You’re obviously up against spring-test. spring-test runs the tests in a (Spring) container as well without needing any IDE tooling as well. In addition per default it runs each test in a transaction and rolls it back after the test (zero lines of Java or XML). This makes sense as a default because per default you don’t want to have tests that commit (or have any other side effect). Arquillian does not support this. You have to inject a UserTransaction or EJBContext and manually roll back after the test. In addition you don’t need to muck around with deployments in spring-test, I mean why would you?
Philippe:
So great feature request for a declarative way to deal with transactions scoped to the test method. I’m thinking something like @Transactional(rollback=boolean) should do the trick. Course, I wouldn’t make this a default at all; I like stuff to be explicit and easily-defined. There are lots of other hooks to reset test state to default values ie. DBUnit and I don’t think we should step on any toes or presume to muck w/ Txs unless otherwise instructed.
And don’t you think you’re rushing to judgement on Arquillian over just this one point? Arquillian is a test platform; it adapts the test lifecycle into *any* backing “container”, including other test frameworks like Selenium. I think you’d be doing yourself a disservice to disregard the power and portability of Arquillian over this one point. And yes, we feel we do many things better than Spring Test (and from the feedback we’ve gotten recently, many users agree).
Maybe you’d like to join us w/ some contribution? Your experience in the area could help shed some light on weaker pieces and let us buff up in those areas.
S,
ALR
I’m trying to understand, that’s why I ask.
I’m curious, what do you think you do better than spring-test? I’m not trolling I really want to know. Sometimes you don’t know what you’re missing until somebody shows you.
I don’t understand the need for ShrinkWrap. The way I understand it what you posted here is just a best case secenario. I imagine once you have to package all the transitive dependencies of a class and versioned artifacts (eg. Maven) it gets quite hard to mantain. For example when you update to a new library you have to update all your ShrinkWrap definitions. Once a class depends on an other class you have to update all your ShrinkWrap definitions.
Regarding transactions I found [1]. I just can’t imagine why per default you would want tests that modify the database.
[1] http://community.jboss.org/thread/154778
Philippe:
Arquillian at its core is an adaptor between a test framework (JUnit, TestNG) and any container. Here we define “container” as: “An application which hosts and provides services to other applications.” In that sense, even Spring may be (and is) a backing “container”. So Arquillian is extensible testing platform with many different runtime targets; Spring Test is clearly bound to the Spring Framework.
I can absolutely see why users coming from a Spring background don’t grok the need for ShrinkWrap or @Deployment. In a flattened classpath without deployments, of course this is superfluous. But many other containers, Java EE included, use the notion of a deployment and ShrinkWrap is the mechanism we use to allow users to specify its contents. Think of it as a Java Object analogue to a standard JAR; only we don’t make you run a full build, serialize a physical file, or any of that. With ShrinkWrap you can take advantage of IDE incremental compilation and run straight from the IDE’s test VM launcher.
That said, yes, using the plain ShrinkWrap Archive API to make deployments could be redundant if you’re already using Maven to package up your deployments. For this case we provide the ShrinkWrap Maven Resolver API, allowing users to resolve a set of Maven Coordinates to ShrinkWrap archive(s). An example of that usage looks like this[1].
The issue of a natural default for Tx is one on which we should continue to get opinions. For instance I’ve got tests that, in the case of one method, need to execute many Txs and ensure the persisted state (from the outside, testing isolation) is as expected.
S,
ALR
[1] https://github.com/arquillian/arquillian-showcase/blob/master/multinode/src/test/java/com/acme/multinode/grid/Deployments.java#L37
I’m loving AS7 now that it’s maturing a bit, though the way the release notes don’t mention breaking backward-incompatible changes is a bit frustrating for a post-release product. I’ve been really happy with AS7 since I threw in the towel on Glassfish and switched; I got sick of the CDI integration bugs, the embedded mode bugs, and the glacial pace at which fixes were integrated. When I realised I’d spent more than 50% of my dev time tracking down or working around defects in the container I moved and I haven’t looked back despite the rough and unfinished edges in AS7. At least AS7′s rough edges get finished and polished eventually
I decided to try Arquillian the other day, and so far I’ve spent two days bashing my head against this “simple” testing framework. It’s really, really simple so long as you don’t want to do anything real-world, but it needs some real-world examples and some smoothing of how it handles common things like beans.xml and persistence.xml.
The way the docs don’t cover the maven dependency resolver plugin or the deployment descriptor plugin is frustrating; knowing about them would’ve saved a lot of time.
The maven dependency resolver plugin sucks at pulling in a subset of dependencies from the project’s pom.xml, especially where the versions are specified via an import pom like the Seam 3 parent pom and/or where the repository isn’t Central. I just can’t get it to add the Seam 3 Security artifacts, for example.
It’s taken me ages to work out how to swap in a test datasource and swap some @Alternative classes in for the tests so I don’t clobber any data. Use of eg @DataSourceDefinition for test datasources would be handy.
Arquillian and ShrinkWrap need some examples that actually show semi-real-world problems, not just toys. If they’re for integration testing not unit testing, why are the examples tiny toy unit tests? It feels like bait and switch, just like Glassfish did with all the claims of it being amazing and fast followed by the buggy, slow, PermGenSpace error filled reality.