Archive for the ‘Java’ Category

« Older Entries

JBoss switching to Fedora Development Model

Monday, April 23rd, 2007

Well, who can say he didn’t see this one coming. JBoss development will apparently switch to the Fedora model. That means a community edition will be developed out in the open, and releases will be made on a regular basis with less attention to backward-compatibility. Based on that subscribers will get a more stable “enterprise” version.

Hard to say if this will work out in the application server market. If you want stability and backward-compatibility, you’ll most likely have to opt for the subscription model which is probably fine with companies relying on both.

On the good side this might mean faster integration of new features into the community edition.

The switch is supposed to happen in June. We’ll see how it works out.

Technorati Tags:
,

Posted in Java | 2 Comments »

Use Burlap to build a simple Java-Ruby bridge

Tuesday, March 13th, 2007

Yes, I know, there is this great tool JRuby which will hopefully be an essential
part of the JDK in the near future, and yes there is
REST where Restlet seems to be the most promising framework,
but all I wanted is to speak with a very simple Java Interface from a Rails application.
So I thought there must be an easier way, but it has to deal with ongoing changes to the interface.
The answer for me was the Burlap protocol which you get with Spring for free.
All you have to do is to expose your Java bean with the Burlap exporter: 


 <bean id="fooService"
 	class="com.agelion.server.impl.DummyService">

 <bean name="/FooService"
 		class="org.springframework.remoting.caucho.BurlapServiceExporter">
     <property name="service" ref="fooService"/>
     <property name="serviceInterface"
     			value="com.agelion.server.FooBackendService"/>
 </bean>

. Thats it for the Java side. Burlap is a very simple protocol where you dont map classes, what you get is a map with key, value pairs. But thats fine for me.

But also the Ruby side is easy to implement. I am still a newby with Ruby but that was relativly quick done (though its still not as easy to get information like you get for J2EE for instance, where you get too much information).
Because the Burlap protocol just supports the POST method you need the low level Ruby methods for Http: 

Net::HTTP.start('localhost', 8080) do |request|
    response = request.post('/backendservice/FooService',
    	'<burlap:call><method>myMethod</method></burlap:call>')

And here we go. All you have to do is to parse this XML: 


 vals = []
 XPath.each( Document.new(response.body),
 				"//burlap:reply/list/map/*")
	{|p|  vals << p.text }

And as I said, what you get are key-value pairs with the exception of the first element which descripes the original type (classname).
I converted it to a map skipping the first element in the array: 

 @bashvals = {}
 1.step(vals.length-1, 2)
    { |i|  @bashvals[vals[i]] = vals[i+1] }

Posted in Java, Ruby | 2 Comments »

Testing with maven2

Tuesday, November 14th, 2006

While I like maven2 because of its productivity benefits now a simple task was taking me some time of research. I have to deal with some legacy code where some tests exists, but these are plain java code with main methods. I look forward to refactor them to junit tests, but step by step. So I have to tell maven what class to use and what not. For two reasons I’d like to gather them all in a testsuite. First I could start the suite easily from my IDE, and second I have another testsuite, which will require an external Corbaserver running. So I would like to seperate these tests.

There are two points to consider:

1) Because maven doesnt seem to work with suites you have to write a TestCase like this:


public class SuiteTest extends TestCase {

TestResult tr = null;

public void testSuite() {
TestSuite suite = (TestSuite) YourTestSuite.suite();
suite.run(tr);
}

public void run(TestResult res) {
tr = res;
testSuite();
}
}

2) Whereas in maven1 it was simple to configure the unit tests with the <unittest> tag, this doesnt work in maven2 anymore. In the pom.xml you have to configure the surefire plugin which runs the test. Thats not obvious for a maven1 user, so its not easy to find the right documentation. But the maven2 concept is to be more plugable. So its easier to include Testng for instance.

Posted in Java | No Comments »

EJB 2.1 Transaction Demarcation Defaults

Thursday, September 21st, 2006

