Du côté de chez...

       
 
GlassFish V3 runs on OSGi

As some of you may remember when I introduced the HK2 project last year, I described it as a friendly environment to OSGi where we would eventually be capable of running GlassFish V3 on top of an OSGi runtime. Thanks to the good work of Sahoo, this vision has finally been completed and I am happy to report that since last week, we are now capable to run GlassFish V3 on top of Apache Felix, one of the OSGi runtime available to the open source community.


In fact, we have also tried KnopflerFish (I like the name of course) and it runs fine so we are pretty confident that any OSGi runtime will be supported with minimum effort.


Now the interesting question that everyone will be asking soon, are we switching to OSGi as our underlying module subsystem ? Today I can say yes, we will. Some people might say that we changed our mind about OSGi, we didn't. From the beginning I always said we wanted to be friendly to OSGi, we just realized that vision... It is pretty clear that there is a big industry support for OSGi and it is important that GlassFish can be part of that excitement. I cannot commit on which implementation we will eventually use because we are still experimenting with some of them and we need to following conditions to be met :


    * open source

    * friendly license to one of our dual open source licenses as well as to our Java EE licensees.

    * good community (forums, mailing list) to get our questions answered

    * possibility of a commiter to be able to push our bug fixes.


Whichever implementation we choose will get a huge boost from this endorsement because we will certainly have engineers capable of fixing bugs, adding features but also we have top performance engineers at Sun that will help with the overall performance of the OSGi runtime. 


Sahoo will probably blog in a day or two explaining in details the technicalities of the solution we adopted but let me introduce it here. We are still capable of running in both HK2 mode and in OSGi mode, I am not sure how long we will maintain the HK2 mode but so far the startup is a lot faster in HK2 (1 second) versus OSGi (2 seconds). Ok no big deal I suppose but we will work on that. It's hardly surprising that HK2 is faster, it is not meant to be a generic modular subsystem like OSGi, it is quite optimized for our V3 work !


None of GlassFish code depends on OSGi libraries (or very very little), we isolated those dependencies in HK2 which makes it very easy for us to switch OSGi runtimes or even module management runtime with no code changes. The HK2 project will continue as it is offering a lot more than just module management, in particular we have the following features that we continue to use heavily :


    * module management isolation layer

    * module management through Repositories (coming in OSGi R5)

    * lightweight component model

    * dependency injection 

    * configuration handling


So if you want to play with the OSGi version of GlassFish V3, I would recommend downloading the latest binaries from there.

It's our latest build, don't expect miracle and please file bugs when you find one.

 

and to run GlassFish in OSGi mode, simply do from your installation directory

    	java -DGlassFish_Platform=Felix -jar modules/glassfish-10.0-SNAPSHOT.jar

to run in hk2 mode, just do

	java -jar modules/glassfish-10.0-SNAPSHOT.jar 
Posted by dochez @ 09:48 PM PDT [ Comments [19] ]
 
 
 
 
New GlassFish V3 Milestone
We just pushed out a new V3 milestone, it's available at https://glassfish.dev.java.net/downloads/v3-techPreview-2.html.

Of course I need to apply the usual warnings, this is a milestone build, we know there is a lot of thing not working or not reliably working... So the intent of this build is really for people to get a feel about the V3 user experience, you can start it, deploy web applications, and if you are all lucky this will all work. I would certainly not recommend using V3 today for any real development/deployment activity. This is also the first weekly promotion of V3, we will now promote weekly build to keep followers with the latest bits without having to build the workspace.

Features that are included in this milestone are web container related technologies excluding JSF for now. We do support the Java SE persistence, JRuby on Rails applications, multiple http listeners, virtual servers configuration.

The list of supported commands are here, the supported containers are Web and JRuby on Rails, check my earlier blogs or Arun's screencasts.



Posted by dochez @ 01:53 PM PST [ Comments [0] ]
 
 
 
 
JDK 6 with Leopard today !

So I have been one of the vocal voices that protested to Apple a few weeks back that Leopard does not bundle JDK6, it's been a disappointment compounded by the fact the JDK5 that ship with Leopard is quite incompatible with previous versions. Hard to say if my favorite Java Apps are incorrectly written or they just broke the compatbility but it is clear that IntelliJ for instance does not run on Leopard. 

