All of us at bdg are very pleased to welcome the newest members of our team: Rich Weinhold and Eric Bucchere.
Rich, our resident PHP and Plumtree guru, has made his claim to fame by developing the PHP EDK, which is now available for download on the Plumtree Code Share (requires a login and password) or by contacting bdg.
Eric, bdg’s Account Manager, serves as the main POC for all of our implementations, helping customers get their issues resolved quickly and efficiently.
We’ve updated the Web site to reflect these new additions and also made a few other changes, including adding a page about our committment to open source development, which has come to fruition with the release of the Plumtree PHP EDK 5.1.
Many of our customers run Plumtree on Oracle, for better or worse.
Despite it’s complexities and eccentricities, it’s been a good platform albeit not without it’s driver issues, configuration issues and other weirdnesses.
While doing some research on running Oracle over TCPS (TCP + SSL), I discovered two excellent Oracle resources in the blogosphere:
I am very pleased to announce that on Friday, 8 July 2005, bdg released the PHP EDK 5.1 to the Plumtree Code Share. Largely due to a Herculean effort on the part of Rich Weinhold, our resident PHP and Plumtree Guru, we were able to take the com.plumtree.remote.portlet.* package from zero to released in just three weeks.
We are offering this code up for redistribution and use under the BSD License, which is the standard for the Plumtree Code Share.
In order to access the code (for now), you’ll need to create a login on portal.plumtree.com. We are currently considering other distribution methods, such as SourceForge, and we’ll make an announcement should we choose to go down that path.
We look forward to seeing some PHP portlets start to emerge for the Plumtree platform. If you’re interested in developing a PHP portlet for Plumtree, let us know — we’d love to hear from you.
Two different customers of ours have recently experienced problems with server-to-server SSL and Plumtree, so I thought I would shed some light on the issue in the hope that it might help someone else who’s having the same problem.
So, here’s the gist: in order for a server to communicate with another server over SSL, the requesting server needs to have the host server’s certificate installed in it’s keystore. Doing this is pretty straighforward and well documented. First, you need to export the certificate from the host server and copy it over to the requesting server. You can read about how to do this in IIS or how to do this in a JVM-based application server such as Weblogic or Tomcat.
After exporting the cert, you’ll end up with a .cer file that you’ll need to install on the requesting server. Say that server is a Tomcat instance on which you’ve installed Plumtree’s Collaboration Server. In this case, this set of instructions should help you get that part working.
One gotcha is that the name of the server in the certificate must match the name being placed in requests made to that server. For example, if the requesting server is making a call to https://images.mycompany.com, you need to have images.mycompany.com as the name of the server in its certificate.
If you’d like to see what people are doing with Plumtree on the open internet, you can search Google using the allinurl: portal/server.pt syntax.
Bear in mind that Plumtree portal administrators can change both “portal” and “server.pt” to anything, but most do not choose (or do not know how) to change this. Really, it’s easy — just change the
VirtualDirectoryPath and the
All of us at bdg are very pleased to announce that our very own Andrew Morris has led Wind River to a successful launch of 5.0.4J on their corporate extranet with an extremely slick and highly customized UI. In fact, the UI is so good that if it weren’t for the portal/server.pt in the URL, you seriously wouldn’t know that it’s a Plumtree Portal!
To pull this off, Andrew leveraged bdg’s extensive knowledge of Plumtree UI customization (especially pluggable navigation) in Java along with a boatload of Plumtree Content Server magic. Up until now, I thought SunTrust was the most creative Plumtree 5x deployment in terms of UI tweaking, but this one trumps it. By a lot. If you don’t believe me, take a look for yourself.
There is some interesting speculation about the future of JSR-168 going on at the Portlets Yahoo! Group. IMO (which is a redundant thing to say because this whole blog is My Opinion), I don’t think the spec is going away by any means. But at the same time, it seems that the entire industry has come to recognize it as the “lowest common denominator” of portlet functionality. In terms of features, it fails to specify portlet-to-portlet communication APIs among several other things. But worst of all, it’s designed with the presumption that the portlets will always run inside the portal container. Humph.
I also get asked this question from time to time. Unfortunately, I can’t take credit for that great little game (and one of Sun’s original sample applets for Java 1.0) because Patrick Chan wrote it.
However, the reason my name is in the source is because I ported it from Java 1.0 to Java 1.1 while interning at Sun in 1997.