You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Glenn R. Golden" <gg...@umich.edu> on 2003/10/03 04:08:14 UTC
[Pluto] basic architecture
This is my current understanding of a 168 Pluto based portal
implementation, I just want to see if I'm on a boat with any other
passengers here...
The whole thing (Portal, Portlets, Servlets, Jsp, etc) is running in a
Java Servlet/Jsp Web application server (i.e. Tomcat).
The entire Portal is one webapp. It has it's own folder under
tomcat/webapps, and the standard isolation from other webapps.
The Portlets that will be running in the portal are in one or more
other webapps. Sets of portlets live in a webapp, along with
(optionally) some servlets, jsp, static content, etc. There may be
many sets of portlets, each in a different webapp. Each with it's own
.war, folder under tomcat/webapps, isolation from other webapps, etc.
The Portal Administrator installs the portal webapp. She installs each
webapp of sets of portlets that will be available (probably via tools
in the portal). She informs the portal (somehow) of the existence of
these sets of portlets in these other webapps. Then she uses the
portal tools to configure the portal pages, etc.
Different webapp sets of portlets are running in their own class
loader, so jar versions and static classes are not in conflict between
them. Also, they cannot share static classes, such as common services
(such as provided by Pluto or Turbine or Avalon). As a request is
processed, and a servlet context request dispatcher is used to pass the
pen from one portlet to another to aggregate the response, the servlet
request *is* common, and anything placed in there (such as a service
manager) would be shared by all the portlets even across different
webapps. [I'm a little blurry on this whole point.]
Yes?
If I'm close here, then...
I wonder if there's a way for the Portal to query the "tomcat" to get
the list of available portlets, so that we can just drop in a (properly
prepared) .war and the portal knows it's there?
Is there a way to have a common Avalon-ish service framework among all
webapps, or are they kept separated?
Thanks.
- Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Thu, 2 Oct 2003, Glenn R. Golden wrote:
| This is my current understanding of a 168 Pluto based portal
| implementation, I just want to see if I'm on a boat with any other
| passengers here...
|
| The whole thing (Portal, Portlets, Servlets, Jsp, etc) is running in a
| Java Servlet/Jsp Web application server (i.e. Tomcat).
|
| The entire Portal is one webapp. It has it's own folder under
| tomcat/webapps, and the standard isolation from other webapps.
|
| The Portlets that will be running in the portal are in one or more
| other webapps. Sets of portlets live in a webapp, along with
| (optionally) some servlets, jsp, static content, etc. There may be
| many sets of portlets, each in a different webapp. Each with it's own
| .war, folder under tomcat/webapps, isolation from other webapps, etc.
|
| The Portal Administrator installs the portal webapp. She installs each
| webapp of sets of portlets that will be available (probably via tools
| in the portal). She informs the portal (somehow) of the existence of
| these sets of portlets in these other webapps. Then she uses the
| portal tools to configure the portal pages, etc.
The question here is: does Pluto "hook into" the internals of Tomcat? See,
I can't understand anything else. Wars have separation, and since a Portal
App is a Web App, then Pluto and Tomcat must reside "on the same level",
right?
|
| Different webapp sets of portlets are running in their own class
| loader, so jar versions and static classes are not in conflict between
| them. Also, they cannot share static classes, such as common services
| (such as provided by Pluto or Turbine or Avalon). As a request is
| processed, and a servlet context request dispatcher is used to pass the
| pen from one portlet to another to aggregate the response, the servlet
| request *is* common, and anything placed in there (such as a service
| manager) would be shared by all the portlets even across different
| webapps. [I'm a little blurry on this whole point.]
|
| Yes?
|
| If I'm close here, then...
|
| I wonder if there's a way for the Portal to query the "tomcat" to get
| the list of available portlets, so that we can just drop in a (properly
| prepared) .war and the portal knows it's there?
|
| Is there a way to have a common Avalon-ish service framework among all
| webapps, or are they kept separated?
|
| Thanks.
|
| - Glenn
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
|
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Mon, 6 Oct 2003, Stefan Hepper wrote:
| As Steven already noted, pluto needs to be in the shared app to allow
| the wrapper servlet that puto puts into the portlet web apps access to
| the pluto classes.
|
| Currently we've tried to not use any interals of tomcat to get pluto
| running and I would like to stick to this design descission to allow
| pluto to run on other app servers besides tomcat and to prove that the
| portlet spec does not require internals of the app server for the
| implementation.
Excellent! :)
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by Stefan Hepper <st...@hursley.ibm.com>.
As Steven already noted, pluto needs to be in the shared app to allow
the wrapper servlet that puto puts into the portlet web apps access to
the pluto classes.
Currently we've tried to not use any interals of tomcat to get pluto
running and I would like to stick to this design descission to allow
pluto to run on other app servers besides tomcat and to prove that the
portlet spec does not require internals of the app server for the
implementation.
Regards,
Stefan
Glenn R. Golden wrote:
> This is my current understanding of a 168 Pluto based portal
> implementation, I just want to see if I'm on a boat with any other
> passengers here...
>
> The whole thing (Portal, Portlets, Servlets, Jsp, etc) is running in a
> Java Servlet/Jsp Web application server (i.e. Tomcat).
>
> The entire Portal is one webapp. It has it's own folder under
> tomcat/webapps, and the standard isolation from other webapps.
>
> The Portlets that will be running in the portal are in one or more
> other webapps. Sets of portlets live in a webapp, along with
> (optionally) some servlets, jsp, static content, etc. There may be
> many sets of portlets, each in a different webapp. Each with it's own
> .war, folder under tomcat/webapps, isolation from other webapps, etc.
>
> The Portal Administrator installs the portal webapp. She installs
> each webapp of sets of portlets that will be available (probably via
> tools in the portal). She informs the portal (somehow) of the
> existence of these sets of portlets in these other webapps. Then she
> uses the portal tools to configure the portal pages, etc.
>
> Different webapp sets of portlets are running in their own class
> loader, so jar versions and static classes are not in conflict between
> them. Also, they cannot share static classes, such as common services
> (such as provided by Pluto or Turbine or Avalon). As a request is
> processed, and a servlet context request dispatcher is used to pass
> the pen from one portlet to another to aggregate the response, the
> servlet request *is* common, and anything placed in there (such as a
> service manager) would be shared by all the portlets even across
> different webapps. [I'm a little blurry on this whole point.]
>
> Yes?
>
> If I'm close here, then...
>
> I wonder if there's a way for the Portal to query the "tomcat" to get
> the list of available portlets, so that we can just drop in a
> (properly prepared) .war and the portal knows it's there?
>
> Is there a way to have a common Avalon-ish service framework among all
> webapps, or are they kept separated?
>
> Thanks.
>
> - Glenn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by "Glenn R. Golden" <gg...@umich.edu>.
The thing I like most about Avalon is the Framework - it lays out the
needs of a pluggable service environment very well, and it's rather
mature. I'm not committed to any of the Avalon container
implementations yet. That's why I think of it as a "cover" or API only.
I'll know more soon about how good it's model is, and about the modern
containers (fortress and merlin).
- Glenn
On Friday, October 3, 2003, at 01:36 PM, David Sean Taylor wrote:
>
> On Friday, October 3, 2003, at 10:21 AM, Glenn R. Golden wrote:
>
>> Are you open to considering just using Avalon framework as the
>> standard service API for JS2, and then using some Avalon container
>> (Forest, Merlin) or one we build ourself for the actual container
>> impl? I don't see why we need yet another cover, even if Pluto is
>> using it. Let Pluto do what it wants, but JS could use Avalon.
>>
> Yes I am open to it but
> I tried using Avalon earlier this year for the service framework.
> It was mostly deprecated without replacements.
> Are you actively using Avalon now?
> We need to discuss its benefits over Fulcrum or Hivemind or
> PicoContainer. or ...
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
> +01 707 529 9194
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Friday, October 3, 2003, at 10:21 AM, Glenn R. Golden wrote:
> Are you open to considering just using Avalon framework as the
> standard service API for JS2, and then using some Avalon container
> (Forest, Merlin) or one we build ourself for the actual container
> impl? I don't see why we need yet another cover, even if Pluto is
> using it. Let Pluto do what it wants, but JS could use Avalon.
>
Yes I am open to it but
I tried using Avalon earlier this year for the service framework.
It was mostly deprecated without replacements.
Are you actively using Avalon now?
We need to discuss its benefits over Fulcrum or Hivemind or
PicoContainer. or ...
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by "Glenn R. Golden" <gg...@umich.edu>.
Are you open to considering just using Avalon framework as the standard
service API for JS2, and then using some Avalon container (Forest,
Merlin) or one we build ourself for the actual container impl? I don't
see why we need yet another cover, even if Pluto is using it. Let
Pluto do what it wants, but JS could use Avalon.
- Glenn
On Friday, October 3, 2003, at 10:50 AM, David Sean Taylor wrote:
>
> On Thursday, October 2, 2003, at 07:08 PM, Glenn R. Golden wrote:
>
>> This is my current understanding of a 168 Pluto based portal
>> implementation, I just want to see if I'm on a boat with any other
>> passengers here...
>>
>> The whole thing (Portal, Portlets, Servlets, Jsp, etc) is running in
>> a Java Servlet/Jsp Web application server (i.e. Tomcat).
>>
>> The entire Portal is one webapp. It has it's own folder under
>> tomcat/webapps, and the standard isolation from other webapps.
>>
>> The Portlets that will be running in the portal are in one or more
>> other webapps. Sets of portlets live in a webapp, along with
>> (optionally) some servlets, jsp, static content, etc. There may be
>> many sets of portlets, each in a different webapp. Each with it's
>> own .war, folder under tomcat/webapps, isolation from other webapps,
>> etc.
>>
>> The Portal Administrator installs the portal webapp. She installs
>> each webapp of sets of portlets that will be available (probably via
>> tools in the portal). She informs the portal (somehow) of the
>> existence of these sets of portlets in these other webapps. Then she
>> uses the portal tools to configure the portal pages, etc.
>>
>> Different webapp sets of portlets are running in their own class
>> loader, so jar versions and static classes are not in conflict
>> between them. Also, they cannot share static classes, such as common
>> services (such as provided by Pluto or Turbine or Avalon). As a
>> request is processed, and a servlet context request dispatcher is
>> used to pass the pen from one portlet to another to aggregate the
>> response, the servlet request *is* common, and anything placed in
>> there (such as a service manager) would be shared by all the portlets
>> even across different webapps. [I'm a little blurry on this whole
>> point.]
>>
>> Yes?
>>
>> If I'm close here, then...
>>
>> I wonder if there's a way for the Portal to query the "tomcat" to get
>> the list of available portlets, so that we can just drop in a
>> (properly prepared) .war and the portal knows it's there?
>
> Jetspeed-2 provides a registry of all portlets in all web applications.
> Unlike Jetspeed-1, the registry is stored entirely in the database.
> You can access the registry with JMX.
>
>>
>> Is there a way to have a common Avalon-ish service framework among
>> all webapps, or are they kept separated?
>>
> Again, I will answer for J2 if you don't mind.
> CPS - Common Portlet Services is a light wrapper over Fulcrum.
> We are currently discussing the best service framework to replace
> Fulcrum.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
> +01 707 529 9194
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [Pluto] basic architecture
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Thursday, October 2, 2003, at 07:08 PM, Glenn R. Golden wrote:
> This is my current understanding of a 168 Pluto based portal
> implementation, I just want to see if I'm on a boat with any other
> passengers here...
>
> The whole thing (Portal, Portlets, Servlets, Jsp, etc) is running in a
> Java Servlet/Jsp Web application server (i.e. Tomcat).
>
> The entire Portal is one webapp. It has it's own folder under
> tomcat/webapps, and the standard isolation from other webapps.
>
> The Portlets that will be running in the portal are in one or more
> other webapps. Sets of portlets live in a webapp, along with
> (optionally) some servlets, jsp, static content, etc. There may be
> many sets of portlets, each in a different webapp. Each with it's own
> .war, folder under tomcat/webapps, isolation from other webapps, etc.
>
> The Portal Administrator installs the portal webapp. She installs
> each webapp of sets of portlets that will be available (probably via
> tools in the portal). She informs the portal (somehow) of the
> existence of these sets of portlets in these other webapps. Then she
> uses the portal tools to configure the portal pages, etc.
>
> Different webapp sets of portlets are running in their own class
> loader, so jar versions and static classes are not in conflict between
> them. Also, they cannot share static classes, such as common services
> (such as provided by Pluto or Turbine or Avalon). As a request is
> processed, and a servlet context request dispatcher is used to pass
> the pen from one portlet to another to aggregate the response, the
> servlet request *is* common, and anything placed in there (such as a
> service manager) would be shared by all the portlets even across
> different webapps. [I'm a little blurry on this whole point.]
>
> Yes?
>
> If I'm close here, then...
>
> I wonder if there's a way for the Portal to query the "tomcat" to get
> the list of available portlets, so that we can just drop in a
> (properly prepared) .war and the portal knows it's there?
Jetspeed-2 provides a registry of all portlets in all web applications.
Unlike Jetspeed-1, the registry is stored entirely in the database.
You can access the registry with JMX.
>
> Is there a way to have a common Avalon-ish service framework among all
> webapps, or are they kept separated?
>
Again, I will answer for J2 if you don't mind.
CPS - Common Portlet Services is a light wrapper over Fulcrum.
We are currently discussing the best service framework to replace
Fulcrum.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org