Of course it starts fine but soon it fills up the system.log with stack traces and your machine will soon spend a lot time indexing these messages, bringing it to its knees. It was first reported by this now famous post and we all shared some anger at the situation.

Anyway, Soylatte have now ported OpenJDK (the now Open Source Java implementation from Sun) to Leopard, so the show will go on ! Of course this is not an acceptable solution for end users, running this port which actually use the X11 port instead of the Apple native UI has its draw backs :

    - it's poorly integrated with the rest of the operating system

    - no Aqua integration

Fabrizio blogged how to use Netbeans 6 with this port, it pinched my curiosity about my other daily tool, IntelliJ IDEA.

    - I download the linux version of IntelliJ, and decided to give it a try... and ...

 


 

Ok so this is probably not the panacea but for the developer it has a few redeeming qualities, for instance
the non visual aspects of the port are working just fine, I can run GlassFish V3 with jdk6 without a glitch
So I am now developing exclusively using the linux version on the mac, after setting the fonts to BistreamVera Sans with Antialiased and Bitstream Vera Sans Mono for editing, switch the theme to Alloy Glass and it's almost bearable...

To start IntelliJ, you just need something like

export IDEA_JDK=/Users/dochez/java/tools/jdk6
sh /Users/dochez/java/tools/idea-7364/bin/idea.sh

One last thing, the ALT key is not mapped correcly in X-Darwin, that is until you modify the .Xmodmap with the following entries, this will nicely swap your option and command key to map linux-style keyboards...

clear mod1
clear mod2
keycode 66 = Meta_L
keycode 63 = Alt_L
add mod1 = Alt_L Alt_R
add mod2 = Meta_L

So this is not perfect, but it has some advantages, they key bindings are Solaris/Linux style which for folks like me who get exposed to multiple OS is a blessing. I think Kohsuke will pay me a beer or better sake for that one, and we might see him hacking on a mac soon... Then again, after his "build this maven module" plugin contribution, I am in debt.. 

One last thing, I could not get ~/.xinitrc to work with X11 on Leopard : X11 would just not start any longer. Maybe a bug, not sure, feedback appreciated... so I have to run the xmodmap ~/.Xmodmap command manually once at each X11 startup.

Overall this is not perfect but for people like me that need JDK6 for development, it works great. Kudos to SoyLatte folks !
 

Posted by dochez @ 09:56 PM PST [ Comments [0] ]
 
 
 
 
How to build a gem

It's been quite public for some time that we have a special distribution of GlassFish V3 as a Ruby Gem file. Ruby gems are the packaging technology for ruby extensions, and having a gem distribution of GlassFish is interesting to the JRuby users community. 

Arun has blogged there about how to use the gem so I will just describe here how to build it.

To build the gem, you will need to following software :

  1. subversion to checkout the code
  2. maven to build
  3. jruby 1.0.1

The gem building is not part of the mainstream GlassFish build because it requires JRuby... The first thing to decide  is whether you want to checkout the entire GlassFish V3 workspace or just checkout the gem distribution module.

Case 1 : Entire V3 workspace

 First you should look into this document if you plan to change/add code to V3.

svn checkout https://svn.dev.java.net/svn/glassfish-svn/trunk/v3
cd v3
mvn install 

Once you have done that you have a glassfish build, you can just build the gem distribution by :

cd distributions/gem
mvn install 

Case 2 : Just the Gem 

To checkout the gem module 

svn checkout https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/distributions/gem

cd gem
mvn install 

Now in either case, you will find the gem file in target/dependency/glassfish/pkg directory, and you can install it in your jruby installation by doing

gem install target/dependency/glassfish/pkg/GlassFish-10.0.0-java.gem 

Once this is done, you just need to refer back to Arun's blog on how to use the Gem !

 


Posted by dochez @ 01:42 PM PST [ Comments [2] ]
 
 
 
 
The Road To Mercurial

