Cocoon-webservices
Hi All, I am a novice user of Cocoon framework. I want to create a small demo for Cocoon with web services. For the same I goggled and got the following link and several other links. But could not follow-up. http://webservices.xml.com/pub/a/ws/2003/03/18/cocoon.html Can any one having demo for cocoon-web services? Thanks in Advance Nagaraju Chittathuru
[jira] Commented: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674709#action_12674709 ] Reinhard Poetz commented on COCOON3-22: --- The patch doesn't cover the cocoon-stax module :-( Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674709#action_12674709 ] reinh...@apache.org edited comment on COCOON3-22 at 2/18/09 9:39 AM: The patch doesn't cover the cocoon-stax module :-( BTW, there is it.bat (or it.sh of *nix) that runs all unit and integration tests and performs license header checks. was (Author: reinh...@apache.org): The patch doesn't cover the cocoon-stax module :-( Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674718#action_12674718 ] Carsten Ziegeler commented on COCOON3-22: - Ah yes, it doesn't cover this as I don't have Java 6 on my machine :( But I can update the patch Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- 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 (109 issues) Subscriber: cocoon Key Summary COCOON-2250 Wrong error message in Element.java (jx:element) https://issues.apache.org/jira/browse/COCOON-2250 COCOON-2249 XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors https://issues.apache.org/jira/browse/COCOON-2249 COCOON-2246 HttpRequest should handle encoding in getParameter and getParameterValues in the same way https://issues.apache.org/jira/browse/COCOON-2246 COCOON-2233 Update archetypes to current trunk artifact versions https://issues.apache.org/jira/browse/COCOON-2233 COCOON- Add SaxParser configuration properties https://issues.apache.org/jira/browse/COCOON- COCOON-2216 IncludeCacheManager can not perfom parallel includes https://issues.apache.org/jira/browse/COCOON-2216 COCOON-2212 jx:attribute does not check name is correct before proceeding https://issues.apache.org/jira/browse/COCOON-2212 COCOON-2211 Support for jx:element https://issues.apache.org/jira/browse/COCOON-2211 COCOON-2197 Making the cocoon-auth-block acegi-security-sample work https://issues.apache.org/jira/browse/COCOON-2197 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 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 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 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-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 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 servlet 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-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-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 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
Re: [C3] Refactoring the SAX module
Carsten Ziegeler wrote:
Hi,
as part of COCOON3-22 I've refactored the whole SAX module and removed a
lot of classes :)
Before committing these changes I would like to discuss them (I can
provided a patch but not sure if this works).
Ok, the aim is to reduce the number of interfaces and abstract classes
as much as possible.
The o.a.c.sax packages contains
- SAXPipelineComponent - the marker interface for all sax components
- AbstractSAXGenerator, AbstractSAXSerializer, AbstractSAXTransformer
- the base classes to simplify implementation of these components
- AbstractSAXProducer - base class for AbstractSAXGenerator and
AbstractSAXTransformer
That's it - this creates imho a clean package and provides a good base
for implementing own sax based components.
Ok, I left o.a.c.sax.component the way it is atm (of course adapted the
implementations)
And o.a.c.sax.util only contains TransformationUtils and XMLUtils.
The former adapter class in this package is replaced by SAXPipe from
cocoon-xml (our 2.2 subproject). I'Ve added a copy of this class to
cocoon-sax for the moment to not rely on a snapshot of cocoon-xml here.
I also fixed javadocs and some bugs in the implementations :)
I know that these changes will brake the symmetrie between the other
implementations (Stax mainly) - but on the other hand it gives a nice
and easier structure to implement components. People comming from 2.x
who want to implement a component just pick up AbstractXYZ as a base and
are done. And as these abstract classes are deduced to the minimum it's
imho much easier to understand what's going on.
The feedback of our student group was rather the opposite. I'm pretty
sure that it helps to understand Cocoon 3 if all different pipeline
component implementations follow the same logic.
But of course my survey isn't really scientific ...
I would go one step further and also remove the AbstractSAXProducer
class and copy the code to the two using classes to make the hierarchy
even simpler.
TBH, I don't like duplicating this code in general and also in this
particular case because I don't see any benefit because people will use
AbstractGenerator/Transformer anyway.
But that's not a must :)
thank god ;-)
So, what do you think?
I'm not fully convinced yet. I will have a look at it again when I can
apply the patch and can build Cocoon. I have some (internal) code that
uses cocoon-sax and I want to understand all effects.
I'm also preparing a project proposal (GSoC, Vienna-based student
groups) about Cocoon profiling which relies on Spring AOP and I have
to think about the influence of not having SAXConsumer and SAXProducer
anymore.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: [C3] Refactoring the SAX module
Reinhard Pötz wrote: The feedback of our student group was rather the opposite. I'm pretty sure that it helps to understand Cocoon 3 if all different pipeline component implementations follow the same logic. Hmm, ok, I don't think so, so let's just agree that we disagree here. But of course my survey isn't really scientific ... I haven't even done a survey but just did test myself :) From the past I know that many people were confused by all the interfaces and abstract classes we had in Cocoon 2.x, but maybe that's different with a new C3. I'm not fully convinced yet. I will have a look at it again when I can apply the patch and can build Cocoon. I have some (internal) code that uses cocoon-sax and I want to understand all effects. Apart from the stax stuff, it builds (at least for me) and the tests run. I'll add a second patch which fixes the stax stuff. I'm also preparing a project proposal (GSoC, Vienna-based student groups) about Cocoon profiling which relies on Spring AOP and I have to think about the influence of not having SAXConsumer and SAXProducer anymore. Hmm, I think this should still be possible. Now, to be honest, I find the whole situation not very comfortable at the moment. There are only a few contributing to C3 and nearly no other comments. My intention is to have a small, nice and easy, pipeline api which allows me to build sax pipelines. And I want to have as less dependencies and as less stuff in their to make it understandable as possible. I don't think that the symmetrie to the other implementations helps us. But that's of course my personal opinion. I think we (Steven, you, the Vienna-based students and myself) 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] 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 interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, cocoon-stax.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [C3] Refactoring the SAX module
Carsten Ziegeler pisze: Now, to be honest, I find the whole situation not very comfortable at the moment. There are only a few contributing to C3 and nearly no other comments. My intention is to have a small, nice and easy, pipeline api which allows me to build sax pipelines. And I want to have as less dependencies and as less stuff in their to make it understandable as possible. I don't think that the symmetrie to the other implementations helps us. But that's of course my personal opinion. I think we (Steven, you, the Vienna-based students and myself) 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. Not only to just add one more dimension to the problem and discussion space I would say that I disagree with both standpoints. This may come from the fact that I see things from completely different angle. Before I post any in-depth comments I still have to digest all the e-mails that have been posted while I've been having a break. What already has stroke me is that people seem to agree that having various *AbstractGenerator, *AbstractTransformer, *AbstractSerializer classes is a good thing. I may miss the point completely but this looks like a code and structure duplication. Could someone enlighten me on why do we need different abstract classes? My very own guess for answer is that our Pipeline API is too weak (in terms of constraints it enforces) so no meaningful abstract class can be provided. This is what I'm not comfortable with for a long time but others seems to not see this as a problem important enough. And yes, I could resist to bring back this issue into discussion. -- Best regards, Grzegorz Kossakowski
Re: [C3] Refactoring the SAX module
Carsten Ziegeler wrote:
Reinhard Pötz wrote:
The feedback of our student group was rather the opposite. I'm pretty
sure that it helps to understand Cocoon 3 if all different pipeline
component implementations follow the same logic.
Hmm, ok, I don't think so, so let's just agree that we disagree here.
But of course my survey isn't really scientific ...
I haven't even done a survey but just did test myself :) From the past I
know that many people were confused by all the interfaces and abstract
classes we had in Cocoon 2.x, but maybe that's different with a new C3.
I'm not fully convinced yet. I will have a look at it again when I can
apply the patch and can build Cocoon. I have some (internal) code that
uses cocoon-sax and I want to understand all effects.
Apart from the stax stuff, it builds (at least for me) and the tests
run. I'll add a second patch which fixes the stax stuff.
Thanks, will try it out asap.
I'm also preparing a project proposal (GSoC, Vienna-based student
groups) about Cocoon profiling which relies on Spring AOP and I have
to think about the influence of not having SAXConsumer and SAXProducer
anymore.
Hmm, I think this should still be possible.
Now, to be honest, I find the whole situation not very comfortable at
the moment. There are only a few contributing to C3 and nearly no other
comments. My intention is to have a small, nice and easy, pipeline api
which allows me to build sax pipelines. And I want to have as less
dependencies and as less stuff in their to make it understandable as
possible. I don't think that the symmetrie to the other implementations
helps us. But that's of course my personal opinion. I think we (Steven,
you, the Vienna-based students and myself) 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.
I don't know if there is a right or wrong for this case. IMO we can only
judge on our personal experiences and tastes on what we think that good
software should look like. So yes, more opinions would be highly
appreciated.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: [C3] Refactoring the SAX module
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Now, to be honest, I find the whole situation not very comfortable
at the moment. There are only a few contributing to C3 and nearly
no other comments. My intention is to have a small, nice and easy,
pipeline api which allows me to build sax pipelines. And I want to
have as less dependencies and as less stuff in their to make it
understandable as possible. I don't think that the symmetrie to the
other implementations helps us. But that's of course my personal
opinion. I think we (Steven, you, the Vienna-based students and
myself) 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.
Not only to just add one more dimension to the problem and discussion
space I would say that I disagree with both standpoints. This may
come from the fact that I see things from completely different angle.
Before I post any in-depth comments I still have to digest all the
e-mails that have been posted while I've been having a break.
What already has stroke me is that people seem to agree that having
various *AbstractGenerator, *AbstractTransformer, *AbstractSerializer
classes is a good thing. I may miss the point completely but this
looks like a code and structure duplication.
Sorry, can't follow you here. What's the problem with that approach?
Could someone enlighten
me on why do we need different abstract classes?
My very own guess for answer is that our Pipeline API is too weak (in
terms of constraints it enforces) so no meaningful abstract class can
be provided. This is what I'm not comfortable with for a long time
but others seems to not see this as a problem important enough. And
yes, I could resist to bring back this issue into discussion.
The only alternative that I've seen so far exposes pipeline internals
(see http://cocoon.markmail.org/message/sda4xck3fevcusns) which is a
very dangerous approach IMHO because it works differently than most Java
developers would expect and therefore could cause a lot of programming
mistakes.
Looking at our goal of providing generic pipelines for *Java* I think
that we have been developing a solution that is powerful and abstract
enough to support three different content types for pipeliones (StAX,
SAX, Java Images) and works like most Java developers expect.
Yes, I'm comfortable (enough) with the current solution and don't see a
reason why we should reconsider our core contracts ATM. Of course that's
my personal opinion and I'm not against changing things if this improves
things within our scope of generic pipelines for Java.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
