You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2005/12/23 14:18:45 UTC
Aggregation Server (AKA Portal Light)
I, (in the past and now as well) have a need for a "light weight" portal
solution. This light weight portal solution is basically an
"aggregation server". I consider it more like a simple wrapper around
the portlet container. It provides the following:
1) Ability to invoke portlets and include their content into a webapp in
a compliant manner.
2) Ability to manage a "portlet registry" at runtime.
3) Ability to define a "page" or grouping of portlets at runtime but
have no layout associated with it.
4) Ability to customize rendering using different technologies (simple
jsp, a servlet, velocity, etc. . .) without having to jump through
hoops. Custom tags to insert rendering such as the <pluto:render> tag
would be nice.
5) Ability to have a portable solution which can be packaged as a single
war (not built differently for different environments) and deployed on
any compliant servlet container.
There may be one or two additional requirements that I'm not thinking of
right now, but literally, this is a very simple portal solution and
needs to be void of additional "fluff". The solution does not need to
include any other "value added" services - and it would be a pretty big
negative if it did.
I have been developing this solution in Pluto, however, at apachecon, I
got wind of the fact that some people may not be comfortable with this
and would prefer that the test driver does not include things such as #2
and #3 above (and perhaps others). The solution needs to be of
production strength.
Would others please provide their ideas on where the best place for this
solution is, whether it may be provided in a solution we allready have
(besides the pluto portal in question), and how we should move forward?
Thanks,
David
Re: Aggregation Server (AKA Portal Light)
Posted by Raphaël Luta <ra...@apache.org>.
David H. DeWolf wrote:
> <snip>
>
> Well, for my usecases (and I suspect others like an embedded webconsole
> in felix or something similar), the concept of a page is simply a
> grouping of portlets -- it has no control over the page layour
> whatsoever -- the layout itself is static - only which portlets are
> displayed changes.
>
>>
>> Perhaps a simple example of what you'd like a "page" to be would be very
>> instructive for us all. I am imagining a Aggregation Server page is
>> something like this:
>>
>> <html>
>> <body>
>> <table>
>> <tr>
>> <aggregator:portlet
>> webapp="myPortletApp"
>> portlet="myFirstPortlet"/>
>> </tr>
>> <tr>
>> <aggregator:portlet
>> webapp="linksys"
>> portlet="linksys-admin"/>
>> </tr>
>> </table>
>> </body>
>> </html>
>
>
> You hit the nail on the head. That's exatly it. The only thing I would
> add is that the portlet definitions within the tags are dynamic -- they
> come from the "portlet grouping". so it may look like:
>
>> <html>
>> <body>
>> <table>
>> <tr>
>> <aggregator:portlet
>> webapp="${portlets.[0].appContext}"
>> portlet="portlets.[0].portletName"/>
>> </tr>
>> <tr>
>> <aggregator:portlet
>> webapp="portlets.[1].appContext"
>> portlet="portlets.[1].portletName"/>
>> </tr>
>> </table>
>> </body>
>> </html>
>
>>
>> Is this the idea? To me, it looks closer to a J2 layout decorator than
>> J2 PSML data model... especially if you imagine our current decorator
>> templates written in JSP... :-)
>
>
> I think I'm still missing the line between these decorator templates
> that the layout information which is included into the PSML.
>
> For instance, this PSML fragment seems to include a lot of what I would
> think should belong in the decorator:
>
>
> <fragment id="100345" type="layout"
> name="jetspeed-layouts::VelocityTwoColumns">
> <property layout="OneColumn" name="row" value="1"/>
> <property layout="TwoColumns" name="sizes" value="33%,66%"/>
> <fragment id="100121" type="portlet" name="j2-admin::LoginPortlet">
> <property layout="TwoColumns" name="row" value="0"/>
> <property layout="TwoColumns" name="column" value="0"/>
> </fragment>
> <fragment id="100171" type="portlet" name="demo::UserInfoTest">
> <property layout="TwoColumns" name="row" value="0"/>
> <property layout="TwoColumns" name="column" value="1"/>
> </fragment>
> </fragment>
>
> Can someone explain to me where the line is drawn between the two?
>
I'll try to clarify the PSML thing:
- The PSML page lists all available *page fragments* that need to be
displayed on a given portal page. These fragments can be nested
in *fragment groups* if it make sense from a layout point of view
- these fragments are usually *portlet instances* but could be in theory
anything that can produce a compatible output stream (servlet, etc...)
- each of these fragments can be associated with *layout hints* (the
<property> elements) . These hints are specific to each layout
component (in the example above, you only provide hints for the
TwoColumns layout component) and of course, you're free to provide no hints.
- additionally, PSML allows to specify on any fragment optional
*security restrictions* (which you could think as a specialized type
of layout hint) and optional *decorators* (these decorates the portlet
output with default portal controls like minimize, maximize, edit
buttons, etc...)
In jetspeed, the aggregation implementation is done by specialized
layout portlets that read the PSML page to load all the portlet
instances they should aggregate, apply the appropriate layout hints if
available and then draw the aggregated page. In the above example, the
layout portlet used is "jetspeed-layouts::VelocityTwoColumns"
If we wanted to apply your use case to PSML you would have something
like this:
<fragment id="100345" type="layout" name="my-layouts::JSPLayoutPortlet">
<property layout="JSPLayout" name="pagename" value="mylayout.jsp"/>
<fragment id="100121" type="portlet" name="j2-admin::LoginPortlet" />
<fragment id="100171" type="portlet" name="demo::UserInfoTest" />
</fragment>
And your JSPLayoutPortlet would simply read the JSP page to use from
PSML pagename property, read the fragment definitions handled by your
JSPLayout and create a set of parameters that your JSP can use and then
delegate everything to the JSP.
It may seem a bit cumbrersome in this situation and it indeed adds some
complexity but keeping the PSML as a layout neutral portlet aggregation
descriptor enables you :
- to keep the declarative security constraints and implementations
- the ability to switch your layout strategy easily in your requirements
grow in complexity
- a standard storage format for your aggregation properties (in your
case, your list of portlet instances).
I hope it helps.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Aggregation Server (AKA Portal Light)
Posted by "David H. DeWolf" <dd...@apache.org>.
Randy Watler wrote:
> David,
>
> I step into this thread with some trepidation, but it is done
> now... :-). I'll just focus for now on what I can describe/explain
> concerning J2 components and PSML. I hope simply to save others some
> effort in replying... here goes...
Thanks for your input and guts Randy, I found your comments very useful.
>
> On Sat, 2005-12-24 at 00:30 -0500, David H. DeWolf wrote:
>
>>>>3) Ability to define a "page" or grouping of portlets at runtime but
>>>>have no layout associated with it.
>>>>
>>>
>>>Will you be using PSML or another technology?
>>>
>>
>>Excuse my ignorance here. . .
>>
>> From what I've seen in jetspeed over the past week or so, PSML is a
>>markup language which defines how pages are layed out. Is this correct?
>> If so, then know, I'd prefer not. My idea of a page is much simpler,
>>it's basically a grouping of portlets which are aggregated together. It
>>contains no layout information whatsoever.
>
>
> PSML contains elements that encapsulate the the following concepts:
>
> 1. Fragments that serve as the links to portlet instances.
> 2. Fragment hierarchies to support the J2 notion that layouts ARE
> portlets.
> 3. Pages that contain fragments.
> 4. Folders that organize groups of Pages.
> 5. Security constraints on these basic entites.
> 6. Menu/Navigation declarations on these same basic entites.
> 7. Localized metadata for PSML elements.
>
> Almost all of this markup is optional. If one wanted only to represent
> Fragments in Pages, it would be a proper subset of PSML and could
> certainly be represented by the Page Manager.
How about if one only wanted to specify *what* portlets existed in a
logical grouping -- not necessarily where they were layed out?
I think what confuses me is that the examples I see all include page
"fragments" which define layout properties such as columns, rows, etc. .
. Am I understanding correctly that this can be left out? If so, is it
possible for me to exclude the service that manages these layout
properties from my jetspeed configuration? Or is it a depdency of the
core components?
>
> Even looking at the Geronimo Admin Console, there are many of these
> concepts present... but they indeed might be coded in "content" or the
> "web page" JSP/Servlet vs. being modeled as is done here with PSML. With
> J2, we have tried to reduce, or even eliminate in most cases, page
> content authoring external to the portlets themselves.
Yes, after these discussions, I agree that jetspeed is the right portal
for geronimo. The fact that they want to support enterprise portals
(with or without the webconsole) tipped the scale for me. Having the
ability to manage the scope of jetspeed within the app server vs.
managing two totally different portals is undoubtedly a better approach.
Additional functionality such as what you describe here definately
adds to the argument.
>
> I can see why one might believe this solution is out of place in a
> portal "ME" environment. However, what confuses me on this front is why
> you would want to explicitly model the notion of a page at all? If you
> start down that path, it is easy to argue for the inclusion of all or
> most of PSML, (that is how I think we got there with J2). I mean to say:
> isn't the notion of portlets and a web page template with embedded tags
> in it where the portlets are to go sufficient in your case?
Well, for my usecases (and I suspect others like an embedded webconsole
in felix or something similar), the concept of a page is simply a
grouping of portlets -- it has no control over the page layour
whatsoever -- the layout itself is static - only which portlets are
displayed changes.
>
> Perhaps a simple example of what you'd like a "page" to be would be very
> instructive for us all. I am imagining a Aggregation Server page is
> something like this:
>
> <html>
> <body>
> <table>
> <tr>
> <aggregator:portlet
> webapp="myPortletApp"
> portlet="myFirstPortlet"/>
> </tr>
> <tr>
> <aggregator:portlet
> webapp="linksys"
> portlet="linksys-admin"/>
> </tr>
> </table>
> </body>
> </html>
You hit the nail on the head. That's exatly it. The only thing I would
add is that the portlet definitions within the tags are dynamic -- they
come from the "portlet grouping". so it may look like:
> <html>
> <body>
> <table>
> <tr>
> <aggregator:portlet
> webapp="${portlets.[0].appContext}"
> portlet="portlets.[0].portletName"/>
> </tr>
> <tr>
> <aggregator:portlet
> webapp="portlets.[1].appContext"
> portlet="portlets.[1].portletName"/>
> </tr>
> </table>
> </body>
> </html>
>
> Is this the idea? To me, it looks closer to a J2 layout decorator than
> J2 PSML data model... especially if you imagine our current decorator
> templates written in JSP... :-)
I think I'm still missing the line between these decorator templates
that the layout information which is included into the PSML.
For instance, this PSML fragment seems to include a lot of what I would
think should belong in the decorator:
<fragment id="100345" type="layout"
name="jetspeed-layouts::VelocityTwoColumns">
<property layout="OneColumn" name="row" value="1"/>
<property layout="TwoColumns" name="sizes" value="33%,66%"/>
<fragment id="100121" type="portlet" name="j2-admin::LoginPortlet">
<property layout="TwoColumns" name="row" value="0"/>
<property layout="TwoColumns" name="column" value="0"/>
</fragment>
<fragment id="100171" type="portlet" name="demo::UserInfoTest">
<property layout="TwoColumns" name="row" value="0"/>
<property layout="TwoColumns" name="column" value="1"/>
</fragment>
</fragment>
Can someone explain to me where the line is drawn between the two?
>
>
>>>Also, if you don't like the Jetspeed solution, just say so.
>>>Gawd knows we are not perfect. There are problems.
>>>Just speak your mind and tell us why its just unusable for a lightweight
>>>portal solution.
>>
>>Perhaps any responses to these comments should go in another thread so
>>that we don't get off track. . .
>>
>>I can't say I don't like jetspeed. From what I can tell, it simply does
>>not meet my requirements. That said, there are two things that are not
>>ideal IMHO (and perhaps my understanding is wrong and these really
>>aren't issues):
>>
>>I don't really like is the repo layout and build -- I don't think that
>>they lend themselves to easily discovering the core components of
>>jetspeed. I found I had to research and look around quite a bit to feel
>>like I had any clue what lived where.
>
>
> Indeed, I too found the components a bit confusing when I first started
> to look at J2. Some of the components also have some deps that lead to
> further confusion. However, we have been improving the sitution over
> time. Bridges have been pulled out. Components have been decomposed. The
> core itself is now a component. It is getting better. To be honest
> though... all of the components generate a separate jar in the repo and
> live in a top level directory called 'components': I am not sure how to
> make component discovery any easier... :-). I suppose we could make the
> pipeline elements into free standing components... might that help?
Yes, I definately agree it's getting better. And there have been
additional conversations one the list lately that suggest it's still
improving -- great work :)
>
> If you have any ideas here, we are all ears. We know we need to simplify
> the build... a task you have volunteered to lead IIRC as we move to
> maven2. To be honest, builds always evolve over time and often lag
> behind the product architecture. We can fix that easily!
Sure. . .I'm definately still game for helping with a Maven2 build if
it's desired. Now that the hollidays are over, I'll hopefully be able
to provide some assistance with that.
>
>
>>The other thing I don't like is the setup required. I'd like to be able
>>to take a jetspeed war, deploy it, and go. . .I don't want to have to
>>create db schemas, build for specific app servers, etc. . .before
>>running. IMHO, either an installer should do that work for me, jetspeed
>>should initialize itself at startup, or the default build should not
>>require this prep work.
>
>
> Again, we are working on this. It is convenient from a development POV
> to have the build be able to deploy to the container, run integration
> tests with a database, etc.. I think it is safe to say that all of these
> "extensions" to the build you have listed here grew out of the
> development environment we have been living in for 2 years.
>
> J2 just had its first release and now we are working on an installer to
> help take some of the "do everything" pressure off the builds. Again,
> things should now get better on this front.
>
>
>>Beside those minor things, I really have no problem with jetspeed.
>
>
> That is good. You do not seem to have any issues with the product
> architecture itself... other than its footprint... !ME if you will. I am
> left with the impression that this is the only requirement J2 does not
> meet functionally from your POV. I have to admit that if you are talking
> about a "portal on a chip", anything seems heavy to me, even Pluto!
>
> Getting back to reality, I think we need to know how severe your
> footprint requirements really are. If you are truly shooting for a J2ME
> environment on my refrigerator, I am not sure anything can be common
> between the J2 and the Aggregation Server projects... but I dont think
> that is the case really.
>
> It seems that using J2 components that are "heavier" than you would like
> would not be a problem, as long as they scaled down gracefully to your
> needs. The same case can be made for the core J2 component... and that
> is what I think the J2 community is trying to propose.
Sure. . and I'm all for supporting that effort. Let's run with it for a
while and see if we can make it happen.
>
> Let me digress...
>
> For example... lets take the Pluto test harness example so often sited
> as a reason to need something "light". During ApacheCon, I took the
> writing portlets tutorial that was given by Noel. Because of a
> communication problem between DST and Noel the previous day, the
> tutorial was given using the Pluto test harness. Being a J2 booster, I
> did the entire tutorial on J2 using our newly minted installer. Here is
> all I had to do to get every sample portlet working on a running J2:
>
> 1. Copy build portlet apps into J2's deployment directory.
> 2. Switch the current page in J2 to edit mode.
> 3. Click on add portlet.
> 4. Select portlets I wanted to add.
> 5. Click Done.
>
> Really, it is that easy! I also ran the Pluto test harness. It was less
> intuitive IMO and certainly looked like a test harness rather than a
> portal. I had to do something like this:
>
> 1. Load the portlet app.
> 2. Define a "page" layout nxm columns/rows.
> 3. Select portlets that I wanted to see in each cell.
> 4. Tell it to continue past a few prompts and finally display the
> "page".
>
> To me, the two platforms were about equivalent functionally for the
> tutorial topics, with J2 getting the nod in my eyes because it looked
> like a portal should look and the students would have the satisfaction
> of knowing they could write portlets on a feature rich portal
> environment. (J2 losses points overall because the install can be more
> of a headache in its current form, but we have already discussed that
> above).
>
> My point here is that J2 can scale down to just about any functional
> level... even suitable for a portlet writing tutorial straight out of
> the box. In my mind, we just need to make the man behind the curtain fit
> into your ME footprint requirements and clean up the install/build
> situation.
>
> Oh well, went a bit beyond my opening charter here... better stop now!
>
> Randy
>
>
>
Re: Aggregation Server (AKA Portal Light)
Posted by Randy Watler <wa...@wispertel.net>.
David,
I step into this thread with some trepidation, but it is done
now... :-). I'll just focus for now on what I can describe/explain
concerning J2 components and PSML. I hope simply to save others some
effort in replying... here goes...
On Sat, 2005-12-24 at 00:30 -0500, David H. DeWolf wrote:
>
> >> 3) Ability to define a "page" or grouping of portlets at runtime but
> >> have no layout associated with it.
> >>
> > Will you be using PSML or another technology?
> >
>
> Excuse my ignorance here. . .
>
> From what I've seen in jetspeed over the past week or so, PSML is a
> markup language which defines how pages are layed out. Is this correct?
> If so, then know, I'd prefer not. My idea of a page is much simpler,
> it's basically a grouping of portlets which are aggregated together. It
> contains no layout information whatsoever.
PSML contains elements that encapsulate the the following concepts:
1. Fragments that serve as the links to portlet instances.
2. Fragment hierarchies to support the J2 notion that layouts ARE
portlets.
3. Pages that contain fragments.
4. Folders that organize groups of Pages.
5. Security constraints on these basic entites.
6. Menu/Navigation declarations on these same basic entites.
7. Localized metadata for PSML elements.
Almost all of this markup is optional. If one wanted only to represent
Fragments in Pages, it would be a proper subset of PSML and could
certainly be represented by the Page Manager.
Even looking at the Geronimo Admin Console, there are many of these
concepts present... but they indeed might be coded in "content" or the
"web page" JSP/Servlet vs. being modeled as is done here with PSML. With
J2, we have tried to reduce, or even eliminate in most cases, page
content authoring external to the portlets themselves.
I can see why one might believe this solution is out of place in a
portal "ME" environment. However, what confuses me on this front is why
you would want to explicitly model the notion of a page at all? If you
start down that path, it is easy to argue for the inclusion of all or
most of PSML, (that is how I think we got there with J2). I mean to say:
isn't the notion of portlets and a web page template with embedded tags
in it where the portlets are to go sufficient in your case?
Perhaps a simple example of what you'd like a "page" to be would be very
instructive for us all. I am imagining a Aggregation Server page is
something like this:
<html>
<body>
<table>
<tr>
<aggregator:portlet
webapp="myPortletApp"
portlet="myFirstPortlet"/>
</tr>
<tr>
<aggregator:portlet
webapp="linksys"
portlet="linksys-admin"/>
</tr>
</table>
</body>
</html>
Is this the idea? To me, it looks closer to a J2 layout decorator than
J2 PSML data model... especially if you imagine our current decorator
templates written in JSP... :-)
> > Also, if you don't like the Jetspeed solution, just say so.
> > Gawd knows we are not perfect. There are problems.
> > Just speak your mind and tell us why its just unusable for a lightweight
> > portal solution.
>
> Perhaps any responses to these comments should go in another thread so
> that we don't get off track. . .
>
> I can't say I don't like jetspeed. From what I can tell, it simply does
> not meet my requirements. That said, there are two things that are not
> ideal IMHO (and perhaps my understanding is wrong and these really
> aren't issues):
>
> I don't really like is the repo layout and build -- I don't think that
> they lend themselves to easily discovering the core components of
> jetspeed. I found I had to research and look around quite a bit to feel
> like I had any clue what lived where.
Indeed, I too found the components a bit confusing when I first started
to look at J2. Some of the components also have some deps that lead to
further confusion. However, we have been improving the sitution over
time. Bridges have been pulled out. Components have been decomposed. The
core itself is now a component. It is getting better. To be honest
though... all of the components generate a separate jar in the repo and
live in a top level directory called 'components': I am not sure how to
make component discovery any easier... :-). I suppose we could make the
pipeline elements into free standing components... might that help?
If you have any ideas here, we are all ears. We know we need to simplify
the build... a task you have volunteered to lead IIRC as we move to
maven2. To be honest, builds always evolve over time and often lag
behind the product architecture. We can fix that easily!
>
> The other thing I don't like is the setup required. I'd like to be able
> to take a jetspeed war, deploy it, and go. . .I don't want to have to
> create db schemas, build for specific app servers, etc. . .before
> running. IMHO, either an installer should do that work for me, jetspeed
> should initialize itself at startup, or the default build should not
> require this prep work.
Again, we are working on this. It is convenient from a development POV
to have the build be able to deploy to the container, run integration
tests with a database, etc.. I think it is safe to say that all of these
"extensions" to the build you have listed here grew out of the
development environment we have been living in for 2 years.
J2 just had its first release and now we are working on an installer to
help take some of the "do everything" pressure off the builds. Again,
things should now get better on this front.
>
> Beside those minor things, I really have no problem with jetspeed.
That is good. You do not seem to have any issues with the product
architecture itself... other than its footprint... !ME if you will. I am
left with the impression that this is the only requirement J2 does not
meet functionally from your POV. I have to admit that if you are talking
about a "portal on a chip", anything seems heavy to me, even Pluto!
Getting back to reality, I think we need to know how severe your
footprint requirements really are. If you are truly shooting for a J2ME
environment on my refrigerator, I am not sure anything can be common
between the J2 and the Aggregation Server projects... but I dont think
that is the case really.
It seems that using J2 components that are "heavier" than you would like
would not be a problem, as long as they scaled down gracefully to your
needs. The same case can be made for the core J2 component... and that
is what I think the J2 community is trying to propose.
Let me digress...
For example... lets take the Pluto test harness example so often sited
as a reason to need something "light". During ApacheCon, I took the
writing portlets tutorial that was given by Noel. Because of a
communication problem between DST and Noel the previous day, the
tutorial was given using the Pluto test harness. Being a J2 booster, I
did the entire tutorial on J2 using our newly minted installer. Here is
all I had to do to get every sample portlet working on a running J2:
1. Copy build portlet apps into J2's deployment directory.
2. Switch the current page in J2 to edit mode.
3. Click on add portlet.
4. Select portlets I wanted to add.
5. Click Done.
Really, it is that easy! I also ran the Pluto test harness. It was less
intuitive IMO and certainly looked like a test harness rather than a
portal. I had to do something like this:
1. Load the portlet app.
2. Define a "page" layout nxm columns/rows.
3. Select portlets that I wanted to see in each cell.
4. Tell it to continue past a few prompts and finally display the
"page".
To me, the two platforms were about equivalent functionally for the
tutorial topics, with J2 getting the nod in my eyes because it looked
like a portal should look and the students would have the satisfaction
of knowing they could write portlets on a feature rich portal
environment. (J2 losses points overall because the install can be more
of a headache in its current form, but we have already discussed that
above).
My point here is that J2 can scale down to just about any functional
level... even suitable for a portlet writing tutorial straight out of
the box. In my mind, we just need to make the man behind the curtain fit
into your ME footprint requirements and clean up the install/build
situation.
Oh well, went a bit beyond my opening charter here... better stop now!
Randy
Re: Aggregation Server (AKA Portal Light)
Posted by David Sean Taylor <da...@bluesunrise.com>.
David H. DeWolf wrote:
>>> 5) Ability to have a portable solution which can be packaged as a
>>> single war (not built differently for different environments) and
>>> deployed on any compliant servlet container.
>>>
>> If its a single war file, then how will standard portlet applications
>> be deployed to a single war file solution? Will all portlet
>> applications run inside the same class loader, same session space as
>> the portal? What about resource collisions?
>>
>
> Great question. When I say "single war", I'm referring to the
> aggregation server - not necessarily the portlets. My instinct says
> that to meet this requirement a cross context dispatch must be used and
> portlets must be deployed to the app server seperately (which is
> acceptable). If anyone has a better idea - I'd LOVE to hear it.
>
We've had some success in this area.
Jetspeed has a "local" portal invoker.
We deploy portlet applications to WEB-INF/apps and run the Java portlet
code from there, each having its own class loader.
This seems to work fine, under certain 'conventions', mainly that you
put the resources (JSPs, images, HTML...) in a common area under the
portal's web application. We still keep a separate class loader for each
portlet application, however the resources are shared and the big
problem with this is collisions. Perhaps we could enforce a name space
for resources...
> For one of the solutions, this is for an admin console which is embedded
> in a device. Think of a generic linksys router and the web console that
> comes with it and then imagine that more than one entity is providing
> different aspects of the management console. B/C it's embeded,
> resources are limited and we'd like to keep it as small as possible.
>
That seems like a valid use case.
> Because of these use cases, this isn't a traditional portal so I don't
> see "users" wanting more. That said, that is always a temptation, but
> one that we've purposely decided to shun.
>
>>
>> I keep repeating myself here, I think a light-weight portal is
>> questionable as its the natural progression of the portal space to
>> integrate with technologies and "grow". The end result will be two
>> portal solutions for Apache Portals. Maybe we should ask ourselves the
>> question first before going on:
>>
>> Do we want to have more than one portal solution at Apache Portals?
>>
>
> I think that's a very fair question. I have no problem if the answer is
> no. *If* we can maintain scope and keep this solution light weight, I
> do believe that a second "light weight" portal may help jetspeed. The
> reason is that it *may* attract more users to the portal world (perhaps
> because it lowers the cost of entry - and no, that's not being critical
> of jetspeed, just something we should think about and evaluate). Once
> this attraction occurs and users begin to ask for more, we simply say -
> hey - look at jetspeed and hopefully provide them an upgrade path.
>
> At the same time, *If* we allow this light solution to grow outside of
> the original scope, there is no doubt that it will detract from
> jetspeed. If we as a community believe that my use cases and
> requirements are unique enough that they don't warrent a solution within
> apache portals, I take no offense.
>
>> Frankly, we don't even have enough committers for any of our projects
>> right now. That is a concern to me, even without the additional
>> maintenance of 4th portal solution here.
>
>
> Fair enough. We at Pluto know all about lack of committers :)
>
I know and you have a great point there.
We need more Jetspeed committers getting involved in Pluto.
We all need to review Pluto 1.1 over the next few weeks.
IF any of you out there have not reviewed 1.1, please do so !
David has refactored Pluto to a much more manageable codebase.
We should all give it a thorough code review.
>> I believe that would be a more "synergized" and community building,
>> rather than community splintering approach. Now this implies that your
>> solution is community-splintering. And frankly, that is not fair at
>> all, to simply imply it. So please, tell us how Jetspeed Components
>> and the Jetspeed team of developers and contributors fit in with this
>> solution, and how we won't feel that we are being ignored and stepped
>> over and splintered?
>
>
> On one hand, I'm not sure how this affects the current make up of
> portals at all. If the jetspeed team has no interest, either nothing
> changes or the pluto portal driver moves outside of pluto and jetspeed
> still isn't affected since none of the active pluto developers are
> active in jetspeed anyways.
>
> On the other hand, I'd very much like to see this be the bridge between
> the two projects. *If* we can find a way for the two teams to
> collaborate I would absolutely love it. I'm very willing to dump the
> pluto portal driver and use jetspeed components instead (though I do
> have a strong preference to the pluto 1.1 container). If that approach
> was chosen, I would think it would be natural for jetspeed to be an
> extension of "the aggregation server". That said, I definately
> understand how that comment may ruffle some feathers - especially
> considering that I have similar feelings regarding "dumping" pluto and
> am only putting that on the table since I know it may be best for the
> community.
>
Well, Im willing to consider creating a Jetspeed Components subproject.
>
>>
>> Also, if you don't like the Jetspeed solution, just say so.
>> Gawd knows we are not perfect. There are problems.
>> Just speak your mind and tell us why its just unusable for a
>> lightweight portal solution.
>
>
> Perhaps any responses to these comments should go in another thread so
> that we don't get off track. . .
>
> I can't say I don't like jetspeed. From what I can tell, it simply does
> not meet my requirements. That said, there are two things that are not
> ideal IMHO (and perhaps my understanding is wrong and these really
> aren't issues):
>
> I don't really like is the repo layout and build -- I don't think that
> they lend themselves to easily discovering the core components of
> jetspeed. I found I had to research and look around quite a bit to feel
> like I had any clue what lived where.
>
Fair enough. Perhaps a re-org of Jetspeed would help, as I mentioned
above, moving the components to a Jetspeed Components subproject.
> The other thing I don't like is the setup required. I'd like to be able
> to take a jetspeed war, deploy it, and go. . .I don't want to have to
> create db schemas, build for specific app servers, etc. . .before
> running. IMHO, either an installer should do that work for me, jetspeed
> should initialize itself at startup, or the default build should not
> require this prep work.
The new installer does all of that.
>
> Beside those minor things, I really have no problem with jetspeed.
>
I agree with you. I find the Jetspeed plugin and build to be lacking
>>
>> Finally, are you willing to base your portal on the Jetspeed API?
>
>
> Yes, as long as it doesn't have a whole ton of dependencies, a lot of
> service interfaces that the core is dependent upon but I don't need, and
> the concept of pages and page layouts (PSML) are seperated from each other.
>
The API is pretty lightly coupled, we hope.
I think it would be worth trying
Im on vacation this week, but I'll be back Friday and can start helping then
Re: Aggregation Server (AKA Portal Light)
Posted by "David H. DeWolf" <dd...@apache.org>.
David Sean Taylor wrote:
> Im going to make an effort to try again to respond.
> Im willing to forgive and forget what was said on the ill-fated last
> thread.
>
> Please, (me included) this time lets try to stay on a topic and try not
> to get personal.
Sounds good to me.
>
>
> David H. DeWolf wrote:
>
>> I, (in the past and now as well) have a need for a "light weight" portal
>
>
> Are there others in your community? I believe there are now two people
> in your community that I am aware of, yourself and Raphael Luta. Others
> please speak up.
>
There are some that I think may be interested that participate on the
pluto dev list (we've had a recent flux of activity from new members),
but I'll go ahead and let them speak for themselves.
It goes without saying that if I'm the only one that has these
requirements, it may be silly to open source this. That said, it seems
to me that this is also the minimum required for development and
testing, so there may be uses outside of what I'm using this type of
solution for.
>> solution. This light weight portal solution is basically an
>> "aggregation server". I consider it more like a simple wrapper around
>> the portlet container. It provides the following:
>>
>> 1) Ability to invoke portlets and include their content into a webapp
>> in a compliant manner.
>>
>> 2) Ability to manage a "portlet registry" at runtime.
>
>
> Could you elaborate more ....
>
Sure, basically, the aggregation server needs to know which portlets are
available to it's disposal. In my mind, the portlet registry is
provided to store this information. Administration tools may be
available to manipulate this info.
>>
>> 3) Ability to define a "page" or grouping of portlets at runtime but
>> have no layout associated with it.
>>
> Will you be using PSML or another technology?
>
Excuse my ignorance here. . .
From what I've seen in jetspeed over the past week or so, PSML is a
markup language which defines how pages are layed out. Is this correct?
If so, then know, I'd prefer not. My idea of a page is much simpler,
it's basically a grouping of portlets which are aggregated together. It
contains no layout information whatsoever.
>> 4) Ability to customize rendering using different technologies (simple
>> jsp, a servlet, velocity, etc. . .) without having to jump through
>> hoops. Custom tags to insert rendering such as the <pluto:render> tag
>> would be nice.
>>
> Does this include a UI customizer component, or a simple, JSP editor as
> the customizer?
No, I do not envision the ui being able to be adjusted. The only
modification to pages would be the portlets which are actually grouped
together on a page. In other words, a grouping of portlets could be
modified, but how they are layed out and their look and feel would not be.
>
>> 5) Ability to have a portable solution which can be packaged as a
>> single war (not built differently for different environments) and
>> deployed on any compliant servlet container.
>>
> If its a single war file, then how will standard portlet applications be
> deployed to a single war file solution? Will all portlet applications
> run inside the same class loader, same session space as the portal? What
> about resource collisions?
>
Great question. When I say "single war", I'm referring to the
aggregation server - not necessarily the portlets. My instinct says
that to meet this requirement a cross context dispatch must be used and
portlets must be deployed to the app server seperately (which is
acceptable). If anyone has a better idea - I'd LOVE to hear it.
> Will it require a database? I have found that databases can complicate
> things and quickly add layers of fluff.
Ya, I'm struggling with this question myself. Currently what we have
done in pluto does use a database to allow for the portlet registry and
page registry (groupings) to be dynamic. That said, I go back and forth
almost every day wondering how much I like this. The other solution
I've kicked around is to serialize xml for these. . .again, this is an
area I'd love to discuss with others and make a community descision.
>
> Will it support Derby, or all flavors of databases?
>
If we support derby, I'd assume we'd support any jdbc connection through
a datasource simply b/c it's simple to do. But, by no means is that I
requirements that I have.
> Will you use the DAO classes from Pluto, or will you use an existing DAO
> or ORM solution?
I like the pure dao's b/c they don't add unecessary dependencies,
however, I don't like the bloat that comes with sql. I've considered
iBatis, am not a huge fan of OJB and we can't use hibernate. I'm open
to whatever others think. Again, collaboration will help us find the
best solution -- and perhaps this isn't even a discussion point if we do
away with the db all together.
>
> Will users and credentials be stored? If yes, in a database, XML?
No, In my perfect world it would rely 100% on the app servers security
mechanisms.
>
>
>> There may be one or two additional requirements that I'm not thinking
>> of right now, but literally, this is a very simple portal solution and
>> needs to be void of additional "fluff". The solution does not need to
>> include any other "value added" services - and it would be a pretty
>> big negative if it did.
>>
> How do you intend to keep the solution light weight?
> That seems like a double-edged sword. Your user base will ask for more
> features, but you will be locked to a light-weight philosophy. Will your
> charter build in the ability to "grow" to a medium-weight or
> heavy-weight portal?
Well, for both applications that I'm using this solution for, this isn't
really a portal. It more of a webapp which I must be able to easily
plug in components to - many of which come from external sources and I
don't develop. The solution is similar to what Geronimo is doing (hence
my interest), and what Felix has mentioned wanting to do.
For one of the solutions, this is for an admin console which is embedded
in a device. Think of a generic linksys router and the web console that
comes with it and then imagine that more than one entity is providing
different aspects of the management console. B/C it's embeded,
resources are limited and we'd like to keep it as small as possible.
Because of these use cases, this isn't a traditional portal so I don't
see "users" wanting more. That said, that is always a temptation, but
one that we've purposely decided to shun.
>
> I keep repeating myself here, I think a light-weight portal is
> questionable as its the natural progression of the portal space to
> integrate with technologies and "grow". The end result will be two
> portal solutions for Apache Portals. Maybe we should ask ourselves the
> question first before going on:
>
> Do we want to have more than one portal solution at Apache Portals?
>
I think that's a very fair question. I have no problem if the answer is
no. *If* we can maintain scope and keep this solution light weight, I
do believe that a second "light weight" portal may help jetspeed. The
reason is that it *may* attract more users to the portal world (perhaps
because it lowers the cost of entry - and no, that's not being critical
of jetspeed, just something we should think about and evaluate). Once
this attraction occurs and users begin to ask for more, we simply say -
hey - look at jetspeed and hopefully provide them an upgrade path.
At the same time, *If* we allow this light solution to grow outside of
the original scope, there is no doubt that it will detract from
jetspeed. If we as a community believe that my use cases and
requirements are unique enough that they don't warrent a solution within
apache portals, I take no offense.
> Frankly, we don't even have enough committers for any of our projects
> right now. That is a concern to me, even without the additional
> maintenance of 4th portal solution here.
Fair enough. We at Pluto know all about lack of committers :)
>
>> I have been developing this solution in Pluto, however, at apachecon,
>> I got wind of the fact that some people may not be comfortable with
>> this and would prefer that the test driver does not include things
>> such as #2 and #3 above (and perhaps others). The solution needs to
>> be of production strength.
>>
>> Would others please provide their ideas on where the best place for
>> this solution is, whether it may be provided in a solution we allready
>> have (besides the pluto portal in question), and how we should move
>> forward?
>>
> I will be proposing a Jetspeed Lite Edition on this email list as a
> solution using Jetspeed technologies to assemble a light weight portal.
>
> I believe that would be a more "synergized" and community building,
> rather than community splintering approach. Now this implies that your
> solution is community-splintering. And frankly, that is not fair at all,
> to simply imply it. So please, tell us how Jetspeed Components and the
> Jetspeed team of developers and contributors fit in with this solution,
> and how we won't feel that we are being ignored and stepped over and
> splintered?
On one hand, I'm not sure how this affects the current make up of
portals at all. If the jetspeed team has no interest, either nothing
changes or the pluto portal driver moves outside of pluto and jetspeed
still isn't affected since none of the active pluto developers are
active in jetspeed anyways.
On the other hand, I'd very much like to see this be the bridge between
the two projects. *If* we can find a way for the two teams to
collaborate I would absolutely love it. I'm very willing to dump the
pluto portal driver and use jetspeed components instead (though I do
have a strong preference to the pluto 1.1 container). If that approach
was chosen, I would think it would be natural for jetspeed to be an
extension of "the aggregation server". That said, I definately
understand how that comment may ruffle some feathers - especially
considering that I have similar feelings regarding "dumping" pluto and
am only putting that on the table since I know it may be best for the
community.
>
> Also, if you don't like the Jetspeed solution, just say so.
> Gawd knows we are not perfect. There are problems.
> Just speak your mind and tell us why its just unusable for a lightweight
> portal solution.
Perhaps any responses to these comments should go in another thread so
that we don't get off track. . .
I can't say I don't like jetspeed. From what I can tell, it simply does
not meet my requirements. That said, there are two things that are not
ideal IMHO (and perhaps my understanding is wrong and these really
aren't issues):
I don't really like is the repo layout and build -- I don't think that
they lend themselves to easily discovering the core components of
jetspeed. I found I had to research and look around quite a bit to feel
like I had any clue what lived where.
The other thing I don't like is the setup required. I'd like to be able
to take a jetspeed war, deploy it, and go. . .I don't want to have to
create db schemas, build for specific app servers, etc. . .before
running. IMHO, either an installer should do that work for me, jetspeed
should initialize itself at startup, or the default build should not
require this prep work.
Beside those minor things, I really have no problem with jetspeed.
>
> Finally, are you willing to base your portal on the Jetspeed API?
Yes, as long as it doesn't have a whole ton of dependencies, a lot of
service interfaces that the core is dependent upon but I don't need, and
the concept of pages and page layouts (PSML) are seperated from each other.
>
> I welcome your enthusiasm, and as I told you at ApacheCon, for what its
> worth, I fully support your efforts to develop portal technology here at
> Apache Portals. I just want to make sure that the portals community
> stands behind your proposal, and that we don't dismiss existing solutions.
>
Thanks. That's much appreciated and I know you mean it.
> I don't want to see the community splintered.
I agree. Quite frankly, I allready feel like a lone ranger over at
pluto and whether you believe it or not, my original proposal was meant
to be a community building effort - NOT a splintering one :)
>
> I really don't want to see two completely different Java portal
> technologies at Apache Portals. I think that is the wrong message.
I understand. Perhaps my problem is that I'm not really looking for a
portal - I'm looking for an aggregation server which utilizes the
portlet spec for it's disperate content.
>
> However, if there are those here in the community who feel that Jetspeed
> is the wrong technology, then just stop beating around the bush and say
> so. Because in the long run, I don't think this is really about a
> light-weight portal. I just cannot see (see my comments above) how a
> portal can stay light-weight and maintain the requirements and needs of
> a valid user base and community.
Hopefully I explained why *I don't think* jetspeed meets my requirements
above. This REALLY IS about a light weight portal to me. If you think
my requirements are so unique that it doesn't warrent the attention it's
getting. . .just say so and we can drop it.
>
>
>
>
>
>
Re: Aggregation Server (AKA Portal Light)
Posted by David Sean Taylor <da...@bluesunrise.com>.
Im going to make an effort to try again to respond.
Im willing to forgive and forget what was said on the ill-fated last thread.
Please, (me included) this time lets try to stay on a topic and try not
to get personal.
David H. DeWolf wrote:
> I, (in the past and now as well) have a need for a "light weight" portal
Are there others in your community? I believe there are now two people
in your community that I am aware of, yourself and Raphael Luta. Others
please speak up.
> solution. This light weight portal solution is basically an
> "aggregation server". I consider it more like a simple wrapper around
> the portlet container. It provides the following:
>
> 1) Ability to invoke portlets and include their content into a webapp in
> a compliant manner.
>
> 2) Ability to manage a "portlet registry" at runtime.
Could you elaborate more ....
>
> 3) Ability to define a "page" or grouping of portlets at runtime but
> have no layout associated with it.
>
Will you be using PSML or another technology?
> 4) Ability to customize rendering using different technologies (simple
> jsp, a servlet, velocity, etc. . .) without having to jump through
> hoops. Custom tags to insert rendering such as the <pluto:render> tag
> would be nice.
>
Does this include a UI customizer component, or a simple, JSP editor as
the customizer?
> 5) Ability to have a portable solution which can be packaged as a single
> war (not built differently for different environments) and deployed on
> any compliant servlet container.
>
If its a single war file, then how will standard portlet applications be
deployed to a single war file solution? Will all portlet applications
run inside the same class loader, same session space as the portal? What
about resource collisions?
Will it require a database? I have found that databases can complicate
things and quickly add layers of fluff.
Will it support Derby, or all flavors of databases?
Will you use the DAO classes from Pluto, or will you use an existing DAO
or ORM solution?
Will users and credentials be stored? If yes, in a database, XML?
> There may be one or two additional requirements that I'm not thinking of
> right now, but literally, this is a very simple portal solution and
> needs to be void of additional "fluff". The solution does not need to
> include any other "value added" services - and it would be a pretty big
> negative if it did.
>
How do you intend to keep the solution light weight?
That seems like a double-edged sword. Your user base will ask for more
features, but you will be locked to a light-weight philosophy. Will your
charter build in the ability to "grow" to a medium-weight or
heavy-weight portal?
I keep repeating myself here, I think a light-weight portal is
questionable as its the natural progression of the portal space to
integrate with technologies and "grow". The end result will be two
portal solutions for Apache Portals. Maybe we should ask ourselves the
question first before going on:
Do we want to have more than one portal solution at Apache Portals?
Frankly, we don't even have enough committers for any of our projects
right now. That is a concern to me, even without the additional
maintenance of 4th portal solution here.
> I have been developing this solution in Pluto, however, at apachecon, I
> got wind of the fact that some people may not be comfortable with this
> and would prefer that the test driver does not include things such as #2
> and #3 above (and perhaps others). The solution needs to be of
> production strength.
>
> Would others please provide their ideas on where the best place for this
> solution is, whether it may be provided in a solution we allready have
> (besides the pluto portal in question), and how we should move forward?
>
I will be proposing a Jetspeed Lite Edition on this email list as a
solution using Jetspeed technologies to assemble a light weight portal.
I believe that would be a more "synergized" and community building,
rather than community splintering approach. Now this implies that your
solution is community-splintering. And frankly, that is not fair at all,
to simply imply it. So please, tell us how Jetspeed Components and the
Jetspeed team of developers and contributors fit in with this solution,
and how we won't feel that we are being ignored and stepped over and
splintered?
Also, if you don't like the Jetspeed solution, just say so.
Gawd knows we are not perfect. There are problems.
Just speak your mind and tell us why its just unusable for a lightweight
portal solution.
Finally, are you willing to base your portal on the Jetspeed API?
I welcome your enthusiasm, and as I told you at ApacheCon, for what its
worth, I fully support your efforts to develop portal technology here at
Apache Portals. I just want to make sure that the portals community
stands behind your proposal, and that we don't dismiss existing solutions.
I don't want to see the community splintered.
I really don't want to see two completely different Java portal
technologies at Apache Portals. I think that is the wrong message.
However, if there are those here in the community who feel that Jetspeed
is the wrong technology, then just stop beating around the bush and say
so. Because in the long run, I don't think this is really about a
light-weight portal. I just cannot see (see my comments above) how a
portal can stay light-weight and maintain the requirements and needs of
a valid user base and community.