Jeremy Boynes wrote:
> The parent/childrelationship between configuration ids defines the
> parent/child classloader structure.
>
> One thing you could do is make all the portlet applications children of
> the portal application. That way they could see all its classes
> (including the portlet libr
Scott Anderson wrote:
I was not as clear as I could have been. I was
referring to a problem Tomcat was having preserving
portlet application sessions so that portlets within
the same portlet application could share data and find
the right application context. This problem was
related to Tomcat not
Jeremy Boynes wrote:
>> The biggest issues that have been recently biting
the Pluto team have
>> been related to Tomcat's implementation of cross
context support for
>> the portal driver war and portlet wars. This
functionality lets
>> portlets access shared portlet sessions and
contexts. How wo
Scott Anderson wrote:
The biggest issues that have been recently biting the Pluto team have
been related to Tomcat's implementation of cross context support for
the portal driver war and portlet wars. This functionality lets
portlets access shared portlet sessions and contexts. How would I
turn on
David Jencks wrote:
> Cross context sessions are hard to get to work
right,
> but I think we have them working properly in
> geronimo/jetty with pluto.
> [...]
> Is this what you are asking for?
There has been confusion as to exactly what the
portlet spec is asking for in this area. However, one
On Apr 1, 2005, at 10:47 AM, David Jencks wrote:
On Apr 1, 2005, at 10:33 AM, Scott Anderson wrote:
David Jencks wrote:
In my first attempt I noticed that Jetty was
ignoring
the context name I had specified in
META-INF/context.xml and used the name of the war
file
instead.
We ignore all jetty-speci
On Apr 1, 2005, at 10:33 AM, Scott Anderson wrote:
David Jencks wrote:
In my first attempt I noticed that Jetty was
ignoring
the context name I had specified in
META-INF/context.xml and used the name of the war
file
instead.
We ignore all jetty-specific deployment info.
It turns out that this is a
David Jencks wrote:
>> In my first attempt I noticed that Jetty was
ignoring
>> the context name I had specified in
>> META-INF/context.xml and used the name of the war
file
>> instead.
>
> We ignore all jetty-specific deployment info.
It turns out that this is a Tomcat specific mechanism
for spe
On Thu, Mar 31, 2005 at 02:46:32PM -0800, Scott Anderson wrote:
> Deployment failed
> Server reports: No deployer present in kernel
I use the "distribute" command to deploy my application and get this
error if there's an instance of Geronimo running when I run the
deployer. Not sure whether it
> > Once I figured this out it also appeared that
> > Jetty was ignoring the welcome file specified in
> > WEB-INF/web.xml and showing the contents of the war
> > directory instead.
> This is very surprising to me. If you can verify this can you open a
> jira issue with a test case?
>
Scott,
Scott Anderson wrote:
I built a minimal war and ran into deployment issues
with both Jetty and Tomcat...
Jetty
-
In my first attempt I noticed that Jetty was ignoring
the context name I had specified in
META-INF/context.xml and used the name of the war file
instead.
I don't think we support co
On Mar 31, 2005, at 2:46 PM, Scott Anderson wrote:
I built a minimal war and ran into deployment issues
with both Jetty and Tomcat...
Jetty
-
In my first attempt I noticed that Jetty was ignoring
the context name I had specified in
META-INF/context.xml and used the name of the war file
instead.
I built a minimal war and ran into deployment issues
with both Jetty and Tomcat...
Jetty
-
In my first attempt I noticed that Jetty was ignoring
the context name I had specified in
META-INF/context.xml and used the name of the war file
instead. Once I figured this out it also appeared that
Jet
13 matches
Mail list logo