on 7/3/2000 5:13 PM, "dave bryson" <[EMAIL PROTECTED]> wrote:
> 1. Can you run more than 1 Turbine application per VM?
I don't see why not.
One issue with this is namespaces with regards to the way that the packages
are found.
For example:
module.package=org.apache.jyve, org.tigris.scarab
If Jyve has a screens.Login and scarab has a screens.Login, then the one for
Jyve will be found first even though you might have wanted the one for
Scarab.
The way around it is to always set things up like this:
org.apache.jyve.screens.jyve and org.apache.scarab.screens.scarab
That way, it would be something like this:
screens.jyve.Login and screens.scarab.Login
urls would look like this:
http://www.f.com/zone/Turbine/screen/scarab.Login
http://www.f.com/zone/Turbine/screen/jyve.Login
that makes for ugly paths on the filesystem because it isn't quite apparent
in each project why you setup the paths like that, it looks like duplication
of the project name. it only becomes apparent why things are done that way
when you have to use the urls. :-)
I could see doing a hack where you took the last bit of the package name and
appended it to the beginning of the search path so that the above URL
examples would work transparently without having code things that way.
For example:
module.package=org.apache.jyve, org.tigris.scarab
Search path for a screen with the ScreenLoader would be this:
org.apache.jyve.screens.jyve
org.apache.jyve.screens
org.tigris.scarab.screens.scarab
org.tigris.scarab.screens
Then you would only need to code your URL's like the URL example above. You
wouldn't need to put things into special packages or anything like that.
------------------------------------------------------------------------
The other way to deal with this issue is to load Scarab and Jyve within
their own zones (ie: classloaders). Thus, they are accessible by different
paths:
http://www.f.com/jyve/Turbine/screen/Login
http://www.f.com/scarab/Turbine/screen/Login
Now, you get into double login issues because each system isn't sharing
session information because of the classloader boundary. This could be
solved by abstracting the session information into a central repository and
that is probably the right way to go.
Yes, this should be discussed further and a final resolution should be
determined.
btw, dave what is up with the new email addr? :-)
-jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