In a discussion the topic of defaults in transaction demarcation for session beans I made an interesting yet somehow shocking discovery. Someone wanted to tell me that the default would be Supports (which means transactions are supported but aren’t created for the called method if none exists). Since all our session bean methods use access the database and write data this didn’t make sense. So I went through the specification, and to my surprise found not a single mention of the default transaction type to be used by the container in case the assembler forgot to specify it. Nothing on unspecified behaviours in this case either.

So the code worked until now without explicit demarcation, what gives? Seems like the JBoss default is Required (i.e. create a new transaction or use an existing one). While you shouldn’t rely on the default here, I’m rather shocked that it’s not mentioned anywhere. I browsed a few books on EJBs, searched the JBoss website, nothing except these forum posts.

I made sure the deployment descriptor now correctly demarcates the correct transaction type, but that still leaves a foul taste. So make sure you don’t rely on defaults, but declare exactly what you’d like the container to do for you.

Mind you, this changed in EJB 3.0, where Required is the default, in both annotations and the deployment descriptor.

Posted in Java | No Comments »

Java Persistence with Hibernate now in MEAP

Tuesday, September 12th, 2006

Finally, the second edition of the classic and must-have “Hibernate in Action” finally made it to Manning’s Early Access Program. The first chapters of “Java Persistence with Hibernate” are available now, with more to come. The book will of course also feature EJB3 related information.

Looks like Hibernate finally gets a worthy reference manual. As much documentation as there is, it’s still very under-documented. Hopefully the second edition fills this void even better than the first one.

Posted in Books, Java | No Comments »

Checkout Maven

Saturday, July 15th, 2006

I worked for a company where they used Maven as a standard build tool. They used maven1, but I had some spare time the last couple of weeks, so I used it to play with maven2. I read the book Maven from the Developers Notebook series and Better Builds with Maven.

First of all, why use Maven instead of Ant, which are most familiar with?

1) Its a collection of best practices of build & configuration managment: Where do I put my configuration files, how do I integrate common tools like xdoclet, clover or checkstyle, make project reports, where do I put my external jars, how to announce a new version, do the deployment and so on. When I checkout old projects of mine, which are based on Ant, I always have to look in the build.xml how and where files are copied and so on. With maven thats not the case, because everything is just at the right place. And because with Ant there is no standard build structure, every project is different.

2) Reuse: Maven has a plugin concept. Every task is a plugin which gets loaded when you use it the first time, or gets updated if there is a new version. Even common tasks like clean are plugins. So you dont need to write scripts, you just call mvn clean without having any definition of clean in your project file.

3) Productivity: you start creating a new project with mvn archetype:create -DgroupId=your.main.package -DartifactId=projectname and you get a basic project structure. You define your final archive like jar, war or ear, add your external jar dependencies to pom.xml, call mvn eclipse:eclipse or mvn idea:idea, you get your project files for your IDE and can start working within seconds. And finally mvn install compiles your code, runs your unit tests and packages your archive. All that is done without the need to write any build code. Last but not least maven2 is faster than Ant.

There is much more you get with maven for free, like cruisecontrol integration, repository integration plus reports and stats, you can run your httpunit or cactus tests out-of-the-box.

The dependency managment is great: Maven supports transitive dependencies, so if you use Struts you just add Struts to your dependencies and get all jars needed by Struts. Maven provides automatic conflict managment. And every dependency has a scope, some jars are just needed at compile time, for tests and so on. All that is nothing you have to worry about, you just add the scope tag to your dependency.

So I really believe every java developer should consider using Maven, at least give it a try and play around with it a little bit.

Posted in Java, Productivity | 2 Comments »

Fun with testing

Friday, June 23rd, 2006

I will not talk about the need for unit tests. This I would say is common sense for a modern thinking developer. I recently had to do some small changes in a project. The main developer had already left the company and I got a brief introduction. They all felt very secure because there was a testcase for every single usecase, and also for every possible error. But these were integrationtests, they wrote something into a database, sent requests per URL and parsed the result with httpunit.

