GlassFish & MySQL Unlimited - I Miss One Feature

Gesendet von admin [General] ( June 30, 2008 10:37 AM ) Permalink | Kommentare [0]

You Don't Need To Think About Transactions If:

1. Your application has no persistence and do not interact with transactional resources like messaging, legacy interfaces etc.
2. The application is used only by one user in sequential way in a single thread.
   
3. It only reads the data and no one writes or if it only writes the data, and no one reads :-).
   
4. The access to persistent storage, backend resources is performed in one (business) method.
   
5. You don't need the "Unit Of Work" abstraction. So it is no problem if the application dies between method invocations and the data is partly processed.
6. It's ok, if other applications, users etc. see the unfinished (uncommitted) activities in their applications.

You know such an application? :-). I hear from time time statements like: "This is just a report - so I don't need transactions - I'm only reading the data". In this particular case you would access the database without a defined transaction and especially isolation - so you will basically see a snapshot of the database (especially uncommitted changes).

Even if you totally ignore the transactions - you will still get the "Green Bar" in most cases. This is probably the reason, why transactions are often in fact ignored ...until the production :-).

Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 29, 2008 11:04 AM ) Permalink | Kommentare [3]

A Beautiful Java Book - Something For Your Lunch Break

I missed somehow this book. It is my first IT-book (almost) without technical content. Instead of learning new stuff, I just enjoyed it and remembered the old JDK 1.0 days. It is a "special edition" book for the Ten Year Celebration Of Java: Hello World(s)!: From Code to Culture, a Ten Year Celebration of Java Technology. It comes with lot of pictures and arts - but almost no text. So it is perfect for a lunch break - you can fully read it :-).

Gesendet von admin [Fun] ( June 28, 2008 12:53 PM ) Permalink | Kommentare [2]

Is EJB 3 The Solution For The "Multicore Crisis"? (@Stateless and @Stateful)

During yesterday's excellent talk of Heinz Kabutz at Jazoon, it turned out, that even the += operator isn't atomic and can cause problems in  parallel, multicore, multiprocessor platforms. It doesn't have to be super-parallel - just current commodity hardware can already cause the problems - and you have to synchronized your code (without synchronized :-)).

Nevertheless, because EJB (1.0, 1.1, 2.0, 2.1, 3.0 and probably 3.1) are always executed in a dedicated thread - they appear as single threaded for the developer. For every thread (=user request, transaction) a new EJB instance is created (or reused from pool) - there is actually no shared state, except you access singletons, files etc. - which is not allowed. Actually the spec even prohibits the usage of the synchronization primitives and threading functionality inside EJBs.

Furthermore the programming model is rather procedural (or if you will "service oriented") - so in the @Stateless Session Beans the methods process some input data and give it back to the caller. Even the @Stateful Session Beans do not brake the rule - the container still prohibits concurrent access to the @Stateful instance. Because a @Stateful Session Bean can be only executed in a single thread - you do not have (you shouldn't!) care about the threading either.

The best of all: if you acess the JPA-persistence - the container synchronizes the data for you. Every transaction receives a copy of the JPA-entity (it is often implemented in this way), so nothing bad can happen even in this case.

I'm not sure whether there are actually some corner cases - where EJB programming model breaks in multicore environment (except you are violating the spec). Every EJB-instance can be only executed in a single thread. And every thread is (hopefully) executed in a single core. So if you keep the transactions short, and do not "hack" the EJBs accessing static variables or singletons - you are on the bright side :-).

Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 27, 2008 08:45 AM ) Permalink | Kommentare [2]

Embedding Glassfish V3 in Unit Test - Two Jars, Three Lines Of Code And Five Seconds Start With Deployment

There is already a great blog entry about using Glassfish v3 in embedded mode (I "reused" some ideaas and even code from the post - this is how web works :-)). It explains the whole process, to install, build and test Glassfish v3 using maven 2. However I just liked to do it without maven - and as easy as possible. To start glassfish you only need two jar:

