Re: TreeProcessor:BUG

2003-06-25 Thread Klaus Bertram 
Hi Sylvian,

it works now

I checked out and build the new cvs and test it.

test with:
 cached and noncached
 cached and noncached
Klaus

Klaus Bertram wrote:
Klaus Bertram wrote:

Sylvain Wallez wrote:

Klaus Bertram wrote:

Hi Joerg

yes I found it by debugging an action where the breakpoint was 
stoped twice.

So I wrote a small test sidemap with an xsp side and database actions

By request the map:aggregation match, an action in map:part add a 
row to the databse and then the xsp read the table entrys.
The browser show the insertred row, but the database had 2 new rows
The sitemap.log shows the complete match handling twice

After that I test the match form the part direkt with a request and 
it works. (1 row added)

When needed I can send you my test sides.




Some questions to help us track the problem :
- do you use a caching pipeline - if yes, does it still happen if you 
use a non-caching pipeline ?


Yes I had the same idea and checked both, same result

Oh, the called map:part match is in different pipeline than the 
map:aggregation
and I checked

and

but I tryed not the match in the same pipeline
I check it in the afternoon


checked with same result

- can you provide us the two stack trace when you hit the breakpoint ?

Re: TreeProcessor:BUG

2003-06-18 Thread Klaus Bertram 
Klaus Bertram wrote:
Sylvain Wallez wrote:

Klaus Bertram wrote:

Hi Joerg

yes I found it by debugging an action where the breakpoint was stoped 
twice.

So I wrote a small test sidemap with an xsp side and database actions

By request the map:aggregation match, an action in map:part add a row 
to the databse and then the xsp read the table entrys.
The browser show the insertred row, but the database had 2 new rows
The sitemap.log shows the complete match handling twice

After that I test the match form the part direkt with a request and 
it works. (1 row added)

When needed I can send you my test sides.




Some questions to help us track the problem :
- do you use a caching pipeline - if yes, does it still happen if you 
use a non-caching pipeline ?
Yes I had the same idea and checked both, same result

Oh, the called map:part match is in different pipeline than the 
map:aggregation
and I checked

and

but I tryed not the match in the same pipeline
I check it in the afternoon
checked with same result

- can you provide us the two stack trace when you hit the breakpoint ?
here are the diff from the stack
(the attached file includes the complete stack)
the first are invoked by:
TreeProcessor.process(Environment) line: 307
the second by:
TreeProcessor.process(Environment) line: 309

>SitemapSource.(ComponentManager, String, Map, Logger) line: 224
>SitemapSourceFactory.getSource(String, Map) line: 99
>SourceResolverImpl.resolveURI(String, String, Map) line: 247
>CocoonComponentManager.resolveURI(String, String, Map) line: 450
>HttpEnvironment(AbstractEnvironment).resolveURI(String, String, Map) 
line: 513
>HttpEnvironment(AbstractEnvironment).resolveURI(String) line: 500
>ContentAggregator.setup(SourceResolver, Map, String, Parameters) line: 322
>NonCachingProcessingPipeline(AbstractProcessingPipeline).setupPipeline(Environment) line: 378
>NonCachingProcessingPipeline(AbstractProcessingPipeline).preparePipeline(Environment) line: 505
>NonCachingProcessingPipeline(AbstractProcessingPipeline).process(Environment) line: 467
>SerializeNode.invoke(Environment, InvokeContext) line: 150
>PreparableMatchNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], >Environment, InvokeContext, String, Map) line: 84
>PreparableMatchNode.invoke(Environment, InvokeContext) line: 164
>PipelineNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], >Environment, InvokeContext) line: 108
>PipelineNode.invoke(Environment, InvokeContext) line: 162
>PipelinesNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], >Environment, InvokeContext) line: 108
>PipelinesNode.invoke(Environment, InvokeContext) line: 162
>TreeProcessor.process(Environment, InvokeContext) line: 325
>TreeProcessor.process(Environment) line: 307


>SitemapSource.refresh() line: 345
>SitemapSource.getURI() line: 298
>SitemapSourceFactory.release(Source) line: 111
>SourceResolverImpl.release(Source) line: 308
>CocoonComponentManager.release(Source) line: 457
>HttpEnvironment(AbstractEnvironment).release(Source) line: 521
>ContentAggregator.recycle() line: 303
>ResourceLimitingPool.put(Poolable) line: 438
>PoolableComponentHandler.doPut(Component) line: 245
>PoolableComponentHandler(ComponentHandler).put(Component) line: 452
>ComponentsSelector(ExcaliburComponentSelector).release(Component) 
line: 336
>ComponentsSelector(ExtendedComponentSelector).release(Component) line: 316
>NonCachingProcessingPipeline(AbstractProcessingPipeline).recycle() 
line: 637
>ResourceLimitingPool.put(Poolable) line: 438
>PoolableComponentHandler.doPut(Component) line: 245
>PoolableComponentHandler(ComponentHandler).put(Component) line: 452
>ComponentsSelector(ExcaliburComponentSelector).release(Component) 
line: 336
>ComponentsSelector(ExtendedComponentSelector).release(Component) line: 316
>InvokeContext.dispose() line: 310
>TreeProcessor.process(Environment) line: 309


