JSR 168, the sucky bits
So the long awaited JSR is finally open to the public at large to ogle and dissect. Relative to other JSR’s, this one isn’t nearly as bad as it could have been. Admittedly, it’s hard to match the abysmal quality of some of those.
This is not to say it’s without its faults. For one thing, why on earth is there no instance/lifecycle management? Maybe I’m misreading things, but they seem to have adopted the servlet spec’s approach a bit too greedily. For example, lets say you found a great new portlet that allows you to view your email. Now, the people writing that portlet decide that 1 portlet == 1 mail account. You, on the other hand, are cursed with having to check 2 email accounts. The spec however will force you to deploy it twice in portlets.xml, even though the only difference is configuration data, per person. To allow for this, you would also have to use ridiculous generic names in the descriptor, like ‘Mail 1′ and ‘Mail 2′. I desperately hope I’m wrong on this one, but I see no mention whatsoever of instance management. Of course what will end up happening is that all vendors will add that feature in their own special way, rather than following a nice easy spec.
Secondly, there is no concept of scoped preferences. A preference is either global, or per user. if you foolishly want to have preferences apply to…oh I dunno…say all users that have certain permissions (or any other arbitrary custom named scope), hard luck. Off you go to peruse vendor extensions.
Of course, there’s also the unhealthy obsession with enumerations. Wouldn’t want to upset all those idiot servlet vendors and force them into the 21st century where the Collection API is both commonplace and usable by even the most retarded of developers. Heaven forbid that anyone using portlets might mistake them for not being…well..servlets.
On the plus side, portal behaviour is completely unspecified. Vendors therefore can do all sorts of crazy wacky things, thus leaving plenty of room to differentiate featuresets.
Finally, why oh why does the spec not include a list of changes against the last draft? Some of us poor bastards went ahead and implemented it, and instead of being able to peruse a list of changes and update my implementation accordingly, I’m forced to trawl through the whole tedious spec and update my test cases. Come on spec authors, if the entire j2ee spec can manage out a release history, surely you IBM/Apache buffoons can too.
Ohyeah, Jetspeed is also rubbish. What a hilarious implementation that’ll turn out to be.
July 21st, 2003 at 6:50 am
Even worse about enumerations is that the servlet spec itself has made it unnecessary to support them, with a minimum JVM version that includes Collections support.
Every spec has had room for vendors – that’s natural and probably wise. Annoying, yes.
As far as the list of changes… well, they should have one, yes. However, note that IBM and Sun are the primary drivers (according to Sun!), not Apache – which means I have far higher hopes for JSR168 than I do for some other JSRs.
Lastly… Jetspeed is open source. Fix it yourself! Actually, I’m not yet willing to say that it blows… I’m also not willing to pronounce the product name “jetspeed” in less than two minutes, since that’s about how long it takes to render a page, even after it’s been loaded and parsed. My goodness… what are they doing in there? If Jetspeed is the model for JSR168, it’s doomed – when I think of portals, I think of something FAST.
What’s more… why can’t portlets communicate?! >:(
July 23rd, 2003 at 7:44 am
About the mail portlet thing, it’d preferably be implemented to read the info about the logged in user, which is available through the API. Sure, you’d have to log out and log in again with the different user id’s you have for each email account that way, but that might be ok. If not, then it could be made user configurable to allow the user to add multiple instances with different conf at runtime. It’s certainly doable.
About the enumerations, I completely agree, and the answer I got from the spec lead when I asked was that “remove” in Iterator isn’t supported, hence… blah blah.
I’m also surprised there’s no support for instance lifecycle. Our portlets own state, which they should remove when they’re deleted but we’ll just have to do custom stuff to implement that in our own portlets (which sucks).
I’m also missing string->object preferences. Most of our portlets have some kind of JavaBean configuration, or even more complex, so the built-in string->string preferences just aren’t enough. Fortunately we can use PortletRequest.getAttributes() for such things, but it’s a “bit” of a hack.
July 29th, 2003 at 10:42 am
Even sadder are some of these portal products. It took a guy I know about a month to get the IBM Websphere portal installed and it really wasn’t his fault. They have database passwords hardcoded (e.g. “wpsadmin” has to have a password of wpsadmin). Also the install is a black art and the documentation in their setup manager is downright wrong.
September 3rd, 2004 at 2:20 pm
I’m trying to implement JSR 168 portlets on IBM Websphere 5.0.2.1
The renderResponse.encodeURL() doesn’t seem to work. it just tacks on the host and port to what I give it, example “/images/icon.gif” returns as “http://localhost:9081/images/icon_doc.gif”. Shouldn’t there be some portlet name or id in the url?
The renderResponse.setTitle() doesn’t work. I have multiple portlets in a single ap. the wizard setup a separate bundles for each portlet. I’m going to have similar strings in my portlets, so I combined the bundles. the portlet title comes from the bundles, since I combined them, the portlets show up with the same name.
is anyone else having these problems, or is it just me?
October 11th, 2004 at 12:46 pm
i can’t use “encodeURL” as well. without this my jsr-168-portlet is working fine in my WPS 5.0.2.2.
next i am trying to use this portlet in a 2nd portal as a WSRP. But this doesn’t work out. (i get the message “Exception occured” WSRP1108E)
Seems i need this encodeURL for the url’s to my jsp’s. (http://www-900.ibm.com/developerworks/cn/wsdd/download/pdf/0403_hepper-JSR168_BestPractices.pdf p.13)
anyone here who is having more success than me?
would be nice to exchange experiences.
October 13th, 2004 at 2:47 am
Hi,
You can diplay an image in JSR 168 portlet as
Plz let me know if u have any doubt..
Bye