Re: svn commit: r439744 - in /cocoon/trunk/tools/cocoon-block-deployer/cocoon-deployer-plugin/src/main/java/org/apache/cocoon/maven/deployer: ./ monolithic/ utils/
[EMAIL PROTECTED] wrote:
+public class CopyUtils {
+public static void copy( InputStream is, OutputStream os ) throws
IOException {
+if ( !(is instanceof BufferedInputStream) ) {
+is = new BufferedInputStream( is );
+}
+if ( !(os instanceof BufferedOutputStream) ) {
+os = new BufferedOutputStream( os );
+}
+
+try {
+IOUtils.copy(is, os);
+} finally {
+IOUtils.closeQuietly(is);
+IOUtils.closeQuietly(os);
+}
+}
+}
I guess that's what one would call "triple buffering", isn't it?
IOUtils uses 4Kb buffer, BufferedInputStream creates buffer 2Kb to 8Kb depending
on Java version, and BufferedOutputStream's buffer varies from 512b to 8Kb. By
the time data is copied, it changes hands 4 times - and two of those are extra.
Vadim
RE: Free for use: SaveFilesTransformer
> Er... why a brand new transformer when you could have > provided a patch adding support for the src attribute in > SourceWritingTransformer??? > > Sylvain I am actually surprised that no one says that the newest SourceWritingTransformer already supports this feature.. ;-) No really, I wasn't confident enough (2 years ago?) and don't have mucht time now to dive into it. But if you think it is useful and perhaps even worth adding to the latest version, I could make a little time to create a patch out of it.. Kind regards, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
Re: Caching jx *without* flow
Thorsten Scherler wrote: On Mon, 2006-09-18 at 11:39 +0200, Leszek Gawron wrote: Hmm, maybe the documentation is outdated but http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html state "When used inside flow, JXTemplate has access to Java and can therefore evaluate expressions like "java.util.Date()" or "java.util.HashMap()". This does NOT work when JXTemplates are used without flow." NOT true. Even if you are not using flow JXTG makes use of Rhino's (javascript engine) NativeJavaPackage. Have a look at https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/environment/FlowObjectModelHelper.java Will have a closer look to get the big picture but the class name sounds heavily like we assume a flow environment. It was TemplateObjectModelHelper but Carsten refactored some functionality outside and thus the class name. We should probably change it. Could you give me a full example of what you want to achieve? http://svn.apache.org/viewvc?view=rev&rev=447311 If we had a simple transformer then we can walk the SAX events and as soon we find an import we add the imported source to the validity. This work fine with an AggregatedValidity. Where the first validity is the src file of the jx. The above example acts on a . A contract is a single unit of content. A contract consist ATM out of a xsl. This xsl can be dispatched against a data uri and the result gets then added in place (simplifying here). do a similar task. Meaning one would want to extend the method treating the import to add to the aggregated validity. This way as soon as an import source get changed the cache get invalid. The biggest problem with the inline jx:cache-validity I see is that it will only act on the main source and not on any imports, right? Yes you're right. I'll have a look into the code you provided and have comments later. We could probably add this class to cocoon-template block and provide some samples. Still - nothing needs to be changed. Yeah that would be awesome. Still I am not sure whether the forrest community would accept the inline solution. I understand your point though, but under the user perspective I am with Niels. What I dislike most about the idea is that the caching is done automatically without user knowing. Moreover it is done for all jxtg runs, not only the chosen ones. Why not have the both solution hand in hand. Meaning if there is no jx:cache-key and jx:cache-validity using the sitemap input parameter approach as fallback. This lets you still define inline but with a comfortable fallback. The comfortable fallback is not to use caching at all. At least not in the default JXTG configuration. Any jx based web application does not perform any caching. We could probably introduce some JTXG configuration parameters like xslt does: pool-max="32" src="org.apache.cocoon.transformation.TraxTransformer"> false false false xalan true If user wants to make JXTG automatically cacheable he/she must explicitly state it in configuration: true true true false false Still it would be way cool if we could limit template's object model to portions we want to use. Otherwise this is very error prone. I will try to implement the feature this week (if noone objects). -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Caching jx *without* flow
On Mon, 2006-09-18 at 11:39 +0200, Leszek Gawron wrote: > > Hmm, maybe the documentation is outdated but > > http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html state "When > > used inside flow, JXTemplate has access to Java and can therefore > > evaluate expressions like "java.util.Date()" or "java.util.HashMap()". > > This does NOT work when JXTemplates are used without flow." > > NOT true. Even if you are not using flow JXTG makes use of Rhino's > (javascript engine) NativeJavaPackage. Have a look at > https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/environment/FlowObjectModelHelper.java > Will have a closer look to get the big picture but the class name sounds heavily like we assume a flow environment. > > I see that http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html is > heavily outdated. > > > > > Wouldn't that mean that the example would not work without flow? > > > > Further regarding the validity as I understand your example this would > > not allow to use an AggregatedValidity which would be extended for all > > , or? > > > > Or could I do > > > > ... > > http://svn.apache.org/viewvc?view=rev&rev=447311 If we had a simple transformer then we can walk the SAX events and as soon we find an import we add the imported source to the validity. This work fine with an AggregatedValidity. Where the first validity is the src file of the jx. The above example acts on a . A contract is a single unit of content. A contract consist ATM out of a xsl. This xsl can be dispatched against a data uri and the result gets then added in place (simplifying here). do a similar task. Meaning one would want to extend the method treating the import to add to the aggregated validity. This way as soon as an import source get changed the cache get invalid. The biggest problem with the inline jx:cache-validity I see is that it will only act on the main source and not on any imports, right? > > > >> We could probably add this class to cocoon-template block and provide > >> some samples. Still - nothing needs to be changed. > > > > Yeah that would be awesome. Still I am not sure whether the forrest > > community would accept the inline solution. I understand your point > > though, but under the user perspective I am with Niels. > > What I dislike most about the idea is that the caching is done > automatically without user knowing. Moreover it is done for all jxtg > runs, not only the chosen ones. Why not have the both solution hand in hand. Meaning if there is no jx:cache-key and jx:cache-validity using the sitemap input parameter approach as fallback. This lets you still define inline but with a comfortable fallback. wdyt? salu2 -- Thorsten Scherler COO Spain Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Caching jx *without* flow
Leszek Gawron wrote: Niels van Kampenhout wrote: Leszek Gawron wrote: The only thing that's missing from HippoJXTemplateGenerator.java functionality is the ability to exclude some parameters from cache key. Anyway this looks like FS from the start: What do you mean by FS? False Security? Flexibility Syndrome :) Ah, ok! The lists of internet abbreviations I found through Google actually all said it meant "For Sale" :-) - if template makes use of all cocoon parameters they should be a part of the cache key, - if not - you shouldn't pass them instead of excluding. Please comment. These two statements are true, and exactly satisfy our requirements. You may have other requirements, though. I was refering to jx:includeKey and jx:excludeKey parameters in your generator. Why do you use it at all? I see what you mean now. I don't think we ever use those parameters, and thinking about it, they do not make sense to me either. If you exclude a sitemap parameter from the cache key, either you get a false cache response or the sitemap parameter was not used in the template anyway. What matters to me is this: in our projects we mainly use JXTG and XSLT, and (as far as I can see from a user perspective) with our solution the formation of the cache key is consistent between the two (cocoon parameters == cache key). This is a big plus in the fragmented world of Cocoon technologies. I like the analogy. In order to fully utilise it we would have to go further in similarities: JTGX object model in this case should be constructed only with sitemap parameters. automatic cache key from sitemap parameters + small object model = full XSLT analogy. We could try this. And the cream on the cake would be to have the same expression language in templates and XSLTs. I keep mixing those up Bottom line: we prefer different solutions and are both happy with them. Good thing we live in a free world ;-) Agreed :) Good, back to work then! :-) Regards, Niels
Re: cannot be in sitemap.xml anymore?
Index: C:/apache/cocoon.home/svn/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/core/container/spring/avalon/SitemapHelper.java===--- C:/apache/cocoon.home/svn/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/core/container/spring/avalon/SitemapHelper.java (revision 447720)
+++ C:/apache/cocoon.home/svn/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/core/container/spring/avalon/SitemapHelper.java (working copy)@@ -200,7 +200,7 @@ final String factoryRole = config.getAttribute
("factory-role", ClassLoaderFactory.ROLE); // Create a new classloader- ClassLoaderConfiguration configBean = AvalonUtils.createConfiguration(sitemapResolver, config);+ ClassLoaderConfiguration configBean =
AvalonUtils.createConfiguration(sitemapResolver, classPathConfig); ClassLoaderFactory clFactory = (ClassLoaderFactory)parentFactory.getBean(factoryRole); return clFactory.createClassLoader(Thread.currentThread
().getContextClassLoader(), configBean,On 9/19/06, Leszek Gawron <
[EMAIL PROTECTED]> wrote:Rice Yeh wrote:> I find this problem is because of a bug at line 203 in
> org.apache.cocoon.core.container.spring.avalon.SitemapHelper, where> classPathConfig shoud be passed as argument to method> AvalonUtils.createConfiguration, intead of config.Could you provide a patch?
--Leszek Gawron, IT Manager MobileBox sp. z o.o.+48 (61) 855 06 67 http://www.mobilebox.plmobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Free for use: SaveFilesTransformer
Geert Josten wrote: > Hi all, > > Available on wiki: > > http://wiki.apache.org/cocoon/SaveFilesTransformer > > It might be that someone else already wrote a Transformer like this one. > It is derived from the SourceWritingTransformer (yet simplified) and has > one important benefit over it: it can take a src attribute that can be > used to capture also binary streams and save them to disk. > > Comments are welcome.. > Er... why a brand new transformer when you could have provided a patch adding support for the src attribute in SourceWritingTransformer??? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: cannot be in sitemap.xml anymore?
Rice Yeh wrote: I find this problem is because of a bug at line 203 in org.apache.cocoon.core.container.spring.avalon.SitemapHelper, where classPathConfig shoud be passed as argument to method AvalonUtils.createConfiguration, intead of config. Could you provide a patch? -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
