Thursday, January 28, 2010

Lesson learned from testing new Eclipse server adapters?

I work for Oracle. It's a huge company and even bigger now from the Sun acquisition.

There are a multitude of offices around the world and even with offices many people work from home or some other remote location. My team in particular is spread out from Germany to the West Coast of the United States. We inhabit many time zones and face to face collaboration is rare; except for yearly team get-togethers or review periods where I might see my manager or other colleagues. Weekly meetings on the phone are 10 AM my time but for someone in Germany it's 6 PM or on the West Coast it's 9 AM.

When we do have interaction it is limited to phone, web conferencing, IM (whether internal or use of Yahoo IM), and VNC sessions.

We've been currently testing upgrade from one release of OEPE to another. We support many different scenarios for upgrade including server upgrade. Although not a full upgrade compared to other upgrades - because the focus is on server adapters - there are still things that need to be done properly.

Since this was my first foray into testing server adapter upgrade there were some things I needed to learn by asking my more experienced colleague. Knowledge transfer occurred over IM. Unfortunately, there were a couple of steps missing in the initial transfer since after my testing there was an issue that came up.

While testing I thought the server adapter upgrade process was a little too short. I should have listened to my instincts and maybe asked some more questions since I was not doing a full upgrade to our current BETA product.

Things that needed to be done were edit to JAR files under the plugins directory:

1) org.eclipse.wst.server.discovery
2) org.eclipse.wst.server.ui

The specific file that needed to be edited in both was: serverAdapterSites.xml

Extraneous sites needed to be removed and an internal update site for testing needed to overwrite either the Ganymede or Galileo default sites.

Regardless, if you feel your testing is a little too straightforward you might ask yourself if you're going far enough or doing the correct steps for the test to succeed; especially if you're in an isolated environment where some steps that might be easily communicated from face-to-face interaction might easily be lost through newer means of communication.

Tuesday, January 12, 2010

History of APP-INF/lib

I've been working for the last few years at BEA Systems and now at Oracle. Plenty of application development and testing has involved using projects within EARs.

I've always taken APP-INF/lib for granted and didn't look at the history of it. It was provided by BEA Systems for WebLogic Server to easily share libraries and other utility classes. among enclosed projects.

As an aside, another BEAism was the use of web services conversations (begin, continue, end) - easily mocked up with service controls. Where did that go with the new JAX-WS spec?

Going back to APP-INF/lib there was a good writeup of WebLogic to Glassfish.

http://weblogs.java.net/blog/sekhar/archive/2009/03/weblogic_to_gla.html

It will be interesting to see where it goes from here once the merger of Sun and Oracle occurs.

Exploring ELK (Elastic) Stack for hack-a-thon

At my current gig, our group finally got to do hack-a-thon week and I joined a team project that tied together a few of the technologies I&#...