Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Friday, April 2, 2010

OS X 10.6.3 and GWT 1.x

Safari 4.0.4, when it came out, had an issue with respect to GWT development, causing the GWT hosted mode browser to crash on load. As a result, I didn't take the Safari 4.0.4 update. When Safari 4.0.5 came out, reports indicated that it wasn't any better, despite the fact that some of the interim builds of WebKit had been used successfully, so I didn't take that update either.


Unfortunately, I did take OS X 10.6.3, which apparently came down with Safari 4.0.4 and broke my GWT development environment. I tried upgrading to Safari 4.0.5, but had no success. Eventually, I settled on the workaround that others were using with the WebKit nightly build (comment #22 on that issue) which seems to have solved my problems.

I did also briefly look into upgrading my current project to GWT 2.0.3; seems like it works pretty well, but we're coming up on a release point and it's an awkward time to do a framework upgrade. I'm hoping that by broadcasting this, some of you will avoid this same path.

Monday, January 25, 2010

Composite Event Handler Registrations in GWT

In my previous entry, I wrote up a class for displaying Input Prompts in GWT. As I started to fold that code into my project, I realized that I didn't expose the handler registrations, which would make it impossible to remove the event handlers if and when the text fields for which input prompts were displayed were created and removed during the lifecycle of the application.

Because the Input Prompt registers handlers for both Blur and Focus, there are two registrations. It's not easy to return two values from a single method, and frankly, I don't think a class using InputPrompt should have to know or care what events it's employing in great detail. As a result, I've created a composite event handler registration to return:


package com.codiform.gwt.event;

import java.util.ArrayList;
import java.util.List;

import com.google.gwt.event.shared.HandlerRegistration;

public class CompositeHandlerRegistration implements HandlerRegistration {

private List registrations;

public CompositeHandlerRegistration() {
registrations = new ArrayList();
}

void add( HandlerRegistration registration ) {
if( registration instanceof CompositeHandlerRegistration ) {
CompositeHandlerRegistration composite = (CompositeHandlerRegistration) registration;
registrations.addAll( composite.getRegistrations() );
composite.clear();
} else {
registrations.add( registration );
}
}

private List getRegistrations() {
return registrations;
}

public void removeHandler() {
if ( registrations.size() > 0 ) {
for ( HandlerRegistration item : registrations ) {
item.removeHandler();
}
clear();
} else {
throw new IllegalStateException( "Composite handler registration is currently empty, and cannot remove handlers." );
}
}

private void clear() {
registrations.clear();
}

}


If a composite handler registration is passed to another composite handler registration, I flatten them; this might be unnecessary. In the spirit of YAGNI, I won't be at all unhappy if you decide you don't need that capability. I also decided I preferred to clear my local references to any inner handler registrations as soon as they've been removed, rather than hanging on to them indefinitely.

All in all, this is pretty simple GWT code, but seemed worth following up on the previous entry to talk about the need for handler registrations.

Friday, January 22, 2010

Input Prompt Pattern in GWT

For a GWT project I'm working on, I've reached a point where I wanted to apply input prompts to a text box; this doesn't seem to be something that's built in to the basic GWT framework, or an easily-located extension. For that matter, I couldn't find anyone who'd done it and blogged about it, although it might be that they've used different terminology.

I thought it was worth a quick experiment to see how easy they would be to apply, and this is what I came up with:


package com.codiform.gwt.widget;

import com.google.gwt.event.dom.client.BlurEvent;
import com.google.gwt.event.dom.client.BlurHandler;
import com.google.gwt.event.dom.client.FocusEvent;
import com.google.gwt.event.dom.client.FocusHandler;

public class InputPrompt implements BlurHandler, FocusHandler {

private String promptText;

public InputPrompt( String text, TextBox... inputs ) {
this.promptText = text;
for( TextBox item : inputs ) {
apply( item );
}
}

public void apply( TextBox input ) {
input.addBlurHandler( this );
input.addFocusHandler( this );
applyPrompt( input );
}

public void onBlur( BlurEvent event ) {
TextBox blurred = (TextBox) event.getSource();
applyPrompt( blurred );
}

private void applyPrompt( TextBox input ) {
if( input.getText().isEmpty() ) {
input.setText( promptText );
input.addStyleName( "inputPrompt" );
}
}

public void onFocus( FocusEvent event ) {
TextBox focused = (TextBox) event.getSource();
if( promptText.equals( focused.getText() ) ) {
focused.setText( "" );
focused.removeStyleName( "inputPrompt" );
}
}
}


The final version has some project-specific tweaks (interface for the textbox to make this code testable with mocks, a style name in the project namespace), but for the most part the above code seems to do the trick well and I'll be applying it shortly.

Friday, December 11, 2009

Maven Growl

I've written up a small script for displaying Maven build notifications using Growl, and put it up on Github.

Monday, July 6, 2009

Fixing Hessian Flex 3.2.0 References

If you're using Hessian Flex 3.2.0 and you'd like to fix the problem with references, the following one-line fix seems to do the job for me:


$ svn diff
Index: src/main/flex/hessian/io/Hessian2Input.as
===================================================================
--- src/main/flex/hessian/io/Hessian2Input.as (revision 1172)
+++ src/main/flex/hessian/io/Hessian2Input.as (working copy)
@@ -129,9 +129,10 @@
public override function init(di:IDataInput):void
{
_di = di;
_buffer = new ByteArray();
_offset = 0;
_length = 0;
+ _refs = null;
}


Basically, HessianOperation hangs on to a Hessian2Input class between invocations, and calls init() to clear out the state before using the class for another invocation. The init() doesn't currently clear the reference cache. By setting _refs to null, you clear the cache and Hessian2Input will simply instantiate a new array in its place if and when it needs to do so.

Monday, June 29, 2009

Dependency Trap - Hessian, Spring, Tapestry

A project I'm doing some work with is using Hessian, Spring and Tapestry, and we've just discovered that we're deep in a dependency trap, as follows:

  1. Hessian, a binary remote-invocation protocol written by Caucho, avoids cycles and reduces bandwidth by only serializing objects once per request by using object references. Unfortunately, hessian-flex 3.2.0 and below have a problem with references such that they have a tendency to point to the wrong object. (See: my initial report of a bug in references, confirmation of references bug).
  2. There's a new version of hessian-flex, hessian-flex-4.0.0, which solves this reference problem, but it's only compatible with hessian-3.2.1 and above. (See: hessian-flex-4.0 posted)
  3. Hessian-3.2.1 and above do not work with the Spring Framework's remoting framework in Spring 2.5.6; there's been some motion to resolve this in Spring 3.X, but that may not be complete. Further, hessian-3.2.1 itself has a bug. (See: summary of the current state, spring-framework bug for supporting later hessian versions, hessian null-pointer bug)
  4. Tapestry-spring, which integrates the spring framework's context into Tapestry's IoC, apparently doesn't play well with Spring 3.x. (See: T5.1/Spring/Antlr issue, another issue I posted myself, but which isn't yet in the list archives).