As we have already stated, eventually GlassFish will move to Mercurial (Hg) as its primary source code management (SCM). However the road to Hg has proven more difficult than expected but let me start with why we need to move out from CVS.
  1. - CVS is fairly incompetent at moving files. With GlassFish v3, we will soon be changing the shape of the workspace to reflect our modularization effort and to stick closer to our new build system, maven2. So files will be moved around (possibly several times) until we stabilize the new brownian motion of modules relationships and without owning the cvs server (owned by java.net), we would have lost cvs history each time.
  2. - Hg is a distributed source code management system which is an advantage when dealing with massive projects like GlassFish.
  3. - Hg has the changeset concept where changes are treated as a group of related changes to several files which makes tracking and rollbacking a lot easier.
In fact, Sun is moving most of its open source projects to Hg, OpenSolaris and OpenJDK for instance so it's only natural we also move to this new SCM.
 
However moving is a difficult task, mainly because the tools to transfer the cvs history to mercurial are not capable of handling such a big repository as GlassFish V2. On top of that, our open source project host, java.net, cannot work with mercurial yet forcing us to manage our own infrastructure for user authentication, servers, and backup. We have better things to do...

So we have decided to move to Subversion ! Ok I know it sounds weird but hear me out :
  1. - java.net supports svn projects so no infrastructure work for us.
  2. - tools to move cvs history to subversion are very mature and worked flawlessly in our trial attempts.
  3. - in subversion, we can move files around without loosing history.
  4. - all IDEs in the universe supports subversion so our programmer's community don't get too impacted.
Does that mean we abandon Hg for subversion. No, the plan is still to move to Hg at some point. In particular, once we have settled our modules, we want to split the GlassFish repository in possibly 3 or 4 different java.net projects each with their private source code management. We think that creating new java.net projects will be a great time to move to mercurial.

So you have the full story, GlassFish developer, get to learn subversion for the time being and keep an eye on Mercurial.

Posted by dochez @ 08:13 PM PDT [ Comments [0] ]
 
 
 
 
GlassFish V3 update
We published the first version of the V3 build during JavaOne, and it was time for an update of bits for the folks that don't want to build themselves...

The new build does not have new features compared to the list announced at JavaOne, it is basically bug fixes coupled with some rework of the implementation that I did not have the time to finish in may. One of the cool new feature is how the admin commands are discovered and processed by the runtime.

One of the difficulties associated with supporting multiple container types from various sources and that you want to make it easy for these container providers to simply use the runtime services offered by GlassFish. One of these services are administrative commands, during my JavaOne session, I actually demonstrated how to add new command : version.

So as everything in V3, we rely on HK2 components to identify administrative commands. So in this case, the AdminCommand interface is annotated with @Contract, so all you have to do to add a new command to GlassFish V3 is to create a Service implementing the AdminCommand interface and the runtime will find it :

package com.foo.bar;

@Service(name="super")
public class MySuperCommand implements AdminCommand {
...
}

Now this is nice but we can do better, for instance because admin commands are Services, we can use injection, so say for instance you want to have access the domain configuration, you just do

@Inject
Domain domain;

and the domain information will be injected in the instance field before the command execute() is invoked, that's nice but why not extending this to the command parameters. Too many times, I have seen command implementations code just ensure that all mandatory parameters to the command are present, values are correct, and extraction from the String[] representation.

This is where the new annotation @Param become useful, annotate any instance field of the command implementation with the @Param annotation to make it a command parameter. So for instance adding the following

@Param
String name

adds a name parameter to the command. Of course, parameters can be optional

@Param(optional=true)
String myoptionalparam

or the default parameter for the legion of lazy typers like me :

@Param(default=true)
String path
so you can now do : 
asadmin deploy --path foo.war
or
asadmin deploy foo.war

Of course there can be only one default parameter. Also the param tag is automatically linked to the resource file of your classloader, so when you add the

com.sun.foo.bar.mysupercommand=Some random super command
com.sun.foo.bar.mysupercommand.path=path to the file the command applies to.

strings to your LocalStrings.properties, the system will find them and use it for any type of error checking or help :

$prompt>asadmin super
FAILURE : super command requires the path parameter : path to the file the command applies to.

$prompt>asadmin super --help
Some random super command

Parameters :
        path : path to the file the command applies to.

The above behaviours are completely handled by the system, the command will not be executed as long as all mandatory parameters are provided by the users. There is more of course, like automatic help page and localized page creation.

