techno.blog("Dion")

I mentioned in the past that we were having some problems talking to a third party service implemented in .NET.

We didn’t have control over anything on their side, and in fact were using their Java proxies (which were gen’d via Axis 1.1).

This meant that we were stuck in their RPC mode, instead of using the currently blessed document/message style.

One item that just breaks, is that .NET can’t handle multiRef’s, so to make sure you are being a good client do the following:

YourNameWebServiceLocator locator = new YourNameWebServiceLocator();

locator.getEngine().setOption(”sendMultiRefs”, Boolean.FALSE);

No more multiRefs. .NET is happy.

Lingo is a new lightweight remoting / messaging library that smells a lot like Indigo in simple ways. The main difference is that the model isn’t baked in with WS-* XML blah.

It is cool that you have control over the messaging exchange patterns, and can do things like JMX over JMS very easily.

About Lingo

Lingo is a lightweight POJO based remoting and messaging library based on Spring’s Remoting which extends it to support JMS and support a wide range of message exchange patterns including both synchronous and asynchronous message exchange.

Current supported message exchange patterns include:

• synchronous request-response (like RMI)
• one way messaging (asynchronous invocation – like a JMS publish)
• asynchronous consumption (like a JMS subscribe)
• asynchronous request-reply (allowing the server side to asynchronously send one or more replies as the data becomes available).

You can think of Lingo as being conceptually similar to both Microsoft Indigo and JSR 181 in that it allows asynchrnous method execution, remoting and asynchronous messaging to be bound to existing POJOs (classes or interfaces) though it has no particular dependency on Web
Services infrastructure.

Lingo supports pluggable messaging bindings; the first binding is an efficient JMS implementation. Over time we’ll be adding other bindings to web services frameworks and other transports.

For more details of how Lingo works and what features it offers, see the Overview or try out the Example

Read more about the new: Lingo

O’Reilly has released a CodeZoo which is meant to wrangle in the wild of opensource, and let us search through and grab components that we need.

At the moment there isn’t a huge amount of data in there, but if it grows it could be quite useful.

Where I would want this site to help is in a scenario such as:

I need a Java based CMS engine that works with X, and has feature A, B, and C

I would like to then go to CodeZoo, and have information there that would help me validate my scenario. Show me what users have said about it (especially those who have implemented something on it!) and then link me to good resources.

John Carmack, the creator of Doom to Quake to Doom 3, and plenty others… has found the pleasure that is Mobile Java. It is really quite interesting to listen in to such a low level guy, as he learns the issues that are inherent in the Java platform.

He starts off quite positively:

I wrote a couple java programs several years ago, and I was left with a generally favorable impression of the language. I dug out my old

So, it seems like Sun is starting to go the whole hog wrt OpenSource. The latest is that we hear Sun Plans To Make Java Enterprise System Open-Source.

Although their product hasn’t made a large push in the industry, the JES is certainly a full stack, including real world functionality like LDAP (as Rickard mentions).

I think it is cool that Sun is putting this all out there (and they need too), but I do wonder where they will make any money. I don’t think the future is SPARC.

The Spring Framework team has done it again ;) Their latest release (1.2 RC1) contains interesting enhancements.

The big guns are:

• Hibernate 3 support
• JMX: JMX support for export of Spring beans, annotations, and more.
• AOP: improved AOP TargetSourceCreator mechanism
• TX: transaction annotation support for JDK 1.5+

There are also some small items which I am excited about. For one, we now have a short-hand way of defining beans in properties:

<property name=”sessionFactory” ref=”sessionFactory”/>

There is also a lot of talk on using Spring with Jython:

• Rapid Web Development with Spring/Velocity/Jython/Hibernate
• Rapid Web Development with Spring/Velocity/Jython/Hibernate
• Jython Spring MVC Controllers

Spring 1.2 RC1 Announcement

Dear Spring community,

It’s Spring time :-)

I’m pleased to announce that Spring 1.2 RC1 has just been released. This release introduces a number of major new features:

* finer-grained distribution jar files, alongside the full spring.jar
* AOP Alliance interfaces are now contained in spring-aop.jar and spring.jar

* XML bean definition improvements (”ref” and “value” shortcut attributes
etc)
* improved AOP TargetSourceCreator mechanism (supporting LazyInitTargetSource too)

* transaction annotation support for JDK 1.5+ (annotation called
“Transactional”)
* improved WebLogicJtaTransactionManager (transaction names, isolation
levels)

* SqlRowSet support for JDBC (in conjunction with JdbcTemplate’s
“queryForRowSet”)
* Hibernate3 support (in orm.hibernate3; Hibernate 2.1 support is still
available)

* JMX support for export of Spring beans as managed resources and for MBean access
* Commons Attributes and JDK 1.5+ annotations for JMX MBean export

This release also contains many minor enhancements, for example:

* factored out BindingErrorProcessor strategy for ServletRequestDataBinder
* improved ParameterMethodNameResolver for Web MVC MultiActionController

For a detailed list of enhancements and bug fixes, see the changelog.

This release candidate is already considered stable and recommended for development use. We expect Spring 1.2 final to be released in late April.

Watch out for the Spring Web Flow preview release to follow later this week (for use with Spring 1.2)! Web Flow will also become part of the nightly build at that time.

