Like a good Tier One Sun Partner we opened a support ticket. Typically, the support process is a long arduous process of describing the problem, sending logs and hoping you can get the ticket escalated. To be fair to the first level support teams, 9 times out 10, due to the complexity of the problem, we need to talk to a product engineering support person to describe the context of the problem.
As with most customer situations, just opening a ticket with support isn’t enough. Our client is usually in a critical support state. The clock is ticking. We need a solution…But this time…Guess what! We found the fix ourselves!
How did we do this? One of our talented engineers (Vince) went to OpenPortal and looked over the source for the psadmin “deploy” command. To our pleasant surprise, Vince identified this tricky little bug. The code read such that deploying to 2 nodes within the Portal instance would work fine but more than 2 nodes would not.
So, Vince modified the code, recompiled and tested our fix. It worked!! Real Nice!
We contacted Sun support with the fix and boy they were exhilarated. What a win/win situation. We delivered a critical bug fix to our customer’s project and the change rolls back into OpenPortal as a supported fix.
Not only did we collaborate with the Open Portal project to diagnose and build a fix, but we supplied the source changes with the ticket. It was quick work from that point for Sun to close the ticket and work on a hot fix (to be rolled into the next formal release). More importantly, the fix is supported!
This all made me think back to a conversation I had with Jonathan Schwartz a couple years back. Specifically I was commenting upon the Sun support model and the challenges we faced in the field with extending and fixing the products. I said something to the effect “I don’t want to own source to your products John, I just need to be able to fix something that will help the customer, but more importantly make it’s way back into the product”. Well our wish has come true.
Open Source changes the escalation process. If you have folks that are talented enough to navigate the product code base, interpret the functionally and recompile the code, you have a tactical advantage. Typically you’d work the forums and support process for a couple of weeks with mixed results. Now, in most situations you can by pass layers of support and shorten the patch process. Win / Win in my book.
After all, what good is Open Source if it’s not supported?
]]>Our second game, we also won, but it was pretty much a blow out. We won 6-0 and I scored 2 goals. One of them I was trying to pass the puck, but it hit off one of the other teams players and went in. I think that that game was our best game of the tournament because we worked as a team and had a lot of fun.
Finally the guys rounded it out with 2 straight victories over Michigan 7-2 and 4-1 to seal the deal. Great work guys!
]]>
NOTE: As depicted in the next image, I’ve found it a best practice to append “opensso” to the default “Configuration Directory” value. As my previous cleanup instructions are based upon this. If you’ve used the default value you’ll still find an “opensso” directory. In addition you’ll need to find the “AMConfig.properties” and “serverconfig.xml” files to delete too.
]]>
Here is Peter after the game.
Hearing about a great team victory makes it all worth while.
]]>
To say this was completely simple is an over statement. You definitely need to cut some JavaScript and CSS code. But what intrigues me is that my learning curve was the toolkit and not making this cross browser capable (tested with IE 6, 7, Opera and Firefox). Also, I was able to complete this widget with about 10 lines of code. Very impressive! Lots of good examples out there too a good sign of a well adopted toolkit. One can quickly surmise there is an excellent foundation of AJAX and JavaScript here.
Now the techi stuff… In the process of creating this widget I came to a dilemma where I needed to serialize a series of Effects. Basically I needed to make sure my menu control was done hiding before showing the new menu. (try selecting Search then Subscribe)
Through a little research I deduced two resolutions.
Resolution A - Use an afterFinish callback
new Effect.SlideUp('inner-search', { afterFinish: function() {
Effect.SlideDown(elem); }
} );
new Effect.SlideUp('inner-search');
Effect.SlideDown(elem, {queue: 'end' });
There are many ways to skin a cat, right. Here is how I made my choice. Resolution A a) Complex code b) 2 effect limit Resolution B a) Simple code b) Ability to queue up N number of effects
Recommendation: Go with Resolution B. To wrap, I will create more data points for myself but, script.aculo.us is indeed cool!
]]>Beyond nice Ant build file creation, integrated Unit testing and all the good IDE coding features, we now have Subversion support. And it really works too. (Now I hope Sun will get rid of the requirement for the native SVN client) This was the tipping point for me. So if you’re considering a second look at NetBeans I’d say it’s ready.
With that said I hit a little snag when first trying Subversion.
The SubVersion add-on creates a config directory that caches your Subversion server settings. In our case we had hit a proxy to reach our SVN repository (which went away). So, long story short. If you’re hitting a “PROPFIND” error while using NetBeans you may need to delete or examine the files file in the ~home\.netbeans\config\svn directory, restart NetBeans and try again.
]]>Following the sage information provided by Kim Cameron and Chuck Mortimore I’ve implemented an authentication Plug-in (called a CardSpace AuthModule) for OpenSSO. Quite simply an end user can use their own InfoCard to authenticate against the OpenSSO security System. What good would an InfoCard be if you can’t authenticate it anywhere??
Below is the use case from the CardSpace docs (I borrowed this picture from Kim’s site hopefully not a problem) that we’re satisfying. I’ve implemented the authentication mechanism required at the Relaying Party (the party consuming the InfoCard) as an AuthModule for OpenSSO.
Once OpenSSO consumes (validates and more) the InfoCard token we can gain access to an otherwise protected site (which OpenSSO is protecting). The InfoCard Token is used as a credential instead of the classic user ID and password. This is good!
Besides the fact OpenSSO is really good at protecting web resources. By implementing the CardSpace authentication by extending OpenSSO we gain an enterprise service as among all the services offered by an access management system. Just to beat the horse here an Access management system is the right place to create this. Not in every application the wishes to use CardSpace.
So on to the good stuff. Here is the flow diagram. Hopefully this is self explaining.
To setup these screenshots just pretend you’re accessing a protected site that is allowing you to use your InfoCard instead of user ID and password. But, at first we don’t recognize your InfoCard so we’ll ask you to authenticate and then link your InfoCard to the existing user Identity. So, after you link your card can use that for all subsequent accesses to this protected website. It so happens I’ve built these functions into OpenSSO (my security system).
Well there is much more to talk about. I’ll save that for next time. I’m still figuring out a method to release and package this. If you’re interested in more details please shoot me an email. martin.gee at icsynergy.com. Thanks again to Kim, Chuck and others that have posted good details regarding CardSpace.
]]>