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 "Glenn R. Golden" <gg...@umich.edu> on 2003/10/30 02:53:51 UTC
problem parsing web.xml with
It looks like Pluto parses not only portlet.xml but web.xml. If my
web.xml has the following:
<web-app>
<display-name>
chef-test
</display-name>
<!-- the session listener -->
<listener>
<listener-class>
org.chefproject.servlet.SessionListener
</listener-class>
</listener>
<listener>
<listener-class>
org.chefproject.servlet.AttributeListener
</listener-class>
</listener>
I get this error when running:
2003-10-29 20:14:47 PortletDefinitionRegistryService initializing...
2003-10-29 20:14:50 ServiceManager: An unidentified error occurred
org.xml.sax.SAXException: unable to find FieldDescriptor for 'listener'
in ClassDescriptor of web-app
at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown
Source)
Is this because of an incorrect or incomplete
servletdefinitionmapping.xml in pluto? Has anyone run into this?
Anybody know what's missing from this file to let it parse this web.xml?
Can castor be told to just ignore, not error out, things it doesn't
know about? Anybody know how?
Thanks.
- Glenn
Re: problem parsing web.xml with
Posted by Stefan Hepper <st...@hursley.ibm.com>.
hi Glenn,
sorry for the late response, I had some holidays :-)
yes we parse also the web.xml as we generate a new web.xml during
deployment in which we add the J2EE roles defined in the portlet.xml to
re-use the servlet container role mapping and insert the portlet tag lib
reference to work around the fact that under J2EE 1.3 there is no search
for tag libs in the common class loader.
thanks for submitting the patch.
Stefan
Glenn R. Golden wrote:
> It looks like Pluto parses not only portlet.xml but web.xml. If my
> web.xml has the following:
>
> <web-app>
>
> <display-name>
> chef-test
> </display-name>
>
> <!-- the session listener -->
> <listener>
> <listener-class>
> org.chefproject.servlet.SessionListener
> </listener-class>
> </listener>
>
> <listener>
> <listener-class>
> org.chefproject.servlet.AttributeListener
> </listener-class>
> </listener>
>
> I get this error when running:
>
> 2003-10-29 20:14:47 PortletDefinitionRegistryService initializing...
> 2003-10-29 20:14:50 ServiceManager: An unidentified error occurred
> org.xml.sax.SAXException: unable to find FieldDescriptor for 'listener'
> in ClassDescriptor of web-app
> at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown
> Source)
>
> Is this because of an incorrect or incomplete
> servletdefinitionmapping.xml in pluto? Has anyone run into this?
> Anybody know what's missing from this file to let it parse this web.xml?
>
> Can castor be told to just ignore, not error out, things it doesn't know
> about? Anybody know how?
>
> Thanks.
>
> - Glenn
>
>
Re: Spec question: portlet window id?
Posted by Stefan Hepper <st...@hursley.ibm.com>.
You're right and I think this will change for the next spec version.
Actually the ID was introduce very late in the spec with the only reason
to re-use the servlet session listners (before we had duplicated them in
order to aviod defining this ID).
Stefan
Glenn R. Golden wrote:
> What I'm looking for is the ability for a servlet and a specific portlet
> window instance to communicate. The spec goes 99% of the way to make
> this possible - it dictates exactly how the portlet scoped attribute
> name gets constructed, calling for that <ID> in the middle. It just
> doesn't have a way for the portlet to get the ID. Well, not a direct
> way...
>
> But the spec also leverages the full Servlet spec, which has session
> attribute listeners, which are called when they are placed into the
> session, and are told as part of the call what the attribute name is.
> It's a simple matter to place a special object into the portlet's
> session in portlet scope, and have that object tell the portlet exactly
> what it's ID is.
>
> All 100% standard, just not 100% direct.
>
> Since the spec gets so close, I'd consider this a hole in the spec. Not
> providing a method to get that portlet - window ID doesn't really
> acomplish anything.
>
> But it's easily dealt with.
>
> - Glenn
>
> On Monday, November 10, 2003, at 04:08 PM, Stefan Hepper wrote:
>
>> Hi Glenn,
>> no we explicitly avoided to define portlet window and portlet entities
>> for the first spec version as there were many different ideas on this
>> and the consensus was to first take a look at different
>> implementations of the spec before deciding anything on this matter,
>> as it goes into the direction of aggreagation.
>>
>> You can share attributes with servlets by using the application scope.
>> Then no prefixing is done.
>>
>> I think what you are looking for is a grouping mechanism. That was
>> also discussed but delayed for a future spec version as it was
>> considerate a special case of the app scope that you can do by hand.
>>
>> Stefan
>>
>>
>> Glenn R. Golden wrote:
>>
>>> The spec mentions that each portlet window gets a unique id from the
>>> portal, used to form the portlet scoped session attributes:
>>> javax.portlet.p.<ID>?<attribute name>
>>> I'm looking for how the portlet can find out this <ID> value for the
>>> current request being processed. Is there a standard way?
>>> The spec talks about servlets being able to share attributes with the
>>> portlet... but without this ID a servlet will have a hard time
>>> finding the attributes... of course, I'm not sure how the servlet
>>> will find it even if the portlet can know.
>>> I guess the portlet could use the application scope, so the name it
>>> uses for an attribute can be shared with the Servlet, but then we
>>> have to re-invent the portlet-window concept to keep attributes from
>>> one portlet-window separate from another.
>>> Ideas?
>>> Thanks.
>>> - Glenn
>
>
>
Re: Spec question: portlet window id?
Posted by "Glenn R. Golden" <gg...@umich.edu>.
What I'm looking for is the ability for a servlet and a specific
portlet window instance to communicate. The spec goes 99% of the way
to make this possible - it dictates exactly how the portlet scoped
attribute name gets constructed, calling for that <ID> in the middle.
It just doesn't have a way for the portlet to get the ID. Well, not a
direct way...
But the spec also leverages the full Servlet spec, which has session
attribute listeners, which are called when they are placed into the
session, and are told as part of the call what the attribute name is.
It's a simple matter to place a special object into the portlet's
session in portlet scope, and have that object tell the portlet exactly
what it's ID is.
All 100% standard, just not 100% direct.
Since the spec gets so close, I'd consider this a hole in the spec.
Not providing a method to get that portlet - window ID doesn't really
acomplish anything.
But it's easily dealt with.
- Glenn
On Monday, November 10, 2003, at 04:08 PM, Stefan Hepper wrote:
> Hi Glenn,
> no we explicitly avoided to define portlet window and portlet entities
> for the first spec version as there were many different ideas on this
> and the consensus was to first take a look at different
> implementations of the spec before deciding anything on this matter,
> as it goes into the direction of aggreagation.
>
> You can share attributes with servlets by using the application scope.
> Then no prefixing is done.
>
> I think what you are looking for is a grouping mechanism. That was
> also discussed but delayed for a future spec version as it was
> considerate a special case of the app scope that you can do by hand.
>
> Stefan
>
>
> Glenn R. Golden wrote:
>
>> The spec mentions that each portlet window gets a unique id from the
>> portal, used to form the portlet scoped session attributes:
>> javax.portlet.p.<ID>?<attribute name>
>> I'm looking for how the portlet can find out this <ID> value for the
>> current request being processed. Is there a standard way?
>> The spec talks about servlets being able to share attributes with the
>> portlet... but without this ID a servlet will have a hard time
>> finding the attributes... of course, I'm not sure how the servlet
>> will find it even if the portlet can know.
>> I guess the portlet could use the application scope, so the name it
>> uses for an attribute can be shared with the Servlet, but then we
>> have to re-invent the portlet-window concept to keep attributes from
>> one portlet-window separate from another.
>> Ideas?
>> Thanks.
>> - Glenn
Re: Spec question: portlet window id?
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Hi Glenn,
no we explicitly avoided to define portlet window and portlet entities
for the first spec version as there were many different ideas on this
and the consensus was to first take a look at different implementations
of the spec before deciding anything on this matter, as it goes into the
direction of aggreagation.
You can share attributes with servlets by using the application scope.
Then no prefixing is done.
I think what you are looking for is a grouping mechanism. That was also
discussed but delayed for a future spec version as it was considerate a
special case of the app scope that you can do by hand.
Stefan
Glenn R. Golden wrote:
> The spec mentions that each portlet window gets a unique id from the
> portal, used to form the portlet scoped session attributes:
>
> javax.portlet.p.<ID>?<attribute name>
>
> I'm looking for how the portlet can find out this <ID> value for the
> current request being processed. Is there a standard way?
>
> The spec talks about servlets being able to share attributes with the
> portlet... but without this ID a servlet will have a hard time finding
> the attributes... of course, I'm not sure how the servlet will find it
> even if the portlet can know.
>
> I guess the portlet could use the application scope, so the name it uses
> for an attribute can be shared with the Servlet, but then we have to
> re-invent the portlet-window concept to keep attributes from one
> portlet-window separate from another.
>
> Ideas?
>
> Thanks.
>
> - Glenn
>
>
Spec question: portlet window id?
Posted by "Glenn R. Golden" <gg...@umich.edu>.
The spec mentions that each portlet window gets a unique id from the
portal, used to form the portlet scoped session attributes:
javax.portlet.p.<ID>?<attribute name>
I'm looking for how the portlet can find out this <ID> value for the
current request being processed. Is there a standard way?
The spec talks about servlets being able to share attributes with the
portlet... but without this ID a servlet will have a hard time finding
the attributes... of course, I'm not sure how the servlet will find it
even if the portlet can know.
I guess the portlet could use the application scope, so the name it
uses for an attribute can be shared with the Servlet, but then we have
to re-invent the portlet-window concept to keep attributes from one
portlet-window separate from another.
Ideas?
Thanks.
- Glenn
Re: problem parsing web.xml with
Posted by "Glenn R. Golden" <gg...@umich.edu>.
I've checked in a fix for this:
jakarta-pluto/src/portal/org/apache/pluto/portalImpl/services/
portletdefinitionregistry/PortletDefinitionRegistryServiceFileImpl.java
version 1.4
----------------------------
Revision : 1.4
Date : 2003/10/30 3:32:40
Author : 'ggolden'
State : 'Exp'
Lines : + 2 0
Description :
When reading the portlet.xml and the web.xml, the
unmarshaller will ignore unknown elements instead
of failing to unmarshal.
This fixes problems with elements in the xml that are
not know to Pluto's unmarshaller but are otherwise valid.
I have not seen the CVS message yet, but it's working better now.
- Glenn
On Wednesday, October 29, 2003, at 08:53 PM, Glenn R. Golden wrote:
> It looks like Pluto parses not only portlet.xml but web.xml. If my
> web.xml has the following:
>
> <web-app>
>
> <display-name>
> chef-test
> </display-name>
>
> <!-- the session listener -->
> <listener>
> <listener-class>
> org.chefproject.servlet.SessionListener
> </listener-class>
> </listener>
>
> <listener>
> <listener-class>
> org.chefproject.servlet.AttributeListener
> </listener-class>
> </listener>
>
> I get this error when running:
>
> 2003-10-29 20:14:47 PortletDefinitionRegistryService initializing...
> 2003-10-29 20:14:50 ServiceManager: An unidentified error occurred
> org.xml.sax.SAXException: unable to find FieldDescriptor for
> 'listener' in ClassDescriptor of web-app
> at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown
> Source)
>
> Is this because of an incorrect or incomplete
> servletdefinitionmapping.xml in pluto? Has anyone run into this?
> Anybody know what's missing from this file to let it parse this
> web.xml?
>
> Can castor be told to just ignore, not error out, things it doesn't
> know about? Anybody know how?
>
> Thanks.
>
> - Glenn
Re: Which Context stores PortletSession Attributes?
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Yes, this is actually a tomcat bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=4690
it should be fixed in tomcat 5.0.7.
Due to this bug two TCK testcases that depend on this spec behavior are
on the exclude list.
Stefan
Serge Huber wrote:
>
> Are you sure Tomcat is incorrect here ?
>
> sessions are attached to cookies. From what I've seen tomcat do, it
> creates two session objects, one for context A and one for context B.
> These two are different, but point to the same sessionID.
>
> Now it can become a little different if RequestWrappers are used. In
> this case by rewriting the RequestWrapper.getSession() method you can
> give access to context A's session, which should be carefully reviewed
> to make sure this is what is wanted.
>
> In my software I've been using wrappers this way, and made the access
> configurable, which seems to fit most requirements.
>
> Regards,
> Serge Huber.
>
> At 04:27 PM 10/30/2003, you wrote:
>
>> I've discovered that if a request comes into context A, and a
>> RequestDispatcher to context B is used to invoke some content from a
>> resource there, the context B Servlet sees the initial session from
>> the context A in the request and thus reads / writes session
>> attributes in context A.
>>
>> So it's the RequestDispatcher and cross context dispatching that's
>> doing this.
>>
>> The bad news is I'm pretty sure this is incorrect Portlet container
>> behavior as specified by the Portlet spec.
>>
>> The Servlet spec clearly describes the session scope requirements in
>> SRV.7.3. It specifically gives an example relevant to our usage:
>>
>> To illustrate this requirement with an example: if a servlet uses the
>> RequestDispatcher to call a servlet in another web application, any
>> sessions
>> created for and visible to the callee servlet must be different from
>> those visible to
>> the calling servlet.
>>
>> From this, I'd say that what Tomcat is doing is incorrect! And that
>> Pluto's use of Request Dispatching should result in proper behavior if
>> Tomcat were following the spec.
>>
>> - Glenn
>>
>> On Wednesday, October 29, 2003, at 11:00 PM, Glenn R. Golden wrote:
>>
>>> I'm surprised! From what I can see, the PortletSession Attributes
>>> are stored in the HttpSession of the Pluto webapp context, not in a
>>> session in the context in which the Portlet lives.
>>>
>>> Example: I deploy a Tomcat with two webapps - "pluto" and "chef-admin".
>>> - "pluto" is the standard webapp created by the "ant install" process
>>> from Pluto.
>>> - "chef-admin" is my webapp with a Portlet called "chef-aliastool".
>>>
>>> When my "chef-aliastool" sets attributes in it's PortletSession,
>>> which, by the way, seems to be working quite well from a Portlet
>>> perspective, these are being stored in the "pluto" context's session.
>>>
>>> I've placed HttpSessionAttribute Listeners in all my contexts, and
>>> they show the attributes being set in Pluto's context, not "chef-admin".
>>>
>>> [DEBUG] HttpSession Created: BD3DDEDB1B9FE85002C3686896355B82 : Pluto
>>> Reference Implementation
>>> [DEBUG] HttpSessionAttribute Added:
>>> javax.portlet.p.chef-aliastool_p10?org.chefproject.SessionState.chef.inited
>>> = true : BD3DDEDB1B9FE85002C3686896355B82 : Pluto Reference
>>> Implementation
>>> ...
>>>
>>> First, this is pretty cool, that it's possible - the Portlet, running
>>> in it's own context, is setting stuff in a separate context. Is it
>>> because the Portlet is called through a cross-context request
>>> dispatcher? Or is it something in the PortletRequest wrapper?
>>>
>>> Second, I'm not sure this is correct. The Portlet spec details
>>> (PLT.15.4) how the PortletSession needs to interoperate with the Http
>>> (servlet) Session. Meaning that I should be able to write a Servlet,
>>> place it in the webapp with my Portlet, and have them share session
>>> values.
>>>
>>> This I can't do now, since the Servlet doesn't see the session
>>> attributes of the Portlet, cause they are not in the session of that
>>> context, but in a session of another context.
>>>
>>> So... is this a bug or a feature? I'd be interested to hear from the
>>> IBM team and the Pluto developers about what might be going on and
>>> any thinking that led us here. And what we might do about this.
>>>
>>> Thanks!
>>>
>>> - Glenn
>>
>> </blockquote></x-html>
>
> - -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
> www.jahia.org <http://www.jahia.org/> : A collaborative source CMS and
> Portal Server
>
Re: Which Context stores PortletSession Attributes?
Posted by Serge Huber <sh...@jahia.com>.
Are you sure Tomcat is incorrect here ?
sessions are attached to cookies. From what I've seen tomcat do, it creates
two session objects, one for context A and one for context B. These two are
different, but point to the same sessionID.
Now it can become a little different if RequestWrappers are used. In this
case by rewriting the RequestWrapper.getSession() method you can give
access to context A's session, which should be carefully reviewed to make
sure this is what is wanted.
In my software I've been using wrappers this way, and made the access
configurable, which seems to fit most requirements.
Regards,
Serge Huber.
At 04:27 PM 10/30/2003, you wrote:
>I've discovered that if a request comes into context A, and a
>RequestDispatcher to context B is used to invoke some content from a
>resource there, the context B Servlet sees the initial session from the
>context A in the request and thus reads / writes session attributes in
>context A.
>
>So it's the RequestDispatcher and cross context dispatching that's doing
>this.
>
>The bad news is I'm pretty sure this is incorrect Portlet container
>behavior as specified by the Portlet spec.
>
>The Servlet spec clearly describes the session scope requirements in
>SRV.7.3. It specifically gives an example relevant to our usage:
>
>To illustrate this requirement with an example: if a servlet uses the
>RequestDispatcher to call a servlet in another web application, any sessions
>created for and visible to the callee servlet must be different from those
>visible to
>the calling servlet.
>
> From this, I'd say that what Tomcat is doing is incorrect! And that
> Pluto's use of Request Dispatching should result in proper behavior if
> Tomcat were following the spec.
>
>- Glenn
>
>On Wednesday, October 29, 2003, at 11:00 PM, Glenn R. Golden wrote:
>
>>I'm surprised! From what I can see, the PortletSession Attributes are
>>stored in the HttpSession of the Pluto webapp context, not in a session
>>in the context in which the Portlet lives.
>>
>>Example: I deploy a Tomcat with two webapps - "pluto" and "chef-admin".
>>- "pluto" is the standard webapp created by the "ant install" process
>>from Pluto.
>>- "chef-admin" is my webapp with a Portlet called "chef-aliastool".
>>
>>When my "chef-aliastool" sets attributes in it's PortletSession, which,
>>by the way, seems to be working quite well from a Portlet perspective,
>>these are being stored in the "pluto" context's session.
>>
>>I've placed HttpSessionAttribute Listeners in all my contexts, and they
>>show the attributes being set in Pluto's context, not "chef-admin".
>>
>>[DEBUG] HttpSession Created: BD3DDEDB1B9FE85002C3686896355B82 : Pluto
>>Reference Implementation
>>[DEBUG] HttpSessionAttribute Added:
>>javax.portlet.p.chef-aliastool_p10?org.chefproject.SessionState.chef.inite
>>d = true : BD3DDEDB1B9FE85002C3686896355B82 : Pluto Reference Implementation
>>...
>>
>>First, this is pretty cool, that it's possible - the Portlet, running in
>>it's own context, is setting stuff in a separate context. Is it because
>>the Portlet is called through a cross-context request dispatcher? Or is
>>it something in the PortletRequest wrapper?
>>
>>Second, I'm not sure this is correct. The Portlet spec details
>>(PLT.15.4) how the PortletSession needs to interoperate with the Http
>>(servlet) Session. Meaning that I should be able to write a Servlet,
>>place it in the webapp with my Portlet, and have them share session values.
>>
>>This I can't do now, since the Servlet doesn't see the session attributes
>>of the Portlet, cause they are not in the session of that context, but in
>>a session of another context.
>>
>>So... is this a bug or a feature? I'd be interested to hear from the IBM
>>team and the Pluto developers about what might be going on and any
>>thinking that led us here. And what we might do about this.
>>
>>Thanks!
>>
>>- Glenn
></blockquote></x-html>
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
Re: Which Context stores PortletSession Attributes?
Posted by "Glenn R. Golden" <gg...@umich.edu>.
I've discovered that if a request comes into context A, and a
RequestDispatcher to context B is used to invoke some content from a
resource there, the context B Servlet sees the initial session from the
context A in the request and thus reads / writes session attributes in
context A.
So it's the RequestDispatcher and cross context dispatching that's
doing this.
The bad news is I'm pretty sure this is incorrect Portlet container
behavior as specified by the Portlet spec.
The Servlet spec clearly describes the session scope requirements in
SRV.7.3. It specifically gives an example relevant to our usage:
To illustrate this requirement with an example: if a servlet uses the
RequestDispatcher to call a servlet in another web application, any
sessions
created for and visible to the callee servlet must be different from
those visible to
the calling servlet.
From this, I'd say that what Tomcat is doing is incorrect! And that
Pluto's use of Request Dispatching should result in proper behavior if
Tomcat were following the spec.
- Glenn
On Wednesday, October 29, 2003, at 11:00 PM, Glenn R. Golden wrote:
> I'm surprised! From what I can see, the PortletSession Attributes are
> stored in the HttpSession of the Pluto webapp context, not in a
> session in the context in which the Portlet lives.
>
> Example: I deploy a Tomcat with two webapps - "pluto" and "chef-admin".
> - "pluto" is the standard webapp created by the "ant install" process
> from Pluto.
> - "chef-admin" is my webapp with a Portlet called "chef-aliastool".
>
> When my "chef-aliastool" sets attributes in it's PortletSession,
> which, by the way, seems to be working quite well from a Portlet
> perspective, these are being stored in the "pluto" context's session.
>
> I've placed HttpSessionAttribute Listeners in all my contexts, and
> they show the attributes being set in Pluto's context, not
> "chef-admin".
>
> [DEBUG] HttpSession Created: BD3DDEDB1B9FE85002C3686896355B82 : Pluto
> Reference Implementation
> [DEBUG] HttpSessionAttribute Added:
> javax.portlet.p.chef-
> aliastool_p10?org.chefproject.SessionState.chef.inited = true :
> BD3DDEDB1B9FE85002C3686896355B82 : Pluto Reference Implementation
> ...
>
> First, this is pretty cool, that it's possible - the Portlet, running
> in it's own context, is setting stuff in a separate context. Is it
> because the Portlet is called through a cross-context request
> dispatcher? Or is it something in the PortletRequest wrapper?
>
> Second, I'm not sure this is correct. The Portlet spec details
> (PLT.15.4) how the PortletSession needs to interoperate with the Http
> (servlet) Session. Meaning that I should be able to write a Servlet,
> place it in the webapp with my Portlet, and have them share session
> values.
>
> This I can't do now, since the Servlet doesn't see the session
> attributes of the Portlet, cause they are not in the session of that
> context, but in a session of another context.
>
> So... is this a bug or a feature? I'd be interested to hear from the
> IBM team and the Pluto developers about what might be going on and any
> thinking that led us here. And what we might do about this.
>
> Thanks!
>
> - Glenn
Which Context stores PortletSession Attributes?
Posted by "Glenn R. Golden" <gg...@umich.edu>.
I'm surprised! From what I can see, the PortletSession Attributes are
stored in the HttpSession of the Pluto webapp context, not in a session
in the context in which the Portlet lives.
Example: I deploy a Tomcat with two webapps - "pluto" and "chef-admin".
- "pluto" is the standard webapp created by the "ant install" process
from Pluto.
- "chef-admin" is my webapp with a Portlet called "chef-aliastool".
When my "chef-aliastool" sets attributes in it's PortletSession, which,
by the way, seems to be working quite well from a Portlet perspective,
these are being stored in the "pluto" context's session.
I've placed HttpSessionAttribute Listeners in all my contexts, and they
show the attributes being set in Pluto's context, not "chef-admin".
[DEBUG] HttpSession Created: BD3DDEDB1B9FE85002C3686896355B82 : Pluto
Reference Implementation
[DEBUG] HttpSessionAttribute Added:
javax.portlet.p.chef-
aliastool_p10?org.chefproject.SessionState.chef.inited = true :
BD3DDEDB1B9FE85002C3686896355B82 : Pluto Reference Implementation
...
First, this is pretty cool, that it's possible - the Portlet, running
in it's own context, is setting stuff in a separate context. Is it
because the Portlet is called through a cross-context request
dispatcher? Or is it something in the PortletRequest wrapper?
Second, I'm not sure this is correct. The Portlet spec details
(PLT.15.4) how the PortletSession needs to interoperate with the Http
(servlet) Session. Meaning that I should be able to write a Servlet,
place it in the webapp with my Portlet, and have them share session
values.
This I can't do now, since the Servlet doesn't see the session
attributes of the Portlet, cause they are not in the session of that
context, but in a session of another context.
So... is this a bug or a feature? I'd be interested to hear from the
IBM team and the Pluto developers about what might be going on and any
thinking that led us here. And what we might do about this.
Thanks!
- Glenn
Pluto ('s portal) 's idea of a url to itself
Posted by "Glenn R. Golden" <gg...@umich.edu>.
I just checked out a fresh Pluto from cvs, and when I run, I get the
Pluto Portal display, but if I click on any portlet "Test", the URL has
localhost:8080/ in it. This is not the URL I used to get there, nor is
it where I'm running Tomcat...
Did anyone change this since Pluto came to Apache? Or is this a config
setting somewhere that I forget about and forget to re-set when I got
new code? Any ideas?
Thanks.
- Glenn