techno.blog("Dion")

I am a big fan of Tapestry. One of the only items left on my list of “this bugs me” was the fact that I didn’t have the control over the URLs that I want.

I want URLs to say something, and detest any gobble-de-gook. I think it DOES make a difference.

Howard has promised that this feature will be in 3.1, and it looks like someone has done the heavy lifting for him ;)

Identitytheft911.com has written code that allows them to map URLs, so if you go to:

http://www.identitytheft911.com/resolution/crisisresolution.htm

it gets mapped into the normal Tapestry URL:

http://www.identitytheft911.com/app?service=page/crisisresolution

The explanation:

There are 2 parts: generating and interpreting.

To generate the urls, I use custom PageLink and ExternalLink components
that utilize a custom ILink implementation that generate the urls using
the following pattern:

/ .htm
The path-to-page-specification is taken from my application specification.

e.g.

specification-path="resolution/CrisisResolution.page"/>
path-to-page-specification = resolution/
page-name = crisisresolution
generated url = /resolution/crisisresolution.htm

Using lower case page names was done at the insistence of my site
developer…

To interpret the urls, I have a custom Tapestry servlet that is mapped
to the url pattern *.htm.
In my service() method, if the url query string contains “sp” (i.e.
Tapestry.PARAMETERS_QUERY_PARAMETER_NAME), then I generate a Tapestry
external link, if not I generate a page link.

Great stuff!

I saw this quote on a job posting:

WebLogic EJB, with some experience making calls on EJB’s

Yeah. making calls on EJB is the tough part! I know they TRY to make it hard with JNDI + PortableRemoteObject.narrow(..), but come on!

I guess a recruiter wrote that bad boy :)

I thought it was cool that SourceBeat (open source, new age publisher) have joined the ObjectWeb consortium.

There are lots of good products under the ObjectWeb umbrella, and they never get enough attention. Hopefully we will get some good content out of them via SourceBeat and people will see what is good.

The world of marketing is always tough. It is always hard for a european company to break into the US (especially French ;). In fact, I was just talking to Erik Thauvin about that fact! (we are both aliens living in the US ;)

After playing with Groovy and WebWork 2, Michael Henderson has written about his Tapestry-Groovy integration.

It will be really great to be able to use Groovy as the config language (instead of XML, and even maybe instead of the SDL in HiveMind), as well as for the Components and Pages themselves. Since Tapestry is such a nice OO/component view of an application, Groovy fits in nicely. Hell, we could use Groovy instead of OGNL too (if it made sense!)

The Spring Framework seems to play nice. They have their own MVC framework, yet you can plugin any that you may wish (WebWork, Tapestry, Struts [sorry], etc).

There is a similar story with AOP. Spring has its own AOP, and an intro article was just published: An Introduction to Aspect-Oriented Programming with the Spring Framework, Part 1.

However you aren’t stuck with the one AOP alternative (Spring AOP). There has been a lot of thought put into integrating with other AOP implementations.

Here Rod talks about this and AspectJ integration:

“Having said that, I believe that AspectJ is going to become increasingly important as we come to understand the full implications of AOP. So one of the major features in Spring 1.1 is AspectJ integration. This will allow AspectJ aspects to be configured by the Spring IoC container using Dependency Injection, which brings similar benefits to applying DI for classes. Both Adrian Colyer and I are very excited about this, and both Spring and AspectJ teams are working together. Support for the core AspectJ integration is already in Spring CVS and will be released with Spring 1.1 RC1 (probably end of next week). I’m also working on some samples, which will probably be released separately slightly later. The Spring/AspectJ integration opens up some interesting possibilities. Beyond that, we’re looking at using AspectJ pointcuts to target Spring AOP advice. This relies on AspectJ changes–they are going to expose an API for Spring and other tools to use at runtime. Another interesting area is implementing Spring services as “native” AspectJ aspects. Thus we’ll provide a transaction aspect, probably in the Spring 1.2 timeframe, although I might release it with the samples.”

Well, there is also support for AspectWerkz AOP with Spring via the Spring Aspect Container

The Spring Aspect Container in AWare will make it possible to manage your aspects using Spring, it let’s you treat the aspects just as any other Spring bean.
The container will read in a Spring configuration file called aware-config.xml, this file has to be on your classpath. In this file you can define your aspects, add parameters and data structures to them, pass in references to other components that is being used etc. This is for example documented briefly in the Role-Based Security section.

We are spoiled for choice :)

As my RSS reader was showing me incoming entries, I got confused and thought I saw:

Cedric Beust – EJB 3.0 is broken

Actually it was a merged viewing of two entries in a row:

Cedric Beust – EJB 3.0 at JavaOne
Cedric Beust – JavaOne’s scheduling is broken

:)

Debu Panda has written an article on Using a JMS Provider with MDBs via the J2EE Connector Architecture.

You often find that once a technology is fairly mature, changes in version don’t get as much attention, unless they are a rewrite like EJB 3 ;)

The latest versions of J2EE Connector Architecture, JMS, and MDBs make the technologies a lot nicer to use. It is great that we can write MDBs that use messages that are not JMS messages.

I also like the fact that with JMS 1.1 we don’t have the two parralel object trees of Queues and Topics. It is a lot nicer that you can use the MessageProducer/MessageConsumer which works with both point-to-point and pub/sub. Now I don’t have to tweak my client code if I change the publishing model.

A nice article…. *go to page 2 to get to the real meat*.

Scott Ferguson has written a simple blog entry that compares JDO, EJB/CMP, Hibernate and Amber.

He has simple Pro’s and Con’s for the various solutions and manages to keep it 100% technical. He stays away from the politics. Nicely done.

Regarding some of his comments:

• I don’t want my OR mapper to be passing around java.sql.ResultSets. I want to work with objects!
• JDO-QL may not be perfect, but in JDO 2 you can use other languages, such as SQL itself (but anything that you want/the vendor allows!)

Scott Ferguson reminds us to look at history, and remember the discussion on whether XPath should be its own spec, or path of one huge spec.

Fortunately XPath was seperated from other technologies that needed it… and we had great reuse, and all specs were better off for it.

Can history repeat itself here? :)

There has been a lot of buzz about JavaServer Faces. Since its release, people seem to love it, or hate it. A lot of the hatred revolves around the JSP tags that you have to work with. Hans Bergsten shows us the flaws, and then shows us, what he thinks, is a better way.

This kind of article is great. I totally agree with Hans that the JSP approach is really clunky, and have mentioned some of these reasons in the past. Just look at a fairly complicated JSF page and you will wince. Show that to a designer and they will cry.

The component model itself isn’t that bad, and Hans gets to that. JSF also really needed to lift the bar and give us some awesome components right off of the bat, rather than leaving them to the community/third parties. If they could have wowed us with amazing controls, then more people would be jumping for it IMO.

JSF: Promising
Tapestry: Today

Improving JSF by Dumping JSP

TSS Discussion on the article