Re: cocoon-xml-2.0.2 in dist?

INARIES > download directory [1]? Unless there is a reason to keep it there, I plan to > remove it. > > > Vadim > > [1] http://www.apache.org/dist/cocoon/BINARIES/ -- Carsten Ziegeler cziege...@apache.org

Re: Team List Updates

Thanks Reinhard! Carsten Reinhard Pötz wrote > On 01/13/2011 08:35 AM, Carsten Ziegeler wrote: >> Hi, >> >> it seems that the teamlists at: >> >> http://cocoon.apache.org/3.0/team-list.html >> http://cocoon.apache.org/team-list.html >> >> are o

Team List Updates

Hi, it seems that the teamlists at: http://cocoon.apache.org/3.0/team-list.html http://cocoon.apache.org/team-list.html are out of date and need some updates. It would be great if someone could send me to emeritus. Thanks! Regards Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [jnet] Threading issues

same url handlers. With a simple ThreadLocal you don't get this. While having the same url handlers in the new thread is nice, it might create problems if the original thread executes before the newly started. But nevertheless this shouldn't result in concurrency problems as far as I ca

Re: [VOTE RESULT] Release cocoon-xml 2.0.2

Vadim Gritsenko wrote: > On Dec 22, 2009, at 2:09 AM, Carsten Ziegeler wrote: > >> Thanks for voting! I'll upload the artifacts asap. > > Hey Carsten, > > Were you able to upload it? All I could find is cocoon-xml-2.0.0 (and with > -source jars for some reason i

[jira] Assigned: (COCOON-2275) [PATCH] Fix for Portal block and block samples

