You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Gary Larsen <ga...@envisn.com> on 2007/01/19 18:58:06 UTC
Problem in custom Transformer (migrating to 2.1.10)
I'm upgrading Cocoon from 2.1.7 to 2.1.10 and having a problem with a custom
Transformer.
This is the error returned in the browser (with XML serializer after the
transformer):
XML Parsing Error: no element found
Location: http://notebook1:8080/netvisn/
Line Number 1, Column 1:
The transformer is processing the sax events but it seems that nothing is
being delivered back to the pipeline. This is the class declaration:
public class NamespaceDecoratorTransformer extends AbstractTransformer
Is it necessary to Implement Serviceable, Configurable, Disposable?
Thanks for any advice,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Problem in custom Transformer (migrating to 2.1.10)
Posted by "Steven D. Majewski" <sd...@virginia.edu>.
On Jan 19, 2007, at 5:15 PM, Joerg Heinicke wrote:
>
>> When I put LogTransformer before the custom transformer I can see
>> logging,
>> but when it is after the custom transformer there is no logging.
>> I think
>> this shows there something wrong with my transformer.
>> Perhaps it was too simple, but acceptable in 2.1.7. Here's the
>> setup():
>
> I don't think it has something to do with the setup. There should
> not have been changed anything critical. You might have a look at
> the changes though (http://cocoon.apache.org/2.1/changes.html) but
> that's really a huge list between 2.1.7 and 2.1.10.
>
> More likely such problems are caused by the updates of the XML
> libraries.
You might try the more gentle upgrade from 2.1.7 to 2.1.9 and see
what happens.
I had no problems upgrading from 2.1.7 to 2.1.8 to 2.1.9.
I just loaded 2.1.10 on my laptop the other day and noticed some
broken pages,
but I haven't had time to look for the problem.
But I was happy to see that I could install the new version along
side the
old one in tomcat, and with the site mounted in ../../mount-table.xml,
I could just change the cocoon in the URL to cocoon-2.1.10 and look at
the same pages served up by either version. Maybe that would be some
help
in debugging.
-- Steve Majewski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Problem in custom Transformer (migrating to 2.1.10)
Posted by Gary Larsen <ga...@envisn.com>.
>
> What happens with the decorator? Somewhere it must be set as new content
> handler. Otherwise it would not do anything (also no harm). It would be
> interesting to see if the sax event methods gets called in your
> transformer and later in the decorator. Somewhere they must get lost
> before reaching super.contentHandler.
>
> Jörg
public SaxDecorator(ContentHandler contentHandler) {
this.contentHandler = contentHandler;
}
>From the application log I can see events are processed in the transformer
and decorator.
DEBUG 64406 [http-8080-Processor25] SaxDecorator: startDocument called
DEBUG 64406 [http-8080-Processor25] NamespaceDecoratorTransformer:
startDocument() called
DEBUG 64547 [http-8080-Processor25] NamespaceDecoratorTransformer:
startElement() called - uri: loc:userSession raw:userSession
DEBUG 64547 [http-8080-Processor25] SaxDecorator: startElement -
localName:userSession
DEBUG 64547 [http-8080-Processor25] NamespaceDecoratorTransformer:
startElement() called - uri: loc:adminLoggedOn raw:adminLoggedOn
DEBUG 64547 [http-8080-Processor25] SaxDecorator: startElement -
localName:adminLoggedOn
DEBUG 64562 [http-8080-Processor25] NamespaceDecoratorTransformer:
startElement() called - uri: loc:appStatus raw:appStatus
DEBUG 64562 [http-8080-Processor25] SaxDecorator: startElement -
localName:appStatus
I guess I'll look through the change Cocoon change log again. It's just a
mystery why this works in 2.1.7. The reason for upgrading was to use the
new XML jars so maybe hat has something to do with it.
Thanks again,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Problem in custom Transformer (migrating to 2.1.10)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.01.2007 23:03, Gary Larsen wrote:
> When I put LogTransformer before the custom transformer I can see logging,
> but when it is after the custom transformer there is no logging. I think
> this shows there something wrong with my transformer.
>
> Perhaps it was too simple, but acceptable in 2.1.7. Here's the setup():
I don't think it has something to do with the setup. There should not
have been changed anything critical. You might have a look at the
changes though (http://cocoon.apache.org/2.1/changes.html) but that's
really a huge list between 2.1.7 and 2.1.10.
More likely such problems are caused by the updates of the XML libraries.
> public void setup(SourceResolver resolver, Map objectModel, String src,
> Parameters par)
> throws ProcessingException, SAXException, IOException {
>
> // Set up the decorator to forward calls to
> if (super.contentHandler != null) {
> this.decorator = new SaxDecorator(super.contentHandler);
> }
> }
>
>
> SaxDecorator is a java content handler which adds uri's to the betwixt
> generated XML which is processing the sax events.
What happens with the decorator? Somewhere it must be set as new content
handler. Otherwise it would not do anything (also no harm). It would be
interesting to see if the sax event methods gets called in your
transformer and later in the decorator. Somewhere they must get lost
before reaching super.contentHandler.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Problem in custom Transformer (migrating to 2.1.10)
Posted by Gary Larsen <ga...@envisn.com>.
> > Initially I wasn't using an updated cocoon.xconf, but the problem still
> > exists. Any ideas how to debug this?
>
> There is a transformer that only logs the sax events: LogTransformer.
>
Thanks for your help.
When I put LogTransformer before the custom transformer I can see logging,
but when it is after the custom transformer there is no logging. I think
this shows there something wrong with my transformer.
Perhaps it was too simple, but acceptable in 2.1.7. Here's the setup():
public void setup(SourceResolver resolver, Map objectModel, String src,
Parameters par)
throws ProcessingException, SAXException, IOException {
// Set up the decorator to forward calls to
if (super.contentHandler != null) {
this.decorator = new SaxDecorator(super.contentHandler);
}
}
SaxDecorator is a java content handler which adds uri's to the betwixt
generated XML which is processing the sax events.
Anything look missing here?
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Problem in custom Transformer (migrating to 2.1.10)
Posted by Gary Larsen <ga...@envisn.com>.
I was able to get the transformer working by cutting out the java content
handler.
Thanks for your advice with this.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Problem in custom Transformer (migrating to 2.1.10)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.01.2007 22:12, Gary Larsen wrote:
>>> XML Parsing Error: no element found
>>> Location: http://notebook1:8080/netvisn/
>>> Line Number 1, Column 1:
>>>
>>> The transformer is processing the sax events but it seems that nothing
>> is
>>> being delivered back to the pipeline.
>> It's a parsing error, so I'd guess it's not the transformer's culprit.
>
> But the parsing error is 'no element found' so it looks like the transformer
> is not sending sax events back to the pipeline.
In theory in a Cocoon pipeline there are only sax events and nothing
gets reparsed. That's why I thought it can't be the transformer. Even
when it does not send sax events you should not get any parsing error.
Actually it might depend on what the transformer is doing.
> Initially I wasn't using an updated cocoon.xconf, but the problem still
> exists. Any ideas how to debug this?
There is a transformer that only logs the sax events: LogTransformer.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Problem in custom Transformer (migrating to 2.1.10)
Posted by Gary Larsen <ga...@envisn.com>.
>
> > XML Parsing Error: no element found
> > Location: http://notebook1:8080/netvisn/
> > Line Number 1, Column 1:
> >
> > The transformer is processing the sax events but it seems that nothing
> is
> > being delivered back to the pipeline.
>
> It's a parsing error, so I'd guess it's not the transformer's culprit.
>
But the parsing error is 'no element found' so it looks like the transformer
is not sending sax events back to the pipeline.
When I take the transformer out of the pipeline I can see the generated XML.
Initially I wasn't using an updated cocoon.xconf, but the problem still
exists. Any ideas how to debug this?
Thanks,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Problem in custom Transformer (migrating to 2.1.10)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.01.2007 18:58, Gary Larsen wrote:
> XML Parsing Error: no element found
> Location: http://notebook1:8080/netvisn/
> Line Number 1, Column 1:
>
> The transformer is processing the sax events but it seems that nothing is
> being delivered back to the pipeline.
It's a parsing error, so I'd guess it's not the transformer's culprit.
> Is it necessary to Implement Serviceable, Configurable, Disposable?
No.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org