Other things new in this build :
  1. HK2 injection manager is now reusable with other types of annotation than @Inject. I got the idea from Adam Bien, I also use it to inject the @Param we saw above
  2. Adding drivers to lib/shared will make them automatically discovered by the persistence provider.
  3. Support for all content types as defined in the domains/domain1/config/default-web.xml
  4. gem support (you can now build a gem file from the distribution and use jRuby to automatically install GlassFish V3 within a jRuby install)
Enjoy, spam me with comments.
Posted by dochez @ 12:04 PM PDT [ Comments [0] ]
 
 
 
 
My Own Bileblog ?
So I am at JavaOne, introducing HK2 and GlassFish V3 but today, I really ponder, should I create my own Bileblog ? It really started on JavaOne Day 0 when I went to the Groovy and Grails nfjs meeting.

It was ugly, bad demos looking to be revamped from demos I was doing with VB and the Java Plugin back in 98, panelists full of attitudes, the audience was actually rioting and challenging everything they were saying, but that did not seem to deter them much.

I was rolling on the floor laughing at the idiotic statements of Neal Ford, I sincerely hope that he was under the influence of some illegal substance (this was in san fran after all) because if he believes :
  • since all talented programmers (like him) do 100% unit tests, strong typing is just bureaucracy to satisfy the compiler. Oh right, let's replace the checks the compilers do for us with some good old tests we have to write manually, and anyway who ever do test 100% of their software, nasa maybe, boeing and airbus hopefully but nobody I know.

  • Nobody needs an IDE, they are just a nuisance created to make strongly typed language bearable, seems like these superstars of programming never needed any code refactoring of any sort. And they probably never worked with teams of more than 2 self proclaimed code artists.

And that was sad, because Guillaume Laforge is such a nice guy and Groovy could have a stronger position in the dynamic languages community with its natural integration with Java, its support for strongly type and untyped programming styles. So instead of reducing Groovy to just a pure untyped OO language, I think they should play the two faces of the coin, use types when you need them and keep the dynamic code for the integration, agile code that need many fast changes.

Anyhow, I will work soon to make Grails work in GlassFish V3, I am not as close minded as some folks I saw that evening.

But I really have high respect for Hani because it is not easy to do a good BileBlog, look at Cedric pathetic attempt to rant here, just plain sad, he really is smarter than that when you talk to him, he probably had to many vodkas the evening before writing his blog at the Sun party at the W. Doing a good Bileblog takes good knowledge of the technology and characters, and certainly no hangover...

Ok I have to confess that maybe I like Hani because he never biled me, I suppose I am too obscure to be his satire victim, but even if it happens, I think that just like a child I should take it as : negative attention is always better than no attention.

And no, I certainly don't consider Hani a paternal figure, good lord !
Posted by dochez @ 10:52 PM PDT [ Comments [1] ]
 
 
 
 
Hundred Kilobytes Kernel


From my first GlassFish V3 screencast I posted here last month, I received quite many inquiries about how we started implementing GlassFish V3. Questions like how can it start so fast, how do you implement the module subsystem and so on... It became very clear that we had done could be reused by others to create modular applications.

So we have created a new java.net project called HK2, for Hundred Kilobytes Kernel. This project is really a set of reusable technologies that serves a foundation for the GlassFish V3 implementation.

  • At the core, there is a module subsystem loosely based on the JSR277 for easy upgrade to Java SE 7

  • a component model above it which heavily use Inversion of Control , automatic dependencies resolution and life cycle management


 

 

HK2 is very small today, about 80Kb so it really is a great technology to use in any Java software development, it can be used in phones up to application server (obviously). HK2 depends on JDK 1.5 although it could easily be accommodated to run on earlier versions.

HK2 relies on maven 2 to build jar modules very easily, although maven is not dependency, it just makes things a lot easier.


As a side note, HK2 as a name triggers my imagination with the K2 mountain, therefore it will be its symbol.

Check it out at http://hk2.dev.java.net

Send feedbacks, I will also be talking about this extensively at JavaOne :

  1. TS-6503 : GlassFish V3 Architecture Review on Thursday 05/10/2007 at 2:50 PM -3:50 PM

  2. BOF-6678 : GLASSFISH V3 Architecture Review on Tuesday 05/08/2007 at 9:00 PM -9:50 PM

  3. BOF-4989 : Embedding the Grizzly Framework with Jean-François Arcand on Tuesday 5/08/2007 at 10:00 PM -10:50 PM
