Archive

Archive for the ‘java ee’ Category

The curious case of JBoss AS 7.1.2 and 7.1.3

January 9, 2013 14 comments

At the moment of writing, JBoss AS 7.1.1 is the latest version of JBoss AS that can be downloaded from their usual download page.

This release is nearly 1 year old, and contains quite a lot of really serious bugs. There is a JBoss AS 7.2 in the works, but since not even an alfa, milestone or beta version has been put on the download page, it might not be unrealistic to surmise a release of that is still at least some time away. For JBoss AS 5 it took over two years (2006-11-17 to 2008-12-05), for JBoss AS 6 one year (2009-12-02 to 2010-12-28) and so on. Although for smaller releases the time is typically shorter, e.g. 7.1 was just below three months (2011-11-22 to 2012-02-16).

JBoss AS 7.2 will undoubtedly fix many of the open bugs in 7.1.1, but because it will contain many exciting and fancy new features, it will almost surely also contain many not so exciting new bugs.

So, why doesn’t JBoss just fix a bunch of bugs in 7.1.1 without introducing any new features? Why isn’t there say a JBoss AS 7.1.2, 7.1.3 etc. Why do we have to wait so long for a new version only to get more new bugs?

Well, actually, this is exactly what they do. There is a 7.1.2 and 7.1.3 in which an enormous amount of bugs are fixed. The only thing is, those aren’t put on the regular download page, but on a ‘special’ download page that’s behind a login. Oh, and to make it kind of look like it’s another product the name is changed from JBoss AS to JBoss EAP and the version numbering is changed as well. 7.1.2 becomes 6.0.0 and 7.1.3 becomes 6.0.1. The WTP server runtime offered by JBoss Tools also plays this game along and puts the runtimes for those EAP builds under a different category. So with the “JBoss 7.1 Runtime” you can start JBoss AS 7.1.0 and 7.1.1, but for something that’s effectively JBoss AS 7.1.2 you need the “JBoss EAP 6.0 Runtime”.

Downloads are available from access.redhat.com/downloads, from which you have to click on “Evaluations and Demos”, and then on “JBoss Enterprise Application Platform Evaluation”. The download of the actual Application Server can then be found all the way at the bottom, called “Application Platform 6.0.1” in the case of JBoss AS 7.1.3 (aka EAP 6.0.1). There is a direct link, but it probably won’t work directly as you have to accept an evaluation license first.

But wait, evaluation license? Doesn’t that mean this is a derivate that’s not open source anymore? As it appears, this is not the case. These EAP builds are still fully open source, and a source archive is even provided as a download from the same page. But despite the fact that it’s still open source, the binary build cannot be used freely. I’m not a lawyer, and thus it’s a bit difficult to understand how this can be true. How something can be a derivative of a fully open source product, be a fully open source product it self, but still can not be used freely. Undoubtedly JBoss has this legally covered, but for a simple user such as myself it’s not easy to understand.

There is a large discussion about this on the JBoss community forum and Jason Greene (project lead) goes to great lengths to explain the situation, but a lot of questions remain. One way around the restrictions imposed by the evaluation license is to build the code from source:

Jason Greene:

Self build and support EAP – You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits.

However Rich Sharples remarks:

Right now we do not have a way of making EAP easily buildable for the general public (nor does the L-GPL or GPL require us to)

Until thus far this situation has not been resolved. One detail that comes up often is that EAP provides patches for “older” releases. In that thinking, if you want the latest and greatest you can get the community edition (AS), and if you want stability and accept older functionality, then you can buy the enterprise version (EAP). However, for nearly a year now, the EAP version is the latest and greatest. The last community release as mentioned is 7.1.1, so for all intends and purposes, the EAP versions corresponding to 7.1.2 and 7.1.3 are both the latest and greatest as well as the most stable release.

But about how many bugs are we exactly talking? Is all of this really worth the trouble? Let’s take a look.

There were 400 bugs fixed for JBoss AS 7.1.2.Final.

Then there were some 234 fixes for JBoss AS 7.1.3.Final.

