Going emeritus
Hi, I would like to go emeritus. I've been hesitating for quite long time because I'm still emotionally connected to this project. Cocoon was the first open source project that I contributed to and it's amazing community shaped me as professional programmer. I literally grew up with you guys learning how to create great software, foster great community and how to communicate long before I got enrolled into university. You've been really influential on how I perceived and continue to perceive open source. Also, I enjoyed your company as a group of great people. I would like to especially thank Daniel Fagerstrom, Reinhard Potz and David Crossley. This is a sad moment for me but I must admit that I see no chance for contributing to Cocoon again in a foreseeable future. Actually, I don't even program in Java anymore. I moved to Scala and I don't want to look back. You can learn a bit about my recent project over here: http://scalagwt.gogoego.com/. I'll update my records in svn in a week and I'll contact PMC to inform about my decision. Thanks for a great time and I hope to meet you again in a future. -- Best regards, Grzegorz Kossakowski
[OT] What Grzegorz is working on (was: Re: [vote] Release Cocoon 3.0.0-alpha-2)
W dniu 05.01.2010 00:20, Robby Pelssers pisze: > So you finally became a SCALA addict? ;-) Scala was just one (although significant) step to interesting topics like: * (efficient) functional data structures * different parallel and concurrent approaches like STM and actors * powerful type systems and their (provable) limits * studying properties of abstractions like monads, monadic transformations. Java world would say that I'm just studying patterns. Scala is just a nice language that enables me to try various ideas. :-) In short: I just prepare myself for upcoming CPUs with 100+ cores. ;-) Oh and I'd like to implement some stuff (query DSL and monad) for my little project I've done during last summer: http://code.google.com/p/gimd/ > Happy newyear Grzegorz, > Robby Pelssers Thanks and the same to you Robby! -- Best regards, Grzegorz
Re: [vote] Release Cocoon 3.0.0-alpha-2
W dniu 04.01.2010 16:36, Reinhard Pötz pisze: > I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2. > Since it has been more than a year since alpha-1 was released, there are > many improvements and enhancements: > > Pipeline API level > ~~~ > . Add generics to the pipeline interface. With additionally introducing > marker interfaces for the component types (SAX, StAX, etc.) this allows > compile time checks if all components have the correct type when > assembling the pipeline H. I might have a look at that. Just curious how you approached it finally. > . Use MurmurHash 2.0, a strong hashing algorithm, to implement the > hashCode() method of cache keys. > . Introduce an exception hierarchy for pipeline components > (ProcessingException and SetupException extend both PipelineException). > . Create a separate SAX module that contains all SAX specific classes > . Provide basic component implementations of StAX pipeline components > (new module: 'cocoon-stax') > . Add a new module 'cocoon-optional' for components that need external > libraries (i.e. everything that goes beyond JDK5, commons-logging and > cocoon-sax) > > New components: > . XMLGenerator (constructors for File, InputStream, String, Node, > SAXBuffer) [cocoon-sax] > . XIncludeTransformer [cocoon-sax] > . SchemaProcessorTransformer [cocoon-sax] > . Add factory methods to o.a.c.sax.component.XMLSerializer to create > properly configured serializers for XML, XHTML and HTML4 [cocoon-sax] > . FOPSerializer [cocoon-optional] > . NekoHTMLGenerator [cocoon-optional] > . BetwixtBeanGenerator [cocoon-optional] > > Sitemap level > ~~~ > Only minor changes > > Webapplication level > ~~~ > . REST controller (new module: 'cocoon-rest') > . JAX-RS based controllers (JSR 311) > . Automatic conditional GET support for all caching pipelines. > (ETag and Last-Modified are supported) > . Wicket integration in both ways (new module: 'cocoon-wicket') > . JMX based monitoring: Cache overview, reconfiguration of logging, > Servlet-Service-Framework overview (new module: 'cocoon-monitoring') > . SSF/Sitemap/Pipeline profiling (new module: 'cocoon-profiling' Another potentially interesting thing. > . Update to Spring 2.5.6 > > Find all details at http://cocoon.apache.org/3.0/changes-report.html. > > > You can find the staged files for all modules (sources, binaries, > javadocs, checksums, gpg signatures) at > http://people.apache.org/builds/cocoon/ > > > SVN tags of all these artifacts can be found at > http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/ > > The general distribution artifacts (tar, zip) are available at > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.asc > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.md5 > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.sha1 > > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.asc > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.md5 > http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.sha1 > > > I want to stress again that this is an alpha release. This means that we > are free to change contracts without following any deprecation rules. > See http://cocoon.apache.org/3.0/alpha-warning.html > > > This majority vote stays open for at least 72 hours. Please cast your votes! +0 Which means that I lack free time (and more importantly, involvement) to test it honestly but I still appreciate the work all of you put into this release. Happy New Year to all! -- Best regards, Grzegorz Kossakowski (who drifted away from Java world and imperative programming almost completely)
[jira] Assigned: (COCOON-2118) Implement map: expression language
[
https://issues.apache.org/jira/browse/COCOON-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2118:
Assignee: (was: Grzegorz Kossakowski)
I don't plan to work on this issue in foreseeable future so I leave it
unassigned.
FYI: This feature has been implemented in C3 and in C2.2 it would be rather
hard to implement it due to (still, sight) complicated ObjectModel. I have lost
any faith when it comes to this.
> Implement map: expression language
> --
>
> Key: COCOON-2118
> URL: https://issues.apache.org/jira/browse/COCOON-2118
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap
>Affects Versions: 2.2
> Reporter: Grzegorz Kossakowski
>
> Implement expression language ("map:") that let's you to access sitemap
> variables.
> Actually, it's already implemented in PreparedVariableResolver for years but
> the task is about implementing it as class imlementing
> org.apache.cocoon.components.expression.Expression interface.
> It was proposed here[1] and clarified here[2].
> [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/73700
> [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73760
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2044) servlet: protocol URIs have to be globally unique for use as cache-keys
[ https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2044: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. > servlet: protocol URIs have to be globally unique for use as cache-keys > --- > > Key: COCOON-2044 > URL: https://issues.apache.org/jira/browse/COCOON-2044 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2 >Reporter: Alexander Klimetschek >Priority: Critical > > All servlet protocol URIs like servlet:/some/thing or servlet:super:/foo/bar > or servlet:myblock:/another/path have to be globally unique because they are > used in the cache, of which there is only one global with globally acting > keys. > There are two caches in standard Cocoon configuration (the only ones I know > of ;-), both with a different key generation. Here are ideas how to make the > keys global: > a) EHDefaultStore for caching resources of caching pipelines: they use the > uriPrefix of the Enviroment in the key, so providing a uriPrefix (eg. the > mount path of the servlet) works here. > b) DefaultTransientStore which caches XSLT and JX generator sources (don't > know why this is different from a)): they do not use the uriPrefix and much > worse, they need correct URIs because they are read by the XSLT processor, > who does not like things like servlet:uniqueID34:/xsl/stylesheet.xsl > containing arbitrary schemes at the beginning. Appending an ID via a query > parameter seems the only working solution (tried it already): > servlet:/xsl/stylesheet.xsl?servlet-services-id=12345 > Another solution would be to have one cache per sitemap, so that the keys > don't have to be unique anymore. But I don't know how to configure that and > if this is feasible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2096) Servlet source's exists() method always returns true
[
https://issues.apache.org/jira/browse/COCOON-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2096:
Assignee: (was: Grzegorz Kossakowski)
I don't plan to work on this issue in foreseeable future so I leave it
unassigned.
> Servlet source's exists() method always returns true
>
>
> Key: COCOON-2096
> URL: https://issues.apache.org/jira/browse/COCOON-2096
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
>Affects Versions: 2.2
>Reporter: Alexander Weber
>
> sitemap from myBlock1-the filename.txt exist at
> resource/external/filename.txt - the myBlock2 is a bean id - myBlock3 id does
> not exist or the file does not exists in myBlock3:
>
>
>
>
>
>
> src="servlet:myBlock2:/resource/external/filename.txt"/>
>
>
>
> Since myBlock3 does not exist, i am expecting that "test=" returns false and
> map:otherwise is used. But unfortunately it _always_ returns true. It is
> acting as if the "servlet:myBlock3:" part is completely ignored.
> Grzegorz reported back on the User-maillist:
> [quote]
> Alex, I've just checked sources of servlet: protocl (source) that it looks[1]
> like this:
> /**
> * Returns true always.
> *
> * @see org.apache.excalibur.source.Source#exists()
> */
> public boolean exists() {
> return true;
> }
> [/quote]
> reported on maillist:
> http://www.nabble.com/-cocoon-2.2.x--site-can-check-for-file-exists--t4040666.html
> Alexander Weber
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2212: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. > jx:attribute does not check name is correct before proceeding > - > > Key: COCOON-2212 > URL: https://issues.apache.org/jira/browse/COCOON-2212 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Templating >Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) >Reporter: Kamal Bhatt > Fix For: 2.2-dev (Current SVN) > > Attachments: JXtemplateAttributePatch > > > Currently, jx:attribute does not validate that the name is correct before > generating attribute. This patch fixes this. > Also, refactored the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2239) Add support for servlet protocol in flow's sendPage
[
https://issues.apache.org/jira/browse/COCOON-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2239:
Assignee: (was: Grzegorz Kossakowski)
I don't plan to work on this issue in foreseeable future so I leave it
unassigned.
> Add support for servlet protocol in flow's sendPage
> ---
>
> Key: COCOON-2239
> URL: https://issues.apache.org/jira/browse/COCOON-2239
> Project: Cocoon
> Issue Type: Task
> Components: - Components: Sitemap, - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
>
> The idea of this task is introduce support for servlet: protocol in sendPage
> calls.
> Current behaviour is that if one called sendPage("some/path") it will get
> translated into redirection to "cocoon:/some/path" so any custom protocol is
> disallowed in sendPage calls.
> I would like to introduce support for sendPage("servlet:/some/path") calls
> that explicitly make use of servlet: protocol. In such case, processing
> should be redirected to ServletSource and SSF machinery.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2216: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. > IncludeCacheManager can not perfom parallel includes > > > Key: COCOON-2216 > URL: https://issues.apache.org/jira/browse/COCOON-2216 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) >Reporter: Christoph Gaffga > Attachments: cocoon-trunk.patch, > multi-thread-simple-28.09.2008.patch, > ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, > test-webapp.zip, test-webapp.zip > > > Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple > sources from other cocoon pipelines into one (similar to the aggregator) is > not working anymore. > We also posted our problem to the mailing list, got little feedback but it > brought us on the right way... > see also: http://www.mail-archive.com/us...@cocoon.apache.org/msg42173.html > I found out that it's a problem with the DefaultIncludeCacheManager, that can > not do parallel inclusion of cocoon-pipelines anymore. I checked several > classes where inclusion is used. In the aggregator parallel inclusion is not > an option anymore, in CIncludeTransformer the IncludeCacheManager is used, > but it can't do parallel inclusion. In the new IncludeTransfomer parallel > inclusion is supported, but it does not use caching as it does not use the > IncludeCacheManager... > But we needed caching AND parallel processing, so I tried to find out what's > broken in the DefaultIncludeCacheManager: > and it seems that the ThreadLocal variables are not initialized for the child > threads that do the inclusion. Neither the spring context nor the old > environment stuff was initialized. And all the source resolving was done > outside the child thread and that way using the wrong thread context. > We were able to fix that issue by small changes to DefaultIncludeCacheManager > and IncludeCacheManagerSession. It would be great if somebody could apply > this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2211. Resolution: Fixed Resolved in r668604. > Support for jx:element > -- > > Key: COCOON-2211 > URL: https://issues.apache.org/jira/browse/COCOON-2211 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Templating >Affects Versions: 2.2, 2.2-dev (Current SVN) >Reporter: Kamal Bhatt > Assignee: Grzegorz Kossakowski > Attachments: JXtemplateElementPatch > > > JXTemplate does n't support a jx:element instruction. This patch provides > this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2087) Upgrade Forms samples' dependency on jDBI to 2.0.x version
[ https://issues.apache.org/jira/browse/COCOON-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2087: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. > Upgrade Forms samples' dependency on jDBI to 2.0.x version > -- > > Key: COCOON-2087 > URL: https://issues.apache.org/jira/browse/COCOON-2087 > Project: Cocoon > Issue Type: Task > Components: Blocks: Forms >Affects Versions: 2.2 > Reporter: Grzegorz Kossakowski > > I reported (http://article.gmane.org/gmane.text.xml.cocoon.devel/73957) > recently that we have a trouble with jDBI as dependency because it's not on > Maven's repository. I just have found out that it's not true, see: > http://repo1.maven.org/maven2/org/jdbi/jdbi/2.0.1/ > The task is to add the dependency on jDBI to cocoon-forms-sample module and > (possibly) adjust the code so it works with new major version. Old samples > used to work with 1.4.x line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2108: Assignee: (was: Grzegorz Kossakowski) I don't plan to work on this issue in foreseeable future so I leave it unassigned. > xmodule:flow-attr Does not accept document objects > -- > > Key: COCOON-2108 > URL: https://issues.apache.org/jira/browse/COCOON-2108 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11, 2.2 >Reporter: Hugh Sparks >Priority: Minor > Fix For: 2.1.12-dev (Current SVN), 2.2 > > Attachments: Cocoon-2.2-truck-JXPathHelper.java.patch, > Cocoon-BRANCH-2.1.X-JXPathHelper.java.patch, xmodulePuzzle.txt > > > Sending document objects from flowscript back to the pipeline using > xmodule:flow-attr produces unexpected results. Also, the examples from > the documentation do not work as described: > http://cocoon.apache.org/2.1/861.daisy.html > The most common error reported is: > 'The object type: class java.lang.String could not be serialized to XML" > This issue was discussed recently on the cocoon-users mailing list. > The thread was introduced by Kazo Csaba with the subject "Sending DOM from > flowscript to pipeline." > (July 17, 2007) > He has attempted to trace this behavior in the source code and believes that a > possibly-inappropriate conversion to string occurs in some cases. > Jason Johnston suggested moving the issue to JIRA. > I've created a demonstration of this apparent bug and some related problems > in this very brief example: > http://www.csparks.com/xmodulePuzzle.txt > I hope someone can fix or explain the correct usage of xmodule:flow-attr. > Thanks to all, > -Hugh Sparks, h...@csparks.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Already in Amsterdam
Jeroen Reijn pisze: > I will attend the meetups this evening and tomorrow evening. > And perhaps be at there tomorrow morning. > > I have not been that devoted to the project the last couple of months, > but am interesting in meeting some old friends :-) Hi Jeroen, Which Meetup are planning to attend today? -- Best regards, Grzegorz Kossakowski
Already in Amsterdam
Hello, I'm already in Amsterdam sitting in BarCamp room. It would be nice if others would share some sketch schedule here so we could arrange some meeting if there is anyone interested in meeting devoted to Cocoon. :-) -- Best regards, Grzegorz Kossakowski
Re: [C3] Sitemap implemented in Scala
Joerg Heinicke pisze:
>
> I don't have the time to actually look into your implementation. I'm
> just wondering if all the insight views couldn't be used to improve the
> Java implementation rather than starting something in a different language.
It could.
What I'm doing at the moment is sort of wild experimentation that I don't know
where will lead me to. I'm reimplementing
sitemap in Scala because I thought that sitemap processing is something
complicated enough to get a real feel of
programming in Scala.
It's true that anything I write in Scala could be emulated in Java but when I
think about it I feel rather overwhelmed
by the possible verbosity of Java counterparts to Scala constructs. In my
implementation I exploit heavily strong typing
by defining lots of types and using lots of generics. I use closures and
pattern matching quite a lot.
Compare (Scala):
private def filterUnprefixedSimpleAttributes(attributes : MetaData) :
Map[String, String] =
Map() ++ attributes.flatMap(attr => attr match {
case ua : UnprefixedAttribute => List(ua.key ->
ua.value.first.toString)
case _ => Nil
})
to translation of it (Java):
private Map filterUnprefixedSimpleAttributes(MetaData
attributes) = {
return (new Map()).putAll(attributes.flatMap(
new Function1>() {
List> apply(MetaData x) {
if (x istanceof UnprefixedAttribute) {
UnprefixedAttribute ua = (UnprefixedAttribute) x;
return new List>().add(
new Tuple2(ua.key(),
ua.value().first().toString()));
} else {
return new List>();
}
})
}
And no, I didn't take the most complicated example from my code because I don't
it find funny to write such a spaghetti
code.
So certainly I could write the same in Java but I honestly believe that in Java
operating on strongly typed, immutable
collections is NOT fun and that's the reason nobody seems to do.
And if you skim through my code you'll find that it's more or less only about
mapping, reducing and filtering strongly
typed collections.
Still example above does not prove anything general (like "Java sucks, let's do
it in Scala") but my reimplementation of
sitemap processing should provide a nice background for a discussion what we
want to see in C3.
For example, I'm interested in answering questions like if we are going to
introduce any other language apart from Java
in C3. Traditionally Cocoon had other languages integrated for years
(Javascript comes to mind) so it's rather natural
to ask this question. If answer was positive (based on some evaluation) another
question that pops up is why it can't be
Scala?
WARNING: Here follows some thoughts on personal experience with Scala that you
my safely ignore as they are rather
off-topic.
Might be that I'm extrapolating but my sitemap reimplementation in Scala did
work just after I finished all necessary
bits. I mean: I have written all the processing, integrated it into servlet so
it could work with the rest of C3 and it
did work just immediately. I didn't have any test-cases and I didn't run my
code while writing it.
After extensive testing with all samples C3 provides I found exactly one bug[1]
in that code. Of course, this does not
mean I don't have any other bugs but the probability that I have many of them
is really small.
Does Scala make me magically not making any mistakes? Certainly not. It only
informs me about them at the time of
writing code by reporting compilation errors.
This experience convinced me to have following standpoint:
If we are going to introduce any secondary language in Cocoon,
I would really prefer if it was strongly typed one.
Oh, and if you wonder how on the hell I could be typing non-trivial stuff for
more than one day without introducing
almost any bugs. It might be because my code cotains 5 if statements, no
return, break or continue statements and only a
few raw loops (like "while", "for" or "repeat"). I believe that's the reason...
And yes, I have to admit that sitemap processing is somehow special case where
the power of concepts I've used simply
shines.
[1]
http://github.com/gkossakowski/apache-cocoon3/commit/845f7b61861827a17fb017625eb7f2281ac458df
--
Best regards,
Grzegorz Kossakowski
Re: [C3] Sitemap implemented in Scala
Leszek Gawron pisze: > > Is there any decent IDE support for Scala? I am not even dreaming of > scala refactorings. > I know someone will ask this question eventually. ;-) IDE support is probably the weakest of Scala. At the moment, I'm using snapshot of trunk version of Eclipse plug-in and some basic functionality works most of the time. What works: * code highlighting * code completion * basic refactoring (like rename but not in every case) * debugging * basic tool-tips displayed when hover on some element (e.g. method call) * errors reporting * code navigation using mouse and links in the code What doesn't work or is annoying: * method call parameters hints (rather annoying) * JUnit integration in Eclipse with test-cases written in Scala (Maven executes them just fine, though) * Bugs, bugs, bugs. It's rather often situation that Scala editor gets mad and does not highlight your code or code completion does not work. Anyway, what I find rather reassuring is the fact that just recently (if I'm not mistaken) Eclipse plug-in got new maintainer and some momentum. There is heavy refactoring happening in trunk and people responsible for that seem to really know how to develop Eclipse plug-ins. There is excellent feedback to my bug reports and most of them are fixed almost daily. This holds some promise for a bright future of this plug-in. I've heard that Netbeans plug-in offers little bit less of functionality than Eclipse one but is much more stable. I have tried it myself yet, though. IntelliJ seems to support Scala quite seriously but I haven't tried it myself as well. To sum it up: I find IDE support rather weak if you compare it to Eclipse's JDT for example but languges itself outweighs inconveniences. -- Best regards, Grzegorz Kossakowski
Re: [C3] Sitemap implemented in Scala
Reinhard Pötz pisze: > > Sorry, forgot to answer. I have to admit that my Scala knowledge is far > from being depp enough to understand what your code does. But I've > started to learn Scala so that I can follow your explanations next week ;-) Ah, it's ok. :-) Personally, I find Scala simpler language than Java we all know but still it takes some time to dive into it. I recommend following materials: http://www.slideshare.net/jboner/pragmatic-real-world-scala-45-min-presentation - simply good http://www.slideshare.net/Odersky/fosdem-2009-1013261 - addressing various doubts and covers Scala <-> Java interoperability and other comparisons http://www.parleys.com/display/PARLEYS/Home#slide=1;title=Scala;talk=10485769 - a it's a great chance to listen to Martin Odersky, Scala creator. Interesting content of course. -- Best regards, Grzegorz Kossakowski
Re: [C3] Sitemap implemented in Scala
Grzegorz Kossakowski pisze: > > The last step of sitemap processing is invoking the result of the reduction. > It's SitemapInvoker[5] class that is > responsible for that. This class is only partly implemented as I didn't have > time to deal with component factories > needed to build actions and pipeline for execution. Anyway, this class > extracts two distinct sets of nodes that we are > interested in: > * actions > * pipeline components Actually this list lacks one item: * controllers (represeted by either call or redirect-to node) > From this point, building a pipeline and executing actions is rather trivial > task. I've refactored my code a little bit so it handles controllers and implemented sitemap building/execution. The implementation is in SitemapInvoker.invokeSitemap but is rather messy. It uses Invocation for actual pipeline building and execution. Messy or not, this code somehow works. You can checkout scalaSitemapEval: http://github.com/gkossakowski/apache-cocoon3/tree/scalaSitemapEval and compile it. Then just go and run samples. Some of them will work just fine. Some not, I have to check why they don't work but I don't have a time right now. One thing doesn't work completely: error handling. This is due to fact that Scala implementation uses completely different logic so if we want to have error handlers working there is no chance to reuse Invocation class. This is not a problem as I already plan to reimplement that part as well to make the whole example complete. Apart from SitemapInvoker.invokeSitemap method I think this code is rather polished. It lacks some comments, though. I plan to add some in upcomming days. Any feedback is greatly appreciated. -- Best regards, Grzegorz Kossakowski
[C3] What's the use of SitemapDelegator class?
Hello, I've stumbled across rather mysterious class called SitemapDelegator. It has some Thread local variable and is used in two lines of XMLSitemapServlet only: (99)SitemapDelegator.setSitemapServlet(this); ... (166) SitemapDelegator.removeSitemapServlet(); I've tried to find some possible AOP magic using it but failed to find anything. Why this class is needed? -- Best regards, Grzegorz Kossakowski
Re: [C3] redirect-to/@uri optional?
Reinhard Pötz pisze: >> So do you agree with me changing both schema and implementation so @uri is >> required? > > yes, go ahead Done in r753635. >>>> The same concern (about too many of optional attributes) applies to >>>> call instruction. >> What about this? > > @controller and @select could be mandatory. Once I was thinking about > having a default controller for a sitemap (e.g. defined at the root > element) but have never implemented it. It that case @controller would > have to become optional. I've made them required in r753634. >> Right. I wasn't active committer at that time so I can't remember original >> goals of TreeProcessor. Anyway, I wonder if >> this functionality was ever used in 2.x? I can't recall such a situation. >> >> If I understand it correctly having extensible sitemap language adds quite a >> lot to complexity of sitemap >> implementation. I would like to know what kind of issues extensibility of >> sitemap language solves. > > There was the idea of designing page flows in XML (very similar to > Spring MVC) but this idea was dropped in favor of Flowscript. You can > guess now how old this idea has to be ;-) > Nowadays I don't know of any use case but when we implemented > cocoon-sitemap we thought that we should make it extensible, especially > because the sitemap module can be used stand-alone very easily. I see. Thanks for explaining it to me. I do not fully agree with the point that sitemap should be extensible but we'll discuss this in Amsterdam. At least I hope so. -- Best regards, Grzegorz Kossakowski
Re: [C3] Sitemap implemented in Scala
Grzegorz Kossakowski pisze: > > As Andreas pointed out, there is nothing wrong here but still my repo without > master branch was a little bit weird. I've > pushed it so now it clones without any warnings. > > Still the best way to checkout is to create local branch on top of my branch, > as suggested by Andreas. ... > > > Thanks for interest in my work. > Just pinging. Reinhard, do you have any success/failure with my work? I would like to receive some feedback as I would like to continue with my work and prepare something more polished for our meeting at ApacheCon EU in Amsterdam. -- Best regards, Grzegorz Kossakowski
Re: [C3] Sitemap implemented in Scala
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> So here it comes: >> http://github.com/gkossakowski/apache-cocoon3/tree/scalaSitemapEval >> It's a branch out of our existing trunk found in svn. The only affected >> module is cocoon-sitemap. > > I tried to clone the repository by using following command: > > git clone git://github.com/gkossakowski/apache-cocoon3.git > > and got this outpout: > > Initialized empty Git repository in [some-path]/.git/ > remote: Counting objects: 7860, done. > remote: Compressing objects: 100% (2229/2229), done. > remote: Total 7860 (delta 3194), reused 7699 (delta 3071) > Receiving objects: 100% (7860/7860), 963.25 KiB | 187 KiB/s, done. > Resolving deltas: 100% (3194/3194), done. > warning: remote HEAD refers to nonexistent ref, unable to checkout. > > I use git (msysgit 1.6.1-preview20081227) on Windows Vista. As Andreas pointed out, there is nothing wrong here but still my repo without master branch was a little bit weird. I've pushed it so now it clones without any warnings. Still the best way to checkout is to create local branch on top of my branch, as suggested by Andreas. > Any suggestions (except changing the OS ;-) )? It's not necessary because: 1. Vista *with SP1* is usable OS and after some tweaking is a nice OS. This is a great improvement on initial Vista release. 2. Git on Windows is much better than it used to be one year ago. There are even plugins like TortoiseGit (http://code.google.com/p/tortoisegit/) evolving very rapidly. The world is better than it was one year ago. ;-) Thanks for interest in my work. -- Best regards, Grzegorz Kossakowski
[C3] Sitemap implemented in Scala
a time right now to polish it more. Thanks for listening. [1] http://github.com/gkossakowski/apache-cocoon3/blob/b0b85d22cad801c90a33ad8c1a18d88b1c0d3244/cocoon-sitemap/src/main/scala/org/apache/cocoon/sitemap/node/sc/SitemapNode.scala [2] http://github.com/gkossakowski/apache-cocoon3/blob/b0b85d22cad801c90a33ad8c1a18d88b1c0d3244/cocoon-sitemap/src/main/scala/org/apache/cocoon/sitemap/sc/SitemapBuilder.scala [3] http://github.com/gkossakowski/apache-cocoon3/blob/b0b85d22cad801c90a33ad8c1a18d88b1c0d3244/cocoon-sitemap/src/main/scala/org/apache/cocoon/sitemap/sc/SitemapReductor.scala [4] http://github.com/gkossakowski/apache-cocoon3/blob/b0b85d22cad801c90a33ad8c1a18d88b1c0d3244/cocoon-sitemap/src/main/scala/org/apache/cocoon/sitemap/sc/SitemapReductor.scala#L145 [5] http://github.com/gkossakowski/apache-cocoon3/blob/b0b85d22cad801c90a33ad8c1a18d88b1c0d3244/cocoon-sitemap/src/main/scala/org/apache/cocoon/sitemap/sc/SitemapInvoker.scala -- Best regards, Grzegorz Kossakowski
Re: Block resources and proxying
Reinhard Pötz pisze: > We usually use httpd mod_cache for static resources in our projects but > some sysadmins don't like it (don't ask me why). > Too bad, I would be very curious to hear why it's a bad idea. I can say why configuring httpd to access some resources directly is a bad idea. It's simply mixing of layers that sooner or later will introduce some headaches (think of SSF for e.g.) or will limit application developer in artificial way. -- Best regards, Grzegorz Kossakowski
Re: Block resources and proxying
Reinhard Pötz pisze: > >> Any ideas and thoughts welcome. > > Another idea is to use mod_cache of httpd. +1 for this one. Cocoon by default sets all caching-related HTTP headers for static resources. Thus httpd should just act as a simple proxy in front of Cocoon instance. -- Best regards, Grzegorz Kossakowski
Re: [C3] redirect-to/@uri optional?
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> Hi, >> >> It's again me trying to understand current sitemap design. This time >> I wonder if it's intended that redirect-to/@uri is optional. I fail >> to see how implementation of redirect-to handles this case in any >> meaningful way. > > I haven't tried it now what happens if the there is no @uri attribute > but from reading the code some exception in the RedirectorComponent will > occur. It's probably better to throw a meaningful exception in the > RedirectorNode. So do you agree with me changing both schema and implementation so @uri is required? >> The same concern (about too many of optional attributes) applies to >> call instruction. What about this? >> BTW. Was the idea of having extensible sitemap syntax discussed >> earlier? As it something new I wonder what was the main idea behind >> such a design decision. > > Why do you think that this is new? When Sylvain wrote the TreeProcessor, > one of his main goals was extensibility. Right. I wasn't active committer at that time so I can't remember original goals of TreeProcessor. Anyway, I wonder if this functionality was ever used in 2.x? I can't recall such a situation. If I understand it correctly having extensible sitemap language adds quite a lot to complexity of sitemap implementation. I would like to know what kind of issues extensibility of sitemap language solves. -- Best regards, Grzegorz Kossakowski
Re: [C3] Releasing alpha-2
Reinhard Pötz pisze: > Carsten Ziegeler wrote: >> Hi, >> >> I'll drop my suggestions and close the bug. >> >> Thanks for the feedback > > Carsten and others, > > would you be fine with a release of 'alpha-2' this or next week or do > you want to work on something before? I'm doing some heavy work on C3 these days (hence my little questions I ask) but it's totally orthogonal to current code and I don't intent do commit it any time soon. > For me the only missing piece is 'output types' but I prefer to discuss > this in Amsterdam. Same here as I'll have more content that we can discuss. As you already mentioned Amsterdam I think it's a good time to plan some talks. Do you guys have any specific plans for hackathon and the rest of the days? Speaking about myself, I plan prepare some demos and maybe slides on strongly typed languages. I would like to show how much you can achieve with type system of nowadays programming languages. Of course, the background would be C3. Moreover, I would like to discuss C3 design in general. I'm especially interested in your thoughts if C3 is going to integrate any other language than Java for some purpose (e.g. writing controllers). Apart from Cocoon-specific activities I plan to discuss Git usage at Apache. I inform you about it in case someone is interested in this topic as well. Also, there is planned meeting with GitHub folks. What about others? What kind of plans do you have? I would like to know what you want to discuss/show there so I can ponder over it in advance and come better prepared. -- Best regards, Grzegorz Kossakowski
[C3] redirect-to/@uri optional?
Hi, It's again me trying to understand current sitemap design. This time I wonder if it's intended that redirect-to/@uri is optional. I fail to see how implementation of redirect-to handles this case in any meaningful way. The same concern (about too many of optional attributes) applies to call instruction. BTW. Was the idea of having extensible sitemap syntax discussed earlier? As it something new I wonder what was the main idea behind such a design decision. Thanks for you patient answers. -- Best regards, Grzegorz Kossakowski
Re: [C3] map:select's value attribute
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> Hi again, >> >> I'm wondering how map:select is intended to work. According sitemap's >> schema following construct is valid: >> >> .. >> .. >> >> This will work because select will take request's URL as a test >> value. I'm not sure if this makes sense. At least I was rather >> surprised that map:select can omit test attribute. >> >> Was this intentional or not? > >> es it was. Match and select use the requestURI as default test > parameters. Alternative test values can be set by using the 'value' > attribute. > > This implementation mostly covers Mark's proposal > (http://cocoon.markmail.org/message/wj4zpfcgxsmlcpp7) but explicitly > distinguishes between match and select. I see. This makes sense but coming with C2.x background one will probably find default for quite surprising. Or is it only me? -- Best regards, Grzegorz Kossakowski
Re: [C3] What's the purpose of FlowNode class?
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> Hi, >> >> I'm wondering what's the purpose of FlowNode class that seems to be not used >> anywhere and there is no definition of >> "flow" in sitemap's schema. > > I've just removed it from our codebase. See the commit message for details. Thanks. Now it looks better. -- Best regards, Grzegorz Kossakowski
[C3] map:select's value attribute
Hi again, I'm wondering how map:select is intended to work. According sitemap's schema following construct is valid: .. .. This will work because select will take request's URL as a test value. I'm not sure if this makes sense. At least I was rather surprised that map:select can omit test attribute. Was this intentional or not? -- Best regards, Grzegorz Kossakowski
[C3] What's the purpose of FlowNode class?
Hi, I'm wondering what's the purpose of FlowNode class that seems to be not used anywhere and there is no definition of "flow" in sitemap's schema. -- Best regards, Grzegorz Kossakowski
Re: [2.2] Servlet service: polymorphism and connections
Andreas Hartmann pisze: > Hi Cocoon devs, Hi Andreas, > I wonder if the servlet service framework can be used to implement the > following scenario: > > There is an "abstract" block called "document-type" (think of a document > type for a CMS, actually it's about Lenya). This block declares (in the > sense of a convention) particular services, without actually > implementing them, e.g. > > /services/schema.rng (provide Relax NG schema for validation) > > Other generic blocks operate on arbitrary document types. E.g., the > "editor" block could invoke a validation step before a document is > saved. Now I imagine something like this in the editor block sitemap: > > > > > > > I guess this works if the block servlet declaration of the editor block > contains connections to all actual document type blocks (extending the > "document-type" block) that exist in the application. But since the CMS > should be easily extensible with new document types, I think we can't > require to register each document type with each generic block that > operates on document types. > > Does it make sense at all to implement such a scenario using the servlet > service framework? If yes, is there a way to achieve this behaviour > using the current implementation? Could I just register the service > connections programmatically (e.g., using a standard init-method of a > bean in the actual document type blocks)? > > Thanks a lot in advance for any comments! In my opinion SSF does not suit your job. I see blocks + SSF as a powerful way to structure your application. SSF's capabilities allow you to extend application's logic. What you want here is not really enriching your application logic as it seems to be very well defined. You want to simply enrich the data it operates on. For this purpose I guess your own protocol fetching resources from CMS's database would be better. Of course inside your protocol's implementation you can use servlet: protocol for default values. > BTW, sorry for posting this to the dev list, but actually I'm afraid the > current SSF doesn't support this, and I'd be interested in your opinions > if this concept should be supported at all. I don't think this kind of use-cases should be handled by SSF which have already well-defined purpose that I would like to keep untouched. -- Best regards, Grzegorz Kossakowski
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: Documentation System [was: Spring Configurator Docs]
Carsten Ziegeler pisze: > 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. Yes, this system is complex but, to be honest, if we want to achieve all goals that we set in the past I don't see an easy solution. I believe that the whole idea behind our system is not that bad but there are so many small things that have to be improved. When it comes to publishing it's not that hard if you make use of nightly builds that our zone does. Then it's only editing in Daisy and doing svn ci on the zone. When it comes to loosing content that nobody noticed. I think there are two reasons for that: a) massive commits into svn (when someone publishes something) that I'm never happy with b) problem with Daisy resending change notifications which, I guess, killed everyone's will to actively track changes Both result in weak changes review that lead to such unpleasant situations. First is a more issue with people's habits but the second is purely an issue with our Daisy installation. I would investigate but we would need to update our Daisy instance as we are using really old version. I wanted to do that a few times in the past but the amount of the work and fragility of our current setup always scared me away. Still doing it is a must. I would take this challenge if there was someone more knowledgeable with Solaris administration willing to help. Might it be a task for Amsterdam's hackathon provided we had done earlier preparations? > 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. No, it's not only you. Actually, I've played with this over summer a little bit but I decided to give up until we upgrade our Daisy instance because that work would probably have to be redone after the upgrade. The biggest challenge is to track renames correctly including first time rename from Daisy's ids to real names. I don't think it's impossible to be done (and not so hard once you know how Maven plug-in works internally) but still I would prefer if it have attracted attention of more than one person so chances of a mistake are minimized. -- Best regards, Grzegorz Kossakowski
Re: Documentation System [was: Spring Configurator Docs]
Grzegorz Kossakowski pisze: > > Hi Carsten, > > Apparently, there is a mess with configurator docs. > > Here you can see that there are no 2.0 docs: > http://svn.eu.apache.org/repos/asf/cocoon/site/site/subprojects/configuration/ > > Even if we have a link to them here: > http://cocoon.apache.org/subprojects/ > > This looks like someone forgot to regenerate docs after the release. > > Anyway, this does not explain why docs are not reachable even if I remember > they were. I'll try to ask git bisect for a > faulty commit. > > Will report my findings. Ok, I found the faulty change: http://cocoon.zones.apache.org/daisy/cdocs/g2/g7/1329/version/5/diff?otherVersion=6 As you can see, this change removed the whole table that linked to documentation of Configurator. I have no clue on this change so I guess we'll need to ask Reinhard what's going on. As a side-note: I can feel your pain with our current documentation system. I don't think it's fundamentally flawed but little bit not maintained-enough. There are areas for improvements. The biggest I can see is removing mismatch between version information stored in svn and daisy. Daisy lacks any information about our artifacts we are releasing which leads to annoying problems. -- Best regards, Grzegorz Kossakowski
Re: Documentation System [was: Spring Configurator Docs]
Carsten Ziegeler pisze: > Robby Pelssers schrieb: >> Hi Carsten, >> >> It's a bit hidden, but if you click on the link Cocoon2.2 under >> versions, you will get the overview page with a link to the spring >> configurator. >> > Hmm, but this opens > > http://cocoon.apache.org/subprojects/configuration/1.0/1329_1_1.html > > which allows me to just download the configurator, but I still can't see > the docs :) Hi Carsten, Apparently, there is a mess with configurator docs. Here you can see that there are no 2.0 docs: http://svn.eu.apache.org/repos/asf/cocoon/site/site/subprojects/configuration/ Even if we have a link to them here: http://cocoon.apache.org/subprojects/ This looks like someone forgot to regenerate docs after the release. Anyway, this does not explain why docs are not reachable even if I remember they were. I'll try to ask git bisect for a faulty commit. Will report my findings. -- Best regards, Grzeogrz Kossakowski
Re: OSGi integration (again)
Juan José Vázquez Delgado pisze: > > 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. Any pointers to "Sling scripts"? Quick look at Sling's home page didn't reveal anything. -- Grzegorz Kossakowski
[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=12667459#action_12667459 ] Grzegorz Kossakowski commented on COCOON3-16: - Steven, I can see some other changes to SaxBuffer. Are they formatting-only? > Fix the class hierarchy of org.apache.cocoon.pipeline.component.Consumer > > > Key: COCOON3-16 > URL: https://issues.apache.org/jira/browse/COCOON3-16 > Project: Cocoon 3 > Issue Type: Bug > Components: cocoon-pipeline >Affects Versions: 3.0.0-alpha-1 >Reporter: Steven Dolg >Assignee: Steven Dolg > Fix For: 3.0.0-alpha-2 > > Attachments: consumer.patch > > > The interface o.a.c.p.c.Consumer does not extend o.a.c.p.c.PipelineComponent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [C3] Question about the Consumer
Andreas Pieber pisze: > On Monday 26 January 2009 22:33:17 Grzegorz Kossakowski wrote: >> Carsten Ziegeler pisze: >>> 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 this :) >> Do we have an idea how to do that already? >> >> BTW. We shouldn't not forget about Producer interface. > > What's with the Producer Interface? Doh. Sorry - nothing. I just checked original Cocoon3 sources instead of not my crazy experiments. Everything is correct when it comes to Producer. Sorry for the noise. -- Grzegorz
Re: [C3] Question about the Consumer
Carsten Ziegeler pisze: > 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 this :) Do we have an idea how to do that already? BTW. We shouldn't not forget about Producer interface. -- Best regards, Grzegorz Kossakowski
Re: [jira] Commented: (COCOON3-14) Use generics for pipeline assembly
Reinhard Poetz (JIRA) pisze: > I think this patch will be the best solution that the Java programming > language can support. > Grek, your ideas are interesting but I fail to see how this could ever work > with Java. It might be that I'm not making myself clearly enough. When I'm talking about about fundamental design decisions I have in mind questions like: 1. Should component take one type of input and produce one type of output or more? 2. Is it component's concern to check if other components fit it (it's tightly coupled with first point) or it's Pipeline concern? 3. Do we want to mix components accepting different types in one pipeline? I'm asking more about our goals, basic principles and boundaries. Answering this kind of questions has nothing to do with Java capabilities even if implementation of fulfiling these goals will be affected by Java capabilities. My little example posted to this issue shows that certain operations can be done using plain Java 1.5. I would like to find out what are real limitations of Java so we can be sure that we exploit maximum we can from this language for our needs. I ask for that because this can be a starting point for doing some research on my side that I'm inserted in doing in my limited spare time. > So here's my +1 for Carsten's patch. > > @Grek: We won't reach beta before Amsterdam, which means that we can still > change core contracts. Good to know that doors are not closed entirely. -- Best regards, Grzegorz Kossakowski
[jira] Issue Comment Edited: (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=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:42 AM:
--
> The supplied patch does not change how the components interact with each
> other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponent {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
" is " +
" PipelineComponent<" + input + ", " +
output + ">");
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponent>
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
> The supplied patch does not change how the components interact with each
other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;
public interface PipelineComponent {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
[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=12666938#action_12666938 ] Grzegorz Kossakowski commented on COCOON3-14: - Looks like our JIRA set-up sucks and JIRA does not follow comment formatting. I'm moving with discussion to mailing list. > 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: 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 checks if all components have the correct type > when assembling the pipeline. -- 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-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:41 AM:
--
> The supplied patch does not change how the components interact with each
> other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;
public interface PipelineComponent {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
" is " +
" PipelineComponent<" + input + ", " +
output + ">");
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponent>
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
> The supplied patch does not change how the components interact with each
other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code}
PipelineComponent.java
package test;
public interface PipelineComponent {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class
[jira] Issue Comment Edited: (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=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:40 AM:
--
> The supplied patch does not change how the components interact with each
> other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code}
PipelineComponent.java
package test;
public interface PipelineComponent {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
" is " +
" PipelineComponent<" + input + ", " +
output + ">");
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponent>
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
> The supplied patch does not change how the components interact with each
other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponent {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
[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=12666936#action_12666936
]
Grzegorz Kossakowski commented on COCOON3-14:
-
> The supplied patch does not change how the components interact with each
> other.
> The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
>This is always the case when the Pipeline is assembled at runtime from a
>provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the
> user's code, we should not forget that automatic pipeline
> construction using some kind of description is still a valid use case and
> that basically no assumptions about
> the actual components can be made in such a case (iow Generics are pretty
> much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponent {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponent> {
public List execute(String event) {
List list = new LinkedList();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
" is " +
" PipelineComponent<" + input + ", " +
output + ">");
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponent>
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
> 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: 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 checks if all components have the correct type
> when assembling the pipeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Please use our issue tracker for attachments
Hi Thorsten, Thorsten Scherler pisze: > Who is talking about that? > > The point is that patches should not been sent to a ml. I am subscribed > to around 50 different ml and if I receive only one attachment (let us > say around 1 MB) from each list I have 50 MB overhead in my mailbox. The > push model is not suitable for patches! Using IMAP along with [PATCH] tag should help. > The issue tracker however is the supposed place for patches! That is why > it is called issue tracker. Why do you have the impression it would play > the role of rapidshare? I always talked about patches and contributions > that are interesting for the project and never said you should upload > porn. > >> However, and that is especially true for the larger patches, your >> personal space on people.apache.org can be used to exchange files >> which are too large for email attachment. > > That is only feasible for committers but not for John Doe that do not > has an apache account and want to send a diff. One of the reasons why people tend to use e-mail for posting patches instead of JIRA is that it's much easier to discuss such patches. When patch is sent to mailing list you can use all capabilities of your e-mail client like good quoting support (in-line comments), threading, etc. I believe that issue tracker should be used for patches that have been already assesed and there is an agreement on that patch. It's only my opinion, though. -- Best regards, Grzegorz Kossakowski
[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=12666913#action_12666913 ] Grzegorz Kossakowski commented on COCOON3-14: - > As far as I understood all the discussions it is now allowed to mix sax with > stax or dom components in a pipeline, > they are required to use the eventing (if you regard dom as one single big > event). Is this event-based communication guaranteed at PipelineComponent level or it's left to implementation how to design it? > If a user knows which type of components (s)he will use, the pipeline can be > "narrowed down" to accept only those type of components. > If the exact type is not known or a mixture of different components is to be > used, using How it's possible that user is using a component and does not know what kind of input/output this component deals with? I agree with Steven's point on the need for creation of marker interfaces. If they are going to be purely marker interfaces then I'm quite concerned about this solution. Is it only my omission or this patch does not solve a problem with Pipeline results outlined by Reinhard: http://article.gmane.org/gmane.text.xml.cocoon.devel/79362 To sum up my opinion I'm -0 on this patch. In itself it's not bad (and not invading) but I think this patch tries to tweak broken foundations. I would prefer if we could agree on Pipelines and PipelineComponent fundamental design decisions and goals before we move to providing patches. There were two different approaches presented in form of patches that left on or another side unhappy so such an agreement seems to be the best solution. What about a serious discussion on this topic during ApacheCon EU this year? I don't want to suspend the whole discussion for two months, of course. > 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: 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 checks if all components have the correct type > when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [C3] Pipeline component event types
Carsten Ziegeler pisze: >> > wouldn't work - and maybe this wouldn't even end in an exception. The > pipeline has no knowledge of the possible event types and which event > types are compatible. So how can it check the validity of this pipeline? This is delegated to pipeline componets that has to check if particular way of combining components is correct. This is a reason for my feeling of dissatisfaction. > Hehe...no, no, it's not about the generator, transformer, serializer and > how to chain them. For instance, the old cocoon pipeline interface made > sure that you add the components to the pipeline in the correct order > (first generator, then transformers, finally serializer). > Just because something has been in one way or the other for years, > doesn't mean that it's good and can't be made better/easier. :) You mean hear that old interface didn't made sure? > Yes, but that's you doing the stuff (or other people involved in > implementing c3). For new users it is a little bit more complicated. > Ok, granted, maybe I'm overestimating the benefit of the compile time > check. Don't know. Carsten, I don't think that compile time check (or better said just a type safety) can be overestimated. The problem we are facing is how to abstract out common bits but still make everything rather general. >> But so far not working solution/prototype has been made available (or >> did I simply miss it?). > :) No of course you didn't miss it. Maybe I have time to look into this > next week. Carsten, before you start hacking anything could you have a look at: http://github.com/gkossakowski/cocoonpipelines2/tree/6c1234a5d439aeced316723d57b9471cbcdeb0e0/src/org/apache/cocoon/pipeline Which is some kind of solution/prototype, IMHO. >> And those that have merely scratch surface IMO. >> There are still things like component order: Generator, Generator, >> Transformer, Serializer, Generator is clearly not a valid pipeline, even >> if all components are actually using the same technology. > Yes, but this can be checked immediately when the component is added to > the pipeline. Of course, this is not a compile time check. It can be compile check if you define component's type carefully. Have a look at my discussion of PipelineComponent definition in another e-mail. > 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. Agreed. It's not surprising that this subject is discussed warmly. Pipeline API is meant to be essential part of C3 and we don't want to change it too often so we need to design it carefully and more importantly, get aware of advantages and disadvantages of solution we chose. -- Best regards, Grzegorz Kossakowski
Re: [c3] Pipeline results
Steven Dolg pisze: > Configuration and setup is clearly not the most important aspect of a > pipeline component. > But AFAIK interfaces are not designed by what is most important or not, > but by what is common to the implementating classes and by what is > really necessary for the caller of that interface. Processing input and generating output is a common to all pipeline components. For any meaningful way of using components you need methods that will execute given component. If we were to stick to this interface it should be renamed to something like PipelineComponentBase but this obviously does not solve anything more than we are honestly admitting our mistake here. > From that point of view configuration and setup (and yes, those names > are not ideal - suggesstion are always welcome...) are very valid > candidates for that interface. > > It is the common basis of *all* pipeline components. > This is the most basic interface for any pipeline component - no matter > if it is a Serializer, Generator, Transformer, uses SAX, StAX, Images, > Beans, ... > I seriously wonder what methods for content processing and component > linking you are missing at that level? As you were unable to check what I've come up with (btw. GitHub folks have fixed their problem already so links work) so you couldn't get my point. Just have a look at reworked PipelineComponent interface which should be considered as a starting point for a discussion. > As this is basically a marker interface (with those 3 methods that are > common to all components) a user won't have to deal with it. > Even a developer implementing new components hardly ever gets in contact > with it, as he will usually deal with the Starter/Finisher, > Producer/Consumer level above PipelineComponent. In pipeline we have three types of components: generators, transformers and serializers. Could you explain to me why do we need 5 different interfaces supporting these three cases: PipelineComponent, Starter, Producer, Consumer, Finisher Moreover, we have AbstractGenerator, AbstractTransformer and AbstractSerializer. An argument, that in C2.2 it wasn't simpler is rather weak as we strive for finding a *better* design. It's not about pointing at anyone and blaming about imperfect code (because you could easily do the same for me) but about expressing current weak points and discussing possible solutions. > I understand that this concept is quite a bit different than Cocoon 2.2 > and is almost completely undocumented at this time, too. > But I seriously doubt that selecting interfaces randomly and questioning > their usefulness is really good approach... We can disagree on different things and it's ok but accusing me of choosing random pieces of code just for a sake of criticizing is not ok. I've worked with this code, I have reworked it according to different philosophy to show possible benefits and weaknesses. After that, I've come to conclusion that this interface looks weird and found relation to problem discussed in this thread (pipeline results). I wanted to bring that interface to the attention because we still have quite a lot of people much clever than me on this list that could possibly propose something better. -- Best regards, Grzegorz Kossakowski
Re: [C3] Pipeline component event types
th Nothing event (which is a special marking object). The property of returning partial results makes functions (pipeline components) streamable. This results in, for example, sending browser fragments of HTML page as soon as they are calculated without waiting for finishing processing of all events. If you are wondering how generator is defined, then it's just a function g: Nothing -> Event|Nothing. This definition reflects the fact that generator is a special function that _generates_ events out of nothing from Pipeline point of view. It does not base it's output on any incoming events but on some external data source that is unknown to pipeline and is out of its focus. If generator emits all its events, it signalizes it with Nothing so its result is a sequence of events ended with Nothing. Now let's discuss Continue. This is a helper object that functions can emit in order to express the fact that they need more input events in order to produce any portion of result. Think of transformer that replaces some fragment of XML with another fragment of XML based on what has been in original fragment. Therefore it has to collect all events repressing original XML fragment in order to produce new events. Here you can recognize that word "collecting" involves some buffering but I won't go into details as I want to focus on other aspects and not implementation details. Having rather precise definitions before our eyes we can move to laziness property of pipeline execution. In definition of function f (pipeline component) is not said precisely when function f can emit Nothing event. Actually, it wasn't part of definition but f must satisfy a property that f emits Nothing after finite number of receiving Nothing events (it's reader's exercise to find out why). This means that f can emit Nothing as response to any kind of event. Let's consider an example: Pipeline P1: f_1 -> f_2 -> f_3 Pipeline P: P1 -> f_4 -> f5 Now let's assume that f_1 is a generator, generating a large stream of events from a big XML file or some records. Now let's assume that f_2 is just a simple function doing some simple transformation like text formatting. Now f_3 is a query function that has a query defined like: NumberOfRecord() <= 20. This means that in pipeline P1 we want to extract only 20 first records of big file. What f_3 does after consuming 20 records is that it just returns Nothing event to say that it's the end of result for f_3. It means to pipeline execution that after Nothing is received from f_3 the whole P1 pipeline can be discarded and execution should continue with f_4 and f_4. It means that the rest of that big XML file wont' be read. I won't give you a formal definition of laziness but I'm sure you've got my point. With this kind of design of pipelines we get laziness almost for free which is a nice addition after all. Isn't it? o0o Ok, this e-mail got rather lengthy but I had a chance to explain to you how I see Cocoon Pipelines on paper. That was an occasion for me to introduce to you a concept of lazy evaluation of pipelines. For you it was an opportunity to see what have influenced my current view on pipelines design. Thank you for your attention. -- Best regards, Grzegorz Kossakowski
Re: [c3] Pipeline results
Peter Hunsberger pisze: > > I guess part of the debate is whether it is worth defining some > additional method, eg: > > CocoonOutput execute( CocoonInput genericInput) throws ?; > > or > > Object execute( Object genericInput) throws ?; > > I really can't see that the CocoonOuput and CocoonInput are anything > more than marker interfaces and this of course means that more > standard objects have to be wrapped so I think the second version is > preferable. But that certainly doesn't buy you anything as far as > pipeline contracts are concerned for traditional Java. However, I do > think that perhaps this opens up some longer term possibilities for > Aspect oriented inspection across the pipeline so maybe it is actually > worth adding? You have got a point, it's exactly about this. The problem is (that my code shows) that this kind of thing, looking simple at the beginning results in rather ugly constructs in Java... At least I couldn't make it more concise... -- Best regards, Grzegorz Kossakowski
Re: [C3] Pipeline component event types
Reinhard Pötz pisze: > My assumption is that the developer that uses the pipeline knows what he > does. This is rather good assumption. The problem I can see is that developer has to check sources of each component in order to know what he does as components type does not express what kind of output particular component produces. Or am I missing something? >>> How component can be sure that next component (its consumer) is the one >>> that accepts right type of events? By checking using instanceof? >>> My point is that once we agree to have generic pipelines that can take >>> components accepting/producing any kind of events then we need to invent >>> some mechanism that check if pipeline is built correctly. It shouldn't >>> be a concern of a given component. >>> >>> If we agree on above point, then my suggestion would be to look for a >>> way that pipeline-correctness is ensured by compiler. > > I don't see any way to express this kind of check with Java and AFAICS > your experiments haven't been successful either. It depends how you define being successful. I've managed to express this rather simple idea but the code is horrible thus I consider it as a failure. You probably haven't had a chance to look at my code due to broken GitHub. My question is if there is someone more clever than me that could come up with something more elegant. The check we are discussing is assured by Pipeline interface (look at modified addComponent method): http://github.com/gkossakowski/cocoonpipelines2/blob/master/src/org/apache/cocoon/pipeline/Pipeline.java -- Best regards, Grzegorz Kossakowski
Re: [C3] StAX research reveiled!
Grzegorz Kossakowski pisze: > I've been thinking about generic but at the same time type-safe pipelines for > some time. I've designed them on paper and > everything looked quite promising. Then moved to implementation of my ideas > and got rather disappointing result which > can be seen here: > http://github.com/gkossakowski/cocoonpipelines/tree/master > > The most interesting files are: > http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline/Pipeline.java > (generic and > type-safe pipeline interface) > > http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline/PipelineComponent.java > (generic and type-safe component def.) > > http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline/demo/RunPipeline.java > (shows how to use that thing) Argh, GitHub seems to have some problems with displaying uploaded repositories. Here are new links: http://github.com/gkossakowski/cocoonpipelines2/tree/master/src/org/apache/cocoon/pipeline/Pipeline.java http://github.com/gkossakowski/cocoonpipelines2/tree/master/src/org/apache/cocoon/pipeline/PipelineComponent.java http://github.com/gkossakowski/cocoonpipelines2/tree/master/src/org/apache/cocoon/pipeline/demo/RunPipeline.java I hope that this time they will work for a little bit longer. -- Best regards, Grzegorz Kossakowski
Re: [C3] Pipeline component event types
Grzegorz Kossakowski wrote: > Reinhard Pötz wrote: > >> I don't believe that pipelines should contain components that support >> different event types or that we event need components that have >> different input and output events. >> >> > What about serializer? Usually, it produces events of a type different > from the type of events it consumes. > >> If you want to mix your components (e.g. using a SAX component in a >> pipeline full of StAX components), you should put your 'alien' component >> into a wrapper. >> >> > Agreed. How do you know what kind of wrapper do you need if you don't > know what kind of events components consume and produce? > > How component can be sure that next component (its consumer) is the one > that accepts right type of events? By checking using instanceof? > My point is that once we agree to have generic pipelines that can take > components accepting/producing any kind of events then we need to invent > some mechanism that check if pipeline is built correctly. It shouldn't > be a concern of a given component. > > If we agree on above point, then my suggestion would be to look for a > way that pipeline-correctness is ensured by compiler. > One more thing: The idea that pipeline does know about event types that components process solves the problem with pipeline results as you have different event type carrying different data. -- Best regards, Grzegorz Kossakowski
Re: [C3] Pipeline component event types
Reinhard Pötz wrote: > I don't believe that pipelines should contain components that support > different event types or that we event need components that have > different input and output events. > What about serializer? Usually, it produces events of a type different from the type of events it consumes. > If you want to mix your components (e.g. using a SAX component in a > pipeline full of StAX components), you should put your 'alien' component > into a wrapper. > Agreed. How do you know what kind of wrapper do you need if you don't know what kind of events components consume and produce? How component can be sure that next component (its consumer) is the one that accepts right type of events? By checking using instanceof? My point is that once we agree to have generic pipelines that can take components accepting/producing any kind of events then we need to invent some mechanism that check if pipeline is built correctly. It shouldn't be a concern of a given component. If we agree on above point, then my suggestion would be to look for a way that pipeline-correctness is ensured by compiler. -- Best regards, Grzegorz Kossakowski
Re: [c3] Pipeline results
Reinhard Pötz pisze:
>
> Thanks Grek! But there is no need to hurry because neither Carsten nor I
> will work on this until Steven has finished his refactorings.
>
Actually, for me there was a hurry as another series of exams in coming and I
wanted to contribute something useful
before February.
Your problem made me to analyze Cocoon3 Pipeline API very carefully and think
about it for a while. What I found rather
strange is PipelineComponent interface, see:
public interface PipelineComponent {
void setConfiguration(Map configuration);
void setup(Map parameters);
void finish(Exception exception);
}
Why I think this interface is strange (and confusing)? Becuase it does not deal
with the most important aspect of
PipelineComponent: that it processes something and that it can be combined with
other components. The most important
aspect is neither configuration nor setup of a component.
I started to think that we will have such problems like the one mentioned in
this thread as long as we don't address
issues with PipelineComponent.
I've decided to experiment with the code (after analyzing the problem on a
paper) and you can see results here:
http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline
This code proves only one thing: that I failed to address an issue mentioned
above. What I'm interested in is if others
share my concerns about PipelineComponent interface (and Pipeline itself) and
if you also see a relation to problem with
pipeline result?
--
Best regards,
Grzegorz Kossakowski
Re: [C3] StAX research reveiled!
Jakob Spörk pisze: > Hello, Hello Jakob, > I just want to give my thoughts to unified pipeline and data conversion > topic. In my opinion, the pipeline can't do the data conversion, because it > has no information about how to do this. Let's take a simple example: We > have a pipeline processing XML documents that describe images. The first > components process this xml data while the rest of the components do > operations on the actual image. Now is the question, who will transform the > xml data to image data in the middle of the pipeline? I agree with you that pipeline implementation should not handle data conversion because there is no generic way to handle it. Now I would like to answer your question: it should be another /pipeline component/ that handles data conversion. > I believe the pipeline cannot do this, because it simply do not know how to > transform, because that’s a custom operation. You would need a component > that is on the one hand a XML consumer and on the other hand an image > producer. Providing some automatic data conversions directly in the pipeline > may help developers that need exactly these default cases but I believe it > would be harder for people requiring custom data conversions (and that are > most of the cases). > > The actual architecture allows to fit any components into the pipeline, and > only the components itself have to know if they can work with their > predecessor or the component following them. That allow most flexibility > when thinking about any possible conversions. If a pipeline should do this, > you would need "plug-ins" for the pipeline that are registered and allow the > pipeline to do the conversions. But then, it is the responsibility of the > developer to register the right conversion plug-ins and you would have get > new problems if a pipeline requires two different converters from the same > to the same data type because the pipeline cannot have automatically the > information which converter to use in which situation. I believe that these problems could be addressed by... compiler. In my opinion, pipelines should be type-safe which basically means that for a given pipeline fragment you know what it expects on the input and what kind of output it gives to you. The same goes for components. This eliminates "flexibility" of having a component that accepts more than one kind of input or more than one kind of output. I believe that having more than one output or one input only adds to complexity and does not solve any problem. If component was going to accept more than one kind of input how a user could know the list of accepted inputs? I guess the only way to find out would be checking source and looking for all "instanceof" statements in its code. I would prefer situation when components have well-defined type of input and output and if you one to combine components for which input-output pairs do not match you should add converters as intermediate components. I've been thinking about generic but at the same time type-safe pipelines for some time. I've designed them on paper and everything looked quite promising. Then moved to implementation of my ideas and got rather disappointing result which can be seen here: http://github.com/gkossakowski/cocoonpipelines/tree/master The most interesting files are: http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline/Pipeline.java (generic and type-safe pipeline interface) http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline/PipelineComponent.java (generic and type-safe component def.) http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline/demo/RunPipeline.java (shows how to use that thing) > The only thing cocoon can help here with is to provide as much "standard" > converters for use as possible, but it is still the responsibility of the > developer to use the right ones. I think Cocoon could define much better, type-safe Pipeline API but we are in unfortunate situation that we are using language that makes it extremely hard to express this kind of generic solutions. Of course, I would like to be proven that I'm wrong and Java is powerful enough to let us express our ideas and solve our problems. Actually, the whole idea of pipeline is not a rocket science as it's, in essence, just ordinary function composition. The only unique property of pipelines I can see is that we want to access to _partial_ results of pipeline execution so we can make it streamable. This become more a brain-dump than a real answer to your e-mail Jakob, but I hope you (and others) have got my point. -- Best regards, Grzegorz Kossakowski
Re: [C3] StAX research reveiled!
Sylvain Wallez pisze: > Again I doubt of the real value of a common unified pipeline if all the > responsibility of ensuring proper compatibility between components > (including possible data conversion) is delegated to components. This > leaves a lot of complexity to component implementers (except in the > simple straightforward push scenario), and the features of the pipeline > will be limited to linking the components together and caching. I've been having similar concerns thus I'm eagerly waiting for some non-XML examples that would change my mind. > Furthermore, people will have to take great care of choosing components > that fit together, or they will get exceptions at pipeline execution > time. Hmm... reminds me of some criticism about the StAX stream API :-D LOL! :-) > So let's agree that we disagree. I'll see what you guys come up with and > hope I'll change my mind then. I just wanted to say that I share many points with Sylvain even if it's still hard for me to say which option I prefer. This will require some more thinking... -- Best regards, Grzegorz Kossakowski
Re: [c3] Pipeline results
Reinhard Pötz pisze: > > TBH I'm still not fully convinced of the parameters approach. If none is > faster than me I will prepare patches for both solutions so that we see > what it means at code level. > > I would also be interested in what others think about the two solutions > or maybe there are other alternatives that Carsten and I haven't > considered yet. Reinhard, this problem looks quite interesting and I've been about it for a while yesterday's evening. I have some idea which I'll try to describe today as soon as I address a few of my doubts. I'm writing this e-mail just to let you know that you can expect some more feedback. :-) -- Best regards, Grzegorz Kossakowski
Re: SSF Secrets or valid enhancements?
gt; +import java.net.URISyntaxException;
>
> import javax.servlet.ServletContext;
> import javax.servlet.ServletException;
> @@ -194,5 +195,15 @@
> }
>
> }
> +
> +public URI getRedirectURI() {
> + String redirectLocation = this.response.getHeader("Location");
> + try {
> + return new URI(redirectLocation);
> + } catch (URISyntaxException e) {
> + this.logger.error("problems creating correct URI...",
> e);
> + return null;
> + }
> +}
>
> }
> Index:
> src/main/java/org/apache/cocoon/servletservice/RelativeServletConnection.java
> ===
> ---
> src/main/java/org/apache/cocoon/servletservice/RelativeServletConnection.java
> (revision 731081)
> +++
> src/main/java/org/apache/cocoon/servletservice/RelativeServletConnection.java
> (working copy)
> @@ -79,7 +79,7 @@
>
> // prepare request and response objects
> this.request = new ServletServiceRequest(reqUri,
> CallFrameHelper.getRequest());
> -this.response = new ServletServiceResponse();
> +this.response = new ServletServiceResponse(reqUri);
>
> if(this.logger.isDebugEnabled()) {
> this.logger.debug("Resolving relative servlet URI " +
> this.uri.toASCIIString());
There are a few more minor things to comment on but for this iteration let's
focus on most important
stuff.
> WDYT?
>
> By the way if it is interesting for the public I can post my
> wicket-cocoon integration sample for others!
Some folks asked for it in the past and we considered this ourselves so I think
this is interesting
to others.
Thanks for your offer and for work on implementing missing pieces of SSF.
--
Best regards,
Grzegorz Kossakowski
Re: [C3] Extract SAX from the Pipeline module
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> Reinhard Pötz pisze: >>> Steven Dolg wrote: > > > >>>> I intend to finish this and provide a patch in the next 1-2 weeks. >>>> If someone is currently working on some components or modules this might >>>> lead to a merge-mess. >>>> So let me know if this might be a problem for you. >> I have some work related to both sitemap and pipeline modules but I hope my >> tools (Git) will help me >> with merging fun. >> >> Could you possibly split your work into a few smaller patches focused on one >> simple step of >> refactoring? That would make my job easier I guess. >> >> Thanks for your work. > > I guess that the only possible split is doing the renaming of classes in > one step and the creation of the SAX module in another. Apart from this > I don't think it makes much sense to create smaller patches. Yep, that's fine with me. Actually, I only care that one patch contains changes related to one isolated action (of course it's hard to define "isolated action" but I guess you can get my point). I don't care if patch is big or small because I deal with patch sets and not with change sets, usually. -- Grzegorz Kossakowski
Re: [C3] Extract SAX from the Pipeline module
Reinhard Pötz pisze: > Steven Dolg wrote: >> Hello, >> >> as indicated some time ago, I would like to remove all the SAX related >> pipeline components from the Pipeline module and put them into their own >> module. >> >> Now I have done this locally just to see how easy or difficult this >> would be. >> I found that some modules (e.g. cocoon-servlet) actually rely on those >> SAX components. >> This means the dependencies amongst the modules will change a little bit >> and the SAX module will actually be a dependency for some other >> higher-level modules. (But I find nothing wrong with that). >> But this also means the patch will be rather huge and affect a lot of >> the existing modules. >> >> I intend to finish this and provide a patch in the next 1-2 weeks. >> If someone is currently working on some components or modules this might >> lead to a merge-mess. >> So let me know if this might be a problem for you. I have some work related to both sitemap and pipeline modules but I hope my tools (Git) will help me with merging fun. Could you possibly split your work into a few smaller patches focused on one simple step of refactoring? That would make my job easier I guess. Thanks for your work. >> As second step I'd like to rename some of those components to clearly >> indicate that they're handling XML using SAX - as opposed to our new >> components using StAX. >> But I guess that can (and should) wait until the new module is there. >> >> >> Any opinions or objections on that? > > +1 > > What module and packages names do we want to use? I see two different > options: > > a) cocoon-sax (org.apache.cocoon.sax) > b) cocoon-pipeline-sax (org.apache.cocoon.pipeline.sax) > > I prefer b) because the module is a specific module for pipelines. +1 -- Best regards, Grzegorz Kossakowski
Re: [VOTE] Robin Wyles as new Cocoon committer
David Crossley pisze: > I propose Robin Wyles as a new Cocoon committer > > and PMC member. > > Robin has been participating on the users mailing list > since early 2002. Recently becoming more active and > participating on the dev mailing list. Also contributing > via our issue tracker. I find Robin's discussion to be > very helpful and collaborative. > > Voting ends one week from today, i.e. midnight UTC on Tuesday 2008-12-16 > > > > So please cast your votes. Warm: +1! -- Best regards, Grzegorz Kossakowski
Re: [cocoon3] Stax Pipelines
Reinhard Pötz pisze: > I've had Stax pipelines on my radar for a rather long time because I > think that Stax can simplify the writing of transformers a lot. > I proposed this idea to Alexander Schatten, an assistant professor at > the Vienna University of Technology and he then proposed it to his > students. > > A group of four students accepted to work on this as part of their > studies. Steven and I are coaching this group from October to January > and the goal is to support Stax pipeline components in Cocoon 3. > > So far the students learned more about Cocoon 3, Sax, Stax and did some > performance comparisons. This week we've entered the phase where the > students have to work on the actual Stax pipeline implementation. > > I asked the students to introduce themselves and also to present the > current ideas of how to implement Stax pipelines. So Andreas, Killian, > Michael and Jakob, the floor is yours! Wow, what a surprise, Reinhard! I won't comment on actual proposal until I hear some details from the research that students have made but I would like to say "Thank you" to all people involved into this effort. It's nice to hear that there will be more students involved in Cocoon! -- Best regards, Grzegorz Kossakowski
Re: [vote] Release Cocoon 3.0.0-alpha-1
David Legg pisze: > Has everyone gone to a party that I don't know about?... or maybe we're > all waiting for someone else to vote first ;-) I wish it had been a party. ;-) Some of us are doing freaky-crazy probability theory these days! Anyway, it would be good if more people could find some time and test this work even briefly. It's has an alpha status and lots of warnings so it does not have to be perfect. -- Grzegorz Kossakowski
Re: [vote] Release Cocoon 3.0.0-alpha-1
Reinhard Pötz pisze: > I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-1. > > You can find the staged files for all modules (sources, binaries, > javadocs, checksums, gpg signatures) at > http://people.apache.org/builds/cocoon/ > > SVN tags of all these artifacts can be found at > http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/ > > The general distribution artifacts (tar, zip) can be found at > http://people.apache.org/~reinhard/cocoon-staging/ > > I want to stress again that this is an alpha release. This means that we > are free to change contracts without following any deprecation rules. > > This majority vote stays open for _at least_ 72 hours. Tested already Maven artifacts, and now distribution artifacts. Everything looks fine, here is mine: +1 -- Best regards, Grzegorz Kossakowski
[C3] What's the purpose of StatusCodeCollector?
Hello, The subject says all. I would like to know something about this class and convert this knowledge into some documentation. Introduction of ThreadLocal always deserves at least a few bits of explanation. -- Best regards, Grzegorz Kossakowski
Cocoon3 commit rights
Hello, I recall some discussion about commit rights to Cocoon3 that should be given explicitly to existing committers. I don't remember the result of that discussion thus I ask for such a green light. I don't have anything big to commit, just a clean-up of the code (getting rid of some warnings redundant annotations, etc.). TIA. -- Grzegorz Kossakowski
Re: Test and verify Cocoon 3 alpha-1 release artifacts
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> [EMAIL PROTECTED] pisze: >>> It took me a while but now I finished the creation of all release >>> artifacts for a Cocoon 3 alpha-1 release. Since this is the initial >>> creation of Maven artifacts and distribution files, I don't call for a >>> vote at this point of time but rather want to wait for some feedback. >> Hi Reinhard. Thanks for preparing all of these. I've finally found some time >> to bustle around your work. >> >>> I would like to ask you to check the release artifacts whether they meet >>> the legal requirements (checksums, pgp signatures, license files, >>> notice files) of the ASF. >> What about tags in svn? > > That's a missing feature of the Maven release plugin when you do a > multi-module release. The plugin only tags the root module, in our case > http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-root/cocoon-root-3.0.0-alpha-1/ Is this only my feeling that release plug-in does nothing useful? I mean here that it does some unintelligent editing of your POMs that: 1. Does not resolve SNAPSHOT versions to correct released versions (but to some random ones) 2. May result in corrupted POM (e.g. it can remove deployment info). Is it only me who had a bad experience with this plug-in? > I will copy the directories manually before I call for a vote. Thanks. I'm sorry that you have to do it manually... -- Grzegorz Kossakowski
Re: Servlet protocol and internal pipelines
Robin Wyles pisze:
>>
>> Actually, I don't understand how you solved this problem so probably
>> the best thing would be if you
>> could show me the patch (since it's one-liner).
>
> Patch against o.a.c.components.treeprocessor.sitemap.PipelineNode is
> attached.
Ahhh, I didn't think of using scheme. It turns out that SitemapServlet (thus
sitemap machinery) has
this one single method to recognize that request is coming from ssf and not
from browser.
Still this looks a little bit dangerous so I would like to see it applied along
with something like:
if (we allow request by recognizing "servlet" scheme)
logger.warn("Following request has been allowed to access internal-only
pipeline by using not
fully secure method:" + request);
Of course message should little bit more relevant that this is only potential
security whole which
is rather hard to use.
>
> I'll take a look and see if I can come up with something this week.
Great, as soon as you provide a good integration test I'm happy to commit it.
> On another note - I have a requirement to test how several cocoon 2.2
> blocks interact with each other via REST, on deployment these blocks are
> split into separate webapps that are hosted in different locations, but
> I guess for testing these could be combined into a single webapp. Is
> this something that I can achieve using the cocoon-it block?
I guess so but it's really Reinhard that is an expert in this area.
BTW. Are you going to connect blocks deployed to different machines using SSF?
This is something
I've been thinking for a while.
--
Grzegorz Kossakowski
Re: [c3] Why Cocoon 3 doesn't use the expression language modules from 2.2
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> As I was already playing with Cocoon3 I decided to have a closer look >> at source code of it. There are many nice things about it (probably >> the most important one is that this code is much cleaner than what we >> have in c2.2). Nevertheless, what I found surprising is that you >> decided to rewrite EL and OM handling from scratch once again. Was >> there any specific reason for doing that apart from "let's throw out >> the whole c.2.2's core"? > > The 2.2 object model is a solution to many problems (e.g. see the > markLocalContext() and cleanupLocalContext() methods, support for > hierarchies, usage together with a jx template) that Cocoon 3.0 > doesn't have. > The object model of Cocoon 3 is really focused to provide a read-only > context to expression languages. The object > model + the Jexl language interpreter implementation don't even account > for 50 lines of code. Maybe we could have saved a few lines of them by > using the 2.2 cocoon-expression-language-* modules (+ all the transitive > dependencies) but this seemed to be a rather high price for little outcome. Ok, let's see how this evolves. >> I don't recall any discussion about that particular decision. > > No there was no common decision. But don't be afraid that C3 is carved > in stone yet. The release that I will propose is tagged with 'alpha' and > this means that we are free to change things whenever we need. > Ok. You skipped my point on missing tags in svn. Do you know why they are missing? -- Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Luca Morandini pisze: > > Hmm... given the above, I'd rather concentrate on views and sitemap, > like: standardizing the expression language between sitemap and JX > templates, better support to JSON, etc. Standarizing expression is a task more for 2.3. Actually most of the code is already in place. There are only a few open bugs that are blocking this to happen. It's a pity I'm not able to tackle them... > >> Thanks for reading so far. > > Don't mention, it was a pleasure. > > Regards, > > P.S. > If people keep insisting on functional languages, I will launch my bid > for a total conversion of Cocoon to the one and only OO language: > Smalltalk ! > ;) That would be dangerous. ;-) -- Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Sylvain Wallez pisze: > Grzegorz Kossakowski wrote: >> I guess this e-mail is already long enough to cut it here. If you are >> interested in my ideas on providing functional implementation of >> sitemap (that would be inspired by some characteristics of bash) I >> could write a little bit more on it with some details. >> > > Interesting thoughts, especially as I am myself interested in functional > programming, which I started with Javascript, then learned Erlang and > looked at Scala as a very interesting way to bring those programming > paradigms to the Java platform. Hi Sylvain. Thanks for your comments. Great integration of Scala with Java is one the most important reasons why I brought Scala into this discussion. For others reading this thread: Scala's code compiles to a binary format understood by JVM so you can use Java code from Scala code and the opposite way. > Now we have to think about what this community is about, and what we can > do to make it successful again. An open source community is a delicate > balance between interest of developers in developing the product, and > interest of users in actually using the product. The concept of > "interest" covers many different aspects: for developers, this includes > a combination of hacking pleasure, pure altruism, strengthening a > business related to the product, socializing with like-minded people, > etc. For users, it includes being able to be efficient and productive, > finding support from developers and other users, and being able to > understand the product to tune it and ultimately write bugfixes and > patches, opening the way to committership. > > The Cocoon community has been a bit special in this regard, since Cocoon > allows to do quite complex stuff with a small amount of "code" (sitemap > and XSLT are code) and without requiring strong programming skills. I > remember someone sending a "Thank you" email, explaining how Cocoon > allowed him to do stuff he wouldn't have been able to do without it, and > thus start a consulting business that allowed him to work from home and > spend more time with his family. How rewarding for us developers! Cocoon > allows less skilled users to _do_ stuff, and skilled developers to be > highly productive. This is why this complex product attracted brillant > innovation but at the same time was more accessible to average people > than less sophisticated products. Yep, that's a great description of Cocoon strengths. The question that comes to my mind is if we still continue to maintain these characteristics? > Looking at our website, I think we have forgotten what forms our > community: "Apache Cocoon is a Spring-based framework (since version 2.2 > of Cocoon) built around the concepts of separation of concerns and > component-based development. Cocoon implements these concepts around the > notion of component pipelines, each component on the pipeline > specializing on a particular operation." Ok, that looks like an answer to the above question. ;-) > Well, Cocoon old-timers understand what it means (at least roughly in my > case, as I never digged into blocks). Now put yourself as a newcomer, > especially a less skilled person representing the largest part of our > users. What the heck is this Cocoon stuff all about? What kind of > problems does it solve? How is it different/better than other products I > can find at Apache and elsewhere? > > Cocoon has been very successful by being a superb integration platform > for everything that can be represented as XML, and there are blocks for > every Apache-compatible library that can produce or consume XML. Even > music, and I've seen people's jaws dropping when I showed them the Bach > prelude being processed in XSLT. Over time blocks have accumulated, the > framework has been abstracted and modularized to become even more > flexible and address even more problems, but this came with a price: > newcomers simply can't grasp what Cocoon is about. > > Also, Cocoon has been an incredible source of innovation, with its > component architecture, the ReSTful sitemap, the mighty (but complex) > portal, server-side scripting, continuations, etc. But the outside world > has also innovated, and new frameworks/techniques have emerged, at all > levels of the stack: Spring as a replacement for Avalon, Wicket for > complex forms, GWT and many others for Ajax, aggregated pages and > portals are now replaced with Ajax gadgets, etc. > > The newer products aren't necessarily easier to use, but are probably > easier to grasp because they do less, or have more introductory > material, or are more "standard" (i.e. widely accepted, be it for good > reasons or
Re: Where is Cocoon 3 going to?
Torsten Curdt pisze:
>> Honestly I have no opinion on an implementation of the sitemap engine in a
>> functional language.
>> Perhaps it's just me, but I fail to see the reason to do so.
>
> I didn't bother to search the archives ... and this might also been
> beer talk during GetTogethers where this came up before ...but IMO the
> point is not use necessarily a "functional language" but a language
> that is more suited for the job.
You probably have in mind thread started by Ugo Cei "[RT] A Groovy Kind of
Sitemap"[1]. I'm still in
process of reading all replies.
Yep, the real point is to use something better than our current sitemap
language. I have chosen
functional language (namely Scala) because it's my current field of interest
and because I can see
benefits coming from using it.
To point out just a few:
1. More concise and natural syntax. What about pipeline looking like:
FileGenerator("a/template.xml") | XSLTTransformer("b/sth.xslt") |
MyTransformer | HTMLSerializer
This is a plain Scala with a few things defined correctly. Scala has a nice
support for creation
of DLSs, see[2]
2. Ad-hoc defintions of simple transformers.
3. Debugging support for sitemap.
4. Strong typing for sitemap.
> Using XML for the sitemap IMO turned out to be a very bad idea in
> retrospect. (Well, everything is XML - right) On the other hand
> writing a sitemap in a common language (javascript or something
> similar) will lead to terrible abuses (as you would only need a subset
> of whatever you pick). Coming up with your own DSL has become so
> simple that this would be my choice now these days.
Actually I don't believe that we can stop people making stupid things simply by
designing a good
software. Definitively we should encourage people to use our software the
proper way but working
hard on obstacles is more questionable.
Anyway, DSL-like syntax is possible in Scala.
> I have already seen so many people adopt the sitemap concept in other
> projects. (I wish httpd would adopt it!) But everyone came up with
> their own implementation. "I just need a little sitemap engine". Let's
> face it the component re-use in that aspect is a bit of a myth. (Poll:
> how many people re-use cocoon components in other projects as is?)
>
> Maybe it's time to learn from the Cocoon strengths and turn parts of
> it into APIs. The pipeline API is a good example. I guess this is the
> only way to revive Cocoon's future.
+1 for that.
I guess we all agree that we want to create something more than just a pipeline
API and its
implementation, right?
Anyway, it's good that this work has started. Rewriting from scratch but based
on our expierience
brings some new opportunities.
[1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/39351
[2] http://www.scala-lang.org/node/104 (Scala is extensible section)
--
Best regards,
Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
into question if it's not a tool (Java) that makes it too easy for me to make simple bugs. These days it's rather common saying that if you write a big application in Java you have to cover it with both test-cases and integration tests in order to avoid obscure bugs and long debugging sessions. I was the one saying the same, actually. However, I started to realize that this approach seems to be broken to some extent. In test-case you execute actions that are meant to check whether your code follows the behaviour you intended to describe in original code. What about a language that is precise and abstract enough that lets you describe what it should really do (read what you really mean) instead of what kind of actions it should perform? What about a language that is immune to most of simple bugs in code we make because it simply does not operate at level were this bugs are made? I happen to attend lectures on mathematical logic and subject called "Languages, Automata and Computations" which give me lots of insights into the subject we are discussing. Even if my understanding of the subject is at introductory level I've got more and more reasons to think that languages can be powerful enough to express your needs so precisely that unit testing and similar surrogates are not needed in most situations. This is only heuristic claim based on some theorems I've learned, though. > ... Usually does not have all the fluff around the basic core, like > utilities, error messages, handling of special cases or exceptions, and > so on ... that will also make your code multiply in size. Actually the XSLT processor follows specification when it comes to error reporting. Anyway, you are right that in general all boring details make our code bigger but still not 100 times bigger or so... > Obviously, there are languages which are easier than Java, more concise, > more performant and all the rest, functional approach is easier than > passing Runnables, there are no doubt about the fact that our industry > is young and there is huge space for new technologies, and probably > Cocoon would greatly benefit from some of them. Yep, that's my whole idea. This community used to be very innovate (maybe not so good at marketing but we all know that already) and I would like to put at least some parts of Cocoon at bleeding edge again. Neither I'm a salesman trying to sell you a hype nor I feel like a chosen one to change a world of programming. I simply believe that Cocoon community would benefit from a little bit of functional programming. > But take these revolutionary claims for what they are : propaganda, not > necessarily real facts, or at least not THAT MUCH as they try to > demonstrate. Actually, as I've already said I've cited such claims to spur a discussion and I have more deep insights into whole subject. Anyway, we both understand that nobody here wants to listen to a _very_ abstract talk on language theory that would support my current interests and the whole excitement about them. Moreover, I take into account that I might be simply wrong and there is no added value coming with functional languages. However, we'll never know until we experiment with some real world application. Cocoon's reimplementation looks like a perfect chance and here I simply ask if others are interested in experimenting. PS. Thanks for your comments Simone. It's been a long time since we talked last time! -- Best regards, Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Steven Dolg pisze: >> >> I second this ask. Bombing us with patches that are not discussed here >> is what we all want to avoid. >> > The number of patches from Simone hardly qualifies for being called > "bombing". Actually the issue mentioned has exactly one patch. > > Furthermore I doubt every single change needs to be discussed here > before it is made. > Something as straightforward as "cache the XSLT to avoid parsing it > every single time the pipeline is executed" is IMO one of those things > that should be obvious to everyone. The idea is obvious, the implementation details as we can see are not so obvious. > Especially since - as Sylvain pointed out - "this feature has been > available in Cocoon for ages". Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to be rewritten. The idea is not to write detailed plan that is almost comparable with final implementation but simple saying "I'm going to implement this and this, using this and this. If someone wants to comment. Go ahead." A few sentences, right? > Not everyone is fond of reading long emails that sketch a vague picture. > A clear description of the problem, a suggested solution and a patch > that provides a working implementation is IMO sometimes preferable. > Everyone is able to have a look at the jira issues and the posted > patch(es) and comment on them just like Sylvain did. After studying recent issues on COCOON3 I have to admit that level of discussions has increased which makes me happy. There are several reasons why things should be discussed here. One of them is that one can grasp what has happened during his offline period. As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap, Steven! -- Grzegorz
Re: Where is Cocoon 3 going to?
Reinhard Pötz pisze: > Simone Tripodi wrote: >> Hi All, >> just to notify you that Steven ad I already started working on a >> caching system in cocoon3 more that 3 weeks ago, maybe the jira's >> issue can provide you more infos. > > Simone, is there more information available than > https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you > please give us pointers or otherwise provide us with a summary > explaining what you both are working on? > > Many thanks in advance! > I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid. -- Best regards, Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> Cocoon 3.0 started by Reinhard looked promising to me but now I >> realize that the main idea of its existence is to more or less >> rewrite C2.2 and add some RESTful features. > > Yes, that's explained by the first paragraph of the Cocoon 3 website. Ahhh right, I've looked at source code of C3 but forgot about the website. Apparently, I have to check recent developments of C3. > You probably have missed it but with Simone we actually have one very > active committer and I know that many other people are fond of the > Cocoon 3 pipeline module. Yes, sort of. > Currently the main problem is that most developers don't know that there > is such a simple thing as the Cocoon 3 pipeline library. I've already > started to provide documentation but haven't got very far yet. But be > assured that it has a very high priority on my opensource todo list. Good to hear that. Some advertising company on e.g. Pipeline library that would show us it's potential would be useful but it might be that I ask for way too much. ;-) >> Has anyone here thoughts on this topic or it's only me who has a >> problem? > > When I started Cocoon 3 my main goal was to solve two problems: 1) > provide a plain and simple pipeline API that is easily usable from > within any Java environment 2) make Cocoon a simple platform for RESTful > services. > This made *me* excited about it and solves *my* problems. I haven't done > any market research about what would have excited others. It would be very nice if you could provide some more details how it solved your problems and what kind of problems. I suspect that you have lots of ideas how this thing should evolve and what kind of new opportunities it brings to us. I would really like to help you with building up the community but before I can start doing that I need a solid background, a vision so I can guide others. That's why I'm asking for all of that all of the time. > Anyway, I don't think that it makes much sense to talk about what an > anonymous mass of people might want. So Grzegorz and all others reading > this, what would make *you* excited about Cocoon 3 so that *you* would > be willing to contribute? Actually, I find myself at the crossroads now. I haven't done anything really pleasant that would make me happy with C2.2. The COCOON-2216 issues almost killed my whole motivation when it comes to C2.2. I feel like the time I can hack C2.2's core is over for me. Until someone helps me with this I will probably stay away of C2.2 completely because this issue blocks most of my plans when it comes to C2.2. That's a reason for me to look for something new. SSF should get some attention so SAX forwarding is implement and some caching bugs are fixed. Anyway, I would like to leave this task for someone else as it's a bad situation that it looks like only me and you have an idea what's going on there. I want someone else to become involved. So the only thing left is C3. What would make me excited? The best thing would be to rewrite C3 in some pure functional language like Haskell. ;-) Ok, that's a joke but an introduction to something more serious. I've been off-line a while which was a perfect chance to read some books and papers. Let's start with a quote from a master thesis "Implementing an XSLT processor for the Haskell XML Toolbox" by Tim Walkenhorst[1]: "The processor is written in a purely in Haskell 98 and does not make use of any advanced libraries. [...] It might be possible to make the implementation even shorter and more concise by using this features; however, the basic implementation should enable interested volunteers to gain familiarity with the code rather quickly. The entire implementation has about 1800 lines of code and is thereby 192 times smaller than the XALAN Java implementation which has about 347000 lines of code.[...] Of course, we could not implement the full functionality of such a huge tool within one master thesis; however, it should be possible to perform the most common kinds of stylesheet transformations within the subset of XSLT we implemented." You read it correctly. The XSLT processor implemented with 1800 lines of Haskell vs 347000 lines of Java. I've checked features and parts of specification that are not implemented and I found that they don't form a big portion of the whole specification and seemed to be rather trivial implement. Of course, this processor does not additional features of Xalan like support for debugging, etc. Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in 2000 lines of Java? I cannot. Even more surprising, I can moderately easily read that code even if I'm not fluent in Haskell. I guess I&
Re: Daisy is down
David Crossley pisze: > > Thanks, i think that Grek and Jasha were talking about > project management type tasks. For most of these, only the > Cocoon PMC members have the wherewithal to carry them out. David, you are generally right but there are some tasks that are crossing boundaries like this one: http://article.gmane.org/gmane.text.xml.cocoon.devel/79044 Our samples are down due to some bug in Maven which seems to be more or less already identified. The task is to contact Maven developers, report them this bug and maybe cooperate on fixing it. Meanwhile, some ugly work-around should be introduced on our zone. The first part of this task does not require any special rights. Anyone can pick this up. > As a developer, you can certainly help in other areas. > > One thing is to generally browse our issue tracker and see > what takes your interest. Perhaps fix some, comment on others. > These changes are alerted to this dev@ mail list, which might > spark the interest of others. > https://issues.apache.org/jira/browse/COCOON Maybe I'm speaking too much from my own position but I believe that the most urgent issue is this: http://article.gmane.org/gmane.text.xml.cocoon.devel/79192 Why I think it's so important: 1. Any multi-thread processing of a request is completely broken. 2. This blocks last step of introduction of unified expressions into Cocoon (notably into sitemap) and deprecating a big portion of old code. Actually, this issue and the fact that I cannot fix it makes me so ashamed that I've lost any motivation to work on anything related to Cocoon. > Another would be to try the examples on the zone server. > Create issues for anything that needs attention. > http://cocoon.zones.apache.org/ Yes, this is for someone that wants something easier to work on. Another very important thing is helping Jeremy with Dojo migration: http://article.gmane.org/gmane.text.xml.cocoon.devel/78940 Unfortunately, I don't have a time to provide any valuable in-depth feedback at the moment. -- Grzegorz Kossakowski
Re: Daisy is down
David Crossley pisze: > Jasha Joachimsthal wrote: >> Grzegorz, >> >> is there an overview of "badly needed-to-be-done" tasks (Jira?)? Maybe >> others can take over >> some of them (if they are documented or otherwise with the help of someone >> with the knowledge). >> > > Grek listed two "badlies" below. Another is to ensure that the zone > configuration is all safe in > our SVN. > > See some details at > https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/ > > Also a simple search of our mailing list shows various info about the Daisy > backup issue. Here > are some only: http://cocoon.zones.apache.org/daisy/documentation/1346.html > http://markmail.org/message/jojhpmlqwoqlz4l6 > https://issues.apache.org/jira/browse/COCOON-1925 > > We also need to ensure that all contributors have a CLA on file at ASF. I > started to do that but > got busy and put it on hold. > > More below ... Yep, generally speaking our zone really requires some love. > Van: Grzegorz Kossakowski: >> Ross Gardler pisze: >>> Can someone please kick the Daisy server on the Zone. >> Done. >> >> A side-note: We badly need to upgrade Daisy to 2.x version and we badly need >> to take care of >> backups of Daisy installation. >> >> Another side-note: I observe that we have a number of "badly needed >> to-be-done" tasks but there >> is a constantly decreasing number of people willing to take care of them. >> This leads me >> personally to a question about the future of this community. >> >> -- (worried) Grzegorz Kossakowski > > One thing that we need to do, is to continually refresh the base of > committers/PMC members. > Please each committer look around to see new people who should be committers. > Propose them on the > private@ mail list, because we don't talk about people in public. Maybe it's only me who sees it and continuously complain about it but I don't think that the root cause is in lack of active committers/PMC members. I think this is just a result of the fact that we seem to lost any vision on how to run and develop this project. Cocoon 3.0 started by Reinhard looked promising to me but now I realize that the main idea of its existence is to more or less rewrite C2.2 and add some RESTful features. It's not my intention to criticize anyone but I really think it's not enough to make others excited and willing to contribute. At least it looks that way... Has anyone here thoughts on this topic or it's only me who has a problem? -- Best regards, Grzegorz Kossakowski
Re: Test and verify Cocoon 3 alpha-1 release artifacts
ase is that I fail to see where this project is heading to and what are its goals and aims. I would feel rather strange voting for a release of something that I don't fully identify with. To sum up my situation: +1 from technical point (provided you fix tags) +0 from my own personal point of view I would really like to know how to convert 0 into 1. Anyway, thanks for your work. -- Best regards, Grzegorz Kossakowski
Re: How to get spring beans with Cocoon Template 1.0?
Thorsten Scherler pisze:
>> It introduces a dependency on very specific implementation that may change
>> in the future.
>
> That is true. Like I wrote in the first mail, would be awesome to have
> cocoon.spring.getBean('NameOfBean').
Personally, I don't like this kind of solution as well because I think one
should follow push
approach instead of pull approach when it comes to access to the data from
template. I think the
best is to make available to ObjectModel (thus to expressions and templates)
what is really needed.
If different blocks need different things that you don't know in advance then
implement different
ObjectModelProviders for each block. Maintenance cost of such solution is much
lower.
>> Thorsten and Roy, if you really need to access some beans from expressions I
>> suggest to add them to
>> ObjectModel by implementing ObjectModelProvider interface.
>
> Hmm, is there any documentation about how to this. I mean how can I
> create a cocoon.spring.getBean('NameOfBean') factory?
No but the whole concept is so easy that I can explain it within a few words
here.
Take a look at existing implementation of ObjectModelProvider[1] for 'cocoon'
object[2][3]. The
ObjectModelProvider is a bean implementing a very simple interface. The name
convention of that bean is:
org.apache.cocoon.el.objectmodel.ObjectModelProvider/[the-name-of-the-variable]
So if you implement your own ObjectModelProvider and name bean with:
org.apache.cocoon.el.objectmodel.ObjectModelProvider/spring
You will be able to access it from top level using "spring" variable. The
object returned by
provider might be anything you like. It might be a simple map, dynamic map
listing all beans or just
a custom class with custom method that will do whatever you want.
You don't need to register ObjectModelProvider in any way. Following naming
convention is enough.
>> This way you can easily control what
>> exactly the template can access and you remove dependency on specific
>> implementation.
>
> IMO a template should be able to access all beans from cocoon. If we
> want to limit the access one can think about adding security to
> cocoon.spring.getBean('NameOfBean') which checks whether the template is
> allow to access the bean. Wee bit like using
> http://www.acegisecurity.org/ for that part.
That might be another approach to tackle problems with security. Anyway, while
writing my original
comment I was having in mind more design problems and simple separation of
concerns. Template should
be able to access what it really needs and nothing more.
[1]
http://cocoon.apache.org/2.2/core-modules/expression-language-api/1.0/apidocs/org/apache/cocoon/el/objectmodel/ObjectModelProvider.html
[2]
http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/objectmodel/impl/CocoonEntryObjectModelProvider.java?revision=636423&view=markup
[3]
http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml?view=markup
--
Grzegorz Kossakowski
Re: Servlet protocol and internal pipelines
Robin Wyles pisze: > It seems the check on the pipeline type and environment type is done by > o.a.c.components.treeprocessor.sitemap.PipelineNode, I made a simple > patch here that checks the request's scheme; if it is 'servlet' and the > pipeline is internal only, then processing is allowed to continue. While > not ideal, I think this method poses less of a security risk than using > a special request attribute. Also it's only one extra line in one class. > WDYT? Actually, I don't understand how you solved this problem so probably the best thing would be if you could show me the patch (since it's one-liner). >> I believe implementing such a functionality on both SSF and >> Sitemap-engine sides would be rather >> easy task and I'm willing to help with preparing the patch and >> applying it. I would require a valid >> test-case for it before it gets accepted. > > Can you give me some hints as to how I can write a unit test for this? > I'm familiar with writing tests for sitemap components but I'm not sure > how to set up a test pipeline and set its attributes accordingly. I believe this would be very hard to cover with plain, simple unit test so I think integration test is needed. Then it's rather trivial, you just build pipelines (by providing sitemap.xmap) and you test what has been returned in special JUnit class. See: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-webapp/src/test/java/org/apache/cocoon/it/ (contains JUnit classes) http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-it/src/main/resources/COB-INF/ (contains sitemap.xmap and rest of the resources) Don't ask me why these things have such a weird locations. Reinhard, can you comment on it? -- Best regards, Grzegorz Kossakowski
Re: Daisy is down
Ross Gardler pisze: > Can someone please kick the Daisy server on the Zone. Done. A side-note: We badly need to upgrade Daisy to 2.x version and we badly need to take care of backups of Daisy installation. Another side-note: I observe that we have a number of "badly needed to-be-done" tasks but there is a constantly decreasing number of people willing to take care of them. This leads me personally to a question about the future of this community. -- (worried) Grzegorz Kossakowski
Re: Servlet protocol and internal pipelines
Robin Wyles pisze: > Hi, > > Apologies for posting on the dev list, but I've been asking this for a > while on users and am still searching for an answer (I'm kind of > desperate now!) Sorry for not responding on users mailing list. I've been offline for some time and didn't have a touch with a project. > In the default sitemap generated with the block archetype there is a > pipeline as follows: > > > > > > > > > On the docs page linked to above it states that blocks may have > "internal resources that are accessible to other block via servlet: > protocol". However, from my tests it seems that internal-only pipelines > are still not accessible via the servlet protocol. So, out of the box > any matchers placed in the above pipeline result in a > SourceNotFoundException when accessed via the servlet protocol. > > Can any devs please confirm whether: > > 1. Internal pipelines *should* be accessible via the servlet protocol. Yes, it should be. > 2. Internal pipelines *are* accessible via the servlet protocol. No they aren't. > If 1 is true and 2 is false then I'm very surprised that this hasn't > been bought up before on the user list as it seems to contradict the > documentation and also severely limit the usefulness of the servlet > protocol - I can't believe we're supposed to leave our SSF only > pipelines accessible to the world at large! I have a test block here > that demonstrates the issue if anyone is interested... Actually, I've been aware of this problem for a long time but never got myself to fix it, which is a shame, of course. The thing is about SSF's design, it's really designed such a way that request coming from SSF looks very the same way as it was coming from an external client (like browser). That's been done on purpose in order to avoid any hidden dependencies between SSF and Cocoon's core. As a consequence of this design, there is no way how sitemap processor can allow requests coming from SSF to access internal-only pipelines. When it comes to documentation, it was written before the actual implementation was made and later on the whole issue has been forgotten. I don't recall the proposal for implementing this functionality but probably the simplest possible approach would be to introduce common contract that both sides (SSF and Cocoon's Core) agree to follow but the one that does not introduce any hard dependencies on each other. This leaves implementing special interface (indicator) out of consideration. Nevertheless, SSF could still indicate that coming request is performed internally by adding some special request attribute. This might be a potential security hole so I would classify such a solution a temporary one. I believe implementing such a functionality on both SSF and Sitemap-engine sides would be rather easy task and I'm willing to help with preparing the patch and applying it. I would require a valid test-case for it before it gets accepted. -- Grzegorz Kossakowski
Re: Ask for a help with multi-thread problems (COCOON-2216)
Grzegorz Kossakowski pisze: > Hello, > > Having (finally) some free time again I decided to give COCOON-2216 another > try. Unfortunately, I > wasn't entirely successful with my latest attempt even if there seems to be > progress. > > Actually, you don't need to follow my previous attempts and comments to > understand what's going on > with latest patches trying to fix this annoying bug. Current problem is that > it looks like I get > into some race conditions but I have no idea how to track them. > > Little background: the problem was with the ObjectModel that was shared > between child threads > leading to illegal state. The solution was to clone ObjectModel object so > separate instances are > used across different child threads. I decided to bind ObjectModel to > Environment (as it felt rather > natural to do so) and to implement cloning in AbstractCocoonRunnable. > Moreover, there is a custom > bean factory that returns an ObjectModel instance obtained from the current > Environment. > Additionally, this instance is being wrapped by a proxy so we can be sure > that other beans always > reference correct instance of the ObjectModel. > > You can find my modifications here: > http://github.com/gkossakowski/apache-cocoon/commits/COCOON-2216-multi-thread-simple > > If you wonder why this is uploaded to Github the answer is rather simple - I > believe that it's > better way to share patches so they are available for online browsing along > with commit messages > before they get committed to trunk. Imran provided us a test-case that nicely > exhibits problems with > both our implementation in Cocoon's trunk (or lack of it) and these race > conditions in my > implementation. The code is available here: > https://issues.apache.org/jira/secure/attachment/12391183/test-block.zip > (referenced from > https://issues.apache.org/jira/browse/COCOON-2216) > > How to reproduce: > 1. Download patched Cocoon sources from > http://github.com/gkossakowski/apache-cocoon/commits/COCOON-2216-multi-thread-simple > and compile them. > 2. Download test-block, run it using mvn jetty:run. > 3. Point your browser to http://localhost:/test-block/index.html > 4. Check console if information about exceptions are being printed out. > > > I would kindly ask multi-thread-programming gurus to have a look at this > problem as I feel like > running out of ideas and energy... > Anyone even have a plan to look at it? Otherwise I'll have to definitively resign from fixing this issue which will mean that Cocoon 2.2.x will have any multi-thread processing completely broken. These are *BAD* news. -- Best regards, Grzegorz Kossakowski
Re: How to get spring beans with Cocoon Template 1.0?
Thorsten Scherler pisze:
> On Thu, 2008-11-20 at 09:31 +0100, Thorsten Scherler wrote:
>> On Wed, 2008-11-19 at 22:06 +0800, 黄海冬公司邮箱 wrote:
>>> codes:
>>> >> value="${cocoon.context.getAttribute(Packages.org.springframework.web.contex
>>> t.WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE)}"/>
>>>
>>>
>>> Roy Huang
>> Thanks very much Roy, will it try now.
>
> Works like a charm, thanks again Roy!
There is one problem with this solution: it's ugly.
It introduces a dependency on very specific implementation that may change in
the future.
Thorsten and Roy, if you really need to access some beans from expressions I
suggest to add them to
ObjectModel by implementing ObjectModelProvider interface. This way you can
easily control what
exactly the template can access and you remove dependency on specific
implementation.
--
Grzegorz Kossakowski
Ask for a help with multi-thread problems (COCOON-2216)
Hello, Having (finally) some free time again I decided to give COCOON-2216 another try. Unfortunately, I wasn't entirely successful with my latest attempt even if there seems to be progress. Actually, you don't need to follow my previous attempts and comments to understand what's going on with latest patches trying to fix this annoying bug. Current problem is that it looks like I get into some race conditions but I have no idea how to track them. Little background: the problem was with the ObjectModel that was shared between child threads leading to illegal state. The solution was to clone ObjectModel object so separate instances are used across different child threads. I decided to bind ObjectModel to Environment (as it felt rather natural to do so) and to implement cloning in AbstractCocoonRunnable. Moreover, there is a custom bean factory that returns an ObjectModel instance obtained from the current Environment. Additionally, this instance is being wrapped by a proxy so we can be sure that other beans always reference correct instance of the ObjectModel. You can find my modifications here: http://github.com/gkossakowski/apache-cocoon/commits/COCOON-2216-multi-thread-simple If you wonder why this is uploaded to Github the answer is rather simple - I believe that it's better way to share patches so they are available for online browsing along with commit messages before they get committed to trunk. Imran provided us a test-case that nicely exhibits problems with both our implementation in Cocoon's trunk (or lack of it) and these race conditions in my implementation. The code is available here: https://issues.apache.org/jira/secure/attachment/12391183/test-block.zip (referenced from https://issues.apache.org/jira/browse/COCOON-2216) How to reproduce: 1. Download patched Cocoon sources from http://github.com/gkossakowski/apache-cocoon/commits/COCOON-2216-multi-thread-simple and compile them. 2. Download test-block, run it using mvn jetty:run. 3. Point your browser to http://localhost:/test-block/index.html 4. Check console if information about exceptions are being printed out. I would kindly ask multi-thread-programming gurus to have a look at this problem as I feel like running out of ideas and energy... -- Best regards, Grzegorz Kossakowski
Re: [jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
imran pariyani (JIRA) pisze: > [ > https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636376#action_12636376 > ] > > imran pariyani commented on COCOON-2216: > > > hi Grzegorz, > > in the article there was something about "Lack of a Standard Thread-Pooling > Library " .. now > there is a standard which comes with the JDK .. i don't know if we are using > that or not .. but > it is possible that it might take care of the ThreadLocal variables .. just a > thought. Had a brief look and I fear that it's not that easy but I'm not an expert in this field. > should i forward this discussion to the dev mailing list ? Yes, please. I have a really shaky internet access these days so any help is greatly appreciated. I hope others more experienced with multi-thread problems can give us some hints how finally tackle this problem. -- Grzegorz
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636361#action_12636361 ] Grzegorz Kossakowski commented on COCOON-2216: -- Imran, It's my time to apologize. I didn't read your previous description carefully enough. Now I could reproduce your problem which is just a sign of much bigger problem. IncludeCacheManager uses thread pooling technique which does not play nicely with ThreadLocals, see: http://java.sys-con.com/node/37241 As I said this problem is not limited to the newly introduced Factory for ObjectModel. Servlet Service Fw and Spring itself use ThreadLocals as well. I think this is a right time to move this discussion to dev@ list so others can comment. I'll be probably in favour of removing thread pooling completely but I don't know performance implications at the moment. > IncludeCacheManager can not perfom parallel includes > > > Key: COCOON-2216 > URL: https://issues.apache.org/jira/browse/COCOON-2216 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) >Reporter: Christoph Gaffga >Assignee: Grzegorz Kossakowski > Attachments: cocoon-trunk.patch, > multi-thread-simple-28.09.2008.patch, > ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, > test-webapp.zip, test-webapp.zip > > > Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple > sources from other cocoon pipelines into one (similar to the aggregator) is > not working anymore. > We also posted our problem to the mailing list, got little feedback but it > brought us on the right way... > see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html > I found out that it's a problem with the DefaultIncludeCacheManager, that can > not do parallel inclusion of cocoon-pipelines anymore. I checked several > classes where inclusion is used. In the aggregator parallel inclusion is not > an option anymore, in CIncludeTransformer the IncludeCacheManager is used, > but it can't do parallel inclusion. In the new IncludeTransfomer parallel > inclusion is supported, but it does not use caching as it does not use the > IncludeCacheManager... > But we needed caching AND parallel processing, so I tried to find out what's > broken in the DefaultIncludeCacheManager: > and it seems that the ThreadLocal variables are not initialized for the child > threads that do the inclusion. Neither the spring context nor the old > environment stuff was initialized. And all the source resolving was done > outside the child thread and that way using the wrong thread context. > We were able to fix that issue by small changes to DefaultIncludeCacheManager > and IncludeCacheManagerSession. It would be great if somebody could apply > this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.2 samples down
Jasha Joachimsthal wrote: > I just tried to start up the "My first block" with "mvn > -Djetty.port=8123 jetty:run" but it still uses port . This is weird. For me this worked yesterday. Only when setting jetty.port using MAVEN_OPTS Maven ignored that setting. > Only when I > comment the part in the pom.xml it listens to port 8123. So > I think the configuration in the pom overrides the commandline port. > Which should be the opposite way. What version of Maven and jetty plugin do you use? -- Grzegorz
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[
https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636201#action_12636201
]
Grzegorz Kossakowski commented on COCOON-2216:
--
Hi Imran,
Sorry for next delay - this time I'm moving to a new flat.
When it comes to your problem I've looked into sources of JX templates and
found:
Attr 1 :${cocoon.request.getParameter('attr1')}
I believe it should look like:
Attr 1 :${cocoon.request.getAttribute('attr1')}
After applying this change both parameters and attributes works fine for me. Is
there anything else missing? I would like to start polishing of my patch so it
can be applied to trunk.
> IncludeCacheManager can not perfom parallel includes
>
>
> Key: COCOON-2216
> URL: https://issues.apache.org/jira/browse/COCOON-2216
> Project: Cocoon
> Issue Type: Bug
> Components: - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
> Reporter: Christoph Gaffga
>Assignee: Grzegorz Kossakowski
> Attachments: cocoon-trunk.patch,
> multi-thread-simple-28.09.2008.patch,
> ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip,
> test-webapp.zip, test-webapp.zip
>
>
> Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple
> sources from other cocoon pipelines into one (similar to the aggregator) is
> not working anymore.
> We also posted our problem to the mailing list, got little feedback but it
> brought us on the right way...
> see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html
> I found out that it's a problem with the DefaultIncludeCacheManager, that can
> not do parallel inclusion of cocoon-pipelines anymore. I checked several
> classes where inclusion is used. In the aggregator parallel inclusion is not
> an option anymore, in CIncludeTransformer the IncludeCacheManager is used,
> but it can't do parallel inclusion. In the new IncludeTransfomer parallel
> inclusion is supported, but it does not use caching as it does not use the
> IncludeCacheManager...
> But we needed caching AND parallel processing, so I tried to find out what's
> broken in the DefaultIncludeCacheManager:
> and it seems that the ThreadLocal variables are not initialized for the child
> threads that do the inclusion. Neither the spring context nor the old
> environment stuff was initialized. And all the source resolving was done
> outside the child thread and that way using the wrong thread context.
> We were able to fix that issue by small changes to DefaultIncludeCacheManager
> and IncludeCacheManagerSession. It would be great if somebody could apply
> this patch so we don'T have to patch every cocoon version again and again...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 2.2 samples down
Grzegorz Kossakowski pisze: > Jasha Joachimsthal pisze: >> Hi there, >> >> the samples of 2.2 are (still) down [1]. Does anyone know how to bring >> them up again? >> >> [1] http://cocoon.zones.apache.org/demos/trunk/ > > Logs[2] do not reveal anything trivial so I guess this might be caused by my > last activity on zone > related to upgrade of Maven to 2.0.9 and Java to 1.5. > [2] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/ > > I may have a look today's night or tomorrow. Found the cause - Maven starts jetty using wrong (default) port number, see the last line of the log[3]: 2008-10-01 16:11:14.548::INFO: Started [EMAIL PROTECTED]: After quick testing at my local computer it looks like settings from MAVEN_OPTS environment variable are not propagated to jetty:run plug-in. In order to test it try: cd core/cocoon-webapp export MAVEN_OPTS="-Djetty.port=8123" mvn jetty:run and check at which port jetty listens. If it's not 8123 then we have found a bug and we should report it to Maven team. If anyone confirms this problem I'll introduce temporary fix so our demos are online again. [3] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/stderr.log PS. If someone else could take care of it I would be grateful. I don't have any reliable internet connection in my new flat now. -- Grzegorz Kossakowski
Re: 2.2 samples down
Jasha Joachimsthal pisze: > Hi there, > > the samples of 2.2 are (still) down [1]. Does anyone know how to bring > them up again? > > [1] http://cocoon.zones.apache.org/demos/trunk/ Logs[2] do not reveal anything trivial so I guess this might be caused by my last activity on zone related to upgrade of Maven to 2.0.9 and Java to 1.5. [2] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/ I may have a look today's night or tomorrow. Thanks for reporting. -- Grzegorz
Re: COCOON3 Jira project
Reinhard Pötz pisze: > Reinhard Pötz wrote: >> Dear Apache Infrastructure team, >> >> on behalf of the Cocoon PMC I would like to ask for the creation of a >> new Jira project "COCOON3". > > Tony Stevenson of the Apache Infrastructure team reacted promptly and > created the COCOON3 Jira project for us: > > https://issues.apache.org/jira/browse/COCOON3 > > Thanks a lot Tony! > > I've already created the list of components and versions. If you find > any bugs or want to provide a patche, I'd be happy to see them filed in > Jira now. Nice. Reinhard, are you going to take care of Corona component in COCOON jira project? There is one issue assigned to that component, see: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310170&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12312258 -- Grzegorz
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635591#action_12635591 ] Grzegorz Kossakowski commented on COCOON-2216: -- I'm glad to hear that it works for you. Is your test-case covering the issue with request attributes? How can I see this problem myself? At the moment I have no clue on what might be happening when it comes to request attributes. > IncludeCacheManager can not perfom parallel includes > > > Key: COCOON-2216 > URL: https://issues.apache.org/jira/browse/COCOON-2216 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) >Reporter: Christoph Gaffga >Assignee: Grzegorz Kossakowski > Attachments: cocoon-trunk.patch, > multi-thread-simple-28.09.2008.patch, > ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip > > > Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple > sources from other cocoon pipelines into one (similar to the aggregator) is > not working anymore. > We also posted our problem to the mailing list, got little feedback but it > brought us on the right way... > see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html > I found out that it's a problem with the DefaultIncludeCacheManager, that can > not do parallel inclusion of cocoon-pipelines anymore. I checked several > classes where inclusion is used. In the aggregator parallel inclusion is not > an option anymore, in CIncludeTransformer the IncludeCacheManager is used, > but it can't do parallel inclusion. In the new IncludeTransfomer parallel > inclusion is supported, but it does not use caching as it does not use the > IncludeCacheManager... > But we needed caching AND parallel processing, so I tried to find out what's > broken in the DefaultIncludeCacheManager: > and it seems that the ThreadLocal variables are not initialized for the child > threads that do the inclusion. Neither the spring context nor the old > environment stuff was initialized. And all the source resolving was done > outside the child thread and that way using the wrong thread context. > We were able to fix that issue by small changes to DefaultIncludeCacheManager > and IncludeCacheManagerSession. It would be great if somebody could apply > this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
imran pariyani (JIRA) pisze: > [ > https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635531#action_12635531 > ] > > imran pariyani commented on COCOON-2216: > > > hi , > > tried to apply the patch to the current trunk .. but it keeps giving this > error > > ERROR [main] (ContextLoader.java:214) - Context initialization failed > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name > 'org.apache.cocoon.ajax.impl.servlet': Invocation of init method failed; > nested exception is > org.springframework.beans.factory.BeanCreationException: Could not create > configuration for > TreeProcesoor; nested exception is java.net.MalformedURLException: unknown > protocol: blockcontext > > > something seems to be broken in the trunk ... i will get the version from git > and try to build > with that ... in the mean while the error above is it because of the new dojo > which we integrated > with cocoon .. it builds successfully but when starting jetty it throws that > error .. do u get > the same error when starting the jetty server ? This looks like an old problem with cocoon-servlet-service-impl and cocoon-core but has been fixed a few weeks ago. Are you sure that all of your SNAPSHOT dependencies has been rebuilt? To answer your question directly: No I don't have any problem and I could run your test-case using mvn jetty:run directly from block. It displayed the page with CForm and parallel includes successfully. -- Grzegorz
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2216: - Attachment: multi-thread-simple-28.09.2008.patch Hello, I just wanted to let you know that I've finally tackled this problem using much more simpler approach than the one I planned to use. Anyway, it looks like this patch fixes the specific problem you have. There are two important notes, though: 1. This patch was tested using your test-case and regular Cocoon samples only 2. This patch is still not a *complete* solution to all OM-related problems that I'm aware off but brings us much closer to final solution because it at least fixes issue with multi-thread environments. I'd would appreciate any feedback on it (testing) before I continue to work in this direction. Also, I've published my local Git branch established for changes related to this issue, see: http://github.com/gkossakowski/apache-cocoon/tree/COCOON-2216-multi-thread-simple You can easily clone this repo using: git clone git://github.com/gkossakowski/apache-cocoon.git and then switch to my local branch using git gui command. Another method is just using download button so you download the entire source code. I mention this second method of getting my changes (instead of patch) because it's more likely that my repository at GitHub will be up-to-date with my changes compared to patches attached to JIRA. Moreover, it's easier to analyse my changes using GitHub website. > IncludeCacheManager can not perfom parallel includes > > > Key: COCOON-2216 > URL: https://issues.apache.org/jira/browse/COCOON-2216 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) > Reporter: Christoph Gaffga >Assignee: Grzegorz Kossakowski > Attachments: cocoon-trunk.patch, > multi-thread-simple-28.09.2008.patch, > ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip > > > Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple > sources from other cocoon pipelines into one (similar to the aggregator) is > not working anymore. > We also posted our problem to the mailing list, got little feedback but it > brought us on the right way... > see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html > I found out that it's a problem with the DefaultIncludeCacheManager, that can > not do parallel inclusion of cocoon-pipelines anymore. I checked several > classes where inclusion is used. In the aggregator parallel inclusion is not > an option anymore, in CIncludeTransformer the IncludeCacheManager is used, > but it can't do parallel inclusion. In the new IncludeTransfomer parallel > inclusion is supported, but it does not use caching as it does not use the > IncludeCacheManager... > But we needed caching AND parallel processing, so I tried to find out what's > broken in the DefaultIncludeCacheManager: > and it seems that the ThreadLocal variables are not initialized for the child > threads that do the inclusion. Neither the spring context nor the old > environment stuff was initialized. And all the source resolving was done > outside the child thread and that way using the wrong thread context. > We were able to fix that issue by small changes to DefaultIncludeCacheManager > and IncludeCacheManagerSession. It would be great if somebody could apply > this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