Technorati Tags: ,
Posted by dochez @ 03:37 PM PDT [ Comments [4] ]
 
 
 
 
First GlassFish v3 screencast

I took some time off coding to do a screencast on GlassFish v3, this should be interesting to many. GlassFish V3 started for me a few months back with the creation of the v3 cvs branch and since then, I have been happily coding some experimental pre-work.

Today, GlassFish v3 which will be a modular application server has reached a milestone. It supports four types of container :

  • Standard Web Applications
  • Ruby on Rails using JRuby 0.9.8
  • Phobos
  • PHP using the Quercus engine.

Startup time is under 1s (about 900 ms) on my MacBook pro, I am officially opening a competition on who can provide me with the best startup number using a commercially available processor...

But a good screencast is better than words so watch it, enjoy it, forward it but more importantly, talk to me about it if you have any feedback.

GlassFish v3 first screencast

As a reminder all the code you see demonstrated in the screencast is available today in cvs, if you are interested developing this outstanding application server, contact us !

Posted by dochez @ 09:13 AM PDT [ Comments [8] ]
 
 
 
 
GlassFish is Universal
Today, we are gathered to celebrate a new achievement of the GlassFish community.

After being used by a vibrant community around the world, GlassFish is the first application server officially adopted by Aliens. We are now Universal

The delegate from the Meelaneese race, a mate called "Robertoch Inni Ci" (nicely pictured here) has signed an extensive agreement to use and enhance the GlassFish Project.

You can learn more from our new GlassFisher friend from his blog, and although he talks about moons, his actual planet location remains a mystery.
Ok le'ts be serious for minute. Starting with build 40, the two native binaries used by the application server are now universal binaries which mean they run on PowerPC as well as the new exciting Intel based Macs.

Here are my findings and adventures on how to transition your JNI libraries to universal binaries.
One of these native component, the libcliutil.jnilib which is a JNI library used to implement one function so we don't echo the password when using the asadmin command in interactive mode. The other component, called the native launcher was used in 8.x to launch the application server with the right JVM parameters. It has since then been replaced with a Java Launcher but we keep this version for backward compatibility reasons.

The changes to support cross compilation were actually not that easy to find, the reason being that Apple's documentation (although being very nicely written and presented) rely too much on XCode to build your native binaries. Well, some folks still want to use good old makefiles to build their software and that was not easy to find the appropriate gcc flags :

-arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk

The -isysroot is very important when you use a PowerPC based Mac since they have the universal and PPC SDKs installed. With an Intel Mac, you only have the universal installed or at least it is the default one. If you do not add this option, you will get this kind of exception :

/usr/lib/libSystem.B.dylib does not contain an architecture that matches the specified -arch flag: i386

Now you may think that I am lucky to own all this Apple hardware, and indeed, my wife works at Apple afterall :).

This time however, I didn't get to own the Intel iMac I used to change the makefiles, I got the machine from James Gosling who was kind enough to lend me his iMac for some time so I could do this. And that machine (entry level 17inch iMac) really suprised me how fast it was. I am ready to trade my dual PowerMac G5 for those anytime !

I just wished that working on James Gosling's machine made me smarter... well that's a totally different story !
Posted by dochez @ 10:18 AM PST [ Comments [0] ]
 
 
 
 
Project GlassFish spins out a beta !

Rejoice !

This is a important day for the GlassFish community. Today, we officially released the Sun Java System Application Server 9.0 Beta which is based on the GlassFish project. Already confused with all these products terminology, I am with you, we could hardly have made it more complicated if we had really tried but consult Tony's wisdom, he will enlighten why everything has a place in the Sun (ah, I could not resist that one).

So what is the fuss about yet another beta... Well, first this is the first beta based on the GlassFish Open Source project, this is therefore the result of hundreds of developers working for at least 2 years. More importantly, this is the first beta of a Java EE 5.0 Application Server.

We worked with the specifications writers for two years to make the developer experience the center of all new features. For me, it really all started with a meeting every Monday evening at 4pm with me, Roberto Chinnici, Bill Shannon and Linda DeMichiel to resolve one of the most hated feature of J2EE 1.4 : XML deployment descriptors. The meeting was let's say always lively...

