Re: deploying minimal web app

[Jeremy Boynes]

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 properly preserving the session
id used when the portal driver web appplication
forwarded a client request to a portlet in a portlet
application. I believe the tricky part was related to
cookie management.
We went through a few of those issues with Jetty too :-) In the end we 
ended up with a solution where all contexts have the same session id 
(used in the cookie) but each context's attribute space is isolated from 
each others so there can be no conflict in attibute names. Session 
invalidation is server wide.

I was not advocating that portlet applications share
their data with other portlet applications. I believe
portlet security will be a big issue requiring secure
messaging and data interchange as well as portlet
sandboxes. You could even see portlet DRM wrappers. I
hear talk of portlet messaging being included in the
next portlet spec. I would like to see a solution that
leverages something like the infobus.

The easiest way to share the libraries is to bundle
the portal and
portlet wars together into an ear and then add the
libraries to the ear
deployment plan as dependency's.
Alternatively you can create a custom config
containing dependencys
for the libraries and then make that the parent of
your portal and
portlet applications; this allows them to be
deployed separately.
I don't think the ear solution won't work because I
need support for dynamically deploying and undeploying
of individual portlet applications while the rest of
the portlets registered with the portal application
keep on running. What I need is an object from a Pluto
jar that is instantiated by the portal driver web
application be sent as a request attribute to a
portlet web application and a portlet be able to use
that object without encountering any classloader
issues. I'd think that these shared jars would need be
loaded by a common parent classloader to the web apps.
It looks like your second option might be this
solution?? Isn't there a directory in Jetty dedicated
for this purpose? In Tomcat this is the shared/lib directory.
There might be but when its embededed in Geronimo we take over most of 
those functions. Geronimo does not follow the pattern of loading 
everything in a directory into the classloader as we wanted to give 
people precise control; the equivalent mechanism is to list the 
libraries an application needs as dependencies and then we ensure they 
are added to its classloader from the repository. The parent/child 
relationship 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 libraries if the portal declared them as 
dependencies) but other applications running in the server would be 
isolated.

On another tack, what mechanism are you using for portlet deployment and 
for having portlets register with the portal when they start?

One of the things we have considered is adding an SPI into the builder 
subsystem that would allow portlet deployment (portlet.xml processing) 
to be integrated with webapp deployment, basically making portlet first 
class objects just like servlets.

Another would be to provide a mechanism for tying portals to portlet 
applications so that the portal was aware of lifecycle changes in the 
portlets. For example, if a portlet app was being restarted the portal 
would know when it went offline/online and hence could choose how to 
handle requests to that portlet or the invalidation of its render cache.

--
Jeremy

Re: deploying minimal web app

[Jeremy Boynes]

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 context.xml (or jetty-web.xml). Instead you can 
specify the context path in a Geronimo deployment plan - this can be 
placed inside the war's META-INF directory or supplied as an external 
plan to avoid modifying the war.

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. I noticed in the wiki that there is
an additional descriptor, geronimo-jetty.xml, that I
might need to support. I tried this and also
restarting Geronimo with the configId I had set in
geronimo-jetty.xml and neither attempt was helpful.
You should not need to do that. You can recover the server by copying 
the file config.list from modules/assembly/src/var/config into the 
var/config directory of your installation (this resets the runnning 
config list to what we orginally built) and then start your war using

$ java -jar bin/deployer.jar start ${configid}
BTW, something I did must have corrupted the
deployment module because I soon found I could no
longer deploy at all..
Deployment failed
  Server reports: No deployer present in kernel
Tomcat
--
snip/
Sorry, I can't help with Tomcat.
I am planning on integrating Apache Pluto with
Geronimo and since I do not have any information on
how compatible Pluto is with Jetty I think my best bet
is to work on getting the Tomcat issues solved. I'd
appreciate any suggestions on getting there from here.
Gluecode integrated and certified Pluto 1.0 with Geronimo/Jetty around 
the M3 timeframe as part of our JOE 1.0 release. All the fixes for that 
were contributed back to Pluto so it should work. You do need to use the 
context based registry (not the one that scans the webapp directory) - 
sorry the name eludes me right now.

I am very interested in getting 1.1 to work but just haven't managed to 
get to it - is that the version you were thinking of using?

--
Jeremy

Re: deploying minimal web app

[toby cabot]

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 applies to you...

deploying minimal web app

[Scott Anderson]

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 specifying web app context properties. I had
thought that this had made it into the servlet spec.
However, it would be nice if Jetty shared this
mechanism.

 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?

