Web Console (IBM Donation)

[Aaron Mulder <am...@alumni.princeton.edu>]

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.  :)

Thanks,
	Aaron

Re: Web Console (IBM Donation)

[Joe Bohn <jo...@earthlink.net>]

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 
mini-Portal
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 
>equivalent.
>
>Aaron
>
>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 
>>seems
>>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.  :)
>>>
>>>Thanks,
>>>	Aaron
>>>
>>>
>>> 
>>>
>>>      
>>>
>>-- 
>>Joe Bohn     
>>
>>joe.bohn@earthlink.net 
>>"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot
>>
>>
>>    
>>
>
>
>  
>

-- 
Joe Bohn     

joe.bohn@earthlink.net 
"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot

Re: Web Console (IBM Donation)

[Aaron Mulder <am...@alumni.princeton.edu>]

	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 
equivalent.

Aaron

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 
> seems
> 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.  :)
> >
> >Thanks,
> >	Aaron
> >
> >
> >  
> >
> 
> -- 
> Joe Bohn     
> 
> joe.bohn@earthlink.net 
> "He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot
> 
> 

Re: Web Console (IBM Donation)

[Joe Bohn <jo...@earthlink.net>]

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 
seems
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.  :)
>
>Thanks,
>	Aaron
>
>
>  
>

-- 
Joe Bohn     

joe.bohn@earthlink.net 
"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot

Re: Web Console (IBM Donation)

["Geir Magnusson Jr." <ge...@apache.org>]

Can we wrap up the vote so we can move forward with this?


On Jul 16, 2005, at 12:27 PM, 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.  :)
>
> Thanks,
>     Aaron
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org