So far so good, everyone was happy, but me. Why that?

Of course because there were no unit tests at all. It took me about three days to get the tests running. They used real services instead of mocks, so the tests ran just on a dedicated machine, because of firewall restrictions. The logs where analysed to ensure proper behaviour, but because they where running on an external machine, there where some shell scripts to pipe the logs to a socket. I played around for a while, even tried to use logj4 SocketAppender but failed to get the whole thing running. God knows why. So I dropped that validation. The script to run the tests swallowed every exception. The tests were running about 30 minutes, so after reading the latest news you just saw that some of the tests failed but had no glue why.

That all pissed me of, so I started writing unit tests and mock objects. One of my first tests failed and I was wondering why. I discovered a bug where two flags from an external database had been read in the wrong order. You have to know these where not just two flags nobody cared. These had been two of five values these app was evaluating, one of the reasons why this service was written. To evaluate these and to redirect the user depending on the combination of these.

WTF?! But what about the integration tests? At least they ran without an error. So after looking at the testcode, I couldnt believe my eyes: the good old boy was reversing his error and exchanged the flags at initialization time, so everything was looking fine again. I can imagine the situation, maybe he was wondering why his tests failed and thought, oh I might have exchanged the flags. So after reversing them he got the green bar.

This app was in production state for about one year and everyone was happy, but me …..

Posted in Java, Productivity | 1 Comment »

SpringOne Conference in Antwerp

Tuesday, June 20th, 2006

It was my first conference since a long time and it was a real pleasure to be there. I do Spring development for over half a year right now and I was excited to see whats currently going on. There were about 410 attendees, and we could listen to 40 presentations. But we had to choose beween four parallel talks, which was a hard decision sometimes. The slides will be published on the SpringOne site at the end of June and the DVD will be available in September. 

The biggest news was Spring 2.0 is ready to use, the final is scheduled for July. Its fully compatible with Spring 1, so no changes for existing apps. Which is great I think, and shows the big advantage of working with POJOs and AOP with loose coupling in mind. You dont destroy old code if you add more. Most of the talks had a relation to the new features included in this new version. For a complete overview click here.

At the keynote Rod Johnson told how many professionals are using Spring, even in mission critical projects like in the banking sector. There were some case studies given, and the message was clear: Spring is not just production ready, every JEE project should switch. Spring is more, its an philosophy, a commitment to agile development, to simplicity, and more or less to test driven development, because its one of Springs key points, to hold your code testable. 

It was obvious that this conference was sponsored by at least two majors namely Oracle and BEA, they even had two talks together. Both are very into JPA, which is supported by Spring since 2.0. I for myself found it funny that Hibernate was mentioned very seldom at this conference ;-) JPA should be the new one and only persistence API in the future, say goodby to JDO. The Hibernate -API will be maintained in the future, but will not developed any further. But Hibernate is on their way to support the new JSR-220, so this should be no principal problem for Hibernate users, like myself. It was news for me that Kodo is bought by BEA and Opensource as well as the core engine of TopLink, TopLink Essentials. The latter is the reference implementation for the new Java persistence API. 

Both companys are very commited to Spring, they will support Springs way to a defacto standard for middleware apps. So Pitchfork is a co-production from BEA and Interface21, an add-on for the Spring Framework for Java EE 5. Spring should provide a foundation for serveral Java Enterprise Edition 5 key components, like EJB 3 interception. But it has more features (e.g. typesafety and pointcuts for interceptors) and is more flexible.

Which leads me to another main feature of Spring 2.0, better AspectJ integration and support. The merge of AspectJ and AspectWerks was a big step forward standardizing AOP, so its great that Spring is not further going their own way. 

A not so spectacular but I think very usefull new feature is custom namespaces in Spring configurations. My last several projects were a typical SOA landscape with many small services. We had some naming conflicts in our configurations, and custom namespace is an solution. On the other hand your configuration gets more readable and less error prone if you define your own types. There are small restrictions though like just singletons are supported (which will change asap). 

