Friday Apr 01, 2011

GlassFish 3.1 released

GlassFish 3.1 was released, find it at http://glassfish.java.net/downloads/3.1-final.html

Tuesday Jun 09, 2009

GlassFish V3 Extensions, part 4 : OSGi Declarative Services

Neil Bartlett was absolutely right that my last entry might have been a little too deep so I am simplifying the whole example in this entry by using plain OSGi Declarative Services in GlassFish v3. Declarative Services are described by Neil there and even more concisely by Peter Kriens with bnd at this location.

So I am going to have 2 modules in this example :

  • service bundle, this is my plain OSGi bundle, which packages two classes, the API and one implementation of that API. 
  • webclient, plain war file that use Java EE injection to access the OSGi declared service in the above service bundle.
Files can be downloaded there, there are two sub directories for each module. 

OSGi Declarative Service bundle

The OSGi bundle project is using maven to build as usual with GlassFish V3, the project contains 5 files

./pom.xml
./src
./src/main/java/examples/services/api/SimpleService.java
./src/main/java/examples/services/impl/SimpleServiceImpl.java
./src/main/resources/META-INF/MANIFEST.MF
./src/main/resources/OSGI-INF/simpleservice.xml

 Let's dive in the content now, first the service definition (unchanged from last entry) :

package examples.services.api;
/\*\*
 \* Simple service defition
 \* @author Jerome Dochez
 \*/
public interface SimpleService {
   /\*\*
    \* Returns a implementation specific string
    \* @return a String
    \*/
   public String getString();
}

The powerful implementation is using a different package and consist of the following java class :

package examples.services.impl;
import examples.services.api.SimpleService;
public class SimpleServiceImpl implements SimpleService {
    public String getString() {
        return "Simple Declarative Service implementation at your service !";
    }
} 

now the serious things can start, first with the manifest file containing the OSGi metadata :

Bundle-Version: 1.0
Bundle-SymbolicName: examples.services.declarative
Bundle-Name: Services definition bundle for OSGi Declarative Services in GlassFish
Export-Package: examples.services.api
Service-Component: OSGI-INF/simpleservice.xml
Bundle-ManifestVersion: 2 

Two things are worth mentioning, first only the API package is exported, the implementation package is a private entity of the module. Encapsulation is one of the benefits of modularization. Second the "Service-Component" entry points to a separate xml file describing the services provided by this module (hence the name Declarative Services I suppose). 

The content of the service definition file, is defined by the OSGi alliance specification, in this example the resulting xml is pretty simple :

<?xml version="1.0"?>
<component name="decl-service-1" immediate="true">
	<implementation class="examples.services.impl.SimpleServiceImpl"/>
	<service>
		<provide interface="examples.services.api.SimpleService"/>
	</service>
</component> 

Note that I gave a name (decl-service-1) to that service implementation, the curious reader should now experiment with creating more than services implementations, giving a different name to each of them. Build the project (mvn install).

The Java EE client

Very similar to the last blog entry where I was using Java EE injection (through the @Resource annotation), the webclient has not changed much :

import ...
import examples.services.api.SimpleService;
@WebServlet(urlPatterns={"/hello"})
public class HelloWorld extends HttpServlet {
    @Resource(mappedName="decl-service-1")
    SimpleService simpleService;
    public void doGet(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {      
        PrintWriter pw = res.getWriter();
	try {
	    pw.println("Service class is " + SimpleService.class + "<br>");
	    pw.println("First service is " + simpleService);
 	    if (simpleService!=null) {
		pw.println("SimpleService says " + simpleService.getString());
		pw.println("<br>");
	    }
	} catch(Exception e) {
	    e.printStackTrace();
	}
    }
} 

Needless to say that the servlet is not importing the implementation package, just the API. In fact even if it tried, it would fail at runtime (not compile time unfortunately until JDK 7 starts supporting modules and OSGi metadata) since only the API package is exported by the bundle. Another mvn install to get the resulting war file.

Getting things together

GlassFish V3 does not ship with all the OSGi services, just the basic runtime, so first, to be able to use OSGi declarative services you need to download the support for Declarative Services for Felix from there , you will need to take the SCR jar file. Once downloaded you should deploy it to the application server and deploy the service bundle as well as the webclient web application (they should be in the respective target directories of your project if you built successfully)

asadmin deploy --type osgi org.apache.felix.scr-1.0.8.jar
asadmin deploy --type osgi simple-declarative-service.jar
asadmin deploy webclient.war

now point your web browser to http://localhost:8080/webclient/hello

Service class is interface examples.services.api.SimpleService<br>
First service is examples.services.impl.SimpleServiceImpl@ec0c06f 
SimpleService says Simple Declarative Service implementation at your service ! 

Now combine this with the example of my last blog entry, you can see that I can now have my service API implemented either with a Spring component, or by a plain old OSGi Declarative Service and the actual implementation location will be immaterial to the servlet client code. Ah ! a good service based architecture can solve many problems just like a level of indirection can often lead to better code...

My next entry ? Maybe implementing my service with an EJB component, and show how one service can be implemented by a Spring bean, by an OSGi Declarative Service and by an EJB and have all three of them injected in the same servlet instance and be invoked transparently by the servlet code... would you be interested ?

Friday Feb 22, 2008

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.



Monday Oct 15, 2007

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.

Wednesday May 09, 2007

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 !

Friday Jan 27, 2006

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.

Thursday Dec 08, 2005

Ecto and other blog clients

Ok I am so tired of the web interface of blogger, I have decided to give a try to the blogger clients. this is my first post from ecto on OS X, let's see how it goes. Right, it worked, excellent, I am going to blog a lot more often

Saturday Sep 10, 2005

The Constant Gardener

Last week end, I went to see the movie titled "The Constant Gardener" and I want to highly recommend this feature to everyone. I will not talk about the story in details but to introduce the rest of my blog, I am forced to mention that the movie is about poor neighborhoods of Nigeria, where local citizens are used as guinea pigs by British pharmaceutical companies for their new medication human trials. Now as I was leaving silently the theater, among weeping women and embarrassed men that were starting to think that upgrading their mercedes might not be that urgent after all, I came to question myself... what a great english movie. right, the main actors, the theme, the companies, all British and then it came to me so violently : Why do Hollywood never produce such movies ? Such movies can raise awareness of the common people so far more than books, tv adds or such. Why is it acceptable that Hollywood make such great movie on the Holocaust but nothing of the troubling subjects of our time. But of course, you will tell me that indeed some innovative movies come out from US studios that do tackle various difficult society issues, I have to question why those movies stay as innovative or distributed by sub channels (like Fox searchlight and others). Why don't they use their most famous actors, their best directors to once in a while do an expensive movie that carry more humanity than the Wedding Crashers (nothing personal, I am sure it's funny). As America discover that we have left the poor behind in the south to face the consequences of Katrina, we do not like to see what we see on CNN. As we discover that our backyard is not that safe, we need to all raise from our couches and start thinking that maybe living in a world of permanent brainless entertainment is transforming us into ignorants of the real matters of our planet. One of the thing I really love at my work, at Sun, is the permanent questions we live in while working. Why, Why not ? Why doing things this way, why not doing things differently... Right, I wished I could extrapolate those practices in my everyday life to continue question myself on the path our society is taking us. I do it today, but will I do it tomorrow, and what is depressing, I feel alone doing it...
About

dochez

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today