11 – Welcome To Azzyzt JEE Tools

 Featured, Regular Post  No Responses »
May 222011
 

I have already hinted at it in the answers to comments, but now it is official.

Azzyzt JEE Tools are available as open source.

Azzyzt JEE Tools are based on my Eclipse / GlassFish / Java EE 6 Tutorial and on a subsequent internal class that I held in October/November 2010 and that was based on the tutorial as well. The code generated by Azzyzt JEE Tools is basically a refinement of the code presented in the tutorial, with some very interesting features added.

For your convenience, here is the announcement again:

Version 1.0.0 has been available since end of March, but I had not announced it. Thus 1.1.0 is the first version that’s really open to the public.

Azzyzt JEE Tools is a collection of software tools helping software developers to create software using Java Enterprise Edition 6. It is designed to be integrated into popular Java IDEs, and at the moment this means it is an Eclipse plugin.

Azzyzt JEE Tools is a set of Eclipse plugins for creating a so-called azzyzted project, and for creating code from a model. Azzyzt uses Java JPA entities as a model, and from that model it creates an enterprise application, ready to be deployed in a Java EE 6 application server like GlassFish 3.1, ready to be accessed via CORBA, SOAP and REST. Thus the generated application is a set of web services, providing all that you need in a typical CRUD application.
Generated enterprise applications have separate source folders for generated and developer-supplied content. Add your own functionality to a well-engineered base project.
Azzyzt JEE Tools is not about user interfaces. It is expected that the generated application is accessed by a RIA frontend (Flex/Flash, Silverlight, Java FX, …) or by a fat client.

If you just want to use Azzyzt JEE Tools (as opposed to modify and build them), the recommended way to install the software is via an Eclipse update site. As of release 1.1.0, there are two update site URLs, one for the edition used by the Municipiality of Vienna, Austria, the other a generic version. The URLs are

http://azzyzt.manessinger.com/azzyzt_generic/

http://azzyzt.manessinger.com/azzyzt_magwien/

If you want to look into the source code, modify Azzyzt JEE Tools for your own use or if you even want to contribute, then you can fork the project from GitHub under the URL

https://github.com/amanessinger/azzyzt_jee_tools

So far the project lacks reference documentation, though a tutorial under

http://azzyzt.manessinger.com/doc/using_azzyzt.html

should give you a fairly good impression of what Azzyzt JEE Tools are about, how to get started and how to go on. The process of building/modifying the tools and of how to contribute to the code base currently lacks documentation.

All announcements of new versions will be published on

http://www.azzyzt.org

Discussion of the architecture, of interesting details of the implementation, and in general of things I’ve learned in the process, will happen on my programming blog

http://programming.manessinger.com/

If you want to be kept up-to-date, I suggest that you subscribe to the feeds of both sites, azzyzt.org and programming.manessinger.com, in the feed reader of your choice.

The next post will give you an overview of how the code generated by Azzyzt JEE Tools differs from the Eclipse / GlassFish / Java EE 6 Tutorial. Until then I suggest you have a look at the new tutorial Using Azzyzt JEE Tools.

Azzyzt JEE Tools are copyright (c) 2011, Municipiality of Vienna, Austria, licensed under the EUPL, version 1.1 or subsequent versions.

 Posted by andreas at 11:18 pm  Tagged with: , , , , , , , , , , ,

10 – That’s Why They Call It Stateless

 Advice, Featured, Regular Post  1 Response »
Aug 152010
 

Have you ever wondered how stateless an EJB3 Stateless Session Bean is? Well, I have, I wrote a test program and I got some interesting and – for me – surprising results, that I wanted to share.

My original understanding (or let’s call it mis-understanding) was, that the JEE server has a pool of EJB instances for each bean class, that you get one of those beans injected for each @EJB annotation, and that all those injections happen immediately upon entrance into the container via a top-level call.

A call to a service bean via SOAP is such a top-level call. I expected, that the injections not only happen in the called bean, but also somehow happen along the whole call graph, meaning that not only EJB references in the top-level service bean would be satisfied via injection, but also in beans referenced by that bean and so on.

