[Moving the thread to Jetspeed Dev]
> >My problem is that is seems impossible to do both of:
> > a) Have a Portal implemented on top of a standard Servlet
> Container
> > b) Run multiple Portlet Applications, preferrably in a
> standard Portlet
> >Container, preferrably -the same- container as the Portal is
> running in.
> >.. and be able to, in a standard way, to communicate between
> the portal
> >and the portlets.
>
I agree that one of the concerns of the JSR 168 is that it does not
describe any public standard API for the communication between
the servlet container and the portlet container.
It does not mean it's impossible, simply that portability between
servlet containers will be an implementation specific feature of
the portlet container and that you may have to write servlet-container
specific adapter code.
Note that there's another related area where the portlet container
will have to have servlet container specific code: the portlet
application deployment requires you to deploy a standard WAR and thus
use the servlet colntainer deployment capabilities. :/
On the whole, I don't think this lack of APIs is a real showstopper
and would rather see that as an opportunity for an OSS project like
Jetspeed to work on the multi-containers approach while vendors will
most likely try to focus on tying their servlet and portlet container.
> <snip>
> From what I understand of my discussion in this mailing
> list, Pluto does
> something in between : it adds within the portlet a proxy
> servlet that
> allows dispatching to the portlets. This way the system I
> have been using
> with cross-context dispatching could be adapted, but it's
> still not as
> efficient as having a portal/portlet full-blown API. Maybe
> this is the
> subject for a new JSR ? Or maybe in this project (Apache
> Jetspeed) we could
> develop what we need and then propose this as a reference
> implementation
> and submit it as a JSR (maybe that way things would move
> faster ?). Seeing
> how projects such as Xerces and Xalan got accepted throughout
> the whole
> commercial world it would seem like Apache is in a position
> to "impose"
> defacto standards.
>
Yes Pluto implements something like this. The key issue to solve
here is request dispatching: how does the portlet container retrieves
a portlet pointer while still fullfilling the JSR constraints (like
sharing session between the portlet and objects in its WAR (JSPs, etc...)
The porxy servlet is mainly a portlet container specific implementation
of this request dispatching, using the native servlet API calls and some
custom parameters.
I don't believe there's a major performance impact there.
>
> >One way of solving it is apparently using WSRP as the "glue"
> between the
> >portlet and portal.
>
> Yes but at what cost. Serializing all objects through XML and
> sending them
> through sockets that are being opened / closed all the time is very
> expensive in terms of performance.
>
Agreed, I don't think WSRP is the solution to this problem.
>
> <snip>
>
> > I would have loved a spec where the Portal was the
> Container, and had to
> >be able to host Portlets within it. This way, one could buy
> the Servlet
> >Container from Oracle, use JetSpeed as the Portal, and buy
> Portlets from
> >CompanyA, B and C, plugging them in / installing like nice little
> >applications in a normal OS.
>
That would however seriously duplicate concerns as the portal/portlet
container would have to deal with classloading, WAR handling, etc...
There is some sense to try to leverage these functions of the servlet
container (after all, how many times do you *really* want lo load
xerces.jar ? :)
The JSR 168 tries to guarantee that any compliant portlet will run on
any compliant container. It does not try to address portlet container
portability just like EJB does not address portability of EJB
container implementations (any luck porting JBoss to Websphere
recently ?)
> Ok, again I agree. Users of portals should be free to migrate
> from one
> system to another, without vendor lock-in. After all the J2EE
> specs exist
> as Sun puts it : "for vendors to compete on implementation,
> and agree on
> standards". This is a nice vision but reality is more like : "vendors
> always compete on anything, Jakarta standardises".
>
+1. SO we can try to standardize what's missing from the JSR... :)
> Now enough with my whining, I'll start a quick proposition
> here : this is
> what I would have loved to see in JSR-168 :
>
> 1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ?
> Basically be able to do something like this :
>
> Context context = getInitialContext();
> PortletRepository portletRepository = (PortletRepository)
> context.lookup("PortletRepository");
> // list of portlet example : ArrayList portletList =
> portletRepository.getPortletList();
> Portlet myPortlet = portletRepository.getPortlet("myPortlet");
>
Just 2 questions:
- what is exactly the Portlet object you're trying to get ?
- a portlet description as gathered from the portlet.xml descriptor
- a portlet object (ie a class implementing javax.portlet.Portlet)
- a portlet description as gathered from the current page context
(for example a PSML page description) ?
- what code should be able to use this API:the portlet container,
portal or any portlet ?
> 2. Direct dispatching to portlet. Continuing on the above code :
>
> myPortlet.render(renderRequest, renderResponse);
>
Note that render requests typically require a page context for them
to be meaningful. A portlet container may avoid thinking about
context and process the request, but a real portal would have to
first load the page settings, then the user preferences before any
invocation of the portlet itself...
> As you can see not much extra is needed to have the complete
> picture. It's
> a shame the JSR-168 only specifies point 2 when point 1 could
> have been
> achieved in a minimal way without much effort. I hope this
> will indeed be
> specified later, but given the time it has taken to specify
> point 2 I had
> hope point 1 was being addressed too. Maybe it's not too late
> and before
> the final release this can be added ? Can somebody here shed
> some light on
> the possibilities still open ?
>
Right now, a lot of possibilites are open these APIs, especially the
portal/portlet container ones.
Check out the slide 4 of the following presentation (in French, but
diagrams should be OK for everyone :)
http://jakarta.apache.org/~raphael/frjug/Jetspeed_2_fr.ppt
for an overview of *my* current thoughts on JS 2 architecture (it
is a bit out of sync with current efforts as it has been done
is May)
All the portal internal APIs can still be modified, and we have a strong
option of either building out the current Pluto public APIs or define
a new Jetspeed container API and have a JetspeedPluto adapter to match
the 2 different APIs.
--
Raphaël Luta - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
**********************************************
Vivendi Universal - HTTP://www.vivendiUniversal.com:
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact immediately
the sender by returning e-mail and delete the material from any computer.
If you are not the specified recipient, you are hereby notified that all
disclosure, reproduction, distribution or action taken on the basis of this
message is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
