[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    Re: DVSL Question
From:       Brad Cox <bcox () virtualschool ! edu>
Date:       2002-01-29 14:59:43
[Download RAW message or body]


On Tuesday, January 29, 2002, at 09:14 AM, Geir Magnusson Jr. wrote:
> Which jars?
>
> The only one that required a change was the dvsl jar...

I copied all of yours.

>> I'm using jetty, but the problem has been reported with all
>> containers that use xml for configuration including Tomcat and
>> Resin. Search for "sealing violation" in google. The workaround
>> is to unseal all jars, crimson in particular. Its yet another
>> classloader conflict but nobody knew the right solution then.
>> Craig said he'd look.
>
> Huh?  I thought craig solved this a while ago...

I'm using Jetty, not Tomcat.

>> Here's WEB-INF/lib jcms.jar, jwaa.jar, jwaaDemo.jar, and
>> mybank.jar are my stuff. Everything else has been manually
>> unsealed. Sorry, the velocity.log with the stack traces have
>> been overwritten by now. From memory, the sealing violation
>> happens when dvsl tries to access my DOM, not when I'm building
>> it.
>
> Right - I thought that is because you have something that 
> Tomcat also has in
> your webapp.  Right?  That's why I thought this happened - 
> because you are
> going outside of your webapp classloader for something...

Exactly except that its dvsl that's going out of the classloader 
while calling dom4j which jetty doesn't use. The velocity.jar 
has been overwritten by now but this was quite clear in the 
stacktrace.

> The problem should be different for servlet spec 2.2 vs spec 2.3, if I
> understand the problem, as the classloader delegation is different.

Sorry, I don't understand. I think Jetty uses the latest spec 
but haven't checked.

> So you have crimson and jaxp.  Can you eliminate them and just 
> use what's in
> tomcats system classloader?

I use Jetty not Tomcat, from http://jetty.mortbay.com. Here's 
its lib directory; e.g. my app needs these to launch.

-rw-r--r--    1 bcox     wheel       74049 Dec 31 00:07 
javax.servlet.jar
-rw-r--r--    1 bcox     wheel       28327 Jan 19 11:36 
javax.xml.jaxp.jar
-rw-r--r--    1 bcox     wheel      186887 Jan 19 11:38 
org.apache.crimson.jar
-rw-r--r--    1 bcox     wheel      432163 Dec 31 00:07 
org.mortbay.jetty.jar

Not that dom4j isn't here. Based on the stack trace it was clear 
that dom4j references something that's being resolved in some 
other jar, probably crimson. Unsealing everything works for me 
so I've not dug deeper. But everything that distributes xml 
libraries will definitely need to address this, if only by 
describing my "unseal everything" workaround in the faq, or 
better, by settling on a compatible xml/xslt combination.

>>>> Also something seems to have changed re: properties handling.
>>>> Had to edit all paths to make them absolute (e.g.
>>>> /jcms/vel/vel.dvsl) to get on the air.
>>>
>>> What did you change?  The changes to dvsl last night were so
>>> minimal, it
>>> really was just 6 lines of code...
>>
>> This is apparently due to using DVSL instead of Velocity. My
>> servlet init
>> calls Velocity.init(propertiesPath) both then and now, just in
>> case because I don't undeerstand the relationship between
>> velocity and dvsl. DVSL doesn't provide such an init. Apparently
>> velocity.init doesn't "take" when I'm using DVSL, or something.
>>
>
> DVSL uses the non-singleton VelocityEngine to avoid banging 
> against anyone
> using the Singleton pattern (the original way).  The VelocityServlet is
> singleton based for Velocity engine use, so unless something is 
> horribly
> broken, the DVSL velocity use should be completely separate 
> from that of
> your servlet.
>
> Now, this may not be what you want - you may want to have one shared
> Velocity engine across your app (the servlet) and the DVSL 
> transformer...
>
> It would be easy to do in theory and in practice.  However, 
> there may be
> other approaches we might want to explore, such as more control over
> configuration in DVSL...

I'm too new at both dvsl and velocity to claim what I want. Was 
just reporting the ambiguity.


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]