The DWR Framework, an Ajax protocol layer for Java, which was presented at the very beginning, is one of the early implementers of this feature. It really does make sense to have more context aware tag- and attributenames. And with schemas you can define possible enumeration-values for instance. So your IDE shows immediatly the read line for wrong values. 

Juergen Hoeller presented the JMS support by Spring, of course including the new features like asynchronous JMS and the task executers, which can work like message driven beans in non managed environments. I dont want to go too much into detail here, but he brought some gotchas and best practices with sending JMS. The new thing is the ability to receive messages in a typical spring way. He used a SessionAwareMessageListener to send a reply message, which is a Spring style MDB. It can participate in transactions and so one. The only thing missing here is a connection pool, this you get from your JMS provider. 

The last talk I listened to was about the new Spring-WS framework, an Spring add-on. First off all, why another Webservice framework? Its key points are of course  ease-of-use and excellent Spring integration, but it focuses on document driven Webservices and contract first WSDL development. Thats a difference to XFire for instance. So you work more with XML, but its the payload XML without the SOAP stuff. To the contrary, with XFire you expose your objects. You get Marshallers and Unmarshallers of course, to parse the XML. But XML is the first thing you have got in your hand with Spring-WS. 

As I said many talks were in parallel so I missed some of them, like the clustering solution from terracota, some in depth talks about JPA, domain driven development and so on. 

Despite the landing of the new version, there are many ideas where to go in the future. Simplier configuration and better production support, like profiling and tuning and more use of JMX are some ideas. But it also depends on the community. Everyone who is interested in or even working with Spring, should regularly check and better post to the forums. 

Posted in Java | 1 Comment »

Eclipse vs. IDEA - Making the Switch

Monday, January 16th, 2006

Okay, I admit it: I’m a switcher.

I’ve been using Eclipse as a Java IDE pretty much from the beginning of my Java developing days. Well, apart from the time I developed Java stored procedures for Oracle. It was and still is a good IDE. But I remember my boss constantly telling about how great IDEA is, and that it’s making the developer more productive with a lot of little details which are hard to describe but must be experienced. Being as stubborn as I am I didn’t really believe it. I gave IDEA a look a while ago and left it at that. Then finally I had some time to get over myself and have a decent and objective look at it and to really spend some time exploring its features. And soon I was hooked. Man, what a great IDE. After a while I could really see what my boss was trying to tell me. You can’t blame a particular feature, but you really have to consider those niceties that make developer live just a little bit more productive. Together they add up, so that in the end, it really can boost your productivity. You even tend to forget the argument about the huge amount of Eclipse plug-ins. For web and J2EE development, you won’t need any. Well, except for web services. Some stuff is very different from Eclipse, but you get used to it, because most of it turns out to make you slap on the forehead and ask yourself, why nobody thought of it that way before.

I wrote about open source and the IDE market a while ago, and maybe it’s time to think again. A colleague of mine put it that way: If a particular technology is to be pictured as an iceberg, then as a vendor you can only earn money, if you’re on top of the iceberg. From time to time an iceberg will melt, and it’s close to impossible to earn money with it. If you’re lucky, there’s a little ice-cube called niche market floating about, but that’s about it. An interesting metaphor which in my opinion fits perfectly into the IDE market. IDEA is definitely top-notch in its market. The free competition is fierce, but there’s always room for someone who likes to think about a specific task that needs to be done by most developers, and how to do it right, fast and without hassle. Eclipse picked up a lot of IDEA’s features, and they’re definitely on the run (being pushed by IBM and all), but we’ll see how it turns out in the end. And no, I won’t forget to mention NetBeans which has made some very good progress since I last gave it a horribly disappointing shot more than two years ago. With version 5.0 coming up, the Java IDE market is gaining some momentum. It’s gonna be interesting to see what’s coming for the Java IDEs.

If you’re one of these people who put free cost above time and money gained a small investment, you should give IDEA a try. It’s a great IDE made by people who care about getting things done. It didn’t win the Java Developer Journal Reader’s Choice award for best Java IDE for nothing.