Additionally there are even more fixes done. Namely, the mentioned 7.1.2.Final and 7.1.3.Final are just tags in the JBoss AS repository. This tag is presumably cloned into another repository, and there more fixes are done. Eventually, 7.1.2.Final became 7.1.2.Final-redhat-1 when it was released and 7.1.3.Final became 7.1.3.Final-redhat-4. Those additional fixes are mostly publicly tracked. Mostly, because there seems to be some tracking going on at restricted pages.

For 7.1.2.Final-redhat-1 there are 40 issues mentioned.

For 7.1.3.Final-redhat-4 there are 36 issues mentioned, but there are 3 intermediate versions with 126, 34 and 86 issues fixed.

Of those additional issues, further complicating the AS/EAP split is that an amount of them are direct clones from issues in the JIRA for AS. Those start with the word “CLONE”.

In total we have thus at least 634 fixes, and then some estimated 150 additional fixes (guessing the overlap is about 50%). So this are approximately 750 fixes, among which are some that are just by themselves a blocker for using JBoss AS 7.1.1 (depending on your use case). It thus definitely seems to be worth it to go for the 7.1.3 release instead of the 7.1.1 one.

Even though the EAP builds are open source and have their source available for download, there doesn’t seem to be a public repository for those ‘additional fixes’. The 7.1.2.Final and 7.1.3.Final tags however are directly accesible on Github. Since those are just tags, and not actual releases, there are no artifacts available for them in a Maven repository. For the EAP builds, there is as mentioned above no source repository available. Instead there is a public FTP server where the source is hosted (this is the same source as is also available as an archive from the restricted download page). Additionally, there is a Maven repository. There is the following somewhat disheartening disclaimer though at the root:

Red Hat reserves the right to modify the behavior and content of this repository or remove it completely with little or no notice.

The question after all of this is though, why does JBoss do all of this? Why does it hide the releases with bug fixes and why does it try so hard to keep up the illusion that JBoss AS and JBoss EAP are two completely different products?

The answer as stated in the above referenced forum discussion is that it mostly has to do with monetization. JBoss as any other company does have to pay its developers. Even open source developers of course need to be able to buy food at the end of the day. The thinking goes that if all binary builds were freely available, then less people would be inclined to buy a support contract. The support contract not only provides you with support, it also gives you access to the binary builds without the restrictions as opposed by the evaluation license. So with this setup, JBoss benefits from open source in that a lot of people from the community are able to report bugs with a detailed analysis of where things go wrong in source, possibly even with patches attached that fix said problem. Simultaneously they also, kind of, benefit from the closed source model, where you can charge customers for the software itself.

It’s undoubtedly a difficult balance, since as said even the restricted JBoss EAP builds are still open source and JBoss remains an open source company. The split between AS and EAP must eat away at least some resources as well. The clone into another repository, the merging of changes done there back to the mainline, keeping duplicated (cloned) issues, creating Eclipse server runtimes that are nearly identical, a separate Maven repository, etc etc.

Personally I wonder if in the end all of this is really worth the trouble. Why not just release every version as “JBoss AS”, put every version on the public download page, and then offer a support contract independent of access to the binary builds. If it’s really needed, some versions could be tagged as being specifically allegeable for support. Just like Canonical does with Ubuntu. Every version is freely downloadable and support can be bought separately. Some versions are supported for a longer time and get the “LTS” tag.

At the very least, JBoss could probably do a better job in advertising that there even is a 7.1.2, 7.1.3 etc available that are bug fix releases. I’ve been a JBoss user for some time and it wasn’t after some years that I finally discovered what was going on with EAP. Before that I just thought that EAP was the name of their support program. I literally had no idea that there were entire series of JBoss releases that were only available via EAP and thus didn’t appear on the public download page.

Categories: java, java ee

The state of @DataSourceDefinition in Java EE

June 30, 2012 3 comments

Traditionally, Java EE favored deploying applications with so-called unresolved dependencies. I talked about this in some more detail in a previous blog entry, but practically it boils down to the fact that a Java EE application can rarely be run as-is on an Application Server (AS hereafter).