Finally I expected that if two beans reference the same type of bean, they would actually get the same instance. I really have never thought the whole thing through, I simply expected some diffuse sort of magic.

The idea was, that some ServiceBean would get a value, either via parameters or from elsewhere (actually I thought of HTTP headers), store that information in some StorageBean, and then call a WorkerBean. The WorkerBean or some other code down the call graph would then retrieve that information from the StorageBean. In order for this to work, the StorageBean injected into the ServiceBean would have to be the same instance as the StorageBean injected into the WorkerBean, and the StorageBean would have to be exclusively allocated to that one thread for the whole duration of the top-level call, or else there would be a time interval between when the value gets being set and the time when it is read in the WorkerBean, leading to the usual multi-threading troubles.

I wanted a StorageBean to have some instance variables, wanted to fill them somewhere in the program, and wanted to read them elsewhere, without having to pass them around as parameters. In other words, I wanted a Stateless Session Bean to have some state, and I hoped that the container would guarantee consistency of this state for the time of one top-level call.

I’m pretty sure this is still not clear, so let’s look at some code. Here is a Singleton that generates random numbers:

package com.manessinger.test.stateless.backing;
 
import java.util.Random;
 
import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.LocalBean;
 
@LocalBean
@Singleton
public class RandomGen {
 
    private Random r;
 
    @PostConstruct
    public void init() { r = new Random(); }
 
    public int nextInt() { return r.nextInt(); }
}

The StorageBean could be something like

package com.manessinger.test.stateless.backing;
 
import javax.ejb.LocalBean;
import javax.ejb.Stateless;
 
@LocalBean
@Stateless
public class StorageBean {
 
    private int value;
 
    public void setValue(int value) { this.value = value; }
    public int getValue() { return value; }
}

A first shot at the ServiceBean could be

package com.manessinger.test.stateless.service;
 
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.jws.WebService;
 
import com.manessinger.test.stateless.backing.RandomGen;
import com.manessinger.test.stateless.backing.StorageBean;
import com.manessinger.test.stateless.backing.WorkerBean;
 
@Stateless
@WebService
public class ServiceBean {
 
    @EJB StorageBean s;
    @EJB WorkerBean  w;
    @EJB RandomGen   rand;
 
    public boolean test1() {
        int i = rand.nextInt();
        s.setValue(i);
        boolean isCorrect = w.verify1(i);
        return isCorrect;
    }
}

and here is finally the worker:

package com.manessinger.test.stateless.backing;
 
import javax.ejb.EJB;
import javax.ejb.LocalBean;
import javax.ejb.Stateless;
 
@LocalBean
@Stateless
public class WorkerBean {
 
    @EJB StorageBean s;
 
    public boolean verify1(int i) {
        int value = s.getValue();
        boolean isCorrect = (value == i);
        if (!isCorrect) {
            System.err.println(String.format("Error: expected %d, got %d", value, i));
        }
        return isCorrect;
    }
}

Thus the ServiceBean retrieves a random value, uses it to set the value of the StorageBean, and then passes the value into a verify() method of the worker. The worker retrieves the value from the StorageBean, compares it with its parameter, and returns true if they are the same value.

Try it for yourself: call the ServiceBean from the web service tester in the GlassFish Administration Console and it will just work. It’s EJB3 and EJBs are just POJOs after all, right?

Wrong. Sure, it does work, but now try to call the test method from a load testing application like Apache Jakarta JMeter. Try a thread group with 15 threads, a ramp-up period of one second, and 50 iterations. This makes for a total of 750 calls with a high degree of parallelity. Now look at the server log and you will see lines like

...
SEVERE: Error: expected 781730157, got -1784951881
SEVERE: Error: expected 781730157, got -1093939097
SEVERE: Error: expected -1093939097, got 540930629
SEVERE: Error: expected -1093939097, got 1481982330
...

Funny, huh? And look at the numbers: this is a typical effect in a program that is not thread-safe. Consecutive calls get mixed up.