Thread [PoolThread-4] (Suspended (breakpoint at line 92 in DatabaseAddAction))
DatabaseAddAction.act(Redirector, SourceResolver, Map, String, Parameters) 
line: 92
ActTypeNode.invoke(Environment, InvokeContext) line: 133
ActTypeNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], 
Environment, InvokeContext, String, Map) line: 84
ActTypeNode.invoke(Environment, InvokeContext) line: 158
ActTypeNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], 
Environment, InvokeContext, String, Map) line: 84
ActTypeNode.invoke(Environment, InvokeContext) line: 158
ActTypeNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], 
Environment, InvokeContext, String, Map) line: 84
ActTypeNode.invoke(Environment, InvokeContext) line: 158

PreparableMatchNode(AbstractParentProcessingNode).invokeNodes(ProcessingNode[], 
Environment, InvokeContext, String, Map) line: 84
PreparableMatchNode.invoke(Environment, InvokeContext) line: 164
PipelineNode(AbstractParentProcessingNode).invokeNodes(Process

Re: TreeProcessor:BUG

2003-06-18 Thread Klaus Bertram 
Sylvain Wallez wrote:
Klaus Bertram wrote:

Hi Joerg

yes I found it by debugging an action where the breakpoint was stoped 
twice.

So I wrote a small test sidemap with an xsp side and database actions

By request the map:aggregation match, an action in map:part add a row 
to the databse and then the xsp read the table entrys.
The browser show the insertred row, but the database had 2 new rows
The sitemap.log shows the complete match handling twice

After that I test the match form the part direkt with a request and it 
works. (1 row added)

When needed I can send you my test sides.


Some questions to help us track the problem :
- do you use a caching pipeline 
- if yes, does it still happen if you use a non-caching pipeline ?
Yes I had the same idea and checked both, same result

Oh, the called map:part match is in different pipeline than the 
map:aggregation
and I checked

and

but I tryed not the match in the same pipeline
I check it in the afternoon
- can you provide us the two stack trace when you hit the breakpoint ?
I will do my best

Klaus
Thanks,
Sylvain

Re: TreeProcessor:BUG

2003-06-18 Thread Sylvain Wallez 
Klaus Bertram wrote:

Hi Joerg

yes I found it by debugging an action where the breakpoint was stoped 
twice.

So I wrote a small test sidemap with an xsp side and database actions

By request the map:aggregation match, an action in map:part add a row 
to the databse and then the xsp read the table entrys.
The browser show the insertred row, but the database had 2 new rows
The sitemap.log shows the complete match handling twice

After that I test the match form the part direkt with a request and it 
works. (1 row added)

When needed I can send you my test sides.


Some questions to help us track the problem :
- do you use a caching pipeline ?
- if yes, does it still happen if you use a non-caching pipeline ?
- can you provide us the two stack trace when you hit the breakpoint ?
Thanks,
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: TreeProcessor:BUG

2003-06-18 Thread Klaus Bertram 
Hi Joerg

yes I found it by debugging an action where the breakpoint was stoped twice.

So I wrote a small test sidemap with an xsp side and database actions

By request the map:aggregation match, an action in map:part add a row to 
the databse and then the xsp read the table entrys.
The browser show the insertred row, but the database had 2 new rows
The sitemap.log shows the complete match handling twice

After that I test the match form the part direkt with a request and it 
works. (1 row added)

When needed I can send you my test sides.

Klaus

Joerg Heinicke wrote:
Do you mean each map:part in an aggregation? Where do you take this from 
(debug?)?

Joerg

Klaus Bertram wrote:

Hi all,

the treeprocessor call an map:part src twice at one request.
The first generated map:part are used from the browser
(both Mozilla and IE6.0)
The sitemap log file show both generation processes
excuse but at the source i don't find the bug  :(

Klaus

Re: TreeProcessor:BUG

2003-06-17 Thread Joerg Heinicke 
Do you mean each map:part in an aggregation? Where do you take this from 
(debug?)?

Joerg

Klaus Bertram wrote:
Hi all,

the treeprocessor call an map:part src twice at one request.
The first generated map:part are used from the browser
(both Mozilla and IE6.0)
The sitemap log file show both generation processes
excuse but at the source i don't find the bug  :(

Klaus