geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Web Console (IBM Donation)
Date Tue, 19 Jul 2005 23:33:34 GMT

That may be the right answer for #1 ... it all depends upon our 
intention to support Portal
applications or not.    For now I think we need to move forward with the 
"static" Portal
configuration we already have in the console with possibly some 
enhancements to make
it a bit more dynamic (within reason).   Hopefully there will be some 
open source
Portal server project that comes along before we end up creating our own 
server within Geronimo.  Of course I agree that we should certainly look 
into securing
whatever we deliver for the console before it leaves the sandbox.

Thanks for clearing up my confusion on #2.  

So does this mean that you are ready to check the code into a sandbox so 
that we can
start to play?  I have a few things I'd like to investigate but I'm not 
sure how to go about
creating JIRA items on a JIRA item itself.  :-) 

Aaron Mulder wrote:

>	Maybe the real answer to #1 is to actually integrate Pluto into 
>Geronimo -- you know, so if you deploy a web app with portlet deployment 
>descriptors then a PortletDeployer GBean "magically" wires it up and makes 
>it available to Pluto, and then some other admin web site lets you arrange 
>your portlets on the page...  Gosh, this is sounding like a bigger effort 
>already.  I guess it would be a portal server module for Geronimo, as 
>opposed to the current "static" Pluto configuration.
>	Anyway, I don't seem to be on the popular end of this one, but I
>have to insist that at a bare minimum, if we don't merge the web apps, we
>apply security to the console-standard web app.
>	As for #2, I didn't say we need to hold up the contribution, but I 
>do feel we should hold up "moving it out of the sandbox" or the 
>On Tue, 19 Jul 2005, Joe Bohn wrote:
>>Regarding #1 below ... I think there are probably some good reasons to 
>>keep this split into 2 or maybe even more web applications.
>>As you mention, the "framework" appears to hold the necessary components 
>>for the console framework itself.  Since this may be replaced
>>at some point in the future by an open source Portal Server (not just 
>>the container) it probably makes sense to keep this split apart.
>>The "standard" application includes the portlets necessary for console 
>>administration.  One of the benefits of the portlet model (and I
>>suspect the reason it was chosen for the console) is that it is 
>>extensible.   Multiple applications can be installed as necessary.  This 
>>like it would be a desirable feature for a modular server like 
>>Geronimo.   If there is no need for the EJB container it need not be
>>included in the resultant image and therefore the portlets that 
>>administer the EJB container would not be deployed into the solution.
>>I wasn't one of the authors of this console structure but I can see how 
>>it makes sense in the big picture even it is seems like overkill for now.
>>For #2 I think that it is a good idea to provide some level of 
>>abstraction between the view (console) and the model/controller 
>>(kernel).  However,
>>is it really necessary to integrate these changes into the initial 
>>donation?   This is all internal functionality to the console and the 
>>kernel functions
>>are not exposed via any other mechanism beyond this.  Can't we discuss 
>>what this abstraction should be and then move the console over to
>>this public interface when it has been created?   I'm not sure why we 
>>would want to hold up the initial contribution of the console for these
>>internal changes / new interfaces.
>>Aaron Mulder wrote:
>>>So I took a look at the web console.  There are two main changes I'd like
>>>to make before we "go live" with it.
>>>1) Combine the "framework" and "standard" web apps into one.  Currently
>>>  the "framework" holds the Pluto engine and page framing and so on,
>>>  while the "standard" holds all the actual portlets.  Some of the issues
>>>  are that I don't really fancy taking two contexts for this, there's no
>>>  security on the portlet (standard) context, it can be accessed directly
>>>  with a variety of unpleasant side effects, it makes the whole thing
>>>  require multiple build modules and an EAR, etc.
>>>2) Separate the "data access" from the "UI".  Right now the portlet code
>>>  is making kernel calls to load the data it presents and alter the
>>>  GBeans when changes are submitted.  Besides the obvious issues with
>>>  this architecture for the console app itself, this means the
>>>  configuration layer is not reusable by other tools (for example, a
>>>  command-line tool to change network ports or whatever).  There's also
>>>  some supporting GBean code for the console that could hopefully be
>>>  rolled into this layer.
>>>Personally, I'd like to start with the second item.  I'm hoping someone
>>>else can take a look at the first one.  I guess my thought on how to
>>>proceed with that one would be to clean up the layout of the "framework"  
>>>WAR a bit (put most of the files under /framework or something), put in a
>>>couple placeholder portlets just to prove that Pluto can display portlets
>>>from its own web app, and make this the basis of a new "web console WAR"  
>>>module in Geronimo apps.
>>>Then we can start updating the donated portlets to use the new
>>>configuration API (#2) and migrate them into the new console WAR (#1).  I
>>>also have some thoughts on changing the layout/ordering of portlets, but
>>>that's not such a big concern right at the moment.
>>>Finally, there are a lot more portlets and features I'd ultimately like to 
>>>add to the web console, but that's definitely a discussion for another 
>>>day.  :)
>>>	Aaron
>>Joe Bohn     
>>"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim

Joe Bohn 
"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot

View raw message