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 Endre Stølsvik <En...@Stolsvik.com> on 2004/02/04 18:56:51 UTC
Some comments after code-browsing.
Some comments after browsing the code for some hours. I might be far out
with everything here, but please read my comments..
*) PortletPreferencesImpl -> store() -> throws new IllegalStateException
message says "only allowed in render call", which should read "action
call".
*) PrintWriterServletOutputStream:
Inefficient (as stated in comment), but also completly wrong: There is
no way (in my understanding) that this might work: printing the -byte-
using a -String- will make the output depend totally on the encoding used.
Using latin-1, the byte would be output correctly - but if the encoding
was e.g. UTF-8, then bytes > 0x7f would be output as two bytes, etc etc.
This goes hand in hand with an API issue that I can't seem to
understand:
*) Several API issues with RenderResponse, RenderRequest
1) Enumeration RenderRequest.getResponseContentTypes[s]()
2) String RenderResponse.getContentType()
3) void RenderResponse.setContentType(String contentType)
4) PrintWriter RenderResponse.getWriter()
5) OutputStream RenderResponse.getPortletOutputStream()
What's the relation between 1) and 2) ?
How may I set the ContentType (3) of the response, -if- another Portlet
have decided upon something else? Which markups allow this? For the HTTP
variant (and I thought that Portlets -are- gotten over HTTP), I thought
that this was a HTTP -header-, and not something that could be changed
throughout the response.
Then the encoding: what clients are able to switch encodings multiple
times during one page-rendering?
What about the aggregator, then? The Portal's header and navigation
tools (for example) are the first HTML (or whatever) that will be output,
in effect setting the content-type (and encoding) for the entire
aggregation (the "desktop") of Portlets.
4) and 5) both have a problem: since there usually will be multiple
portlets on a page, and the page is part of an aggregator (Servlet), then
the portlet shouldn't have much choice - it will have to use the output
means (with encoding, if using Writer) that the aggregator (Portal)
already chose.
.. And when will you write binary data in the middle of character
output? I don't know WML: is WML's images included directly in the stream?
(And btw: 5) Why get_Portlet_OutputStream? With the servlet-variant,
this has a reason (although this is badly i18n'ed), but in this API it
returns a pure OutputStream. The getWriter() hasn't got the "Portlet" in
there).
This is the relation to the above-mentioned problem with the
PrinterWriterServletOutputStream: getting the Wrinter from the
ServletResponse, then making a Stream for the Portlets isn't possible (at
least not w/o tons of hassle).
However, it is possible to do this the other way: a byte-oriented
fashion: fetch the OutputStream from the ServletResponse, and then wrap
the stream in writers each time you need to output strings (or when the
Portlet does res.getWriter()), using the encoding that is in effect at
that point, or simply return it if the portlet invokes the
getPortletOutputStream(). .. but then again, what clients allow encoding
switched in the middle of a page-rendering?
Just to state it again: I am not sure if I have a point here, but if I'm
wrong, please explain my error!
*) Another API question: PortletRequest.getProperty(String name)
".. and, if available, the HTTP headers".. Why this rather strange
mixing of concerns for that method? What about dates and ints, as with the
ServletRequest, which have 5 distinct methods for headers. What if the
portlet container defines a property named "Authentication"?
*) And Yet Another API Question: RenderResponse.setBufferSize() throws
IllegalStateException both if the Container doesn't support caching, AND
if this method is called after some response is written. This makes for
difficult'ier debugging: it should use two different Exceptions for two
such different problems, e.g. IllegalArgumentException if the portlet
container doesn't support caching.
*) PortletServlet: what is that comment about "This portlet uses the
<load-on-startup> flag - turn it off"? Why can't this be implemented? The
Servlet would be loaded, which in turn loads the Portlet..
*) PortletDefinitionRegistryServiceFileImpl:
Why does it read web.xml? Is it ever used?
*) Deploy:
arg 3 (fourt arg) is never used!
*) ContainerServiceStack: ThreadLocal's.
Spelling error: ThreadLocal_e_. What is the deal with this ThreadLocal
thing? - it might be obvious - but I couldn't seem to understand the point
of this. A servlet container users tons of threads: why would one need
ThreadLocals here? What is the StackedThreadLocale?
*) PortletRequestWrapper:
what's the need?
*) PortletRequestImpl:
Why is the getAttribute() and setAttribute() namespaced? isn't it
actually critical that this -doesn't- happen? Isn't some of the point with
this that other elements (possibly included) of this Portlet should be
able to read these attributes? The namespacing would just make it
difficult to agree upon a name for the attribute.
*) Implement proper logging! (Mentioned before)
Regards,
Endre.
Re: Deploy.java: arg[3] not used
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Michael Westbay wrote:
> I appear to have clipped off the final couple of paragraphs before
> sending. The above message should conclude:
>
> [...]
>
> Ugly, but it works.
>
> What I would like to do is replace arg[3] (buildContainerDirectory) with
> a parameter that points to the root of the pluto project (i.e.
> jakarta-pluto directory). That will eliminate the need to go two
> directories up, then a few down to find portlet.tld. It will just go
> straight down.
>
> If there are no objections, and it not viewed as being outside the scope
> of the Pluto project to make such a change, I would be more than happy
> to submit a patch to Deploy.java and testsuite/maven.xml to facilitate
> such a deployment strategy.
>
+1 for this change.
Stefan
Re: Deploy.java: arg[3] not used
Posted by "David H. DeWolf" <da...@vivare.com>.
Michael Westbay wrote:
> David H. DeWolf wrote:
>
>> I think in addition, we should make sure that we publish the
>> portlet.tld dependencies to the maven repository and use them when
>> appropriate. This way, whenever we are using maven, we can pull the
>> tld straight out of the repository and use it. I don't think that
>> will help you much in your situation (since it's referred to inside a
>> class that we don't want depending on maven), but your comments
>> jogged my memory that we should be publishing all artifacts to the
>> maven repository - not just jars. Struts is a good example of a
>> project that publishes tlds to the repo.
>
>
> Is this kind of like the <war.bundle.jar> tag to include a jar file
> under WEB-INF/lib? I'm not familiar enough with Maven to know if
> there's a <war.bundle.tld> tag to include a tld file under
> WEB-INF/tld, but that would be a more elegant solution and eliminate
> the need to do that in the Deploy class.
>
Yes, I think you hit the nail on the head. Unfortunately I'm not a
maven expert either - just trying to learn it and any related best
practices as we go.
> Along the lines of Maven, I was thinking that deploy really should be
> a [pluto] plug-in goal. But again, I'm not a Maven expert. I can
> tweak something that's there to work the way I want, but that's about
> it. I'll just leave this one as a suggestion.
>
I agree 100%. We should make a pluto plugin that allows deployment of
portlets. I'm just finishing up packaging our tomcat deployment goals
into a Maven plugin. Once I get it finalized and submitted to the maven
team my plan was to look into the "pluto" plugin.
> Back to the Deploy.java patch, I've submitted it to Bugzilla:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27001
>
> This patch effects three files:
>
> portal/src/java/org/apache/pluto/portalImpl/Deploy.java
> testsuite/maven.xml
> deploy/maven.xml
>
> I actually made two changes in deploy/maven.xml as the
> ${tomcat.home.pluto} property is called ${maven.tomcat.home}
> everywhere else.
>
> Which is the correct place to post a patch, to the list here or to
> Bugzilla? I see a number of them posted to the list lately, but most
> other Apache project mailing lists I subscribe to specifically state
> that nothing will be done unless it's reported to Bugzilla (for
> tracking purposes).
>
Thanks for your work.
David
Re: Deploy.java: arg[3] not used
Posted by Michael Westbay <we...@users.sourceforge.net>.
David H. DeWolf wrote:
> I think in addition, we should make sure that we publish the
> portlet.tld dependencies to the maven repository and use them when
> appropriate. This way, whenever we are using maven, we can pull the
> tld straight out of the repository and use it. I don't think that
> will help you much in your situation (since it's referred to inside a
> class that we don't want depending on maven), but your comments
> jogged my memory that we should be publishing all artifacts to the
> maven repository - not just jars. Struts is a good example of a
> project that publishes tlds to the repo.
Is this kind of like the <war.bundle.jar> tag to include a jar file
under WEB-INF/lib? I'm not familiar enough with Maven to know if
there's a <war.bundle.tld> tag to include a tld file under WEB-INF/tld,
but that would be a more elegant solution and eliminate the need to do
that in the Deploy class.
Along the lines of Maven, I was thinking that deploy really should be a
[pluto] plug-in goal. But again, I'm not a Maven expert. I can tweak
something that's there to work the way I want, but that's about it.
I'll just leave this one as a suggestion.
Back to the Deploy.java patch, I've submitted it to Bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27001
This patch effects three files:
portal/src/java/org/apache/pluto/portalImpl/Deploy.java
testsuite/maven.xml
deploy/maven.xml
I actually made two changes in deploy/maven.xml as the
${tomcat.home.pluto} property is called ${maven.tomcat.home} everywhere
else.
Which is the correct place to post a patch, to the list here or to
Bugzilla? I see a number of them posted to the list lately, but most
other Apache project mailing lists I subscribe to specifically state
that nothing will be done unless it's reported to Bugzilla (for tracking
purposes).
--
Michael Westbay
Re: Deploy.java: arg[3] not used
Posted by "David H. DeWolf" <da...@vivare.com>.
Michael Westbay wrote:
> I appear to have clipped off the final couple of paragraphs before
> sending. The above message should conclude:
>
> [...]
>
> Ugly, but it works.
>
> What I would like to do is replace arg[3] (buildContainerDirectory) with
> a parameter that points to the root of the pluto project (i.e.
> jakarta-pluto directory). That will eliminate the need to go two
> directories up, then a few down to find portlet.tld. It will just go
> straight down.
>
> If there are no objections, and it not viewed as being outside the scope
> of the Pluto project to make such a change, I would be more than happy
> to submit a patch to Deploy.java and testsuite/maven.xml to facilitate
> such a deployment strategy.
>
+1
I think in addition, we should make sure that we publish the portlet.tld
dependencies to the maven repository and use them when appropriate. This
way, whenever we are using maven, we can pull the tld straight out of
the repository and use it. I don't think that will help you much in
your situation (since it's referred to inside a class that we don't want
depending on maven), but your comments jogged my memory that we should
be publishing all artifacts to the maven repository - not just jars.
Struts is a good example of a project that publishes tlds to the repo.
Re: Deploy.java: arg[3] not used
Posted by Michael Westbay <we...@users.sourceforge.net>.
I appear to have clipped off the final couple of paragraphs before
sending. The above message should conclude:
[...]
Ugly, but it works.
What I would like to do is replace arg[3] (buildContainerDirectory) with
a parameter that points to the root of the pluto project (i.e.
jakarta-pluto directory). That will eliminate the need to go two
directories up, then a few down to find portlet.tld. It will just go
straight down.
If there are no objections, and it not viewed as being outside the scope
of the Pluto project to make such a change, I would be more than happy
to submit a patch to Deploy.java and testsuite/maven.xml to facilitate
such a deployment strategy.
--
Michael Westbay
Deploy.java: arg[3] not used
Posted by Michael Westbay <we...@users.sourceforge.net>.
Endre Stølsvik pointed out in the "Some comments after code-browsing"
thread that:
> *) Deploy:
> arg 3 (fourt arg) is never used!
I've got a use for it, but don't like the kludge of a patch I've made.
Essentially, I want to be able to use the following maven.xml from my
own project directory:
<?xml version="1.0" encoding="UTF-8"?>
<project default="deployHelloWorld">
<goal name="deployHelloWorld">
<delete dir="${tomcat.home.pluto}/webapps/helloworld" />
<attainGoal name="war" />
<java classname="org.apache.pluto.portalImpl.Deploy" fork="yes">
<classpath>
<path refid="maven.dependency.classpath"/>
<pathelement path="${maven.build.dest}"/>
</classpath>
<arg value="${tomcat.home.pluto}/webapps" />
<arg value="pluto" />
<arg value="${basedir}/target/${maven.war.final.name}" />
<arg value="${pluto.home}/container/target" />
<!--
<arg value="-addToEntityReg" />
<arg value="hello" />
<arg value="hello:HelloWorld" />
-->
</java>
</goal>
</project>
This will go with the following project.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<extend>${pluto.home}/testsuite/project.xml</extend>
<pomVersion>3</pomVersion>
<name>Hello World</name>
<id>hello</id>
<groupId>pluto</groupId>
<currentVersion>1.0</currentVersion>
</project>
This allows me to reuse the Maven build framework that already exists
for building and deploying a portlet. So far, so good.
However, line 433 of Deploy.java states:
String strFrom = ".." + dirDelim + "portal"+dirDelim+
"src"+dirDelim+"webapp"+strTo;
Therefore, unless my project is located under ${pluto.home} (which I
define in build.properties), the portlet.tld file cannot be found.
To fix this, I replaced line 443 with this:
String strFrom = buildContainerDirectory+".."+dirDelim+
".."+dirDelim+"portal"+dirDelim+"src"+dirDelim+
"webapp"+strTo;
Re: Some comments after code-browsing.
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Thanks for putting together this list Endre!
Endre Stølsvik wrote:
> Some comments after browsing the code for some hours. I might be far out
> with everything here, but please read my comments..
>
> *) PortletPreferencesImpl -> store() -> throws new IllegalStateException
> message says "only allowed in render call", which should read "action
> call".
>
right, fixed.
> *) PrintWriterServletOutputStream:
> Inefficient (as stated in comment), but also completly wrong: There is
> no way (in my understanding) that this might work: printing the -byte-
> using a -String- will make the output depend totally on the encoding used.
> Using latin-1, the byte would be output correctly - but if the encoding
> was e.g. UTF-8, then bytes > 0x7f would be output as two bytes, etc etc.
> This goes hand in hand with an API issue that I can't seem to
> understand:
>
> *) Several API issues with RenderResponse, RenderRequest
>
> 1) Enumeration RenderRequest.getResponseContentTypes[s]()
> 2) String RenderResponse.getContentType()
> 3) void RenderResponse.setContentType(String contentType)
> 4) PrintWriter RenderResponse.getWriter()
> 5) OutputStream RenderResponse.getPortletOutputStream()
>
> What's the relation between 1) and 2) ?
>
1) is are content types that the portal requests for the response, 2) is
the content type of the request
for the encoding: that's why the encoding is given to this class in the
constructor and the encoding of the servlet response is used.
> How may I set the ContentType (3) of the response, -if- another Portlet
> have decided upon something else? Which markups allow this? For the HTTP
> variant (and I thought that Portlets -are- gotten over HTTP), I thought
> that this was a HTTP -header-, and not something that could be changed
> throughout the response.
> Then the encoding: what clients are able to switch encodings multiple
> times during one page-rendering?
> What about the aggregator, then? The Portal's header and navigation
> tools (for example) are the first HTML (or whatever) that will be output,
> in effect setting the content-type (and encoding) for the entire
> aggregation (the "desktop") of Portlets.
> 4) and 5) both have a problem: since there usually will be multiple
> portlets on a page, and the page is part of an aggregator (Servlet), then
> the portlet shouldn't have much choice - it will have to use the output
> means (with encoding, if using Writer) that the aggregator (Portal)
> already chose.
> .. And when will you write binary data in the middle of character
> output? I don't know WML: is WML's images included directly in the stream?
> (And btw: 5) Why get_Portlet_OutputStream? With the servlet-variant,
> this has a reason (although this is badly i18n'ed), but in this API it
> returns a pure OutputStream. The getWriter() hasn't got the "Portlet" in
> there).
>
> This is the relation to the above-mentioned problem with the
> PrinterWriterServletOutputStream: getting the Wrinter from the
> ServletResponse, then making a Stream for the Portlets isn't possible (at
> least not w/o tons of hassle).
> However, it is possible to do this the other way: a byte-oriented
> fashion: fetch the OutputStream from the ServletResponse, and then wrap
> the stream in writers each time you need to output strings (or when the
> Portlet does res.getWriter()), using the encoding that is in effect at
> that point, or simply return it if the portlet invokes the
> getPortletOutputStream(). .. but then again, what clients allow encoding
> switched in the middle of a page-rendering?
>
> Just to state it again: I am not sure if I have a point here, but if I'm
> wrong, please explain my error!
>
The error is that each portlet gets conceptually its own requests and
responses and a portal may support an aggregation that transcodes
different MIME types returned by the portlets into the target MIME type
of the client.
You may want to write binary data when returning content like gifs,
pdfs, etc. iFrames would allow different content types for different
iFrames on the same page, or you could have a portlet that generates
dynamic gifs.
>
> *) Another API question: PortletRequest.getProperty(String name)
> ".. and, if available, the HTTP headers".. Why this rather strange
> mixing of concerns for that method? What about dates and ints, as with the
> ServletRequest, which have 5 distinct methods for headers. What if the
> portlet container defines a property named "Authentication"?
>
I know not the best solution, but how would you get otherwise the client
string in order to adapt the portlet output to the client? In V1.1 we'll
support JSR 188, but that was not final when we finished our JSR.
> *) And Yet Another API Question: RenderResponse.setBufferSize() throws
> IllegalStateException both if the Container doesn't support caching, AND
> if this method is called after some response is written. This makes for
> difficult'ier debugging: it should use two different Exceptions for two
> such different problems, e.g. IllegalArgumentException if the portlet
> container doesn't support caching.
>
The reason why this is the same exception is because they describe the
same behavior: something has already written to the outputstream: in
case the portlet container does not support caching it was the portal.
> *) PortletServlet: what is that comment about "This portlet uses the
> <load-on-startup> flag - turn it off"? Why can't this be implemented? The
> Servlet would be loaded, which in turn loads the Portlet..
>
Pluto needs to be loaded first before the portletServlets are loaded.
> *) PortletDefinitionRegistryServiceFileImpl:
> Why does it read web.xml? Is it ever used?
>
hmm, no I think currently the web app settings are not used
> *) Deploy:
> arg 3 (fourt arg) is never used!
>
you can use that from the command line
> *) ContainerServiceStack: ThreadLocal's.
> Spelling error: ThreadLocal_e_. What is the deal with this ThreadLocal
> thing? - it might be obvious - but I couldn't seem to understand the point
> of this. A servlet container users tons of threads: why would one need
> ThreadLocals here? What is the StackedThreadLocale?
>
thanks fixed typo.
you need this for having more than one pluto container running at the
same time. WSRP4J is doing this f.e. as they also use the pluto
container. with the stack you can push and pop the current environment
that was used. this is the reason why the prepare and release methods
must be called before using the container.
> *) PortletRequestWrapper:
> what's the need?
>
this is symmetric to the portletRequest - ActionRequest.
the action request wrapper extends the portlet request wrapper like the
action request extends the portlet request
> *) PortletRequestImpl:
> Why is the getAttribute() and setAttribute() namespaced? isn't it
> actually critical that this -doesn't- happen? Isn't some of the point with
> this that other elements (possibly included) of this Portlet should be
> able to read these attributes? The namespacing would just make it
> difficult to agree upon a name for the attribute.
>
As the portal sample implementation reuses the httprequest we somehow
need to ensure that attributes that portlet A sets are not visible for
portlet B when calling render on portlet B.
> *) Implement proper logging! (Mentioned before)
>
> Regards,
> Endre.
>
>
Re: Some comments after code-browsing.
Posted by Serge Huber <sh...@jahia.com>.
At 08:12 AM 2/17/2004, you wrote:
>Yes, these are explained in the portlet spec PLT.23.
Thanks for the info. I just had a look at it and it is interesting.
Regards,
Serge Huber.
>Stefan
>
>
>>Regards,
>> Serge Huber.
>>
>>- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
>>www.jahia.org : A collaborative source CMS and Portal Server
>
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
Re: Some comments after code-browsing.
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Serge Huber wrote:
> At 04:20 PM 2/13/2004, you wrote:
>
>
>
>
>> No, it's not that easy, as part of the functionality that the pluto
>> container needs is implemented in the portal driver, like the render
>> parameter handling. Also there is no standard way for the TCK to
>> directly call the container as each implementation will have a
>> different interface. Therefore the TCK talks via the portal with the
>> portlet container. Thus only portals can be JSr 168 compliant, not the
>> standalone container.
>
>
> Does this mean that the TCK has a standard way of talking to portals ?
>
Yes, these are explained in the portlet spec PLT.23.
Stefan
> Regards,
> Serge Huber.
>
>
> - -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
> www.jahia.org : A collaborative source CMS and Portal Server
>
>
Re: Some comments after code-browsing.
Posted by Serge Huber <sh...@jahia.com>.
At 04:20 PM 2/13/2004, you wrote:
>No, it's not that easy, as part of the functionality that the pluto
>container needs is implemented in the portal driver, like the render
>parameter handling. Also there is no standard way for the TCK to directly
>call the container as each implementation will have a different interface.
>Therefore the TCK talks via the portal with the portlet container. Thus
>only portals can be JSr 168 compliant, not the standalone container.
Does this mean that the TCK has a standard way of talking to portals ?
Regards,
Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
Re: Some comments after code-browsing.
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Endre Stølsvik wrote:
> On Wed, 11 Feb 2004, Stefan Hepper wrote:
>
> |
> |
> | Michael Westbay wrote:
> |
> | > I need some sleep, but first two comments:
> | >
> | > Endre Stølsvik wrote:
> | >
> | >> There ain't no such thing as "Portal Container". There is however, a
> | >> "Portlet Container", and a "Portal". "portalImpl" (the "driver") is,
> | >> yes, simply a "portal" to run the Pluto Portlet Container through the
> | >> TCK.
> | >> However, several Portals uses, and more will use, the Pluto Portlet
> | >> Container as their Portlet Container - Pluto must be good!
> | >
> | >
> | > You are correct. I went back through the specification to review the
> | > terminology. I'm referring to the Portal, not the Portlet Container.
> | > The Portal is where internationalization needs to be set, and where the
> | > content produced by the portlets needs to be brought together (pages
> | > 13-14).
> | >
> | > My apologies for the confusion this word mix-up caused.
> | >
> | >> And while I'm at it: HOW can the TCK fail to check i18n issues? I
> | >> mean, we live on a globe where not everything is expressible in latin-1.
> | >
> | >
> | > My feelings exactly! That's why I made the patch to the Portal in the
> | > first place. Anyone is welcome to apply the patch who wants to test
> | > Pluto outside the latin-1 character set.
> | >
> | > You have many very valid arguments. I was ready to accept that it was
> | > inappropriate to incorporate the patch before, but thanks to your having
> | > me clarify the difference between Portal and Portlet Container, I'm
> | > having second thoughts. I'm very much in your corner for seeing i18n
> | > issues addressed.
> | >
> | > I'll look at the arguments under a better understanding tomorrow. Thanks
> | > for challenging my answers.
> | >
> |
> |
> | The TCK is not testing the portal. The TCK is enforcing all the MUST
> | things of the spec and the spec talks about portlets and the portlet
> | container. A spec cannot enforce that everyone implements i18n enabled
> | portals (that is the job of the companies, people buying portals) it
> | only can provide support for it.
>
> I wonder about one thing regarding this:
>
> If I use Pluto to make my Portal "JSR 168 compliant", will I
> "automatically" get a certified status of my -portal- too?
>
> I mean - if my portal can't support anonymous users, can't do "file
> uploads" etc etc - will it still be a certified JSR 168 portal?
>
> I don't quite get this.
>
No, it's not that easy, as part of the functionality that the pluto
container needs is implemented in the portal driver, like the render
parameter handling. Also there is no standard way for the TCK to
directly call the container as each implementation will have a different
interface. Therefore the TCK talks via the portal with the portlet
container. Thus only portals can be JSr 168 compliant, not the
standalone container.
Stefan
> Endre.
>
>
Re: Some comments after code-browsing.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Wed, 11 Feb 2004, Stefan Hepper wrote:
|
|
| Michael Westbay wrote:
|
| > I need some sleep, but first two comments:
| >
| > Endre Stølsvik wrote:
| >
| >> There ain't no such thing as "Portal Container". There is however, a
| >> "Portlet Container", and a "Portal". "portalImpl" (the "driver") is,
| >> yes, simply a "portal" to run the Pluto Portlet Container through the
| >> TCK.
| >> However, several Portals uses, and more will use, the Pluto Portlet
| >> Container as their Portlet Container - Pluto must be good!
| >
| >
| > You are correct. I went back through the specification to review the
| > terminology. I'm referring to the Portal, not the Portlet Container.
| > The Portal is where internationalization needs to be set, and where the
| > content produced by the portlets needs to be brought together (pages
| > 13-14).
| >
| > My apologies for the confusion this word mix-up caused.
| >
| >> And while I'm at it: HOW can the TCK fail to check i18n issues? I
| >> mean, we live on a globe where not everything is expressible in latin-1.
| >
| >
| > My feelings exactly! That's why I made the patch to the Portal in the
| > first place. Anyone is welcome to apply the patch who wants to test
| > Pluto outside the latin-1 character set.
| >
| > You have many very valid arguments. I was ready to accept that it was
| > inappropriate to incorporate the patch before, but thanks to your having
| > me clarify the difference between Portal and Portlet Container, I'm
| > having second thoughts. I'm very much in your corner for seeing i18n
| > issues addressed.
| >
| > I'll look at the arguments under a better understanding tomorrow. Thanks
| > for challenging my answers.
| >
|
|
| The TCK is not testing the portal. The TCK is enforcing all the MUST
| things of the spec and the spec talks about portlets and the portlet
| container. A spec cannot enforce that everyone implements i18n enabled
| portals (that is the job of the companies, people buying portals) it
| only can provide support for it.
I wonder about one thing regarding this:
If I use Pluto to make my Portal "JSR 168 compliant", will I
"automatically" get a certified status of my -portal- too?
I mean - if my portal can't support anonymous users, can't do "file
uploads" etc etc - will it still be a certified JSR 168 portal?
I don't quite get this.
Endre.
Re: Some comments after code-browsing.
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Michael Westbay wrote:
> I need some sleep, but first two comments:
>
> Endre Stølsvik wrote:
>
>> There ain't no such thing as "Portal Container". There is however, a
>> "Portlet Container", and a "Portal". "portalImpl" (the "driver") is,
>> yes, simply a "portal" to run the Pluto Portlet Container through the
>> TCK.
>> However, several Portals uses, and more will use, the Pluto Portlet
>> Container as their Portlet Container - Pluto must be good!
>
>
> You are correct. I went back through the specification to review the
> terminology. I'm referring to the Portal, not the Portlet Container.
> The Portal is where internationalization needs to be set, and where the
> content produced by the portlets needs to be brought together (pages
> 13-14).
>
> My apologies for the confusion this word mix-up caused.
>
>> And while I'm at it: HOW can the TCK fail to check i18n issues? I
>> mean, we live on a globe where not everything is expressible in latin-1.
>
>
> My feelings exactly! That's why I made the patch to the Portal in the
> first place. Anyone is welcome to apply the patch who wants to test
> Pluto outside the latin-1 character set.
>
> You have many very valid arguments. I was ready to accept that it was
> inappropriate to incorporate the patch before, but thanks to your having
> me clarify the difference between Portal and Portlet Container, I'm
> having second thoughts. I'm very much in your corner for seeing i18n
> issues addressed.
>
> I'll look at the arguments under a better understanding tomorrow. Thanks
> for challenging my answers.
>
The TCK is not testing the portal. The TCK is enforcing all the MUST
things of the spec and the spec talks about portlets and the portlet
container. A spec cannot enforce that everyone implements i18n enabled
portals (that is the job of the companies, people buying portals) it
only can provide support for it.
Stefan
Re: Some comments after code-browsing.
Posted by Michael Westbay <we...@users.sourceforge.net>.
I need some sleep, but first two comments:
Endre Stølsvik wrote:
> There ain't no such thing as "Portal Container". There is however, a
> "Portlet Container", and a "Portal". "portalImpl" (the "driver") is, yes,
> simply a "portal" to run the Pluto Portlet Container through the TCK.
> However, several Portals uses, and more will use, the Pluto Portlet
> Container as their Portlet Container - Pluto must be good!
You are correct. I went back through the specification to review the
terminology. I'm referring to the Portal, not the Portlet Container.
The Portal is where internationalization needs to be set, and where the
content produced by the portlets needs to be brought together (pages 13-14).
My apologies for the confusion this word mix-up caused.
> And while I'm at it: HOW can the TCK fail to check i18n issues? I mean, we
> live on a globe where not everything is expressible in latin-1.
My feelings exactly! That's why I made the patch to the Portal in the
first place. Anyone is welcome to apply the patch who wants to test
Pluto outside the latin-1 character set.
You have many very valid arguments. I was ready to accept that it was
inappropriate to incorporate the patch before, but thanks to your having
me clarify the difference between Portal and Portlet Container, I'm
having second thoughts. I'm very much in your corner for seeing i18n
issues addressed.
I'll look at the arguments under a better understanding tomorrow.
Thanks for challenging my answers.
--
Michael Westbay
Re: Some comments after code-browsing.
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Michael Westbay wrote:
> Stølsvik-san wrote:
>
> > [About optimizations]
> >
> > This is not "less than optimal", this is more in the line of
> > "catastrophic", I feel! ;)
>
> You have many good points about how better optimization could have been
> accomplished. And you rightfully pointed out that the specification
> (API) is flawed in this respect. Does someone who worked with the
> JSR-168 working group know if these were discussed?
>
> So far as I can tell, the current API is final (for version 1.0). I
> don't know what more can be done at this point.
>
no this one will live with us. there were long discussions in the EG
about this. my proposal was to use a listener (or additional lifecycle
method) for setting the dynamic title, but the vast majority of the EG
wanted to stick with the servlet pattern to set headers before writing
to the output stream. The argument was that most portals will do
buffering anyway....
> > | The thing to remember, as I made this mistake, too, is that Pluto's
> > | portal container is for TCK compliance only, and is not meant to be
> used
> > | as a portal container itself.
> >
> > There ain't no such thing as "Portal Container". There is however, a
> > "Portlet Container", and a "Portal". "portalImpl" (the "driver") is,
> yes,
> > simply a "portal" to run the Pluto Portlet Container through the TCK.
> > However, several Portals uses, and more will use, the Pluto Portlet
> > Container as their Portlet Container - Pluto must be good!
>
> OK. I think I see my mistake, and the mistake of my mistake. I
> accepted Hepper-san's explanation that:
>
> | The pluto portal implementation is just a simple driver in order
> | to pass the TCK and give an example of how to use pluto. Therefore
> | it does not support internationalization. For full portal
> | capabilities, please check jetspeed 2 that uses pluto and provides
> | a full blown portal.
>
> He, too, blurs the scope of the Portal and the Portlet Container. The
> Portlet Container is the portion that will get reused by other Portals,
> and thus only needs to guarantee TCK compliance.
>
> The Portal, on the other hand, can be as simple or as powerful as the
> Pluto team would like to make it. Other portals are *not* required to
> be implemented the same as the Pluto Portal. They must only conform to
> the same behavior as Pluto's Portlet Container. Therefore, the above is
> not a valid excuse to exclude the patch I sent, or a variation thereof
> that will support internationalization.
>
my point was that not the pluto container is prohibiting the
internationalization, but the pluto portal. I completely agree that the
container must be as good as possible.
> I know that that wasn't exactly the point you were trying to make, but
> it has changed the way I view that response from Hepper-san. Thank you
> very much for challenging that view point.
>
> > Jetspeed 2 uses Pluto as portlet container. How can Jetspeed 2 be
> > performant and i18n compliantm, if pluto does things in an unoptimal
> way,
> > and doesn't take care of any i18n elements?
>
> I don't know how the "unoptimal way" can be avoided, since that's part
> of the specification.
>
> However, the i18n aspects can be avoided since Jetspeed 2 doesn't use
> Pluto's org.apache.pluto.portalImpl.Servlet as the Portal itself. This
> is the level that the content type that gets returned to the client
> (browser, web phone, PDA, B2B app, etc.) gets set. That was my
> understanding of Hepper-san's comment, and I still see it as valid.
>
> What I no longer see as valid is that Pluto *must not* implement i18n
> support in its own Portal.
>
> You sound like you can give me an honest opinion. What do you think of
> my proposed patch? If there is a better way to support i18n under the
> current framework, I'd be very interested in hearing your opinion.
>
Stefan
Re: Some comments after code-browsing.
Posted by Michael Westbay <we...@users.sourceforge.net>.
Stølsvik-san wrote:
> [About optimizations]
>
> This is not "less than optimal", this is more in the line of
> "catastrophic", I feel! ;)
You have many good points about how better optimization could have been
accomplished. And you rightfully pointed out that the specification
(API) is flawed in this respect. Does someone who worked with the
JSR-168 working group know if these were discussed?
So far as I can tell, the current API is final (for version 1.0). I
don't know what more can be done at this point.
> | The thing to remember, as I made this mistake, too, is that Pluto's
> | portal container is for TCK compliance only, and is not meant to be
used
> | as a portal container itself.
>
> There ain't no such thing as "Portal Container". There is however, a
> "Portlet Container", and a "Portal". "portalImpl" (the "driver") is,
yes,
> simply a "portal" to run the Pluto Portlet Container through the TCK.
> However, several Portals uses, and more will use, the Pluto Portlet
> Container as their Portlet Container - Pluto must be good!
OK. I think I see my mistake, and the mistake of my mistake. I
accepted Hepper-san's explanation that:
| The pluto portal implementation is just a simple driver in order
| to pass the TCK and give an example of how to use pluto. Therefore
| it does not support internationalization. For full portal
| capabilities, please check jetspeed 2 that uses pluto and provides
| a full blown portal.
He, too, blurs the scope of the Portal and the Portlet Container. The
Portlet Container is the portion that will get reused by other Portals,
and thus only needs to guarantee TCK compliance.
The Portal, on the other hand, can be as simple or as powerful as the
Pluto team would like to make it. Other portals are *not* required to
be implemented the same as the Pluto Portal. They must only conform to
the same behavior as Pluto's Portlet Container. Therefore, the above is
not a valid excuse to exclude the patch I sent, or a variation thereof
that will support internationalization.
I know that that wasn't exactly the point you were trying to make, but
it has changed the way I view that response from Hepper-san. Thank you
very much for challenging that view point.
> Jetspeed 2 uses Pluto as portlet container. How can Jetspeed 2 be
> performant and i18n compliantm, if pluto does things in an unoptimal way,
> and doesn't take care of any i18n elements?
I don't know how the "unoptimal way" can be avoided, since that's part
of the specification.
However, the i18n aspects can be avoided since Jetspeed 2 doesn't use
Pluto's org.apache.pluto.portalImpl.Servlet as the Portal itself. This
is the level that the content type that gets returned to the client
(browser, web phone, PDA, B2B app, etc.) gets set. That was my
understanding of Hepper-san's comment, and I still see it as valid.
What I no longer see as valid is that Pluto *must not* implement i18n
support in its own Portal.
You sound like you can give me an honest opinion. What do you think of
my proposed patch? If there is a better way to support i18n under the
current framework, I'd be very interested in hearing your opinion.
--
Michael Westbay
Re: Some comments after code-browsing.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
Thanks for comments..
Good point about the "rearranging" of the output of the portlet - however
it sounds rather labor-intensive - but I get the idea. What about the
charset-setting, then? The writer is supposed to be made according to the
content-type's charset setting, right? Or, wait, it could of course also
be so that -if- the Corelet says "text/html", then you'd return the output
means directly, but if you say "text/wml" (?), then you'd give him a
transformer-writer.. hmm.. okay..
Anyways - the portal itself should then most definately set the charset
to utf-8, to accomodate any chinese, norwegian and american portlet
displayed in there at the same time!
On Thu, 5 Feb 2004, Michael Westbay wrote:
| I believe that some of your arguments for optimizing output streaming
| fall under this, too. Compliance to the TCK is the only thing that
| Pluto is interested in testing. While forcing the programmer to use
| more optimal logic, such as specifying the title before writing
| anything, is great in theory, there may be times when it isn't
| convenient. Therefore, the spec allows for it to be set in a less than
| optimal order.
This is not "less than optimal", this is more in the line of
"catastrophic", I feel! ;)
There are plenty of other places where you have to do stuff before
"committing" the stream, e.g. setting headers of a servlet, redirecting,
and that sort.
Setting the title -clearly- falls in under this category.
And why wouldn't you know what the title would be when you start the
rendering? Remeber, this -is- the second phase, the render(..) method.
Thus, any state changes should have been done in processAction(..) already
And anyway, if you have to decide the title in the render step - then
just do that, -before- you start writing to the stream - it ain't that
difficult to reorder your code!
|
| If all portlets were being created by a single developer or team, then
| optimizations such as writing directly to the Servlet's output stream
| would be possible, although it would most likely bring up problems with
| synchronization or forbid running the portlets in parallel. If TCK
| compliance isn't important, and all portlets used conformed to a set of
| optimal guidelines as you suggest, such an "optimal" portal container
| could be created.
I don't get this point at all. TCK compliance doesn't affect this.
If you want to do parallel rendering, then of course you can't give the
servlet stream to the portlet - but that would be a totally different
thing. Since Pluto -does- render things in serial, and that the JSR is
defined around such a scenario (fragments are rendered in a serial way,
that's the reason for two-stage processing (action/render)), the setTitle
should be invoked before any rendering, and the standard should adress
this.
|
| The thing to remember, as I made this mistake, too, is that Pluto's
| portal container is for TCK compliance only, and is not meant to be used
| as a portal container itself.
There ain't no such thing as "Portal Container". There is however, a
"Portlet Container", and a "Portal". "portalImpl" (the "driver") is, yes,
simply a "portal" to run the Pluto Portlet Container through the TCK.
However, several Portals uses, and more will use, the Pluto Portlet
Container as their Portlet Container - Pluto must be good!
| That's what Jetspeed2 is for. It would be nice to test non ISO-8895-1
| based portlets with the Pluto container, but i18n handling is outside
| its scope as, since Pluto is the reference implementation, if Pluto
| supported i18n, then all other containers would be required to support
| it in the same manner.
Jetspeed 2 uses Pluto as portlet container. How can Jetspeed 2 be
performant and i18n compliantm, if pluto does things in an unoptimal way,
and doesn't take care of any i18n elements?
| By not supporting i18n, each container vendors is free to implement it
| in their own way, hopefully adding value to their respective containers.
I get confused of your use of the word "container".
|
| While I mainly focused on the i18n issues, I think that several other
| issues you've raised fall under the same TCK compliance matter. Pluto
| only covers aspects that vendors are *required* to comply with, nothing
| more.
Again, since the Pluto Container is posed to be used as the Portlet
Container for many -Portals-, then it should comply with everything, also
elements that aren't strictly a part of the TCK.
And while I'm at it: HOW can the TCK fail to check i18n issues? I mean, we
live on a globe where not everything is expressible in latin-1.
Endre.
Re: Some comments after code-browsing.
Posted by Michael Westbay <we...@users.sourceforge.net>.
Stølsvik-san wrote:
> Btw: I believe this somewhat relates to the newly filed bug #26586.
As the filer of the bug, I can say that, yes, these questions are all
related as they deal with i18n. The response that I got was that the
Pluto portal only deals with confirming TCK compatibility, which does
*not* include any i18n tests. I haven't looked into changing the MIME
section of the content type yet, but suspect that only text/html is
supported (tested?) as well.
It is true that you will only want to set the response charset once,
which is why the RenderResponse.setContentType(String contentType)
strips everything after the ";" in the contentType being set. This will
actually allow RenderResponse to work as is in other portal containers
without exceptions being raised or unexpected results caused by changing
character sets mid-stream.
To support i18n, the portal container *must* allow the user to define
the charset for the output stream. The Pluto portal container does not,
as this will be a portal container specific function. (My patch will do
it, if you want to test i18n with the Pluto portal container, but don't
expect other portals to support such a method.) If you want multiple
charsets to be supported, setting the portal container to UTF-8 is best.
Otherwise, I can imagine a portlet container setting the character set
internally depending on the user's language/locale preference, with only
portlets supporting such locales being offered.
As for changing content-type to something like text/xml or text/wap,
again, it doesn't appear that the Pluto portal container supports this.
But other ones may. For example, if your portlet supports text/xml,
and text/xml is returned, the portal container may have XSL transforms
ready and waiting to output that in HTML or WAP. If your portlet
specifies text/wap, then transforms will send it out as-is to web phones
or convert it to HTML for browsers. That *will be* the job for the
portal container to implement. The Pluto portal container chooses not
to as such functionality will be container specific, thus, outside the
realm of TCK compliance and Pluto.
I believe that some of your arguments for optimizing output streaming
fall under this, too. Compliance to the TCK is the only thing that
Pluto is interested in testing. While forcing the programmer to use
more optimal logic, such as specifying the title before writing
anything, is great in theory, there may be times when it isn't
convenient. Therefore, the spec allows for it to be set in a less than
optimal order.
If all portlets were being created by a single developer or team, then
optimizations such as writing directly to the Servlet's output stream
would be possible, although it would most likely bring up problems with
synchronization or forbid running the portlets in parallel. If TCK
compliance isn't important, and all portlets used conformed to a set of
optimal guidelines as you suggest, such an "optimal" portal container
could be created.
The thing to remember, as I made this mistake, too, is that Pluto's
portal container is for TCK compliance only, and is not meant to be used
as a portal container itself. That's what Jetspeed2 is for. It would
be nice to test non ISO-8895-1 based portlets with the Pluto container,
but i18n handling is outside its scope as, since Pluto is the reference
implementation, if Pluto supported i18n, then all other containers would
be required to support it in the same manner. By not supporting i18n,
each container vendors is free to implement it in their own way,
hopefully adding value to their respective containers.
While I mainly focused on the i18n issues, I think that several other
issues you've raised fall under the same TCK compliance matter. Pluto
only covers aspects that vendors are *required* to comply with, nothing
more.
By the way, do I need to close bug #26586 since it will not be
supported? Or does a project lead do that?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26586
Hope this helps.
--
Michael Westbay
Re: Some comments after code-browsing.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Wed, 4 Feb 2004, Endre Stølsvik wrote:
| *) Several API issues with RenderResponse, RenderRequest
|
| 1) Enumeration RenderRequest.getResponseContentTypes[s]()
| 2) String RenderResponse.getContentType()
| 3) void RenderResponse.setContentType(String contentType)
| 4) PrintWriter RenderResponse.getWriter()
| 5) OutputStream RenderResponse.getPortletOutputStream()
|
| What's the relation between 1) and 2) ?
|
| How may I set the ContentType (3) of the response, -if- another Portlet
| have decided upon something else? Which markups allow this? For the HTTP
| variant (and I thought that Portlets -are- gotten over HTTP), I thought
| that this was a HTTP -header-, and not something that could be changed
| throughout the response.
| Then the encoding: what clients are able to switch encodings multiple
| times during one page-rendering?
| What about the aggregator, then? The Portal's header and navigation
| tools (for example) are the first HTML (or whatever) that will be output,
| in effect setting the content-type (and encoding) for the entire
| aggregation (the "desktop") of Portlets.
Btw: I believe this somewhat relates to the newly filed bug #26586.
Endre.