Re: cocoon.processPipelineTo()
Mark Lundquist wrote: Hi, I seem to remember from a long time ago, some mention of something that could be used in place of processPipelineTo(). Something that might have been better, or... not sure. Anyway, does this ring any bells? I can't seem to find the reference now... best regards, —ml— PipelineUtil? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: Apples enhancements
Reinhard Poetz wrote: Leszek Gawron wrote: Reinhard Poetz wrote: Leszek Gawron wrote: What 'apple initialization options' are you refering to ? - Thread.currentThread().getContextClassLoader().loadClass(appleName); - sitemapManager.lookup(beanName); And why would you like to mix those? Either you want managed apples or you don't. If some do not need to be managed the only thing you need to do is: bean id=appleName class=o.a.c.apples.AppleName scope=prototype/ and you have the same functionality but more consistent. right and as your solution was in place first, I will remove the support for #[bean-name] apples (btw, sooner or later we should deprecate the call function as it doesn't fit for a generic controller concept at all) Do not get me wrong. You are way more experienced so I don't feel like enforcing my solution (which is btw a 5 liner). Still some discussion won't hurt :) There is one more thing that I dislike about current apples + spring integration: you can mix ApplesController vs. StatelessApplesController (which triggers different continuations handling) and prototype scope vs. singleton scope. The most dangerous situation is marking a bean singleton and not implementing StatelessAppleController. This way a continuation will be created with a singleton apple which other threads also will use. Simply put: ApplesProcessor.callFunction should not depend on marker interfaces if used with managed apples. What do you want to say? Shall we disallow singleton scoped beans that do not implement StatelessAppleController? Exactly. There is no point in such construct (at least I don't see it) and it may be a very dangerous mistake to be made. -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: Apples enhancements
Leszek Gawron wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
What 'apple initialization options' are you refering to ?
- Thread.currentThread().getContextClassLoader().loadClass(appleName);
- sitemapManager.lookup(beanName);
And why would you like to mix those? Either you want managed apples
or you don't. If some do not need to be managed the only thing you
need to do is:
bean id=appleName class=o.a.c.apples.AppleName scope=prototype/
and you have the same functionality but more consistent.
right and as your solution was in place first, I will remove the
support for #[bean-name] apples (btw, sooner or later we should
deprecate the call function as it doesn't fit for a generic
controller concept at all)
Do not get me wrong. You are way more experienced so I don't feel like
enforcing my solution (which is btw a 5 liner). Still some discussion
won't hurt :)
The only argument for making both options available is less configuration. But
thinking more about it, I probably want all my Apples being managed by Spring in
the future.
There is one more thing that I dislike about current apples + spring
integration: you can mix ApplesController vs.
StatelessApplesController (which triggers different continuations
handling) and prototype scope vs. singleton scope.
The most dangerous situation is marking a bean singleton and not
implementing StatelessAppleController. This way a continuation will
be created with a singleton apple which other threads also will use.
Simply put: ApplesProcessor.callFunction should not depend on marker
interfaces if used with managed apples.
What do you want to say? Shall we disallow singleton scoped beans that
do not implement StatelessAppleController?
Exactly. There is no point in such construct (at least I don't see it)
and it may be a very dangerous mistake to be made.
I Will look into it. I think it is possible to prevent it since with Carsten's
help we have access to the Spring app context in the interpreter now which
should make it possible to find out a bean's scope.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[jira] Commented: (COCOON-2021) NPE in WriteDOMSessionTransformer
[
https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478723
]
robert.onslow commented on COCOON-2021:
---
The problem lies in this matcher:
map:match pattern=*.xhtml
map:select type=request-method
map:when test=GET
map:generate type=serverpages src=xsp/{1}.xsp/
map:transform src=xsl/{1}.xsl/
map:serialize type=xhtml/
/map:when
map:when test=POST
map:generate type=stream/
map:transform type=writeDOMsession
map:parameter name=dom-name value=postdata/
map:parameter name=dom-root-element value=n1:dataFields/
/map:transform
map:serialize/
/map:when
/map:select
/map:match
When the POST comes through, the WriteDOMSessionTransformer is not having its
setup() method invoked. Is this expected behaviour?
NPE in WriteDOMSessionTransformer
-
Key: COCOON-2021
URL: https://issues.apache.org/jira/browse/COCOON-2021
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.10
Reporter: robert.onslow
The following POST thru' a Stream generator generates an NPE:
POST:
?xml version=1.0 encoding=UTF-8?
n1:dataFields xmlns:xscript=http://apache.org/xsp/xscript/1.0;
xmlns:soap=http://apache.org/xsp/soap/3.0;
xmlns:xsp-request=http://apache.org/xsp/request/2.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xhtml=http://www.w3.org/1999/xhtml;
xmlns:n5=http://xlegal.co.uk/courts/schemas/parties;
xmlns:n4=http://xlegal.co.uk/courts/schemas/case;
xmlns:n3=http://xlegal.co.uk/courts/schemas/objects;
xmlns:n2=http://xlegal.co.uk/courts/schemas/chron;
xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:n1=http://xlegal.co.uk/XPDLEngine/;
xmlns:xpdle=http://xlegal.co.uk/XPDLEngine/;
xmlns:xforms=http://www.w3.org/2002/xforms;
newpkg_df5
n2:EventList caseNumber=HC04C1234
n2:Event eventOfType=documentFiled eventTime=10:00
eventDate=2007-01-01
n3:StatCase dref=http://; apparentDate=2007-01-01
statCaseOfType=Claim Form
/n3:StatCase
/n2:Event
/n2:EventList
/newpkg_df5
newpkg_df3HC04C1234/newpkg_df3
newpkg_df4
n4:Case caseNumber=HC04C1234
n5:Parties
n5:PartyGroup partyGroupOfType=Claimant
n5:PartyNEW CLAIMANT/n5:Party
/n5:PartyGroup
n5:PartyGroup partyGroupOfType=Defendant
n5:PartyNEW DEFENDANT/n5:Party
/n5:PartyGroup
/n5:Parties
/n4:Case
/newpkg_df4
/n1:dataFields
Sitemap:
map:generate type=stream/
map:transform type=writeDOMsession
map:parameter name=dom-name value=postdata/
map:parameter name=dom-root-element value=n1:dataFields/
/map:transform
map:serialize/
Exception:
java.lang.NullPointerException
at
org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186)
at
org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123)
at
org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown
Source)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
The namespaces appear to be correct in the POST. The error is still present
when a different dom-root-element is used.
Is the stream generator is generating a startPrefixMapping(null, null) when
the unqualified elements appear?
Robert
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: cocoon.processPipelineTo()
Leszek Gawron wrote: Mark Lundquist wrote: Hi, I seem to remember from a long time ago, some mention of something that could be used in place of processPipelineTo(). Something that might have been better, or... not sure. Anyway, does this ring any bells? I can't seem to find the reference now... best regards, —ml— PipelineUtil? Yep. Provides an easier way to call pipelines from flowscript to stream, sax, dom, etc. Sylvain -- Sylvain Wallez - http://bluxte.net
Can't build trunk
Hi, I just did an 'svn up' and now I'm having problems building trunk. It looks like something with rcl. [INFO] Building Cocoon Reloading ClassLoader - Webapp Wrapper [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 4 source files to C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [32,8] cann ot resolve symbol symbol : constructor ReloadingListener () location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [36,13] can not resolve symbol symbol : method onFileChange (java.io.File) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [41,13] can not resolve symbol symbol : method onFileDelete (java.io.File) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [46,13] can not resolve symbol symbol : method onFileCreate (java.io.File) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\ReloadingClassloaderManager.j ava:[72,18] cannot resolve symbol symbol : method addReloadNotificationListener (org.apache.commons.jci.ReloadingClassLoader) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\ReloadingClassloaderManager.j ava:[73,19] addListener(org.apache.commons.jci.monitor.FilesystemAlterationListener) in org.apache.commons.jci.monitor.FilesystemAlterationMonitor cannot be applied t o (java.io.File,org.apache.commons.jci.listeners.ReloadingListener) Anyone any idea? Thanks, Bart.
[2.2] Can't build with empty local repository
Hi, I've tried to build Cocoon with an empty local repository, block Cocoon Samples Style Default Block has a dependency on cocoon-deployer-plugin version 1.0.0-M2-SNAPSHOT which can't be found on any snapshot server. This aftifact was available in my local repository. Is the version in the pom incorrect? Thanks, Bart.
Re: Can't build trunk
Bart Molenkamp wrote:
Anyone any idea?
yes, my fault :-(
At the weekend I upgraded to the latest version of commons-jci which is only
available from SVN but not in any public Maven repo.
For now I commented both rcl modules in cocoon/trunk/tools/pom.xml. There could
be some references in other poms to it but don't have time now to run a build
with an empty local repo to find it out.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
JIRA and Daisy karma
Hello, Would someone be so kind to give me necessary rights on JIRA and Daisy? My JIRA and Daisy logins are both: grek Thanks. -- Grzegorz Kossakowski
Re: JIRA and Daisy karma
Grzegorz Kossakowski wrote:
Hello,
Would someone be so kind to give me necessary rights on JIRA and Daisy?
My JIRA and Daisy logins are both: grek
done
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
cocoon-rcl test case fails due to hardcoded path
Hi, In RwmPropertiesTest there are several hardcoded path like: assertEquals(file:/F:/blocks/myBlock2/src/main/resources/COB-INF, springProps.getProperty(org.apache.cocoon.cocoon-rcl-plugin-demo.block2/contextPath)); Reinhard, could you fix that? -- Grzegorz Kossakowski
Re: [vote] Jeroen Reijn as a new Cocoon committer
On Mar 5, 2007, at 9:19 AM, Andrew Savory wrote: I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [vote] Felix Knecht as a new Cocoon committer
On Mar 5, 2007, at 8:38 PM, Reinhard Poetz wrote: I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! +1 Ugo
[jira] Commented: (COCOON-2021) NPE in WriteDOMSessionTransformer
[ https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478777 ] robert.onslow commented on COCOON-2021: --- Sorry - please close I had failed to set up a session with a map:act type=session around my components in the sitmap. Looking in the cocoon log in WEB-INF/logs showed that setup() was being called, but was failing due to the lack of a session. Robert NPE in WriteDOMSessionTransformer - Key: COCOON-2021 URL: https://issues.apache.org/jira/browse/COCOON-2021 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: robert.onslow The following POST thru' a Stream generator generates an NPE: POST: ?xml version=1.0 encoding=UTF-8? n1:dataFields xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xhtml=http://www.w3.org/1999/xhtml; xmlns:n5=http://xlegal.co.uk/courts/schemas/parties; xmlns:n4=http://xlegal.co.uk/courts/schemas/case; xmlns:n3=http://xlegal.co.uk/courts/schemas/objects; xmlns:n2=http://xlegal.co.uk/courts/schemas/chron; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:n1=http://xlegal.co.uk/XPDLEngine/; xmlns:xpdle=http://xlegal.co.uk/XPDLEngine/; xmlns:xforms=http://www.w3.org/2002/xforms; newpkg_df5 n2:EventList caseNumber=HC04C1234 n2:Event eventOfType=documentFiled eventTime=10:00 eventDate=2007-01-01 n3:StatCase dref=http://; apparentDate=2007-01-01 statCaseOfType=Claim Form /n3:StatCase /n2:Event /n2:EventList /newpkg_df5 newpkg_df3HC04C1234/newpkg_df3 newpkg_df4 n4:Case caseNumber=HC04C1234 n5:Parties n5:PartyGroup partyGroupOfType=Claimant n5:PartyNEW CLAIMANT/n5:Party /n5:PartyGroup n5:PartyGroup partyGroupOfType=Defendant n5:PartyNEW DEFENDANT/n5:Party /n5:PartyGroup /n5:Parties /n4:Case /newpkg_df4 /n1:dataFields Sitemap: map:generate type=stream/ map:transform type=writeDOMsession map:parameter name=dom-name value=postdata/ map:parameter name=dom-root-element value=n1:dataFields/ /map:transform map:serialize/ Exception: java.lang.NullPointerException at org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186) at org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123) at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) The namespaces appear to be correct in the POST. The error is still present when a different dom-root-element is used. Is the stream generator is generating a startPrefixMapping(null, null) when the unqualified elements appear? Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2021) NPE in WriteDOMSessionTransformer
[ https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Johnston closed COCOON-2021. -- Resolution: Invalid Closing at the request of the issue reporter. NPE in WriteDOMSessionTransformer - Key: COCOON-2021 URL: https://issues.apache.org/jira/browse/COCOON-2021 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: robert.onslow The following POST thru' a Stream generator generates an NPE: POST: ?xml version=1.0 encoding=UTF-8? n1:dataFields xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xhtml=http://www.w3.org/1999/xhtml; xmlns:n5=http://xlegal.co.uk/courts/schemas/parties; xmlns:n4=http://xlegal.co.uk/courts/schemas/case; xmlns:n3=http://xlegal.co.uk/courts/schemas/objects; xmlns:n2=http://xlegal.co.uk/courts/schemas/chron; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:n1=http://xlegal.co.uk/XPDLEngine/; xmlns:xpdle=http://xlegal.co.uk/XPDLEngine/; xmlns:xforms=http://www.w3.org/2002/xforms; newpkg_df5 n2:EventList caseNumber=HC04C1234 n2:Event eventOfType=documentFiled eventTime=10:00 eventDate=2007-01-01 n3:StatCase dref=http://; apparentDate=2007-01-01 statCaseOfType=Claim Form /n3:StatCase /n2:Event /n2:EventList /newpkg_df5 newpkg_df3HC04C1234/newpkg_df3 newpkg_df4 n4:Case caseNumber=HC04C1234 n5:Parties n5:PartyGroup partyGroupOfType=Claimant n5:PartyNEW CLAIMANT/n5:Party /n5:PartyGroup n5:PartyGroup partyGroupOfType=Defendant n5:PartyNEW DEFENDANT/n5:Party /n5:PartyGroup /n5:Parties /n4:Case /newpkg_df4 /n1:dataFields Sitemap: map:generate type=stream/ map:transform type=writeDOMsession map:parameter name=dom-name value=postdata/ map:parameter name=dom-root-element value=n1:dataFields/ /map:transform map:serialize/ Exception: java.lang.NullPointerException at org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186) at org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123) at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) The namespaces appear to be correct in the POST. The error is still present when a different dom-root-element is used. Is the stream generator is generating a startPrefixMapping(null, null) when the unqualified elements appear? Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2021) NPE in WriteDOMSessionTransformer
[ https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke reassigned COCOON-2021: - Assignee: Jörg Heinicke NPE in WriteDOMSessionTransformer - Key: COCOON-2021 URL: https://issues.apache.org/jira/browse/COCOON-2021 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: robert.onslow Assigned To: Jörg Heinicke The following POST thru' a Stream generator generates an NPE: POST: ?xml version=1.0 encoding=UTF-8? n1:dataFields xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xhtml=http://www.w3.org/1999/xhtml; xmlns:n5=http://xlegal.co.uk/courts/schemas/parties; xmlns:n4=http://xlegal.co.uk/courts/schemas/case; xmlns:n3=http://xlegal.co.uk/courts/schemas/objects; xmlns:n2=http://xlegal.co.uk/courts/schemas/chron; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:n1=http://xlegal.co.uk/XPDLEngine/; xmlns:xpdle=http://xlegal.co.uk/XPDLEngine/; xmlns:xforms=http://www.w3.org/2002/xforms; newpkg_df5 n2:EventList caseNumber=HC04C1234 n2:Event eventOfType=documentFiled eventTime=10:00 eventDate=2007-01-01 n3:StatCase dref=http://; apparentDate=2007-01-01 statCaseOfType=Claim Form /n3:StatCase /n2:Event /n2:EventList /newpkg_df5 newpkg_df3HC04C1234/newpkg_df3 newpkg_df4 n4:Case caseNumber=HC04C1234 n5:Parties n5:PartyGroup partyGroupOfType=Claimant n5:PartyNEW CLAIMANT/n5:Party /n5:PartyGroup n5:PartyGroup partyGroupOfType=Defendant n5:PartyNEW DEFENDANT/n5:Party /n5:PartyGroup /n5:Parties /n4:Case /newpkg_df4 /n1:dataFields Sitemap: map:generate type=stream/ map:transform type=writeDOMsession map:parameter name=dom-name value=postdata/ map:parameter name=dom-root-element value=n1:dataFields/ /map:transform map:serialize/ Exception: java.lang.NullPointerException at org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186) at org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123) at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) The namespaces appear to be correct in the POST. The error is still present when a different dom-root-element is used. Is the stream generator is generating a startPrefixMapping(null, null) when the unqualified elements appear? Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2021) NPE in WriteDOMSessionTransformer
[ https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke reopened COCOON-2021: --- NPE in WriteDOMSessionTransformer - Key: COCOON-2021 URL: https://issues.apache.org/jira/browse/COCOON-2021 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: robert.onslow Assigned To: Jörg Heinicke The following POST thru' a Stream generator generates an NPE: POST: ?xml version=1.0 encoding=UTF-8? n1:dataFields xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xhtml=http://www.w3.org/1999/xhtml; xmlns:n5=http://xlegal.co.uk/courts/schemas/parties; xmlns:n4=http://xlegal.co.uk/courts/schemas/case; xmlns:n3=http://xlegal.co.uk/courts/schemas/objects; xmlns:n2=http://xlegal.co.uk/courts/schemas/chron; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:n1=http://xlegal.co.uk/XPDLEngine/; xmlns:xpdle=http://xlegal.co.uk/XPDLEngine/; xmlns:xforms=http://www.w3.org/2002/xforms; newpkg_df5 n2:EventList caseNumber=HC04C1234 n2:Event eventOfType=documentFiled eventTime=10:00 eventDate=2007-01-01 n3:StatCase dref=http://; apparentDate=2007-01-01 statCaseOfType=Claim Form /n3:StatCase /n2:Event /n2:EventList /newpkg_df5 newpkg_df3HC04C1234/newpkg_df3 newpkg_df4 n4:Case caseNumber=HC04C1234 n5:Parties n5:PartyGroup partyGroupOfType=Claimant n5:PartyNEW CLAIMANT/n5:Party /n5:PartyGroup n5:PartyGroup partyGroupOfType=Defendant n5:PartyNEW DEFENDANT/n5:Party /n5:PartyGroup /n5:Parties /n4:Case /newpkg_df4 /n1:dataFields Sitemap: map:generate type=stream/ map:transform type=writeDOMsession map:parameter name=dom-name value=postdata/ map:parameter name=dom-root-element value=n1:dataFields/ /map:transform map:serialize/ Exception: java.lang.NullPointerException at org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186) at org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123) at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) The namespaces appear to be correct in the POST. The error is still present when a different dom-root-element is used. Is the stream generator is generating a startPrefixMapping(null, null) when the unqualified elements appear? Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2021) NPE in WriteDOMSessionTransformer
[ https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke closed COCOON-2021. - Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Adapted WriteDOMSessionTransformer so that NPE is prevented in case session is not available. NPE in WriteDOMSessionTransformer - Key: COCOON-2021 URL: https://issues.apache.org/jira/browse/COCOON-2021 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: robert.onslow Assigned To: Jörg Heinicke Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) The following POST thru' a Stream generator generates an NPE: POST: ?xml version=1.0 encoding=UTF-8? n1:dataFields xmlns:xscript=http://apache.org/xsp/xscript/1.0; xmlns:soap=http://apache.org/xsp/soap/3.0; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xhtml=http://www.w3.org/1999/xhtml; xmlns:n5=http://xlegal.co.uk/courts/schemas/parties; xmlns:n4=http://xlegal.co.uk/courts/schemas/case; xmlns:n3=http://xlegal.co.uk/courts/schemas/objects; xmlns:n2=http://xlegal.co.uk/courts/schemas/chron; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:n1=http://xlegal.co.uk/XPDLEngine/; xmlns:xpdle=http://xlegal.co.uk/XPDLEngine/; xmlns:xforms=http://www.w3.org/2002/xforms; newpkg_df5 n2:EventList caseNumber=HC04C1234 n2:Event eventOfType=documentFiled eventTime=10:00 eventDate=2007-01-01 n3:StatCase dref=http://; apparentDate=2007-01-01 statCaseOfType=Claim Form /n3:StatCase /n2:Event /n2:EventList /newpkg_df5 newpkg_df3HC04C1234/newpkg_df3 newpkg_df4 n4:Case caseNumber=HC04C1234 n5:Parties n5:PartyGroup partyGroupOfType=Claimant n5:PartyNEW CLAIMANT/n5:Party /n5:PartyGroup n5:PartyGroup partyGroupOfType=Defendant n5:PartyNEW DEFENDANT/n5:Party /n5:PartyGroup /n5:Parties /n4:Case /newpkg_df4 /n1:dataFields Sitemap: map:generate type=stream/ map:transform type=writeDOMsession map:parameter name=dom-name value=postdata/ map:parameter name=dom-root-element value=n1:dataFields/ /map:transform map:serialize/ Exception: java.lang.NullPointerException at org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186) at org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123) at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) The namespaces appear to be correct in the POST. The error is still present when a different dom-root-element is used. Is the stream generator is generating a startPrefixMapping(null, null) when the unqualified elements appear? Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (101 issues) Subscriber: cocoon Key Summary COCOON-2019 Make DefaultRunnableManager custom configurable https://issues.apache.org/jira/browse/COCOON-2019 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2016 captcha sample https://issues.apache.org/jira/browse/COCOON-2016 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2014 Make asciiart sample working https://issues.apache.org/jira/browse/COCOON-2014 COCOON-2010 ServletConnection and ServletSource cache-aware https://issues.apache.org/jira/browse/COCOON-2010 COCOON-2009 Pipelines more HTTP-compliant (respecting and producing HTTP headers and status codes) https://issues.apache.org/jira/browse/COCOON-2009 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1993 Make Forms resources loaded directly https://issues.apache.org/jira/browse/COCOON-1993 COCOON-1992 Make Ajax resourced loaded directly from cocoon-ajax-impl https://issues.apache.org/jira/browse/COCOON-1992 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1955 [Patch] Allow shielded class loading for a single block https://issues.apache.org/jira/browse/COCOON-1955 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice https://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin https://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element https://issues.apache.org/jira/browse/COCOON-1893 COCOON-1887 Host selector should be case insensitive https://issues.apache.org/jira/browse/COCOON-1887 COCOON-1877 [PATCH] Pageable Repeater https://issues.apache.org/jira/browse/COCOON-1877 COCOON-1870 Lucene block does not store attributes when instructed so https://issues.apache.org/jira/browse/COCOON-1870 COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE https://issues.apache.org/jira/browse/COCOON-1846 COCOON-1843 LDAPTransformer: add-entry tag doesn't work https://issues.apache.org/jira/browse/COCOON-1843 COCOON-1842 LDAPTransformer: ClassCastException with Binary fields https://issues.apache.org/jira/browse/COCOON-1842 COCOON-1838 Always use 3-digit version number https://issues.apache.org/jira/browse/COCOON-1838 COCOON-1810 [PATCH] JMSEventMessageListener does not work https://issues.apache.org/jira/browse/COCOON-1810 COCOON-1807 Workaround for IE Bug in button https://issues.apache.org/jira/browse/COCOON-1807 COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
Re: Apples enhancements
Reinhard Poetz wrote: Leszek Gawron wrote: Reinhard Poetz wrote: Leszek Gawron wrote: Reinhard Poetz wrote: Leszek Gawron wrote: What 'apple initialization options' are you refering to ? - Thread.currentThread().getContextClassLoader().loadClass(appleName); - sitemapManager.lookup(beanName); And why would you like to mix those? Either you want managed apples or you don't. If some do not need to be managed the only thing you need to do is: bean id=appleName class=o.a.c.apples.AppleName scope=prototype/ and you have the same functionality but more consistent. right and as your solution was in place first, I will remove the support for #[bean-name] apples (btw, sooner or later we should deprecate the call function as it doesn't fit for a generic controller concept at all) Do not get me wrong. You are way more experienced so I don't feel like enforcing my solution (which is btw a 5 liner). Still some discussion won't hurt :) The only argument for making both options available is less configuration. But thinking more about it, I probably want all my Apples being managed by Spring in the future. There is one more thing that I dislike about current apples + spring integration: you can mix ApplesController vs. StatelessApplesController (which triggers different continuations handling) and prototype scope vs. singleton scope. The most dangerous situation is marking a bean singleton and not implementing StatelessAppleController. This way a continuation will be created with a singleton apple which other threads also will use. Simply put: ApplesProcessor.callFunction should not depend on marker interfaces if used with managed apples. What do you want to say? Shall we disallow singleton scoped beans that do not implement StatelessAppleController? Exactly. There is no point in such construct (at least I don't see it) and it may be a very dangerous mistake to be made. I Will look into it. I think it is possible to prevent it since with Carsten's help we have access to the Spring app context in the interpreter now which should make it possible to find out a bean's scope. There is a small gotcha': currently managed apples are looked up using a service manager, not spring directly. Should we switch to spring lookup? One more thing: even if a bean is spring managed it is being instantiated with LifecycleHelper anyway. I'll try to commit some fix (laaack of time). -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: cocoon-rcl test case fails due to hardcoded path
Grzegorz Kossakowski wrote:
Hi,
In RwmPropertiesTest there are several hardcoded path like:
assertEquals(file:/F:/blocks/myBlock2/src/main/resources/COB-INF,
springProps.getProperty(org.apache.cocoon.cocoon-rcl-plugin-demo.block2/contextPath));
Reinhard, could you fix that?
fixed, thanks for spotting it.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r514671 - /cocoon/trunk/blocks/cocoon-repository/cocoon-repository-impl/src/test/java/org/apache/cocoon/components/source/impl/CachingSourceTestCase.java
[EMAIL PROTECTED] wrote: -assertTrue(meta1 == meta2); +assertTrue(meta1.getMimeType() == meta2.getMimeType()); +assertTrue(meta1.getContentLength() == meta2.getContentLength()); +assertTrue(meta1.getLastModified() == meta2.getLastModified()); Looks like caching source ain't working correctly anymore. It should be returning same (cached) objects. Vadim
Re: svn commit: r514671 - /cocoon/trunk/blocks/cocoon-repository/cocoon-repository-impl/src/test/java/org/apache/cocoon/components/source/impl/CachingSourceTestCase.java
Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: -assertTrue(meta1 == meta2); +assertTrue(meta1.getMimeType() == meta2.getMimeType()); +assertTrue(meta1.getContentLength() == meta2.getContentLength()); +assertTrue(meta1.getLastModified() == meta2.getLastModified()); Looks like caching source ain't working correctly anymore. It should be returning same (cached) objects. It does, test works. Vadim
Re: Reloading Classloader Plugin
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error disappears. After
testing commons-jci built on Sunday afternoon, everything works as expected.
Maybe I'm doing something wrong in
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Reloading Classloader Plugin
Reinhard Poetz wrote:
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error disappears.
After testing commons-jci built on Sunday afternoon, everything works as
expected.
Once again ;-)
Yesterday I did a svn up on commons-jci and now I get errors of type
ClassDefNotFoundError when the reloading classloader is used (- doing a page
refresh) right after a change. After a second page refresh, the error is gone.
After reverting to commons-jci which was built on Sunday afternoon, everything
works as expected (except that I still need to run it in debug mode which causes
problems because the hot code replace mechanism of Eclipse interfers.)
Any clue?
Maybe I'm doing something wrong in
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
