xenei-users Mailing List for Xenei.org - Xenei Utilities & Solutions
Brought to you by:
claudenw
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Claude W. <cl...@hi...> - 2002-06-26 19:24:43
|
Laust, Sorry that it has taken me so long to get back to you with this. There are a couple of issues here.... First in test2 you are making a function call. Unless the function is a static method it needs to have an instance of the object as the first parameter. (See the Xalan extension documentation). You might try <xsl:template match="test:test2"> <xsl:variable name="page"><xtest:test /></xsl:variable> <xsl:value-of select="$page"/> </xsl:template> It does not seem possible to create an object with and extension element and pass that to a method call. Things get munged around differently in the the extension element and extension function returns. I have spent a little time trying to figure out how to mix the two without any luck. As a second solution would be to use the extension function. The following example assumes that dk.defoged.imago.extensions.Test has a 0 argument constructor, otherwise the arguments would need to be added to the new() call. <xsl:template match="test:test2"> <xsl:variable name="tst" select="xtest:new()" /> <xsl:variable name="page" select="xtest:test( $tst )"/> <xsl:value-of select="$page"/> </xsl:template> As a third solution, you can make the test() method static then your example would work. Hope this helps. Claude. p.s. I recently released the newest versions of the code. In some testing today I think that there is a memory management problem but I have not been able to isolate it yet. Laust M. Ladefoged wrote: > Hej Claude, > > It has been a while, but now I have a little time and I have started > working on a small idea I have for extending Imago. However I have a > question/problem I have not been able to resolve. > > I have a need for creating an extension function that can be used as > part of an XPath expression. The very simplest would be the assignment > of the returned value of the function to a variable, > > <xsl:variable name="test" select="extension:test( )"/> > > A simple method that should satisfy the above would be > > public String test( > org.apache.xalan.extensions.XSLProcessorContext context, > org.apache.xalan.templates.ElemExtensionCall element) > { > return "Testing"; > } > > I have a stylesheet ala > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > version="1.0" > xmlns:xtest="xalan://dk.defoged.imago.extensions.Test" > xmlns:test="dk.defoged.imago.extensions" > extension-element-prefixes="xtest" > > <xsl:template match="/document"> > <document> > <xsl:apply-templates/> > </document> > </xsl:template> > > <xsl:template match="test:test1"> > <xtest:test /> > </xsl:template> > > <xsl:template match="test:test2"> > <xsl:variable name="page" select="xtest:test( )"/> > <xsl:value-of select="$page"/> > </xsl:template> > > <!-- copy everything else --> > <xsl:template match="@*|*|text()|processing-instruction()|comment()" > > <xsl:copy> > <xsl:apply-templates > select="@*|*|text()|processing-instruction()|comment()" /> > </xsl:copy> > </xsl:template> > </xsl:stylesheet> <!-- close the style sheet --> > > In the above the template for test1 template works fine, however the > test2 template generates an error. Please note that the above stylesheet > will fail, but if excluding the test2 part it will work fine. > > Looking in the log I have found the following stacktrace explaining that > I should provide appropriate arguments to the call, but I am unclear on > how to provide the required objects. > > 2002-06-19 13:55:18,731 [HttpProcessor[8080][4]] ERROR > org.xenei.imago.pipeline.ImagoFilter - error(); SystemID: > file:/opt/lib/imago_1.0.20020501/webapps/imago/test.xsl; Line#: 34; > Column#: 68 javax.xml.transform.TransformerException: > javax.xml.transform.TransformerException: Instance method call to method > name requires an Object instance as first argument > at > org.apache.xalan.extensions.ExtensionHandlerJavaPackage.callFunction(ExtensionHandlerJavaPackage.java:395) > .... > > I hope that you can help me figure out how to accomplish this task. > > Best regards, > Laust. > > > > ---------------------------------------------------------------------------- > Bringing you mounds of caffeinated joy > >>> http://thinkgeek.com/sf <<< > > _______________________________________________ > Xenei-users mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenei-users |
From: Laust M. L. <la...@de...> - 2002-06-19 12:45:39
|
Hej Claude, It has been a while, but now I have a little time and I have started working on a small idea I have for extending Imago. However I have a question/problem I have not been able to resolve. I have a need for creating an extension function that can be used as part of an XPath expression. The very simplest would be the assignment of the returned value of the function to a variable, <xsl:variable name="test" select="extension:test( )"/> A simple method that should satisfy the above would be public String test( org.apache.xalan.extensions.XSLProcessorContext context, org.apache.xalan.templates.ElemExtensionCall element) { return "Testing"; } I have a stylesheet ala <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:xtest="xalan://dk.defoged.imago.extensions.Test" xmlns:test="dk.defoged.imago.extensions" extension-element-prefixes="xtest" > <xsl:template match="/document"> <document> <xsl:apply-templates/> </document> </xsl:template> <xsl:template match="test:test1"> <xtest:test /> </xsl:template> <xsl:template match="test:test2"> <xsl:variable name="page" select="xtest:test( )"/> <xsl:value-of select="$page"/> </xsl:template> <!-- copy everything else --> <xsl:template match="@*|*|text()|processing-instruction()|comment()" > <xsl:copy> <xsl:apply-templates select="@*|*|text()|processing-instruction()|comment()" /> </xsl:copy> </xsl:template> </xsl:stylesheet> <!-- close the style sheet --> In the above the template for test1 template works fine, however the test2 template generates an error. Please note that the above stylesheet will fail, but if excluding the test2 part it will work fine. Looking in the log I have found the following stacktrace explaining that I should provide appropriate arguments to the call, but I am unclear on how to provide the required objects. 2002-06-19 13:55:18,731 [HttpProcessor[8080][4]] ERROR org.xenei.imago.pipeline.ImagoFilter - error(); SystemID: file:/opt/lib/imago_1.0.20020501/webapps/imago/test.xsl; Line#: 34; Column#: 68 javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: Instance method call to method name requires an Object instance as first argument at org.apache.xalan.extensions.ExtensionHandlerJavaPackage.callFunction(ExtensionHandlerJavaPackage.java:395) .... I hope that you can help me figure out how to accomplish this task. Best regards, Laust. |
From: Claude W. <cl...@hi...> - 2002-05-02 04:31:34
|
New Xenei releases out tonight. Xenei Imago -- Bug fix and added XInclude extension. Xenei Util -- Bug fix in DBCache. Xenei Thales -- First release of index engine. |
From: Laust M. L. <lad...@e-...> - 2002-04-27 16:58:53
|
On Fri, 2002-04-26 at 06:36, Claude Warren wrote: > > org.xenei.imago.processmap.ProcessMap > > ------------------------------------- > > Line 169 - 175: Added a check if uriPattern is null. Maybe this is only > > the symptom of an error somewhere else, but I have not been able to > > verify this - and this made it work. > > Can you double check this? My reading of the code does not allow for a > null uriPattern during the construction of the ReqRec class in the > buildReqMap() method. In any case changing the string "null" will > probably cause unexpected results in some cases. I guess we need to > find out how the null was generated and stop that. I looked into this and I found what is causing it to happen, it is not straight forward - also I have not found a way to fix the problem (except the null check in ReqRec.toString()). Here goes: In short the error happens because the super classes of ReqRec in their constructor, at one point calls the toString() method of ReqRec before the local variables are set. So the very first time the toString() method is called the values of all the local variables are null. The path to the error is: ReqRec.init() WatchableURL.init() TimedWatchable.init() AbstractWatchable.init() (org.xenei.imago.cache) AbstractWatchable.init() (org.xenei.util.cache) TimedWatchableContainer.addWatchable() ... TimedWatchableContainer$Entry.init() AbstractWatchable.init() (org.xenei.util.cache) ... TimedWatchableContainer$Entry.updateTimeStamp() // At this point the toString() method of the // "resource" is called if debugging is enabled. // This "resource" is the ReqRec instance that // actually is not fully initialised yet. ... this.uriPattern = uriPattern; this.mappedUri = mappedUri; this.transformer = transformer; I do not know if the above illustrated the problem clearly, but at least it shows that the toString() method of the ReqRec class is actually called before a instance if fully initialized. With the extra "null" check in toString() the first entry in the log is: 2002-04-27 17:18:56,325 [HttpProcessor[8080][4]] DEBUG org.xenei.imago.cache.TimedWatchableContainer - Entry: updateTimestamp(): org.xenei.imago.processmap.ProcessMap$ReqRec[[null]]null][null][null]] - 1019124654000 This indicates the not fully initialized ReqRec instance, the next time the same entry is used it looks like this: 2002-04-27 17:18:56,707 [HttpProcessor[8080][4]] DEBUG org.xenei.imago.cache.TimedWatchableContainer - Entry: updateTimestamp(): org.xenei.imago.processmap.ProcessMap$ReqRec[[index.xml]]null][imago_index][null]] - 1019124654000 I am not really sure how this problem should be fixed, the null check fix is not really feasible since it adds records to the log that can not be traced. It is sort of a circullar reference that is broken. Also maybe it is not really a problem, since it only occurs debug is enabled and could be fixed by removing (or changing) the entry that is logged. - Laust. |
From: Claude W. <cl...@hi...> - 2002-04-26 04:56:38
|
Laust M. Ladefoged wrote: > Hej Claude, > > I realised that the feature was important as soon as I got the > application to "work" - actually getting output in the browser. > > You are correct that JVM1.4 has its only XML parser, based on the > Crimson which does not include the java-encoding feature. I considered > for a while how to approach making the Xerces parser available to Imago. > Using the "Optional Packages" solution did not go very well and is also > not my prefered method of using external libraries with Java, since it > can affect other applications as well. And it actually did with my > current setup; I use Netbeans as my IDE and Netbeans started to crash in > mysterious ways when I had Xerces in /lib/ext. Also I am a bit unclear > on how this solution will make sure that the Xerces parser is called, > from time to time the Crimson parser was loaded. > > So I choose a different path, I have added an new property in the > properties file, called sax.parser.class which should point to the > correct parser (org.apache.xerces.parsers.SAXParser). ImagoFilter init() > has been changed to call the createXMLReader with the value of the > property, forcing Imago to use the desired parser. This sounds like a good solution. I was considering implementing something similar but had not had a chance to look at it yet. > > Now Imago seem to be working fine on my system. I still have a small > problem, the cookies section of the extension.xml page does not seem to > work. This is not important for me at this moment, but maybe I will get > time ot look into it for now. > I think there are bugs in the cookies implementation, I'm working on this. > I have included the files I have made changes to and a short list > describing the changes and why I made them. Many thanks. > > Now I am looking forward to begin using Xenei. What kind of > implementations are you using Xenei for? I am migrating the histio.org web site (www.histio.org) from cocoon to imago, to do that I need to create several extensions. I am approx 90% of the way there. The histio.org site uses meta data from each document to create the navigation links which sounds a lot like what you describe below. The other reason to use Xenei is to be able to generate the appropriate content for the client device, though this is not implemented on the histio.org site yet. > I have two initial ideas I will try to implement using Xenei, a dynamic > description of the infrastructure of a site, specifically for internal > links, dynamic menu generation and navigation. Also I expect it will be > possible to use Xenei as central repository (middleware) for the > different XML sources I have in my development environment, having the > transformation in one place must be a big advantage. > Are anyone working on an SOAP/web service extension? Not that I know of. The only other use that I have heard of is a front end for a knowledge base project. That project may provide a SOAP/web service implementation but I don't believe that has been resolved yet. Thanks for the good work, Claude |
From: Claude W. <cl...@hi...> - 2002-04-26 04:39:00
|
Laust M. Ladefoged wrote: > > org.xenei.imago.pipeline.EventSerializer > ---------------------------------------- > Line 1005-1006: Compile error - Added an extra catch of SAXException. I think we should probably log the error here. I'll see about adding that to the code. > org.xenei.imago.processmap.ProcessMap > ------------------------------------- > Line 169 - 175: Added a check if uriPattern is null. Maybe this is only > the symptom of an error somewhere else, but I have not been able to > verify this - and this made it work. Can you double check this? My reading of the code does not allow for a null uriPattern during the construction of the ReqRec class in the buildReqMap() method. In any case changing the string "null" will probably cause unexpected results in some cases. I guess we need to find out how the null was generated and stop that. > > _Xenei_util_ > org.xenei.util.cache.cbcache.DBCache > ------------------------------------ > Line 638-643: Compile error - Added try/catch of InterruptedException > Line 661: Compile error - Added catch af SQLException that reports an > error in the log. I think that the InterruptedException should probably be caught at the same level as the SQLException and let the process finish. I am begining to believe that the JVM you use requires that you catch all the exceptions explicitly rather than assuming that the finally will handle them. I can see that this would be an improvement over 1.3 where the finally catches everything making it difficult to detect when some lower level method is throwing an exception that should be dealt with. In anycase I'll make the change of moving the InterruptedException. Claude |
From: Laust M. L. <la...@de...> - 2002-04-18 22:12:28
|
I have tried the suggestions from Claude with some success. Moving the return statement from the final block to the try block resulted in a much more informative exception description. The exception was thrown when the ImagoFilter was setting the parser features from the imago properties file. The feature http://apache.org/xml/features/allow-java-encodings is apparently not supported by the standard xml parser in J2SDK 1.4.0. I fixed this by introducing the following try/catch section in org.xenei.imago.pipeline.ImagoFilter.setFeature() try { parent.setFeature(name, value); } catch( org.xml.sax.SAXNotSupportedException ex) { log.error( errmsg.append("setFeature(").append(name).append( ",").append(value).append(") not supported by parser!").toString()); errmsg.setLength(0); } catch( org.xml.sax.SAXNotRecognizedException ex) { log.error( errmsg.append("setFeature(").append(name).append( ",").append(value).append(") not recognized by parser!").toString()); errmsg.setLength(0); } which instead of throwing an exception writes the not supported feature or option as an error in the Imago log. I believe this is a better way because in removes a direct depency on a specific xml parser and if a feature is not supported informs the user in the log. I will wrap my changes this weekend and send them back to you. However I still have a problem, the stack trace is at the end of this mail. I am looking into this and will keep you posted with my findings, but any suggestions are appreciated. This happens when I try to reach the index.xml and I am pretty close now to actual getting a page, since if I change the ProcessMap$ReqRec.toString to just return an empty string I get the index.xml and can use the extension page also. Question of the day, why are you using the finally block of a try/catch to return the method value? I do not really see any advantages by doing so, actually it introduces problems as with my previous problem. Thank you, Laust. ava.lang.NullPointerException at org.xenei.imago.processmap.ProcessMap$ReqRec.toString(ProcessMap.java:169) at org.xenei.imago.cache.TimedWatchableContainer$Entry.updateTimestamp(TimedWatchableContainer.java:144) at org.xenei.imago.cache.TimedWatchableContainer$Entry.<init>(TimedWatchableContainer.java:108) at org.xenei.imago.cache.TimedWatchableContainer.addWatchable(TimedWatchableContainer.java:224) at org.xenei.imago.cache.TimedWatchable.<init>(TimedWatchable.java:36) at org.xenei.imago.cache.WatchableURL.<init>(WatchableURL.java:49) at org.xenei.imago.processmap.ProcessMap$ReqRec.<init>(ProcessMap.java:110) at org.xenei.imago.processmap.ProcessMap.buildReqMap(ProcessMap.java:728) at org.xenei.imago.processmap.ProcessMap.<init>(ProcessMap.java:247) at org.xenei.imago.ImagoInstanceDataImpl.getProcessMap(ImagoInstanceDataImpl.java:209) at org.xenei.imago.ImagoDataImpl.getProcessMap(ImagoDataImpl.java:237) at org.xenei.imago.ImagoInvocationDataImpl.getContentType(ImagoInvocationDataImpl.java:182) at org.xenei.imago.ImagoInvocationDataImpl.getRequestArguments(ImagoInvocationDataImpl.java:284) at org.xenei.imago.ImagoInvocationDataImpl.getRequestURL(ImagoInvocationDataImpl.java:353) at org.xenei.imago.ImagoDataImpl.getRequestURL(ImagoDataImpl.java:172) at org.xenei.imago.Imago.service(Imago.java:420) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) |
From: Claude W. <cl...@hi...> - 2002-04-17 13:48:42
|
Laust, The easiest way to submit the changes back is to send the entire source file(s) that you have changed. That way I can diff them with the current development versions and merge the changes in. THe ClientMap and ProcessMap are missing the <?xml... because I forgot to add it. ;-P Good catch. I suspect that the client map is not in the location specified in the properties file, though a parsing error is also possible. Thanks again for the input Claude la...@de... wrote: > > Hej Claude, > > I will look into this on Thursday and let you know of my > findings. > > The few changes I made I will offcourse route back to you. > One question in this regard, how is this best done. > > Another question, is there a reason for the ClientMap.xml > and ProcessMap.xml do not have the "required" <?xml ... > header? Could this be what is the real course of the error? > Maybe the j2sdk1.4 parser will not pass the xml dokument > correctly because the xml header is missing. > This only occured to me now and since I too, am away from > my development machine I cannot check this until Thursday. > > I will move further correspondance to the disussion groups > when I get back. > > Thank you for your swift reply, best regards, > Laust. > > --------------Besvaret besked-------------- > Dato: Tue, 16 Apr 2002 08:51:46 -0700 > Fra: Claude Warren <cl...@hi...> > Til: "Laust M. Ladefoged" <la...@de...> > Emne: Re: Getting Xenei to run? > > Laust, > > First, please send your changes back so that they may be > merged back > into the official source code. We appreciate all the help we can > get. > > Second, please use the xenei users or xenei developers > discussion groups > so that others might benefit from any discoveries found here. > > I think that the problem may be in > org.xenei.imago.ImagoInvocationDataImpl.java > > I expect that there is an exception thrown in the try statement of > getRawDocument but that the finally is still returning null. In this > case the null pointer would be thrown at the location listed below. > I > expect that the finally should be removed and the return placed > inside > the try block. If you would care to try this solution and let me > know > how it works I would appreciate it. I am traveling for the next > week > and do not have easy access to a development machine. > > org.xenei.imago.cache.WatchableDOM > getRawDocument(ImagoData data, > java.lang.String systemID) throws XeneiException > { > org.xenei.imago.cache.WatchableDOM result = null; > try > { > org.w3c.dom.Document doc = data.newDocument(); > org.xenei.imago.pipeline.ImagoFilter reader = > new org.xenei.imago.pipeline.ImagoFilter(data); > org.apache.xml.utils.DOMBuilder dombuilder = > new org.apache.xml.utils.DOMBuilder(doc); > reader.setContentHandler(dombuilder); > reader.parse(systemID); > result = new org.xenei.imago.cache.WatchableDOM(data, > doc, > systemID, reader.getKey()); > result.addWatchable(reader.getWatchable()); > } > catch (Exception e) > { > throw new XeneiException(e); > } > finally { return result; > } } > > Many thanks, > Claude Warren > > "Laust M. Ladefoged" wrote: > > > > Hej Claude, > > > > I think the basic design of Xenei looks very interresting but > I have a > > slight problem running it. > > > > I have followed the instructions in the docs/index.html file in the > > Imago package. > > My environment is Mandrake Linux 8.2, J2SDK 1.4.0 and > Jakarta-Tomcat > > 4.0.3 - however I have tried with various combinations of > J2SDK 1.3 and > > Tomcat 3.3 also with the same result. > > > > The problem is that when I try to access the > > http://192.168.1.230:8080/imago/index.xml, I get the following > null > > pointer exception. Error page below (btw, very nice error > handling with > > environment and all.) I have included the imago.log as well. > > > > Looking in the source I had to correct a number of exceptions > that was > > not caught, maybe this has to do with me using j2sdk1.4? But I > got the > > source to compile but the problem still exists. > > > > I will be looking closer for the errors the following days, but I > wanted > > to check with you if this is a known situation? > > > > Thank you in advance, > > Laust M. Ladefoged > > Copenhagen, Denmark. > > > > ---------------------------------- > > Internal Server Error > > Stack Trace > > > > java.lang.NullPointerException > > at > > > org.xenei.util.cache.CompoundWatchableImpl.addWatchable(Co > mpoundWatchableImpl.java:106) > > at > org.xenei.imago.framework.ClientMap.<init>(ClientMap.java:75) > > at > > > org.xenei.imago.ImagoInvocationDataImpl.getClientMap(ImagoIn > vocationDataImpl.java:131) > > at > > > org.xenei.imago.ImagoInvocationDataImpl.getClientType(ImagoI > nvocationDataImpl.java:165) > > at > > > org.xenei.imago.ImagoInvocationDataImpl.getRequestURL(I > magoInvocationDataImpl.java:339) > > at > org.xenei.imago.ImagoDataImpl.getRequestURL(ImagoDataI > mpl.java:172) > > at org.xenei.imago.Imago.service(Imago.java:420) > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt > er(ApplicationFilterChain.java:247) > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli > cationFilterChain.java:193) > > at > > > org.apache.catalina.core.StandardWrapperValve.invoke(Stan > dardWrapperValve.java:243) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Standard > Pipeline.java:566) > > at > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeli > ne.java:472) > > at > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j > ava:943) > > at > > > org.apache.catalina.core.StandardContextValve.invoke(Standard > ContextValve.java:190) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Standard > Pipeline.java:566) > > at > > > org.apache.catalina.valves.CertificatesValve.invoke(CertificatesV > alve.java:246) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Standard > Pipeline.java:564) > > at > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeli > ne.java:472) > > at > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j > ava:943) > > at > > > org.apache.catalina.core.StandardContext.invoke(StandardConte > xt.java:2347) > > at > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHo > stValve.java:180) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Standard > Pipeline.java:566) > > at > > > org.apache.catalina.valves.ErrorDispatcherValve.invoke(Erro > rDispatcherValve.java:170) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Stand > ardPipeline.java:564) > > at > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRe > portValve.java:170) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Stand > ardPipeline.java:564) > > at > > > org.apache.catalina.valves.AccessLogValve.invoke(AccessL > ogValve.java:468) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Standard > Pipeline.java:564) > > at > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeli > ne.java:472) > > at > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j > ava:943) > > at > > > org.apache.catalina.core.StandardEngineValve.invoke(Standard > EngineValve.java:174) > > at > > > org.apache.catalina.core.StandardPipeline.invokeNext(Standard > Pipeline.java:566) > > at > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeli > ne.java:472) > > at > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j > ava:943) > > at > > > org.apache.catalina.connector.http.HttpProcessor.process(HttpPr > ocessor.java:1017) > > at > > > org.apache.catalina.connector.http.HttpProcessor.run(HttpProces > sor.java:1115) > > at java.lang.Thread.run(Thread.java:536) > > > > ----- > > Servlet Request Data > > AUTH Type: null > > Remote User: null > > Method: GET > > Path Info: null > > Path Xlated: null > > Query String: null > > Req URI: /imago/index.xml > > Servlet Path: /index.xml > > > > Environment > > > > #---- BEGIN writeEnvironmentReport($Revision: 1.7 $): > Useful properties > > found: ---- > > java.version=1.4.0 > > version.JAXP=1.1 > > java.ext.dirs=/usr/java/j2sdk1.4.0/jre/lib/ext > > version.crimson=not-present > > version.SAX=2.0 > > > java.class.path=/usr/java/j2sdk1.4.0/lib/tools.jar:/opt/tomcat/bi > n/bootstrap.jar > > version.xerces=not-present > > > sun.boot.class.path=/opt/tomcat/bin/bootstrap.jar:/opt/tomcat/ > common/lib/servlet.jar:/opt/tomcat/common/lib/naming- > resources.jar:/opt/tomcat/common/lib/naming- > common.jar:/opt/tomcat/common/lib/log4j- > core.jar:/opt/tomcat/common/lib/log4j.jar:/opt/tomcat/common > /lib/xenei_servrun_1.0.20020315.jar:/opt/tomcat/common/lib/j > dbc7.0- > 1.2.jar:/usr/java/j2sdk1.4.0/jre/lib/rt.jar:/usr/java/j2sdk1.4.0/jre/ > lib/i18n.jar:/usr/java/j2sdk1.4.0/jre/lib/sunrsasign.jar:/usr/java/j > 2sdk1.4.0/jre/lib/jsse.jar:/usr/java/j2sdk1.4.0/jre/lib/jce.jar:/usr/ > java/j2sdk1.4.0/jre/lib/charsets.jar:/usr/java/j2sdk1.4.0/jre/clas > ses > > version.DOM.draftlevel=2.0fd > > version.xalan2=Xalan;Java;Xalan Java 2.2.D11; > > version.DOM=2.0 > > version.xalan1=not-present > > #----- END writeEnvironmentReport: Useful properties found: --- > -- > > # YAHOO! Your environment seems to be OK. > > > > This page generated dynamically by Imago Version 1.0 - alpha > (nymph) > > > > ----------------------------- > > > > ------------------------------------------------------------------------ > > Name: imago.log > > imago.log Type: Text Document (application/x-unknown- > content-type-txtfile) > > Encoding: quoted-printable |
From: Claude W. <cl...@hi...> - 2002-04-16 15:52:25
|
Laust, First, please send your changes back so that they may be merged back into the official source code. We appreciate all the help we can get. Second, please use the xenei users or xenei developers discussion groups so that others might benefit from any discoveries found here. I think that the problem may be in org.xenei.imago.ImagoInvocationDataImpl.java I expect that there is an exception thrown in the try statement of getRawDocument but that the finally is still returning null. In this case the null pointer would be thrown at the location listed below. I expect that the finally should be removed and the return placed inside the try block. If you would care to try this solution and let me know how it works I would appreciate it. I am traveling for the next week and do not have easy access to a development machine. org.xenei.imago.cache.WatchableDOM getRawDocument(ImagoData data, java.lang.String systemID) throws XeneiException { org.xenei.imago.cache.WatchableDOM result = null; try { org.w3c.dom.Document doc = data.newDocument(); org.xenei.imago.pipeline.ImagoFilter reader = new org.xenei.imago.pipeline.ImagoFilter(data); org.apache.xml.utils.DOMBuilder dombuilder = new org.apache.xml.utils.DOMBuilder(doc); reader.setContentHandler(dombuilder); reader.parse(systemID); result = new org.xenei.imago.cache.WatchableDOM(data, doc, systemID, reader.getKey()); result.addWatchable(reader.getWatchable()); } catch (Exception e) { throw new XeneiException(e); } finally { return result; } } Many thanks, Claude Warren "Laust M. Ladefoged" wrote: > > Hej Claude, > > I think the basic design of Xenei looks very interresting but I have a > slight problem running it. > > I have followed the instructions in the docs/index.html file in the > Imago package. > My environment is Mandrake Linux 8.2, J2SDK 1.4.0 and Jakarta-Tomcat > 4.0.3 - however I have tried with various combinations of J2SDK 1.3 and > Tomcat 3.3 also with the same result. > > The problem is that when I try to access the > http://192.168.1.230:8080/imago/index.xml, I get the following null > pointer exception. Error page below (btw, very nice error handling with > environment and all.) I have included the imago.log as well. > > Looking in the source I had to correct a number of exceptions that was > not caught, maybe this has to do with me using j2sdk1.4? But I got the > source to compile but the problem still exists. > > I will be looking closer for the errors the following days, but I wanted > to check with you if this is a known situation? > > Thank you in advance, > Laust M. Ladefoged > Copenhagen, Denmark. > > ---------------------------------- > Internal Server Error > Stack Trace > > java.lang.NullPointerException > at > org.xenei.util.cache.CompoundWatchableImpl.addWatchable(CompoundWatchableImpl.java:106) > at org.xenei.imago.framework.ClientMap.<init>(ClientMap.java:75) > at > org.xenei.imago.ImagoInvocationDataImpl.getClientMap(ImagoInvocationDataImpl.java:131) > at > org.xenei.imago.ImagoInvocationDataImpl.getClientType(ImagoInvocationDataImpl.java:165) > at > org.xenei.imago.ImagoInvocationDataImpl.getRequestURL(ImagoInvocationDataImpl.java:339) > at org.xenei.imago.ImagoDataImpl.getRequestURL(ImagoDataImpl.java:172) > at org.xenei.imago.Imago.service(Imago.java:420) > 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:1017) > at > org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1115) > at java.lang.Thread.run(Thread.java:536) > > ----- > Servlet Request Data > AUTH Type: null > Remote User: null > Method: GET > Path Info: null > Path Xlated: null > Query String: null > Req URI: /imago/index.xml > Servlet Path: /index.xml > > Environment > > #---- BEGIN writeEnvironmentReport($Revision: 1.7 $): Useful properties > found: ---- > java.version=1.4.0 > version.JAXP=1.1 > java.ext.dirs=/usr/java/j2sdk1.4.0/jre/lib/ext > version.crimson=not-present > version.SAX=2.0 > java.class.path=/usr/java/j2sdk1.4.0/lib/tools.jar:/opt/tomcat/bin/bootstrap.jar > version.xerces=not-present > sun.boot.class.path=/opt/tomcat/bin/bootstrap.jar:/opt/tomcat/common/lib/servlet.jar:/opt/tomcat/common/lib/naming-resources.jar:/opt/tomcat/common/lib/naming-common.jar:/opt/tomcat/common/lib/log4j-core.jar:/opt/tomcat/common/lib/log4j.jar:/opt/tomcat/common/lib/xenei_servrun_1.0.20020315.jar:/opt/tomcat/common/lib/jdbc7.0-1.2.jar:/usr/java/j2sdk1.4.0/jre/lib/rt.jar:/usr/java/j2sdk1.4.0/jre/lib/i18n.jar:/usr/java/j2sdk1.4.0/jre/lib/sunrsasign.jar:/usr/java/j2sdk1.4.0/jre/lib/jsse.jar:/usr/java/j2sdk1.4.0/jre/lib/jce.jar:/usr/java/j2sdk1.4.0/jre/lib/charsets.jar:/usr/java/j2sdk1.4.0/jre/classes > version.DOM.draftlevel=2.0fd > version.xalan2=Xalan;Java;Xalan Java 2.2.D11; > version.DOM=2.0 > version.xalan1=not-present > #----- END writeEnvironmentReport: Useful properties found: ----- > # YAHOO! Your environment seems to be OK. > > This page generated dynamically by Imago Version 1.0 - alpha (nymph) > > ----------------------------- > > ------------------------------------------------------------------------ > Name: imago.log > imago.log Type: Text Document (application/x-unknown-content-type-txtfile) > Encoding: quoted-printable |
From: Claude W. <cl...@hi...> - 2002-03-18 06:15:35
|
This is a bugfix. Fixes a major bug that prohibited the cache from correctly identifying expired pages. |
From: Claude W. <cl...@hi...> - 2002-03-16 06:04:17
|
Xenei Utilities version 1.0.20020315 has been released. This fixes several bugs noted in the intitial release. A better packaging format is now being used and more documentation is included. Xenei Servlet Runner version 1.0.20020315 has been released. A better packaging format is now being used and more documentation is included. Xenei Imago version 1.0.20020315 has been released. This is the premier product of the xenei project. The is the first release of the the Imago code and is considered alpha code. However it appears to be failry stable. All packages are not available at http://sourceforge.net/projects/xenei |