Instead, specifically for the application that you want to run, all kinds of things have to be created and configured on the AS. Of course, this is different for every other implementation of such an AS, like JBoss, GlassFish, WebLogic, etc. So Java EE applications that are in theory portable, aren’t so in practice because of this ‘little’ thorny issue.

Worse, even if the application is to be run only on say JBoss, you traditionally can’t just take the .war or .ear and deploy. It has to be accompanied by some readme that explains which datasources, jms queues, roles etc need to be created. In JBoss AS 7 for example, all this has to be added to a single .xml file inside the AS.

So even if you only want to quickly test a single application, you’ll have to make many modifications to your installed AS. Imagine that every time you wanted to run a Windows or OS X application, you first had to thoroughly study some readme, make a ton of changes to your internal OS configuration files and only then after some trial and error would be able to run the app. Without a shadow of doubt, this would not fly with many people.

So do we really need to accept this for Java EE applications?

The short answer is “still a little, but it’s getting better”.

As an important step towards ready-to-run applications, Java EE 6 has standardized the way a data source is defined. This can be done via either an annotation (@DataSourceDefinition) or an element in web.xml, ejb-jar.xml or application.xml (data-source). Although the Java EE specification is rather clear in what has to be supported, its weak point is in enforcing that it’s actually supported. This mainly happens via the often criticized TCK (Technical Compliance Kit), which seems to spot check for features and behavior instead of exhaustingly making sure each and every thing specified is present.

On top of that, some vendors (notably JBoss), didn’t seem particularly thrilled about this approach. As a result, adoption of standardized internally defined data sources was initially slow.

However, the situation has greatly improved lately. After initially flat out refusing to support embedded data sources, JBoss has given in to support it anyway (via their proprietary -ds.xml mechanism). Up until the latest JBoss AS release (7.1.1) the standardized data source definition didn’t work really well, but in the recently released JBoss EAP 6.0.0 (a branched JBoss AS 7.1.2) it finally seems to work. JBoss EAP 6.0.1 (a branched JBoss AS 7.1.3) was also tested and luckily it also still works there.

To see how a variety of servers was doing, I tried to run the application I discussed at my above given previous blog entry on them, without making any modifications. The follow is the result:

Name Works Embedded driver Remarks
JBoss EAP 6.0 (AS 7.1.2) V V After AS shut-down, Hibernate tries to drop schema, but DB already closed at that point.
GlassFish 3.1.2 V X
WebLogic 12.1.1 V V Seems to start embedded DB twice, leading to locking errors in case of H2 on disk. Workaround by following strict shut-down/restart pattern
TomEE 1.1nightly V V After AS shut-down, DB tries to close itself, but classes already unloaded at that point. Note that TomEE 1.1 hasn’t been released yet.
Resin 4.0.28 V V
Geronimo v3.0 X V Doesn’t deploy when persistence.xml references datasource. Seems to be able to load driver from war, but lots of exceptions and failures everywhere.

As can be seen, two AS implementations struggle with an embedded DB that closes itself. Both JBoss EAP 6 and TomEE 1.1 threw exceptions at shut-down, though quite different ones. WebLogic had the reverse problem, instead of issues at shut-down time the issues were at start-up time, but only when restarting the server “the wrong way” (described here).

GlassFish was the only AS unable to load the DB driver from within the .war. This is a shame, as this is a very important feature for embedded databases (the driver jar -is- the DB in that case) and thus still requires the user to change something to the installed AS.

Geronimo was the only AS that didn’t work at all. As soon as the datasource was referenced in persistence.xml deployment of the application failed. Apparently the JPA processor can’t find the datasource when it’s setting up the persistence units. Removing JPA and attempting to inject the datasource directly semi-worked. Deployment succeeded and injection happened, but Geronimo appeared to be unable to set the vitally important url property. An issue has been created for this at their JIRA. On the plus side, it did seem Geronimo was able to load the driver from the war, but without anything else working this isn’t of much use in practice.

