gw webaccess 6 / 6.5 - linux/apache/tomcat -> sealing violation loading com.novell.webaccess.common.Config

[Sebastian Pein]

hi there.

testing webaccess on debian linux (3.0 testing) and got problems with
6.0.1 and 6.5.1 (tested first 6.5.1 and then 6.0.1, same error).

software:
apache 1.3.29
tomcat 4.0.4 (connected to apache with mod_jk)
j2sdk1.4.2_02 from sun

but i dont think it's a versions issue.

following several howto's i got tomcat to load (he tries at least) the
webaccess servlet. but going to /servlet/webacc with the browser (on
8180 or 80) delivers "servlet /servlet/webacc ist currently unavailable".

i guess the reason can be found in:
/var/log/tomcat4/localhost_log.[date].txt

the log says: ->
----- Root Cause -----
java.lang.SecurityException: Sealing violation loading
com.novell.webaccess.common.Config : Package com.novell.webaccess.common
is sealed.

i'm not too deep into java coding, but the problem seams to have to do
something with java classes taken from various namespaces.

did anyone of you have the same "sealing violation"?

regards

sebastian

[Jim Michael]

Sebastian Pein wrote:

> i'm not too deep into java coding, but the problem seams to have to do
> something with java classes taken from various namespaces.
>
> did anyone of you have the same "sealing violation"?

I have installed webacccess on Redhat and Suse, and have never encountered
that error. No idea what it means, but your theory sounds correct. I'll have
to ask around to see if anyone's heard of it.

--
Jim
NSC SYsop

[Ron Bingham]

It is most likely a problem with your classpath setting.

This is a symptom when the Java class loader finds the class or classes it is looking for in two places.

Your classpath is somehow set such that it is either finding two njweb.jar files or

it could be finding old classes that are contained in the jar some other place.

The sealing prevents the class from being loaded unless all of the classes from that

package are contained in the same jar file.

 

Ron

>>> Sebastian Pein<pe...@NOSPAMinfinity-networks.de> 1/26/2004 03:19:39 AM >>>

[Sebastian Pein]

ron,

as far as i get it, there is not a classpath variable around for tomcat
servlets. it takes classes from the servlet containers classes or libs
directory. these are located in the servlets WEB-INF directory. but
nevertheless, i did not found any com.novell.* classes on my machine
except those from the webacc app. the sun jdk does not contain them as well.

i tried the ibm jdk for a shot, but tomcat did not start with that one
set in $JAVA_HOME.

next step is to update tomcat to 4.1.29 (debian unstable).

do i have to try suse (dont like it)?

sebastian

[Sebastian Pein]

jim,

can you list your suse/redhat setup? espacially which jdk you used to
install and which env-vars you set (classpath?).

tia

sebastian

[Jim Michael]

Sebastian Pein wrote:

> can you list your suse/redhat setup? espacially which jdk you used to
> install and which env-vars you set (classpath?).

I used:

- JVM 1.4.1_02
- created /etc/usr/profile.d/javasdk.sh and added these lines:
JAVA_HOME=/usr/java/j2sdk1.4.1_02/
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH

javasdk.sh gets executed automatically that way.

Regarding Tomcat, I did a similar thing:

- created /etc/profile.d/tomcat41.sh
CATALINA_HOME=/usr/java/jakarta-tomcat-4.1.28 (or whatever you use)
export CATALINA_HOME

then run $CATALINA_HOME/bin/startup.sh
--
Jim
NSC SYsop

[Sebastian Pein]

gotcha!

it IS a (bloody) versions issue.

upgraded to debian unstable containing tomcat 4.1.29. at first there was
error "java.security.AccessControlException: access denied", but that is
to controlled by security settings in /etc/default/tomcat4 -> USE
SECURITY MANAGER = yes|no (file location may differ in your distro, this
could be also set in your tomcat4 startup-script, usually in
/etc/init.d/tomcat4). set to "no", then i got login screen and login
with jdoe worked perfectly.

with a little testing it might be possible to figure out the right
security setup.

thanks for your help

sebastian