Re: Bug# 34696 - Website update
Il giorno 11/ago/05, alle 17:15, hepabolu ha scritto: Now that I've got my commit rights working I will try to focus on the documentation. However, I've already found out that updating the website is not a simple thing to do, so it might get down to me patching the content and bugging others to do the actual update, in which case it means that you need to be patient some more. Rest assured I greatly appreciate every help, big or small, with the documentation. I haven't been following all the recent threads on reworking the documentation, so I'm feeling a bit confused. In particular, I've recently added one small new feature to CForms and I want to document it before it slips off my mind. Should I update the usual website docs or am I supposed to do the update somewhere else? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT] The impact of using OSGi
On Thursday 11 August 2005 23:12, Daniel Fagerstrom wrote: At component level, you can connect a Map with any content to a service, then you can use a subset of the LDAP query language on these maps during lookup, so each component factory that is registred as an OSGi service could certainly be namespaced with a block name if we want to. And the ServiceFactory (OSGi term) will get the Bundle reference of the requestor, and could potentially discriminate accordingly. This discussion is a bit weird, since I think Vadim tries to super-impose the previous/standing definition of what real blocks encompass on top of the OSGi architecture, whereas Daniel is making a more evolutionary approach starting with what OSGi *is*, and continue from there with solutions to use-cases. IMHO, Daniel's approach is more likely to succeed, and not become another Cocoon2 excercise, where too grand goals just delayed the project to the point of exhausting the folks doing the work. Daniel (Sylvain?), I suggest that you lay out some basic thoughts on sitemap management and custom URL handling, which I think are the critical pieces at this point. In principle, OSGi bundles are effectively not very relevant to the Cocoon discussion. Merely a classloader and application packaging concern. What matters are services. And ideally, each service interface is fairly small, and allows for implementations that do not depend on heaps of other services. I think it would be good to see some examples of how that could look like. Cheers Niclas
FW: LocaleAction and cookies
Seeing as I got absolutely no response to this on the users list, I thought I'd try here before I open an enhancement request in Bugzilla ;-) To: users@cocoon.apache.org Date: Thu, 21 Jul 2005 15:36:00 +0100 Hi, I'm using Cocoon 2.1.7 to generate a bilingual site (i.e. every page may be displayed in either English or Chinese, according to the users' preference). I want the chosen language to be remembered between page requests, but there may not a session available (we had problems on a previous site when we hit the configured max sessions limit on the server, so we don't want the brochureware parts of the site to always create a session since they don't really need one). Therefore, I've got the LocaleAction configured to store-in-cookie as well as store-in-session. However, I've discovered that as I browse around the site's hierarchy it's creating multiple locale cookies, under every path I visit. This means that if I go to /site/a, then /site/area/b, switch locales (/site/area/b?locale=zh_HK), then request /site/a again, it still displays in English rather than the Chinese I was expecting (as the en_GB cookie with the higher level path still exists). By the time I've browsed all over the site, switching back and forth between the languages, it's anyone's guess which language any particular page will display :-( Is there any way to specify a particular path for the locale cookie to use, so that I can set it to / and have it affect the whole site? For that matter, I may want to change the domain it uses, or set an expiry time so that it's persistent between browser sessions. Is there any way to do this? Andrew.
Re: Bug# 34696 - Website update
Helma, However, I've already found out that updating the website is not a simple thing to do, so it might get down to me patching the content and bugging others to do the actual update, in which case it means that you need to be patient some more. I am a committer in the Lenya project and I know very well what you're talking about. Updating the website is a PITA as it involves several steps, partly to be executed on your own machine. At least that was the status last time I tried this. The situation might have improved since the zones are available. I would have to check. AFAIK there is an Apache wide project trying to come up with a very nice website editing process, but this is future and I would not necessarily wait for it. If the process is the same for Cocoon than it is for Lenya (which would be my guess) that you would probably have to check in the modfied XDoc file (from bugzilla) into SVN. That's probably easy. Then you would have to check the whole XDoc stuff out again, process it through Forrest to generate static HTML and check that back into SVN. Then there should be a script somewhere on the server that will check out the HTML off SVN and put it onto the actual webserver. This is how it works for the Lenya website: http://lenya.apache.org/community/website-update.html From the other answers I get the impression that there is a number of people on the Cocoon project who are not aware of the process for the Cocoon site. So maybe someone can find out and document it. In the Lenya project we still have the goal to establish an automatic process running every night with a cron job, so that it will be sufficient to check in the XDocs file and the change will appear on the site the next day. Need to check where we are with that. Regards, Torsten Torsten Schlabach wrote: Dear all, is there a process for updating the Cocoon website? The above mentioned bug for example is sitting there since January. I think someone (a committer) should actually either decide that website updates does not make sense / neeeds more work / whatever or apply the patch. AFAIK there is a sub-project concerned with better documentation, isn't it? But people might get discouraged if they sit down, write and submit documentation and it never makes it to the site. Or did I miss anything? Now that I've got my commit rights working I will try to focus on the documentation. However, I've already found out that updating the website is not a simple thing to do, so it might get down to me patching the content and bugging others to do the actual update, in which case it means that you need to be patient some more. Rest assured I greatly appreciate every help, big or small, with the documentation. Bye, Helma
Re: Bug# 34696 - Website update
Torsten Schlabach wrote: From the other answers I get the impression that there is a number of people on the Cocoon project who are not aware of the process for the Cocoon site. So maybe someone can find out and document it. http://wiki.apache.org/cocoon/CocoonWebsiteUpdate Needs some editing re CVS vs SVN, and cocoon-2.2 is not covered, but basics are there. Vadim
DO NOT REPLY [Bug 36162] New: - Possible Memory Leak with LinkRewriterTransformer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36162. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36162 Summary: Possible Memory Leak with LinkRewriterTransformer Product: Cocoon 2 Version: Current SVN 2.2 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: blocks AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [RT] The impact of using OSGi
Niclas Hedhman wrote: This discussion is a bit weird, since I think Vadim tries to super-impose the previous/standing definition of what real blocks encompass on top of the OSGi architecture, Of course: the goal is the same, it is just the way to get there is different. imho iiuc. whereas Daniel is making a more evolutionary approach starting with what OSGi *is*, and continue from there with solutions to use-cases. I don't see what usecase it can possibly solve if it does not provide necessary level of isolation blocks need. Vadim
Re: Bug# 34696 - Website update
All, Torsten Schlabach wrote: From the other answers I get the impression that there is a number of people on the Cocoon project who are not aware of the process for the Cocoon site. So maybe someone can find out and document it. http://wiki.apache.org/cocoon/CocoonWebsiteUpdate Needs some editing re CVS vs SVN, and cocoon-2.2 is not covered, but basics are there. Vadim Vadim has updated the Wiki page, so maybe now the backlog of website (documentation) updates can we processed. @Helma: Do you think you can move on now? Regards, Torsten
Re: [RT] The impact of using OSGi
On Friday 12 August 2005 21:07, Vadim Gritsenko wrote: whereas Daniel is making a more evolutionary approach starting with what OSGi *is*, and continue from there with solutions to use-cases. I don't see what usecase it can possibly solve if it does not provide necessary level of isolation blocks need. The OSGi specification is fairly exact on many isolation points. Bundles are classloader isolated, and if the bundles play the game according to the specification, then the full isolation needed will be provided. Some of the need to play along are; * If you call bundleContext.getService(), i.e. a lookup, you must call the bundleContext.ungetService() when you no longer need it. * If you hold on to a service for long (undefined), you should implement a ServiceListener and call ungetService(), when the service is removed. You should also unget it and get a new reference if the service is modified. The above is essentially a matter of letting go of references to instances, so that the classes can be GCed. The specification is fairly clear that for when a bundle is installed or started, only 2 possible outcomes are allowed; * Successful. * Failure, and the state of the entire platform must be identical to the state prior to attempting the operation. As for multiple versions of the same service; OSGi has covered this in the specification as well. Again, it is fairly important that bundles plays by the rules, and unfortunately one can get away with not playing too well. quote src=R3 spec The Export-Package manifest header allows a bundle to export Java packages to other bundles, exposing the packages to other bundles. The Framework must guarantee that classes and resources in the exported package's name-space are loaded from the exporting bundle. Additionally, the package's classes and resources must be shared among bundles that import the package. See Importing Packages on page 48. If more than one bundle declares the same package in its Export-Package manifest header, the Framework controls the selection of the exporting bundle. The Framework must select for export the bundle offering the highest version of the declared package. /quote Furthermore; quote src=R3 spec Exporting a package does not imply that the exporting bundle will actually use the classes it offers for export. Multiple bundles can offer to export the same package; the Framework must select only one of those bundles as the exporter. A bundle will implicitly import the same package name and version level as it exports, and therefore a separate Import-Package manifest header for this package is unnecessary. If the bundle can function using a lower specification version of the package than it exports, then the lower version can be specified in an Import-Package manifest header. /quote This means that exported (i.e. public) packages has a whole set of compatibility requirements attached to them, which IMVHO is a GoodThing. Classes/interfaces that are not part of exported packages (e.g. Eclipse places them in package names internal) are classloader separated and only a concern within the Bundle. quote src=R3 spec. === Recommended Export Strategy === Although a bundle can export all its classes to other bundles, this practice is discouraged except in the case of particularly stable library packages that will need updating only infrequently. The reason for this caution is that the Framework may not be able to promptly reclaim the space occupied by the exported classes if the bundle is updated or uninstalled. Bundle designs that separate interfaces from their implementations are strongly preferred. The bundle developer should put the interfaces into a separate Java package to be exported, while keeping the implementation classes in different packages that are not exported. If the same interface has multiple implementations in multiple bundles, the bundle developer can package the interface package into all of these bundles; the Framework must select one, and only one, of the bundles to export the package, and the interface classes must be loaded from that bundle. Interfaces with the same package and class name should have exactly the same signature. Because a modification to an interface affects all of its callers, interfaces should be carefully designed and remain backward compatible once deployed. /quote I hope this provides some confidence that isolation is the last of Cocoon's worries. :o) OSGi will, however, not provide much help for the compile blocks of today to automatically receive any isolation from each other, other than isolation of the entire bundle containing the ECM + its blocks. So, the idea of creating a bundle that wraps compile blocks and in that way creates a real block, is a good idea for migration path. But it should IMHO, not be the primary future recommended pattern. Cheers Niclas
Documentation request (was: Re: Bug# 34696 - Website update)
Vadim Gritsenko wrote: Torsten Schlabach wrote: From the other answers I get the impression that there is a number of people on the Cocoon project who are not aware of the process for the Cocoon site. So maybe someone can find out and document it. http://wiki.apache.org/cocoon/CocoonWebsiteUpdate Needs some editing re CVS vs SVN, and cocoon-2.2 is not covered, but basics are there. Thanks for updating the page Vadim. However, there is a more fundamental problem about the documentation: we know what we want in the end (fabulous documentation on the website) and what we have now (documentation of various quality scattered over several places), but what to do in the mean time? Holidays have surely erased much of my memory ;-), so I'm trying again to clarify things for myself. Do please chip in and correct me if I'm wrong. I've looked through the archives and tried to retrieve what was generally agreed on: Current state: documentation of varying quality in wiki, Daisy on Cocoon zone, website and java docs. End result: extensive, coherent, up-to-date documentation of excellent quality at the website. Note: I'm not sure whether cocoon.apache.org will be the official cocoon documentation location or the Daisy repository, but that's a discussion that can be held much later in time. In between we need to build one documentation repository and AFAIR we decided on Daisy on the cocoon zone. To me this means that ALL (yes ALL) documentation pages need to be moved there, after a reviewing process. Bruno has helped out here by moving the doc pages from SVN BRANCHE 2.X to a separate collection in Daisy. The only thing to be done now is review these pages and move them to the actual documentation set. Since then (June 17) some time has passed, so I will figure out what changes have been done to the doc pages in SVN since then and incorporate them into the Daisy version. I'll assume that updated pages are worth keeping, so I'll also move them over to the current documentation collection in Daisy. Requests: - PLEASE DO THE UPDATES OF THE DOCUMENTATION IN THE WEBSITE IN DAISY! - If you want to help, start by checking pages in the legacy docs collection in Daisy and move them to the regular collection. - Stop updating/adding doc pages in SVN. Once this is done, someone (Ross?, Reinhard?) could extract the information and update cocoon.apache.org for the time being. Bye, Helma
Re: Proposal: Make defaults for text serializers UTF-8
On Wed, 2005-08-10 at 15:55 +0200, Leszek Gawron wrote: Berin Loritsch wrote: Considering we have a very international user base, and the fact that more and more projects have to deal with international or special character, why not make the demo international friendly. In order to set encoding standards for your mime-type you have to include the character-encoding after the mime-type. Ex: text/html;encoding=utf-8 Without the encoding clue, most browsers assume whatever is the default for that browser. In the U.S. it is typically iso-8859-latin. This bit us yesterday as we had to make that change to support special characters again--this time with Cocoon. What do you propose? map:serializer name=text src=org.apache.cocoon.serialization.TextSerializer mime-type=text/plain logger=sitemap.serializer.text encodingutf-8/encoding /map:serializer This works just fine. Should we set this in main sitemap? Don't forget the text/plain;charset=utf-8. Microsoft Explorer is notoriously inconsistent in what it respects and doesn't respect.
Re: Documentation request (was: Re: Bug# 34696 - Website update)
Where is that DAISY instance and how can I access it? Who can access it? Anyone or just Cocoon committers? Note: I'm not sure whether cocoon.apache.org will be the official cocoon documentation location It will probably be for anyone interested in reading Cocoon documentation. Unless you remove *any* documentation from the site and make a bold link saying: This site does not have documentation - please go *here*! But what for is a project website if it does not contain the docu? Regards, Torsten Vadim Gritsenko wrote: Torsten Schlabach wrote: From the other answers I get the impression that there is a number of people on the Cocoon project who are not aware of the process for the Cocoon site. So maybe someone can find out and document it. http://wiki.apache.org/cocoon/CocoonWebsiteUpdate Needs some editing re CVS vs SVN, and cocoon-2.2 is not covered, but basics are there. Thanks for updating the page Vadim. However, there is a more fundamental problem about the documentation: we know what we want in the end (fabulous documentation on the website) and what we have now (documentation of various quality scattered over several places), but what to do in the mean time? Holidays have surely erased much of my memory ;-), so I'm trying again to clarify things for myself. Do please chip in and correct me if I'm wrong. I've looked through the archives and tried to retrieve what was generally agreed on: Current state: documentation of varying quality in wiki, Daisy on Cocoon zone, website and java docs. End result: extensive, coherent, up-to-date documentation of excellent quality at the website. Note: I'm not sure whether cocoon.apache.org will be the official cocoon documentation location or the Daisy repository, but that's a discussion that can be held much later in time. In between we need to build one documentation repository and AFAIR we decided on Daisy on the cocoon zone. To me this means that ALL (yes ALL) documentation pages need to be moved there, after a reviewing process. Bruno has helped out here by moving the doc pages from SVN BRANCHE 2.X to a separate collection in Daisy. The only thing to be done now is review these pages and move them to the actual documentation set. Since then (June 17) some time has passed, so I will figure out what changes have been done to the doc pages in SVN since then and incorporate them into the Daisy version. I'll assume that updated pages are worth keeping, so I'll also move them over to the current documentation collection in Daisy. Requests: - PLEASE DO THE UPDATES OF THE DOCUMENTATION IN THE WEBSITE IN DAISY! - If you want to help, start by checking pages in the legacy docs collection in Daisy and move them to the regular collection. - Stop updating/adding doc pages in SVN. Once this is done, someone (Ross?, Reinhard?) could extract the information and update cocoon.apache.org for the time being. Bye, Helma
Re: Documentation request
Torsten Schlabach wrote: Where is that DAISY instance and how can I access it? Who can access it? Anyone or just Cocoon committers? http://cocoon.zones.apache.org/daisy/ Have to run now. Bye, Helma
Re: Documentation request
Thank you. Maybe there should be a link to this from the Cocoon site. This might make it more popular. Regards, Torsten Torsten Schlabach wrote: Where is that DAISY instance and how can I access it? Who can access it? Anyone or just Cocoon committers? http://cocoon.zones.apache.org/daisy/ Have to run now. Bye, Helma
Re: Documentation request
Torsten Schlabach wrote: Thank you. Maybe there should be a link to this from the Cocoon site. This might make it more popular. It isn't intended for public consumption. It is intended as a backend system. So, we might publish it on some dev site, but not on the public site - in time, the content of the Daisy site should be uploaded to the public site. Regards, Upayavira
Re: Documentation request
Torsten Schlabach wrote: Note: I'm not sure whether cocoon.apache.org will be the official cocoon documentation location It will probably be for anyone interested in reading Cocoon documentation. Unless you remove *any* documentation from the site and make a bold link saying: This site does not have documentation - please go *here*! But what for is a project website if it does not contain the docu? Daisy is to edit website content, it still will be published to the main cocoon.apache.org website - at least, that's the intention. Vadim
EHCache exception
One of our production servers is getting this exception repeatedly. Can someone clue me in on what to do to correct it? The code base was at svn revision 122686 which, as I recall, was slightly before 2.1.7 was released. Ralph - cocoon-ehcache-1Cache: Could not read disk store element for key PK_G-file-cocoon://webcenter/contentAccess?file=fiFiles/content/home_message.xhtmlpipelinehash=4720981305673544638 java.io.EOFException at java.io.RandomAccessFile.readFully(RandomAccessFile.java:365) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:343) at net.sf.ehcache.store.DiskStore.get(DiskStore.java:258) at net.sf.ehcache.Cache.searchInDiskStore(Cache.java:545) at net.sf.ehcache.Cache.get(Cache.java:361) at org.apache.cocoon.components.store.impl.EHDefaultStore.get(EHDefaultStore.java:242) at org.apache.cocoon.caching.impl.CacheImpl.get(CacheImpl.java:97) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.validatePipeline(AbstractCachingProcessingPipeline.java:420) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:616) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:488) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.prepareInternal(AbstractProcessingPipeline.java:501) at org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:343) at org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:213) at org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource(SitemapSourceFactory.java:64) at org.apache.excalibur.source.impl.SourceResolverImpl.resolveURI(SourceResolverImpl.java:208) at org.apache.cocoon.components.CocoonComponentManager.resolveURI(CocoonComponentManager.java:516) at org.apache.cocoon.portal.coplet.adapter.impl.URICopletAdapter.streamContent(URICopletAdapter.java:125) at org.apache.cocoon.portal.coplet.adapter.impl.URICopletAdapter.streamContent(URICopletAdapter.java:89) at org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter.toSAX(AbstractCopletAdapter.java:133) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultCopletAspect.toSAX(DefaultCopletAspect.java:75) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.aspect.impl.HistoryAspect.toSAX(HistoryAspect.java:114) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.impl.AspectRenderer.toSAX(AspectRenderer.java:85) at org.apache.cocoon.portal.layout.renderer.aspect.impl.AbstractCompositeAspect.processLayout(AbstractCompositeAspect.java:86) at org.apache.cocoon.portal.layout.renderer.aspect.impl.TabContentAspect.toSAX(TabContentAspect.java:143) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.aspect.impl.HistoryAspect.toSAX(HistoryAspect.java:114) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.aspect.impl.ParameterAspect.toSAX(ParameterAspect.java:85) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.impl.AspectRenderer.toSAX(AspectRenderer.java:85) at org.apache.cocoon.portal.layout.renderer.aspect.impl.AbstractCompositeAspect.processLayout(AbstractCompositeAspect.java:86) at org.apache.cocoon.portal.layout.renderer.aspect.impl.TabContentAspect.toSAX(TabContentAspect.java:143) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.aspect.impl.HistoryAspect.toSAX(HistoryAspect.java:114) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.aspect.impl.ParameterAspect.toSAX(ParameterAspect.java:85) at org.apache.cocoon.portal.layout.renderer.aspect.impl.DefaultRendererContext.invokeNext(DefaultRendererContext.java:62) at org.apache.cocoon.portal.layout.renderer.impl.AspectRenderer.toSAX(AspectRenderer.java:85) at org.apache.cocoon.portal.impl.PortalManagerImpl.showPortal(PortalManagerImpl.java:76) at
Re: EHCache exception
On 8/12/05, Ralph Goers [EMAIL PROTECTED] wrote: One of our production servers is getting this exception repeatedly. Can someone clue me in on what to do to correct it? The code base was at svn revision 122686 which, as I recall, was slightly before 2.1.7 was released. Ralph - cocoon-ehcache-1Cache: Could not read disk store element for key PK_G-file-cocoon://webcenter/contentAccess? This looks like a corrupted cache (though it's been a while since I've seen the message that results from one). If so, you may have to shutdown Cocoon, delete the cache files (cocoon-ehcache-1.index and cocoon-ehcache-1.data) and restart Cocoon... -- Peter Hunsberger
Re: EHCache exception
Thanks, Peter. I suspected it was a corruption. I didn't know the names of the files. Frankly, I'm not even sure we need external caching enabled for this application. Will it provide any better performance than re-reading the original document? Ralph Peter Hunsberger wrote: On 8/12/05, Ralph Goers [EMAIL PROTECTED] wrote: One of our production servers is getting this exception repeatedly. Can someone clue me in on what to do to correct it? The code base was at svn revision 122686 which, as I recall, was slightly before 2.1.7 was released. Ralph - cocoon-ehcache-1Cache: Could not read disk store element for key PK_G-file-cocoon://webcenter/contentAccess? This looks like a corrupted cache (though it's been a while since I've seen the message that results from one). If so, you may have to shutdown Cocoon, delete the cache files (cocoon-ehcache-1.index and cocoon-ehcache-1.data) and restart Cocoon...
Re: EHCache exception
On 8/12/05, Ralph Goers [EMAIL PROTECTED] wrote: Thanks, Peter. I suspected it was a corruption. I didn't know the names of the files. Frankly, I'm not even sure we need external caching enabled for this application. Will it provide any better performance than re-reading the original document? It should, it normally stays in memory and only gets written to disk at shutdown (or overflow). If you suffer a hard shutdown on Cocoon you can get a corrupt cache and you get errors when there are attempts to validate the on disk cache against the incoming objects. A nice fix would be only to issue one error then stop checking... Only testing will tell you for sure if caching is worth it, for us it makes a huge difference... -- Peter Hunsberger
Re: Documentation request
Guys, On 8/12/05, Upayavira [EMAIL PROTECTED] wrote: It isn't intended for public consumption. It is intended as a backend system. So, we might publish it on some dev site, but not on the public site - in time, the content of the Daisy site should be uploaded to the public site. On 8/12/05, Vadim Gritsenko [EMAIL PROTECTED] wrote: Daisy is to edit website content, it still will be published to the main cocoon.apache.org website - at least, that's the intention. Then let's tackle two problems at once by moving the current website content into Daisy (Bruno has already done most of it) and, after reviewing the current pages, produce a new version of the website through the use of Ross' Daisy-to-Forrest component (if that is more workable than the current procedure as updated on the wiki by Vadim) and repeat this process more frequently than now (maybe once a month, or after a certain number of modifications in Daisy). OTOH I don't see why Daisy should be hidden from the general user population. I myself rather see documentation in progress than static, incomplete documentation. The only warning we should put up is that it's subject to change, both content and outline. However, the search is very good, so it is very likely people will find what they are looking for. -- Bye, hepabolu
Re: EHCache exception
Thanks Peter. I can understand that the in-memory caching makes a huge difference. I am not sure as to whether you are talking about that or external caching. I guess what I am wondering is if setting overflowToDisk to false in ehcache.xml would make much of a difference. Ralph Peter Hunsberger wrote: On 8/12/05, Ralph Goers [EMAIL PROTECTED] wrote: Thanks, Peter. I suspected it was a corruption. I didn't know the names of the files. Frankly, I'm not even sure we need external caching enabled for this application. Will it provide any better performance than re-reading the original document? It should, it normally stays in memory and only gets written to disk at shutdown (or overflow). If you suffer a hard shutdown on Cocoon you can get a corrupt cache and you get errors when there are attempts to validate the on disk cache against the incoming objects. A nice fix would be only to issue one error then stop checking... Only testing will tell you for sure if caching is worth it, for us it makes a huge difference...
Re: EHCache exception
Got me, guess you'd have to experiment with that one: lots of variables... On 8/12/05, Ralph Goers [EMAIL PROTECTED] wrote: Thanks Peter. I can understand that the in-memory caching makes a huge difference. I am not sure as to whether you are talking about that or external caching. I guess what I am wondering is if setting overflowToDisk to false in ehcache.xml would make much of a difference. Ralph -- Peter Hunsberger
Re: EHCache exception
On 12.08.2005 20:38, Ralph Goers wrote: Thanks Peter. I can understand that the in-memory caching makes a huge difference. I am not sure as to whether you are talking about that or external caching. I guess what I am wondering is if setting overflowToDisk to false in ehcache.xml would make much of a difference. Of course it depends - as always. But you must not forget that XML is not cached in its file version, but in a processed form: see the org.apache.cocoon.components.sax package. So there might be advantages for external caching too. Joerg
Re: Documentation request
Upayavira wrote: Torsten Schlabach wrote: Thank you. Maybe there should be a link to this from the Cocoon site. This might make it more popular. It isn't intended for public consumption. It is intended as a backend system. So, we might publish it on some dev site, but not on the public site - in time, the content of the Daisy site should be uploaded to the public site. The Daisy plugin for Forrest is now complete and being used in a (small) production environment. If people start editing in Daisy, Forrest can create the standalone site for cocoon.apache.org and for distributions. You can create a separate navigation document within Daisy (or a site.xml document for Forrest) and use that to define what is made public. In other words, what is in Daisy need not be the publically published materials. Ross
More Cocoon stacktraces
Hi team! I added new features to the Cocoon stacktraces: - a Location now has a description, which is used to store the statement name (e.g. map:generate or jx:set) - when an error occurs while processing a pipeline, all components of the pipeline and their locations are added to the stacktrace - the nesting of exception has been dramatically reduced: as soon as an exception with a location is catched by Cocoon, it is never wrapped again but new locations are appended to its location stack I will port this to trunk in the coming days. We'll then have to make sure that every exception that is raised in a location-aware environment uses the location framework in org.apache.cocoon.util.location. I'll write a short doc explaining how to do that. Enjoy, Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