Finally, the perhaps somewhat lesser known Resin 4.0.28 was surprisingly the only AS that didn’t seem to exhibit a single problem on my test application with respect to the embedded data source (it was however rather noisy when running this test application, throwing various kinds of “warning exceptions” about backing beans and even some internal JSF artifact not being seriablizable).

So overall the results are rather good. Some minor issues, but no real show-stopper as before. Unfortunately JBoss still tries to scare their users away from these embedded data sources, by explicitly calling it “for development & testing only“, but they do support it now and seem to support it rather well.

Java EE 7 will introduce various additional standardized embedded resources, like JMS queues and possible even an embedded platform default database, which further widens the options applications that need to be ready-to-run have.

I would like to stress that Java EE applications with unresolved dependencies are absolutely useful for those situations where they need to integrate into existing infrastructure managed by operations teams. This is especially true if operations and developers don’t 100% trust or even know each other. Places like these is where Java EE was traditionally used a lot, but with the current crop of lightweight* application servers, Java EE has the opportunity to branch out to many more places, including those that don’t need or want to use a strict separation between application and resources.

(* to give an indication; the example app is small, but does use JSF, EJB, JPA and BeanValidation, which means the container needs to start up a lot of services. Yet, a cold startup of every Java EE server tested with the app already deployed to it, took in the range of 1 to a few seconds at most)

Further reading

Categories: java, java ee

Is WebLogic 12c a heavy-weight enterprise solution?

May 1, 2012 2 comments

There are quite a lot of Java EE implementations, among which open source and closed source implementations.

The closed source implementations are traditionally not only known for their “closed sourceness”, but also for their “enterprise aspects”. Developers themselves typically associated them with the term heavy weight. Where TomEE needs just 25MB for the entire Java EE 6 WebProfile and GlassFish 3.1.2 81MB for the full profile, the closed source implementations are assumed to be many gigabytes in size (including all kinds of “middleware” and “value added business solutions”), unobtainable via a public download (a salesperson will contact you if interested), take up to half an hour just to bootup and will use gigabytes of memory.

But is all of this still true? To test this I tried to obtain, install and run a very simple CRUD application on WebLogic 12c.

The results of this exercise were rather good, although there are some points open for improvement.

First of all, WebLogic can simply be downloaded just like all open source implementations. The download size is 183MB, which happens to be the exact same size that JBoss AS 6.10 was (AS 7.1 has since been slightly trimmed to 127MB). Yes, there are the ye olde 1GB+ downloads as well, but the 183MB one is the default. The text on the page is initially slightly confusing. At first glance it looks like you need a 997MB download for 64-bits VMs, but apparently this is only if you want the installer version.

So far so good, but then a slightly disappointing experience: you don’t just need to accept the license, no, you need to register first despite the promise that you can “download the software now”. I can only imagine many developers drop off here and download JBoss instead. (The company I work for among others investigates these kinds of flows and the drop off rate for each such hurdle is indeed dramatic)

The ones who do proceed to register, hoping for a quick “username + password” form are disappointed again. Here WebLogic/Oracle shows its enterprise face, as you have to fill out a huge form asking among others for your company and business phone. “Business phone”? Really!? Whoever made this form might not have had developers trying out things as their prime audience in mind. I filled out the form though and at least the download starts immediately after.

Hereafter I tried the usual steps to start the AS:

  1. Unzip downloaded archive
  2. Point Eclipse WTP server runtime to unzip directory
  3. Start AS via said server runtime

Unfortunately the server runtime didn’t recognize the directory where I unzipped WebLogic or any of its sub-directories. I quickly found a getting started by Arun Gupta and it appeared some scripts had to be run first. This getting started was a big help (thanks Arun!).

Running these scripts is not difficult really, but as I just blindly copy/pasted the commands I wonder why this can’t be automated or if it wouldn’t be possible to create a slightly smarter setup archive so this wouldn’t be needed at all. As said, it’s not difficult, but it’s a tedious chore, especially if you want to experiment with different installations. Things like this sadly contribute to the feeling of something being heavy-weight.

