Mailing-List: contact pluto-user-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pluto-user@portals.apache.org
Reply-To: pluto-user@portals.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Mon, 28 Feb 2005 15:53:32 -0800
From: Matthew Ingenthron <Matt.Ingenthron@Sun.COM>
Subject: Re: deploying portlets to Pluto binary distribution
To: Bill Schneider <bschneider@vecna.com>
Cc: pluto-user@portals.apache.org
Message-id: <1310c7132c02.132c021310c7@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_TBeHtgahfjX6QASZb5OI7A)"
Content-language: en
Priority: normal

This is a multi-part message in MIME format.

--Boundary_(ID_TBeHtgahfjX6QASZb5OI7A)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Bill,

> The point is not so much to have the *portal* directly access the 
> JSPs, 
> servlets, etc. in an existing WAR, but to have the WAR supply 
> multiple 
> views into the same business logic.  I see this as not much 
> different 
> than providing a user interface and SOAP-based web-services in the 
> same 
> WAR, backed by the same business components.

By directly accessing the JSPs, what I meant is the end user feeding the
servlet container a URI with the .jsp file.  In other words
/warapp/myDashboard.jsp would work, but /warapp would not.  Sorry if
there was some confusion.  I can see where you're coming from now though.
 
> 
> In effect, what I'd like to be able to do is take an existing, 
> standalone WAR, and leave it mostly as-is, but add some portlets 
> incrementally.  This would allow the application to supply some 
> summary 
> information to a portal, where it would be aggregated with 
> information 
> from other applications on a dashboard-type page.  The portlets 
> would 
> then link to the full-blown application.

That makes a lot of sense.  However, looking at it a different way, for
some portal tier stuff (i.e. view) you're looking to embed (potentially
a lot of) business logic.  This isn't necessarily the wrong thing to do,
but it will tend to make your app less flexible.

I've done what you're talking about above today, but instead of using
the app, I use some kind of identity context implemented with SSO. 
Typically it's with a Sun product (Access Manager), but I did just see
on java.net an article where someone was working with pluto and JOSSO. 
It could be some other implementation too.  Basically the idea is that
the portlet is deployed with enough configuration info to know how to
get the data to build the dashboard, and it builds URLs to get the user
to the full blown app if need be.

> 
> I acknowledge that, in the EJB world, the "right" solution is to 
> use 
> session EJBs for the business logic, then you have a single EAR 
> file 
> with two different WARs for the webapp and portlet.  Then there is 
> no 
> real question about how to keep a single WAR, because your re-used 
> business logic is in an ejb-jar file.  But is there a comparable 
> good 
> solution for the POJO world?

There are a few POJO solutions-- I just don't know of any that will let
you deploy one WAR to do both-- at least not without relying on how a
particular implementation handles a WAR.  Now that I've looked at the
spec again, it does seem that they spend some time explaining how a
portlet WAR is the same as any other WAR.  Still, when it comes to
servlets, there are real differences, and the spec has a section that
discusses those differences.  I still think you'd be relying on an
implementation detail-- a portlet container will nearly always be on top
of a servlet container, but it's not required to be.  I guess you could
argue that it needs to handle everything in web.xml (since the spec says
that), but I'm not certain.

It's probably worthy of sending a comment with your use case over to the
jsr-168-comments@jcp.org.  

There are certain other things one should do if you wanted to reuse
other stuff of course.  For example, there's all the stuff for namespace
conversion with javascript.

Again, that's just my take as a user, not an expert.  :) 

- Matt

--Boundary_(ID_TBeHtgahfjX6QASZb5OI7A)
Content-type: text/x-vcard; name=mi109165.vcf; charset=windows-1252
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=mi109165.vcf
Content-description: Card for Matthew Ingenthron <Matt.Ingenthron@Sun.COM>

begin:vcard
n:Ingenthron;Matt
fn:Matt Ingenthron
tel;work:310-242-6439
url:http://blogs.sun.com/mingenthron/
org:Sun Microsystems;Client Solutions; Software Practice
adr:;;222 N. Sepulveda Blvd. 10th Floor;El Segundo;CA;90245;US
version:2.1
email;internet:Matt.Ingenthron@Sun.COM
title:Technical Specialist, Web Services
end:vcard


--Boundary_(ID_TBeHtgahfjX6QASZb5OI7A)--