Sunday March 23, 2008
I have seen two bugs lately, which were directly related to the GregorianCalendar:
- GregorianCalendar and XMLGregorianCalendar count the time differently. While XMLGregorianCalendar starts counting the months with ‘1′, the standard GregorianCalendar starts with ‘0′.
- If you use GregorianCalendar.HOUR, this will make the
GregorianCalendar to use a 12-hour clock, which resulted in a bug which only occured after midday.
While these quirks can be considered as must-have knowledge for a Java
developer, they still suck.
As a result of these bugs, I have started introducing Joda-time in some of projects I work on. This is probably not big news for some of you, but it seems that Joda-time is much easier to use.
What are your experiences with Joda-time?
Posted on Mar 23, 2008 at 19:50 (MET) |
Permalink |
Tuesday February 12, 2008
There has a lot of blog posting about the up- and downsides about Maven lately. As I was one of the early adopters, and probably made others to use it by writing articles in the Java Magazin about it, I am following the discussing with some interest.
On the one side, the idea behind Maven is certainly a good one. Everytime I created a build system based on good old Ant, I wished I would have been able to use Maven. On the other hand, Maven really sucks. Yes, it does. And people like Matt Raible and Don Brown who try to help improving Maven don’t make it much better. In fact, I strongly agree with Charles Miller of Atlassian, who says “Maven: Broken by Design” (btw: an excellent and entertaining read).
In this whole discussion, I personally think that the use cases for Maven should be re-thought. This would help focussing the discussion.
Posted on Feb 12, 2008 at 17:27 (MET) |
Permalink |
Wednesday January 16, 2008
I wrote about analyzing the Jetty SSL problem. Eventually it turned out, that this is not a problem of Jetty at all (there is the same problem on Tomcat). The problem in fact is related to the used algorithm for key pair generation and signature. If you use RSA Firefox won’t complain after handshake errors, if you use DSA (which is the default when using keytool) you will run into trouble.
So, it looks like this is a Firefox problem, so I have posted again to mozilla.dev.tech.crypto. We’ll see what they say…
Posted on Jan 16, 2008 at 21:36 (MET) |
Permalink |
Wednesday January 9, 2008
Over the holidays I debugged a wierd problem with Jetty and Firefox: When Firefox accesses a Webapp running on Jetty over SSL, this will result in a SSLHandshakeException eventually.
To debug this problem, I use ssltap a little tool from Netscape/Mozilla. ssltab is something like a SSL proxy and writes all SSL traffic going through it to the console.
To install it on Windows it is required to download the ZIP file provided here (Unix/Linux is here, README) and copy bin/ssltap.exe and all file from lib/ to somewhere on your path. Additionally you will need the following DLLs on your path, which can be found in the the Firefox installation directory:
nspr4.dll
plc4.dll
plds4.dll
After that ssltap should be able to start. For example, this will let ssltap listen on port 4443 and forward the requrests to port 8443 on your local machine:
ssltap -sxlp 4443 localhost:8443
In my case ssltap I was able to figured out, that Firefox sends a ClientHelloV2 after the handshake failure:
alloclen = 63 bytes
(63 bytes of 63)
[Wed Jan 09 21:07:12 2008] [ssl2] ClientHelloV2 {
version = {0×03, 0×00}
cipher-specs-length = 36 (0×24)
sid-length = 0 (0×00)
challenge-length = 16 (0×10)
cipher-suites = {
(0×000039) TLS/DHE-RSA/AES256-CBC/SHA
(0×000038) TLS/DHE-DSS/AES256-CBC/SHA
(0×000035) TLS/RSA/AES256-CBC/SHA
(0×000033) TLS/DHE-RSA/AES128-CBC/SHA
(0×000032) TLS/DHE-DSS/AES128-CBC/SHA
(0×000004) SSL3/RSA/RC4-128/MD5
(0×000005) SSL3/RSA/RC4-128/SHA
(0×00002f) TLS/RSA/AES128-CBC/SHA
(0×000016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0×000013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0×00feff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0×00000a) SSL3/RSA/3DES192EDE-CBC/SHA
}
session-id = { }
challenge = { 0×2ff5 0×68bd 0×2e11 0×903a 0xd40d 0×8809 0×86f7 0×8e0e }
}
]
This is especially wierd, as SSL v2 is disabled in Firefox 2.0. From analyzing SSL traffic and debugging Jetty I guess it seems that this is a race condition somewhere inside Jetty, which results in some response back to Firefox, which messes up the SSL session.
I have started a new thread in Sun’s JSSE forum and mozilla.dev.tech.crypto. I hope someone can help.
References:
[1] Mozilla Developer Center: Introduction to SSL
[2] Mozilla.org: Using the SSL Debugging Tool
Posted on Jan 9, 2008 at 22:14 (MET) |
Permalink |
Tuesday January 8, 2008
I always thought Apache JServ was the predecessor of Tomcat, and I bragged every once in a while about myself using Tomcat before it even was invented.
Today I stumbled across this post which told me, that Tomcat is in fact based on Sun’s Java Web Server and that JServ was ditched by Apache in favour of the Sun’s code base.
:-)
Posted on Jan 8, 2008 at 15:21 (MET) |
Permalink |
Sunday June 24, 2007
If one is designing/writing an API, s/he should take Joshua Blochs “How to Design a Good API and Why it Matters” (PDF) into account - no excuses.
Update: You can watch the presentation held by Joshua at InnoQ here.
Posted on Jun 24, 2007 at 17:03 (MET) |
Permalink |
Thursday April 12, 2007
I’ve spend hours on Maven 1 and 2, while writing articles about it. I guess that’s what you have to do, when you evaluate a tool.
However, this is the result when lead developer/product architect Charles Miller of Atlassian spends too much time:
An Open Letter to Maven 2.
Posted on Apr 12, 2007 at 20:40 (MET) |
Permalink |
Tuesday April 10, 2007
We, that is the Bosch Group’s EAI department, are looking for an EAI-developer for our global EAI platform. Location: Stuttgart, Germany. The profile is not online yet, I will post a link as soon as its available. Drop me a line, if you are interested!
Btw, understanding this joke is a must:
(from: Darren Smith)
Posted on Apr 10, 2007 at 22:19 (MET) |
Permalink |
Monday December 18, 2006
I just returned from the 1st Atlassian User Group Meeting in Karlsruhe, Germany. It was a great meeting, mostly b/c 5 Atlassians attended the meeting - even Mike and Scott (the founders).
First of all Scott presented the roadmap for Jira and Confluence. There wasn’t too much new info here, but it seems that Jira is going 4.0 next year, which will obviously be a major make over - improvements to expect: reconfigured and role-dependent dashboards, reworked custom fields which allow for field-level security. These plus the improvements released today, do make Jira to a pretty good, general purpose workflow solution - keep going Jira!
Regarding Confluence Scott provided some pretty impressive examples of customers (namely SAP and Accenture), which run Confluence for 50.000+ users. To support these large user bases the next Confluence release will provide clustering using Tangosol. Besides product news the featured some plugins one of which was Gliffy, a flash-based, online Visio replacement.
After other talks by Arne Schirmacher of Pix Software, Mike demoed the Atlassian build server Bamboo. Although I was sceptic initially (”yet another continuous integration server”), Bamboo convinced me. Setting up new projetcs is easy and straight-forward, the reporting features are comprehensive and I like the build-notifications via instant messaging. According to Mike Bamboo will be released in Q1 next year.
Crowd is a simple identity management solution to be used with Confluence and Jira. Although it seems to be a pretty simple solution, IMHO it may have potential in medium size enterprises.
After the talks, Scott and Mike took some time sit down with the users in two working groups to discuss requirements and wrote down some feature requests. That’s what I like about Atlassian’s culture - open and down-to-earth. 
Posted on Dec 18, 2006 at 20:09 (MET) |
Permalink |
Wednesday November 29, 2006
I meant to write a longer post about this topic, but as some opinion leaders are blogging about it at the moment, I’m also adding my 2 cents to the whole Spring configuration issue and tell you a little bit about XBean (my favourite configuration mechanism).
Before one decides which IoC configuration option to go, I think it is important to look at the target group. Who will create the configuration files? If your “users” have a development background, there are not many limitations - only keep in mind that most developers are lazy. 
So almost everything is better than the verbose Spring XML syntax as we know it.
If you users are more “endish” users (e.g. I think of operations people) it is very, very important to have a simple, concise and meaningful syntax. In that case, the current Spring syntax isn’t a good fit, but also the latest developments using the “p” namespace does confuse users because of using namespaces and naming conventions such as the “-ref” suffix to reference other beans (more details at Rod Johnson’s blog: “XML Syntax Sugar in Spring 2.0“).
So, what am I proposing? Well, for quite a while XBean (part of the Apache Geronimo project) has been an option, which provides functionality to configure Spring beans using a vanilla XML file.
An example: Something like this…
<beans>
<bean name="myBean" class="com.example.MyBeanClass">
<property name="greeting">
<value>Hello, World!</value>
</property>
<property name="recipients">
<list>
<value>jon@doe.com</value>
<value>scott@tiger.net</value>
</list>
</property>
</bean>
</beans>
… will turn into this …
<beans xmlns="http://example.com/namespace" >
<helloWorldConfig>
<greeting>Wazzup, World!</greeting>
<recipients>
<recipient>jon@doe.com</recipient>
<recipient>scott@tiger.net</recipient>
</recipients>
</helloWorldConfig>
</beans>
Easy, eh? I’m not going into detail here, but XBean provides an extended ApplicationContext class to process these files. The XBean Application context uses a special properties file, which contains meta-information about how to map the XML onto the beans. Usually the properties file would go into the JAR file containing the class files.
XBean offers the option to annotate properties in the bean classes, which will be configured using the XBean configuration files, so that you don’t have to create the properties files by hand. These tags are also used to create a XML schema and a schema documentation - very neat.
The downside of XBean so far has been the lack of good documentation. Craig has a good post here and maybe I get to write a short tutorial about it some day.
Update: Rod notes, that Spring provides functionality to externalize single properties to config files. In case you have missed it: I have posted about this before.
Posted on Nov 29, 2006 at 22:55 (MET) |
Permalink |
Next Posts
Previous Posts