After this the dialog in Eclipse for creating the WTP server runtime recognized the WebLogic install immediately. A few remarks here though: for some reason I have to manually enter an external JDK home here. This feels sloppy, as the norm for Eclipse plug-ins is to offer the user a choice between the JDKs that are registered with Eclipse. On the same dialog there was also a text that “Server extensions Java Persistence 2.0” were enabled. I guess this is a left-over from an older WebLogic version where JPA 2.0 wasn’t yet the standard. I’m not sure this text still makes any sense for a Java EE 6 AS, but if anyone knows why this text is there please let me know.

I then finally started up WebLogic 12c and it surely didn’t take the many minutes people claim that this kind of software takes. Deploying the actual CRUD app didn’t take any significant amount of time either and my system certainly didn’t instantly started to swap. Strong points for WebLogic 12c here.

The default logging when starting up is also reasonably sane. The LoggingService is a bit noisy after the first startup, repeating the message about the log being rotated 3 times, but it’s certainly not page after page of unintelligible mumble jumble. To compare, the startup logs of JBoss AS 6.x and TomEE are much noisier. Here’s what the startup log looked like at my system:

<Apr 29, 2012 3:15:30 PM CEST> <Info> <Security> <BEA-090905> <Disabling CryptoJ JCE Provider self-integrity check for better startup performance. To enable this check, specify -Dweblogic.security.allowCryptoJDefaultJCEVerification=true> 
<Apr 29, 2012 3:15:30 PM CEST> <Info> <Security> <BEA-090906> <Changing the default Random Number Generator in RSA CryptoJ from ECDRBG to FIPS186PRNG. To disable this change, specify -Dweblogic.security.allowCryptoJDefaultPRNG=true> 
<Apr 29, 2012 3:15:30 PM CEST> <Info> <WebLogicServer> <BEA-000377> <Starting WebLogic Server with Java HotSpot(TM) 64-Bit Server VM Version 20.6-b01-415 from Apple Inc..> 
<Apr 29, 2012 3:15:31 PM CEST> <Info> <Management> <BEA-141107> <Version: WebLogic Server Temporary Patch for 13340309 Thu Feb 16 18:30:21 IST 2012
WebLogic Server Temporary Patch for 13019800 Mon Jan 16 16:53:54 IST 2012
WebLogic Server Temporary Patch for BUG13391585 Thu Feb 02 10:18:36 IST 2012
WebLogic Server Temporary Patch for 13516712 Mon Jan 30 15:09:33 IST 2012
WebLogic Server Temporary Patch for BUG13641115 Tue Jan 31 11:19:13 IST 2012
WebLogic Server Temporary Patch for BUG13603813 Wed Feb 15 19:34:13 IST 2012
WebLogic Server Temporary Patch for 13424251 Mon Jan 30 14:32:34 IST 2012
WebLogic Server Temporary Patch for 13361720 Mon Jan 30 15:24:05 IST 2012
WebLogic Server Temporary Patch for BUG13421471 Wed Feb 01 11:24:18 IST 2012
WebLogic Server Temporary Patch for BUG13657792 Thu Feb 23 12:57:33 IST 2012
WebLogic Server 12.1.1.0  Wed Dec 7 08:40:57 PST 2011 1445491 > 
<Apr 29, 2012 3:15:32 PM CEST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING.> 
<Apr 29, 2012 3:15:32 PM CEST> <Info> <WorkManager> <BEA-002900> <Initializing self-tuning thread pool.> 
<Apr 29, 2012 3:15:32 PM CEST> <Notice> <LoggingService> <BEA-320400> <The log file /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/myserver.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms, such as Windows.> 
<Apr 29, 2012 3:15:32 PM CEST> <Notice> <LoggingService> <BEA-320401> <The log file has been rotated to /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/myserver.log00018. Log messages will continue to be logged in /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/myserver.log.> 
<Apr 29, 2012 3:15:32 PM CEST> <Notice> <Log Management> <BEA-170019> <The server log file /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/myserver.log is opened. All server side log events will be written to this file.> 
<Apr 29, 2012 3:15:34 PM CEST> <Notice> <Security> <BEA-090082> <Security initializing using security realm myrealm.> 
<Apr 29, 2012 3:15:34 PM CEST> <Warning> <Store> <BEA-280109> <Unable to load the native wlfileio library for the persistent file store "_WLS_myserver". The store will use buffered I/O. The store is still operating in a transactionally safe synchronous mode. See store open log messages for the requested and final write policies.> 
<Apr 29, 2012 3:15:34 PM CEST> <Notice> <LoggingService> <BEA-320400> <The log file /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/access.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms, such as Windows.> 
<Apr 29, 2012 3:15:34 PM CEST> <Notice> <LoggingService> <BEA-320401> <The log file has been rotated to /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/access.log00018. Log messages will continue to be logged in /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/access.log.> 
<Apr 29, 2012 3:15:35 PM CEST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STANDBY.> 
<Apr 29, 2012 3:15:35 PM CEST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING.> 
<Apr 29, 2012 3:15:35 PM CEST> <Notice> <LoggingService> <BEA-320400> <The log file /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/mydomain.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms, such as Windows.> 
<Apr 29, 2012 3:15:35 PM CEST> <Notice> <LoggingService> <BEA-320401> <The log file has been rotated to /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/mydomain.log00018. Log messages will continue to be logged in /Users/henk/eclipse37ee/wls1211_dev/mydomain/servers/myserver/logs/mydomain.log.> 
<Apr 29, 2012 3:15:35 PM CEST> <Notice> <Log Management> <BEA-170027> <The server has successfully established a connection with the Domain level Diagnostic Service.> 
<Apr 29, 2012 3:15:35 PM CEST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to ADMIN.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RESUMING.> 
<Apr 29, 2012 3:15:36 PM CEST> <Error> <Server> <BEA-002606> <The server is unable to create a server socket for listening on channel "Default[2]". The address xxxx:0:0:0:0:0:0:1%0 might be incorrect or another process is using port 7001: java.net.BindException: Can't assign requested address> 
<Apr 29, 2012 3:15:36 PM CEST> <Error> <Server> <BEA-002606> <The server is unable to create a server socket for listening on channel "Default[3]". The address xxxx:0:0:0:xxxx:off:xxxx:d7%0 might be incorrect or another process is using port 7001: java.net.BindException: Can't assign requested address> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <Server> <BEA-002613> <Channel "Default[1]" is now listening on xxx.xx.xx.x:7001 for protocols iiop, t3, ldap, snmp, http.> 
<Apr 29, 2012 3:15:36 PM CEST> <Warning> <Server> <BEA-002611> <The hostname "localhost", maps to multiple IP addresses: 127.0.0.1, 0:0:0:0:0:0:0:1, fe80:0:0:0:0:0:0:1%1.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <Server> <BEA-002613> <Channel "Default" is now listening on xxx.xxx.x.xxx:7001 for protocols iiop, t3, ldap, snmp, http.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <Server> <BEA-002613> <Channel "Default[4]" is now listening on 127.0.0.1:7001 for protocols iiop, t3, ldap, snmp, http.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <Server> <BEA-002613> <Channel "Default[5]" is now listening on 0:0:0:0:0:0:0:1:7001 for protocols iiop, t3, ldap, snmp, http.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <WebLogicServer> <BEA-000331> <Started the WebLogic Server Administration Server "myserver" for domain "mydomain" running in development mode.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RUNNING.> 
<Apr 29, 2012 3:15:36 PM CEST> <Notice> <WebLogicServer> <BEA-000360> <The server started in RUNNING mode.>