The first intimidating steps was JavaOne 2005, where Bill presented Java EE 5 during the technical keynote followed my own session to present the current state of affairs. After Abhijit's retirement, I became the GlassFish architect which is really a pompous title to say I am taking care of the stability and the future of the implementation.

We received very positive feedback during JavaOne and continued to work hard to push the specifications and the implementation to beta quality. But let's look at what is new to get you started with Java EE 5 :

  • AJAX : Java EE 5 with Java Server Faces has all the qualities to accomodate the specific requirements of an AJAXified application. Consult our local expert Greg Murray in this interview or the Aquarium page
  • JSF : Talking about JSF, you need to go check Ed's blog for the latest news on the web tier.
  • Persistence : A new persistence API based on Plain Old Java Objects (POJO) has been worked on by Linda and Mike Keith. This API will be available in Java SE as well as Java EE environments. I recommend you follow Sahoo's blogpage for tips and details on how to use this new technology. or the Aquarium persistence
  • EJB3 : The persistence APIs being separated from the EJBs definition will give a new life to this component model : simplified, lean and powerful, the new EJBs should be considered for all back end tasks. Look at Ken's samples, they are a great way to get you up to speed.
  • JAX-WS : the JAX-RPC APIs have came and gone. There were numerous issues with their evolution or ease of use, Roberto Chinnici came up with a new API for Web Services. Of course, Dhiru updated the JSR 109 to include such technologies in the Java EE environment. Go to my blog or to Vijay's blog to details and tricks on web services.
  •  JAXB, StaX and other XML goodies. There are plenty of web resources on how to use XML apis in Java, but I have to recommend the prolific Kohsuke's  train of thoughts

But wait, if you think we stopped at just implementing the specifications, heck no, we also have a full list of product features that will make your experience with our application server easy and complete.

  • Grizzly connector : check Jean Francois's blog on the optimized HTTP path we have in SJS Application Server.
  • Tools integration : we have plugins ! That's right, whether you use NetBeans 5.0 or better NetBeans 5.5 preview, they integrate with GlassFish. That's not all, you like Eclipse, we support that too. Ludo and Vince both maintain active blogs that talk about tools.
  • Admin framework : all administrative tasks of the application server can be done either through a CLI command, an API, or the admin GUI. One reference for administration : Kedar.
  • Web Services : there is life beyong basic web services. First for performance related information, FastInfoset is what you are looking for, Paul has also a blog to get you started. Then there is JBI with this how-to. Also remember to check WebServices Management with this tip
  • Deployment : from autodeploy to Java Web Start, deployment is faster than ever and packed with features, start with Tim's blog.

And we have documentation too, check the download page for the update SJS Application Server 9.0 documentation.

Well that's it, I hope I got you all excited about this new beta, one last thing, there is where you can download it. Please use it, write your ideas and experiences to the beta forum (user forum) or the GlassFish forum (more developer centric). We are looking for your feedbacks.

Posted by dochez @ 09:48 AM PST [ Comments [0] ]
 
 
 
 
GlassFish with Mustang

  No I am not playing with genetics to mix horses and fish DNA... I am just going to explain how to run the GlassFish application server with Mustang which is the JDK 1.6 codename.


The Beta2 of the Java SE 6 was released today. This is an exiting release, especially for folks like me who were never impressed with how previous JDK displayed fonts or obeyed to the native platform look and feel. Now when you install JDK 1.6, you get the native look and feel and font antialiasing. This makes Java applications look as neat as any other native applications now !     
Download the Java SE 6 beta from there and take the Glassfish bits. You can either take the beta or the active development version from the download page. I am on Solaris 10 running on one of these awsome AMD machine but the following intructions should be easily transferable to Windows.

I installed the JDK bits in /Users/applications/jdk1.6.0, let's check my installation and set my environment to use JDK 1.6
-bash-3.00$ which java
/usr/bin/java
-bash-3.00$ export JAVA_HOME=/Users/applications/jdk1.6.0
-bash-3.00$ $JAVA_HOME/bin/java -version
java version "1.6.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta-b59g)
Java HotSpot(TM) Client VM (build 1.6.0-beta-b59g, mixed mode)