Technorati Tags:
, , , ,

Posted in Development, Java | 8 Comments »

Deleting a large number of objects with Hibernate (or not)

Monday, January 9th, 2006

A component of our product uses an algorithm whose calculation can result in several ten thousand objects at the worst, if not more. Creating these wasn’t the problem once it was done in small pieces. For those of you who didn’t already know: it’s not a very good idea to handle a large number of objects at a single point in time with Hibernate. The more objects you pulled out of the database with a single session, the longer it will take for them being dirty-checked. With several thousand objects you can just sit and wait, or get a cuppa coffee, and wait for the transaction timing out. Why’s that you ask?

We had a main class that was associated with several other classes. There were three associations (one with a potentially big association by itself) that could end up sticking several thousand objects together. Now, if you remove the first-class object, Hibernate will fetch the associated objects (if you configured the association to cascade on deletion, that is), thus putting them into the session cache, and start cascading them one by one. It gets worse, if you have event listeners installed. So even, if handling a single object costs about 10 milliseconds, this adds up to minutes for several thousand objects. Consider 10000 objects: 10000 * 10 milliseconds = 100000 milliseconds = 100 seconds. You do the math for more than 10000. Now that is way more time than you’d like to spend your application with deleting a single object and its children.

So what did we do? We turned to good old JDBC. We loosened the coupling between the objects concerning Hibernate and did the deletion handling by ourselves. The deletion listener for the parent object just removed all its children through simple SQL statements. That’s it. It worked, we padded ourselves on the back and went to lunch.

But what do you know, our QA ran some tests and it still took an awful lot of time to remove all those rows in the database. It was Oracle, we thought, it’s gotta do this stuff fast, doesn’t it? So it was time to roll up the sleeves and get that explain plan out. Didn’t look that weird, but then it hit me. The database made a full table scan on each child’s table. Whoopsie, that shouldn’t happen. Even though there was only one parent row in the database, and all the data in the children’s tables (around 20000 rows in each one) belonged to that one entry, it took minutes for Oracle to clean up. We forgot the simplest thing: to create an index on the foreign key column. Doh! One more time, repeat after me: “select” isn’t broken!

Hibernate 3.1 introduced a new concept called `StatelessSession`. Maybe there’s something that can be done in a similar way with it. Although it doesn’t seem to support cascading which was the primary problem we had. But otherwise it sounds quite interesting as a tool for batch processing.

So the lessons learned here deal primarily with handling a large number of objects with Hibernate. We had two solutions to this problem. The first one, during the calculation, was to split up the larger transactions into smaller bundles and calculate asynchronously in small steps. This had the nice side effect that the calculation can be clustered in the future via JMS. So try to use as small transactions as possible when dealing with huge amounts of data.

The cascaded delete was just too big to handle for Hibernate, so we used direct SQL via JDBC to handle it. That’s only one side of the story. If you don’t index your foreign key columns, you won’t have a benefit from this. So performance measures should not only include the application, but also the database if worse comes to worst.

__Update__: The Hibernate documentation actually has been a helpful fella and pointed me to some more information after having a deeper look. It seems, according to the section about performance, that it’s possible to cause a single delete by just dereferencing the collection. It’s not really applicable in the case where you have large associations again referencing large associations like the one described (you’d at least have to fetch the objects of the first level to clear their collections which results again in a huge session cache and aforementioned problems), but it’s a solution if you only have associations at a depth no deeper than one level. Thanks to Chris Conrad for pointing that out.

__Update 2__: As Gavin pointed out, there is (yet) another way. If you trust your database to do the cascading for you. The key (indeed) to this is as simple as it gets. Whenever you define an association, you simply add an attribute `on-delete`:

`


So if your database supports it and you trust it, your obviously better off letting it do the dirty work. Thanks Gavin.

Hibernate you versatile beast!

__Update 3__: Smile, you’re on JavaLobby!

Technorati Tags:
, , , , ,

Posted in Development, Java | 5 Comments »

« Older Entries