Brett McLaughlin wrote:
> > 1. Define this for the JSP Servlet:
> > - doesn't work for non Servlet applications: Swing, console, etc.
> > - will conflict with any other object that needs a "properties" param
> > - doesn't play well with Jakarta/Servlet 2.2. Each servlet zone has to
> > define init params. WAR's really shouldn't *have* to be
> > messed with
>
> -1. In addition to what you pointed out, you now are duplicating the
> places you specify that properties file.
Right.
> >
> > 2. Have the default be {java.home}/TurbineResources.properties with
> > this value overriden in Turbine.java.
> > - works for all applications from Servlets, to Swing, console, etc.
> > - won't conflict with a JSP that needs "properties"
> > - works for all WARS.
> > - Works across servlet zones
>
> -1. Although you have some good points, you really limit folks. In
> addition, setting additional environment variables can cause problems,
> because different servlet engines, etc., handle this type of thing
> differently.
No. {java.home} is always provided by the VM. This would simply be the
fallback. There is another problem in that TurbineResources uses a
static filename. It is brain damaged in that you want to run two web
apps based on Turbine... you are screwed because you can only have one
TurbineResources pointing to one file. What needs to be done is manage
files based on the "application". So Turbine can register itself and so
can my JSP app.
> If you have to have something up immediately, specify it to the JSP
> while we work on a better solution (see below).
> So, what to do?
> (1) I still think I can get Turbine to use JSP, rather than the other
> way around. Turbine was built to be a control structure, and when you
> take it out of that context (which you are having to do, for
> understandable reasons), it starts to break down (as you are finding
> out). Once I get the Cocoon stuff solidified, I will look at how/if to
> do this
For Jakarta. YES! For JSDK 2.0/JServ. No. It would be a hopeless
kludge under JServ specifically because we don't have RequestDispatcher.
> (2) Make Turbine have more of an engine core architecture, so it can be
> called like Cocoon is called, allowing Turbine to set everything up, and
> then you just get shared resources already initialized by Turbine.
So we are still in a position where you can't have more than one
application using TurbineResources at a time. Right now I want to use
Turbine for user administration and then use it as an API within our
application. However, I can't do this specifically because of this.
Perhaps a more correct way to do it would be to have a TurbineResources
instance per web app. This way I can have JetSpeed, Turbine (user
administration) and Jyve runnign within the same VM. And when each was
to TurbineResources.getInstance() it would internally store it in a
Hashtable that was specific per web app.
This is actually better than the java.home suggestion I made.
Specifically because it had a problem where you could only have 2
applications. Turbine and then whatever was in the file.
I guess this really doesn't matter if you can share the same instance of
TurbineResources (because the values are different) but this will come
up again.
Kevin
--
Kevin A Burton
Senior Software Engineer
Kendara Inc
http://www.kendara.com
Mobile: 408-910-6145
Linux - You *will* be assimilated
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
