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 <Kristian.Waagan@sun.com> 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 <vcozma@elfyard.com <mailto:vcozma@elfyard.com>> 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.