• gf-embedded-api-1.0-alpha-4.jar
• web-all-10.0-build-20080430.jar

Having them in the classpath, you can start glassfish v3 just from your code - in process:

  GlassFish glassfish = new GlassFish(port);
It is not only possible to start glassfish in embedded code, it is even possible to deploy applications on the fly. The following code does exactly that:

ScatteredWar war = new ScatteredWar(NAME, new File("src/main/resources"), new File("src/main/resources/WEB-INF/web.xml"),   Collections.singleton(new File("build/classes").toURI().toURL()));
glassfish.deploy(war);

...and the full test code:

import org.glassfish.embed.GlassFish;
import org.glassfish.embed.ScatteredWar;
//and other obvious imports

public class HelloServletTest{
   
private final String NAME = "AppTest";
public static int port = 9999;

private GlassFish glassFish;

    @Before
    public void bootGlassfish() throws Exception{
        this.glassFish = newGlassFish(port);
        assertNotNull(this.glassFish);
    }
    @Test
    public void testServlet() throws Exception {
        URL url = new URL("http://localhost:" + port + "/" + NAME + "/HelloServlet");
        BufferedReader br = new BufferedReader(
                new InputStreamReader(
                url.openConnection().getInputStream()));
        assertEquals("Hallo from servlet", br.readLine());
    }

    private GlassFish newGlassFish(int port) throws Exception {
        GlassFish glassfish = new GlassFish(port);
        ScatteredWar war = new ScatteredWar(NAME,
                new File("src/main/resources"),
                new File("src/main/resources/WEB-INF/web.xml"),
                Collections.singleton(new File("build/classes").toURI().toURL()));
        glassfish.deploy(war);
        System.out.println("Ready ...");
        return glassfish;
    }
   
    @After
    public void shutdown(){
           this.glassFish.stop();
    }

The unit test is only a sample, in general I woul start glassfish in the static @BeforeClass method - for one test it is good enough.
Glassfish v3 is not production ready yet - but it becomes more and more interesting for development. Cannot wait for embeddable EJB 3 containers :-).

I checked in the whole project (with servlet, glassfish jars and the unit test) into the p4j5. The project name is: EmbeddedGlassfishWeb. The remaining question is: from where I have this two jars - the answer is simple: from the maven repository :-).

So, and I'm going to present this stuff now  - I'm at Jazoon :-).

Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 26, 2008 12:02 PM ) Permalink | Kommentare [4]

To JSF Or Not To JSF ...This Is The Question - or Why vi is Not Enough

1. Java Server Faces 1.2 are already shipped with every Java EE 5 server - so before you are choosing a more esotheric framework, you should at least evaluate JSF.
   
2. JSF are component based - the development model is event-driven and similar to Swing
1. A backend object (backing bean) receives the events (just a method)
   
2. Bi-directional, declarative Data Binding can be used to synchronize the view-components with the backing bean
3. The backing bean runs on the server - it can access e.g. the EJB 3.0 per Reference. "Fat Client" programming model is possible :-). This is a huge advantage. No value objects, client objects etc. are required.
   
4. Model View Presenter / Model View Controller patterns are easy to implement. The presenters / controllers can be even shared with Swing apps (in theory - in practice the views are too different).
   
3. Convenient data conversion for the common types (e.g. from String to int) already happens behind the scenes.
4. Validation support is already built in.
5. Navigation / Page Flow are provided and standardized.
   
6. Visual tool support for JSF is outstanding. Most of the tools are free e.g. Netbeans 6.1, Oracle JDeveloper, Eclipse with Plugins (e.g. Visual Page Designer in WTP 2.0). Some tools (e.g. Netbeans) provide visual support for page flows.
   
7. There are already many JSF component providers - many have AJAX support, and are opensource.
   

JSF programming with good tool support can be very productive (in my opinion - unbeatable). So it is absolutely possible to build from scratch a CRUD app in three minutes (with nice table - sorting included) - without hacking. In case a given JSF provider fully covers your customer's requirements - it's the best choice. Some extensions like Shale or Tiles, help you better structuring your application / page flow. However I would only use them if necessary (every jar increases the complexity...- and makes the deployment harder).

