You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Wittinghofer, Pan" <Wi...@i-technology.de> on 2000/10/24 13:06:41 UTC
question: calling java-extensions
Hello, I'm running the latest version of cocoon under tomcat 3.1 on SusE
6.4. Cocoon works just fine, all xsl transformatiosn work great. But
unfortunately I have not been able to call the java or
javascript-extensions. All jar Files are on the classpath. But when I
call the stylesheet I've sent as attachment, the system prints out the
following :
call to extension function failed:xml.apache.org
When trying to call a javascript extension i get the the following
error:
Call to extension function failed: unable to load language: javascript
any help/hints/comments would be great and will be appreciated !!
Thanks !!
<<MyTest.java>> <<test.xsl>> <<test.xml>>
Re: question: calling java-extensions
Posted by Gary L Peskin <ga...@firstech.com>.
"Wittinghofer, Pan" wrote:
>
> Hello, I'm running the latest version of cocoon under tomcat 3.1 on SusE
> 6.4. Cocoon works just fine, all xsl transformatiosn work great. But
> unfortunately I have not been able to call the java or
> javascript-extensions. All jar Files are on the classpath. But when I
> call the stylesheet I've sent as attachment, the system prints out the
> following :
>
> call to extension function failed:xml.apache.org
>
> When trying to call a javascript extension i get the the following
> error:
> Call to extension function failed: unable to load language: javascript
In your stylesheet, remove the extension-element-prefixes attribute.
This causes Xalan to think that you will have extension elements with
the java: prefix, which is not allowed in this release and gets Xalan
confused.
When trying to use javascript, be sure you have the js.jar file in your
classpath. This file can be obtained from
http://www.mozilla.org/rhino. Depending on your version of Xalan,
you'll need either version 1.4 R3 or version 1.5. Version 1.4R3 is
needed for all versions except 1.2, I believe. You might try
downloading both and see if either one works. If not, come back to this
list and we'll try to figure out the problem.
Gary
Re: question: calling java-extensions
Posted by Benoit Cerrina <be...@writeme.com>.
Well,
just a cursory look brought four different custom class loader in tomcat:
JspLoader
AdaptiveClassLoader
AdaptiveServletLoader
NetworkClassLoader
I'm looking in more details what happens
Benoit
----- Original Message -----
From: "Gary L Peskin" <ga...@firstech.com>
To: <xa...@xml.apache.org>
Sent: Tuesday, October 24, 2000 8:19 PM
Subject: Re: question: calling java-extensions
> Benoit Cerrina wrote:
> >
> > Hi,
> > Gary there has to be a custom class loader in Tomcat or it wouldn't be
able
> > to reload classes which have changed in a webapp as it is supposed to.
> > Also I've seen just the same behavior and couldn't nail down what didn't
> > work in one install but worked in the other and I did have the jars in
the
> > lib directory of the webapps when it didn't work.
> > Also I had something funny happen if I put all the cocoon classes in
> > tomcat/classes directory it couldn't find the jars in the
webapps/cocoon/lib
> > directory which it did when I had the classes in the
webapps/cocoon/classes
> > directory, all this is very strange, I'll try to look into it.
> > Benoit
>
> Oh. Well I was talking about a custom class loader in BSF. As I said,
> I don't know about Tomcat. That would be great if you could look into
> it. I'll help however I can.
>
> BTW, I'm making progress on your "import traversal" problem and may have
> a solution shortly. Or not.
>
> Gary
Re: question: calling java-extensions
Posted by Gary L Peskin <ga...@firstech.com>.
Benoit Cerrina wrote:
>
> Hi,
> Gary there has to be a custom class loader in Tomcat or it wouldn't be able
> to reload classes which have changed in a webapp as it is supposed to.
> Also I've seen just the same behavior and couldn't nail down what didn't
> work in one install but worked in the other and I did have the jars in the
> lib directory of the webapps when it didn't work.
> Also I had something funny happen if I put all the cocoon classes in
> tomcat/classes directory it couldn't find the jars in the webapps/cocoon/lib
> directory which it did when I had the classes in the webapps/cocoon/classes
> directory, all this is very strange, I'll try to look into it.
> Benoit
Oh. Well I was talking about a custom class loader in BSF. As I said,
I don't know about Tomcat. That would be great if you could look into
it. I'll help however I can.
BTW, I'm making progress on your "import traversal" problem and may have
a solution shortly. Or not.
Gary
Re: question: calling java-extensions
Posted by Benoit Cerrina <be...@writeme.com>.
Hi,
Gary there has to be a custom class loader in Tomcat or it wouldn't be able
to reload classes which have changed in a webapp as it is supposed to.
Also I've seen just the same behavior and couldn't nail down what didn't
work in one install but worked in the other and I did have the jars in the
lib directory of the webapps when it didn't work.
Also I had something funny happen if I put all the cocoon classes in
tomcat/classes directory it couldn't find the jars in the webapps/cocoon/lib
directory which it did when I had the classes in the webapps/cocoon/classes
directory, all this is very strange, I'll try to look into it.
Benoit
----- Original Message -----
From: "Gary L Peskin" <ga...@firstech.com>
To: <xa...@xml.apache.org>
Sent: Tuesday, October 24, 2000 5:41 PM
Subject: Re: question: calling java-extensions
> Martin Klang wrote:
> >
> > i've had similar problems running xalan1.2 with tomcat3.1 - when i put
the
> > bsf jars and all other extentions-related jars in tomcats own lib
> > directory things work fine. however, if i stick them in the lib or
> > classpath of a particular webapp (which is the 'right' way and what i'd
> > prefer) it throws stuff like class not found, can't load language etc.
> >
> > ie
> > $TOMCAT_HOME/lib/ --> works
> > $TOMCAT_HOME/webapps/myapp/WEB-INF/lib --> fails
> > $TOMCAT_HOME/webapps/myapp/WEB-INF/classes --> fails
> >
> > i mailed the list earlier about this, but never came around to doing the
> > tests i was supposed to do...
> > i'm pretty sure there's a custom class loader used somewhere that screws
> > things up, because when i try to load my own extension classes from a
> > servlet with Class.forName() it loads it okay.
> >
> > if someone could tell me where i can find the bsf sauce (what is this
bsf
> > stuff anyhow??) then i'll try to trace it through to where exactly it
> > fails.
>
> Martin --
>
> I doubt that there's a custom class loader in there. I've never seen
> one. Doesn't mean it isn't there just that I haven't come across it.
>
> You can find BSF info at
> http://oss.software.ibm.com/developerworks/opensource/bsf/
>
> I'm happy to work through this with you if you can give us some
> specifics. I'm not familiar with tomcat but can probably muddle my way
> through.
>
> Gary
Re: question: calling java-extensions
Posted by Benoit Cerrina <be...@writeme.com>.
Gary,
my understanding is that you are right about the multiple instances of the
Xalan classes, therefore I don't see that
it would be any better than copying (or creating a symlink) the jar file
everywhere. However, I think one of the requirements is also that the xalan
files not be in the original classpath, since looking at the adaptive class
loader code I see that before trying to load the class in one of its
repository, it tries to load it from the system. Just having the xalan jar
in tomcat launches class path would pause some problems if the extensions
are not in the same place.
Benoit
> Thanks for finding this out as I'm not familiar with Tomcat at all.
> Does this mean that if you want to use Xalan extensions for a particular
> webapp, you need to include a copy of Xalan in a webapps/... directory?
>
> Or is there some way to tell Tomcat that you want Xalan loaded with the
> ClassLoader for the webapp in question even though you have only one
> copy of the xalan.jar file. I guess this would result in multiple
> instances of the Xalan classes, one for each ClassLoader. Is that
> right?
>
> Gary
Re: question: calling java-extensions
Posted by Benoit Cerrina <be...@writeme.com>.
Hi,
yes however I'm not so sure what the system repository is, I thought at the
beginning it meant the class path, but now I tend to think that it means the
boot classes and those in jre/lib/ext
Benoit
> in what circumstances using the threads cl would fail - Benoit pointed out
> that the tomcat AdaptiveCl, for one, will first try the system repository
> (correct?).
>
> /m
Re: question: calling java-extensions
Posted by Martin Klang <ma...@pingdynasty.com>.
what about:
try to get the 'getContextClassLoader' method by reflection - if this
fails don't try again - stick to the classloader used to load xalan.
if any other exception is thrown simply report the error (try with the
'default' cl??).
once a classloader is determined, if invoking the extension method fails
then simply report the error (as opposed to trying another cl).
i guess that's option 2)?
tomcat presently does something like this when switching context cl (from
what i can gather from the sauce), only that if any exception is thrown
when getting hold of the context cl then that will stop tomcat trying
again.
i 'spose issues might occur for people who are depending on how extensions
are currently loaded, if we were to change it. however i can't really see
in what circumstances using the threads cl would fail - Benoit pointed out
that the tomcat AdaptiveCl, for one, will first try the system repository
(correct?).
/m
On Wed, 25 Oct 2000, Benoit Cerrina wrote:
> Don't know about Martin, but I for one would like 2 best.
> Benoit
> PS:
> unrelated question: xsl-list + xalan-dev have been having hiccups with me, I
> seem to get a lot of message in double (not all though) do any of you
> experiment it too?
i'm not on xsl-list, i get no doubles (xalan-dev already fills my mailbox
nicely! :)
> > Martin Klang wrote:
> > > On Wed, 25 Oct 2000, Gary L Peskin wrote:
> > > > What should Xalan do?
> > > > (1) Should we try the thread's context class loader and if we don't
> load
> > > > from there, try the default (ie Xalan's) class loader.
> > > > (2) Or should we only use the thread's class loader and if the load
> > > > fails just report that we can't find the extension.
> > > > (3) Or should we have some way to specify this via a property, or on
> the
> > > > extension URI itself so that it can vary URI by URI (ie class by
> class)?
> > > > (4) Or should we leave it the way it is? That is, the extensions are
> > > > loaded by the same classloader that loaded Xalan.
>
> >
>
Re: question: calling java-extensions
Posted by Benoit Cerrina <be...@writeme.com>.
Don't know about Martin, but I for one would like 2 best.
Benoit
PS:
unrelated question: xsl-list + xalan-dev have been having hiccups with me, I
seem to get a lot of message in double (not all though) do any of you
experiment it too?
> Martin Klang wrote:
> > On Wed, 25 Oct 2000, Gary L Peskin wrote:
> > > What should Xalan do?
> > > (1) Should we try the thread's context class loader and if we don't
load
> > > from there, try the default (ie Xalan's) class loader.
> > > (2) Or should we only use the thread's class loader and if the load
> > > fails just report that we can't find the extension.
> > > (3) Or should we have some way to specify this via a property, or on
the
> > > extension URI itself so that it can vary URI by URI (ie class by
class)?
> > > (4) Or should we leave it the way it is? That is, the extensions are
> > > loaded by the same classloader that loaded Xalan.
Re: question: calling java-extensions
Posted by Gary L Peskin <ga...@firstech.com>.
Martin Klang wrote:
> On Wed, 25 Oct 2000, Gary L Peskin wrote:
> > What should Xalan do?
> > (1) Should we try the thread's context class loader and if we don't load
> > from there, try the default (ie Xalan's) class loader.
> > (2) Or should we only use the thread's class loader and if the load
> > fails just report that we can't find the extension.
> > (3) Or should we have some way to specify this via a property, or on the
> > extension URI itself so that it can vary URI by URI (ie class by class)?
> > (4) Or should we leave it the way it is? That is, the extensions are
> > loaded by the same classloader that loaded Xalan.
>
> i believe the context classloader _should_ be used if possible, to make
> xalan truly useful in any sort of j2ee-style environment. ie with a
> servlet engine sa tomcat, ejb-server or whatever.
> question is then if it's worth the cost of a workaround/hack for backwards
> compatibility, or if we're better off waiting until you guys decide to put
> out a pure java2 version.
> any such plans?
>
Martin --
I'm not talking about backward compatibility here. I think we can do
this even with jdk 1.1.x using the reflection method which you
previously posted.
However, my question was what classloader strategy of the four I listed
(or some other one I haven't thought of) would you favor? I guess (4)
would be out since that's what Xalan already does.
Gary
Re: question: calling java-extensions
Posted by Martin Klang <ma...@pingdynasty.com>.
On Wed, 25 Oct 2000, Gary L Peskin wrote:
> See my comments below.
> Gary
>
dito
/m
>
> Yes. The Thread.getContextClassLoader() method does not exist in jdk
> 1.1.x. If getMethod cannot find an accessible method, it throws
> NoSuchMethodException or SecurityException. In that case, we'd need to
> trap it and use the default class loader. Then, we could run under any
> jdk.
also, this only needs to be done once, eg in the init/ctor. that way no
overhead is incurred by looking for a classloader every time if we're
running on pre-jdk1.2.
>
> What should Xalan do?
> (1) Should we try the thread's context class loader and if we don't load
> from there, try the default (ie Xalan's) class loader.
> (2) Or should we only use the thread's class loader and if the load
> fails just report that we can't find the extension.
> (3) Or should we have some way to specify this via a property, or on the
> extension URI itself so that it can vary URI by URI (ie class by class)?
> (4) Or should we leave it the way it is? That is, the extensions are
> loaded by the same classloader that loaded Xalan.
i believe the context classloader _should_ be used if possible, to make
xalan truly useful in any sort of j2ee-style environment. ie with a
servlet engine sa tomcat, ejb-server or whatever.
question is then if it's worth the cost of a workaround/hack for backwards
compatibility, or if we're better off waiting until you guys decide to put
out a pure java2 version.
any such plans?
>
> > ps i don't think there's a way to tell tomcat what classloader to use for
> > what libs, though i could be wrong.
>
> Yes, that would be the best way.
yeah? i can't really see how that would work, seeing there's a classloader
per webapp, plus the default one.
Re: question: calling java-extensions
Posted by Gary L Peskin <ga...@firstech.com>.
See my comments below.
Gary
Martin Klang wrote:
>
> hey,
>
> i've found that changing the Class.forName() call to use the context
> classloader solves this problem.
>
> eg change XSLTJavaClassEngine to do something like:
> ClassLoader cl = Thread.currentThread().getContextClassLoader();
> object = Class.forName (className, true, cl);
>
> now, in tomcat they have a slightly more convoluted way of getting hold
> of the context cl:
>
> Thread t=Thread.currentThread();
> java.lang.reflect.Method getCCL = t.getClass()
> .getMethod("getContextClassLoader", noParams);
> ClassLoader old=(ClassLoader)getCCL.invoke( t, noObjs );
>
> i believe this is a workaround for jdk < 1.2, i'll investigate if there's
> interest from you xalan-people.
Yes. The Thread.getContextClassLoader() method does not exist in jdk
1.1.x. If getMethod cannot find an accessible method, it throws
NoSuchMethodException or SecurityException. In that case, we'd need to
trap it and use the default class loader. Then, we could run under any
jdk.
> at the moment i've got my patched xalan working the way i want it - if you
> want i could spend a bit more time on testing this with different setups
> (i'll soon be running tomcat in the same vm as our ejb-server which uses
> its own set of classloaders - that will be interesting!) and then submit
> the patches.
> however i understand if you guys feel that this is not really a problem
> with xalan at all - that classes should be loaded with the same
> classloader that loaded xalan.
> though personally i think it makes more sense to use the context cl.
What should Xalan do?
(1) Should we try the thread's context class loader and if we don't load
from there, try the default (ie Xalan's) class loader.
(2) Or should we only use the thread's class loader and if the load
fails just report that we can't find the extension.
(3) Or should we have some way to specify this via a property, or on the
extension URI itself so that it can vary URI by URI (ie class by class)?
(4) Or should we leave it the way it is? That is, the extensions are
loaded by the same classloader that loaded Xalan.
> ps i don't think there's a way to tell tomcat what classloader to use for
> what libs, though i could be wrong.
Yes, that would be the best way.
Re: question: calling java-extensions
Posted by Martin Klang <ma...@pingdynasty.com>.
hey,
i've found that changing the Class.forName() call to use the context
classloader solves this problem.
eg change XSLTJavaClassEngine to do something like:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
object = Class.forName (className, true, cl);
now, in tomcat they have a slightly more convoluted way of getting hold
of the context cl:
Thread t=Thread.currentThread();
java.lang.reflect.Method getCCL = t.getClass()
.getMethod("getContextClassLoader", noParams);
ClassLoader old=(ClassLoader)getCCL.invoke( t, noObjs );
i believe this is a workaround for jdk < 1.2, i'll investigate if there's
interest from you xalan-people.
at the moment i've got my patched xalan working the way i want it - if you
want i could spend a bit more time on testing this with different setups
(i'll soon be running tomcat in the same vm as our ejb-server which uses
its own set of classloaders - that will be interesting!) and then submit
the patches.
however i understand if you guys feel that this is not really a problem
with xalan at all - that classes should be loaded with the same
classloader that loaded xalan.
though personally i think it makes more sense to use the context cl.
regards,
/m
ps i don't think there's a way to tell tomcat what classloader to use for
what libs, though i could be wrong. and yes, i guess that means tomcat
would have to load all those classes in all 'local' classloaders, ie one
copy per webapp.
i guess the 'easy' way would be to symlink the xalan jars to the tomcat
lib... not pretty!
On Wed, 25 Oct 2000, Gary L Peskin wrote:
> Martin Klang wrote:
> >
> > okay, think i've got this sussed now...
> > tomcat loads anything in its own lib directory with the default class
> > loader, so those classes will use the sun Launcher when doing a
> > Class.forName().
> > anything in webapps/myapp/WEB-INF/classes or /lib will be loaded with the
> > AdaptiveClassLoader, and so will work fine when you load another class in
> > the same webapp context.
> > so the key to this is simply not to put xalan and bsf in the tomcat lib
> > (as i did...) and _not_ to mix the classloaders/classes!!
> >
> > thanks for your help,
> > sorry to bother you about something that's basically a tomcat issue, but
> > maybe there are people out there using xalan with tomcat who will find it
> > useful...
>
> Martin --
>
> Thanks for finding this out as I'm not familiar with Tomcat at all.
> Does this mean that if you want to use Xalan extensions for a particular
> webapp, you need to include a copy of Xalan in a webapps/... directory?
>
> Or is there some way to tell Tomcat that you want Xalan loaded with the
> ClassLoader for the webapp in question even though you have only one
> copy of the xalan.jar file. I guess this would result in multiple
> instances of the Xalan classes, one for each ClassLoader. Is that
> right?
>
> Gary
>
Re: question: calling java-extensions
Posted by Gary L Peskin <ga...@firstech.com>.
Martin Klang wrote:
>
> okay, think i've got this sussed now...
> tomcat loads anything in its own lib directory with the default class
> loader, so those classes will use the sun Launcher when doing a
> Class.forName().
> anything in webapps/myapp/WEB-INF/classes or /lib will be loaded with the
> AdaptiveClassLoader, and so will work fine when you load another class in
> the same webapp context.
> so the key to this is simply not to put xalan and bsf in the tomcat lib
> (as i did...) and _not_ to mix the classloaders/classes!!
>
> thanks for your help,
> sorry to bother you about something that's basically a tomcat issue, but
> maybe there are people out there using xalan with tomcat who will find it
> useful...
Martin --
Thanks for finding this out as I'm not familiar with Tomcat at all.
Does this mean that if you want to use Xalan extensions for a particular
webapp, you need to include a copy of Xalan in a webapps/... directory?
Or is there some way to tell Tomcat that you want Xalan loaded with the
ClassLoader for the webapp in question even though you have only one
copy of the xalan.jar file. I guess this would result in multiple
instances of the Xalan classes, one for each ClassLoader. Is that
right?
Gary
Re: question: calling java-extensions
Posted by Benoit Cerrina <be...@writeme.com>.
I sure did, since I had the same problem.
Thanks Martin
> thanks for your help,
> sorry to bother you about something that's basically a tomcat issue, but
> maybe there are people out there using xalan with tomcat who will find it
> useful...
>
> regards,
>
> /m
>
Re: question: calling java-extensions
Posted by Martin Klang <ma...@pingdynasty.com>.
okay, think i've got this sussed now...
tomcat loads anything in its own lib directory with the default class
loader, so those classes will use the sun Launcher when doing a
Class.forName().
anything in webapps/myapp/WEB-INF/classes or /lib will be loaded with the
AdaptiveClassLoader, and so will work fine when you load another class in
the same webapp context.
so the key to this is simply not to put xalan and bsf in the tomcat lib
(as i did...) and _not_ to mix the classloaders/classes!!
thanks for your help,
sorry to bother you about something that's basically a tomcat issue, but
maybe there are people out there using xalan with tomcat who will find it
useful...
regards,
/m
Re: question: calling java-extensions
Posted by Martin Klang <ma...@pingdynasty.com>.
Gary, seems you're right about bsf/xalan not using custom class loaders. I
get an exception from a simple Class.forName() in XSLTJavaClassEngine:125
try
{
object = Class.forName (className);
}
catch (ClassNotFoundException e)
{
throw new BSFException(1, "unable to load class '" +
className + "'", e);
}
when i try to load the same class from a servlet (same servlet that calls
Xalan!) it works fine...
Tomcat sets the context class loader before invoking the servlet to be
org.apache.tomcat.loader.AdaptiveClassLoader, and then sets it back to
what it was at the end of the call.
when the servlet thread gets to calling xalan, the class loader is still
the tomcat one, but when it gets to XSLTJavaEngine it has changed to the
default -> sun.misc.Launcher$AppClassLoader
now what i can't get my head around is how the class loader can suddenly
change, when setContextClassLoader is not called anywhere in the
xalan code?!? or maybe there's something else i'm missing here..
here's a (long!) stack trace from where the forName() fails, to where i
call stylesheetRoot.process() - at the top of the stack the class loader
is the default (which fails since it doesn't know about the webapp
classpath) and at the bottom, in XalanProcessor::process() it's the tomcat
AdaptiveClassLoader.
java.lang.ClassNotFoundException: com.city3k.util.DateFormat
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:191)
at java.lang.ClassLoader.loadClass(ClassLoader.java:290)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:124)
at org.apache.xalan.xpath.XSLTJavaClassEngine.call(XSLTJavaClassEngine.j
at org.apache.xalan.xpath.ExtensionFunctionHandler.callFunction(Extensio
at org.apache.xalan.xpath.xml.XMLParserLiaisonDefault.extFunction(XMLPar
at org.apache.xalan.xpath.XPath.extfunction(XPath.java:1015)
at org.apache.xalan.xpath.XPath.executeExtension(XPath.java:1254)
at org.apache.xalan.xpath.XPath.execute(XPath.java:1379)
at org.apache.xalan.xpath.XPath.execute(XPath.java:1354)
at org.apache.xalan.xpath.XPath.execute(XPath.java:311)
at org.apache.xalan.xpath.XPath.execute(XPath.java:274)
at org.apache.xalan.xslt.ElemVariable.getValue(ElemVariable.java:166)
at org.apache.xalan.xslt.ElemVariable.execute(ElemVariable.java:146)
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemTemplate.execute(ElemTemplate.java:145)
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemTemplateElement.transformChild(ElemTemplate
at org.apache.xalan.xslt.ElemTemplateElement.transformSelectedChildren(E
at org.apache.xalan.xslt.ElemApplyTemplates.execute(ElemApplyTemplates.j
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemLiteralResult.execute(ElemLiteralResult.jav
at org.apache.xalan.xslt.ElemTemplateElement.executeChildren(ElemTemplat
at org.apache.xalan.xslt.ElemTemplate.execute(ElemTemplate.java:145)
at org.apache.xalan.xslt.StylesheetRoot.process(StylesheetRoot.java:443)
at org.apache.xalan.xslt.StylesheetRoot.process(StylesheetRoot.java:294)
at com.city3k.xml.XalanProcessor.process(XalanProcessor.java:77)
/m
On Tue, 24 Oct 2000, Gary L Peskin wrote:
> Martin Klang wrote:
> >
> > i've had similar problems running xalan1.2 with tomcat3.1 - when i put the
> > bsf jars and all other extentions-related jars in tomcats own lib
> > directory things work fine. however, if i stick them in the lib or
> > classpath of a particular webapp (which is the 'right' way and what i'd
> > prefer) it throws stuff like class not found, can't load language etc.
> >
> > ie
> > $TOMCAT_HOME/lib/ --> works
> > $TOMCAT_HOME/webapps/myapp/WEB-INF/lib --> fails
> > $TOMCAT_HOME/webapps/myapp/WEB-INF/classes --> fails
> >
> > i mailed the list earlier about this, but never came around to doing the
> > tests i was supposed to do...
> > i'm pretty sure there's a custom class loader used somewhere that screws
> > things up, because when i try to load my own extension classes from a
> > servlet with Class.forName() it loads it okay.
> >
> > if someone could tell me where i can find the bsf sauce (what is this bsf
> > stuff anyhow??) then i'll try to trace it through to where exactly it
> > fails.
>
> Martin --
>
> I doubt that there's a custom class loader in there. I've never seen
> one. Doesn't mean it isn't there just that I haven't come across it.
>
> You can find BSF info at
> http://oss.software.ibm.com/developerworks/opensource/bsf/
>
> I'm happy to work through this with you if you can give us some
> specifics. I'm not familiar with tomcat but can probably muddle my way
> through.
>
> Gary
>
Re: question: calling java-extensions
Posted by Gary L Peskin <ga...@firstech.com>.
Martin Klang wrote:
>
> i've had similar problems running xalan1.2 with tomcat3.1 - when i put the
> bsf jars and all other extentions-related jars in tomcats own lib
> directory things work fine. however, if i stick them in the lib or
> classpath of a particular webapp (which is the 'right' way and what i'd
> prefer) it throws stuff like class not found, can't load language etc.
>
> ie
> $TOMCAT_HOME/lib/ --> works
> $TOMCAT_HOME/webapps/myapp/WEB-INF/lib --> fails
> $TOMCAT_HOME/webapps/myapp/WEB-INF/classes --> fails
>
> i mailed the list earlier about this, but never came around to doing the
> tests i was supposed to do...
> i'm pretty sure there's a custom class loader used somewhere that screws
> things up, because when i try to load my own extension classes from a
> servlet with Class.forName() it loads it okay.
>
> if someone could tell me where i can find the bsf sauce (what is this bsf
> stuff anyhow??) then i'll try to trace it through to where exactly it
> fails.
Martin --
I doubt that there's a custom class loader in there. I've never seen
one. Doesn't mean it isn't there just that I haven't come across it.
You can find BSF info at
http://oss.software.ibm.com/developerworks/opensource/bsf/
I'm happy to work through this with you if you can give us some
specifics. I'm not familiar with tomcat but can probably muddle my way
through.
Gary
Re: question: calling java-extensions
Posted by Martin Klang <ma...@pingdynasty.com>.
i've had similar problems running xalan1.2 with tomcat3.1 - when i put the
bsf jars and all other extentions-related jars in tomcats own lib
directory things work fine. however, if i stick them in the lib or
classpath of a particular webapp (which is the 'right' way and what i'd
prefer) it throws stuff like class not found, can't load language etc.
ie
$TOMCAT_HOME/lib/ --> works
$TOMCAT_HOME/webapps/myapp/WEB-INF/lib --> fails
$TOMCAT_HOME/webapps/myapp/WEB-INF/classes --> fails
i mailed the list earlier about this, but never came around to doing the
tests i was supposed to do...
i'm pretty sure there's a custom class loader used somewhere that screws
things up, because when i try to load my own extension classes from a
servlet with Class.forName() it loads it okay.
if someone could tell me where i can find the bsf sauce (what is this bsf
stuff anyhow??) then i'll try to trace it through to where exactly it
fails.
cheers,
/m
On Tue, 24 Oct 2000, Wittinghofer, Pan wrote:
> Hello, I'm running the latest version of cocoon under tomcat 3.1 on SusE
> 6.4. Cocoon works just fine, all xsl transformatiosn work great. But
> unfortunately I have not been able to call the java or
> javascript-extensions. All jar Files are on the classpath. But when I
> call the stylesheet I've sent as attachment, the system prints out the
> following :
>
> call to extension function failed:xml.apache.org
>
> When trying to call a javascript extension i get the the following
> error:
> Call to extension function failed: unable to load language: javascript
>
> any help/hints/comments would be great and will be appreciated !!
>
> Thanks !!
>
> <<MyTest.java>> <<test.xsl>> <<test.xml>>
>