Ok, we are all set on the JDK side (you could also update your PATH but that's not necessary), now I am going to install the GlassFish bits in say ~dochez/glassfish.
-bash-3.00$ java -Xmx250m -jar~/Desktop/glassfish-installer-9.0-b32g.jar 
-bash-3.00$ cd glassfish/
-bash-3.00$ ant -f setup.xml
Buildfile: setup.xml
....
validate-java:
     [echo] Current Java Version1.6.0-beta
....

That's it, pretty simple.

Now how can you change the version of the JDK used when you have already installed GlassFish. That's equally simple. The JDK path is stored in one location : <GlassFish_home>/config/asenv.conf
AS_JAVA="/Users/applications/jdk1.6.0"
you can replace this value with another path (as long as it is at least JDK 1.5) to play with different JDKs.


Posted by dochez @ 11:23 AM PST [ Comments [2] ]
 
 
 
 
Spring and Hibernate in GlassFish

Few days back, Matt Raible complained in his blog that Spring and Hibernate do not work in GlassFish. Being the GlassFish architect, he sparkled my interest ;-) Since I am always in for a good technical challenge, I decided to prove him wrong :

Part 1 : Spring

Here I am going to demonstrate the following :
    - how to get the Spring binaries
    - how to install them in the application
    - demonstrate how the Spring tutorial can work with the GlassFish/Spring combination.

First of all, go to the Spring website and download the latest version 1.2.6, I chose the fat download with all bunch of dependency jar files you will probably never need but at least, you are sure to have what you need.

Now, as I mentioned, I decided to try to run the Tutorial application which is also found on the Spring website. This is the link to the original tutorial, find below the updated instructions targeted to GlassFish, you will still need to reference the original article as I don't repeat everything...

Also, because I am not a big fan of complicated build scripts and being naturally lazy, I decided to use Netbeans 5.0 as my development tool. You can adapt the tutorial scripts to work with GlassFish if you prefer command line interfaces. Also, GlassFish has a plug in for Eclipse so you should be able to easily translate this effort for Eclipse (and maybe post the instructions as a comment...)

Next thing to do, go get yourself the NetBeans 5.0 RC2 and install it. Once you have done that, go get the latest GlassFish build, here I am using Build35. Install it in say $home/glassfish :

simplified instructions to install glassfish :

    jar -Xmx256m -jar glassfish<>.jar
    cd glassfish
    ant -f setup.xml

Now reading from the Spring tutorial steps, all you need to make your  Spring app work are three files located in the unzipped distribution we downloaded earlier
  • dist/spring.jar
  • lib/jakarta-commons/commons-logging.jar
  • lib/log4j/log4j-1.2.9.jar
To simplify things, I will make Spring available to the entire application server installation, which mean that all domains will have access to it and applications will not be required to bundle these jars inside their war files.

To do that, just copy the above three files in your glassfish installation lib directory ($home/glassfish/lib) and you are done ! I will explain later how you can actually restrict this to a particular domain or even a particular application.

So now you can start NetBeans 5.0 and add the Glassfish server to it :Tools Menu, Server Manager, Add Server

Adding a server to NetBeans 5.0

Once you have added the server to NetBeans, you can actually start GlassFish.

Now let's build our first Spring application ! The Spring Tutorial steps1 to 4 is just about building a simple WebApplication with a .jsp file. In NetBeans, it is very easy to do that in a couple of clicks  :
  1. From the file menu, choose "New Project"
  2. Choose Web Category
  3. Choose Web Application, Click Next
  4. Call you new project springapp, ensure that "Sun Java System Application Server" is the targeted server
  5. Click Finish
Select Web Pages, right-click and add a new JSP hello.jsp with this content :

      
<html>
<head><title>Example :: Spring Application</title></head>
<body>
<h1>Example - Spring Application</h1>
<p>This is my test.</p>
</body>
</html>
Now you have your project opened,  From the Run Menu, select "Run Main Project" you should see your browser showing you a "Hello World" type of page if you browse index.jsp (given by Netbeans for free) or hello.jsp

At this point you are done with step 1 to 5 of the Spring Tutorial, without typing a line of code or script...

On to Step 6, add the following
 <servlet>
<servlet-name>springapp</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>springapp</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
to your WEB-INF/web.xml, you can either use the nice UI or you can select XML category on top of your editor to have direct access to the XML content.

Adding the servlet to the XML