[ https://issues.apache.org/jira/browse/COCOON-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned COCOON-2275: Assignee: Carsten Ziegeler > [PATCH] Fix for Portal block and block samp

[jira] Closed: (COCOON-2275) [PATCH] Fix for Portal block and block samples

[ https://issues.apache.org/jira/browse/COCOON-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2275. Resolution: Fixed Thanks for your patch, Klaus! I've applied it in revision 8

[VOTE RESULT] Release cocoon-xml 2.0.2

Hi, the vote to release cocoon-xml 2.0.2 passed successfully with four binding +1 votes from Felix Knecht, Thorsten Scherler, David Legg, and Reinhard Pötz and one non-binding vote from Carsten Ziegeler. No other votes have been cast. Thanks for voting! I'll upload the artifacts asap. Re

Re: [VOTE] Release cocoon-xml 2.0.2

Anyone else? We need two more binding votes. Regards Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [VOTE] Release cocoon-xml 2.0.2

+1 Regards Carsten -- Carsten Ziegeler cziege...@apache.org

[VOTE] Release cocoon-xml 2.0.2

http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.2/ Please cast your votes. Regards Carsten -- Carsten Ziegeler cziege...@apache.org

New release of the xml subproject

Hi, I just fixed COCOON-2274 (https://issues.apache.org/jira/browse/COCOON-2274) which adds the license and notice files into the jar and fixes some OSGi header information. I would like to do a new release. Any comments/objections? Regards Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Closed: (COCOON-2274) Include license info in the cocoon-xml bundle

[ https://issues.apache.org/jira/browse/COCOON-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2274. Resolution: Fixed > Include license info in the cocoon-xml bun

[jira] Updated: (COCOON-2274) Include license info in the cocoon-xml bundle

[ https://issues.apache.org/jira/browse/COCOON-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON-2274: - I've added the two files and also updated the header information in revision: 8

[jira] Assigned: (COCOON-2274) Include license info in the cocoon-xml bundle

[ https://issues.apache.org/jira/browse/COCOON-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned COCOON-2274: Assignee: Carsten Ziegeler > Include license info in the cocoon-xml bun

Re: [VOTE RESULT] Release Cocoon Serializers Charset and Block

Carsten Ziegeler wrote: > The vote to release > > Apache Cocoon Serializers Charsets 1.0.0 > and > Apache Cocoon Serializers Block 1.0.0 > > > passed successfully with six +1 votes from: > Carsten Ziegeler > Felix Knecht > Reinhard Pötz > David Legg &g

[VOTE RESULT] Release Cocoon Serializers Charset and Block

The vote to release Apache Cocoon Serializers Charsets 1.0.0 and Apache Cocoon Serializers Block 1.0.0 passed successfully with six +1 votes from: Carsten Ziegeler Felix Knecht Reinhard Pötz David Legg Thorsten Scherler Alfred Nathaniel I'll upload the artifacts asap. Thanks for v

Re: Admin rights for cocoon3 jira

y please. > If I did everything correctly it should work now Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [VOTE] Release Cocoon Serializers Charset and Block

he cocoon portal to include portlet output directly into the response without requiring to transform the html output to xhtml just to get it through the pipeline. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [VOTE] Release Cocoon Serializers Charset and Block

+1 Carsten -- Carsten Ziegeler cziege...@apache.org

[VOTE] Release Cocoon Serializers Charset and Block

/cocoon-serializers-impl/1.0.0/ The first artifact is a general purpose library with the basic code for the serializers. The block uses this lib to add some new serializers to Cocoon. Please cast your votes. Regards Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Releasing serializers block

Reinhard Pötz wrote > > Please try again and only use the 'release' profile (= don't use > 'daisy,localDocs,javadocs-script'). > > Let me know if that works for you. > Yes, thanks that works. I'll start the vote soon :) Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Releasing serializers block

Reinhard Pötz wrote: > Carsten Ziegeler wrote: >> During the release process I get errors as these two dependencies are >> missing. >> >> >> Path to dependency: >> 1) org.daisycms:daisy-maven-plugin:maven-plugin:1.0.0-alpha-2 >>

Re: Releasing serializers block

) org.daisycms:daisy-maven-plugin:maven-plugin:1.0.0-alpha-2 2) org.daisycms:daisy-java-adapter:jar:1.5.1.0-alpha-2 3) org.apache.avalon.framework:avalon-framework-api:jar:4.3 Any ideas? Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Releasing serializers block

Reinhard Pötz wrote: > Carsten Ziegeler wrote: >> Hi, >> >> I would like to release the 2.2 version of the serializers block >> (consisting of two modules). >> >> Is anything preventing us from releasing this? > > No I don't think so. After rer

Releasing serializers block

Hi, I would like to release the 2.2 version of the serializers block (consisting of two modules). Is anything preventing us from releasing this? What's the procedure to release the block? Regards Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [2.2] ThreadLocal use in PoolableProxyHandler

w PoolableProxyHandler(this)); > } > > [2] > http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java > > -- Carsten Ziegeler cziege...@apache.org

Re: [2.2] ThreadLocal use in PoolableProxyHandler

Alexander Daniel wrote: > On 03.07.2009, at 10:41, Carsten Ziegeler wrote: > >> Alexander Daniel wrote: >>> Does somebody know why ThreadLocal is used in PoolableProxyHandler [1] >>> for the componentHolder in Cocoon 2.2? >>> >> Sure :) >> &g

Re: [2.2] ThreadLocal use in PoolableProxyHandler

lableFactoryBean.java > > -- Carsten Ziegeler cziege...@apache.org

[jira] Closed: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)

