"Kevin A. Burton" wrote:
>
> So I now have JSP using Turbine as a user authentication like we talked
> about.
>
> There is one problem. TurbineResources.properties.
I was wondering when this would come up ;-)
>
> Turbine.java sets this as an init parameter during (init).
>
> Anything that circumvents this servlet will break. There are a couple
> ways around this.
>
> 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.
>
> 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.
If you have to have something up immediately, specify it to the JSP
while we work on a better solution (see below).
>
> There are some problems with this. You wouldn't be able to provide
> multiple TurbineResources.properties. I am not sure if there is a
> decent way around this. If someone *really* wants it we could provide a
> custom property that would be specific per VM.
>
> Thoughts?
This is _exactly_ why we don't call Cocoon's processing directly, but
rather use Engine.getInstance(). This allows the engine to be set up by
Cocoon beforehand; you will notice in my diffs that if you call the
engine before it is initialized (which includes a properties file being
set) it throws an error to the application. That's because even though
we are using Cocoon elsewhere, the Engine is "owned" by Cocoon and my
application has no business setting engine properties for Cocoon. Only
Cocoon itself does.
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
(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.
-Brett
>
> --
>
> 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]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
