You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/05/09 22:17:18 UTC
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
lgawron@apache.org wrote:
> Author: lgawron
> Date: Sun May 8 14:23:28 2005
> New Revision: 169169
>
> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
> Log:
> JXTG uses cocoon store
>
> Modified:
> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
could this be the reason for the following exception?
java.lang.ClassCastException
at
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
at
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
at
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
at
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
--
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: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> The transient store is meant as a cache for objects that aren't
>> serializable, whereas the regular store has a memory front-end and
>> some persistent filesystem swap, and therefore can only accept
>> serializable objects.
>
>
> Not true. Regular store must accept all objects. See also [1].
>
> Vadim
>
> [1] http://cocoon.apache.org/2.1/installing/updating.html#Store
Thanks for clarifying. Nice to know I'm not that crazy after all :)
--
Leszek Gawron lgawron@mobilebox.pl
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: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> The transient store is meant as a cache for objects that aren't
>>>> serializable, whereas the regular store has a memory front-end and
>>>> some persistent filesystem swap, and therefore can only accept
>>>> serializable objects.
>>>
>>>
>>>
>>> Not true. Regular store must accept all objects. See also [1].
>>>
>>> Vadim
>>>
>>> [1] http://cocoon.apache.org/2.1/installing/updating.html#Store
>>
>>
>>
>> Hmm... although the old implementation *may* have been able to accept
>> non-serializable objects, it has AFAIK never formally be defined in
>> the general store contract,
>
>
> So now you will blame this bug on incomplete javadoc, huh? :-)
Well, do we have a better specification?
Here's what it says on the Store interface: "In some cases (like for
example a cache) the data needs not to be persistent. Therefore with the
two role TRANSIENT_STORE and PERSISTENT_STORE you get a store with
exactly that behaviour."
We can consider that "the data needs not to be persisted" when it *can
not* because it's not serializable.
>> and this is why we also have the transient store role.
>
>
> No, that's not necessarily the right conclusion. I say we have
> transient store for objects which should not - or even must not! - be
> persisted across system restarts - even if they are serializable!
True, but (feeling like doing biblical interpertation) a
non-serializable object must not be persisted across system restarts,
and this for a good reason: it isn't possible to store it :-)
>> Considering the current issues with the newer cache systems we use
>> (that integrate both memory front-end and persistent swap)
>
>
> It does not mean that they are better, though. Even MRUMemoryStore is
> more efficient.
>
>
>> and can't handle non-serializable objects, I think it would be better
>> to make it clear that non-serializable objects have to go in the
>> transient store.
>
>
> It is a serious backward incompatible change in contract. It might be
> better if general store simply passes non serializable objects to the
> transient store. Even better is fixing these new buggy stores. At the
> very least, this can be fixed in Cocoon itself - by wrapping objects
> into serializable holder.
Wow, a serializable holder? How can you do that when the wrapped objects
are intrinsically not serializable? Or is it just for the serialization
error to appear later, internally in the store, when the object is
swapped to the filesystem?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> The transient store is meant as a cache for objects that aren't
>>> serializable, whereas the regular store has a memory front-end and
>>> some persistent filesystem swap, and therefore can only accept
>>> serializable objects.
>>
>>
>> Not true. Regular store must accept all objects. See also [1].
>>
>> Vadim
>>
>> [1] http://cocoon.apache.org/2.1/installing/updating.html#Store
>
>
> Hmm... although the old implementation *may* have been able to accept
> non-serializable objects, it has AFAIK never formally be defined in the
> general store contract,
So now you will blame this bug on incomplete javadoc, huh? :-)
> and this is why we also have the transient store role.
No, that's not necessarily the right conclusion. I say we have transient store
for objects which should not - or even must not! - be persisted across system
restarts - even if they are serializable!
> Considering the current issues with the newer cache systems we use (that
> integrate both memory front-end and persistent swap)
It does not mean that they are better, though. Even MRUMemoryStore is more
efficient.
> and can't handle
> non-serializable objects, I think it would be better to make it clear
> that non-serializable objects have to go in the transient store.
It is a serious backward incompatible change in contract. It might be better if
general store simply passes non serializable objects to the transient store.
Even better is fixing these new buggy stores. At the very least, this can be
fixed in Cocoon itself - by wrapping objects into serializable holder.
Vadim
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> The transient store is meant as a cache for objects that aren't
>> serializable, whereas the regular store has a memory front-end and
>> some persistent filesystem swap, and therefore can only accept
>> serializable objects.
>
>
> Not true. Regular store must accept all objects. See also [1].
>
> Vadim
>
> [1] http://cocoon.apache.org/2.1/installing/updating.html#Store
Hmm... although the old implementation *may* have been able to accept
non-serializable objects, it has AFAIK never formally be defined in the
general store contract, and this is why we also have the transient store
role.
Considering the current issues with the newer cache systems we use (that
integrate both memory front-end and persistent swap) and can't handle
non-serializable objects, I think it would be better to make it clear
that non-serializable objects have to go in the transient store.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> The transient store is meant as a cache for objects that aren't
> serializable, whereas the regular store has a memory front-end and some
> persistent filesystem swap, and therefore can only accept serializable
> objects.
Not true. Regular store must accept all objects. See also [1].
Vadim
[1] http://cocoon.apache.org/2.1/installing/updating.html#Store
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Sylvain Wallez wrote:
>
>> Leszek Gawron wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Leszek Gawron wrote:
>>>>
>>>>> I think I have to switch to transient store because
>>>>> at least for now jxtg template is not serializable.
>>>>
>>>>
>>>> Is there a reason not to use transient store for jxtg?
>>>
>>>
>>> none .. but I thought it is better to use a "store" instead of
>>> explicit "transient store". What I did not know was that when using
>>> Store one had to put only serializable objects in it.
Well it's better to use a store which is more appropriate. If it is faster to
re-create something from original source than load it back from file system
store, it is obvious that transient store is the best.
>> The transient store is meant as a cache for objects that aren't
>> serializable, whereas the regular store has a memory front-end and
>> some persistent filesystem swap, and therefore can only accept
>> serializable objects.
>>
>
> got that now. I had a crazy idea that regular store can store all
> objects and is able to overflow to disk for those objects which support
> it - serializable.
It's not a crazy idea - that's how it should work. General store must accept any
kind of objects. Default implementation still does work properly. Newer
implementations are buggy. This is mentioned on the "known issues" page.
Vadim
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Reinhard Poetz wrote:
>>>>
>>>>> lgawron@apache.org wrote:
>>>>>
>>>>>> Author: lgawron
>>>>>> Date: Sun May 8 14:23:28 2005
>>>>>> New Revision: 169169
>>>>>>
>>>>>> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
>>>>>> Log:
>>>>>> JXTG uses cocoon store
>>>>>>
>>>>>> Modified:
>>>>>>
>>>>>> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> could this be the reason for the following exception?
>>>>>
>>>>> java.lang.ClassCastException
>>>>> at
>>>>> org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
>>>>>
>>>>> at
>>>>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
>>>>>
>>>>> at
>>>>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
>>>>>
>>>>> at
>>>>> org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yes. I did not get it on my test case as I was using other store
>>>> implementation. I think I have to switch to transient store because
>>>> at least for now jxtg template is not serializable.
>>>
>>>
>>>
>>> Is there a reason not to use transient store for jxtg?
>>
>>
>> none .. but I thought it is better to use a "store" instead of
>> explicit "transient store". What I did not know was that when using
>> Store one had to put only serializable objects in it.
>
>
>
> The transient store is meant as a cache for objects that aren't
> serializable, whereas the regular store has a memory front-end and some
> persistent filesystem swap, and therefore can only accept serializable
> objects.
>
> Sylvain
>
got that now. I had a crazy idea that regular store can store all
objects and is able to overflow to disk for those objects which support
it - serializable.
--
Leszek Gawron lgawron@mobilebox.pl
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: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Vadim Gritsenko wrote:
>
>> Leszek Gawron wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> lgawron@apache.org wrote:
>>>>
>>>>> Author: lgawron
>>>>> Date: Sun May 8 14:23:28 2005
>>>>> New Revision: 169169
>>>>>
>>>>> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
>>>>> Log:
>>>>> JXTG uses cocoon store
>>>>>
>>>>> Modified:
>>>>>
>>>>> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> could this be the reason for the following exception?
>>>>
>>>> java.lang.ClassCastException
>>>> at
>>>> org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
>>>>
>>>> at
>>>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
>>>>
>>>> at
>>>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
>>>>
>>>> at
>>>> org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yes. I did not get it on my test case as I was using other store
>>> implementation. I think I have to switch to transient store because
>>> at least for now jxtg template is not serializable.
>>
>>
>> Is there a reason not to use transient store for jxtg?
>
> none .. but I thought it is better to use a "store" instead of
> explicit "transient store". What I did not know was that when using
> Store one had to put only serializable objects in it.
The transient store is meant as a cache for objects that aren't
serializable, whereas the regular store has a memory front-end and some
persistent filesystem swap, and therefore can only accept serializable
objects.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Leszek Gawron wrote:
>
>> Reinhard Poetz wrote:
>>
>>> lgawron@apache.org wrote:
>>>
>>>> Author: lgawron
>>>> Date: Sun May 8 14:23:28 2005
>>>> New Revision: 169169
>>>>
>>>> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
>>>> Log:
>>>> JXTG uses cocoon store
>>>>
>>>> Modified:
>>>>
>>>> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
>>>
>>>
>>>
>>>
>>> could this be the reason for the following exception?
>>>
>>> java.lang.ClassCastException
>>> at
>>> org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
>>>
>>> at
>>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
>>>
>>> at
>>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
>>>
>>> at
>>> org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
>>
>>
>>
>>
>> Yes. I did not get it on my test case as I was using other store
>> implementation. I think I have to switch to transient store because at
>> least for now jxtg template is not serializable.
>
>
> Is there a reason not to use transient store for jxtg?
none .. but I thought it is better to use a "store" instead of explicit
"transient store". What I did not know was that when using Store one had
to put only serializable objects in it.
--
Leszek Gawron lgawron@mobilebox.pl
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: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> lgawron@apache.org wrote:
>>
>>> Author: lgawron
>>> Date: Sun May 8 14:23:28 2005
>>> New Revision: 169169
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
>>> Log:
>>> JXTG uses cocoon store
>>>
>>> Modified:
>>>
>>> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
>>
>>
>> could this be the reason for the following exception?
>>
>> java.lang.ClassCastException
>> at
>> org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
>>
>> at
>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
>>
>> at
>> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
>>
>> at
>> org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
>
>
> Yes. I did not get it on my test case as I was using other store
> implementation. I think I have to switch to transient store because at
> least for now jxtg template is not serializable.
Is there a reason not to use transient store for jxtg?
Vadim
Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> lgawron@apache.org wrote:
>
>> Author: lgawron
>> Date: Sun May 8 14:23:28 2005
>> New Revision: 169169
>>
>> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
>> Log:
>> JXTG uses cocoon store
>>
>> Modified:
>>
>> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
>>
>
>
> could this be the reason for the following exception?
>
> java.lang.ClassCastException
> at
> org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
>
> at
> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
>
> at
> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
>
> at
> org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
Yes. I did not get it on my test case as I was using other store
implementation. I think I have to switch to transient store because at
least for now jxtg template is not serializable.
--
Leszek Gawron lgawron@mobilebox.pl
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: NPE in JXTemplate
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> I am not able to diagnose it properly. Sylvain, could you help?
removing RedundantNamespacesFilter from:
> public void performGeneration(Event startEvent, Event endEvent)
> throws SAXException {
> XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(
> new RedundantNamespacesFilter(this.xmlConsumer));
> ((Map) expressionContext.get("cocoon")).put("consumer", consumer);
> Invoker.execute(consumer, this.expressionContext, new ExecutionContext(
> this.definitions, this.scriptManager), null, startEvent, null);
> }
renders page properly. Still this is not a valid solution.
--
Leszek Gawron lgawron@mobilebox.pl
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: NPE in JXTemplate
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Leszek Gawron wrote:
>>
>>> fixed. thanks for reporting.
>>
>>
>>
>> thanks for fixing it!
>>
>> in the meantime I found another problem :-( in
>> http://localhost:8888/samples/blocks/forms/form2simpleXML.flow when I
>> want to show the form as XML:
>>
>> java.lang.NullPointerException
>> at
>> org.apache.cocoon.components.expression.jxpath.JXPathExpression.setProperty(JXPathExpression.java:99)
>>
>> at
>> org.apache.cocoon.template.jxtg.expression.JXTExpression.setLenient(JXTExpression.java:257)
>>
>> at
>> org.apache.cocoon.template.jxtg.instruction.StartOut.<init>(StartOut.java:51)
>
>
> I fixed the problem with expression leniency - we've just lost a null
> check during the refactoring.
>
> Bad news is that there is still a NPE in this example:
>
>> java.lang.NullPointerException
>> at
>> org.apache.xml.serializer.NamespaceMappings.pushNamespace(NamespaceMappings.java:208)
>>
>> at
>> org.apache.xml.serializer.ToStream.startPrefixMapping(ToStream.java:2106)
>> at
>> org.apache.xml.serializer.ToStream.startPrefixMapping(ToStream.java:2056)
>> at
>> org.apache.xalan.transformer.TransformerIdentityImpl.startPrefixMapping(TransformerIdentityImpl.java:932)
>>
>> at
>> org.apache.cocoon.xml.AbstractXMLPipe.startPrefixMapping(AbstractXMLPipe.java:66)
>>
>> at
>> org.apache.cocoon.xml.AbstractXMLPipe.startPrefixMapping(AbstractXMLPipe.java:66)
>>
>> at
>> org.apache.cocoon.xml.RedundantNamespacesFilter.startElement(RedundantNamespacesFilter.java:69)
>>
>> at
>> org.apache.cocoon.xml.AttributeAwareXMLConsumerImpl$StartElement.send(AttributeAwareXMLConsumerImpl.java:187)
>>
>> at
>> org.apache.cocoon.xml.AttributeAwareXMLConsumerImpl.playCache(AttributeAwareXMLConsumerImpl.java:225)
>>
>> at
>> org.apache.cocoon.xml.AttributeAwareXMLConsumerImpl.startElement(AttributeAwareXMLConsumerImpl.java:71)
>>
>> at
>> org.apache.cocoon.xml.IncludeXMLConsumer.startElement(IncludeXMLConsumer.java:162)
>>
>> at org.apache.cocoon.forms.util.XMLAdapter.start(XMLAdapter.java:363)
>> at
>> org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:322)
>> at
>> org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:305)
>> at
>> org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:347)
>> at
>> org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:305)
>> at org.apache.cocoon.forms.util.XMLAdapter.toSAX(XMLAdapter.java:294)
>> at
>> org.apache.cocoon.template.jxtg.script.Invoker.executeNode(Invoker.java:97)
>>
>> at
>> org.apache.cocoon.template.jxtg.instruction.StartOut.execute(StartOut.java:66)
>>
>> at
>> org.apache.cocoon.template.jxtg.script.Invoker.execute(Invoker.java:72)
>> at
>> org.apache.cocoon.template.jxtg.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:122)
>>
>> at
>> org.apache.cocoon.template.jxtg.JXTemplateGenerator.generate(JXTemplateGenerator.java:111)
>>
>
>
> I'm checking that out right now.
>
I am not able to diagnose it properly. Sylvain, could you help?
--
Leszek Gawron lgawron@mobilebox.pl
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: NPE in JXTemplate
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> fixed. thanks for reporting.
>
>
> thanks for fixing it!
>
> in the meantime I found another problem :-( in
> http://localhost:8888/samples/blocks/forms/form2simpleXML.flow when I
> want to show the form as XML:
>
> java.lang.NullPointerException
> at
> org.apache.cocoon.components.expression.jxpath.JXPathExpression.setProperty(JXPathExpression.java:99)
>
> at
> org.apache.cocoon.template.jxtg.expression.JXTExpression.setLenient(JXTExpression.java:257)
>
> at
> org.apache.cocoon.template.jxtg.instruction.StartOut.<init>(StartOut.java:51)
I fixed the problem with expression leniency - we've just lost a null
check during the refactoring.
Bad news is that there is still a NPE in this example:
> java.lang.NullPointerException
> at org.apache.xml.serializer.NamespaceMappings.pushNamespace(NamespaceMappings.java:208)
> at org.apache.xml.serializer.ToStream.startPrefixMapping(ToStream.java:2106)
> at org.apache.xml.serializer.ToStream.startPrefixMapping(ToStream.java:2056)
> at org.apache.xalan.transformer.TransformerIdentityImpl.startPrefixMapping(TransformerIdentityImpl.java:932)
> at org.apache.cocoon.xml.AbstractXMLPipe.startPrefixMapping(AbstractXMLPipe.java:66)
> at org.apache.cocoon.xml.AbstractXMLPipe.startPrefixMapping(AbstractXMLPipe.java:66)
> at org.apache.cocoon.xml.RedundantNamespacesFilter.startElement(RedundantNamespacesFilter.java:69)
> at org.apache.cocoon.xml.AttributeAwareXMLConsumerImpl$StartElement.send(AttributeAwareXMLConsumerImpl.java:187)
> at org.apache.cocoon.xml.AttributeAwareXMLConsumerImpl.playCache(AttributeAwareXMLConsumerImpl.java:225)
> at org.apache.cocoon.xml.AttributeAwareXMLConsumerImpl.startElement(AttributeAwareXMLConsumerImpl.java:71)
> at org.apache.cocoon.xml.IncludeXMLConsumer.startElement(IncludeXMLConsumer.java:162)
> at org.apache.cocoon.forms.util.XMLAdapter.start(XMLAdapter.java:363)
> at org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:322)
> at org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:305)
> at org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:347)
> at org.apache.cocoon.forms.util.XMLAdapter.generateSAX(XMLAdapter.java:305)
> at org.apache.cocoon.forms.util.XMLAdapter.toSAX(XMLAdapter.java:294)
> at org.apache.cocoon.template.jxtg.script.Invoker.executeNode(Invoker.java:97)
> at org.apache.cocoon.template.jxtg.instruction.StartOut.execute(StartOut.java:66)
> at org.apache.cocoon.template.jxtg.script.Invoker.execute(Invoker.java:72)
> at org.apache.cocoon.template.jxtg.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:122)
> at org.apache.cocoon.template.jxtg.JXTemplateGenerator.generate(JXTemplateGenerator.java:111)
I'm checking that out right now.
--
Leszek Gawron lgawron@mobilebox.pl
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
NPE in JXTemplate
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> fixed. thanks for reporting.
thanks for fixing it!
in the meantime I found another problem :-( in
http://localhost:8888/samples/blocks/forms/form2simpleXML.flow when I want to
show the form as XML:
java.lang.NullPointerException
at
org.apache.cocoon.components.expression.jxpath.JXPathExpression.setProperty(JXPathExpression.java:99)
at
org.apache.cocoon.template.jxtg.expression.JXTExpression.setLenient(JXTExpression.java:257)
at org.apache.cocoon.template.jxtg.instruction.StartOut.<init>(StartOut.java:51)
--
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: r169169 - in /cocoon/blocks/unsupported/template/trunk:
java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> lgawron@apache.org wrote:
>
>> Author: lgawron
>> Date: Sun May 8 14:23:28 2005
>> New Revision: 169169
>>
>> URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
>> Log:
>> JXTG uses cocoon store
>>
>> Modified:
>>
>> cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
>>
>
>
> could this be the reason for the following exception?
>
> java.lang.ClassCastException
> at
> org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
>
> at
> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
>
> at
> org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
>
> at
> org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)
>
>
>
fixed. thanks for reporting.
--
Leszek Gawron lgawron@mobilebox.pl
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