So, we can:
  1. Continue with the dependencies we have, which leave us with broken hessian references.
  2. Upgrade to a newer hessian-flex, which requires a newer spring framework, possibly one that isn't even made yet, and which isn't compatible with Tapestry.
  3. Fix hessian-flex-3.2.0 ourselves to avoid the reference issue.
  4. Write our own hessian remoting (or patch existing) for springframework 2.5.6 to export services using hessian-3.2.1.
  5. Fix tapestry-spring to work with Spring 3.x.
  6. Abandon hessian in favor of Spring-BlazeDS.
  7. Other equally painful choices, probably.
It's always nice to have choices.

Thursday, June 25, 2009

Flex Builder 3 on Eclipse 3.5 (Gallileo) on OS X?

I spent a little time this morning trying to get FlexBuilder 3 up and running in Eclipse 3.5 (Gallileo). A little experimentation and reading implied that getting it up in the Cocoa version of Eclipse wasn't going to happen.

I then tried a few more times with Eclipse 3.5 carbon, and still wasn't able to get it working. So if you've managed to get FlexBuilder 3.X up and running on Eclipse 3.5 on OS X, I'd be happy to hear more.

Tuesday, June 23, 2009

Caucho's OSGi Pains

Earlier this month, I commented on Atlassian's OSGi experiences, and how it seemed that most of these experiences recount the pain of getting up-close-and-personal with OSGi. I've just noticed that Caucho has a similar tale of woe; they considered using OSGi within their application server and eventually rejected it, at least for the time being.

