Saturday, January 19. 2008
Welcome to the last entry of this blog. No I am not quitting, I am just moving. I just installed a new blog software framework. I was starting to dislike the way to interact and I wanted something that contained more out of the box. I am in the middle of moving to wordpress software. There is a very good reason to do this. I had found a great tool on the mac called MarsEdit. And again this could not be used with serendipity. I hope I did make a good choice. Since there is a lot of information in the old blog, I did not take this blog offline. It will stay to exist, but I will not make changes there anymore.
I hope to see you at the new version of the blog (check the page at http://www.gridshore.nl). You can attach you feedreader to the following url: feed://www.gridshore.nl/feed/
Wednesday, November 21. 2007
Some time ago I started working with intellij, recently I bought a mac, and now I want to start programming. But where to start? There are some mandatory things, or not? Well let’s just start and try to make it as flexible as possible so we can use other frameworks for some layers. For now I will focus on the following technologies:
- Springframework
- JPA, the hibernate implementation
- Java 5 and annotations
When creating the sample I started of programming in Intellij. Even with the excellent integration of JPA and Hibernate I still had a lot op problems creating the sample. Damn this is not easy. So what do you do when you are stuck? You start reading, I already had some books that could help me out. Still I like the “Java Persistence with Hibernate” book the best. The similarities between hibernate and JPA enabled me to quicker learn the basics. So I started reading, I came to the conclusion I had or wanted to start using annotations. It struck me how well Intellij was helping me again.
Just a few tips when developing with intellij, maven, jpa, spring, etc.
Create a new project based on an external model, click next and choose maven. Click next again and browse to the folter containing the master pom file. Click next and you have the option to select the project. The finish will create your new project with all modules present.
By default the spring and jpa facets are not present. You need to add them to the modules. Open the module settings (right mouse click and select menu item) and add the plus sign for adding a facet. The following screen shows the result of adding the spring facet and creating a new File Set. Another cool thing is that you can create a datasource to a database and connect this to a persistent unit. Columns and tables are then checked when creating your annotations.
I like the intellij way of creating new projects, but still I am a maven adept, so I wanted to have it all running with maven. You can find the sample online again. Beware, it is work in progress. I am adding a front end and more logic the coming weeks. Check:
http://gridshore.googlecode.com/svn/trunk/RaffleApp/
If you want to start with jpa, spring and maven I can recommend the following archetype:
http://www.rateyourwriting.com/downloads/jpa-hibernate-archetype.tar.gz
I did not try it out myself, but it looks very good. It is create by Chris Maki ( http://www.jroller.com/cmaki/category/JPA+101)
In the reference manual of the springframework I found a sentence that for new applications they prefer not to use the JpaDaoSuppor class. There is another way based on the special bean PersistenceAnnotationBeanPostProcessor. Using this bean you can use annotations like : @Entity, @PersistenceContext from within the spring container.
Back to my problem, for some reason my tests using the AbstractJpaTests did not work with the separate jars for domain and data access (dao). I started by combining them in one module. But I was not satisfied. So I went back to my friend Google. I typed in a query for information about using modules with jpa and springframework. To my surprise I got back a lot of articles about the debate between using DAO’s or not. Yes we are back to the discussion about DDD or Domain Driven Design. After reading a lot of posts I guess the following sentence found on a blog item from Craig Wickesser but written by Adam Bien:
“ I would say: it depends. It depends how complex your application really is. ”
Now back to the original problem, how to design a application using JPA?
Some of the choices you have to make: - Use annotations or XML or both?
- Use JpaTemplate or annotations and (org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor)
- Create one or multiple modules
Use a DAO layer or step into the DDD world and use the Persistence class.
In the end I did manage to get back to my so well known structure of a DAO layer and domain objects. What I had to do? We will check the persistence.xml file later on. I had to add the specific classes in this file.
Every problem needs a sample
Let me first explain a bit about the example that I am going to use. For a technology evening at my company I had some books that I could give away to the people present. Since it was an evening about the Google Web Toolkit I created a nice front end application using a file as storage to a Raffle application. Check the following application if you want to see it:
http://gridshore.googlecode.com/svn/trunk/Raffle/
I decided this file thing was not really optimal, so I wanted to create a database backed application. What to use? Well let’s try it out JPA, hibernate started to get boring and I wanted to move on. So what is in the raffle applications domain model
Some rules: - A raffle has multiple prices and multiple participants.
- A price has a winner
- A winner is a participant, or has a participant and a price.
We begin with the project setup using maven:
First the dependencies that you need in your pom:
spring-aop, spring-dao, spring-jpa, spring-hibernate3, hibernate-entitymanager, c3p0, mysql-connector-java, concurrent, spring-mock
That’s about it, put that in the pom.xml, create the structure and do a mvn clean install, or ...
Fire up intelij, create a new project based on this pom.xml and you can do the same things as I showed before.
We’ll begin with the domain objects:
@MappedSuperclass
public class BaseDomain {
@Id
@GeneratedValue
private Long id;
}
@Entity
@Table (name = "participants")
public class Participant extends BaseDomain {
private String name;
@ManyToOne
@JoinColumn(name = "raffle_id")
private Raffle raffle;
}
@Entity
@Table(name = "prices")
public class Price extends BaseDomain {
private String title;
private String description;
@ManyToOne
@JoinColumn(name = "raffle_id")
private Raffle raffle;
@OneToOne (mappedBy = "price")
private Winner winner;
}
@Entity
@Table (name = "winners")
public class Winner extends BaseDomain {
@OneToOne
@JoinColumn(name = "price_id")
private Price price;
@ManyToOne
@JoinColumn(name = "participant_id")
private Participant participant;
}
Next step is to create a DAO interface that does not have anything to do with JPA, I use the interface like this:
public interface BaseDao {
T save(T entity);
T loadByExample(T entity);
T loadById(Long entityId);
List loadAll();
List loadByFilter(T entityFilter);
}
For now I will not focus on the implementation, I am not a JPA expert yet  . One thing I want to mention is the EntityManager. Using a special annotation we make sure the EntityManager is injected by the container, the spring container in our case.
public abstract class BaseDaoJpa implements BaseDao {
@PersistenceContext
private EntityManager entityManager;
...
}
Next step is to configure the spring beans:
<bean id="raffleDao" class="nl.gridshore.samples.raffle.dao.jpa.RaffleDaoJpa"/>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceUnitName" value="raffle"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="databasePlatform" value="${hibernate.sql.dialect}"/>
</bean>
</property>
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>
<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${jdbc.driverclass}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
Finally we need to configure the the entity manager, this is done with a special file named persistence.xml which is displayed beneath.
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="raffle" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<class>nl.gridshore.samples.raffle.domain.BaseDomain</class>
<class>nl.gridshore.samples.raffle.domain.Raffle</class>
<class>nl.gridshore.samples.raffle.domain.Price</class>
<class>nl.gridshore.samples.raffle.domain.Participant</class>
<class>nl.gridshore.samples.raffle.domain.Winner</class>
<properties>
<property name="hibernate.archive.autodetection" value="class"/>
<property name="hibernate.show_sql" value="true"/>
<property name="hibernate.format_sql" value="true"/>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect"/>
</properties>
</persistence-unit>
</persistence>
That is enough to start using the application. However, there is one thing I forget. What about testing this application. Spring comes with a special class for testing called AbstractJpaTests. This is class had familiar functionality, auto dependency injection and rolling back a transaction after the test.
Using this test you still need a database. For the data access tests I am using a combination of dbunit, springframework and hsqldb. Most important part of the test class is the injection of the dao:
public class RaffleDaoJpaTest extends AbstractJpaTests {
private RaffleDaoJpa raffleDao;
public void setRaffleDao(RaffleDaoJpa raffleDao) {
this.raffleDao = raffleDao;
}
...
protected String[] getConfigLocations() {
return new String[] {"classpath:test-dao-spring.xml","classpath:dao-config.xml"};
}
}
The following beans are in the special test spring config file together with the datasource for the test database.
<bean id="dbUnitInsertOperation" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"
depends-on="transactionManager">
<property name="targetObject">
<bean class="org.dbunit.operation.RefreshOperation" />
</property>
<property name="targetMethod" value="execute" />
<property name="arguments">
<list>
<ref bean="dbUnitConnection" />
<bean id="dbUnitDataSet" class="org.dbunit.dataset.xml.FlatXmlDataSet">
<constructor-arg>
<bean id="refDataFile" factory-bean="referenceData" factory-method="getInputStream" />
</constructor-arg>
</bean>
</list>
</property>
</bean>
<bean id="referenceData" class="org.springframework.core.io.ClassPathResource">
<constructor-arg value="testdata.xml"/>
</bean>
<bean id="dbUnitConnection" class="util.CustomDatabaseConnection">
<constructor-arg>
<bean id="connection" factory-bean="dataSource" factory-method="getConnection" />
</constructor-arg>
</bean>
That is about it, again, check the source code, everything is runnable by maven2 and tested on tomcat 5.5. If you want to read more, I used the following resources while creating learning about jpa and the other topics.
Links:
http://www.infoq.com/news/2007/09/jpa-dao
http://debasishg.blogspot.com/
http://www.vitarara.org/cms/struts_2_cookbook/integration_testing
http://dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html?page=6
http://www.jroller.com/cmaki/entry/domain_model_revisited
Friday, November 16. 2007
Hai All,
finally a new technical item. It is a short item, but I have been struggling to get this to work. Therefore I want to share this so other can use it to configure there properties in a flexible way.
Problem:
Properties like database url's, userid's and pasword's are different in your test environment and your production environment. There are other items you might want to configure.
Solution:
You can make complicated deployment scripts that get the right property files for the right environment. But you need to create different packages for different environments. I think a more elegant solution is to use the JNDI parameters to load the specific environmental values. If there are a lot a good way might be to store them in a database and only configure the database access parameters using JNDI.
The following solution is based on two posts in different forums:
http://forum.java.sun.com/thread.jspa?threadID=647327&messageID=3810991 - gives details about the configuration of tomcat.
http://forum.springframework.org/showthread.php?t=30991 - gives details about the spring configuration
Now the code, we start with the tomcat configuration. The server.xml file contains all the actual values connected to the exposed JNDI parameter names.
server.xml
<!-- Global JNDI resources -->
<GlobalNamingResources>
<!-- Test entry for demonstration purposes -->
<Environment name="jdbc/username" value="myUser" type="java.lang.String"/>
<Environment name="jdbc/password" value="myPwd" type="java.lang.String"/>
<Environment name="jdbc/url" value="jdbc:mysql://servername/schema" type="java.lang.String"/>
<Environment name="jdbc/drivername" value="com.mysql.jdbc.Driver" type="java.lang.String"/>
</GlobalNamingResources>
We need to tell the application the names of the parameters that are available. We must add the following items to the web configuration file.
web.xml
<resource-env-ref>
<resource-env-ref-name>jdbc/username
<resource-env-ref-type>java.lang.String
</resource-env-ref>
Of course you need to do this for all four parameters. Then the tricky part. This is the one I missed while getting this to work. You need to add a tomcat specific deployment configuration with the following lines
META-INF/context.xml
<Context path="/webapp">
<ResourceLink name="jdbc/username" global="jdbc/username" type="java.lang.String"/>
<ResourceLink name="jdbc/password" global="jdbc/password" type="java.lang.String"/>
<ResourceLink name="jdbc/url" global="jdbc/url" type="java.lang.String"/>
<ResourceLink name="jdbc/drivername" global="jdbc/drivername" type="java.lang.String"/>
</Context>
Thats is all we need to do to make these values available to the spring beans. So the last part is the spring configuration. We are going to create a PropertyPlaceHolderConfigurer. That way you can access the properties just like properties from a file.
spring-config.xml
<bean id="databaseprops" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties">
<bean class="java.util.Properties">
<constructor-arg>
<map>
<entry key="database.username">
<jee:jndi-lookup jndi-name="java:comp/env/jdbc/username"/>
</entry>
<entry key="database.password">
<jee:jndi-lookup jndi-name="java:comp/env/jdbc/password"/>
</entry>
<entry key="database.url">
<jee:jndi-lookup jndi-name="java:comp/env/jdbc/url"/>
</entry>
<entry key="database.drivername">
<jee:jndi-lookup jndi-name="java:comp/env/jdbc/drivername"/>
</entry>
</map>
</constructor-arg>
</bean>
</property>
</bean>
<bean id="sampleConfigBean" class="nl.gridshore.samples.config.SampleConfiguredBean">
<property name="username" value="${database.username}"/>
<property name="password" value="${database.password}"/>
<property name="url" value="${database.url}"/>
<property name="drivername" value="${database.drivername}"/>
</bean>
This made my deployment life a lot easier, hope you will find some good use of it. Thanks again to contributers on the forum for making the different parts clear to me.
Till next time, which is going to be a piece about JPA.
greetz Jettro Coenradie
Sunday, October 14. 2007
The last month(s) I have been working on multiple Google Web Toolkit implementations. I must admit that the implementations are not very big. They are mostly small applications I needed for some reason. One of them is a Raffle system, there is one with a large amount of data on a screen that should be editable as well. In this blog item I will share some experiences I have gained using the Google Web Toolkit with maven2, JetBrains IntelliJ. The applications can interact with a standard GWT servlet, or with the springframework and security via spring security (acegi). I also experimented with a nice GUI framework called gwt-ext. Finally, I also used the Google Web Toolkit in a sample we created for spring osgi. So please continue reading, most sources can be found in in my code repository at google.
In this blog item I will mostly look at IntelliJ, I will create new blog items about using eclipse and maven as well.
Step 1 - Creating a project skeleton
If you just want to play around and you have IntelliJ, I recommend to use the new project wizzard from intellij. Just create a new Java Project and select Google Web Toolkit in the desired technologies section. Go to the module settings and point to the right direction of you gwt install. Now you can start adding modules, remote services, etc.
Step 2 - Adding the module and entry point
Start by adding a package, select src and alt+insert. Select package, enter the package name. Then select that package and again alt-insert. Now choose the gwt>gwt module. Give the name you think is right for your project, in my case Raffle. This step generates multiple files:
Raffle.gwt.xml - the configuration file for the module with a reference to the entry point.
Raffle.java - in the client package, this is the entry point for the gwt application.
Raffle.html - html file in the public folder that is called by the browser with a javascript that starts the gwt application.
Raffle.css - stylesheet referenced by the html file that is also in the public folder.
Everthing in the client folder is compiled to JavaScript, be sure there is nog Java 5 features in here, this is not (yet) supported. The public folder is exposed using the webserver as static files. Nothing happens to them. You can put images in here as well. Finally there is a server folder. This is in the end a plain java folder that contains the implementations of remote services. More on that later.
Step 3 - Test the setup we have created
Time to start the test. We need to create a configuration. Press alt+shift+f10 and 'edit configurations'. In the next screen add the + sign to create a new configuration and choose GWT Configuration. Give the configuration a good name. Other than that, the defaults should be fine. Now you can run the application by clicking the green run arrow or shift + f10. You can see the result in the icon on the right.
Step 4 - Adding stuff to the screen.
Step 4.1 - Add the menu
The total screen will consist of two panels, one containing the menu, the other is the content panel in which all menu actions take place.
public void onModuleLoad() {
ScrollPanel contentContent = new ScrollPanel();
MenuBar menuBar = createMenuBar(contentContent);
RootPanel.get().add(menuBar);
RootPanel.get().add(contentPanel);
}
private MenuBar createMenuBar(final ScrollPanel contentPanel) {
...
menuBar.addItem("List Names", new Command() {
public void execute() {
contentPanel.setWidget(createListNames(contentPanel));
}
});
...
}
private Panel createListNames(final ScrollPanel contentPanel) {
...
}
The code shows how to create the MenuBar and how to add an item. This is not a very thorough example and as you can see I did not implement the method createListNames. Before I do this I need to explain remoting which I will do next. The sample up till now does show how to add an a menu and how to add items to the menu. Look at the way to create a command when the menu item is clicked. By using the method setWidget on the content panel we can change the content on the page when clicking a menu item.
Step 4.2 - Doing some remoting
This is the moment Intellij will also help you a lot. Select the package where you stored your client gwt module. alt + insert will popup a menu. Select the Google Web Toolkit > GWT Remote Service. The following file will be generated when you create the RaffleRemoteService:
In the client package
RaffleRemoteService - Interface containing a static internal class App with a utility method getInstance to get a RaffleRemoteServiceAsync. Check the code later on.
RaffleRemoteServiceAsync - Interface that has the same methods as the RaffleRemoteService with one extra parameter of type AsyncCallback.
In the server package
RaffleRemoteServiceImpl that implements RaffleRemoteService and is a subclass of RemoteServiceServlet, a google web toolkit provided servlet. This servlet is also automatically configured in the module configuration file 'Raffle.gwt.xml'. The following lines are added.
servlet path="/nl.gridshore.samples.gwt.simple.Raffle/RaffleRemoteService"
class="nl.gridshore.samples.gwt.simple.server.RaffleRemoteServiceImpl"/>
Want to see some intellij magic? Let's add a method to the RaffleRemoteService for obtaining a list of names.
As you can see on the image there is an error. Intellij asks you if you want to synchronise the remote service with the asynchronous service. Click ant + enter and the interfaces are in sync again. There is more in the image. Check the return argument ArrayList. This is not a java 5 collection, gwt cannot handle that. But we do need to tell what kind of objects are in the ArrayList. This is why we need the annotation @gwt.typeArgs .
Step 4.3 - Doing some styling
You can add styling via the style sheet. Almost every widget has it's own styling and of course you can add a style name to every widget you create. Some of the basic styles are:
.gwt-Button {}
.gwt-Label {}
.gwt-TextBox {margin-left:20}
.gwt-TextBox-readonly {}
.gwt-MenuBar {}
.gwt-MenuBar .gwt-MenuItem {}
.gwt-MenuBar .gwt-MenuItem-selected {}
That is about it for now, hope this helps, you can extract the important information if you want to use eclipse. Next time I will write something about using maven2 and a special toolkit called gwt-ext. You can find the complete source code online: http://gridshore.googlecode.com/svn/trunk/Raffle/
Monday, August 20. 2007
There are many blog entries and articles out there about web service versioning. So why write another? In my day-to-day work, I am often asked about how to solve web service versioning issues. The articles on the web provide different ways to do it, but do not take the impact on the codebase, deployment and testing into consideration. Now that's exactly what I'll be trying to do in this article. First, I'll briefly describe what I mean with Web Service versioning. Then, I'll shed some light on different possible solutions. Finally, I'll compare all of these solutions in terms of complexity, codebase, deployment and testing.
Web service versioning, real or just a myth?Many, maybe even all, projects that involve web services will encounter a problem they call "web service versioning". But what is it? And does it really exist?
A web service is a piece of code, published under a more or less strict contract (WSDL and XSD), that can be called by other pieces of code across the web. This contract poses a problem, because your users depend on this contract to communicate with your application. If your request or response message format changes, it will most probably break the contract, causing your clients to send invalid messages and being unable to parse your responses.
So, if you change the contract, are we still talking about the same service? Or is it just another service you are providing? In terms of web services, it will be just another service. However, developers think in terms of code and classes. Since the major part of the codebase will be the same for the new service, we like to think of it as a new version. So, web service versioning doesn't really exist, but we want our classes to be reused. Now we've put our finger on the sore spot. Why versioning web services is an issueWeb Service versioning doesn't exist. So why is it an issue? Because developers (myself included) want to be able to reuse existing classes for new versions of a service. So, in our Version Control System (VCS, e.g. Subversion or CVS) repository weÂ?ll want to create a branch for the old version, and continue development in our main branch. We'd want to deploy our application with our old JAR and the new one and provide some mechanism for selecting either the old classes or the new ones.
That's when class loading comes in to play and ruin our day. Java isn't able to load the two different classes with the same name, at least, not in this case. It will load class com.mycompany.MyService from only one of both jars, whichever is first on the classpath. For java to accept different implementations of a same class, you'd have to do some class loader tricks.
Solutions for service versioningThe web is full of solutions for versioning. I'll mention each solution briefly, and explain how it is set up. At the end of this blog entry, I will compare these solutions in terms of codebase, deployment and testing.
1. Don't do versioning. Force clients to migrate to the newest version available.This is often tried as the first solution, but will most likely fail. Often, client applications are managed by another project, not in the area of influence of the project developing the web service provider. The cons are mostly financial: who's going to pay for the migration of the client? I'm not going into more detail on this solution, as it doesn't solve the versioning problem.
2. Deploy another EAR file containing the new version of the web service, leaving the old application untouched.In terms of development and maintenance of the codebase, this is the easiest solution. Just create a branch in your VCS for the old version and continue the development in the main branch. Since the old application is totally unmodified, it doesn't have to be tested when a new version is created. However, your deployers will have to deploy and maintain one applications per supported version.
In case of bug fixes, there is another choice to be made. Will the bug be fixed in each version, or just in the latest one. In the first case, the code has to be changed in several locations in you repository. Fortunately, today's VCS tools (e.g. TortoiseSVN) allow you to easily merge changes across branches. Then, testers have to test each modified application and the deployer has to redeploy them.
In conclusion, this solution is easy for the developers, but has more impact on testers and deployers.
3. Deploy a single EAR file, with a WAR file per versionBeware! For this solution to work, all version specific code should be placed in the WEB-INF/lib dir of your WAR file, and each WAR file must have its own class loader.
Just like the previous solution, you can create a branch in your VCS and merge changes across branches. However, a change in one version of the code will change the composition of the entire EAR file, and thus affect other versions, even if the specifications of that version haven't changed. This means that there is no way to guarantee that old versions are unaffected by changes in newer versions. This puts some extra load on the testers. The deployers however will only have to deploy and maintain a single application, regardless of the number of versions it supports.
4. Use different package names for each versionOn several blog sites, this solution is provided as "the one" to use. If you take java out of the equation, it might be very interesing, because your request and response messages are very clear about the version of the service. However, in the real world, developers use binding frameworks such as jaxb or augis. This would mean different package names (and rewriting code) for each version. This makes solution the worst of all for developers, as the entire codebase has to be changed for each new version.
I am not going into detail about this solution, because it is not a solution to the "versioning" problem. Here, we are just creating a completely new service, with all new classes. No resuse. However, do take this option into consideration for at least a few minutes. Depending on the size of your codebase, it might just not be such a bad solution.
5. Use a framework that supports advanced class loadingPeople who know me would probable wonder by now: "When will he mention OSGi"?. Well, just about now. Frameworks that implement the OSGi specification (e.g. Equinox, Knoplerfish and Felix), are able to load different implementations of the same class, and understand the difference between them. Jettro Coenradie and I have given a presentation on Web Service versioning using OSGi that the Spring 2007 conference (see http://www.nljug.org/pages/events/content/jspring_2007/sessions/00003/). We've also dedicated a website to provide information on the subject: http://www.osgisamples.com.
This solution is probably the most difficult one to implement. It is most likely that neither the developers, nor the testers and deployers have knowledge about OSGi and the impact on their work. However, if this knowledge is available to your project, make sure to consider this solution. Comparing the solutionsNow that I have mentioned each solution briefly, it is time to put them in the ring to compete against each other. Here we go: | EAR versioning
(endpoint versioning) | WAR versioning
(endpoint versioning) | Package versioning
(namespace versioning) | OSGi
(any type of versioning you like) | How the versions are recognized | By endpoint Either the EARs will be deployed on different app servers, or the WARs inside will have different contexts | By endpoint Each WAR in the ear wil have a different context (e.g. /services/v1 and /services/v2) | By namespace We're talking about different services here. The dispatching process will send each service to the appropriate class | Any way you like. You have complete influence on the dispatching process. | Complexity to set up | No specific set up to be done. Make sure to use a VCS. | Slightly complex. Use e.g. maven to build the WAR files and include the necessary versions in your EAR. Make sure version specific classes and jars are included inside the WAR. | Not complex at all to set up, but each new version will require you to create new classes or rename the old ones. Consider each new version as a completely new service in your web service dispatcher | Very complex for beginners. OSGi introduces some extra features and a different mindset than Â?normalÂ? java programming. | Impact on codebase, bug fixing and maintenance | Little impact. Keep in mind that each fixed version will have to be redeployed. Use your VCS tools to merge changes across branches. | Little impact. Each modified version will have to be rebuilt and each WAR included in the EAR file. Use your VCS tools to merge changes across branches. | Huge impact. The amount of classes will double with each version. Merging across branches is no longer possible, since class names are different. | You application will have to be set up in a modular fashion. If it already is, the impact on your codebase is small. You can use VCS tools to merge changes, since class names donÂ?t change. | Impact on deployment effort | Highest impact on deployers. Each version requires an extra EAR to be maintained. | Small impact on deployers. There is only a single EAR file to deploy and maintain. | Small impact on deployers. There is only a single EAR file to deploy and maintain. | Small impact on deployers. There is only a single EAR file to deploy and maintain. | Impact on testers | Small impact. Old versions are remained intact when deploying new versions. | Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version. | Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version. | Big impact. It is hard to guarantee that old versions are remained intact upon deployment of a new version. | Flexibility | Very high. Since versions are completely separate, changes in one version do not affect the other. | High. Because all versions share a common (EAR) class loader, there are some limitations. Especially when using native code. | Low. All versions must use the same shared libraries, as all versions share a single class loader. | Very high. The versioning and dispatching mechanism is completely configurable to your projects needs. Each version of the web service can depend on different versions of external libraries. |
Monday, July 16. 2007
Hai, today I have a short blog item. This is just because I am having fun with java generics. Check out the following piece of code. Will it compile? If you think it will compile, what will it print? If you think it won't compile, why not?
Use the comment option at the end of each blog item to give me your answer.
package generics.method.withinterface;
public interface Converter {
<E,T> E convert (T toBeConverted);
}
package generics.method.withinterface;
public class ExampleConverter implements Converter {
public <String, Integer> String convert(Integer toBeConverted) {
String retVal = "";
retval = toBeConverted.toString();
return retval;
}
}
package generics.method.withinterface;
public class Executer {
public static void main(String[] args) {
ExampleConverter converter = new ExampleConverter();
System.out.println(converter.convert(5));
}
}
After a few weeks I'll give the answer
Wednesday, July 4. 2007
My previous post was about creating a client with the spring-ws project. This dis take me some time to grasp. But without a published webservice a client is of no much use. Therefore I also had a look at the server side. To my surprise this was even easier than expected. I did have some requirements for the sample:
- wsdl generation
- marshalling/unmarshalling using jaxb2
That does not sound to bad does it? Well try to do it with axis and you'll be surprised. If you know a little bid about spring-webmvc and the use of the dispatcher, you know you need one configuration file for spring. For the webservice I had to provide the spring config file and one class, yes really, just one class. I used maven to generate the jaxb stuff and this is wat I did:
web.xml
<servlet>
<servlet-name>spring-ws /servlet-name>
<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>spring-ws /servlet-name>
<url-pattern>/* /url-pattern>
</servlet-mapping>
The spring-ws framework provides a special servlet that receives the requests. No the really hard part, the spring configuration for the endpoint:
<bean class="org.springframework.ws.server.endpoint.mapping.SimpleMethodEndpointMapping">
<property name="endpoints" ref="congressRegistrationEndpoint"/>
</bean>
<bean id="congressRegistrationEndpoint" class="nl.gridshore.samples.springws.server.JaxbMarshallingMethodEndpoint">
<property name="marshaller" ref="marshaller"/>
<property name="unmarshaller" ref="unmarshaller"/>
</bean>
<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="contextPath" value="nl.gridshore.samples.jaxb"/>
</bean>
<bean id="unmarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="contextPath" value="nl.gridshore.samples.jaxb"/>
</bean>
First check the endpoint mapping, this class SimpleMethodEndpointMapping is found by the dispatcher to map all incoming requests to endpoints. In our case we map to our only endpoint called the congressRegistrationEndpoint. This class has a special super class that needs a marshaller and unmarshaller. Other than that it needs nothing. By convention the name of the Request is used by the super class to know which method to call. In our case we have a CongressRegistrationRequest. Therefore we need to implement to method handleCongressRegistrationRequest as you can see in the following coded block.
public CongressRegistrationResponse handleCongressRegistrationRequest(CongressRegistrationRequest request) {
ObjectFactory objectFactory = new ObjectFactory();
CongressRegistrationResponse response = objectFactory.createCongressRegistrationResponse();
response.setRegistrationCode("code333");
return response;
}
In this code the argument and the return value are JAXB objects. I created the most easy method, do nothing with the request and always return the same response. Bu as you can see the code itself is very clean. I do not need to do a lot of conding. I think this is probably one of the easiest implementations I have seen that works in java 1.4 as well.
That is it for one of the requirements. Now I also wanted a solution for generating the wsdl. In the end this is only some springframework configuration. You also need an xsd, but you have already used this to generate the jaxb classes with maven. So we can reuse it. Check the following configuration
<bean id="service" class="org.springframework.ws.wsdl.wsdl11.DynamicWsdl11Definition">
<property name="builder">
<bean class="org.springframework.ws.wsdl.wsdl11.builder.XsdBasedSoap11Wsdl4jDefinitionBuilder">
<property name="schema" value="/WEB-INF/classes/congressregistration.xsd"/>
<property name="portTypeName" value="services"/>
<property name="locationUri" value="http://localhost:8080/spring-ws-sample-server/"/>
<property name="targetNamespace" value="http://www.gridshore.nl/samples/definitions"/>
</bean>
</property>
</bean>
So you need the location of the xsd, the name of the bean is used to find the wsdl. The locationUri locates the endpoint and the targetNamespace is the namespace used in the xsd. By entering the following url you can find the wsdl.
http://localhost:8080/spring-ws-sample-server/service.wsdl
You can check the code at the google code project.
I know it is pretty short, but with the code you should be able to understand it.
greetz Jettro
Saturday, June 30. 2007
Last week I attended the SpringOne Congress in Antwerp. Just one or two days before the congress I wanted to create a proof of concept for a client connecting to a webservice. I have been using the proxy way (spring-remote), but I did not really like the way this works. Therefore I was looking for something else. I stumbled upon the Spring Webservices project. I did try this out before, but not for clients. I started working and it did not look very complicated. I must admit I needed the help from Arjen Poutsma himself to make it work, but now I have a very light weight solution. I like the approach very much, therefore I will briefly describe the solution I have created. You can of course find the sources online as well. Check the google code subversion repo for gridshore.
Overview of application- Build application using maven2
- Web application build using spring webmvc
- Webservice client created using spring-ws
- Mapping between objects and xml using jaxb2 and spring-oxm
Maven 2 for buildingThis time not much details about the maven2 part. There are some things interesting though. Most important part is the creation of the jaxb generated classes using the maven2 jaxb2 plugin.
Using spring-webmv for web projectI do not think it is really interesting to talk a long time about this. There can be found a lot (better) resources online. I used the spring webmvc project to make the client i18n compatible, used the form controllers from spring to help with the error messages and validation stuff. For the webservices part the most interesting thing starts in the file service-applicationcontext.xml. This spring configurtion file contains the webservice client, the converters for jaxb (using generics to abstract the technique marshalling technique).
Webservice client created using spring-wsLet's start by having a look at the configuration:
<bean id="congressRegistrationDAO"
class="nl.gridshore.samples.springws.integration.wsclient.impl.CongressRegistrationGateway">
<property name="defaultUri" value="${cr.endpoint}" />
<property name="marshaller" ref="marshaller"/>
<property name="unmarshaller" ref="unmarshaller"/>
<constructor-arg index="0" ref="congressRegistrationRequestConverter"/>
<constructor-arg index="1" ref="congressRegistrationResponseConverter"/>
</bean>
<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="contextPath" value="nl.gridshore.samples.jaxb"/>
</bean>
<bean id="unmarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="contextPath" value="nl.gridshore.samples.jaxb"/>
</bean>
This configured class is the class that knows how to connect to the webservice. It uses a few values and classes to do it's work. The defaultUri is used to find the endpoint to connect to (we obtain it from a property file). Since we use JAXB2 to marshall and unmarshall the request we need the marshaller and unmarshaller. These (un)marshallers are provided by spring-ws as well. Actually they are provided by spring-oxm. The interface for the marshaller is the same as for the unmarshaller. The only thing you need to provide is the package where the jaxb files are generatd in. The other two references are converters used to convert the application specific components to JAXB2 components. More on this later as well. So the most important class is the Gateway class. Let's have a look at that now.
package nl.gridshore.samples.springws.integration.wsclient.impl;
import nl.gridshore.samples.springws.domain.RegistrationDetails;
import nl.gridshore.samples.springws.integration.converter.Converter;
import nl.gridshore.samples.springws.integration.wsclient.CongressRegistrationDAO;
import org.springframework.ws.client.core.support.WebServiceGatewaySupport;
import org.springframework.ws.soap.client.core.SoapActionCallback;
public class CongressRegistrationGateway extends WebServiceGatewaySupport implements CongressRegistrationDAO {
private final Converter requestConverter;
private final Converter responseConverter;
public CongressRegistrationGateway(Converter requestConverter,
Converter responseConverter) {
this.requestConverter = requestConverter;
this.responseConverter = responseConverter;
}
public String registerForCongress(final RegistrationDetails registrationDetails) {
Object request = requestConverter.convert(registrationDetails);
Object response = getWebServiceTemplate().marshalSendAndReceive(request);
return responseConverter.convert(response);
}
}
This is it, really. I show you the complete class, but in the end the most important works takes place in one line. That's the one in bold. Here we use the special webServiceTemplate class and ask it to marshall our request object and send it as a soap message to the configured endpoint. Ofcourse you can do a lot more, but for most situations this is all it takes. Do not forget to extend the WebServiceGatewaySupport class.
Mapping between objects and xml using jaxb2 and spring-oxmNot much to tell here as well. I keep saying this, but that's because it is true. We have configured the marshaller and the unmarshaller which are provided by spring-oxm. We also call the right method from the template adapter called marshalSendAndReceive. I did create an interface and some implementations that enable the gateway to be ignorand to the type of marshalling and unmarshalling we use. This is my first try to do something with generics. There can be a better way, if you know one, please let me know as well . Let's start with the generic interface.
public interface Converter {
public E convert(T toBeConverted);
}
So we have an interface specifying we have a object as a parameter and an object as a return type. Then there is a method called convert that uses these generic types. At the moment I have two concrete implementations for creating the JAXB request and handling the JAXB Response. One of them is presented below.
public class CongressRegistrationResponseConverter implements Converter {
public String convert(CongressRegistrationResponse toBeConverted) {
String response = toBeConverted.getRegistrationCode();
return response;
}
}
As you can see we now have a concrete implementation for the generic interface. The returned object is a String and the parameter is a JAXB object called CongressRegistrationResponse. Now look back at the gateway code, check that there is no jaxb reference in that code.
Again check out the code at google code subversion repo for gridshore. You can already find the code for a server implementation there as well. The next blog will deal with the server. I am also working on a sample about the Rule engine called Drools. so stay tuned.
Wednesday, May 16. 2007
We did it, Allard and I have been choosen to give a presentation at the NLJUG JSpring the 13th of June 2007. We are going to give a presentation about Webservice versioning using osgi.
A lot of companies are using or starting to use webservices and/or a Service Oriented Architecture. For each of these companies there comes a time to think about backwards compatibility and versioning. The solution is not always obvious. There are multiple options, we will discuss some of them and explain the concerns we have with them at our current projects. Our presentation deals mostly with a solution based on apache axis and the eclipse equinox implementation of the OSGi framework. The presentation uses a case of a congress registration system for demonstrating the problem of a plain webservice project. We will present our osgi based solution to the versioning problem. In a demo, we show that we can solve the versioning problem within one deployment with one ear/war file. Even better, we can do it at runtime, so no need to redeploy, no downtime. We can do an upgrade and roll it back without one second downtime. At the end of the presentation you will have basic understanding of osgi concepts. You will have the ambition to try it out yourself, that is when you take out your notes, go to our website and download all our material. This is when the real fun part starts.
Wednesday, January 3. 2007
A few months a go I was reading the website of the springframework. One article subject supprised me. I had never heard of it, OSGi. Curious enough to want to know what it was about I opened the article and started reading. The more I read the more I was certain, this is going to be the next big thing. Then in December I attended The SpringExperience in Miami and of course there was one presentation I had to attend. It turned out I was not the only one interested in spring-OSGi. Adrian Colyer gave a very interesting presentation and almost the complete interface21 team was there. They all think OSGi is going to be the next big thing. If you do a google on spring osgi you will get a lot of hits. Of course none of these is as technical as mine
If you want to read more about the event look at this blog.
Now a few weeks later I had finally found some time to experiment, and of course I want to share what I have learned. This blog item is a step by step approach of creating your own spring-osgi bundle. Later I will add some more complicated bundles with references, listeners and maybe a webserver.
So, how do we start? Well first download all code and install it using maven. Hmm, maybe I should tell you first that you need to install maven 2 and subversion. So, please install subversion and maven2. Then checkout all sources:
svn checkout https://svn.sourceforge.net/svnroot/springframework/spring-osgi/trunk spring-osgi
Than step into the root folder and do a mvn install. You can ofcourse have a look at the samples that come with spring-osgi. Please go to the spring-osgi website and see the tutorials there. We arfe going to create a new bundle using the maven archetype.
If you want to have a look at the complete source code, do a checkout from the following google code website or browse it online
svn checkout http://gridshore.googlecode.com/svn/trunk/SpringOsgiSample gridshore
Using the archetype
mvn archetype:create \
-DarchetypeGroupId=org.springframework.osgi \
-DarchetypeArtifactId=spring-osgi-bundle-archetype \
-DarchetypeVersion=1.0-SNAPSHOT \
-DgroupId=nl.gridshore.samples.springosgi \
-DartifactId=bookreview-service \
-Dversion=1.0-SNAPSHOT \
-DremoteRepositories=http://static.springframework.org/maven2-snapshots
Have a look at the generated pom.xml file and check mine. There are some things I altered that are important.
- I added the scope - test to the dependencies that did not have it
- I added the following dependencies : jcl104-over-slf4j.osgi, slf4j-log4j-full and log4j.osgi
- removed the dependecy for commons-logging
Check the pom.xml file of the provided samples by spring-osgi, that is where I got it from.
The archetype also provides a .project and .classpath file for eclipse. I had problems when I did a mvn eclipse:clean eclipse:eclipse. Some lines are not added that were in place when the files were provided by the archetype.
<buildCommand>
<name>org.eclipse.pde.ManifestBuilder</name>
</buildCommand>
<buildCommand>
<name>org.eclipse.pde.SchemaBuilder</name>
</buildCommand>
<nature>org.eclipse.pde.PluginNature</nature>
Not sure whether these are absolutely necessary. I do know a bundle within eclipse is a plugin, therefore you need the plugin nature.
Start coding
The framework of the project is in place and should compile (mvn install). Now it is time to start creating the bundle. We'll start by creating the BookReviewService, the unit test and the implementation of this service. This is pure java code, check the sources if you like. Now add a bean that we can expose as a service to the spring context file. There are two context files out of the box. You can find them in the src/main/resources/META-INF/spring folder.
bundle-context.xml : contains the normal spring configuration
bundle-context-osgi.xml : contains all beans that use the osgi namespace
We have created the spring bean myBookReviewService:
<bean name="myBookReviewService"
class="nl.gridshore.samples.springosgi.impl.BookReviewServiceImpl" />
Then we expose this bean as a special osgi service
<osgi:service id="bookReviewServiceOSGi" ref="myBookReviewService"
interface="nl.gridshore.samples.springosgi.BookReviewService" />
And now we are done, no not really. First we need to create an integration test. We use the special super class AbstractDependencyInjectionSpringContextTests. This test uses the spring config file to configure and start an application context. From the context we obtain our bean and test it to see if it works.
Alter the manifest file
Next step is to alter the manifest file, you can find this file in the META-INF folder at the same level of the src folder. You need to add an export package and the Bundle-classpath
Bundle-Version: 1.0
Bundle-SymbolicName: nl.gridshore.samples.springosgi.bookreviewservice
Bundle-Name: nl.gridshore.samples.springosgi.bookreview-service
Export-Package: nl.gridshore.samples.springosgi
Bundle-ClassPath: .,
target/classes/
Now we are ready to package our bundle. By using one of the tutorials from the spring-osgi website you can use eclipse/equinox to install and start this bundle. There is however not much to see. Wouldn't it be nice to be able to test within an exsiting osgi container whether your hard labor was wurth it? You can, the next steps will describe how you can create an in container test.
Creating the in container test
Again the framework provides a number of super classes that makes life a lot easier. I am not going to explain in detail what these classes are doing. Still I think one thing is important to know. Your test projects is being transformed into a bundle at runtime with a reference to the bundle under test. But lets start with the creation of the normal jar file that will contain our test.
mvn archetype:create \
-DgroupId=nl.gridshore.samples.springosgi \
-DartifactId=bookreview-service-integration-test \
-Dversion=1.0-SNAPSHOT \
Alter the pom, it should use the parent and have a lot of dependencies. There are two I would like to mention is special:
bookreview-service : this is our own project that we are gonna test
org.springframework.osgi.test : utilit classes for our own test class
The manifest file for the bundle that is created on the fly comes from the test/resources directory and looks like this.
Manifest-Version: 1.0
Bundle-Name: simple-service-integration-tests
Bundle-SymbolicName: nl.gridshore.samples.springosgi.test
Bundle-Activator: org.springframework.osgi.test.JUnitTestActivator
Import-Package: junit.framework,
org.osgi.framework;specification-version="1.3.0",
org.springframework.core.io;specification-version="2.1.0",
org.springframework.osgi.test,
org.springframework.osgi.test.runner,
nl.gridshore.samples.springosgi
Now we can create the test, use the ConfigurableBundleCreatorTests as a super class and implement the method to locate your MANIFEST.MF file. You also must implement a method that defines all the dependencies that can be obtained from your local maven repository. Finally you need to add your test methods.
public void testOSGiStartedOk() {
BundleContext bundleContext = getBundleContext();
assertNotNull(bundleContext);
}
This test checks if the context for the created bundle can be obtained.
public void testSimpleServiceExported() {
waitOnContextCreation("nl.gridshore.samples.springosgi.bookreviewservice");
BundleContext context = getBundleContext();
ServiceReference ref = context.getServiceReference(BookReviewService.class.getName());
assertNotNull("Service Reference is null", ref);
try {
BookReviewService bookReviewService = (BookReviewService) context.getService(ref);
assertNotNull("Cannot find the service", bookReviewService);
List bookreviews = bookReviewService.findBookReviewByKeyword("habits");
assertEquals(1, bookreviews.size());
} finally {
context.ungetService(ref);
}
}
This test first checks if the osgi service can be obtained from the bundle context. Then the obtained service is used and the result is checked. In my case we are looking for a book and if all is well we should be able to find exactly one.
Now do a mvn install on the highest level and you should have a tested spring osgi module
Conclusion
That is about it, I hope this will help some of you, do not hesitate to ask questions if something is not clear. You can find a lot of information on the spring osgi website, there is a google group and google lists about thousands of hits.
|
