RE: [enhydra] Postgres driver kills MySQL communication

["Michael Warne" <mwarne@xxxxxxxxxxxxxxxxxx>]

Hi Petr,

I think Michael may be right.  Dods probably has static fields in the class.  
Once a java classloader loads a class, it is global to all other classes 
loaded by the same classloader.  

I have had similar issues in the past, and I ended up running 2 instances of 
Multiserver.  If you try Michaels suggestion let us know.  I have always had 
trouble trying to figure out when I should put a class in the 
Server.ClassPath[] of an application, and when I should add it to the 
Multiserver application class path.  In particular when does Enhydra create a 
new classloader for an application?  Is it after it has started the app, or 
before?  Sometimes out of frustration I have added 3rd party jars to the 
system classpath, when I couldn't get it to work in the Server.ClassPath[] 
config file setting.

Hope the "multiple Dods jar" idea works.
Mike.




-----Original Message-----
From: Michael Strapp [mailto:mstrapp@xxxxxxxxxxxxx] 
Sent: Monday, October 25, 2004 5:57 AM
To: Enhydra Mailing List
Subject: Re: [enhydra] Postgres driver kills MySQL communication


Hi Petr,
    I can't say for sure whether this is a flaw in Enhydra or DODS.  I was 
able to determine that the problem was caused by the fact that one of the 
configuration classes (org.enhydra.dods.Common in the case of the 
DatabaseManager.ConfigurationDir setting) was getting loaded by the system 
classloader instead of the classloader created for each individual Enhydra 
app - causing the static member variables in the class(es) to be shared 
across all apps.
    Actually, I just had an idea that I hadn't thought of before - if you 
remove the jar(s) for the dods classes from the system classpath (or even 
move them out the enhydra5.1 tree to ensure that the regular Enhydra scripts 
can't find them), and explicitly add the dods jars to the Server.ClassPath[] 
setting in the .conf file for each Enhydra app, that would allow the DODS 
classes to be loaded only by the classloader belonging to each individual 
Enhydra app.  With the DODS project having been separated from the main 
Enhydra project, the multiserver hopefully wouldn't have a problem with that 
configuration - in which case, this would make each Enhydra app load the 
DODS classes with its own classloader and keep its own copy of the class 
definition (including any static member variables within the class).  In 
which case, that just might do the trick.

    If you end up giving this idea a try, let me know how it turns out.  In 
my case, I've already worked around the problem for now, but I'll probably 
revisit this and try it out myself at some point.

Regards,
Mike.

----- Original Message ----- 
From: "Petr Stehlik" <pstehlik@xxxxxxxxxx>
To: <enhydra@xxxxxxxxxxxxx>
Sent: Monday, October 25, 2004 10:36 AM
Subject: Re: [enhydra] Postgres driver kills MySQL communication


V Po, 25. 10. 2004 v 16:11, Michael Strapp píše:

Michael,

>    It sounds like you have multiple Enhydra apps running under the 
> same multiserver with different database configurations.  Under DODS 
> 5.x, some of the database settings are shared between applications 
> (and declaring different values for them in different .conf files 
> results in the value being used from whatever application happened to 
> initialize last) - I found
> that this was the case for the DatabaseManager.ConfigurationDir setting a
> couple months back (see
> http://mail-archive.objectweb.org/dods/2004-07/msg00000.html) and I have
> since found that the DatabaseManager.ObjectIdColumnName and
> DatabaseManager.VersionColumnName settings are similarly affected.

now I know what you mean. Isn't this a shortcoming in the DODS? What does the 
Enhydra team think?

Petr






--------------------------------------------------------------------------------


>
> --
> You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx 
> mailing list. To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>