I did some further investigation and discovered that
the welcome file list *is* properly supported if there
is only one welcome file in the list. I encountered
the failure when I was testing with a war generated
from NetBeans default web application template which
initializes this list with three entries...

welcome-file-list
welcome-file
index.jsp
/welcome-file
welcome-file
index.html
/welcome-file
welcome-file
index.htm
/welcome-file
/welcome-file-list

...but only includes an index.jsp file with the war
that is generated. Let me know if you want me to add
this issue to JIRA. I have my workaround.

 You should look at Gluecode JOE which is
geronimo/jetty + pluto (+ a  
 management console and some other goodies).
 [...]
 I expect integrating pluto with tomcat in geronimo
would
 be a fairly major project until the tomcat
integration is more
 complete.

I will check out JOE. I eventually want to support
deploying my stuff on both Tomcat and Jetty.

Jeremy Boynes wrote:

 Gluecode integrated and certified Pluto 1.0 with
Geronimo/Jetty around
 the M3 timeframe as part of our JOE 1.0 release. All
the fixes for that
 were contributed back to Pluto so it should work.
You do need to use the
 context based registry (not the one that scans the
webapp directory) -
 sorry the name eludes me right now.


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 a web app context's crossContext
behavior in the Geronimo/Jetty or JOE environments? If
I can get this behavior to work and determine what
Jetty directory I need to install Pluto's libraries so
that the contents of the jars can be shared by the
portal driver war and the portlet wars...the
equivalent of Tomcat's shared/lib directory...I think
I will be in good shape for moving forward on Jetty.

 I am very interested in getting 1.1 to work but just
haven't managed to
 get to it - is that the version you were thinking of
using?

I have been working with the Pluto 1.1 code for some
time now. It was not a hard decision for me to bypass
supporting the 1.0.1 implementation.

Thanks for the help!



__ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

Re: deploying minimal web app

[David Jencks]

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 Tomcat specific mechanism
for specifying web app context properties. I had
thought that this had made it into the servlet spec.
However, it would be nice if Jetty shared this
mechanism.
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?
I did some further investigation and discovered that
the welcome file list *is* properly supported if there
is only one welcome file in the list. I encountered
the failure when I was testing with a war generated
from NetBeans default web application template which
initializes this list with three entries...
welcome-file-list
welcome-file
index.jsp
/welcome-file
welcome-file
index.html
/welcome-file
welcome-file
index.htm
/welcome-file
/welcome-file-list
...but only includes an index.jsp file with the war
that is generated. Let me know if you want me to add
this issue to JIRA. I have my workaround.
Thanks, I'll look into this.

You should look at Gluecode JOE which is
geronimo/jetty + pluto (+ a
management console and some other goodies).
[...]
I expect integrating pluto with tomcat in geronimo
would
be a fairly major project until the tomcat
integration is more
complete.
I will check out JOE. I eventually want to support
deploying my stuff on both Tomcat and Jetty.
Jeremy Boynes wrote:
Gluecode integrated and certified Pluto 1.0 with
Geronimo/Jetty around
the M3 timeframe as part of our JOE 1.0 release. All
the fixes for that
were contributed back to Pluto so it should work.
You do need to use the
context based registry (not the one that scans the
webapp directory) -
sorry the name eludes me right now.

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 a web app context's crossContext
behavior in the Geronimo/Jetty or JOE environments? If
I can get this behavior to work and determine what
Jetty directory I need to install Pluto's libraries so
that the contents of the jars can be shared by the
portal driver war and the portlet wars...the
equivalent of Tomcat's shared/lib directory...I think
I will be in good shape for moving forward on Jetty.
Cross context sessions are hard to get to work right, but I think we 
have them working properly in geronimo/jetty with pluto.  I'm not sure 
I understand what you are asking for here.  My understanding of the 
servlet spec is that it is absolutely prohibited that the portal share 
a session with a portlet application, or that any 2 portlet 
applications share a session.  On the other hand, for a user visible 
session id, it must be possible for multiple portlet applications and 
the portal to each have separate sessions that to the user appear to be 
 keyed by the user visible session id.  IIRC the somewhat surprising 
requirement for this to work, which is not mentioned in any spec I 
could find, is that if one app destroys its sessions, all sessions with 
the same user visible  session id must be destroyed at the same time. 
 Is this what you are asking for?

thanks
david jencks

I am very interested in getting 1.1 to work but just
haven't managed to
get to it - is that the version you were thinking of
using?
I have been working with the Pluto 1.1 code for some
time now. It was not a hard decision for me to bypass
supporting the 1.0.1 implementation.
Would be great to get pluto 1.1 support!
Thanks for the help!

__
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250