Then I tried to request a page on localhost:8080, but no response. After a cursory look at the log shown above, it appears that WebLogic listens to HTTP at port 7001 instead of the usual 8080. I’m not sure why WebLogic has chosen 7001 here. Is it a port that WebLogic started using before the convention of using port 8080 was established, or is it a deliberate choice, “Think Different”?

Using port 7001 I could now request the CRUD form of the sample app, but unfortunately, I couldn’t post back this form as a ViewExpiredException was thrown. It appeared that my browser (Safari) didn’t accept the JSESSIONID cookie being send:

Set-Cookie:JSESSIONID=k2yPPcdFtLyyQL2vBmjt1G2PkV3YJGhyPvnYZhDZmn0TGC5GjLsN!-180841883; path=/; HttpOnly

I posted about this on the Oracle forum (hey, one advantage of the registration, I could post right away) and continued using Chrome, which did accept the cookie.

Right after the post back of the form I immediately got another exception:

java.lang.IllegalArgumentException: No persistence unit named 'entityManager' is available in scope jsf_ejb_jpa. Available persistence units: []

Suspecting the datasource in web.xml wasn’t supported I tried to find out how to define a WebLogic-specific datasource in a war. When this didn’t seem to be possible after reading articles and Googling for the better of an hour, I created an EAR with such datasource. Unfortunately still the same exception.

