portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: [Fwd: Admin Portlet]
Date Tue, 05 Dec 2006 02:34:12 GMT
Oliver, please see below for details.  In general this looks good, but I 
do caution you to remember that pluto is a portlet container and the 
portal driver (and portlets) we develop around it should be in support 
of the container -- not for their own consumption.  In otherwords, 
things like providing the ability to add new themes may be going 
overboard for pluto.  That's starting to encroach into the jetspeed space.

David H. DeWolf wrote:
> Hi Oliver,
> I'm forwarding this to the pluto-dev list.  All of these discussions 
> need to take place there.  I'll respond onlist.
> Thanks,
> David
> -------- Original Message --------
> Subject: Admin Portlet
> Date: Tue, 05 Dec 2006 03:10:29 +0100
> From: Oliver Spindler <olisp@minet.uni-jena.de>
> To: David H. DeWolf <ddewolf@apache.org>
> References: 
> <OF97BB1AD0.BB244BD7-ON8525723A.0058A697-8525723A.005B8500@hannaford.com> 
> <45745014.7030806@apache.org>
> Hi David
> As Torsten told you, I'm working on the admin-portlet.
> At the moment  I'm still working on the software-design.
> I think it would be the best to split the Admin-Portlet into two
> separate ones.
> The first for deploying portlets and the second one for editing the
> portal pages.

If you are still designing is there any reason why you wouldn't leverage 
what's in the trunk in these regards? Have you seen the most recent commits?

> Then the second portlet is independent from the servlet container (like
> Tomcat).
> The main problem is, that you cannot save the configuration of a running
> pluto-instance.

I assume you are talking about the <portlet-app> configuration elements 
in pluto portal?  If so, This configuration is no longer necessary in 
Pluto.  This info is automatically discovered on startup. If you haven't 
already, please take a look at what I've checked into the trunk.

> I think it is necessary to implement something to save the current
> configuration.
> Maybe we can use a XML-mapper like JAXB or something else instead of
> Digester.

We'll need this for page administration, but not for deployment. But in 
general I'm fine with JAXB if we need it.

> The next problem is the portlet-assembler. 


I think we need a better one,
> which provides
> a good result in all cases. For example if you use him twice.
> This is my idea for the Deployer-Portlet:
> for deploying:
>    1. the user selects an .war file
>    2. upload the .war file to a temp-dir
>    3. the portlet-assembler checks the .war file and inject pluto
> specific things
>    4. we can use existing features of the servlet container to deploy
> the .war to the servlet-container
>    5. register the portlet application in pluto (persistent)
>    optional:
>    6. select/create a page for the new portlets

I agree up to step 6.  Step 6 should be left for the second portlet 
(page admin portlet).  Page administration should be kept separate of 
portlet deployment.

I'm all for redoing the assembler.  It's always been the hairiest part 
of pluto.  To be honest, I'm not too keen on having one at all, but I 
know it's something a lot of people want.  My biggest beef with it is 
having to support app server specific code.  The more you can abstract 
this - the better off we will be.

Whatever you do, you should wait for Craig's response - as he is the one 
that is most involved with that aspect of pluto.

> The portlet should also be able to re-/undeploy a portlet application.


> I have implemented an wrapper class for the Tomcat-Manager servlet
> (see http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html) and I
> think it would be
> the best way to deploy the .war file to Tomcat. The problem here is the
> authentication for the
> tomcat-manager servlet (username/password) when using HttpClient for the
> connection.

Why not allow the user to enter the username and password in the upload 

> I can send you the sources, if you are interested in.

Sure, attach them to a bug.

> Another problem is the context.xml file. I think we should create one in
> the META-INF directory
> or check it if it exists.

Again, I'm not keen on app server specific things in the war.  If we 
must, we must, buy why not just allow it to be uploaded with the war?

> Maybe we could also provide a servlet for deploying portlets like the
> Tomcat-Manager servlet
> (not the html part) for using with maven and ant.

Sure! There's a restful service that was implemented with that in mind. 
I'm all for it. . .

> This is my idea for the page-manager portlet:
>    1. list of all known portlets
>    2. create new pages
>    3. edit/remove existing pages
>    4. put and arrange any portlet on a page
>    5. save the configuration
>    optional:
>    6. create own themes for the portal pages

It seems like you haven't checked out the latest modifications in the 
trunk.  Take a look.  Pluto now:

1) Auto-Publishes all portlet applications which are depoyed to the server

2) Has a page admin portlet which lists all pages and allows you to 
select a portlet to add to it

In regards to page administration configuration -- you are
correct.  The current implementation only does it in memory and persists 
nothing.  You'll have to modify the page layout the next time you enter 
the app. This should change.

A couple of things I would caution about:

- I would prefer that we don't depend upon an exploded webapp.  The 
persistence should be external to the webapp.  Basically, if the 
persistence file is found, then it overrides what is bundled with the app.

- I would prefer that we don't get too complicated here.  An xml file is 
fine, but we shouldn't go down the road of a database.  Remember, Pluto 
is not about the portal, it's about the portlet container. All else is 
just in support of the container.

- The service that provides persistence should be plugable so others can 
make it more robust if they choose.

> I think we should also create a new directory (f.e: pluto-portla-admin)
> for the administration portlets/servlets/utilities.
> The pluto-driver directory should only contain some interfaces for the
> pluto-specfic administration tasks,
> like register portlets, save configuration and so on.

I'm not sure that I understand totally.  Currently we have:

pluto-driver - interfaces
pluto-driver-impl - implementations

are you suggesting another webapp for all of the admin portlets?  If so, 
realize that will be very difficult as the portlets will depend heavily 
on accessing classes loaded by the portal app.

> What do you think about that all?

I think we're on the right track.  I'm excited about this. Let's keep on 
fleshing this out on the list and see where it goes.  Have a look at the 
current implementation in the trunk and let me know what you think.  It 
would be GREAT if you could do this work in the trunk and we can merge 
it into the branch as we go.  I don't see any reason why this work needs 
to be 286 specific (at least not yet).

Thanks for the info!!!


> Off-topic:
> I have still problems redeploying Pluto, when Tomcat is running. I think
> we should also use the Tomcat-Manager-Servlet
> for deploying/undeploying Pluto if Tomcat is running.
> Best regards
> Oliver

View raw message