My next idea was a variant:

    public boolean test2() {
        int i = rand.nextInt();
        s.setValue(i);
        boolean isCorrect = w.verify2(i, s);
        return isCorrect;
    }

and

    public boolean verify2(int i, StorageBean sParam) {
        int value = sParam.getValue();
        boolean isCorrect = (value == i);
        if (!isCorrect) {
            System.err.println(String.format("Error: expected %d, got %d", value, i));
        }
        return isCorrect;
    }

This means that I don’t let the StorageBean be injected into the worker, instead I pass it down as a parameter. Funnily enough, this did not work either. Under load it showed the same effect. Only when I finally passed the value in something that was really only a POJO, it did work:

package com.manessinger.test.stateless.backing;
 
public class StorageNonBean {
 
    private int value;
 
    public void setValue(int value) { this.value = value; }
    public int getValue() { return value; }
}
    public boolean test3() {
        int i = rand.nextInt();
        StorageNonBean snb = new StorageNonBean();
        snb.setValue(i);
        boolean isCorrect = w.verify3(i, snb);
        return isCorrect;
    }

and

    public boolean verify3(int i, StorageNonBean snbParam) {
        int value = snbParam.getValue();
        boolean isCorrect = (value == i);
        if (!isCorrect) {
            System.err.println(String.format("Error: expected %d, got %d", value, i));
        }
        return isCorrect;
    }

Of course the latter is trivial, but the consequences of this little test are clear:

Stateless Session Beans are really meant to be stateless. In fact the EJB 3.0 final specification says in section 4.5 that:

Because all instances of a stateless session bean are equivalent, the container can choose to delegate a client-invoked method to any available instance. This means, for example, that the container may delegate the requests from the same client within the same transaction to different instances, and that the container may interleave requests from multiple transactions to the same instance.

The only thing that the container guarantees, is that one bean will be exclusively allocated to a transaction (and therefore a thread) for the time of the invocation of one of its own methods. This does not extend to other EJBs that it calls. There is no guarantee that we call the same instance of StorageBean, if we call storage.setValue() and storage.getValue() even consecutively from the same ServiceBean, one call immediately after the other, and even if it were the same instance, there is no guarantee, that the storage has not been modified by another instance of the service bean.

Why did I ever get the idea that this construct could work? Well, probably it’s the fact, that the injection of a persistence context always gives you access to the same context (or at least the same data). I don’t know, but in any case I found it important to clarify things, because I have the impression that my mis-understanding is not completely uncommon, and when you fall into that pit, you may not recognize it until your system is under heavy load.

 Posted by andreas at 6:43 pm  Tagged with: , , , ,

7 – Eclipse 3.6 “Helios” and GlassFish 3.01

 Advice, Featured, Regular Post  No Responses »
Jul 092010
 

It’s only a few days since I’ve posted my Eclipse / GlassFish / Java EE 6 Tutorial, but due to the fact that it took me so long to write it, the toolset that I used is already outdated.

In the meantime Oracle has published a bugfix release to GlassFish v3, their reference implementation of Java EE 6 (and still the only implementation available), and of course Eclipse 3.6, code name “Helios”, has arrived. The last two days I had a deeper look into the combination, and I can tell that it works :)

Overall Impressions

Some bugs have been fixed, for example it is no problem now to restart the server, and the bug with libraries having been added to an EAR’s lib directory being “forgotten”, is gone as well.

At the moment I see only one major annoyance, and that is that re-publishing an application to the server tends to fail. The workaround is, to not manually re-publish, but instead use Add and Remove from the server’s context menu, Remove the application, Finish, followed by Add and Remove / Add / Finish. The bug has been reported on Java.net, but so far the guys responsible for the GlassFish plugin claim, that it is a bug in Eclipse. I fully expect some ping pong between the two development teams until the bug gets fixed :D

At work, under Linux, I have played once through my whole tutorial and found no showstopper. Thus, when I begin to teach Java EE 6 from next week, this is the combination that I’ll use.

