X-Application Version: 4.1.1, 3.1.3
Tamino Version : 4.1.1, 3.1
Platform : Win2k, WinXP, Solaris, Linux, …
WebContainer : Tamocat 4.1.1, Tomcat 3.3.1
JDK Version : 1.4.1, 1.3.1
Hello,
I get an error when I load a jsp page.
This page uses plugin to update xml documents.
Here is the stacktrace that is generated by the error:
Stack: XJspException:
id = 270 arg[0] = current
at com.softwareag.xtools.xapplication.plugin.StandardWorkspacePlugin.lookup(StandardWorkspacePlugin.java:379)
at com.softwareag.xtools.xapplication.plugin.StandardWorkspacePlugin.commitDocumentList(StandardWorkspacePlugin.java:231)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.softwareag.xtools.xapplication.plugin.Action.invoke(Action.java:180)
at com.softwareag.xtools.xapplication.plugin.Dispatcher.execute(Dispatcher.java:158)
at com.softwareag.xtools.xapplication.jsp.SessionContext.processWorkspaceAction(SessionContext.java:389)
at com.softwareag.xtools.xapplication.jsp.taglib.ModuleTag.processDocumentAction(ModuleTag.java:503)
at com.softwareag.xtools.xapplication.jsp.taglib.ModuleTag.doStartTagCore(ModuleTag.java:117)
at com.softwareag.xtools.xapplication.jsp.JspTag.doStartTag(JspTag.java:142)
at org.apache.jsp.sublinesModify$jsp._jspService(sublinesModify$jsp.java:263)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:431)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:355)
at is.visa.invoice.event.EventHandlerBase._dispatch(EventHandlerBase.java:39)
at is.visa.invoice.event.EventHandlerBase.forward(EventHandlerBase.java:27)
at is.visa.invoice.Controller.doPost(Controller.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1027)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:536)
Does this stacktrace tell you anything?
I can give some better details about how the page works if you need it.
Best regards
Eagle
Hello,
according to the stacktrace you are using X-Application 3.1.3. The error message that is produced is wrong. It must be
Message: No such document “current”.
Help: The document with the name was not found within the workspace. Check
whether the name of the document is correct or a document with name
was created, read or selected.
This is a bug of X-Application 3.1.3 we already fixed in X-Application 4.1.1.
In your case, the value ‘current’ is used by X-Application as default for a document name because no ‘document’ attribute was found. Please, check your page whether you used a ‘document’ attribute when creating the document or reading the document and which document name you are using when committing the document. These names must be identical.
If you can’t find out the reason for your problem. Please, post the JSP where the commit action / directcomand is invoked.
Bye,
Christian.
Hello Christian,
Thank you for your reply.
Yes I am using version 3
I am planning to move to version 4.1.1.
But I managed to fix this by adding this line to the page that called the page that generated the error:
Don’t know why though?
Best regards
Eagle
Hello,
according to your description I guess there is a bug for X-Application 3.1.3 when committing schema-less documents. Without the ‘queryschema’ parameter X-Application does not assign a schema to the documents requested by the query. Could be that the “doctype” could not be evaluated properly when committing changes on the document.
In this case, this problem should not occur for X-Application 4.1.1 because meta-information as doctype and collection are requested by a query wrapper independed of the schema assignment.
Thank for this hint.
Bye,
Christian.