geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Portal framework in Geronimo w/ or w/o the Web Console
Date Thu, 04 Aug 2005 00:52:42 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
OK, we can assume that for now.&nbsp; That certainly the quickest approach
to get the console included (and I really do want the console included
as quickly as possible).&nbsp;&nbsp; I just think the question will come up from
users sooner rather than later.&nbsp; The only reason that I was even
brining it up again was because I'm already being asked&nbsp; by folks if
they can use the portlet container included in Geronimo for their own
purposes once the Web Console brings it in.&nbsp; <br>
<br>
>From a pure architectural perspective it makes more sense to pull in
the dependencies of a component as you want them before you pull in the
higher level components.&nbsp;&nbsp; We can rework the architecture to pull it
out later but if we could consider it now it would make the design
much, much cleaner.<br>
<br>
-Joe<br>
<br>
Aaron Mulder wrote:
<blockquote
 cite="midPine.LNX.4.58.0508031855540.27191@saturn.opentools.org"
 type="cite">
  <pre wrap="">	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:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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:

    </pre>
    <blockquote type="cite">
      <pre wrap="">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.

      </pre>
    </blockquote>
    <pre wrap="">&lt;snip&gt;

I responded with:

On Tue, 19 Jul 2005, Joe Bohn wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">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.

      </pre>
    </blockquote>
    <pre wrap="">&lt;snip&gt;

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     

<a class="moz-txt-link-abbreviated" href="mailto:joe.bohn@earthlink.net">joe.bohn@earthlink.net</a>

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


    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="60">-- 
Joe Bohn     

<a class="moz-txt-link-abbreviated" href="mailto:joe.bohn@earthlink.net">joe.bohn@earthlink.net</a>

"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot
</pre>
</body>
</html>

Mime
View raw message