Now, you could of course argue that this a way for Caucho to explain the lack of OSGi support within their application server. I'm not trying to position their tale in any way. I don't have enough OSGi experience to agree or disagree with the points they raise, I'm just trying to synthesize from the experiences of others, and that seems to come down to this:

If you read detailed adventures of people's experiences with OSGi, it seems to come with a fair amount of pain, so keep that in mind when you're looking at OSGi for your own purposes.

Thursday, June 18, 2009

Java for OS X Update 4, Java Preferences and JAVA_HOME

Java for Mac OS X 10.5 Update 4 is out, and if you're on Mac OS X 10.5, you should install it as soon as possible; it patches the serious vulnerabilities that existed in Java for OS X before that.


However, if you're unfortunate, installing this will also mess up your ability to run different versions of Java. On OS X, the version of Java you run by default can be controlled using the Java Preferences panel:


Unfortunately, I quickly discovered that this was no longer true on my system. Although Java 1.6 was heading up the pack, Java 1.5 seemed to be the VM of choice when compiling and running Java code. And since I'm on a project that's using Java 1.6, this was a serious problem.

Changing the value in the Java Preferences application had no effect. Neither did rebooting. I briefly considered reconfiguring the Java setup using softlinks, but it seemed like that was a last resort as it would be further breaking the Java preferences panel. I did some digging and didn't find very much at first.

Eventually I discovered this post on Apple's "java-dev" mailing list talking about changes to the way JAVA_HOME works on OS X, and started experimenting. I discovered:
  • The value of JAVA_HOME was pointing to Java 1.5 on my system.
  • Altering JAVA_HOME had an immediate and significant impact on what version of Java was used to run 'java' or 'javac' by the executeables that were softlinked by OS X.
  • The output of the new 'java_home' command was influenced by whatever went into the Java Preferences panel.
Accordingly, I did as the mailing list suggested, and set JAVA_HOME to `/usr/libexec/java_home` and voila, everything seems to have resolved itself. If any of you run into this, hopefully you'll find success with this solution as well.

. In order to better support JAVA_HOME in OSX there have been some changes. Out of curiosity, I switched the order of the JVMs in Java Preferences and ran the new 'java_home' command and the results would change. I also tried changing the value of the JAVA_HOME environment variable, which immediately affected which version of Java would be run by the 'java' and 'javac' commands.

I'm guessing that I had a JAVA_HOME setting already, pointing to Java 1.5, and it was this value that was overriding whatever was in my Java Preferences. Adjusting JAVA_HOME to be the result of the java_home invocation seems to have solved my problems.

I'm hoping that by posting this I can save some of you the same pain.

Wednesday, June 10, 2009

PHP Considered Harmful

I noticed this morning (via @PeterBell) that PHP was getting a goto statement in v5.3. Some would argue that the Goto statement has been considered harmful since the late '60s, if not before.


Monday, June 8, 2009

OSGI Case Studies == Pain

Every time I see someone give both sides of their OSGi tale, it reminds me a lot of my EJB 1.x experiences, and I remind myself to stay away unless I absolutely have to.

At QCon (2007?), I saw a presentation on Spring Dynamic Modules. They pointed out some of the issues you might have with OSGi and how Spring DM might help. Mostly, it made me want to avoid OSGi.

I've just quickly skimmed Atlassian's presentation on how they've used OSGi for their plugin architecture, and while I'm sure it has provided them with benefits, and it may be worth it for their needs, my key takeaway is still, "stay away from OSGi unless you have no other choice."

Basically, just looks like it's going to come with a fair amount of pain, so you'd best know in advance that you absolutely need the benefits to offset the cost.

Lift Book Outsells All Other Web Frameworks at JavaOne

It's interesting to review the top sellers at the JavaOne bookstore. Seems to break down like this:

  • Two JavaFX books, at #1 and #2. Considering how few people I know who are interested in JavaFX, this feels like a stuffed ballot box to me, but, what the hell, I'll give it the benefit of the doubt. Maybe people were impressed with JavaFX at the conference.
  • Three scala books, at #5, #8, #9. Interesting that 'lift' was the only web framework whose book made the top ten, unless you want to count the Java EE book (I don't).
  • Four core Java and Java EE books at #3, #4, #6, #7. Not really shocking for a Java conference.
  • One solaris book.

Sunday, May 3, 2009

What's New in Eclipse 3.5: Milestone 7

