Kristian (and others who responded) - Thanks for the variety of thoughts which did help isolate the problem: your third item was the key - I wasn't sufficiently "controlling" Jetty and it managed to find another jar even though it wasn't in the classpath I had set when I started the app. I have now (at long last) found and neutered that problem. I very much appreciate the feedback from all who responded.
Thanks again, Richard On Thu, Oct 9, 2008 at 10:02 AM, Kristian Waagan <[EMAIL PROTECTED]>wrote: > On 09.10.08 15:17, Richard Scott wrote: > >> Thanks, but it doesn't help. My requirements are for the networked >> database, not the embedded version (which does, as you note, work properly). >> > > Hello Richard, > > Just a few thoughts. > 1) Are you sure there aren't more than one version of derby.jar in your > system? > 2) Can any of the components you are using pull in its own version of > Derby? > 3) Are you doing any kind of class loader trickery? Or is for instance > Jetty doing it? > > 4) Are you able to get the code base(s) for the class causing the > violation? > 5) Do you have a more detailed stack trace? > > A more general question, can a sealing violation happen in any other case > than trying to load classes in the same package from two different sources / > code bases? > > > Sorry, not really helpful, but this is hard to verify/debug with the > current information. > > > regards, > -- > Kristian > > >> On Thu, Oct 9, 2008 at 1:01 AM, Valentin Cozma <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Richard Scott wrote: >> >> Derby gurus: >> >> I am seeing an unexpected sealing violation on >> org.apache.derby.iapi.services.monitor. There is not more than >> one instance of derby.jar in the classpath (as you can verify >> below). >> >> I have an application (under construction) that starts several >> services from within the application. Among these are Jetty to >> support a web app, and Derby using the network server (via >> NetworkServerControl) instead of using the embedded model. >> These services start without incident, and as expected, I can >> access the application's database externally (via ij, for >> instance). However, when there's a hit on the web-app which >> triggers a client-side connection to the database (using the >> org.apache.derby.jdbc.ClientDriver), it barfs with >> "java.lang.SecurityException: sealing violation: package >> org.apache.derby.iapi.services.monitor is sealed". >> >> Can this be fixed other than by starting Derby externally to the >> application (which works just fine)? >> >> Here's what getSysinfo() spits out when after the engine is >> started: >> >> Appreciate whatever enlightenment you can provide! >> >> >> what I can tell you is that I'm using embedded+network derby and >> jetty in the same jvm , with no problem at all. >> first start derby, then jetty. >> 10.3.3.0 <http://10.3.3.0>, all 4 derby jars in classpath, didn't >> bother about the order ever. >> >> I do remember that I ran into that "sealing violation" once, I think >> it was a library or version problem. >> >> hope this helps. >> >> >> >> >
