Friday, October 18, 2013

JEUS application server: The story continues

In a previous blog post I wrote about JEUS, a Java EE 7 certified application server that is popular in Korea but pretty much unknown elsewhere. In this follow up I'll report about the latest findings and take a look at how to deploy an application to JEUS and do some debugging.

The previous installment was quite a story, but there's more. The us domain that was previously just gone briefly flickered into existence again, and it indeed offered the much sought after JEUS 7 download link; jeus70_linux_x86.bin. In order to get this I once again had to register a new account, and this time the signup process limited my password to 12 characters and did not allow capitals and non-alphanumerics (the 4 other signup processes that I went through did allow this). Unfortunately after a few hours the site suddenly featured completely different content. It's now largely, but not entirely, identical to the main corporate site, and doesn't feature the JEUS 7 download link anymore.

The tech site appeared to have a forum "hidden" behind the Q & A link. With some 5 to 10 posts per day it's clear that JEUS is definitely very much alive in Korea. (Google translate unfortunately stops working after you click on a post, so the forum is best viewed directly using the Chrome auto-translation).

Just as the entire site, the forum posts are mainly about JEUS 5 (J2EE 1.4, 2003) and JEUS 6 (Java EE 5, 2006). Apparently Java EE 6 (2009) hasn't fully penetrated the Korean market yet, although occasionally Korean users too wonder why JEUS 7 is not out there in the open. After asking on the forum the kind people from TmaxSoft where friendly enough to upload a JEUS 7 trial version again, this time on the English variant of the tech site ((which is rather empty otherwise, but now does feature this unique download)

There appears to be an Eclipse plug-in available after all on the download page, called JMaker, which in the typical ancient versions trend is of course for Eclipse 3.2 (2006) and supports JEUS 5. Next to the download page there's also a "resource room", which has a download page as well that has another Eclipse plug-in called the Jeus Bridge. This one supports Eclipse 3.5 (2009), which is slowly creeping towards the modern world, but unfortunately it too only supports JEUS 5. I got in touch with JEUS' lead developer Yoon Kyung Koo and he let me know they're attempting to open up the plug-in, which I take as meaning it will eventually appear in the Eclipse marketplace and such.

Downloads

So far I've found the following download links:

JEUS binary Size Initial release refJava EE versionDocumentation Dev preview Public download Site
jeus50-unix-generic.bin 265 MB May 2005 J2EE 1.4 JEUS 5 X X Korean tech site
jeus50-win.exe 205 MB X X
jeus60-winx86-en.exe 147 MB June, 2007 Java EE 5 JEUS v6.0 Fix8 Online Manual (11/2011) X X
jeus60-winx64-ko.exe 190 MB X X
jeus60_unix_generic_ko.bin 268 MB X X
jeus70_linux_x86.bin 133 MB June, 2012 Java EE 6 JEUS v7.0 Fix#1 Korean Online Manual (04/2013)

JEUS v7.0 Fix#1 English PDF set (08/2013)
V X US corporate site (dead link, no other source)
jeus70_unix_generic.bin 546 MB X X English tech site
jeus70_win_x86.exe 441 MB X X
jeus70_win_x64.exe 445 MB X X
jeus80_unix_generic_ko.bin 165 MB Est. Q4 2014 Java EE 7 [no documentation yet] V V Int. corporate site

 

Deploying to JEUS 8

Just as GlassFish, WebLogic and Geronimo among others, it seems it's only possible to deploy an application to JEUS via a running server. The simplicity that JBoss, TomEE and Tomcat offer by simply copying an archive to a special directory is unfortunately not universally embraced by Java EE implementations.

In order to deploy an app to JEUS 8 we first start it again:

