I am developing my company project.
I have 2 tables. And I connected to this tables with OneToMany - ManyToOne relation.
I am using postgreSql.
#OneToMany(fetch = FetchType.LAZY)
private Set<TblAgentParameters> tblAgentParameters;
#JoinColumn(name = "TBL_AGENT_PROPERTY_PARAMETERS_ID")
#ManyToOne(fetch = FetchType.LAZY)
private TblAgentPropertyParameters tblAgentPropertyParametersList;
But i get this error.
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 5
Exception Details:
Location:
com/karcin/template/persistence/entities/TblAgentPropertyParameters.class$(Ljava/lang/String;)Ljava/lang/Class; #0: aload_0
Reason:
Expected stackmap frame at this location.
Bytecode:
0x0000000: 2ab8 00ef b04c bb00 f159 2bb6 00f6 b700
0x0000010: f8bf
Exception Handler Table:
bci [0, 5] => handler: 5
at java.lang.Class.forName0(Native Method)[:1.8.0_271]
at java.lang.Class.forName(Class.java:264)[:1.8.0_271]
at com.karcin.template.persistence.entities.TblAgentParameters.class$(TblAgentParameters.java)[79:karcin-template-persistence:1.0.0.SNAPSHOT]
at com.karcin.template.persistence.entities.TblAgentParameters.<clinit>(TblAgentParameters.java)[79:karcin-template-persistence:1.0.0.SNAPSHOT]
at java.lang.Class.forName0(Native Method)[:1.8.0_271]
at java.lang.Class.forName(Class.java:264)[:1.8.0_271]
at com.karcin.template.web.controllers.ApiController.getEntityClass(ApiController.java:154)[82:karcin-template-web:1.0.0.SNAPSHOT]
at com.karcin.template.web.controllers.ApiController.test(ApiController.java:101)[82:karcin-template-web:1.0.0.SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_271]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_271]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_271]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_271]
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)[144:org.apache.servicemix.bundles.spring-web:3.2.18.RELEASE_1]
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)[144:org.apache.servicemix.bundles.spring-web:3.2.18.RELEASE_1]
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:743)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:672)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:82)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:933)[146:org.apache.servicemix.bundles.spring-webmvc:3.2.18.RELEASE_1]
... 27 more
How can i this fix.?
Something generated bytecode. That something is either [A] bugged, and messed up here, producing an invalid class file, or [B] is incredibly old1.
The fix is to, well, fix the code that messed up. If that's not your code, then file a bug with the library. If nobody maintains it anymore, ¯\_(ツ)_/¯, you're out of luck.
The invalid class file is com/karcin/template/persistence/entities/TblAgentPropertyParameters.class.
[1] Technical detail you probably don't need to understand: Well over a decade ago java class file format was changed a little bit to add some hints about stack frames within the class file itself. The verifier is the thing that checks if a class file is 'valid', and that executing the class file cannot lead to what C coders tend to call a 'core dump' - an execution path that would break the security of the system and causes your program to be instantly hardkilled by your OS, or a security issue if the OS fails to detect it. Java promises this cannot happen, and the class verifier is a part of this. The class verifier is helped out by this stack frame registration in the class file: Verifying that this stack frame info is correct, and then verifying that the bytecode only accesses memory that it is allowed to access, is much simpler and faster than verifying that the bytecode only accesses memory that it is allowed to access without this information. Older class files are allowed to not have this registration, in which case the verifier will add it for you (but this takes a lot of time, which is why it's required for more modern class files). Thus, we're really still in buggy territory: Whatever made that class file put a class-file-version in that is high enough that the stack frame notes are required, but did not add them, and thus the verifier is rejecting the class file. Alternatively, because this is 10+ years old news, maybe these days a very modern VM is no longer capable of running very old class files because the 'figure out the stack frame' code has been removed at this point. If this is the case, downgrading back to JDK8 might work, but you really need to address this; you're running code that's 10+ years out of date.
Related
Edit: I was lucky enough that James_D quickly identified and explained this phenomenon in his comments below. Having now found the alternative to the use of PropertyValueFactory (for Groovy users) I thought I'd add my own answer to help anyone unlucky enough to be flummoxed by this in future.
Specs Java: 11. OS: Linux Mint 18.3.
All this app and testing code is written in Groovy (2.5.10), but this shouldn't be particularly relevant (i.e. the same phenomenon should occur with an equivalent project written in Java).
I have a method called from App.start() where App extends javafx.application.Application (so it is running in the JAT/JavaFX Application Thread):
class GraphBuilder {
...
def attachAndShow(Stage stage, Node rootNode) {
try {
App.instance.fxmlController.treeTableView.root = rootTreeItem
App.instance.fxmlController.treeTableView.showRoot = false
stage.scene = new Scene(rootNode, 1200, 800)
stage.show()
}catch( Throwable t ){
log.error( "got throwable in attachAndShow... $t.message", t )
}
}
I am TDD'ing my way forward on the model of a "spike" (untested code where I just raced ahead) where the TreeTableView gets populated. I emphasise that there is no sign any anything being amiss with the spike.
Intrinsic to doing this is to set the TreeTableView's columns "cell value factories", which stipulate the name of a field of the class instances of which will be set as the value of the TreeItems.
The value class is called Task... and its first field is String title. I've added a first factory for this. But (because I'm proceeding by TDD) I have added the factory for the second column, property dueDate, but I haven't yet included this field in Task. Naturally the test to make sure that a factory has been set, with the right property name, is failing. But I'm more interested in what happens when I do a Gradle installDist (i.e. distribute a self-contained executable) at this point.
This runs: the window is displayed. I can see that the TreeItems have been given the right titles. In the Terminal I see a stack trace caused by my failure to include a required field (dueDate) in the Task instances:
Mar 23, 2020 6:16:25 PM javafx.scene.control.cell.TreeItemPropertyValueFactory getCellDataReflectively
WARNING: Can not retrieve property 'dueDate' in TreeItemPropertyValueFactory: javafx.scene.control.cell.TreeItemPropertyValueFactory#2d1e69d0 with provided class type: class core.Task
java.lang.IllegalStateException: Cannot get property dueDate
at com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:194)
at javafx.scene.control.cell.TreeItemPropertyValueFactory.getCellDataReflectively(TreeItemPropertyValueFactory.java:185)
at javafx.scene.control.cell.TreeItemPropertyValueFactory.call(TreeItemPropertyValueFactory.java:158)
at javafx.scene.control.cell.TreeItemPropertyValueFactory.call(TreeItemPropertyValueFactory.java:136)
at javafx.scene.control.TreeTableColumn.getCellObservableValue(TreeTableColumn.java:576)
at javafx.scene.control.TreeTableColumn.getCellObservableValue(TreeTableColumn.java:561)
at javafx.scene.control.TreeTableCell.updateItem(TreeTableCell.java:632)
at javafx.scene.control.TreeTableCell.indexChanged(TreeTableCell.java:457)
at javafx.scene.control.IndexedCell.updateIndex(IndexedCell.java:120)
at javafx.scene.control.skin.TableRowSkinBase.updateCells(TableRowSkinBase.java:539)
at javafx.scene.control.skin.TreeTableRowSkin.updateCells(TreeTableRowSkin.java:276)
at javafx.scene.control.skin.TableRowSkinBase.<init>(TableRowSkinBase.java:159)
at javafx.scene.control.skin.TreeTableRowSkin.<init>(TreeTableRowSkin.java:102)
at javafx.scene.control.TreeTableRow.createDefaultSkin(TreeTableRow.java:529)
at javafx.scene.control.Control.doProcessCSS(Control.java:897)
at javafx.scene.control.Control.access$000(Control.java:83)
at javafx.scene.control.Control$1.doProcessCSS(Control.java:89)
at com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67)
at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:145)
at javafx.scene.Node.processCSS(Node.java:9529)
at javafx.scene.Node.applyCss(Node.java:9616)
at javafx.scene.control.skin.VirtualFlow.setCellIndex(VirtualFlow.java:1715)
at javafx.scene.control.skin.VirtualFlow.getCell(VirtualFlow.java:1692)
at javafx.scene.control.skin.VirtualFlow.getCellLength(VirtualFlow.java:1801)
at javafx.scene.control.skin.VirtualFlow.computeViewportOffset(VirtualFlow.java:2639)
at javafx.scene.control.skin.VirtualFlow.layoutChildren(VirtualFlow.java:1245)
at javafx.scene.Parent.layout(Parent.java:1204)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Parent.layout(Parent.java:1211)
at javafx.scene.Scene.doLayoutPass(Scene.java:576)
at javafx.scene.Scene.preferredSize(Scene.java:1748)
at javafx.scene.Scene$2.preferredSize(Scene.java:393)
at com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
at javafx.stage.Window$12.invalidated(Window.java:1086)
at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
at javafx.stage.Window.setShowing(Window.java:1174)
at javafx.stage.Window.show(Window.java:1189)
at javafx.stage.Stage.show(Stage.java:273)
at javafx.stage.Stage$show.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119)
at core.GraphBuilder.attachAndShow(main.groovy:111)
at core.GraphBuilder$attachAndShow$4.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:135)
at core.App.start(main.groovy:56)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846)
at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:277)
at java.base/java.lang.Thread.run(Thread.java:834)
This Throwable (IllegalState is a RuntimeException) doesn't get caught in the above try ... catch. Why not? Is there any way to catch such exceptions?
This certainly appears to be the JAT: you can see App.start() in that stack trace (and also GraphBuilder.attachAndShow())
I just performed a couple of experiments: throwing first a RuntimeException and then a standard Exception in this attachAndShow() method, before any of the 4 lines in the method.
In both cases the (distributed) application failed to run, and displayed nothing... but the log message was indeed logged, i.e. these were both caught. Totally expected behaviour, so it appears that the JAT itself is not the "culprit".
I also note that the trace shown above is not a "normal" stack trace: the first two lines indicate that something is handling it and, it appears, rather unfortunately swallowing it. At the very least I'd like to be able to log such problems!
The basic answer is here.
Groovy users can smugly slice through the vast forest of pointy brackets though: my solution became:
fxmlController.treeTableView.columns.get( 0 ).cellValueFactory =
new Callback() {
#Override
Binding call(Object cellDataFeatures ) {
// NB it turns out that the first "value" is a TreeItem
Task task = cellDataFeatures.value.value
Bindings.createStringBinding({ task.title })
}
}
or stick some minimal ones in maybe:
fxmlController.treeTableView.columns.get( 0 ).cellValueFactory =
new Callback<TreeTableColumn.CellDataFeatures, ObservableValue>() {
#Override
Binding call(TreeTableColumn.CellDataFeatures cellDataFeatures ) {
Task task = cellDataFeatures.value.value
Bindings.createStringBinding({ task.title })
}
}
For the Groovy "Java lambda" substitute, no surprise that we use a closure:
fxmlController.treeTableView.columns.get( 0 ).cellValueFactory
= { cellDataFeatures -> cellDataFeatures.value.titleProperty() }
NB this involves a little understanding of JavaFX Property (see here) and a little tailoring of the class whose instances are displayed.
I'm trying to build an uberjar using lein uberjar. During compiling, the following gets thrown:
Exception in thread "main" java.lang.NullPointerException, compiling:(/tmp/form-init8223412427040046857.clj:1:73)
at clojure.lang.Compiler.load(Compiler.java:7391)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj:277)
at clojure.main$initialize.invokeStatic(main.clj:308)
at clojure.main$null_opt.invokeStatic(main.clj:342)
at clojure.main$null_opt.invoke(main.clj:339)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.NullPointerException
at clojure.string$lower_case.invokeStatic(string.clj:217)
at clojure.string$lower_case.invoke(string.clj:213)
at kappa.joke_classifier$is_jokable_QMARK_.invokeStatic(joke_classifier.clj:32)
at kappa.joke_classifier$is_jokable_QMARK_.invoke(joke_classifier.clj:29)
at kappa.core$maybe_joke.invokeStatic(core.clj:47)
at kappa.core$maybe_joke.invoke(core.clj:45)
at clojure.core$run_BANG_$fn__7276.invoke(core.clj:7393)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
at clojure.core$reduce.invokeStatic(core.clj:6544)
at clojure.core$run_BANG_.invokeStatic(core.clj:7388)
at clojure.core$run_BANG_.invoke(core.clj:7388)
at kappa.core$run.invokeStatic(core.clj:58)
at kappa.core$run.invoke(core.clj:53)
at kappa.core$_main.invokeStatic(core.clj:66)
at kappa.core$_main.doInvoke(core.clj:61)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:375)
at user$eval5.invokeStatic(form-init8223412427040046857.clj:1)
at user$eval5.invoke(form-init8223412427040046857.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6917)
at clojure.lang.Compiler.load(Compiler.java:7379)
... 14 more
The code using string/lower-case looks as follows:
(defn is-jokable? [msg]
(and
(> 30 (count msg))
(= :positive (.classify classifier (str/lower-case msg)))
(< 1 (:positive (.probabilities classifier (str/lower-case msg))))))
As can be seen from the stack trace, my -main function calls a function that eventually calls is-jokable, and str/lower-case seems to be called with nil. If I understand correctly this is because of the AOT compilation happening for uberjars, but I'm not quite sure why exactly this problem occurs... I've already tried to read up on AOT, but didn't find anything helpful. Can you explain the inner workings of AOT to me?
I'm almost embarrassed I have posted this, it must have been too late in the night... ;)
I got completely distracted by the compiling and invokeStatic hints in the stacktrace, and just now found that this was indeed an everyday bug where I expected a map to contain a key/value pair that wasn't existent, leading to nil being passed to the function in question.
Thanks for the helpful comments!
With reference to my previous question,
Executing a lisp function from Java
I was able to call lisp code from Java using ABCL.
But the problem is, the already existing lisp code uses CL-PPCRE package.
I can not compile the code as it says 'CL-PPCRE not found'.
I have tried different approaches to add that package,
including
1) how does one compile a clisp program which uses cl-ppcre?
2)https://groups.google.com/forum/#!topic/cl-ppcre/juSfOhEDa1k
Doesnot work!
Other thing is, that executing (compile-file aima.asd) works perfectly fine although it does also require cl-pprce
(defpackage #:aima-asd
(:use :cl :asdf))
(in-package :aima-asd)
(defsystem aima
:name "aima"
:version "0.1"
:components ((:file "defpackage")
(:file "main" :depends-on ("defpackage")))
:depends-on (:cl-ppcre))
The final java code is
interpreter.eval("(load \"aima/asdf.lisp\")");
interpreter.eval("(compile-file \"aima/aima.asd\")");
interpreter.eval("(compile-file \"aima/defpackage.lisp\")");
interpreter.eval("(in-package :aima)");
interpreter.eval("(load \"aima/aima.lisp\")");
interpreter.eval("(aima-load 'all)");
The error message is
Error loading C:/Users/Administrator.NUIG-1Z7HN12/workspace/aima/probability/domains/edit-nets.lisp at line 376 (offset 16389)
#<THREAD "main" {3A188AF2}>: Debugger invoked on condition of type READER-ERROR
The package "CL-PPCRE" can't be found.
[1] AIMA(1):
Can anyone help me?
You need to load cl-ppcre before you can use it. You can do that by using (asdf:load-system :aima), provided that you put both aima and cl-ppcre into locations that your ASDF searches.
I used QuickLisp to add cl-ppcre (because nothing else worked for me).
Here is what I did
(load \"~/QuickLisp.lisp\")")
(quicklisp-quickstart:install)
(load "~/quicklisp/setup.lisp")
(ql:quickload :cl-ppcre)
First 2 lines are only a one time things. Once quickLisp is installed you can start from line 3.
In both the Joy of Clojure and on Alex Miller's Pure Danger Tech blog-post it is recommended that you can print the last stack using something like the following:
(use 'clojure.stacktrace)
(java.util.Date. "foo")
(.printStackTrace *e 5)
But I can't get any of their examples to work, and instead just get
java.lang.NullPointerException: null
Reflector.java:26 clojure.lang.Reflector.invokeInstanceMethod
(Unknown Source) jtown$eval9755.invoke
What's up with this? .printStackTrace seems to be a Java function from the looks of it, so I am not sure why I am bringing clojure.stacktrace into my namespace, in the first place. I read through the clojure.stacktrace API, though, and see an e function, which seems similar too but is not the *e function, which is in core and is supposed to be binding to the last exception, but isn't. Could somebody straighten me out on the best way to check stack-traces?
There are some special vars available when using the REPL and
*e - holds the result of the last exception.
For instance:
core=> (java.util.Date. "foo")
IllegalArgumentException java.util.Date.parse (Date.java:615)
core=> (class *e)
java.lang.IllegalArgumentException
core=> (.printStackTrace *e)
java.lang.IllegalArgumentException
at java.util.Date.parse(Date.java:615)
<not included.....>
You are right, .printStackTrace is the java method that is invoked on the exception class. This is not very straightforward (since its java interop) so clojure.stacktrace namespace has some utilities about working with stack traces
So after
(use 'clojure.stacktrace)
you can use the stacktrace library instead of java interop:
core=> (print-stack-trace *e)
java.lang.IllegalArgumentException: null
at java.util.Date.parse (Date.java:615)
<not included.....>
Obviously in an app, instead of *e, you can do a try - catch and use the related functions as necessary
I use
(.printStackTrace *e *out*)
That seems to work.
I have a problem while transforming the xslt to pdf in java, i am following the same process posted in this link
"Java Transformation to PDF".
Error:
`
Caused by: java.lang.NoSuchMethodError: org.apache.xmlgraphics.java2d.GraphicContext.<init>(Lorg/apache/xmlgraphics/java2d/GraphicContext;)V
at org.apache.fop.render.intermediate.IFGraphicContext.<init>(IFGraphicContext.java:50)
at org.apache.fop.render.intermediate.IFGraphicContext.clone(IFGraphicContext.java:56)
at org.apache.fop.render.intermediate.IFRenderer.saveGraphicsState(IFRenderer.java:632)
at org.apache.fop.render.intermediate.IFRenderer.startViewport(IFRenderer.java:885)
at org.apache.fop.render.intermediate.IFRenderer.startVParea(IFRenderer.java:878)
at org.apache.fop.render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:289)
at org.apache.fop.render.intermediate.IFRenderer.renderRegionViewport(IFRenderer.java:731)
at org.apache.fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:249)
at org.apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:230)
at org.apache.fop.render.intermediate.IFRenderer.renderPage(IFRenderer.java:580)
at org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:114)
at org.apache.fop.layoutmgr.AbstractPageSequenceLayoutManager.finishPage(AbstractPageSequenceLayoutManager.java:312)
at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:167)
at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:109)
at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238)
at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
at net.sf.saxon.event.ContentHandlerProxy.endElement(ContentHandlerProxy.java:391)
at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:174)
at net.sf.saxon.event.NamespaceReducer.endElement(NamespaceReducer.java:213)
at net.sf.saxon.event.ComplexContentOutputter.endElement(ComplexContentOutputter.java:417)
at net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:301)
at net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
at net.sf.saxon.instruct.Instruction.process(Instruction.java:94)
at net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:298)
at net.sf.saxon.instruct.Template.applyLeavingTail(Template.java:175)
at net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:343)
at net.sf.saxon.Controller.transformDocument(Controller.java:1736)
at net.sf.saxon.Controller.transform(Controller.java:1560)
at mypackage.v2.business.pdf.XMLtoPDF.convertXMLPDF(XMLtoPDF.java:103)
... 51 more
java.lang.ClassCastException: java.lang.NoSuchMethodError cannot be cast to java.lang.Exception
`
Please let me know what could be the problem.
As described in the documentation
Thrown if an application tries to call a specified method of a class (either static or instance), and that class no longer has a definition of that method.
Here's how this can happen. Imagine you built some code that used a library with a method called foo(). You compiled your project and then later decided to upgrade the library. You do this by overwriting the old jar file with the new one. You don't recompile your code.
But what you didn't know is the new library removed the foo() method. Now if you run your code, it will throw this exception because your compile code calls this method and it's no longer there.
In your specific case, this isn't necessarily your code with the problem. It could be that you have one library that uses another library and the problem is there (for example, Library X uses version 2 of Library Y, but you only have Library Y version 1 in your classpath). If this is happening, you need to make sure the libraries are using the version they expect.
For your specific problem, you need to find the version of the jar that has org.apache.xmlgraphics.java2d.GraphicContext in it and it needs to have a constructor that takes a... list of org/apache/xmlgraphics/java2d/GraphicContext... maybe. I forget what (L...;)V means.