Thursday, October 31, 2002

the petstore saga gets an interesting twist; open source fights back :-) iBATIS JPetStrore 2.0 in the works. Now this is what I call doing some real work and makeing Java work for you. [dsuspense] Interesting stuff. 9:28:47 PM    comment []

C# style Attributes for Java Look at Nanning. Nice one! [Joe's Jelly] This looks great. I really like the example. 2:24:01 PM    comment []

Why stateful session beans suck... An interesting article by Tyler Jewel on why stateful session beans should typically be avoided if you're using a Servlet engine. Here's another article that shows that using them is more trouble than its worth and typically have zero performance benefit. So if entity beans suck, and stateful session beans suck, all thats left of EJB thats of any real value is stateless session beans. Which is kinda like RMI with a simple transactional interceptor. Its no suprise to see that all the EJB vendors have been quietly de-emphasizing EJB and talking up web servies instead for quite some time. 12:20:20 PM    comment []

XWork, Ognl, and type conversion. XWork, Ognl, and type conversion. Today I spent some time on seeing if Ognl would be a good choice for bean manipulation in XWork. Well, things were running well until I hit two very large snags 1) Performance is the pits. I mean, Ognl is literally 25X slower than WebWork's BeanUtil method. 2) Ognl, like BeanUtil, OSCore BeanUtils, and Jakarta Commons-BeanUtils, has no way to get data in a type-specific way. This is actually more important than people tend to think. Sure, converting from input is important (setValue in all the above implementations has a way to convert data), but getting the data back in the same way we set it is equally important. Example: User inputs a date as "02/12/1982". This should be calling FooAction.setBar(Date). FooAction also has a method "Date getBar()". But when we display the data back to the user, we want to display it as "02/12/1982" or "12/02/1982" or however the user first entered it. This means that type conversion needs to happen both ways, not just for setting values. So I think I'll write my own code that does this and is tuned specifically for XWork (Ognl has too much other stuff going on, which is probably why it's so much slower). [PSquad's Corner] commons-beanutils comes with a ConverterUtils helper class for performing type conversions if you need it, which can work both directions. However  it sounds like what you really want to do is to use internationalization to convert the value into a localised String representation? If its any help, there's various JSP custom tags in JSTL for doing this kinda thing. 7:47:34 AM    comment []

XML APIs XML APIs. I am trying to get a good comparative benchmark of the current XML APIs (JDOM, dom4j, etc, etc). I was able to find this document. But seeing that it uses the v7 of JDOM and v8 claims great performance improvements I am not sure how valid it is. Any of you out there have a preference, biased by performance, on your XML API? I am using JDOM v8 right now, but am thinking of switching my code to dom4j since it seems to be fast and also has XPath built in, so I don't have to use jaxen separately to traverse my Documents. Maybe James will have some insight since he works on dom4j and jaxen. I am running into performance problems on a work project where I am needing to build an XML document (used for reporting via the web) with up to 60,000 entries (leaf nodes). I use XPath to update nodes in the tree as well. I store this document as a blob in an Interbase database, and retrieve it for viewing via the web, which uses a server side XSLT transformation of the document to HTML. I am using JDOM v8, jaxen for XPath traversal and xalan for XSLT transformation. From what I have seen so far the bottlenecks are the XPath node updates, serialization to a blob for storage, and XSLT transformation for view. [dsuspense] I'm obviously biased - use dom4j! :-) Irrespective of whatever model you use, I'd certainly recommend a few things. cache the XML parser. In dom4j this is the SAXReader. Can't remember the similar class in JDOM. Its SAXParser in JAXP. Basically reuse these things as they typically have considerable startup time. (Its the underlying XML parser that takes the time to warm up). Though only use the parser by 1 thread at once. cache the XPath expression objects. This avoids parsing the XPath expressions each time you use them do you need to parse and process the whole document in one go? 60K nodes is quite a lot. dom4j has an ElementHandler feature that allows you to process things in a 'row by row' kinda manner which if you've a large document can boost performance considerably by requiring much less RAM and having a much smaller document on which the XPaths operate. try cache the output of XSLT stylesheets as they can be expensive to run. when using XPath try to use relative rather than absolute expressions. So //foo is always gonna be slow for a large document. If possible try to refactor out common parts of XPath expressions and use variables. e.g. foo/bar/a and foo/bar/b could be refactored to create a variable bar of the value foo/bar and then reusing that for $bar/a and $bar/b. It can be tempting to use XPath a little too much... :-)  Dunno how applicable the above is but thats my general XML performance advice. 7:41:52 AM    comment []