./bin/startDomainAdminServer -domain jeus_domain -u administrator -p admin007
After it's started we connect to the running instance via the jeusadmin command:
./bin/jeusadmin -u administrator -p admin007
In my home directory I have a small war that I normally use for quick JASPIC tests. In order to deploy this we first have to install it via the admin console that we just opened:
[DAS]jeus_domain.adminServer>installapp /home/arjan/abc.war
Successfully installed the application [abc_war].
This command will copy the .war to [jeus install dir]/domains/jeus_domain/.uploaded and [jeus install dir]/domains/jeus_domain/.applications. After this kind of pre-staging step we can do the actual deploy:
[DAS]jeus_domain.adminServer>deploy abc_war -all
deploy the application for the application [abc_war] succeeded.
Note that the first argument for the deploy command is "abc_war". This is the application ID that is assigned to the application when it was installed and defaults to the full archive name with all periods replaced by underscores. There is more information available for each command via the help command, e.g. help deploy will list all arguments with some short explanation.

The deploy command will add a new entry to [jeus install dir]/domains/jeus_domain/config/domain.xml:

<deployed-application>
    <id>abc_war</id>
    <path>/home/arjan/jeus8/domains/jeus_domain/.applications/abc_war/abc.war</path>
    <type>WAR</type>
    <targets>
        <all-target/>
    </targets>
    <options>
        <classloading>ISOLATED</classloading>
        <fast-deploy>false</fast-deploy>
        <keep-generated>false</keep-generated>
        <shared>false</shared>
        <security-domain-name>SYSTEM_DOMAIN</security-domain-name>
    </options>
</deployed-application>

Requesting http://localhost:8808/abc/index.jsp?doLogin=true in a browser did load the correct test page, but JASPIC itself didn't work as expected. We should see the authenticated user's name and role, but this didn't happen:

This is not entirely unexpected as most servers need a special configuration (typically a vendor specific group-to-role mapping) before JASPIC starts working and I haven't added any such configuration for JASPIC yet.

Debugging JEUS 8

In order to find out where things go wrong it's always handy to do a little debugging. Maybe it's not the configuration at all, but perhaps the @WebListener isn't called that installs the SAM, or maybe it is, but then the SAM isn't called, etc. But without any tooling support, how do we debug an application running on JEUS? Using good-old System.out debugging gave me some hints. The SAM is not called for public pages (it should be) but it is indeed called for protected pages. Unfortunately despite being called for a protected page there still wasn't any sight of the authenticated name nor roles. Obviously we need some -real- debugging.

The most straightforward method to do that in this case is via remote debugging, which means we need to add a special agentlib parameter when starting up JEUS. [jeus install dir]/bin/startDomainAdminServer seemed like an obvious place as this starts a Java application that looks to be the server. Unfortunately it appeared to be only a launcher that launches a new process representing the real server and then exits. After some digging I found out that additional parameters for this "real server" can be specified in the same [jeus install dir]/domains/jeus_domain/config/domain.xml file that we saw before via the jvm-option element:


    
        adminServer
        
        
            
                -Xmx1024m -XX:MaxPermSize=128m 
                -agentlib:jdwp=transport=dt_socket,address=1044,server=y,suspend=y
            
        
        
    

Starting JEUS 8 again will cause it to halt and wait for a debug connection:

[launcher-1] [Launcher-0012] Starting the server [adminServer] with the command
 /opt/jdk1.7.0_40/jre/bin/java -DadminServer -Xmx1024m -XX:MaxPermSize=128m -agentlib:jdwp=transport=dt_socket,address=1044,server=y,suspend=y -server -Xbootclasspath/p:/home/arjan/jeus8/lib/system/extension.jar -classpath /home/arjan/jeus8/lib/system/bootstrap.jar -Djava.security.policy=/home/arjan/jeus8/domains/jeus_domain/config/security/policy -Djava.library.path=/home/arjan/jeus8/lib/system -Djava.endorsed.dirs=/home/arjan/jeus8/lib/endorsed -Djeus.properties.replicate=jeus,sun.rmi,java.util,java.net -Djeus.jvm.version=hotspot -Djava.util.logging.config.file=/home/arjan/jeus8/bin/logging.properties -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.util.logging.manager=jeus.util.logging.JeusLogManager -Djeus.home=/home/arjan/jeus8 -Djava.net.preferIPv4Stack=true -Djeus.tm.checkReg=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Djeus.domain.name=jeus_domain -Djava.naming.factory.initial=jeus.jndi.JNSContextFactory -Djava.naming.factory.url.pkgs=jeus.jndi.jns.url -Djeus.server.protectmode=false -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=/home/arjan/jeus8/domains/jeus_domain/servers/adminServer/logs/jvm.log jeus.server.admin.DomainAdminServerBootstrapper -domain jeus_domain -u administrator -server adminServer .