Software versions and installation

I have used the following software versions:

  • JDK 6 Update 21 (JDK!!!): There are 32 bit and 64 bit versions, under Linux I have used the 32 bit version, on my laptop, where I’m just writing this, I run the 64 bit version. No problem with either.
  • Java EE 6 SDK: There is only one version, but the SDK is mostly JARs anyway. This time there is no “GlassFish Tools Bundle for Eclipse”, so be sure to download the right package. On the download page is a matrix that shows, which packages include what version. You will want the full Java EE 6 SDK, not the “Web Profile”.
  • Eclipse IDE for Java EE Developers is available for 32 bit and 64 bit as well. Under Linux I have used 32 bits, under Windows 7 the 64 bit version.
  • The Aquarium blog lists a temporary Eclipse update site for the GlassFish plugin, that’s how I have installed it. In the long run, the GlassFish plugin will be merged into the Oracle Enterprise Pack for Eclipse, the plugin that covers Oracle’s commercial application servers.

First thing to install is the JDK. Under Windows I have installed it to the default location. The JDK installs a JRE (runtime only) as well.

When you install the Java EE 6 SDK, you are asked to choose the JDK to be used. Unfortunately the stupid updatetool installation still has not been fixed. The installer asks you if it should be installed and you really ought to do that. Included with the installer is only a bootstrap version. Unfortunately (and unlike the full version) the bootstrap version can’t easily cope with authenticating proxies. At work under Linux, I had to supply username/password as part of the http_proxy environment variable, and because our proxy needs a Windows domain name in front of the user name, with a backslash as separator, I was in quoting hell :)

What I did after installing to ~/Applications/GlassFish_v3.01 was this:

cd ~/Applications/GlassFish_v3.01/bin
sh
http_proxy='http://DOMAIN\\\\USER:PASSWORD@PROXYSERVER:PROXYPORT' ./updatetool
http_proxy='http://DOMAIN\\\\USER:PASSWORD@PROXYSERVER:PROXYPORT' ./updatetool
^D

Starting sh disables the commandline history. Passwords don’t belong into histories :)

The first call to updatetool actually calls the bootstrap tool, the second call is to the real thing, a GUI tool, and there I’ve installed the two updates that are currently available, and then I have disabled automatic updates.

The four backslashes are necessary, because the bootstrap tool is a shell script, and the value is obviously evaluated two times. Whatever.

This was only a problem under Linux, because our fabulous proxy understands NTLM, and the Windows machine at work where I tried it, automatically authenticated via NTLM.

After the Java EE 6 SDK is installed (and with it GlassFish v3.01), don’t start the server. In your develpoment environment you will want to start it from Eclipse.

Next thing to install is Eclipse Helios. Simply unpack the ZIP where you want it. Start Eclipse, go to the Workbench, use Window > Preferences > Install/Update > Available Software Sites > Add to add the location http://download.java.net/glassfish/eclipse/helios, for instance under the name GlassFish Plugin.

Close the Preferences dialog and use Help > Install New Software. Make sure that Group items by category is not checked, at the top under Work with select the site you’ve just added, and now you should see three entries in the list, Oracle GlassFish Server Tools and the documentations for Java EE 5 and Java EE 6. Install all three. After the installation, Eclipse will prompt you to restart the application. Do so, and after marveling at the changed intro screen, go to the Workbench again.

Now we need to make sure, that we use the right JDK. Use Window > Preferences > Java > Installed JREs and check, that the path really points to the JDK that you’ve just installed, and not to the JRE, that was installed along with it.

Finally you can go to the Servers view and from its context menu add a server. As server type choose GlassFish Server Open Source Edition 3 (Java EE 6). Supply the directory, where you’ve installed the server (actually the glassfish directory within the directory, where you’ve instaleld the Java EE 6 SDK).

From then on, you can start the server via Eclipse and follow the tutorial.

Within the next days I will adapt the tutorial to the new versions and remove the discussion of bugs that have been fixed, but I will keep the old version for those people, who can’t update yet.

 Posted by andreas at 8:42 pm  Tagged with: , , ,