Milestone seven of Eclipse 3.5 is out, and it solves a long-standing annoyance for me with Eclipse, which is that you switch between editor tabs with Ctrl-PgUp and Ctrl-PgDown, but in a multi-tab editor, you switch within the editor with the same keystroke. This leads to weird behaviours like when you want to switch from a Java tab to another Java tab but pass through an XML tab with design/source view and get "trapped" because the keystroke you were using no longer lets you continue.

It also looks like support for cocoa on OS X continues to improve.

Monday, April 13, 2009

What's New in Eclipse 3.5M5?

Eclipse 3.5 M5 is out, and as this cycle winds down, the changes are getting less significant.

I like the way they're planning on highlighting matching characters in the Open Type dialog:
It's also nice that they'll be offering an Open Implementation hyperlink:

Tuesday, March 3, 2009

Generating Flex HTML Templates with Flex Mojos in Maven

Since I'd managed to reach a base level of comfort with Flex Mojos fairly quickly, we decided to see how hard it would be to extend it the rest of the way. As it turns out, not terrifically difficult.

I wasn't willing to disable the working FlexBuilder-integrated build that would take the results that FlexBuilder would generate from target/bin-release and include it into an assembly, so I took a little time to use a dual-profile approach to setting up the assembly:


<profiles>
<profile>
<id>flex-mojos-assembly</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>flex-mojos-assembly.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</build>
</profile>

<profile>
<id>flex-builder-assembly</id>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>flex-builder-assembly.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>


This gave me the freedom to continue working on integrating Flex Mojos approach without breaking what was already in place, particularly since we haven't thoroughly gone over the SWF that Flex Mojos generates. If I want to build an assembly with the SWF that flex-mojos generates, I simply run the build. If I want to use the release build from FlexBuilder, I run the same build but turn on the flex-builder-assembly profile (which automatically takes the other profile out).

Now, this approach doesn't take Flex Mojos out entirely; it just ignores the results of the flexmojo compilation process if it isn't being used. This is a little wasteful, so I may come back and revisit that approach later. For now, it's a lot less complex than trying to remove the flexmojos integration entirely, which is done through a parent POM approach.

After that, it was a matter of generating the HTML using the local custom html template by adding this to the flex-mojos-assembly profile:


<plugin>
<groupId>info.flex-mojos</groupId>
<artifactId>html-wrapper-mojo</artifactId>
<executions>
<execution>
<goals>
<goal>wrapper</goal>
</goals>
<configuration>
<targetPlayer>9.0.124</targetPlayer>
<templateURI>folder:html-template</templateURI>
<outputDirectory>${project.build.directory}/html-template</outputDirectory>
<parameters>
<bgcolor>#ffffff</bgcolor>
<!-- Defaults Follow -->
<!--
Version comes from 'targetPlayer' or '9.0.0' if no targetPlayer.
<version_major>9</version_major>
<version_minor>0</version_minor>
<version_revision>0</version_revision>
<swf>${project.build.finalName}</swf>
<width>100%</height>
<height>100%</height>
<application>${project.artifactId}</application>
<bgcolor>#869ca7</bgcolor>
-->
</parameters>
</configuration>
</execution>
</executions>
</plugin>


And setting up an assembly descriptor to pull in what I needed from the project structure and the results of the generation:


<assembly>
<id>flex</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<files>
<!-- SWF -->
<file>
<source>${project.build.directory}/${project.build.finalName}.swf</source>
</file>
</files>
<fileSets>
<!-- HTML Template -->
<fileSet>
<directory>target/html-template</directory>
<outputDirectory />
<includes>
<include>**/*</include>
</includes>
</fileSet>
<!-- Project Resources -->
<fileSet>
<directory>src/main/flex</directory>
<outputDirectory />
<includes>
<include>assets/**/*</include>
<include>images/**/*</include>
<include>*.html</include>
<include>*.mp3</include>
</includes>
</fileSet>
</fileSets>
</assembly>


This gives me a final assembly that looks a lot like the assembly the project was already generating. Now to find out if it works the same way ...

Building Flex with Maven and Flex Mojos

I've been getting to know a project that uses Maven and Flex.  The flex portion of the project is currently built using FlexBuilder, and it seemed worth investigating whether or not buildng the Flex using Maven were feasible.


I took a look around at the options, and it seems like the Flex-Mojos project is the one with the most momentum.  It's relatively current, gets updated regularly, and the team seems to be working with Sonatype, well-known in the Maven community.

