Glassfish V3.0.1 and Update Tool

When installing plugins for glassfish at work I would receive a Premature EOF just after accepting the license terms for the plugin. This would occur regardless of method used, updatetool cli, gui or web.
Strangely it worked at home, but for me and my colleagues at work, we couldnt get through. I suspect some network issue on our end but didnt need to delve too deep as I found a workaround.

The simple thing to do is to install the latest version of the pkg command. I used pkg-2.3.2 from updatecenter (http://wikis.sun.com/display/IpsBestPractices/Downloads) site.

After extracting the archive, I ran this at a command prompt (in its bin directory)
C:DevEnvpkg-2.3.2bin>pkg install updatetool

The download is strangely very slow and it timed out about three times before I could install update tool. Thankfully running the same command again resumes from where it left off.

C:DevEnvpkg-2.3.2bin>pkg install updatetool
DOWNLOAD PKGS FILES XFER (MB)
wxpython2.8-minimal 1/2 915/929 7.5/7.9

Errors were encountered while attempting to retrieve package or file data for
the requested operation.
Details follow:

1: Framework error: code: 18 reason: transfer closed with 2028 bytes remaining t
o read
URL: ‘http://pkg.sun.com/layered/collection/dev’. (happened 4 times)
2: Framework error: code: 18 reason: transfer closed with 1901 bytes remaining t
o read
URL: ‘http://pkg.sun.com/layered/collection/dev’. (happened 4 times)

C:DevEnvpkg-2.3.2bin>pkg install updatetool
DOWNLOAD PKGS FILES XFER (MB)
Completed 2/2 929/929 7.9/7.9

PHASE ACTIONS
Install Phase 1092/1092
PHASE ITEMS
Reading Existing Index 8/8
Indexing Packages 2/2

You then can simply run updatetool from the command prompt to kick off the GUI app. Downloading plugins via here was slow and timed out also, but it found my local Glassfish install and worked to install plugins to it as I needed.

Java EE, Spring, and why I care

Finally a post that seems to be sticking up for the Spring framework. (nice change)

Java EE, Spring, and why I care « techscouting through the news.

Sure EJB 3.1 does make things easier, but it has taken a lot of time to catchup to where Spring was.  And as the blogger points out, as new versions of the technologies that JEE use like JPA come out, how long will it take for JEE to implement these.

Also, one thing that does bother me with all the ‘my JEE is better than your Spring’ articles is, and the blogger alludes to here, is that they compare annotations in EJB to Springs old XML config which just like EJB is seldom needed these days.  This is a little unfair.

As for myself, I’m technology agnositic, but easily develop biases based on the path of least resistance factoring in long sightedness too.  Like many, if a tool does what I want and is scalable, I’m going to use it.  I think both approaches are fine but they aren’t necessarily compatible.  Unfortunately we aren’t unified yet although the standards are in place to get it to work (eg Spring components <-> JEE components).  Getting a Grails app to talk locally to EJB components hasn’t been easy as I learnt last week primarily due to having the app log to the right place in a container its not used to, and thats just at the container level, but thats another post.