6 – An Eclipse / GlassFish / Java EE 6 Cookbook

 Advice, Featured, Regular Post, Tutorial  Comments Off
Apr 062010
 

Version 1.4, last updated May 23, 2011 – 11:10

The content of this tutorial is still relevant, but you may also consider my new open source Azzyzt JEE Tools, a set of Eclipse plugins that greatly simplify the process of creating a Java Enterprise application using the patterns outlined in this tutorial. See the Azzyzt JEE Tools home page and especially the tutorial “Using Azzyzt JEE Tools“.

In “4 – Equipment” I have committed myself to using Eclipse and the Java Enterprise Edition as my tools, while in “5 – Patterns And Languages” I’ve declared my high-level goals for implementing a next step of design pattern-based tools. Now, for a deeper understanding of design patterns, you first have to use them. This post in the form of a tutorial shows some very basic project setups using Eclipse and GlassFish.

I am no expert in this field, some important things may be missing, so just take the following as a set of things that work for me.

As I am not immune to learning, and as I am going the use these things a lot, it is inevitable that my understanding of certain aspects will change. I suppose that means, I will have to make changes to this post whenever it happens. If I ever do so, I will post a short notice.

Applicability

This is a tutorial about using Eclipse and the GlassFish v3 Java application server to implement Java EE 6 applications. I will show how to use different Eclipse project types for different purposes, will show how to do manual tests and how to implement automatic unit tests. We will not create a complete application, but more a vertical slice through an application. The idea is to just touch all relevant areas, not to finish a project.

The tutorial assumes the existence of a relational database, and it concentrates on the Java application used as a backend. Using JSF or another server-based GUI framework is definitely out of scope.

Where’s the beef?

At an equivalent of approximately 80 printed pages, the full tutorial is much too long for a regular blog post. It would break the size limit of feeds syndicated via Google’s Feedburner server. In fact it did. I had no choice but to move the text to a separate page. On the other hand, that’s quite OK, I want my tutorials (this won’t be the last) to be available as pages from a tutorial menu anyway.

Unfortunately I noticed the feed problems only after I had already published the URL of this post a few times. Thus, if you arrive here from a link, please go on to the actual page containing the full Eclipse / GlassFish / Java EE 6 tutorial. Sorry for the inconvenience.

 Posted by andreas at 3:27 pm  Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , ,

3 – What Can I Rely On?

 Featured, Regular Post  8 Responses »
Mar 272010
 

In the last post we have seen that it will take me years to finish this project. The question is, what can I rely on, what can I build upon. What are the tools that I can use, without worrying that they are obsolete before my own tool even becomes usable?

Programming Language

In the case of RPCmagiX I have made a bad choice. I used Itcl 2.2 for implementing the GUI, and as soon as I had finished it, ITcl 3 came out and it was incompatible in some subtle but crucial ways. But even if it had not been so obvious, today Tcl is mostly dead.

Perl was my choice for WADL, and although Perl is still much more alive than Tcl ever was, it is not really dominant any more. Perl 6 has taken too much time, there was a lot of FUD about Perl’s imminent death, and at the moment Python is king and Ruby the fashionable contender.

I really hate Python. It’s personal, probably nothing that you’ll understand, but a language that relies on indentation for structure, c’mon! That’s nothing but a bad, tasteless joke. So Python can’t be it.

Ruby seems to be OK as a language, but I have no idea how it will fare. It could easily be the next Tcl. Remember: we are talking about at least three years before the shelf life of my program even begins!

COBOL would be a good candidate for a language that is guaranteed to never die. But who would want to work in COBOL? Nope, not even joking :)

And then there is another thing: I would like to use one language for the tool and for the code it creates.

Currently I work with Java. It took me a time to like it, but now I do. Yes, it’s a big ecosystem, yes it suffers from the fact that they had to reinvent the wheel and everything else that already was there, but now it is pretty mature and complete. And it has Eclipse. Working with Perl I never missed an IDE. A lot of Emacs windows on a big virtual desktop, some teminal windows, that’s all I ever needed.

