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.
>>
>>
>>
>>
>
|