on 7/24/2000 11:55 AM, "Jeff Brekke" <[EMAIL PROTECTED]> wrote:
> Well the question is if it is really Turbine's or the application servers
> problem. If we want sessions to be shared across zones/contexts then it is
> the app servers problem. To have true session recovery the app servers will
> need this, and we could use it for moving the session around. I think jsdk2.2
> covers some of this but I'm not really up on the solutions. Other,
> non-appserver, solutions bounced around were to create an RMI service outside
> the application server for authentication/auth purposes that all could share (
> even on different physical machines ). I don't believe any work has been
> started, but I may be wrong.
My opinion is that it is the app servers problem and *your* (the developers)
problem, not Turbine's.
There are ways to effectively design a Turbine based application so that
multiple apps can run in the same space without name conflicts. I described
a couple ways on the Turbine list and people have already given out the
links.
As far as the app server is concerned, all Turbine is doing is sticking 2
objects into the HttpSession. If you simply have an abstraction within the
servlet engine to store the HttpSession somewhere else and all your contexts
reference that single point (or distributed point) then all you have to do
use take advantage of that.
You can also override Turbine's default behavior to store the objects
somewhere else other than an HttpSession (such as a database).
In other words, there are solutions to these problems and Turbine isn't
limiting you at all with regards to them. Just because it doesn't have all
the code done for you as default doesn't mean that it is our (the Turbine
Projects) responsibility to write your code for you. :-)
> Webmacro seems to be the lang of choice now. Freemarker, jsp, xml, and tea
> all have differing levels of support. You can just call cocoon to perform
> your processing much like Jetspeed does internal to your application. There
> may be others on the turbine list working towards integration close to
> webmacro's with these other languages, you may have to search the mail
> archives.
>
> They key here would be for you to help out and define the integration of your
> template language of choice if it is not fully supported to your liking and/or
> the authentication/auth stuff if it is important to your application. I
> started out thinking I needed to find a framework that 'had everything I would
> ever need in the future' and quickly learned that I only care about what I
> need now since everything changes so fast. Kinda the extreme programming bit
> ( www.extremeprogramming.com ). Turbine is designed well enough to hold up to
> change and has a good and growing developer base.
+1
> I thought there were ecs based examples in the examples directory. I don't
> know of others. You may want to ask on the turbine list. They are working on
> a Turbine Developers Kit which should clear up some of this. But we've done a
> large re-org of the cvs tree which may have moved some samples around.
There is an ecs based example in the getting started documentation. I
strongly suggest that people do not use ECS for your entire website. It will
bite you in the ass later on. WM is a much better solution and it would be
silly not to go that route.
I have *yet* to see a good reason for not using WM.
-jon
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