Step 7, add you springapp-servlet.xml to the WEB-INF directory

Step 8, add the SpringappController java class to the "Source Packages" category of your project.

Now your IDE should look like this
complete project

Something interesting here : With red underlining, NetBeans is telling you that the first two imports are illegal and that's because NetBeans does not know anything about the Spring Framework. Let's fix that :
  1. Tools menu, select Library Manager
  2. Add a new Library, call it "Spring"
  3. Add the 3 Jars we copied to $home/glassfish/lib
Done with adding the new Library, now change your project properties to add the new Spring library...
  1. Right click on your "springapp"
  2. Select Librairies, Add Library
  3. Select Spring Library from the list
Now when netBeans is done scanning the new jar, those red lines under the import statements should disappear...
Time to rebuild and deploy to check we are right on course with Step 11.

Step 12 : create a view
From the "Web Pages" sub element of your springapp project, select "new" and in the wizard, select "other" and "empty file", call this new file "hello.jsp"

<html>
<head><title>Example :: Spring Application</title></head>
<body>
<h1>Hello - Spring Application</h1>
<p>Greetings.</p>
</body>
</html>
Change the controller to now handle this new view :

import org.springframework.web.servlet.mvc.Controller;
import org.springframework.web.servlet.ModelAndView;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import java.io.IOException;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class SpringappController implements Controller {

/** Logger for this class and subclasses */
protected final Log logger = LogFactory.getLog(getClass());

public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

logger.info("SpringappController - returning hello view");

return new ModelAndView("hello.jsp");
}
}

Run the project and you should get something like this when browsing http://localhost:8080/springapp/hello.htm

successful running


On to Step 13, there is a mistake in the Spring Framework tutorial, It specifies that you need to change the include.jsp like this
<%@ page session="false"%>

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt" %>
In fact, it should be
<%@ page session="false"%>

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt" %>
Otherwise you can basically continue until step 16 and get the same results...

Ok, I think I have made my point : Spring runs unmodified in the unmodified GlassFish freshly downloaded from our web site.

Part 2 : Hibernate

For hibernate, things are a little more complicated depending on what youwant to do :
  • Use Hibernate APIs from a EJB Session bean, this is working since Sun Java System Application Server 8.1 and well documented here
    This integration is however far from complete as far as the TransactionManager is concerned  
  • Use Hibernate as an EJB3 Persistence Provider :
    This is not easy to make it work but doable, I have been working with Emanuel Bernard (ah.. the french connection, always easier) to get this done and he will be updating his wiki page with steps. The reason why this is not easily working is that both products are in active development and the windows for integration are not always overlapping. This will get resolved in the next day or so and I will publish a new blog. Today, what you have to do is described in another Hibernate wiki.
So running Hibernate in GlassFish is today difficult, granted but we are working hard to change this and you should hear soon when the integration will be completed. Now remember that we have a persistence provider in GlassFish (TopLink) which will allow you to start working with Spring+EJB3 Persistence. You may not have the persistence provider you want today but Emmanuel and I will ensure that we will provide a easy solution very soon. You can also follow Sahoo's blog for updated information.

Conclusion

Well, in all honesty, Matt had asked for some help on the glassfish forum and he did not get a satisfying answer which probably led him to believe that it just does not work but I hope I have dismissed all misunderstandings, we support Spring and Hibernate, we will work closely with all willing Open Source communities to integrate each others technologies. Finally, I hope that we will get more and more folks excited about GlassFish.

Post Script-um :

In his attempt to run Spring in the GlassFish application server, Matt got into trouble with the SecurityManager. What he did was probably to cobundle the Spring archives within his war files. I know some folks love to do that, but honestly this is not the right way of integrating framework libraries in any application server. My approach described above made the framework available to all the deployed applications. If you want to restrict its availability to a particular domain, just copy the 3 jars files in your domain/lib directory (like$user/glassfish/domains/domain1/lib) and edit your server.policy to not get into the same issue than Tom :

grant codeBase "file:${com.sun.aas.installRoot}/domains/domain1/lib/spring.jar" {
        permission java.security.AllPermission;
};   

Same solution (with a different path) can be applied for jar files that are bundled within your war file, this is actually documented here.
Posted by dochez @ 08:15 PM PST [ Comments [3] ]