[ https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2071. Resolution: Won't Fix This has been open for a long time with no further action, so

[jira] Closed: (COCOON-1959) o.a.c.environment.Request'setParameter()

[ https://issues.apache.org/jira/browse/COCOON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-1959. Resolution: Won't Fix This one has been open for a long time, so I think it's o

Re: [C3] Refactoring the SAX module

Carsten Ziegeler wrote: > > I'll go through the code and try to find the place. > Ok , I couldn't find them anymore :( Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [C3] Refactoring the SAX module

Reinhard Pötz wrote: > > in your original mail you mentioned that your patch also fixed some > bugs. Do you remember what it was? > not concrete :( I'll go through the code and try to find the place. Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Closed: (COCOON3-22) Remove XMLConsumer interface

[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON3-22. --- Resolution: Won't Fix > Remove XMLConsumer i

Re: [C3] Refactoring the SAX module

Hi, I'll drop my suggestions and close the bug. Thanks for the feedback Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Updated: (COCOON3-22) Remove XMLConsumer interface

[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-22: Attachment: cocoon-stax.patch > Remove XMLConsumer interf

Re: [C3] Refactoring the SAX module

self) have a opinion and I guess it is based on/influenced by our experience and we are somehow stuck in our thinking. So it would be great if others could voice their opinion. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Commented: (COCOON3-22) Remove XMLConsumer interface

[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674718#action_12674718 ] Carsten Ziegeler commented on COCOON3-22: - Ah yes, it doesn't cover

Re: [C3] Refactoring the SAX module

SAXPipe thingy)? Yes, it's just ContentHandler - and this alone is imho really an improvement. But once you do this, you see that you can simplify other things and that's what the patch is all about. Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Updated: (COCOON3-22) Remove XMLConsumer interface

[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-22: Attachment: cocoon-3.patch Proposed patch > Remove XMLConsumer interf

Re: [C3] Refactoring the SAX module

f for years, but it took me some time to find out what is there and why and how things work. Maybe it's me getting old, but I hope not :) So why not simply having just the stuff there which is really needed? Try to explain the difference between the existing abstract classes/interfaces :) HTH Carsten -- Carsten Ziegeler cziege...@apache.org

[C3] Refactoring the SAX module

o, what do you think? Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Documentation System [was: Spring Configurator Docs]

t; I think there are too many steps involved in getting something out - adding chapters is really a pain; and as we see above we're loosing content and nearly noone notices this and nearly noone knows how to restore this. And still I think the resulting urls are really not pretty urls, I really would prefer something like http://cocoon.apache.org/spring-configurator/index.html But again, maybe it's just me. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Documentation System [was: Spring Configurator Docs]

.0/1329_1_1.html which allows me to just download the configurator, but I still can't see the docs :) Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Documentation System [was: Spring Configurator Docs]

r Apache projects I'm working on, we're using Confluence which has the important advantage that the installation is supported by infra. It would be great if someone could find out why the docs for the spring configurator are not linked anymore on our site (or I'm still too dumb to find the links). Thanks Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Spring Configurator Docs

The menu only has a few links to get started but there is no > clear way of navigating to the other pages... > Hmm, yes I agree and I had the same feeling when trying to edit/update docs back in the good old days :( May be it's time to use something like confluence for C3 C

Re: Spring Configurator Docs

pache.org/subprojects/configuration/1.0/1329_1_1.html without any pointers to the docs. Carsten > > Cheers > Nagaraju Chittathuru > > -Original Message- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: Thursday, February 12, 2009 1:35 PM > To: Cocoon-De

Spring Configurator Docs

Hi, can someone point me to our online docs of the spring configurator? I wasn't able to find it.. :( Thanks Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Cocoon-xml dependency on xml-apis

Reinhard Pötz wrote: > Does cocoon-xml still need a dependency on xml-apis? AFAIU with Java 5 > the Jaxp API is part of the JDK and we don't need to add it ourselves, > do we? > Yes, you're right - I removed it in trunk. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [VOTE RESULT] Release cocoon-xml 2.0.0 [was Re: [VOTE] Release cocoon-xml 2.0.0]

Reinhard Pötz wrote: > Carsten Ziegeler wrote: >> The vote to release cocoon-xml 2.0.0 finished successfully with three >> binding +1 votes (from David Legg, Reinhard Pötz, and Carsten Ziegeler) >> and one non binding +1 vote from Andreas Pieber. >> No other votes were

Re: [VOTE] Release cocoon-xml 2.0.0

bout the various 'protected' fields like the ones in > SAXBuffer.java or DOMBuilder.java etc. It would be all too easy to > write code that accidentally abused these fields. I suppose this could > be fixed later by making them private. Yes, that's right. > Here&#

[VOTE RESULT] Release cocoon-xml 2.0.0 [was Re: [VOTE] Release cocoon-xml 2.0.0]

The vote to release cocoon-xml 2.0.0 finished successfully with three binding +1 votes (from David Legg, Reinhard Pötz, and Carsten Ziegeler) and one non binding +1 vote from Andreas Pieber. No other votes were cast. Thanks for your support! I'll continue with the release upload asap. Ca

Re: [VOTE] Release cocoon-xml 2.0.0

only binding votes into account; binding votes are votes from the PMC members. HTH Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [VOTE] Release cocoon-xml 2.0.0

Hi, has anyone else time to review the release? So far we only have two votes. Thanks Carsten Carsten Ziegeler wrote: > Hi, > > I've assembled a first release candidate for the new xml sub project > containing useful stuff for dom and sax handling. The module is small > a

Re: [VOTE] Release cocoon-xml 2.0.0

Reinhard Pötz wrote: > Carsten Ziegeler wrote: >> Hi, >> >> I've assembled a first release candidate for the new xml sub project >> containing useful stuff for dom and sax handling. The module is small >> and focused and could be used as a utility lib for

Re: [VOTE] Release cocoon-xml 2.0.0

+1 Carsten Carsten Ziegeler wrote: > Hi, > > I've assembled a first release candidate for the new xml sub project > containing useful stuff for dom and sax handling. The module is small > and focused and could be used as a utility lib for C3. > > The release candidate

Re: [VOTE] Release cocoon-xml 2.0.0

Carsten Ziegeler wrote: > Reinhard Pötz wrote: >> Carsten Ziegeler wrote: >>> Hi, >>> >>> I've assembled a first release candidate for the new xml sub project >>> containing useful stuff for dom and sax handling. The module is small >>

Re: [VOTE] Release cocoon-xml 2.0.0

Reinhard Pötz wrote: > Carsten Ziegeler wrote: >> Hi, >> >> I've assembled a first release candidate for the new xml sub project >> containing useful stuff for dom and sax handling. The module is small >> and focused and could be used as a utility lib for

[VOTE] Release cocoon-xml 2.0.0

ocoon/cocoon-xml/2.0.0/ Please cast your votes. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [RT] C3: Cleaning up SAX module

or each type (xml, dom, stax). I would vote for the second approach. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [RT] C3: Cleaning up SAX module

handler. This really simplifies the impl and the handling, makes integrating other stuff easy and doesn't create unnecessary dependencies. > I'm very sorry for that but the last days in January are always very painful > for Austrian students... No problem :) we're now having

Re: OSGi integration (again)

> I´ve written a proof of concept with a Sling Servlet using the Cocoon > pipeline api to get the response. This proof was ok but I´m thinking > about a more natural Cocoon/Sling integration. IMHO, a pipeline, even > a sitemap, would be as a script in Sling. > Wow, great - what do yo

[jira] Commented: (COCOON3-22) Remove XMLConsumer interface

[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668370#action_12668370 ] Carsten Ziegeler commented on COCOON3-22: - Ok, having worked with the xml cons

Re: OSGi integration (again)

ules as OSGi bundles would be a good starting point. For our products I've written a simple pipeline api (and impl) which post processes the output from Sling. My intention is to do exactly this with C3. Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Created: (COCOON3-22) Remove XMLConsumer interface

Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is

Re: OSGi integration (again)

't speak about C2, but my intension is to enable C3 for OSGi (whatever that means in the end). Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [RT] C3: Cleaning up SAX module

ndler as well, so we are in good company) Carsten -- Carsten Ziegeler cziege...@apache.org

[RT] C3: Cleaning up SAX module

think we can remove this and just rely on ContentHandler for chaining sax components. When sax components are chained, they can simply check if the next component implements LexicalHandler as well or not. With this simple improvement we can also remove the XMLConsumerAdapter. WDYT? Carsten -- Carsten

[jira] Commented: (COCOON3-16) Fix the class hierarchy of org.apache.cocoon.pipeline.component.Consumer

[ https://issues.apache.org/jira/browse/COCOON3-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667598#action_12667598 ] Carsten Ziegeler commented on COCOON3-16: - We should use the SAXBuffer from co

Re: [jira] Created: (COCOON3-14) Use generics for pipeline assembly

r hand, the class hierarchy of the whole SAX module is rather > messy IMO... Yes, that's what I thought as well :) But I saw you opened a bug for this. so let's discuss it there. Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Closed: (COCOON3-15) Use Java 5 Regex instead of internal sun classes

[ https://issues.apache.org/jira/browse/COCOON3-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON3-15. --- Resolution: Fixed Changed in revision: 737809 > Use Java 5 Regex instead of internal

[jira] Created: (COCOON3-15) Use Java 5 Regex instead of internal sun classes

-sitemap Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 3.0.0-alpha-2 The wildcard matcher helper uses internal sun classes which makes the module fail during compilation on my mac osx; jdk 5 The use of the

Re: [c3] Towards alpha-2

e integration of JAX-RS (using Jersey) >with Cocoon 3. If there are no objections and I have enough time >to finish it, I'd like to add it to the cocoon-rest module. > > Comments? +1 Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [C3] Question about the Consumer

Steven Dolg wrote: > Michael Seydl schrieb: >> What purpose or intention has it that the Consumer isn't a >> PipelineComponent? > Actually that's just a design flaw we haven't fixed yet. > Of course it should be a PipelineComponent. > So let's fix t

Re: [jira] Commented: (COCOON3-14) Use generics for pipeline assembly

n theory we can change everything - but I don't think that this is required :) Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [RT] Using the xml subproject in C3

Reinhard Pötz wrote: > Carsten Ziegeler wrote: >> Hi, >> >> I think we should use the new xml subproject (containing sax and dom >> utility classes) in C3. >> >> If noone objects, I could do the changes in the next days. > > Do you have any plans fo

[RT] Using the xml subproject in C3

Hi, I think we should use the new xml subproject (containing sax and dom utility classes) in C3. If noone objects, I could do the changes in the next days. Carsten -- Carsten Ziegeler cziege...@apache.org

[jira] Commented: (COCOON3-14) Use generics for pipeline assembly

[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1210#action_1210 ] Carsten Ziegeler commented on COCOON3-14: - Yes, even with this patch it

[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly

; > Key: COCOON3-14 > URL: https://issues.apache.org/jira/browse/COCOON3-14 > Project: Cocoon 3 > Issue Type: Improvement > Components: cocoon-pipeline >Reporter: Carsten Ziegeler >Assignee:

[jira] Commented: (COCOON3-14) Use generics for pipeline assembly

[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666541#action_12666541 ] Carsten Ziegeler commented on COCOON3-14: - Hmm I still don't so :) As

[jira] Commented: (COCOON3-14) Use generics for pipeline assembly

[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666527#action_12666527 ] Carsten Ziegeler commented on COCOON3-14: - Why does your example from above

[jira] Updated: (COCOON3-14) Use generics for pipeline assembly

[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-14: Attachment: generics.patch Patch > Use generics for pipeline assem

[jira] Created: (COCOON3-14) Use generics for pipeline assembly

: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time

Re: Avoid escaping chars in script/style only in HTMLSerializer? (Re: svn commit: r515096)

bout this at that time, and I think the outcome was to only apply it to the html serializer. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [C3] Pipeline component event types

eck. Maybe we don't need to change this and just properly naming things (like either adding SAX etc. to the class name or as a package) is enough. I actually don't know, but I think the easier we make it and the more we can check at compile time, the more we attract possible users. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [C3] Pipeline component event types

n separately. This doesn't sound like a promising approach. Now, the impl should be shareable, I totally agree that having to maintain 9 (or more) implementations that vary only a little bit is a nightmare. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [C3] Pipeline component event types

Steven Dolg wrote: > Carsten Ziegeler schrieb: >> Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a >> stax pipeline, perhaps sharing a common interface? >> > From my point of view: > Currently the user must know which components he needs (as

Re: [C3] Pipeline component event types

ine interface? Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a stax pipeline, perhaps sharing a common interface? Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [c3] Pipeline results

pipeline run or if a boolean is sufficient. Apart from that I think, the interface is the price we have to pay for the flexibility we get. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [c3] Pipeline results

hanges first. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [c3] Pipeline results

Carsten Ziegeler wrote: > Reinhard Pötz wrote: >> I want to provide a SAX buffer to the pipeline and the serializer just >> passes the SAX events to it. > Ah, ok. > >>> As the output stream is a runtime object for the finisher it should be >>> treated like

Re: [c3] Pipeline results

een input and output parameters. Maybe two parameter maps make more sense. > The advantage compared to my proposed solution is that this way a > serializer could handle more than one output type. Right? Yes (and it doesn't create a new interface :) ) Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [c3] Pipeline results

execution of the pipeline returns the result (if any). As the output stream is a runtime object for the finisher it should be treated like other objects of this kind (the src url for the file generator for example etc.) which means it should be passed in through the parameters for the finisher. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [C3] Extract SAX from the Pipeline module

the new module is there. > > > Any opinions or objections on that? Sounds great! The only comment I have atm is about the naming of the sax classes, I think for consistency we should use upper case characters (SAX) as this is the way the classes are named in the jdk (same with DOM). Carsten -- Carsten Ziegeler cziege...@apache.org

Re: Really small bugs

dule pom in the subprojects directory. This is fixed now and you should be able to build again. Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [c3] Pipeline results

Reinhard Pötz wrote: > Reinhard Pötz wrote: >> Carsten Ziegeler wrote: >> >>> There is a slight overlap between the serializer and the result - for >>> example if you want to get java objects out of the pipeline, you might >>> want to use a special seria

Re: [RT] Reusable code for xml (dom/sax)

David Crossley wrote: > Carsten Ziegeler wrote: >> Yes, let's start here, see where we end up with and then get the >> *communities* (xlm, commons, cocoon) together for further discussions. >> But as I said, as we are shifting away from a monolithic big bang >> fra

Re: [C3] Caching

be alot better. Yes, I guess that's all we have to do. >> It's >> just about minor improvements if at all. > I think it's actually a little bit more than that. > Seems like I was already so accustomed to the concept in my head that I > didn't even see, the implementation has become less clear that it could be. This happens, but here we have the advantage of the community :) > So PLEASE keep on doing this! > And don't feel bad when my answers appear a little harsh - I rarely mean > it that way... ;-) No problem with that :) Carsten -- Carsten Ziegeler cziege...@apache.org

Re: [RT] Reusable code for xml (dom/sax)

re we end up with and then get the *communities* (xlm, commons, cocoon) together for further discussions. But as I said, as we are shifting away from a monolithic big bang framework to finer grained reusable modules, it might make sense to have this common xml stuff here and maybe use it for &

Re: [C3] Caching

to implement just by looking at all the names. But maybe it's just me. Perhaps moving the sax stuff to another module, having the xml-util module is already enough. Maybe renaming something like XMLConsumer to SAXConsumer helps as well. So please, don't consider this as a critics on the whole concept. It's just about minor improvements if at all. Carsten -- Carsten Ziegeler cziege...@apache.org

  1   2   3   4   5   6   7   8   9   10   >