Not so with Java. Java is pretty unusable without an IDE. But when you have something like Eclipse, when you have an integrated, incremental compiler, when you don’t write texts but actually manipulate parse trees, then all sorts of funny things are possible. Think of the refactoring support, and suddenly Java is a very flexible and dynamic language.

And Java has some other advantages: It won’t go away. Too much important code depends on it. Java is like Cobol, only a much more likeable language, and one with absolutely superior tools. Java is such an important language, because so much code for banks and insurances is written in it. There is a reason why there is a Java Enterprise Edition.

And for all that reasons my potential users are very, very likely to use Java. When I want to maximize the impact of my tool, Java is an ideal language.

But then, very similar things could be said about C#. Same category of language, same capabilities. A year ago I have written a nice mult-threaded system in it, and as a language I like it. Why not, it’s Java, deliberately disguised in an incompatible syntax, but there is no essential difference, and some solutions they have come up with, are really, really clever. For instance I like partial classes and miss them in Java.

On the other hand, it’s a matter of principle. I don’t like a language that is so tightly controlled by an entity like Microsoft. I don’t like working on Windows either. Yes, there is Mono, but when you go the Microsoft way, you really want Visual Studio.

Apart from that, it can have actual advantages when your tools are open source. Remember my ill-inspired decision for Itcl? Well, it is open source after all. For more than 10 years we have compiled Itcl 2.2 on all our AIX and Linux systems, and I see no reason why this can’t go on. A closed source core component would long since have been unsupported. Think of Visual Basic. Sure, Microsoft offered a migration path into .NET, but that’s only the core language. People often had augmented it with third-party components, and they often were not ported. We sure do have some of those cases.

Libraries And Frameworks

And then there’s all the stuff other people do. After all, what I’ll do is basically Model Driven Design. Eclipse has a whole big group of projects under that title. Shall I use them. Can I?

They play a different game. They play a numbers game. The Eclipse Modeling Project has seven people only on its Project Management Council. Look at the list of projects on that page. Everything on that list looks interesting and like something that I could need, but I would have to spend all my time, work, free, sleeping, just to follow all that.

And then think of all that constantly changing. Try imagining the hassle with keeping all that in sync. It’s impossible, and even if I could do that, it would not help me, it would only slow me down.

No. I won’t do it. It may be possible to catch up with these things later though, for instance at a time when I have some people helping me. If they are interested in the field at all, they would probably have worked with those tools and frameworks. They would probably know how to bridge the gap between EMF and my own core abstractions. After all, whatever I come up with, it must be semantically equivalent to EMF, because if it were not, it couldn’t be as expressive.

Yes, I know, in a way it’s a waste of time to re-invent such things, but I simply can’t tie my own core abstractions to something that is completely out of my control. This would be irresponsible. On the other hand, when my own modeling structures are largely equivalent, when they simply have to, we can always bridge that single gap later, and by doing so, we will gain access to the whole infrastructure. At least that’s the theory :D

So What’s Left?

I consider Java to be a good choice as a language, and I consider the Enterprise Edition in release 6 sufficiently mature. I will use all of that (well, probably not JSF, but who knows), and I won’t use any other framework.

The whole design will be very abstract, most of it completely oblivious of the environment it runs in. In the end there will be some channels where input comes from, the models will have to be stored, there will be code generators, but all that can be abstracted away, done by primitive stubs in the beginning, done by plugins later. The only things that I have to worry about now are my code abstractions and how expressive they are.

I can and should program away in my simple sandbox, not caring about slick user interfaces and high performance. While I do that, all sorts of things will happen. Computers will get faster, new frameworks, new GUI systems may come up and get mature, and I’ll connect to them when I need to. Doing it from the beginning would only be a waste of time.

 Posted by andreas at 8:35 am  Tagged with: , , , , ,
© 2010 Andreas Manessinger Suffusion theme by Sayontan Sinha