By this time I was also frequently getting the following exception:

Caused By: weblogic.common.ResourceException: Database may be already in use: "Locked by another process". Possible solutions: close all other connection(s); use the server mode [90020-161]
	at weblogic.jdbc.common.internal.XAConnectionEnvFactory.makeConnection(XAConnectionEnvFactory.java:498)
	at weblogic.jdbc.common.internal.XAConnectionEnvFactory.createResource(XAConnectionEnvFactory.java:175)
	at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1310)
	at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1227)
	at weblogic.common.resourcepool.ResourcePoolImpl.start(ResourcePoolImpl.java:250)

I’m using the embedded H2 database here in disk mode, which uses a lock. For some reason WebLogic seems to initialize the datasource twice. Once when starting up, and once when deploying the application containing this (app scoped) datasource, which causes a lock conflict. After some twiddling, the right sequence to get rid of this is:

  1. Undeploy app while WebLogic is running.
  2. Shut down.
  3. Delete locks on filesystem.
  4. Start up.
  5. Hot deploy app.

This kind of problem doesn’t occur when using H2 in memory or server mode, or using other ‘regular’ databases, but it’s peculiar that of the servers I tested the CRUD app on (JBoss AS, GlassFish and TomEE), only WebLogic has this problem with the on disk locks.

After some more experimenting, it appeared the entityManager problem isn’t related to WebLogic 12c itself, but appears to be a known issue with the WebLogic 12c WTP Server runtime and exploded deployments. After deploying the packaged war, everything worked.

Better yet, of all the Java EE 6 implementations I tested, WebLogic 12c scores best here. It’s able to process the datasource in web.xml AND is able to load the JDBC driver jar from the war. In contrast, GlassFish required this driver to be internally installed. JBoss AS can load the driver from a war as well, but currently has some major problems with transactional datasources. TomEE’s beta 2 also didn’t work correctly (but this will most likely be fixed in their 1.0 release).

So to conclude, despite the problems I ran into, I’m fairly positive about WebLogic 12c from the perspective of a developer trying out Java EE 6 code. The supposed real power of WebLogic is in quite another area (scalability, fail-over, etc), but for developers to even consider WebLogic and not have it merely forced upon them by management, it should have the basics right too and I think it has.

To summarize, WebLogic with respect to a casual developer trying out Java EE 6:

Strong points

  • Downloadable
  • Reasonable download size (183MB)
  • Good startup time
  • Startup log is not overly verbose
  • Can load JDBC driver from war
  • Processes data-source element in web.xml correctly

Points that could possible be improved upon

  • Elaborate required registration before downloading
  • Simple, but required installation scripts after download
  • Port 7001 for HTTP is uncommon
  • Eclipse plug-in asks for external JDK

The one thing that is and remains an issue for developers in WebLogic is that it’s closed source. It does pack an amount of open source code, like Mojarra (JSF) and EclipseLink (JPA), but the general inability to step into source in order to find the root of an issue would personally hinder me in my day to day development. I’m aware though that not all developers frequently step into the internals of their AS 😉

To conclude; WebLogic 12c is by no means the heavy-weight beast that common knowledge claims it is.

Categories: java, java ee Tags: