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.