Nevertheless JSF 1.2 has also a "dark side":

1. The amount of XML-configuration is considerable (therefore tools are absolutely needed - vi, even emacs are not enough :-))
2. Building custom components requires some deeper knowledge - it is not so simple, as it could be.
3. Every request is a POST request - you will need some workarounds for bookmarking etc.
4. For more sophisticated applications - you will need to understand the "6 phases" - this can take a day of experimentation to fully understand it.
5. You will still need JavaScript / AJAX expertise, regardless how good your framework is.
6. Customizing the look and feel of the visual components, can be time-consuming. Go with the default if possible.
7. The whole component tree is cached on the server in memory - you should plan some performance tests to verify the requirements. In general the performance is o.k.
   

So to JSF Or Not To JSF - I'm a consultant - so the answer is clear: "it depends" :-). If you are building a corporate, enterprise application - JSF are just perfect. On the other hand, if you target is the consumer market, you are probably looking for more flexibility (and probably more effort to build the app then). Already looking forward to JSF 2.0 :-).
Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 25, 2008 10:14 AM ) Permalink | Kommentare [12]

How Fast Is The Build And Deployment Of about 660 JPA Entities And 50 Session Beans On Glassfish v2 And Netbeans 6.1?

I'm often asked about the deployment performance of Glassfish v2 in Real World. If you have just few EJB 3 and JPA-Entities the whole build and deployment takes only few (1-3 ) seconds. In Real World you will have rarely only few components to deploy, so I just measured the performance in the one of my current projects. The initial (standard Netbeans) ant build and deployment of JSF application with 660 JPA Entities and about 80 EJB 3 in an EAR, with creation of  tables etc. takes:

Enable of application in all targets  completed successfully
All operations completed successfully
post-run-deploy:
run-deploy:
BUILD SUCCESSFUL (total time: 2 minutes 32 seconds)

Subsequent redeployments are much faster - and takes about:

Enable of application in all targets  completed successfully
All operations completed successfully
post-run-deploy:
run-deploy:
BUILD SUCCESSFUL (total time: 41 seconds)

 In both cases the full cycle (clean, build deploy and undeploy) ot the whole EAR was tested. It seems like preparing the named queries and deploying the JPA entities consumes most of the time.

The first deployment in incremental / or activated directory deployment (goto -> services -> Glassfish -> options in Netbeans 6.1). Is very slow:

Enable of application in all targets  completed successfully
All operations completed successfully
post-run-deploy:
run-deploy:
BUILD SUCCESSFUL (total time: 7 minutes 6 seconds)

But subsequent deployment become really fast. I changed some JSFs and EJBs and it took:

Browsing: http://localhost:8080/myapp/
run-display-browser:
run-ac:
run:
BUILD SUCCESSFUL (total time: 6 seconds)

opening the browser included :-).

If you like to use the incremental deployment, use the "Run" option in Netbeans, instead of  "Undeploy and Deploy".

It was tested on Glassfish v2 (developer profile) on Java 6 update 10, Oracle XE, Netbeans 6.1 ...and Windows Vista 32 bit (without activated virus scanner :-)) on a IBM notebook. However from time to time it seems like Windows locks the files - so I have to restart Glassfish then. It seems to be a Windows problem - it occurs only in the "directory deployment" mode.

See you at Jazoon'08 :-)!.

Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 24, 2008 10:21 AM ) Permalink | Kommentare [7]

How To Start With Mercurial in 3 Minutes - or How Big Is The Netbeans Source Repo?

