You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2005/08/04 00:06:06 UTC
Portal framework in Geronimo w/ or w/o the Web Console
A few weeks back we had a discussion about how we should deal with the
Portal framework (and the portlet container) that is included in the web
console contribution.
At the time, here were some of the comments:
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.
>
<snip>
I responded with:
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.
>
<snip>
to which Aaron added:
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.
Now that I've caught you all up on the discussion .... I was wondering
if we can figure out what we are doing with the portlet container and
portal framework for the console contribution. Since the container will
most like be included as an optional element with Geronimo (even without
the console) I think that raises the question of what should we do about
a Portal framework around that container. What does this mean to the
user? If the portlet container is integrated directly into Geronimo it
will be visible to the user (actually, the user will know it's there
when he sees the console anyway). Can a user deploy portlets into this
container? If so, how are the portlets accessed (one at a time via
URL?) and/or should we provide some type of generic Portal framework
capabilities that include aggregation, navigation, persistence, etc....?
I know these are muddy waters, but I think the questions will come from
the users as soon as we include the portlet container for the web console.
We're not trying to compete/clash with JetSpeed but at the same time it
appears that what they are creating is a bit too heavy weight for the
web console needs alone. However, it might be just fine if the user
wants to directly exploit the portal capabilities. With this in mind
should we be looking to update the Web Console so that it can run either
with the static Portal included as part of the console contribution or
full JetSpeed depending upon the GBean configuration (assuming we
include JetSpeed as an option)? Maybe I'm moving too fast here .... I
guess the first question is are we planning to integrate Pluto directly
into Geronimo or are we treating it as part of the Web Console
contribution for now? If it's just part of the Web Console I guess we
can declare that it's off-limits to the user (of course, with open
source I guess they can really do anything they want to do :-) ).
-Joe
--
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: Portal framework in Geronimo w/ or w/o the Web Console
Posted by Daniel Alejandro Rangel Gavia <dr...@yahoo.com.mx>.
I'm agree with Aaron, first step is to use the Pluto "integration", and in a long-term a big plan to "portal server" implementation, because this option has more implicit work.
daniel rangel
Aaron Mulder <am...@alumni.princeton.edu> escribió:
I think the short-term plan is to use the Pluto "integration" that
we have in the web console. It's horrible as portal servers go because
it's totally static (from layout to portlet selection), but since it's
totally statically customized for the web console, it works. If someone
wanted to use it for their application, they can, but it would be
extremely painful.
I guess the long-term plan should be some reasonable Pluto
integration in the form of a proper "portal server" where you can
dynamically select portlets and alter layout and so on. But that's a
pretty big effort.
Aaron
On Wed, 3 Aug 2005, Joe Bohn wrote:
> A few weeks back we had a discussion about how we should deal with the
> Portal framework (and the portlet container) that is included in the web
> console contribution.
>
> At the time, here were some of the comments:
>
> 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.
> >
>
>
> I responded with:
>
> 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.
> >
>
>
> to which Aaron added:
> 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.
>
> Now that I've caught you all up on the discussion .... I was wondering
> if we can figure out what we are doing with the portlet container and
> portal framework for the console contribution. Since the container will
> most like be included as an optional element with Geronimo (even without
> the console) I think that raises the question of what should we do about
> a Portal framework around that container. What does this mean to the
> user? If the portlet container is integrated directly into Geronimo it
> will be visible to the user (actually, the user will know it's there
> when he sees the console anyway). Can a user deploy portlets into this
> container? If so, how are the portlets accessed (one at a time via
> URL?) and/or should we provide some type of generic Portal framework
> capabilities that include aggregation, navigation, persistence, etc....?
>
> I know these are muddy waters, but I think the questions will come from
> the users as soon as we include the portlet container for the web console.
>
> We're not trying to compete/clash with JetSpeed but at the same time it
> appears that what they are creating is a bit too heavy weight for the
> web console needs alone. However, it might be just fine if the user
> wants to directly exploit the portal capabilities. With this in mind
> should we be looking to update the Web Console so that it can run either
> with the static Portal included as part of the console contribution or
> full JetSpeed depending upon the GBean configuration (assuming we
> include JetSpeed as an option)? Maybe I'm moving too fast here .... I
> guess the first question is are we planning to integrate Pluto directly
> into Geronimo or are we treating it as part of the Web Console
> contribution for now? If it's just part of the Web Console I guess we
> can declare that it's off-limits to the user (of course, with open
> source I guess they can really do anything they want to do :-) ).
>
> -Joe
>
> --
> Joe Bohn
>
> joe.bohn@earthlink.net
> "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>
---------------------------------
Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx
Re: Portal framework in Geronimo w/ or w/o the Web Console
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I think the short-term plan is to use the Pluto "integration" that
we have in the web console. It's horrible as portal servers go because
it's totally static (from layout to portlet selection), but since it's
totally statically customized for the web console, it works. If someone
wanted to use it for their application, they can, but it would be
extremely painful.
I guess the long-term plan should be some reasonable Pluto
integration in the form of a proper "portal server" where you can
dynamically select portlets and alter layout and so on. But that's a
pretty big effort.
Aaron
On Wed, 3 Aug 2005, Joe Bohn wrote:
> A few weeks back we had a discussion about how we should deal with the
> Portal framework (and the portlet container) that is included in the web
> console contribution.
>
> At the time, here were some of the comments:
>
> 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.
> >
> <snip>
>
> I responded with:
>
> 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.
> >
> <snip>
>
> to which Aaron added:
> 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.
>
> Now that I've caught you all up on the discussion .... I was wondering
> if we can figure out what we are doing with the portlet container and
> portal framework for the console contribution. Since the container will
> most like be included as an optional element with Geronimo (even without
> the console) I think that raises the question of what should we do about
> a Portal framework around that container. What does this mean to the
> user? If the portlet container is integrated directly into Geronimo it
> will be visible to the user (actually, the user will know it's there
> when he sees the console anyway). Can a user deploy portlets into this
> container? If so, how are the portlets accessed (one at a time via
> URL?) and/or should we provide some type of generic Portal framework
> capabilities that include aggregation, navigation, persistence, etc....?
>
> I know these are muddy waters, but I think the questions will come from
> the users as soon as we include the portlet container for the web console.
>
> We're not trying to compete/clash with JetSpeed but at the same time it
> appears that what they are creating is a bit too heavy weight for the
> web console needs alone. However, it might be just fine if the user
> wants to directly exploit the portal capabilities. With this in mind
> should we be looking to update the Web Console so that it can run either
> with the static Portal included as part of the console contribution or
> full JetSpeed depending upon the GBean configuration (assuming we
> include JetSpeed as an option)? Maybe I'm moving too fast here .... I
> guess the first question is are we planning to integrate Pluto directly
> into Geronimo or are we treating it as part of the Web Console
> contribution for now? If it's just part of the Web Console I guess we
> can declare that it's off-limits to the user (of course, with open
> source I guess they can really do anything they want to do :-) ).
>
> -Joe
>
> --
> Joe Bohn
>
> joe.bohn@earthlink.net
> "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>