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

Comments

Post a Comment

Popular posts from this blog

Jakarta EE Survey 2022

-
At OmniFaces we poll the community from time to time and again about Jakarta EE (previously Java EE) and related technologies. With the transfer of Java EE to Jakarta EE now fully completed and Jakarta EE 10 released , people are now starting to think about Jakarta EE 11 , the second Jakarta EE feature release. As such it's a good time to poll the community again. This year we're doing so in cooperation with OmniFish . In the 2022 edition, there are 4 categories of questions again: Current usage of Jakarta EE Servlet containers APIs related to Jakarta EE The future of Jakarta EE Compared to 2020, we simplified some of the questions once more; again omitting some of the less popular options to make it more manageable. We kept the questions about the future of Jakarta EE and MP together as this issue still isn't resolved. We also ask about the preferred Jakarta EE cadence. As Jakarta EE 10 is the first feature release, we haven't really established a cade
Read more

Implementing container authentication in Java EE with JASPIC

-
This article takes a look at the state of security support in Java EE 6, with a focus on applications that wish to do their own authentication and the usage of the JASPI/JASPIC/JSR 196 API. Update: the further reading section has been moved to my ZEEF page about JASPIC . This contains links to articles, background, questions and answers, and more.   Declarative security is easy In Java EE it has always been relatively straightforward to specify to which resources security constraints should be applied. For web resources (Servlets, JSP pages, etc) there is the <security-constraint> element in web.xml, while for EJB beans there's the @RolesAllowed annotation. Via this so called 'declarative security' the programmer can specify that only a user having the given roles is allowed access to the protected web resource, or may invoke methods on the protected bean. The declarative model has a programmatic counterpart via methods like HttpServletRequest#isUserInR
Read more

Counting the rows returned from a JPA query

-
Despite being almost ten years old, the JPA specification to this day has rather poor support for basic paging/sorting/filtering. Paging/sorting/filtering is used in a lot of (CRUD) applications where the result from a query is shown in a table, and where the user can scroll through the results one page at a time, and where this result can be sorted by clicking on any of the table column headers. In order to support this a number of things are generally needed: The total number of rows (or entities) in the full result must be known There should be support for an offset in the full result and a limit for the amount of rows that will be obtained The column (attribute) on which to sort must be dynamically added to the query Search expressions must be dynamically added to the query As it appears, only offset/limit is directly supported in JPA. A sorting column can only be added dynamically when using the overly verbose and hard to work with Criteria API. Search expressions
Read more