Cheers,

Juergen

It is always frustrating if you have to munge a server.xml in Tomcat, or the equivilent in other servers. At that point, your nice deployable .war file requires a README that says “oh, and make sure your server.xml is setup like this…”.

At least now we have a feature that lets us put context information in the war file. I didn’t know that Tomcat supported this until recently:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Resource
auth="Container"
description="DB Connection"
name="jdbc/ebackbay"
type="javax.sql.DataSource"
password=""
driverClassName="com.mysql.jdbc.Driver"
maxIdle="2"
maxWait="5000"
validationQuery="select * from testdata;"
username="root"
url="jdbc:mysql://localhost/ebackbay"
maxActive="4"/>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>META-INF/context.xml</WatchedResource>
</Context>

AOP adoption requires a good standard aspect library.

Throughout AOSD, and indeed after the show (including on Saturday), a group gathered to discuss a new AOP library. The group consisted of the group of people named above, and other users of AOP. The first meeting discussed the scope of the project. Since we had multiple implementors (AspectJ team, and JBoss AOP for example), what could be used by both. It was really great that Bill had time to be there, as we discussed that, at a minimum, it would be good to share annotation naming/semantics. From there, pointcut language could be reused too, and potentially even more.

The bulk of the code itself will be written using the common idiom of AOP:

• Java code where possible, doing the actual work
• AspectJ code to do the thin wiring up to the Java modules

This also means that there is potential reuse outside of the scope of an AspectJ 5 library.

Rob Harrop of Spring was also key at these meetings. The library does NOT want to reinvent the wheel here. We have common issues such as configuring Aspects, and the default DI implementation will be Spring for this goal (Although, we talked about how we will also tie into hivemind, pico, and the like).

Spring also offers a lot of logic that we can reuse. Take a set of Transactional aspects for example. Spring has a LOT of code to handle transactions, from XA to Local, to Hibernate, to JTA, and beyond. We definitely want to just write aspects which USE these features.

On Saturday, the team ironed out a beginning taxonomy for the aspect library. Then we got to answer the age old question:

How many AOP experts does it take to come up with a reusable Tracing aspect.

The aspect library will be structured with two projects. One will be an incubation project that lives outside of the Eclipse foundation. Then, aspects will ‘graduate’ into the main AspectJ library itself which will be part of Eclipse.

A strong AO library will take AOP to the next level. The aim is to move people to using a lot of useful aspects, rather than thinking about writing everything from scratch. Imagine not having the Collections package in Java? We need a platform rather than just a language.

There has been a lot of interesting talk surrounding VM technology at AOSD.

JRockit Rules

Firstly, as Bill writes, the latest JRockit work is awesome. Why bother using a third party tool, when you can just download the JRockit JVM and have at it. The overhead is really meant to be almost unnoticeable, the metrics are fantastic, and the memory leak tool blows you away.

If you are on Intel, I think that you will be running on a JRockit JVM. And, they are working on other platforms too. I really want the JRockit team to do a screencast that we can put up to show you how cool this stuff is.

Microsoft Phoenix

Anders and company may be on the fence wrt AOP at Microsoft, but there were some other smart folks working on Microsoft Phoenix:

Phoenix is a software optimization and analysis framework that is the basis for all future Microsoft compiler technologies. The Phoenix framework is an extensible system that can be adapted to read and write binaries and MSIL assemblies, represent the input files in an IR which can be analyzed and manipulated by applications by using the Phoenix API and then the code can be written in binary, or JITable form for execution.

I saw a short presentation at AOSD and it looks very cool and promising.

I wonder if Sun will finally think seriously about getting AOP into their JVM ever.

With Microsoft and JRockit on the case, I think at some point they will have too. It just makes so much sense.

In fact, Sam Pullara talked a lot about AOP in the JVM in a session earlier today. It enables so many things, and will be a god-send to many of us. It will also make us think *very* differently about AOP.

Sam talked about how we will stop using the term “weaving”. At this point, we will be giving code to the VM. With AOP semantics. And it will be able to run the code correctly. It won’t be ‘weaving’ at all.

I think this is one of the reasons that many AOP-ists like to get the point across that AOP != interception, or “weaving”, etc.

Who knows how long it will take to get there, but I can’t wait.

This morning, one of the Microsoft head honchos had a high level conversation with the crowd, where he explained that:

Microsoft is a software company.

Microsoft lives to make Windows the most compelling platform.

A lot of the crowd didn’t get this. There was a lot of talk about open sourcing Windows (huh?), and porting the CLR to other platforms. They aren’t in that business. It isn’t going to happen. Mono is out there, and MSFT are watching it, and they think that it is cool the Miguel and company think .NET is cool, but that is it for now.

Since MSFT is all about Windows, they are very interested in making Java more compelling on the Windows platform. I think they are hoping that the check to Sun will help them in this regard.

I would love to see a windows.* or com.microsoft.* package which allows me to do the cool low level things that I can do in the CLR. What about Indigo from Java? Avalon with Java? etc etc.

Who knows what will be allowed here, but I would be happy to see this support, from a pragmatic perspective.

Obviously, there is an interesting tension between Microsoft wanting you to run Java on Windows, and Sun wanting to have Java as a platform to allow you to work on other areas.