Jetspeed's "new API" and IBM's WebSphere 4.1 API...

[Endre Stølsvik <En...@Stolsvik.com>]

Raphael Lute: thank you very much for your tremendously helpful and
informative answers!

So..

While reading the document for the IBM WebSphere Portal v.4.1, I run into
something that I do not understand, and thought that maybe you (or someone
else here) may be able to answer:

On page 7, a Porlet is shown like an extension of PortletAdapter, which is
an extension of Portlet. I guess the latter one is meant to shown
"implements". Nevertheless, these are both from package
org.apache.jetspeed.portlet. OK. But what I do not understand, is the logic
with the next step, where Porlet inherits from
_javax.servlet.http.HttpServlet_.

Has the Jetspeed API, old or new, _ever_ had any inheritance from the
servlet specification?

Is the Jetspeed API shown in this document actually available from the
Jetspeed CVS?

This inheritance scares me! This, to me, seems like a TOTAL trashing of the
concept of a "loadable module" or "portal application" that I've found it
called here at Jetspeed. You're supposed to package the portal application
in a .war file. How are you supposed to have multiple portal applications
installed, then? Install multiple _web_ applications? But how is the
communication between the different portal applications supposed to be made?
For example, a HttpSession should not be migrated between different web
applications, according to the Servlet specs.

Given that IBM somewhat ambiguously states "The Portlet API offered in
WebSphere Portal Version 4.1 is the first step toward the Portlet API
standardization." (pg 6), I wonder about this Servlet dependency.

Jason van Zyl and David Sean Taylor: hi! Do you folks have any inside info
you can share?! ;)

Thanks,
Endre.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jetspeed's "new API" and IBM's WebSphere 4.1 API...

[Endre Stølsvik <En...@Stolsvik.com>]

A quick follow up on my own mail..

| Raphael Lute: thank you very much for your tremendously helpful and
| informative answers!

Raphaël Luta, even! ;)

but..

| This inheritance scares me! This, to me, seems like a TOTAL trashing of
the
| concept of a "loadable module" or "portal application" that I've found it
| called here at Jetspeed. You're supposed to package the portal application
| in a .war file. How are you supposed to have multiple portal applications
| installed, then? Install multiple _web_ applications? But how is the
| communication between the different portal applications supposed to be
made?
| For example, a HttpSession should not be migrated between different web
| applications, according to the Servlet specs.
|
| Given that IBM somewhat ambiguously states "The Portlet API offered in
| WebSphere Portal Version 4.1 is the first step toward the Portlet API
| standardization." (pg 6), I wonder about this Servlet dependency.
|
| Jason van Zyl and David Sean Taylor: hi! Do you folks have any inside info
| you can share?! ;)

I now believe that what IBM have done, is to require a full J2EE environment
instead of a simple servlet container. Portlet Applications are packaged as
war's, and deployed like a normal web application. But since the instance of
the _enterprise_ application is a special portal type of application, there
must exist one special portal-web-application within, controlling all the
other portlet web applications. Probably, by clever use of J2EE features,
e.g. EJBs, JNDI (?), JMX (?), and some special "spanning RequestDispatchers"
or whatever, the different web applications will be sewn together into one
portal application.

Dynamic loading of portlet applications will now have to be implemented by
the J2EE server. Good thing that most servlet containers can handle this
already.

I can not decide whether I find this VERY bad or pretty OK! ;) I hate the
overhead with the J2EE system, but there are also some cool stuff in there.

Endre.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>