The Flex Mojos project is still pretty rough in some areas.  In order to get things done, you need to search the blog, the google group, the google code home and the newer wiki and source code repository hosted at Sonatype, as well as the plugin documentation.  I'm hoping that with a little more time, the documentation will start to coalesce in a single location and get better, although sparse documentation is par for the course when it comes to Maven plugins.

With a little work, I was able to get the project to build an SWF file:


<parent>
<groupid>info.flex-mojos</groupid>
<artifactid>flex-super-pom</artifactid>
<version>2.0</version>
</parent>

<repositories>
<repository>
<id>flex-mojos-repository</id>
<url>http://svn.sonatype.org/flexmojos/repository</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>

<build>
<plugins>

<plugin>
<groupid>info.flex-mojos</groupid>
<artifactid>flex-compiler-mojo</artifactid>
<configuration>
<sourcefile>CrystalQ2.mxml</sourcefile>
</configuration>
</plugin>

</plugins>
</build>

I also needed to declare a dependency on the SWC library on which the project depended:


<dependencies>
<dependency>
<groupid>com.caucho</groupid>
<artifactid>hessian-flex</artifactid>
<version>3.2.0</version>
<type>swc</type>
</dependency>
</dependencies>
There's still other things I'd need to do to mimic what Flex Builder offers, such as generate an HTML Wrapper and copy assets needed by the final application but not included in the SWF.
That said, I'd say that the basics are already in place and I'm starting to feel comfortable that there are options for putting Flex and Maven together, should you so desire.

Tuesday, February 24, 2009

Maven Resource-Filtering Escapes Backslashes

Having moved up to Maven Resources Plugin 2.3 in order to stop Maven from attempting to filter some binary files for us, and in so doing, destroying them, we've discovered that 2.3 has its own problem -- it escapes backslashes and colons in files where escaping is totally unwarranted, which does a surprisingly good job of destroying an XML file we need for Selenium and Java Web Start to play nicely together (a mimetypes.rdf that tells Firefox how to deal with a JNLP file).


Three cheers for Maven, an ecosystem of tiny plugins, each of which has its own set of bugs and idiosyncrasies, which collaborate to ensure that there's no valid way to build your project.  Whee.

Friday, February 13, 2009

Are We Ready for Bespin?

It's interesting to finally see what's going on in Mozilla Labs around Bespin.  It's an interesting idea, making a web-based development environment.  It's been tried before, but I'm curious to see it develop and see how far they can take it.  


What they have already seems promising, but it's a long way from replacing a desktop application for me at this stage.  Still, with enough persistence and enough time, there are undoubtedly some things a web-based application could do that would be difficult for a desktop application to mimic.  We'll see what happens.

I'm not sure developers are ready to move their development environment into a browser.  More specifically, I'm not sure that it will be possible to create a compelling, seamless enough web development environment.  But if it can be done, these are some of the people I'd like to see working on it, so I'll keep my fingers crossed and keep my eye on Bespin as it evolves.

Productivity and Pair Programming

I'm with Raganwald on the productivity issue. I don't feel like I can measure my own productivity or that of other developers, and I don't think anyone's made a really conclusive argument either direction about the productivity of pair programming, although I will say that there are times when I've found it very useful and times when I've found it a little irritating.

And, frankly, I think a good chunk of productivity studies are bunk anyway. The idea that we can measure and suggest that we're 36% more productive than people X years ago seems to be making claims about precision that aren't supported by any kind of useful data.

But what I will say is that despite the lack of a good productivity measure, I suspect that both a single developer and a developer-pair are more productive than any group of developers who are arguing about productivity instead of writing code.

On that note, I think I'll go write some code.

Thursday, February 12, 2009

Bean Validation Public Draft

Sounds like Bean Validation has been voted through the public draft stage. I've just finally managed to get my voluminous feedback into the appropriate hibernate forum after wading through the spec.


Mostly, it looks reasonable, although I'd prefer to skip the bootstrapping entirely, or alter it pretty significantly so that it doesn't remind me of Why I Hate Frameworks.

I'm also not sold that we really NEED a JSR for this until there are multiple competing and incompatible implementations that take on validation seriously, which isn't currently true, IMO. Although I've used Hibernate Validator before, I'm not sure one implementation justifies a JSR.

But anyway.