You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Stephan Hesmer <sh...@apache.org> on 2004/02/26 20:29:36 UTC
Clarification on Container Services
David and others,
I am sorry to answer you guys so late, but I have been quite busy these
days.
There have been a lot of discussions about the Container Services
introduced within pluto. Let me try to clarify some of the points David
brought up and also try to differentiate between the concept and the way
it is implemented.
We all agree on the concept of the Container Services. They provide a
simple plug point to make the portlet container implementation
independent from the portal it is running in. This was one major goal
from the beginning of the creation of pluto. We wanted to make pluto as
reusable as possible, so that other projects and portals like Jetspeed
could reuse pluto's portlet container.
What was discussed on the other side, was how the container services are
actually implemented. This is a point worth of investigating - and I
come to that later. However, we should proceed very carefully and not
make hasty decisions. Thanks David to be careful so far and asking the
community before changing anything! You also brought up the problematic
point. There have been some design requirements about the implementation
that have not been documented :-( (That would be my fault)
These are the design requirements that are important for our discussion
(Stefan, Michael, if you recall others please feel free to add or correct)
1. Container Services are scoped per container
2. Container Services must be easy to use from within the container (as
well as accessible everywhere)
One use case that we tried often during development of pluto was to use
pluto's portlet container for the WSRP implementation as well.
Most discussions have been around the ThreadLocals. Some points David
brought up are simply bugs.
The reason I have chosen ThreadLocales for the beginning was the design
requirement (2). It is much more convenient for a developer to simply write
Debug.log
instead of
Debug.get(someContext).log
Additionally, it is nearly guaranteed that this can be used in every
method, even though the someContext has not been passed. Otherwise, we
would have to pass someContext into every method and add it to every
signature that we have in the portlet container.
Before everybody starts shouting ;-), I have to say that we also saw
some problems with using threadlocales.
Does anybody have a better solution than passing someContext everywhere
around in the portlet container ?
Bye
Stephan
Re: contenttype
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Zsofi wrote:
> Hello!
>
> I m not really understand the getter and setter method of the content type
> in the RenderResponseImpl class. Because when I set a contenttype, and I
> want to get it may give me a different one. I hope that someone can explain
> me why it is good for me, and what the point is.
>
> public String getContentType() {
> if (!isContentTypeSet) {
> return null;
> }
> return
> InformationProviderAccess.getDynamicProvider(getHttpServletRequest()).getRes
> ponseContentType();
> }
>
> public void setContentType(String type) {
> String mimeType = stripCharacterEncoding(type);
> if (!isValidContentType(mimeType)) {
> throw new IllegalArgumentException(mimeType);
> }
> this._getHttpServletResponse().setContentType(mimeType);
> isContentTypeSet = true;
> }
>
>
> In the portlet Api:
> setContentType:
> Sets the MIME type for the render response. The portlet must set the content
> type before calling getWriter() or getPortletOutputStream().
> Calling setContentType after getWriter or getOutputStream does not change
> the content type.
>
> getContentType:
> public java.lang.String getContentType()Returns the MIME type that can be
> used to contribute markup to the render response.
> If no content type was set previously using the
> setContentType(java.lang.String) method this method retuns null.
>
> The specification:
>
> A portlet must set the content type of the response using the setContentType
> method of
> the RenderResponse interface. The setContentType method must throw an
> IllegalArgumentException if the content type set does not match (including
> wildcard
> matching) any of the content types returned by the getResponseContentType
> method of
> the PortleRequest objectl. The portlet container should ignore any character
> encoding specified as part of the content type.
> If the getWriter or getPortletOutputStream methods are called before the
> setContentType method, they must throw an IllegalStateException.
> The setContentType method must be called before the getWriter or
> getPortletOutputStream methods. If called after, it should be ignored.
> If the portlet has set a content type, the getContentType method must return
> it.
> Otherwise, the getContentType method must return null.
>
> Do they mean the same?
>
>
> Thanks: zsofi
>
>
Thanks for catching that. This is an error, I'll fix this.
Stefan
contenttype
Posted by Zsofi <zs...@rndsoft.hu>.
Hello!
I m not really understand the getter and setter method of the content type
in the RenderResponseImpl class. Because when I set a contenttype, and I
want to get it may give me a different one. I hope that someone can explain
me why it is good for me, and what the point is.
public String getContentType() {
if (!isContentTypeSet) {
return null;
}
return
InformationProviderAccess.getDynamicProvider(getHttpServletRequest()).getRes
ponseContentType();
}
public void setContentType(String type) {
String mimeType = stripCharacterEncoding(type);
if (!isValidContentType(mimeType)) {
throw new IllegalArgumentException(mimeType);
}
this._getHttpServletResponse().setContentType(mimeType);
isContentTypeSet = true;
}
In the portlet Api:
setContentType:
Sets the MIME type for the render response. The portlet must set the content
type before calling getWriter() or getPortletOutputStream().
Calling setContentType after getWriter or getOutputStream does not change
the content type.
getContentType:
public java.lang.String getContentType()Returns the MIME type that can be
used to contribute markup to the render response.
If no content type was set previously using the
setContentType(java.lang.String) method this method retuns null.
The specification:
A portlet must set the content type of the response using the setContentType
method of
the RenderResponse interface. The setContentType method must throw an
IllegalArgumentException if the content type set does not match (including
wildcard
matching) any of the content types returned by the getResponseContentType
method of
the PortleRequest objectl. The portlet container should ignore any character
encoding specified as part of the content type.
If the getWriter or getPortletOutputStream methods are called before the
setContentType method, they must throw an IllegalStateException.
The setContentType method must be called before the getWriter or
getPortletOutputStream methods. If called after, it should be ignored.
If the portlet has set a content type, the getContentType method must return
it.
Otherwise, the getContentType method must return null.
Do they mean the same?
Thanks: zsofi
Re: Clarification on Container Services
Posted by David Le Strat <dl...@yahoo.com>.
Micheal,
Jetspeed2 heavily relies on Pico + Nano. We use Nano
to configure our components with Groovy scripts. If
you are interested, I recommend you have a look at the
CVS Head, especially /components/cm (our lightweight
component manager). The CM provides facilities for
building the various containers.
Regards,
David.
--- Michael Blum <bl...@apache.org> wrote:
> Hello, I have tried to find out and learn more about
> Pico/Nano. In the
> beginning I was satisfied with the existing
> introductory pages available
> at the homepages of Pico and Nano. When I started
> to write some
> sandbox-code, I got the impression that there must
> be some better/newer
> and more complete documentation. Even the API-doc,
> which comes with
> binaries does not help much. Has anyone found more
> information? Perhaps
> people from Jetspeed ?
>
> Michael
>
> David Sean Taylor wrote:
>
> >
> > Has anyone considered using an IoC container such
> as Pico Container?
> > We are developing Jetspeed with Pico and Nano with
> some success.
> > For example, you can easily define containers of
> components with
> > assemblies and clearly define the relationships
> between components.
> > I've been working with Pluto for a while now and I
> must say that the
> > services integration just feels wrong and is very
> confusing.
> > The Pluto 'container' is a natural candidate for a
> Pico container, and
> > could easily solve the OO issues with thread-local
> in Pluto.
> >
> > I really find following the Pluto container/portal
> interaction to be
> > needlessly complex.
> > I still get lost trying to follow, for example,
> how my Portlet URL is
> > generated.
> > Lets see:
> >
> > Tag -> responseCreateRenderUrl ->
> PortletObjectAccess.getPortletUrl ->
> > PortletUrlFactory -> new PortletUrlImpl ->
> > InformationProviderAccess.getDynamicProvider
> > ->
>
PortletContainerServices->get(InformationProviderService.class)
>
> > (and here we get into the ThreadLocal issues)
> > finally I get to a Jetspeed
> DynamicInformationProvider impl .... and
> > with more abstractions I finally get to my
> PortletURL implementation
> >
> > Its no wonder this stuff isn't documented (sigh)
> >
> > What I'd like to propose is refactoring the Pluto
> container services
> > and information providers
> > We have the opportunity to define a clear
> interface between container
> > and portal, right here at Pluto, the reference
> implementation of the
> > Portlet api (which defines the container / portlet
> interface)
> > We have members of the Portlet API standard as
> committers on this project
> > I believe that it will benefit all of us to better
> formalize the the
> > container/portal interfaces
> >
> >
> >
> >
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
Re: Clarification on Container Services
Posted by Michael Blum <bl...@apache.org>.
Hello, I have tried to find out and learn more about Pico/Nano. In the
beginning I was satisfied with the existing introductory pages available
at the homepages of Pico and Nano. When I started to write some
sandbox-code, I got the impression that there must be some better/newer
and more complete documentation. Even the API-doc, which comes with
binaries does not help much. Has anyone found more information? Perhaps
people from Jetspeed ?
Michael
David Sean Taylor wrote:
>
> Has anyone considered using an IoC container such as Pico Container?
> We are developing Jetspeed with Pico and Nano with some success.
> For example, you can easily define containers of components with
> assemblies and clearly define the relationships between components.
> I've been working with Pluto for a while now and I must say that the
> services integration just feels wrong and is very confusing.
> The Pluto 'container' is a natural candidate for a Pico container, and
> could easily solve the OO issues with thread-local in Pluto.
>
> I really find following the Pluto container/portal interaction to be
> needlessly complex.
> I still get lost trying to follow, for example, how my Portlet URL is
> generated.
> Lets see:
>
> Tag -> responseCreateRenderUrl -> PortletObjectAccess.getPortletUrl ->
> PortletUrlFactory -> new PortletUrlImpl ->
> InformationProviderAccess.getDynamicProvider
> -> PortletContainerServices->get(InformationProviderService.class)
> (and here we get into the ThreadLocal issues)
> finally I get to a Jetspeed DynamicInformationProvider impl .... and
> with more abstractions I finally get to my PortletURL implementation
>
> Its no wonder this stuff isn't documented (sigh)
>
> What I'd like to propose is refactoring the Pluto container services
> and information providers
> We have the opportunity to define a clear interface between container
> and portal, right here at Pluto, the reference implementation of the
> Portlet api (which defines the container / portlet interface)
> We have members of the Portlet API standard as committers on this project
> I believe that it will benefit all of us to better formalize the the
> container/portal interfaces
>
>
>
>
Re: Clarification on Container Services
Posted by Serge Huber <sh...@jahia.com>.
I've been following the new container development on J2 and I must say that
Pluto would definitely benefit from the new architecture. Plus it makes
some sense to have a similar arch between the two projects.
Regards,
Serge Huber.
At 07:07 PM 2/27/2004, you wrote:
>I'm definitely in favor of considering Pico. I've been looking at it for
>a while and wondering if it's the best direction. I'm especially
>interested in any additional feedback from Jetspeed contributors. What
>are the pros and cons that you seen so far?
>
>David
>
>David Sean Taylor wrote:
>
>>Has anyone considered using an IoC container such as Pico Container?
>>We are developing Jetspeed with Pico and Nano with some success.
>>For example, you can easily define containers of components with
>>assemblies and clearly define the relationships between components.
>>I've been working with Pluto for a while now and I must say that the
>>services integration just feels wrong and is very confusing.
>>The Pluto 'container' is a natural candidate for a Pico container, and
>>could easily solve the OO issues with thread-local in Pluto.
>>I really find following the Pluto container/portal interaction to be
>>needlessly complex.
>>I still get lost trying to follow, for example, how my Portlet URL is
>>generated.
>>Lets see:
>>Tag -> responseCreateRenderUrl -> PortletObjectAccess.getPortletUrl ->
>>PortletUrlFactory -> new PortletUrlImpl ->
>>InformationProviderAccess.getDynamicProvider
>>-> PortletContainerServices->get(InformationProviderService.class) (and
>>here we get into the ThreadLocal issues)
>>finally I get to a Jetspeed DynamicInformationProvider impl .... and with
>>more abstractions I finally get to my PortletURL implementation
>>Its no wonder this stuff isn't documented (sigh)
>>What I'd like to propose is refactoring the Pluto container services and
>>information providers
>>We have the opportunity to define a clear interface between container and
>>portal, right here at Pluto, the reference implementation of the Portlet
>>api (which defines the container / portlet interface)
>>We have members of the Portlet API standard as committers on this project
>>I believe that it will benefit all of us to better formalize the the
>>container/portal interfaces
>>
>
>
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
Re: Clarification on Container Services
Posted by Serge Huber <sh...@jahia.com>.
At 08:52 AM 3/2/2004, you wrote:
>David Sean Taylor wrote:
>>On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>>
>>>>But all in all the conversion is going well, we are almost there.
>>>>
>>>This is a pretty radical step - it is probably going to mean significant
>>>changes to the container API, and if we deceided to go ahead with it we
>>>should (probably?) wait until we have it stable before putting a release out.
>>I agree we should release 1.0 of Pluto from portals.apache.org first.
>>This can be a 1.1 direction.
>>
>
>I agree with this. Let's try to get a 1.0 release out and look into using
>IoC in more detail before changing anything. I would like to have discuss
>and prototype these kind of fundamenal changes first before deciding on
>them. IoC really looks interesting, so I think it is definitely worth
>looking into that.
+1.
Regards,
Serge...
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
RE: Clarification on Container Services
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David H. DeWolf wrote:
> Are you suggesting that the IoC version of Pluto would not
> need to be backwards compatible with a 1.0 release? I know
> there's been a lot of discussions on other lists about
> commons-collections not maintaining binary compatibility
> (through deprecation) with it's most recent release. I
> wouldn't want to make the same mistake. Granted, a commons
> library is significantly different than a container, but a
> switch without binary compatibility would require any portals
> using the pluto container to re-integrate from the ground up.
>
I'm not suggesting but implying :) Of course, we should try
to make it as compatible as possible, but switching from the
current approach to IoC might be very hard to do if you
also try to be compatible. I might be wrong.
So, I guess (just a guess!) that an IoC version would be a
2.0 version that might not be compatible.
But we shouldn't discuss this now :) This might give the wrong
impression to our users.
Carsten
Re: Clarification on Container Services
Posted by "David H. DeWolf" <dd...@apache.org>.
Carsten Ziegeler wrote:
> David H. DeWolf wrote:
>
>>>I agree with this. Let's try to get a 1.0 release out and look into
>>>using IoC in more detail before changing anything. I would like to
>>>have discuss and prototype these kind of fundamenal changes first
>>>before deciding on them. IoC really looks interesting, so I
>>
>>think it
>>
>>>is definitely worth looking into that.
>>>
>>
>>Part of me agrees that it's best to get a 1.0 release out
>>before taking on a "rewrite". On the other hand, a rewrite
>>will *significantly* change the API. I would hate to have a
>>1.0 release put out just for the sake of timing and then have
>>to support a significantly different API through deprecation
>>just so we're backwards compatible.
>>
>>No matter what we choose. . .
>>
>>I propose that we setup a "contrib" or "sandbox" folder in
>>cvs so that we have a place to track proposals and eventually
>>prototypes for an IoC based pluto.
>>
>
> I really would love to have a IoC based pluto (I integrate it into
> Cocoon and Cocoon uses Avalon, so that would be a perfect fit).
> And I also think a sandbox would be good,
>
> BUT: we are still in incubation and I think our first priority should
> be to get out off incubation. I think if we focus on a release now -
> and I think there isn't much to do for it anyway - then do the
> release we can get out of incubation with that and can then more
> easily do what we think is best.
Agreed, getting out of incubation should be a priority. To do this, I
would think that we should come up with a specific roadmap. What are
the things that need to be done before a release?
>
> We would have to maintain the 1.0 branch then, but I think that
> shouldn't be to hard as well and we could start a new version in
> our sandbox.
Are you suggesting that the IoC version of Pluto would not need to be
backwards compatible with a 1.0 release? I know there's been a lot of
discussions on other lists about commons-collections not maintaining
binary compatibility (through deprecation) with it's most recent
release. I wouldn't want to make the same mistake. Granted, a commons
library is significantly different than a container, but a switch
without binary compatibility would require any portals using the pluto
container to re-integrate from the ground up.
>
> WDYT?
>
> Carsten
>
>
RE: Clarification on Container Services
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David H. DeWolf wrote:
> > I agree with this. Let's try to get a 1.0 release out and look into
> > using IoC in more detail before changing anything. I would like to
> > have discuss and prototype these kind of fundamenal changes first
> > before deciding on them. IoC really looks interesting, so I
> think it
> > is definitely worth looking into that.
> >
>
> Part of me agrees that it's best to get a 1.0 release out
> before taking on a "rewrite". On the other hand, a rewrite
> will *significantly* change the API. I would hate to have a
> 1.0 release put out just for the sake of timing and then have
> to support a significantly different API through deprecation
> just so we're backwards compatible.
>
> No matter what we choose. . .
>
> I propose that we setup a "contrib" or "sandbox" folder in
> cvs so that we have a place to track proposals and eventually
> prototypes for an IoC based pluto.
>
I really would love to have a IoC based pluto (I integrate it into
Cocoon and Cocoon uses Avalon, so that would be a perfect fit).
And I also think a sandbox would be good,
BUT: we are still in incubation and I think our first priority should
be to get out off incubation. I think if we focus on a release now -
and I think there isn't much to do for it anyway - then do the
release we can get out of incubation with that and can then more
easily do what we think is best.
We would have to maintain the 1.0 branch then, but I think that
shouldn't be to hard as well and we could start a new version in
our sandbox.
WDYT?
Carsten
Re: Clarification on Container Services
Posted by "David H. DeWolf" <dd...@apache.org>.
Stefan Hepper wrote:
> David Sean Taylor wrote:
>
>>
>> On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>>
>>>> But all in all the conversion is going well, we are almost there.
>>>>
>>>>
>>> This is a pretty radical step - it is probably going to mean
>>> significant changes to the container API, and if we deceided to go
>>> ahead with it we should (probably?) wait until we have it stable
>>> before putting a release out.
>>>
>> I agree we should release 1.0 of Pluto from portals.apache.org first.
>> This can be a 1.1 direction.
>>
>>
>>
>
> I agree with this. Let's try to get a 1.0 release out and look into
> using IoC in more detail before changing anything. I would like to have
> discuss and prototype these kind of fundamenal changes first before
> deciding on them. IoC really looks interesting, so I think it is
> definitely worth looking into that.
>
Part of me agrees that it's best to get a 1.0 release out before taking
on a "rewrite". On the other hand, a rewrite will *significantly*
change the API. I would hate to have a 1.0 release put out just for the
sake of timing and then have to support a significantly different API
through deprecation just so we're backwards compatible.
No matter what we choose. . .
I propose that we setup a "contrib" or "sandbox" folder in cvs so that
we have a place to track proposals and eventually prototypes for an IoC
based pluto.
> Stefan
>
Re: Clarification on Container Services
Posted by Stefan Hepper <st...@hursley.ibm.com>.
David Sean Taylor wrote:
>
> On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>
>>> But all in all the conversion is going well, we are almost there.
>>>
>>>
>> This is a pretty radical step - it is probably going to mean
>> significant changes to the container API, and if we deceided to go
>> ahead with it we should (probably?) wait until we have it stable
>> before putting a release out.
>>
> I agree we should release 1.0 of Pluto from portals.apache.org first.
> This can be a 1.1 direction.
>
>
>
I agree with this. Let's try to get a 1.0 release out and look into
using IoC in more detail before changing anything. I would like to have
discuss and prototype these kind of fundamenal changes first before
deciding on them. IoC really looks interesting, so I think it is
definitely worth looking into that.
Stefan
Re: Clarification on Container Services
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>> But all in all the conversion is going well, we are almost there.
>>
>>
> This is a pretty radical step - it is probably going to mean
> significant changes to the container API, and if we deceided to go
> ahead with it we should (probably?) wait until we have it stable
> before putting a release out.
>
I agree we should release 1.0 of Pluto from portals.apache.org first.
This can be a 1.1 direction.
Re: Clarification on Container Services
Posted by Nick Lothian <ni...@mackmo.com>.
David Sean Taylor wrote:
>
> On Friday, February 27, 2004, at 10:07 AM, David H. DeWolf wrote:
>
>> I'm definitely in favor of considering Pico. I've been looking at it
>> for a while and wondering if it's the best direction. I'm especially
>> interested in any additional feedback from Jetspeed contributors.
>> What are the pros and cons that you seen so far?
>>
> IoC seems to just make sense. With component adapters we can control
> the patterns of component creation and are not limited to singletons
> as in our previous service-oriented model.
> I really like assembling objects into containers and containers into
> containers outside the actual components, clearly defining
> relationships via constructors, all good programming practices.
> We are identifying different scenarios for containers as we progress.
> Nano gives us scriptable assembly of containers (we have chosen Groovy
> scripts thus far, but Nano supports quite a few scripting languages).
> We plan to make use of the Nano multi-caster for events.
> We have yet to integrate J2's configuration with assembly; and i
> believe we have some novel ideas in this area.
> One downside is that we have had a learning curve, and it has taken
> some time and false starts, setting back expectations and perceived
> schedules.
> But all in all the conversion is going well, we are almost there.
>
>
This is a pretty radical step - it is probably going to mean significant
changes to the container API, and if we deceided to go ahead with it we
should (probably?) wait until we have it stable before putting a release
out.
How do other people trying to integrate Pluto feel about this?
Nick
Re: Clarification on Container Services
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Friday, February 27, 2004, at 10:07 AM, David H. DeWolf wrote:
> I'm definitely in favor of considering Pico. I've been looking at it
> for a while and wondering if it's the best direction. I'm especially
> interested in any additional feedback from Jetspeed contributors.
> What are the pros and cons that you seen so far?
>
IoC seems to just make sense. With component adapters we can control
the patterns of component creation and are not limited to singletons as
in our previous service-oriented model.
I really like assembling objects into containers and containers into
containers outside the actual components, clearly defining
relationships via constructors, all good programming practices.
We are identifying different scenarios for containers as we progress.
Nano gives us scriptable assembly of containers (we have chosen Groovy
scripts thus far, but Nano supports quite a few scripting languages).
We plan to make use of the Nano multi-caster for events.
We have yet to integrate J2's configuration with assembly; and i
believe we have some novel ideas in this area.
One downside is that we have had a learning curve, and it has taken
some time and false starts, setting back expectations and perceived
schedules.
But all in all the conversion is going well, we are almost there.
Re: Clarification on Container Services
Posted by "David H. DeWolf" <dd...@apache.org>.
I'm definitely in favor of considering Pico. I've been looking at it
for a while and wondering if it's the best direction. I'm especially
interested in any additional feedback from Jetspeed contributors. What
are the pros and cons that you seen so far?
David
David Sean Taylor wrote:
>
> Has anyone considered using an IoC container such as Pico Container?
> We are developing Jetspeed with Pico and Nano with some success.
> For example, you can easily define containers of components with
> assemblies and clearly define the relationships between components.
> I've been working with Pluto for a while now and I must say that the
> services integration just feels wrong and is very confusing.
> The Pluto 'container' is a natural candidate for a Pico container, and
> could easily solve the OO issues with thread-local in Pluto.
>
> I really find following the Pluto container/portal interaction to be
> needlessly complex.
> I still get lost trying to follow, for example, how my Portlet URL is
> generated.
> Lets see:
>
> Tag -> responseCreateRenderUrl -> PortletObjectAccess.getPortletUrl ->
> PortletUrlFactory -> new PortletUrlImpl ->
> InformationProviderAccess.getDynamicProvider
> -> PortletContainerServices->get(InformationProviderService.class) (and
> here we get into the ThreadLocal issues)
> finally I get to a Jetspeed DynamicInformationProvider impl .... and
> with more abstractions I finally get to my PortletURL implementation
>
> Its no wonder this stuff isn't documented (sigh)
>
> What I'd like to propose is refactoring the Pluto container services and
> information providers
> We have the opportunity to define a clear interface between container
> and portal, right here at Pluto, the reference implementation of the
> Portlet api (which defines the container / portlet interface)
> We have members of the Portlet API standard as committers on this project
> I believe that it will benefit all of us to better formalize the the
> container/portal interfaces
>
>
>
Re: Clarification on Container Services
Posted by David Sean Taylor <da...@bluesunrise.com>.
Has anyone considered using an IoC container such as Pico Container?
We are developing Jetspeed with Pico and Nano with some success.
For example, you can easily define containers of components with
assemblies and clearly define the relationships between components.
I've been working with Pluto for a while now and I must say that the
services integration just feels wrong and is very confusing.
The Pluto 'container' is a natural candidate for a Pico container, and
could easily solve the OO issues with thread-local in Pluto.
I really find following the Pluto container/portal interaction to be
needlessly complex.
I still get lost trying to follow, for example, how my Portlet URL is
generated.
Lets see:
Tag -> responseCreateRenderUrl -> PortletObjectAccess.getPortletUrl ->
PortletUrlFactory -> new PortletUrlImpl ->
InformationProviderAccess.getDynamicProvider
-> PortletContainerServices->get(InformationProviderService.class) (and
here we get into the ThreadLocal issues)
finally I get to a Jetspeed DynamicInformationProvider impl .... and
with more abstractions I finally get to my PortletURL implementation
Its no wonder this stuff isn't documented (sigh)
What I'd like to propose is refactoring the Pluto container services
and information providers
We have the opportunity to define a clear interface between container
and portal, right here at Pluto, the reference implementation of the
Portlet api (which defines the container / portlet interface)
We have members of the Portlet API standard as committers on this
project
I believe that it will benefit all of us to better formalize the the
container/portal interfaces
Re: Clarification on Container Services
Posted by "David H. DeWolf" <dd...@apache.org>.
Stephan Hesmer wrote:
> We all agree on the concept of the Container Services. They provide a
> simple plug point to make the portlet container implementation
> independent from the portal it is running in. This was one major goal
> from the beginning of the creation of pluto. We wanted to make pluto
> as reusable as possible, so that other projects and portals like
> Jetspeed could reuse pluto's portlet container.
Agreed.
> What was discussed on the other side, was how the container services
> are actually implemented. This is a point worth of investigating - and
> I come to that later. However, we should proceed very carefully and
> not make hasty decisions. Thanks David to be careful so far and asking
> the community before changing anything! You also brought up the
> problematic point. There have been some design requirements about the
> implementation that have not been documented :-( (That would be my fault)
>
I have no doubt that you wrote things a certain way for specific
reasons. As far as I'm concerned, *if* changes are necessary it's best
to get all the issues on the table so that we can find an optimal
solution for everyone/everything.
> These are the design requirements that are important for our
> discussion (Stefan, Michael, if you recall others please feel free to
> add or correct)
> 1. Container Services are scoped per container
> 2. Container Services must be easy to use from within the container
> (as well as accessible everywhere)
>
Can you define "easy to use"? Sometimes I think that we mistake "short
invocations" for "easy to use". For instance, one may claim that a
static method Log.debug(String,String) is "easier to use" than the
standard commons logging LogFactory.getLog(String).debug(String), I
would disagree b/c the former method makes performance optimizations and
other not so trivial uses of the class more difficult to use. As long
as methods are well defined, I prefer a more object oriented approach.
> One use case that we tried often during development of pluto was to
> use pluto's portlet container for the WSRP implementation as well.
>
That's a great idea. We should continue to do that as we move forward.
> Most discussions have been around the ThreadLocals. Some points David
> brought up are simply bugs.
> The reason I have chosen ThreadLocales for the beginning was the
> design requirement (2). It is much more convenient for a developer to
> simply write
> Debug.log
> instead of
> Debug.get(someContext).log
> Additionally, it is nearly guaranteed that this can be used in every
> method, even though the someContext has not been passed. Otherwise, we
> would have to pass someContext into every method and add it to every
> signature that we have in the portlet container.
I've got two thoughts:
First, I don't think I understand why we would have to pass around
someContext for every method invocation. It seems that if we were to
use a more standard OO approach each container would contain instances
of their "services". Each service would then in turn be able to be
initialized for use within a single container. As a result, a single
instance of each service would exist for each container and would thus
already have knowledge about the context in which it lives. That said,
I do think there are some wrinkles to work out between the
PortletInvokation and dispatching to the PlutoServlet.
Second, I also wonder if using ThreadLocal's really does simplify things
for the developer. Using them definitely makes for less typing (or
cutting and pasting ;) ), however, I wonder if it also makes it more
difficult to understand design considerations, and perhaps even the code
itself. Granted, more developers will be simply using APIs than they
will be worrying about the things we're discussing, however, I'm sure
there are plenty of people that like to understand the inner workings of
what they are coding against.
Another consideration that I'd throw in is that I'm kind of from the
school of thought that once you start using static methods for things
other than simple utility classes, following design patterns and std OO
practices become much more difficult. Once you get to this difficulty
and have to work around it, I tend to find that the code becomes less
self documenting and more difficult to manage.
>
> Before everybody starts shouting ;-), I have to say that we also saw
> some problems with using threadlocales.
>
I know it sounds like I'm adamently against the current approach, but
I'm not. I'm just trying to bounce some of my thoughts off of everyone
to see if they've got any merit. If there are more considerations for
implementing with static methods and ThreadLocals, I'm still interested
in hearing them. Unless it comes out that the main reason for choosing
this approach was the "simplicity of use" argument, then I think we've
got a long way to go before making any drastic decisions.
> Does anybody have a better solution than passing someContext
> everywhere around in the portlet container ?
>
I'll try to start putting some design thoughts down on paper to make my
thoughts a little more concrete.
Thanks for your comments.
David
> Bye
>
> Stephan
>
>
>
Re: Clarification on Container Services
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Thu, 26 Feb 2004, Stephan Hesmer wrote:
| Does anybody have a better solution than passing someContext everywhere
| around in the portlet container ?
a) I think that this solution is OK, where needed. MUCH better than the
ThreadLocals.
I kinda feel that when one come to the point of using ThreadLocals, then
one've made some non-optimal choice somewhere - or are stuck with some
legacy API that can't handle your complex need.
b) I can't seem to understand why there is such a need for passing this
instance -anywhere- - isn't this an object oriented language?
See, I imagine the situation like this:
Container Instance 1:
has-a: factory 1 (that has-a Container Instance 1, if needed)
has-a: whatever 1 (that has-a Container Instance 1, if needed)
etc..
Container Instance 2:
has-a: factory 2 (that has-a Container Instance 2, if needed)
has-a: whatever 2 (that has-a Container Instance 2, if needed)
etc..
etc..
My point is that once you then get hold of the Container Instance that
you're scoped with, that one single reference gives you access to -every
other- element of -that instance's- "system". And those elements have
back-references to their "owning Container", if they need to call around
in this tree (graph) of objects - thus "one system" is "self-contained",
having references pointing around to every part of -its- world.
My point is that every single such tree/graph (every instance of
container) is thus -separated- from the other instances. Whether there are
-one- Container, or two thousand, each container wouldn't know of this.
Only the creator of the container(s) would now of all the instances, being
able to select the appropriate one for each situation.
I understand the use of ThreadLocals to imply that every method
throughout the system basically is a static method, kind of a collection
of utility-methods, and the use of ThreadLocals is to relieve the
programmer from passing the actual Container in question to all these
utility methods.
This seems to me like a logical breach of the OO element of Java - the
ThreadLocal kind of takes the position of what "this" is really meant to
do.
I might, as always, be -TOTALLY FAR OUT- and really making a fool of
myself, but please explain my error in that case!
Endre
(As a side-node: I've used ThreadLocal once that was really helpful:
this was with error handling:
I had a situation where the server side of a system was calling into an
SPI. The imlementor had to call "back into" the server, using some
context, and thus got some object back, this object was registerd into the
server internals. The implementor was then supposed to return this back to
the calling server-part.
Well, the situation is thus a call-path like this: "first server part"
-> SPI implementor -> "second server part". The second server part makes
and adds some object that the first server-part needs. THE PROBLEM arises
if the SPI implementation throws some Exception, due to bad code, e.g. an
NPE. It won't then return the object, and the first server part won't ever
know what object the second server part inserted, and can thus not thrash
and clean the object out of the system. This is where the TreadLocal came
into use: the "second part" shoves the newly created object into the
TreadLocal. If the SPI implementor then comes throwing out, the "first
part"'s Exception handling checks the ThreadLocal whether there is an
object in there, and if so, cleans it.
Anyone else had a similar situation? Or other situations where
ThreadLocal's were of fantastic help?)
--
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/