[2013.10.18 23:36:56][2] [launcher-1] [Launcher-0014] The server[adminServer] is being started ...
Listening for transport dt_socket at address: 1044

After this point we can attach to it via Eclipse:

If everything went well, you'll see JEUS 8's thread appearing in the debug view:

Setting a break-point inside the SAM and requesting the protected page again indeed breaks us into the debugger:

Without diving much further in the details it appears that despite passing the JASPIC TCK, the handler (shown in the image above as JeusCallbackHandler) does exactly *nothing*, so a standard JASPIC module can never really work. I confirmed that this is indeed the case with JEUS' lead developer. Remember though that the JEUS version being tested here is just a developer preview and the final version will most likely implement the required behavior correctly.

Interestingly, after playing around with JEUS' authentication some more it appeared that JEUS uses JASPIC auth modules to implement the build-in Servlet authentication methods. This is almost certainly also without using the Callback handler (as it does absolutely nothing, what would be the point?) so it's not in a fully JASPIC compliant way, but it's nevertheless really interesting. All other Java EE servers that I looked at don't actually use Java EE authentication as their native authentication system, but just wrap the JASPIC interfaces on top of whatever else they're using natively. JEUS has an exclusive here by basing their authentication directly on JASPIC. If they only can make it fully compliant JEUS will be one of the most interesting servers for JASPIC our there.

Redeploying

Deploying a single war once that's already in your home is one thing, but how to easily see your changes after editing in your IDE? Unfortunately there's no real easy solution for this without tooling support, but I cooked up the following admittedly very crude script that when executed from the (Maven) project folder somewhat gets the job done:

#!/bin/sh

WAR_HOME=/home/arjan/eclipse43ee/workspace/auth/target/

# Rebuild project
mvn package
cp ${WAR_HOME}/auth-0.0.1-SNAPSHOT.war ${WAR_HOME}/auth.war

# Redeploy to JEUS
~/jeus8/bin/jeusadmin -u administrator -p admin007 "undeploy auth_war"
~/jeus8/bin/jeusadmin -u administrator -p admin007 "uninstall auth_war"
~/jeus8/bin/jeusadmin -u administrator -p admin007 "installapp ${WAR_HOME}/auth.war"
~/jeus8/bin/jeusadmin -u administrator -p admin007 "deploy auth_war -all"

Meanwhile I have a tail on the log in another console:

tail -f domains/jeus_domain/servers/adminServer/logs/JeusServer.log

It works, but it's not exactly the experience you'd normally expect when working with an IDE.

Finally, we stop the server again via the following command:

./bin/stopServer -host localhost -u administrator -p admin007

Conclusion

In this article we haven't really extensively tested JEUS, but we just went through the steps of finding the download links, installing it (see previous article), deploying a really small application, and doing some debugging on the Java EE 7 developer preview. I didn't yet test a bigger application such as the OmniFaces showcase, something I still plan to do for JEUS 7 (the production ready Java EE 6 implementation).

By putting up English documentation and downloadable trial versions of JEUS 7 as well as a developer preview of JEUS 8 TmaxSoft has made some small but important steps to get JEUS out of international obscurity. Still they have some way to go. While we saw that deployment and debugging can be done without tool support, very few developers would consider this a viable option and because of that may not be really eager to try out JEUS.

