Re: Nullpointer in ZipSerializer (cocoon 2.2)
Robby Pelssers Robby.Pelssers at nxp.com writes:
Hi guys,
Just wanted to know if the issue in below thread has ever been fixed.
http://web.archiveorange.com/archive/v/uRmkWnxszXP6g7Xuw33H
To shortly describe the use case:
http://cocoon.apache.org/2.1/userdocs/ziparchive-serializer.html
The zipserializer only allows either:
- You specify a at src pointing to some cocoon pipeline using
cocoon:// (Ideally it would also support the servlet: protocol as now I have
to provide a façade in the calling cocoon block)
- You specify inline content and the at serializer
In a ideal world you should be able to use at src in combination with the
at serializer because now I have to first include the content from a pipeline
by using cinclude before calling
map:serialize type=”zip”/
I actually created some nice generic functionality to work around some issues:
FLOWSCRIPT ***
function downloadImdsZip() {
var entries = [];
new
Collection(cocoon.request.getParameterValues(id)).forEach(function(id){
var entry = {name: id + .xml, source:
cocoon://chemicalcontent/imds/ + id + .xml, serializer: upload};
print('Adding entry [name=' + entry.name + ', source=' +
entry.source + '] to ZIP archive.');
entries.push(entry);
});
var response = cocoon.response;
response.setHeader(
Content-Disposition,
attachment; filename=imds.zip
);
cocoon.sendPage(zipArchive, {entries: entries});
}
*
?xml version=1.0 encoding=UTF-8?
jx:template
xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
xmlns:zip=http://apache.org/cocoon/zip-archive/1.0;
xmlns:cinclude=http://apache.org/cocoon/include/1.0;
!--
This jx expects an array called 'entries' containing objects with
following
properties:
* name (mandatory)
* source (mandatory)
* serializer (optional)
*
* If both source and serializer are provided, we assume that we want to
include the content inline so we can specify the serializer
--
zip:archive
jx:forEach var=entry items=${entries}
zip:entry name=${entry.name}
jx:choose
jx:when test=${entry.serializer != null}
jx:attribute name=serializer value=${entry.serializer}/
cinclude:include src=${entry.source}/
/jx:when
jx:otherwise
jx:attribute name=src value=${entry.source}/
/jx:otherwise
/jx:choose
/zip:entry
/jx:forEach
/zip:archive
/jx:template
*
map:match pattern=zipArchive
map:generate src=jx/zipArchive.jx type=jx/
map:transform type=cinclude/
map:serialize type=zip/
/map:match
*
But I now am facing the same nullpointer exception as in the link above.
Anyone some usefull input on this matter?
Cheers,
Robby Pelssers
Hi Robby,
Just want to share my fix with the community. The NullPointerException was
caused by ZipArchiveSerializer (improper usage of a setter method). If you read
javadocs, they'll tell you that you shouldn't provide null to setConsumer
method. You can use the specific method to deinitialize consumer. Here is the
patch:
Index: src/main/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
===
--- src/main/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
(revision 1208405)
+++ src/main/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
(revision )
@@ -369,7 +369,7 @@
throw this.exception = new SAXException(ioe);
}
-super.setConsumer(null);
+super.recycle();
this.selector.release(this.serializer);
this.serializer = null;
Best regards,
Ivan Lagunov
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Hi all guys! Apologies for the lack of participations but looks like contributing in more ASF communities requires a lot of time! :) My position are: * +1 on migrating old components - that's true that we could maintain them in their proper branch, but at the same time they would need an update to be more compliant with C3 - moreover, since we agreed on migrating to Java6, it would worth started getting advantage from the new platform - that would imply subprojects actualization. * +1 on restructuring the svn, I would like to restructure anyway the C3 first: IMHO having all the modules in a flat structures starts being a little confusing, even to me that I'm involved, I would suggest to move to a different hierarchical structure, grouping modules by technology/extension type/application type. Moreover IMHO the 'optional' module should be split, it contains now a lot of good reusable - more that at the begin - stuff that we could consider as a collection of modules. Of course, we have to pay attention to not overengineering. I would suggest as well to open a Sandbox open to all ASF committers to experiment new modules. My proposal is considering the two topics separately, I would like Francesco lead the topic #1, I can prepare during the weekend a proposal on how to restructure the SVN. WDYT? Many thanks in advance and sorry for the delay! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Nov 29, 2011 at 5:07 PM, Andreas Hartmann andr...@apache.org wrote: Am 27.11.11 00:58, schrieb Thorsten Scherler: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. IMO the current SVN structure is not really transparent. Trunk (2.2) and cocoon3/trunk are conflicting versions. Maybe the following would make sense? branches/ cocoon-2.2/ cocoon-3/ … subprojects/ cocoon-jnet … Of course this would imply that the subprojects have a well-defined API and functionality which is independent from any particular functionality in any of the Cocoon branches. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