I read some installation instructions for installing Mercurial and checking out the sources. I got more and more confused - and I just tried it out. It turned out to be much easier, than expected. You just have to dowload the mercurial binaries, and execute the installation package (this is all you need for start). On Windows (Vista) it takes about 2 minutes. You don't even have to restart your machine (which is remarkable). Then restart Netbeans 6.1 (in case it is already running), go to Menu "Mercurial" -> "Clone Other".  You will be asked for the Repository URL. Use this: http://hg.netbeans.org/main to download Netbeans sources. It will take some time to clone the repo. In my case it took about 40 minutes over slow DSL line. After this you will be asked to open 899 projects (it's a good performance test for netbeans). The whole repo is 1.5 GB big, it contains 167.269 files. Gesendet von admin [Netbeans] ( June 23, 2008 11:06 AM ) Permalink | Kommentare [1]

Would Someone Consider To Use SWT (or another native widget library) Again These Days For Portable Platforms / Applications?

Everything started with AWT in JDK 1.0. It came with JDK 1.0, and it used (actually uses - is still there) native widgets for rendering. I still remember the excitement, as it was introduced around 1998 (with JDK 1.2). Everyone was excited, although even the JTextFields weren't rendered correctly. Swing took the opposite approach - it rendered the components itself - so it was somehow OS independent. Only about three years later Eclipse was introduced with the SWT. It took similar approach to AWT - because of responsiveness problems of Swing and the native look and feel. At the time it was a viable solution for a given problem (although e.g. the performance of other Swing apps was really good). These days the responsiveness of Swing is just phenomenal (just ask IntelliJ / Netbeans users about it :-)), and Eclipse (forms) looks very different to the native Windows applications (Outlook, Office, OneNote etc.). The new platforms like Flex, Silverlight, even Java FX do not even try to achieve a perfect, native, look and feel - many nice demos just look totally different (which can be a good thing).

A native UI toolkit is harder too maintain for different platforms, because you have to test different operating systems (32 and 64 bits), and emulate some widgets, since they are not available for every given platform. So there is more effort to achieve the same goal (a decent toolkit). Furthermore SWT can only wrap existing native widgets, so the usable API is somehow limited. It's not always fun to work with it. Just ask a developer (after a beer) with SWT / JFace experience, whether he reall enjoyed it. You will get interesting answers :-).

Regarding the maintanenance overhead and portabilities issues - it remains really interesting question. Would e.g. Eclipse start with SWT again - or provide a lightweight approach?

Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 22, 2008 05:26 PM ) Permalink | Kommentare [13]

Glassfish Could Become The Killer Portal Server - Project WebSynergy

I'm following the development of the Liferay portal server, for several months (if not years) now - it is one of the more pragmatic - and so usable portal solutions on the market. LifeRay is opensource, the code is clean and understandable - nevertheless the documentation could be still improved (as always :-)). Liferay is really impressive, it comes already with FaceBook, openSocial integration, different themes are already available -  PHP is already integrated as well. ...and it is JSR-286 compliant. At the JavaONE 2008 Sun/Liferay initiative was announced - the glassfish-synergy is already available for download. Liferay Portal 5 is bundled with Glassfish v3 TP2 - you have just too extract and start it, wait a minute and go to http://localhost:8585/  its worth (login with: paul@example.com and paul). It comes with some nice widgets...

An except from the announcement:

"...The common codebase will be managed by the Liferay community with Sun as a committer and governance board member of the project. Over the past 6 months, Sun and Liferay have worked together to incorporate Sun's OpenPortal Portlet Container 2.0 (JSR286), Web Services for Remote Portlets (WSRP), and JSF Portlet Bridge projects into Liferay Portal. Over time, Liferay Portal will incorporate additional OpenPortal technologies such as Mirage CMS, Simple API for Workflow (SAW), and other projects that Sun and Liferay are planning..."

Some resources:

• http://www.liferay.com/web/guest/downloads/portal
• http://portal.dev.java.net/
• https://eclipse-portalpack.dev.java.net/
• http://portalpack.netbeans.org/

I posted about 2 years ago already an entry with similar title: "Glassfish could become the killer appserver for Java EE 5...", a kind of deja-vu :-). See you at Jazoon (I'm preparing the slides now :-))!.

Gesendet von admin [Java EE 5 Architectures And Idioms] ( June 21, 2008 05:41 PM ) Permalink | Kommentare [1]