An important next step for TmaxSoft will be to indeed make the required tooling easily and freely available.

Arjan Tijms

Thursday, October 17, 2013

The most popular Java EE 7 technologies according to ZEEF users

For some time now I'm keeping a page at ZEEF.com about Java EE 7. The page covers pretty much all Java EE 7 technologies, so the amount of clicks on the links of this page may give some indication of what parts of Java EE 7 are most popular with users.

At the moment of writing the top 20 list for the last 8 weeks looks as follows:

Position Link Category
1 Beginning Java EE 7 by Antonio Goncalves Java EE 7 overal
2 The Java EE 7 Tutorial Java EE 7 overal
3 Java EE 7 Essentials by Arun Gupta Java EE 7 overal
4 Java EE 7 code samples Java EE 7 overal
5 What's New in JAX-RS 2.0? (2) JAX-RS 2.0
6 Java EE 7: And Then What? Java EE 7 overal
7 JSF 2.2 new features in context [slides] JSF 2.2
8 CDI 1.1 available :-) CDI 1.1
9 Java EE 7 support in Eclipse 4.3 Java EE 7 overal
10 JSF 2.2: HTML5 friendly markup JSF 2.2
11 A closer look at the JSF 2.2 View Action JSF 2.2
12 What's new in JSF 2.2? JSF 2.2
13 Getting Started with JSON-P Java API for JSON Processing (JSON-P) 1.0
14 JSF 2.2 and HTML5 JSF 2.2
15 An overview of batch processing in Java EE 7 Batch Applications for Java Platform 1.0
16 Method validation in Bean Validation 1.1 Bean Validation 1.1
17 What's new in EJB 3.2 ? EJB 3.2
18 Java EE 7 Delivers Expression Language Enhancements Expression Language 3.0
19 Injecting An ExecutorService With Java EE 7 Concurrency utils for Java EE
20 What's new in Java EE 7's authentication support? JASPIC 1.1

As can be seen the general Java EE 7 topics are by far the most popular. There may be multiple explanations for this though. Is it simply the fact that the block containing the Java EE 7 links is the top left one (which people thus typically see first), or the fact that the page's title is "Java EE 7", so it primarily attracts people looking for general Java EE 7 stuff? Or is it indicative that people are increasingly seeing Java EE 7 as a single platform instead of a mere collection of individual specs?

After Java EE 7, a link about what's new in JAX-RS 2.0 was the most popular one, closely followed by links about JSF 2.2 and CDI 1.1. Aggregated on total clicks per category (not shown in the table) JSF 2.2 was the most popular category after Java EE 7.

With some distance we see JSON-P, JBatch, Bean Validation 1.1, EJB 3.2, EL 3.0, Concurrency utils for Java EE and JASPIC 1.1. Remarkable is that JPA 2.1, JMS 2.0, Servlet 3.1 and WebSocket didn't make it into the top 20 list for the last 8 weeks. Also remarkable is that JASPIC 1.1, which normally doesn't seem to be that well known among users, just barely makes it into the top 20 of most popular links.

Ordered by the highest ranking single link, the most popular Java EE 7 technologies according to ZEEF users thus seem to be the following:

  1. Java EE 7 overal
  2. JAX-RS 2.0
  3. JSF 2.2
  4. CDI 1.1
  5. JSON-P
  6. JBatch
  7. Bean Validation 1.1
  8. EJB 3.2
  9. EL 3.0
  10. Concurrency utils for Java EE
  11. JASPIC 1.1

Conclusion

We can't draw too many conclusions from this list, as the location of the link blocks on the page, the position of the links within each block, as well as the titles of the posted links play a role as well. As I'm active in the JSF community and not in say the JPA one, there may be some bias for JSF as well. Still, the page has a diverse amount of links, a diverse amount of referrals and there were a few thousand visitors over the last 8 weeks so I hope the data gives us at least some insight.

Arjan Tijms