You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Brad Cox <bc...@virtualschool.edu> on 2002/01/30 23:38:51 UTC
More about sealing violation problem
From: Greg Wilkins <gr...@mortbay.com>
Date: Wed Jan 30, 2002 05:22:40 PM US/Eastern
To: Brad Cox <bc...@virtualschool.edu>
Cc: jetty-support@yahoogroups.com
Subject: Re: A gnarly one. Sealing violation. GREG TAKE NOTE
Yep I have seen that one.... but it only gets worse! JDK1.4
now provides
crimson and the org.w3c and javax.xml classes, so it is unclear if the
2.3 classloader recommendation now applies to these classes. If they
are now considered "system classes" then they should not be able to
be replaced by a web application.
You will find that using 1.4, you will get sealing violations
EVEN if you unseal
the jars in the webapp.
You reap what you sow... The 2.3 classloader recommendation was
and is bollocks.
By breaking the classloader hierachy with such an ill-defined
recommendation,
you are just asking for trouble.
I really recommend calling setJava2Compliant(true) on your Jetty
ContextLoaders.
In fact I think I'll make some changes to make this an easier
thing to set....
I'll also be adding org.w3c and javax.xml to the "system"
packages list, so
hopefully that will help avoid some of these issues....
and finally why I'm ranting - why does everybody include the
org.w3c and javax.xml
classes in their jars anyway?????
cheers
Brad Cox wrote:
Greg, have you seen this? I'm getting the same problem in Jetty.
My workaround was to unseal every jar in my WEB-INF/lib, but
that's clearly a hack.
Status Report: "Sealing Violation" Problems With Xerces
------------------------------------------------------------------------
* To: tomcat-dev@jakarta.apache.org
* Subject: Status Report: "Sealing Violation" Problems With Xerces
* From: "Craig R. McClanahan" <Cr...@eng.sun.com>
* Date: Wed, 07 Feb 2001 18:05:04 -0800
* Delivered-To: mailing list tomcat-dev@jakarta.apache.org
* list-help: <ma...@jakarta.apache.org>
* list-post: <ma...@jakarta.apache.org>
* list-unsubscribe: <mailto:tomcat-dev-
unsubscribe@jakarta.apache.org>
* Mailing-List: contact tomcat-dev-help@jakarta.apache.org;
run by ezmlm
* Reply-To: tomcat-dev@jakarta.apache.org
------------------------------------------------------------------------
Several people have reported difficulties with Tomcat 4.0b1when trying
to put xerces.jar (or another XML parser) in the WEB-INF/lib directory.
In theory, this should work fine -- Tomcat 4.0 implements the new
servlet 2.3 recommendation that local classes override ones from the
shared library classpath (i.e. all the JAR files in $CATALINA_HOME/lib,
which includes the JAXP 1.1 reference implementation required by
Jasper).
The good news: Thanks to the help of several folks in the Turbine and
Jetspeed communities, I was able to accumulate enough test cases to
isolate where the problem is occurring. It's definitely a problem in
the Tomcat 4.0 web app class loader, which is implementing the "local
override" functionality inconsistently.
The bad news: Several simple fix attempts have not succeeded in making
this work -- it's going to take some more digging, but I'm confident
that it can be solved within a few days. At that time, I will be asking
people to try a nightly build with the proposed fix, to ensure (a) that
it fixes the problem for everyone encountering it; and (b) that it does
not introduce other wierd things related to class loaders.
For those interested in the gory details, the problem is in
StandardClassLoader.findClass(), which delegates to the parent class
loader prior to checking the local repositories (I'm not sure this is
really correct behavior -- hence the need for some research). Consider
a class like org.xml.sax.EntityResolver, which correctly exists in both
Xerces and Crimson. If the Crimson version of this class is loaded
first, any attempt to load other org.xml.sax.* classes from Xerces will
fail with a package sealing exception, because crimson.jar is sealed.
Knowing what's wrong is the biggest part of the debugging effort -- now,
it's just a matter of finding the right solution.
Craig McClanahan
(Jon, feel free to share this status report with the Turbine and
Jetspeed lists, and anyother list you know of that has reported this
issue).
On Saturday, January 19, 2002, at 10:14 AM, Brad Cox wrote:
Thanks but I'm still stuck. The setup I'd converged on is just
as you described but I'm still getting the sealing violation. I
added a properties dump statement just before the xml operation
just to be sure.
Here's the classpath according to
System.getProperties().getProperty("java.class.path").
java.class.path:/jetty/lib/com.sun.net.ssl.jar:/jetty/lib/javax.servlet.jar:
/jetty/lib/javax.xml.jaxp.jar:/jetty/lib/org.apache.crimson.jar:/jetty/lib/
org.apache.jasper.jar:/jetty/lib/org.mortbay.jetty.jar:/jdk/lib/tools.jar
The whole System.properties().list()
java.vendor.url=http://www.ibm.com/
path.separator=:
java.vm.name=Classic VM
file.encoding.pkg=sun.io
jetty.log=/www/logs/mybank
java.vm.specification.name=Java Virtual Machine Specification
user.dir=/jcms
java.runtime.version=1.3.0
java.fullversion=J2RE 1.3.0 IBM build cx130-20010925 (...
java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
os.arch=x86
java.io.tmpdir=/tmp
line.separator=
java.vm.specification.vendor=Sun Microsystems Inc.
java.awt.fonts=
os.name=Linux
java.library.path=/jdk/jre/bin:/jdk/jre/bin/classic:/us...
java.specification.name=Java Platform API Specification
java.class.version=46.0
jetty.home=/jetty
os.version=2.2.16-22
LOG_FILE=/www/logs/mybank/yyyy_mm_dd.jetty.log
user.home=/home/bcox
user.timezone=America/New_York
java.awt.printerjob=sun.awt.motif.PSPrinterJob
file.encoding=ISO-8859-1
java.specification.version=1.3
user.name=bcox
java.class.path=/jetty/lib/com.sun.net.ssl.jar:/jetty...
java.vm.specification.version=1.0
java.home=/jdk/jre
java.specification.vendor=Sun Microsystems Inc.
user.language=en
java.vm.info=J2RE 1.3.0 IBM build cx130-20010925 (...
java.version=1.3.0
java.ext.dirs=/jdk/jre/lib/ext
sun.boot.class.path=/jdk/jre/lib/rt.jar:/jdk/jre/lib/i18n...
java.vendor=IBM Corporation
file.separator=/
java.vendor.url.bug=
java.compiler=jitc
sun.io.unicode.encoding=UnicodeBig
user.region=US
jetty.port=8080
java.lang.SecurityException: sealing violation
at java.net.URLClassLoader.defineClass(URLClassLoader.java:237)
at java.net.URLClassLoader.access$300(URLClassLoader.java:69)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:544)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:203)
at org.mortbay.http.ContextLoader.access$0(ContextLoader.java)
at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:216)
at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:189)
at
edu.virtualschool.jcms.view.JcmsPage$TaskPage.controller(JcmsPage.java:500)
at
edu.virtualschool.jwaa.AbstractPage.doRequest(AbstractPage.java:93)
at
edu.virtualschool.jwaa.AbstractServlet.doRequest(AbstractServlet.java:91)
at
edu.virtualschool.jwaa.AbstractServlet.doGet(AbstractServlet.java:50)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:291)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:542)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1265)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1219)
at org.mortbay.http.HttpServer.service(HttpServer.java:725)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:745)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:918)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:760)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287)
at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715)
at java.lang.Thread.run(Thread.java:498)
On Saturday, January 19, 2002, at 03:52 AM, jetty-
support@yahoogroups.com wrote:
For the latest information about Jetty, please see
http://jetty.mortbay.org
------------------------------------------------------------------------
There is 1 message in this issue.
Topics in this digest:
1. RE: A gnarly one. Sealing Violation
From: Bradley Williams <bw...@clientsoft.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Fri, 18 Jan 2002 07:08:17 -0500
From: Bradley Williams <bw...@clientsoft.com>
Subject: RE: A gnarly one. Sealing Violation
Had this problem with a IBM WebSphere server a while back......(Sorry)
Some classes on the System classpath in a jar are also being loaded on
another classpath
and some classes from one jar some classes from another jar. What I
typically do
is put the jaxp and crimson jar in the lib dir of the webapp.
This should
solve the problem.
Jetty is JAXP compliant last I checked. //Any JAXP Compliant Parser will
work I have tested "three"
XML is fine, just need to understand the JAXP plugability layer
a little
better.
P.S. stick with the crimson, it is the fastest from my testing
on small to
medium size documents.
Don't put all these jars in the classpath at once, that could
cause real
problems.
Xalan is a transformer not a parser so it is ok to be on the
classpath with
the others.
See the JAXP spec on suns site read the stuff on the plugability layer.
The Crimson.jar should have the correct META-INF/service entries so you
shouldn't have to do anything but put the jar in the lib directory.
In Java from my experience, first always check the classpath.
"That is the
main source of this problem."
Not what you think the classpath is, but what the VM says the
classpath is.
Hope this helps solve your problem.
((
Bradley G. Williams ))
Senior Software Engineer |_____|_
Clientsoft Inc. | | )
8323 NW 12 St. Suite 216 | |'
Miami, FL 33126 |_____|
-----Original Message-----
From: Brad Cox [mailto:bcox@virtualschool.edu]
Sent: Thursday, January 17, 2002 8:39 PM
To: jetty-support@yahoogroups.com; gregw@mortbay.com
Cc: Brad Cox
Subject: [jetty-support] A gnarly one. Sealing Violation
I've a jetty application that uses Velocity as shown below. The
application works fine except when it tries to use any flavor of
XML with a "sealing violation" in every case. The symptoms are
precisely the same nomatter which XML flavor I try. A small XML
test case works fine when run standaline (outside of jetty and
velocity). The servlet + velocity works fine if all XML related
code is removed.
From a google search on "JDOM sealing violation", it seems the
problem is that Jetty and Velocity are using different XML
flavors internally and that refs from one are resolving to the
other, triggering a sealing violation. The question is, what to
do about it. I've spent a whole day trying various guesses, but
I've found no way of disentangling them.
Can someone please help? I've got xalan, xerces, jdom, crimson,
werken.xpath, and god knows what others installed but no idea
which ones I should keep.
So far my worst XML fears are 100% confirmed. XML is a REAL hairball.
VelocityContext context = new VelocityContext();
try
{
Task thisTask = Task.load(ctx, cid, lid, tid);
Task.Page thisPage = thisTask.getPage(ctx, person.id, page);
String templatePath =
thisPage.getTemplatePath(thisTask).toString();
javax.xml.parsers.DocumentBuilderFactory factory =
javax.xml.parsers.DocumentBuilderFactory.newInstance();
javax.xml.parsers.DocumentBuilder builder =
factory.newDocumentBuilder();
org.w3c.dom.Document root = builder.parse(templatePath);
// Jetty
// SAXParserFactory factory =
SAXParserFactory.newInstance();
// SAXParser parser = factory.newSAXParser();
// _parser.parse(url, handler);
// Document root = builder.build(templatePath);
// Velocity
// org.jdom.input.SAXBuilder builder = new
org.jdom.input.SAXBuilder
// ( "org.apache.xerces.parsers.SAXParser" );
// org.jdom.Document root = builder.build(templatePath);
context.put("op", op );
context.put("cid", cid );
context.put("lid", lid );
context.put("tid", tid );
// context.put("root", root );
context.put("task", thisTask );
Template template = Velocity.getTemplate
(thisPage.getTemplatePath(thisTask).toString());
template.merge( context, ctx.getWriter() );
}
catch( ResourceNotFoundException e )
{ throw new Fault("couldn't find page "+index, e); }
catch( ParseErrorException e )
{ throw new Fault("syntax error in page "+index, e); }
catch( MethodInvocationException e )
{ throw new Fault("exception in page "+index, e); }
catch( Exception e )
{ throw new Fault("unexpected exception in page "+index, e); }
}
For the latest information about Jetty, please see
http://jetty.mortbay.org
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
________________________________________________________________________
________________________________________________________________________
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
Brad Cox, Ph.D.; bcox@virtualschool.edu 703 361 4751
For industrial age goods there were checks and credit cards.
For everything else there is http://virtualschool.edu/mybank
Java Web Application Architecture: http://virtualschool.edu/jwaa
-- Greg Wilkins<gr...@mortbay.com> GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>