Re: svn commit: r689749 - /cocoon/whiteboard/corona/trunk/corona-sitemap/src/main/java/org/apache/cocoon/corona/sitemap/InvocationImpl.java
Joerg Heinicke wrote:
> On 28.08.2008 09:47, [EMAIL PROTECTED] wrote:
>
>> Author: reinhard
>> Date: Thu Aug 28 00:47:42 2008
>> New Revision: 689749
>>
>> URL: http://svn.apache.org/viewvc?rev=689749&view=rev
>> Log:
>> improve error reporting: print the full stacktrace when the loglevel
>> is set to INFO or below. Otherwise only print the first 5 lines.
>
> Shouldn't these kind of things be left to the logging implementation and
> configuration?
If I knew how to do this ... Log4j isn't really well documented.
Any hints?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: Help... how can I setFeature() on JaxpParser
On Thu, 2008-08-28 at 14:54 -0700, Mark Lundquist wrote: > Never mind. > > I went ahead as described, creating an XMLReader and setting the > EntityResolver by hand, then setting the feature. It turns out I was > given some bad advice that setting the "load-external-dtd" feature to > false would solve my problem (Xerces trying to connect to w3c.org in > spite of catalog-based EntityResolver), but it doesn't fix it anyway, > so... back to the drawing board. not sure whether you are aware of http://svn.apache.org/viewvc/forrest/branches/update_cocoon_2.1.12-dev/main/webapp/WEB-INF/cocoon.xconf?diff_format=h&view=markup maybe that helps. salu2 > —ml— > > > On Aug 28, 2008, at 10:22 AM, Mark Lundquist wrote: > > > > > Hi, > > > > I very much need to set the feature > > "http://apache.org/xml/features/nonvalidating/load-external-dtd > > " (see http://xerces.apache.org/xerces-j/features.html#load-external-dtd) > > on the Xerces parser wrapped by a JaxpParser instance (returned by > > manager lookup of SAXParser.role). > > > > I don't see a way to do it... it looks like JaxpParser doesn't > > expose an interface for it. JaxpParser buries the factory instances > > and the parser instances pretty thoroughly and doesn't provide any > > handles to set features, even in the component configuration. > > > > This is for a project that's stuck on Cocoon 2.1.8, BTW. I guess I > > can always just create my own parser instance if it comes down to > > that. Before I bother, does anybody know of a way to avoid the > > bother? Maybe I'm missing something... > > > > cheers, > > —ml— > > > > > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: svn commit: r689749 - /cocoon/whiteboard/corona/trunk/corona-sitemap/src/main/java/org/apache/cocoon/corona/sitemap/InvocationImpl.java
On 28.08.2008 09:47, [EMAIL PROTECTED] wrote: Author: reinhard Date: Thu Aug 28 00:47:42 2008 New Revision: 689749 URL: http://svn.apache.org/viewvc?rev=689749&view=rev Log: improve error reporting: print the full stacktrace when the loglevel is set to INFO or below. Otherwise only print the first 5 lines. Shouldn't these kind of things be left to the logging implementation and configuration? Joerg
Re: Help... how can I setFeature() on JaxpParser
Never mind. I went ahead as described, creating an XMLReader and setting the EntityResolver by hand, then setting the feature. It turns out I was given some bad advice that setting the "load-external-dtd" feature to false would solve my problem (Xerces trying to connect to w3c.org in spite of catalog-based EntityResolver), but it doesn't fix it anyway, so... back to the drawing board. —ml— On Aug 28, 2008, at 10:22 AM, Mark Lundquist wrote: Hi, I very much need to set the feature "http://apache.org/xml/features/nonvalidating/load-external-dtd " (see http://xerces.apache.org/xerces-j/features.html#load-external-dtd) on the Xerces parser wrapped by a JaxpParser instance (returned by manager lookup of SAXParser.role). I don't see a way to do it... it looks like JaxpParser doesn't expose an interface for it. JaxpParser buries the factory instances and the parser instances pretty thoroughly and doesn't provide any handles to set features, even in the component configuration. This is for a project that's stuck on Cocoon 2.1.8, BTW. I guess I can always just create my own parser instance if it comes down to that. Before I bother, does anybody know of a way to avoid the bother? Maybe I'm missing something... cheers, —ml—
Help... how can I setFeature() on JaxpParser
Hi, I very much need to set the feature "http://apache.org/xml/features/nonvalidating/load-external-dtd " (see http://xerces.apache.org/xerces-j/features.html#load-external-dtd) on the Xerces parser wrapped by a JaxpParser instance (returned by manager lookup of SAXParser.role). I don't see a way to do it... it looks like JaxpParser doesn't expose an interface for it. JaxpParser buries the factory instances and the parser instances pretty thoroughly and doesn't provide any handles to set features, even in the component configuration. This is for a project that's stuck on Cocoon 2.1.8, BTW. I guess I can always just create my own parser instance if it comes down to that. Before I bother, does anybody know of a way to avoid the bother? Maybe I'm missing something... cheers, —ml—
Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
On Thu, 2008-08-28 at 07:44 -0400, Vadim Gritsenko wrote: > On Aug 26, 2008, at 3:59 AM, Thorsten Scherler wrote: > > > On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote: > >> On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote: > > ... > >> Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is > >> actually unique in any environment. And since it is unique, it does > >> not make sense to lock on it at all - lock on unique object serves no > >> purpose :-) > > > > Makes me wonder since HttpServletRequest is always unique as well > > due to > > the headers, so does not violate as well the whole locking? > > HttpServletRequest is unique only in context of external request; but > it is same for multiple sub-requests of single external request. > Similarly, CommandLineRequest would be unique per single external > request, but shared across sub-requests. > > At the same time, ObjectModelHelper.REQUEST_OBJECT will be always > unique: it will either be HttpServletRequest/CommandLineRequest for > top level, or Wrapper for nested requests. > > > > >> You could, for example, have same effect with code: > >> > >> // Avoids NPE, does nothing > >> if (lock == null) lock = new Object(); > >> > >> > >> To get back to the problem... The original goal of pipeline locking > >> was to prevent separate external requests to start generating cached > >> response for the same resource-intensive resource. In other words, if > >> too external requests both (directly or through aggregation) hit '/ > >> slow/cached/foo' resource, only one request will trigger this > >> pipeline, while another will wait for the first to complete. > >> > >> This logic, in turn, had to be augmented to exclude single external > >> request hitting the same slow resource twice due to aggregation (and > >> parallel aggregation), hence locking against top level external > >> request was implemented. > >> > > > > Understand but I am confused due to the above fact that the > > HttpServletRequest is as well unique as it is my understanding. > > > >> Now, in situation when CommandLineEnvironment is used from the, ahem, > >> command line, two external requests will not happen. Which means that > >> whole pipeline locking thing is irrelevant and can be omitted > >> completely (like in 'lock = new Object()' snippet above). But, the > >> same CommandLineEnvironment stuff can be used in multi threaded > >> environment which uses the CocoonBean class. So, strictly speaking, > >> in > >> this scenario locking still should be performed against external > >> request object, and not against any RequestWrapper which is unique > >> for > >> each sub-request. > > > > I now are using the url as lock key since as I understand it perfectly > > qualifies as lock key. > > Why not CommandLineRequest? Hmm, because it would be the same as ObjectModelHelper.REQUEST_OBJECT this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT, new CommandLineRequest(this, null, uri, null, attributes, parameters, headers)); However if you recommend to do: CommandLineRequest request = new CommandLineRequest(this, null, uri, null, attributes, parameters, headers); this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT, request); this.objectModel.put(CLI_REQUEST, request); That is as well fine with me. wdyt? Thanks for your feedback. salu2 > > > > The patch is attached to COCOON-2241. As soon you are ok with it I > > will > > commit it. > > I'd rather use CommandLineRequest; or at least change one line to be: > >this.objectModel.put(CLI_REQUEST_ID, new String(uri)); > > > > Vadim > > > > Thanks for your patience. > > > > salu2 > > > >> > >> Hope now it all makes more sense. > >> > >> Regards, > >> Vadim > >> > >> > >>> In comparison the HttpEnvironment has in the constructor: > >>> this.objectModel.put(HTTP_REQUEST_OBJECT, req); > >>> where HttpServletRequest req. > >>> > >>> The uniqueness in both cases are, as I understand, the headers. > >>> > >>> salu2 > >> > > -- > > Thorsten Scherler > > thorsten.at.apache.org > > Open Source Java consulting, training and > > solutions > > > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
On Aug 26, 2008, at 3:59 AM, Thorsten Scherler wrote: On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote: On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote: ... Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is actually unique in any environment. And since it is unique, it does not make sense to lock on it at all - lock on unique object serves no purpose :-) Makes me wonder since HttpServletRequest is always unique as well due to the headers, so does not violate as well the whole locking? HttpServletRequest is unique only in context of external request; but it is same for multiple sub-requests of single external request. Similarly, CommandLineRequest would be unique per single external request, but shared across sub-requests. At the same time, ObjectModelHelper.REQUEST_OBJECT will be always unique: it will either be HttpServletRequest/CommandLineRequest for top level, or Wrapper for nested requests. You could, for example, have same effect with code: // Avoids NPE, does nothing if (lock == null) lock = new Object(); To get back to the problem... The original goal of pipeline locking was to prevent separate external requests to start generating cached response for the same resource-intensive resource. In other words, if too external requests both (directly or through aggregation) hit '/ slow/cached/foo' resource, only one request will trigger this pipeline, while another will wait for the first to complete. This logic, in turn, had to be augmented to exclude single external request hitting the same slow resource twice due to aggregation (and parallel aggregation), hence locking against top level external request was implemented. Understand but I am confused due to the above fact that the HttpServletRequest is as well unique as it is my understanding. Now, in situation when CommandLineEnvironment is used from the, ahem, command line, two external requests will not happen. Which means that whole pipeline locking thing is irrelevant and can be omitted completely (like in 'lock = new Object()' snippet above). But, the same CommandLineEnvironment stuff can be used in multi threaded environment which uses the CocoonBean class. So, strictly speaking, in this scenario locking still should be performed against external request object, and not against any RequestWrapper which is unique for each sub-request. I now are using the url as lock key since as I understand it perfectly qualifies as lock key. Why not CommandLineRequest? The patch is attached to COCOON-2241. As soon you are ok with it I will commit it. I'd rather use CommandLineRequest; or at least change one line to be: this.objectModel.put(CLI_REQUEST_ID, new String(uri)); Vadim Thanks for your patience. salu2 Hope now it all makes more sense. Regards, Vadim In comparison the HttpEnvironment has in the constructor: this.objectModel.put(HTTP_REQUEST_OBJECT, req); where HttpServletRequest req. The uniqueness in both cases are, as I understand, the headers. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [jira] Updated: (COCOON-2241) The commandline is not working since cocoon-1985
On Tue, 2008-08-26 at 00:45 -0700, Thorsten Scherler (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/COCOON-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Thorsten Scherler updated COCOON-2241: > -- > > Attachment: COCOON-2241.txt > > Fixing small error that intruded the patch Is it ok that I apply the patch and leave the issue open for later review? I mean the CLI is broken ATM and this patch fixes this. The fix may not be 100% concurrent proof but that we can fix later on. WDYT? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
[summary][vote] Release of cocoon-template-impl-1.0.0 and cocoon-forms-impl-1.0.0
Grzegorz Kossakowski pisze: Grzegorz Kossakowski pisze: Hello Cocoon community, I've prepared artifacts for the release of our two blocks: Cocoon Forms Impl 1.0.0 ~~~ This is Avalon-based (contrary to the 1.1.0 release that has been already published and is Spring-based) version of Cocoon Forms. However, this version is already using SSF for serving resources. Cocoon Template Impl 1.0.0 ~~ Similarly to the Forms block, template block is also based on Avalon. There are no other differences compared to 1.1.0 version which was already published as well. [...] Please cast your votes. Here is my +1 After testing them throughly with rather big application that heavily relies on both Forms and Templates blocks. No problems were found. The vote has passed with three +1 and no negative ones. I'll proceed with publishing and announcing these blocks ASAP. Forgot to add summary tag in the subject. -- Grzegorz Kossakowski
Re: [vote] Release of cocoon-template-impl-1.0.0 and cocoon-forms-impl-1.0.0
Grzegorz Kossakowski pisze: Hello Cocoon community, I've prepared artifacts for the release of our two blocks: Cocoon Forms Impl 1.0.0 ~~~ This is Avalon-based (contrary to the 1.1.0 release that has been already published and is Spring-based) version of Cocoon Forms. However, this version is already using SSF for serving resources. Cocoon Template Impl 1.0.0 ~~ Similarly to the Forms block, template block is also based on Avalon. There are no other differences compared to 1.1.0 version which was already published as well. [...] Please cast your votes. Here is my +1 After testing them throughly with rather big application that heavily relies on both Forms and Templates blocks. No problems were found. The vote has passed with three +1 and no negative ones. I'll proceed with publishing and announcing these blocks ASAP. -- Grzegorz Kossakowski
