Re: JNet integration
Joerg Heinicke wrote:
On 25.03.2008 10:53, Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest
form, I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for simple use cases of a pipeline API.
Yes, I understand that when it comes to caching pipelines, you need
more, but not everybody needs caching pipelines. For that purpose
there could be a CacheableFileGenerator, etc.
If you are right and it is difficult or even impossible to remove the
dependencies on source/sourceresolve/xmlutils/jnet, then be it. I
withdraw my example Url(servlet:...) from above. When we can switch
to sourceresolve 3.0, the dependency graph will get smaller anyway.
The main benefit from using URLs (instead of the SourceResolver) comes
from simple use cases, e.g. you need a pipeline in your Java
application that reads in some XML file, performs some transformations
and finally creates a PDF document. FWIW, using URLs should be all
that you need.
Hmm, I don't see the advantages of dropping the Source abstractions. Why
giving up all the good things just to remove one dependency?
I'm not talking about giving up the Source abstraction (as long as there is no
equivalent replacement in the Java Standard API) but to put it on top of
java.net.URL.
What are
the downsides of the Source abstraction?
When we are able to introduce a pipeline API, we don't need it for simple use
cases. The concept of URLs is well-known in the Java world, the Source
abstraction is not.
I never had the need to
implement a Source and for the mentioned simple cases I wonder where you
have to cope with them at all? Cocoon used to be a framework for
non-Java developers ... even if we introduce a pipeline API as in the
examples in this thread why do I need to care about Urls or Sources at
all? Why should it be different then map:generate with its src
attribtue? And when I read CacheableFileGenerator something tells me
this approach is wrong.
What's the advantage of giving our components the responsibility to deal with
strings that represent sources?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: JNet integration
It seems that this topic is even more interesting than the environment abstraction threads we had a while back :) Ok, first of all, the sourceresolver is a very cool component and I really like it (and it was also me who started this component years ago :) ). As the java api lacks such kind of an abstraction, its good to have it. Other approaches like the Spring resource stuff are not as good as they are not very flexible. So, it doesn't make sense to drop this stuff for Cocoon - seeing Cocoon as the big framework for building web applications. But on the other side we are talking about making Cocoon more modular and easier to understand. The Corona work is a great start and for me it makes totally sense to base the core api just on the java net stuff. It's much easier to understand and use. When we were doing Cocoon trainings, it was always a little bit difficult to get the point across that people should use the source resolver and not the file api or the java net api. Not a big deal, but still it adds more new stuff on top of the core api than you might need. While the source resolver, source factory and source interfaces are of great use, I'm not so sure about the extensions of the source interface like modifiable source or traversable source. I rarely needed them through the years, but your mileage might vary. Caching is very important and the java api does not provide a very good way to support caching in general. The source abstaction was built with caching in mind. If you look at the pipeline caching we have in cocoon it is rather complicated (it can cache partial pipelines etc.), and during the years we switched for a time based/event based caching of complete pipelines. But again your mileage may vary. The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: JNet integration
On 26.03.2008 03:34, Reinhard Poetz wrote: I never had the need to implement a Source and for the mentioned simple cases I wonder where you have to cope with them at all? Cocoon used to be a framework for non-Java developers ... even if we introduce a pipeline API as in the examples in this thread why do I need to care about Urls or Sources at all? Why should it be different then map:generate with its src attribtue? And when I read CacheableFileGenerator something tells me this approach is wrong. What's the advantage of giving our components the responsibility to deal with strings that represent sources? Isn't that what components are there for? Encapsulating commonly used functionality? Why should I extract that to the pipeline *instance* level? So writing pipelines is becoming a mess! Joerg
Re: JNet integration
Joerg Heinicke wrote: On 26.03.2008 03:34, Reinhard Poetz wrote: I never had the need to implement a Source and for the mentioned simple cases I wonder where you have to cope with them at all? Cocoon used to be a framework for non-Java developers ... even if we introduce a pipeline API as in the examples in this thread why do I need to care about Urls or Sources at all? Why should it be different then map:generate with its src attribtue? And when I read CacheableFileGenerator something tells me this approach is wrong. What's the advantage of giving our components the responsibility to deal with strings that represent sources? Isn't that what components are there for? Encapsulating commonly used functionality? Why should I extract that to the pipeline *instance* level? So writing pipelines is becoming a mess! Hmm, I don't think so. Imagine a pipeline java api just taking a uri for the sources used in the pipeline. That's simple and easy. Now, you can use the source resolver on top of that, resolve your sources and you get a uri from your source that you can put into the pipeline api. That's neither a mess nor does it require more java coding. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: JNet integration
Carsten Ziegeler wrote: Hmm, I don't think so. Imagine a pipeline java api just taking a uri for the sources used in the pipeline. That's simple and easy. Now, you can use the source resolver on top of that, resolve your sources and you get a uri from your source that you can put into the pipeline api. That's neither a mess nor does it require more java coding. That sounds good in theory, but the proof is in when you actually try to do it with caching enabled. As I said, I'm not really too interested in the non-caching use case as I view that as the minority use case. Furthermore, the non-caching use case can always be dealt with by using the caching use case and just turning off the cache. So you build this pipeline API that only uses java.net. Now you want to build pipelines that cache. Does the Source now have to show through the caching version of the pipeline API? If it does you will have a real mess as now users of pipelines have to determine whether they are caching or non-caching just to determine what methods they can use. Ralph
Re: JNet integration
On 26.03.2008 08:04, Carsten Ziegeler wrote: What's the advantage of giving our components the responsibility to deal with strings that represent sources? Isn't that what components are there for? Encapsulating commonly used functionality? Why should I extract that to the pipeline *instance* level? So writing pipelines is becoming a mess! Hmm, I don't think so. Imagine a pipeline java api just taking a uri for the sources used in the pipeline. That's simple and easy. Now, you can use the source resolver on top of that, resolve your sources and you get a uri from your source that you can put into the pipeline api. That's neither a mess nor does it require more java coding. I'm not sure if we are talking about the same. If I take Reinhard's sample [1] URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); and want to add caching to it and therefore have to switch from URL to Source and from FileGenerator to CachingFileGenerator - sorry, but that's a mess since this means pretty much rewriting the application for adding caching. Why is this page so slow? Oh, sorry we forgot this pipeline to switch to caching ... Why can't high-level pipeline components use low-level components like SourceResolver? Then it is up to the component to use either URLs or Sources. That would be like implementing CacheableProcessingComponent or not. That's why I wonder where a pipeline writer gets into uri resolving at all? Why does he have to care about URLs or Sources? That's the component developer's concern. I really wonder if I miss something. All this seems to be too obvious to me ... Joerg [1] http://marc.info/?l=xml-cocoon-devm=120646488429681w=4
Re: JNet integration
Ralph Goers wrote: Carsten Ziegeler wrote: Hmm, I don't think so. Imagine a pipeline java api just taking a uri for the sources used in the pipeline. That's simple and easy. Now, you can use the source resolver on top of that, resolve your sources and you get a uri from your source that you can put into the pipeline api. That's neither a mess nor does it require more java coding. That sounds good in theory, but the proof is in when you actually try to do it with caching enabled. As I said, I'm not really too interested in the non-caching use case as I view that as the minority use case. Furthermore, the non-caching use case can always be dealt with by using the caching use case and just turning off the cache. :) Sure, I have many use cases for pipelines where I don't need caching at all - like some processing pipelines that are not used for creating web responses. So you build this pipeline API that only uses java.net. Now you want to build pipelines that cache. Does the Source now have to show through the caching version of the pipeline API? If it does you will have a real mess as now users of pipelines have to determine whether they are caching or non-caching just to determine what methods they can use. Hmm, ok, I have not thought about this very deeply, so I don't have an answer yet and perhaps there is no good answer and it might turn out that all this is not a good idea. But :) without looking further into it, I have the feeling that it should be possible to build a clean layered architecture that solves all our problems. And perhaps it turns out that it might make more sense to use the sourceresolver throughout all of these layers. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: JNet integration
Joerg Heinicke wrote: I'm not sure if we are talking about the same. If I take Reinhard's sample [1] URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); Ok, up to here we are talking about the same :) Adding the sourceresolver and sources to the above example and let the sources return the urls should be easy. That's more or less what you do today. and want to add caching to it and therefore have to switch from URL to Source and from FileGenerator to CachingFileGenerator - sorry, but that's a mess since this means pretty much rewriting the application for adding caching. Why is this page so slow? Oh, sorry we forgot this pipeline to switch to caching ... Ah, no no, I'm not saying this :) There should only be one file generator. Let's use the above example: you setup the pipeline as shown above and then do a: Pipeline cachingPipeline = new CachingPipeline(pipeline); Et voila! That's all you have to do. Now, as I answered to Ralphs mail, I don't know if this is possible or how to do it right now. So it might turn out that it's not or it's not worth doing it. That's why I wonder where a pipeline writer gets into uri resolving at all? Why does he have to care about URLs or Sources? That's the component developer's concern. The pipeline writer needs to know how uri resolving works. He needs to know what input values are allowed, what relative values mean etc. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: JNet integration
Carsten Ziegeler wrote: It seems that this topic is even more interesting than the environment abstraction threads we had a while back :) Ok, first of all, the sourceresolver is a very cool component and I really like it (and it was also me who started this component years ago :) ). As the java api lacks such kind of an abstraction, its good to have it. Does it? It seems to me the URLConnection class provides the same level of abstraction and functionnality than a Source. Other approaches like the Spring resource stuff are not as good as they are not very flexible. So, it doesn't make sense to drop this stuff for Cocoon - seeing Cocoon as the big framework for building web applications. But on the other side we are talking about making Cocoon more modular and easier to understand. The Corona work is a great start and for me it makes totally sense to base the core api just on the java net stuff. It's much easier to understand and use. When we were doing Cocoon trainings, it was always a little bit difficult to get the point across that people should use the source resolver and not the file api or the java net api. Not a big deal, but still it adds more new stuff on top of the core api than you might need. While the source resolver, source factory and source interfaces are of great use, I'm not so sure about the extensions of the source interface like modifiable source or traversable source. I rarely needed them through the years, but your mileage might vary. Caching is very important and the java api does not provide a very good way to support caching in general. The source abstaction was built with caching in mind. Hmm... If this is just about Source.getSourceValidity which is optionally implemented (non-caching source can simply return null), we could equally well have a CachableURLConnection. If you look at the pipeline caching we have in cocoon it is rather complicated (it can cache partial pipelines etc.), and during the years we switched for a time based/event based caching of complete pipelines. But again your mileage may vary. The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. The main need for the Source abstraction was to circumvent the staticness of URLStreamHandlerFactory. Otherwise, pretty much everything we need is there: - extensible framework for cacheable, modifiable, traversable, whatever-able sources with URLConnection sub-classes, - integrated parsing/conversion features with the getContent() method - source-resolving using the URL(URL context, String spec) constructor The staticness problems of URLStreamHandlerFactory are still there in the JVM, but the OSGi/Equinox guys have found creative ways to circumvent them on most JVMs. If we're happy with this solution, it seems to me the Source abstraction is one of the many cocoon-isms we should consider to gently deprecate just as the copy of the servlets that we have in our environment abstraction. Fewer new concepts to learn for newcomers, fewer specific concepts that hinder the integration of Cocoon with other environments. My 0.02 euros (which are worth their $ these days!) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: JNet integration
Carsten Ziegeler wrote: Joerg Heinicke wrote: That's why I wonder where a pipeline writer gets into uri resolving at all? Why does he have to care about URLs or Sources? That's the component developer's concern. The pipeline writer needs to know how uri resolving works. Still: Why? He needs to know what input values are allowed, what relative values mean etc. Have to think about this part. Regards, Florian
Layered software designs
Carsten Ziegeler wrote:
The question is now if we need support for caching in the low level apis
or if it is possible to have a layered approach - which would make the
entry barrier much easier.
Yes, this layered approach is what I'm aiming for. All the reactions in this
thread make me think that everybody, who has commented on this mailing list so
far (except Carsten), believes that we want to throw away good things that have
profed to be useful in many situations.
Rest assured, that's not the case. Carsten and I only want to break up this
all-or-nothing situation that we (still) have now.
What I want to see is a concise pipeline API that comes with only little
overhead in terms of its learning curve and its dependencies on third-party
software. Usually this means that we stick with standard APIs as much as
possible - and I think this rule applies for our situation too.
This means that the user of the API only needs to learn as little as possible.
When he wants more, we offer additional modules that help him. Since he has a
concrete need, the motiviation to learn something new is much higher than when
he has to learn everything right from the beginning.
If you want to learn how this whole concept *might* apply for a next generation
Cocoon, have a look at Steven's and my Exploring Corona mail from last week
(http://marc.info/?l=xml-cocoon-devm=120611990603725w=2).
The idea of Corona is having a concise core that doesn't have any dependencies
on a particular component container (Spring, OSGi, etc.), source resolving
mechanisms or environment (http, java only, etc.) or even the type of the
components (XML-SAX event stream, XML-Stax event stream, binary streams, etc.)
that are linked together in a pipeline.
A simple scenario could be:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you
are:
Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring
XML-SAX
componnents
This layered approach makes Cocoon easily embeddable in any Java application and
Cocoon's learning curve becomes more gradual.
Is such a situation only appealing to Carsten, Steven and me?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Reinhard Poetz wrote: Carsten Ziegeler wrote: The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. Yes, this layered approach is what I'm aiming for. All the reactions in this thread make me think that everybody, who has commented on this mailing list so far (except Carsten), believes that we want to throw away good things that have profed to be useful in many situations. Rest assured, that's not the case. Carsten and I only want to break up this all-or-nothing situation that we (still) have now. What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. This means that the user of the API only needs to learn as little as possible. When he wants more, we offer additional modules that help him. Since he has a concrete need, the motiviation to learn something new is much higher than when he has to learn everything right from the beginning. If you want to learn how this whole concept *might* apply for a next generation Cocoon, have a look at Steven's and my Exploring Corona mail from last week (http://marc.info/?l=xml-cocoon-devm=120611990603725w=2). The idea of Corona is having a concise core that doesn't have any dependencies on a particular component container (Spring, OSGi, etc.), source resolving mechanisms or environment (http, java only, etc.) or even the type of the components (XML-SAX event stream, XML-Stax event stream, binary streams, etc.) that are linked together in a pipeline. A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Your mail makes things a little bit more clear. But (maybe I have missed some mails) how do you want to make this Pipeline API? E.g. a SAX-based pipeline is something different than image data running through several filters. How do you want to prevent the use of a SAX-events generating component together with an image data transformer? What about something like it's used in clipboards: each component offers a list of importable and exportable formats? Just my 2 Räppli :-) Florian
Re: Layered software designs
Dev at weitling wrote:
But (maybe I have missed some mails) how do you want to make this
Pipeline API?
E.g. a SAX-based pipeline is something different than image data running
through several filters. How do you want to prevent the use of a
SAX-events generating component together with an image data transformer?
What about something like it's used in clipboards: each component offers
a list of importable and exportable formats?
See http://marc.info/?l=xml-cocoon-devm=120611990603725w=2
Do the explanations that this mail answer your question?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Reinhard Poetz wrote: Dev at weitling wrote: But (maybe I have missed some mails) how do you want to make this Pipeline API? E.g. a SAX-based pipeline is something different than image data running through several filters. How do you want to prevent the use of a SAX-events generating component together with an image data transformer? What about something like it's used in clipboards: each component offers a list of importable and exportable formats? See http://marc.info/?l=xml-cocoon-devm=120611990603725w=2 Do the explanations that this mail answer your question? Quote from the text: We hope that this gives you enough hints in order to understand Corona. We are very interested in further discussions. So fire at will! My Answer: Great work! And yes, it answered my questions :-)
Re: Layered software designs
Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know.
Re: Layered software designs
Ralph Goers schrieb: Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. Just curious - do you have doubts, that this is achievable specifically with Java, or generally with any language?
Re: Layered software designs
On Mar 26, 2008, at 9:14 AM, Reinhard Poetz wrote: A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine Do you really need both URL and SourceResolver? As Sylvain described it, with java.net.URL we should be able to implement replacement for all features of existing SourceResolver. I just don't think it is worth it, if in the end we are going to have a mix of two paradigms. Vadim
Re: JNet integration
On Wed, Mar 26, 2008 at 4:46 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: snip/ The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. We've ended up layering our own caching on top (or maybe under, depending on your POV) of much of the Cocoon caching. This is because we mainly use a single generator and serve most of our content from a database. In our case different database resources have very different cache lifetimes, we have very granular resources with very aggressive caching (very simplified example; metadata and data is pulled from the same pipeline.) Basically I've found a couple of things: - Cache key construction is the thing that matters. We allow polymorphic behavior in the cache keys so that multiple resources can resolve to the same resource. It is up to the cache key to determine what underlying resource is being accessed and not the URI. - Since we allow cache key polymorphisim we cannot use a Hashmap since a hash code look up doesn't allow two objects with different hash values to occupy the same object space. Instead we use a TreeMap that tests equality explicitly, a seperate equality test can use whatever rules it needs. - all of the call context is made available for the cache key construction, we make no assumptions on how the cache key is going manage itself, there is no such thing as different types of cache keys any cache key might be based on time to live, events, URI, request parameters and attributes, or whatever. - cache keys can register other cache keys that they are dependent on and invalidating a cache key causes resources defendant on it to also be invalidated. The important thing here is that all caching decisions are contained in a single place (the cache key). - all resource access goes through the same path. Non cached resources simply do not get a cache key, if no cache key is built the attempt to retrieve the resource from the cache is skipped (duh). Don't know if this helps any, but for us, having made this design decision our caching is completely decoupled form URI resolving (and in fact the rest of the Cocoon infrastructure). -- Peter Hunsberger
Re: Layered software designs
Vadim Gritsenko wrote:
On Mar 26, 2008, at 9:14 AM, Reinhard Poetz wrote:
A simple scenario could be:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
Do you really need both URL and SourceResolver? As Sylvain described it,
with java.net.URL we should be able to implement replacement for all
features of existing SourceResolver. I just don't think it is worth it,
if in the end we are going to have a mix of two paradigms.
I had written this before I read Sylvain's mail. Even better, if we don't need
the SourceResolver at all.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Ralph Goers pisze: Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. +1. I've got my hands dirty with URL stuff from Java and I fail to see how we can avoid using Source interface, especially when caching comes in. The issue is not about lack of the will but more about lack of ability, at least at this stage. Examine current Source/SourcaFactory/CocoonSourceResolver usage patterns to see what I mean. -- Grzegorz
Re: JNet integration
Carsten Ziegeler schrieb: The pipeline writer needs to know how uri resolving works. He needs to know what input values are allowed, what relative values mean etc. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? I believe this is a very important question. I'm sure use cases that require the ultra complex solution and use cases that will work with a more simple approach are easily found. So the question becomes What makes the most sense? and How can all this still be easy to *use*?. After all I'm convinced that at the end of the day, the way Cocoon feels for someone who uses it or - maybe even more important - for someone who thinks about using it, is all that matters. Still this shouldn't result in a total mess for all who work on Cocoon itself. But I'm sure there are way*s* (yes, more than just one ;-) ) to have all this. And I believe a layered approach is a good candicate to achieve this. But as I said above: I'm sure there is more than just one way. Carsten
Re: Layered software designs
On Mar 26, 2008, at 14:44, Ralph Goers wrote: Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Just lurking but I am with you guys. Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. IMO this would simplify a lot as it separates concerns and the inner guts can be used in other projects without the pain of dependencies we have right now. People have been asking for this for years. I really think think this is the right direction. cheers -- Torsten
[jira] Commented: (COCOON-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other
[
https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582312#action_12582312
]
Alexander Daniel commented on COCOON-2173:
--
Thanks! That's a good move that locking can be switched off.
I am still seeing the deadlock with the reproduceMultipleThreads test with the
default settings. The reason for that is that in the patched branch waitForLock
returns false when a timeout occurs which is different to the patch I provided
where true is returned when a timeout occurs.
AbstractCachingProcessingPipeline: Two requests can deadlock each other
---
Key: COCOON-2173
URL: https://issues.apache.org/jira/browse/COCOON-2173
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN)
Reporter: Alexander Daniel
Attachments: patchFor2.1.11.txt, reproduceMultipleThreads.tar.gz,
reproduceMultipleThreads2.2RC3-SNAPSHOT.tar.gz
Two requests can deadlock each other when they depend on the same resources
which they acquire in a different order. I can reproduce that in Cocoon
2.1.11 and Cocoon 2.2-RC3-SNAPSHOT:
* request A: generating lock for 55933
* request B: generating lock for 58840
* request B: waiting for lock 55933 which is hold by request A
* request A: waiting for lock 58840 which is hold by request B
I can reproduce this behaviour with Apache Bench and following pipeline:
* terminal 1: Apache Bench request A (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
* terminal 2: Apache Bench request B (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
* terminal 3: touching the two data files every second to invalidate the
cache (while true; do echo -n .; touch 55933.xml 58840.xml; sleep 1; done)
* pipeline:
map:pipeline type=caching
map:match pattern=productOfferForDevice*/*/
map:generate src=cocoon:/exists/{2}.xml label=a/
map:transform type=xsltc src=productOfferIncludeDevice.xsl
label=b
map:parameter name=noInc value={1}/
/map:transform
map:transform type=include label=c/
map:serialize type=xml/
/map:match
map:match pattern=exists/**
map:act type=resource-exists
map:parameter name=url value={1} /
map:generate src={../1} /
map:serialize type=xml /
/map:act
!-- not found --
map:generate src=dummy.xml /
map:serialize type=xml /
/map:match
/map:pipeline
After some seconds the deadlock occurs ==
* Apache Bench requests run into a timeout
* I can see following pipe locks in the default transient store:
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/58840.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
I added some logging to AbstractCachingProcessingPipeline.java which
reconfirms the explanations above:
INFO (2008-03-13) 13:50.16:072 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
INFO (2008-03-13) 13:50.16:074 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
INFO (2008-03-13) 13:50.16:075 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
PoolThread-6/AbstractCachingProcessingPipeline: generating lock
Re: unable to build cocoon forms 1.0 branch
On Mar 25, 2008, at 4:22 PM, Vadim Gritsenko wrote: Hi All, There is something wrong going with maven here. Trying to build Cocoon Forms from 1.0 branch: $ svn info URL: https://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/cocoon-forms-impl $ mvn install [INFO] Installing ~/cocoon-forms-1.0.x/cocoon-forms-impl/target/ cocoon-forms-impl-1.0.0-RC2-SNAPSHOT.jar to ~/.m2/repository/org/apache/cocoon/cocoon-forms-impl/1.1.0-SNAPSHOT/ cocoon-forms-impl-1.1.0-SNAPSHOT.jar Please note what it is doing: it installs 1.0.0 version of jar (cocoon-forms-impl-1.0.0-RC2-SNAPSHOT.jar) into repository in place of 1.1.0 version (cocoon-forms-impl-1.1.0-SNAPSHOT.jar). Can anybody take a look and fix this? Anybody knowledgeable about maven? Anybody at all? :) Vadim
Re: JNet integration
On Mar 26, 2008, at 11:09 AM, Steven Dolg wrote: Carsten Ziegeler schrieb: The pipeline writer needs to know how uri resolving works. He needs to know what input values are allowed, what relative values mean etc. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? I believe this is a very important question. Not really. Partial pipeline caching is implemented completely by the pipeline using all already existing APIs which were used by regular caching. From the perspective of pipeline class users, or from the perspective of classes which pipeline uses, there is no difference between using 'partial-response-caching' and 'complete-response- caching' pipelines. The distinction is only in private implementation details. Vadim I'm sure use cases that require the ultra complex solution and use cases that will work with a more simple approach are easily found. So the question becomes What makes the most sense? and How can all this still be easy to *use*?. After all I'm convinced that at the end of the day, the way Cocoon feels for someone who uses it or - maybe even more important - for someone who thinks about using it, is all that matters. Still this shouldn't result in a total mess for all who work on Cocoon itself. But I'm sure there are way*s* (yes, more than just one ;-) ) to have all this. And I believe a layered approach is a good candicate to achieve this. But as I said above: I'm sure there is more than just one way. Carsten
Re: CForms 1.1.0 Incompatibility
On Mar 21, 2008, at 12:42 PM, Vadim Gritsenko wrote: Hi All, When trying to use trunk version of CForms, found out API incompatibility with previous version. Namely, getLogger() method has disappeared from the JXPathBindingBase class, so any custom binding which uses logger will not compile after upgrade to 1.1.0 version. Shouldn't CForms be (as far as possible) compatible with 1.0 API? If yes... and if there are no objections... I will fix this bug. Done, as promised. Vadim
Re: unable to build cocoon forms 1.0 branch
Vadim Gritsenko wrote:
On Mar 25, 2008, at 4:22 PM, Vadim Gritsenko wrote:
Hi All,
There is something wrong going with maven here. Trying to build Cocoon
Forms from 1.0 branch:
$ svn info
URL:
https://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/cocoon-forms-impl
$ mvn install
[INFO] Installing
~/cocoon-forms-1.0.x/cocoon-forms-impl/target/cocoon-forms-impl-1.0.0-RC2-SNAPSHOT.jar
to
~/.m2/repository/org/apache/cocoon/cocoon-forms-impl/1.1.0-SNAPSHOT/cocoon-forms-impl-1.1.0-SNAPSHOT.jar
Please note what it is doing: it installs 1.0.0 version of jar
(cocoon-forms-impl-1.0.0-RC2-SNAPSHOT.jar) into repository in place of
1.1.0 version (cocoon-forms-impl-1.1.0-SNAPSHOT.jar).
Can anybody take a look and fix this?
Anybody knowledgeable about maven? Anybody at all? :)
I will look into this when I will be done with creating the release artifacts. I
don't want to pollute my system with experiments right now.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
Reinhard Poetz wrote:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
or maybe you need the full stack that corresponds to Cocoon Core 2.2 -
here you are:
Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine +
Spring XML-SAX componnents
This layered approach makes Cocoon easily embeddable in any Java
application and Cocoon's learning curve becomes more gradual.
Is such a situation only appealing to Carsten, Steven and me?
Appealing? yes. Actually implementable in Java so that it isn;t even more
complicated than what we have? I don't know.
+1.
I've got my hands dirty with URL stuff from Java and I fail to see how we can
avoid using Source interface, especially when caching comes in.
The issue is not about lack of the will but more about lack of ability, at
least at this stage. Examine current
Source/SourcaFactory/CocoonSourceResolver usage patterns to see what I mean.
Why do you want to give up even before you start? Because things _seem_ to be
difficult?
At the current stage we haven't even defined what we expect from caching. Please
let's first put all our requirements on the table.
My (and that of many others) *main requirement is a layered software design*
that makes Cocoon easily useable and embeddable in many different environments.
Given, caching is important, but compared to that it is of subordinate relevance.
Maybe we have to go back to the old Source/SourceResolver solution because
everything is impossible as some of us think, but let's decide this latter when
we are sure that there is no better alternative.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: JNet integration
Vadim Gritsenko schrieb: On Mar 26, 2008, at 11:09 AM, Steven Dolg wrote: Carsten Ziegeler schrieb: The pipeline writer needs to know how uri resolving works. He needs to know what input values are allowed, what relative values mean etc. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? I believe this is a very important question. Not really. Partial pipeline caching is implemented completely by the pipeline using all already existing APIs which were used by regular caching. From the perspective of pipeline class users, or from the perspective of classes which pipeline uses, there is no difference between using 'partial-response-caching' and 'complete-response-caching' pipelines. The distinction is only in private implementation details. I completely agree. But aren't we the ones talking about those private implementation details... And on the other hand: If partial vs. complete caching makes no difference for the user/caller, why bother maintaining both? Vadim I'm sure use cases that require the ultra complex solution and use cases that will work with a more simple approach are easily found. So the question becomes What makes the most sense? and How can all this still be easy to *use*?. After all I'm convinced that at the end of the day, the way Cocoon feels for someone who uses it or - maybe even more important - for someone who thinks about using it, is all that matters. Still this shouldn't result in a total mess for all who work on Cocoon itself. But I'm sure there are way*s* (yes, more than just one ;-) ) to have all this. And I believe a layered approach is a good candicate to achieve this. But as I said above: I'm sure there is more than just one way. Carsten
Re: JNet integration
On Mar 26, 2008, at 12:01 PM, Steven Dolg wrote: Vadim Gritsenko schrieb: On Mar 26, 2008, at 11:09 AM, Steven Dolg wrote: Carsten Ziegeler schrieb: The pipeline writer needs to know how uri resolving works. He needs to know what input values are allowed, what relative values mean etc. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? I believe this is a very important question. Not really. Partial pipeline caching is implemented completely by the pipeline using all already existing APIs which were used by regular caching. From the perspective of pipeline class users, or from the perspective of classes which pipeline uses, there is no difference between using 'partial-response-caching' and 'complete- response-caching' pipelines. The distinction is only in private implementation details. I completely agree. But aren't we the ones talking about those private implementation details... And on the other hand: If partial vs. complete caching makes no difference for the user/caller, why bother maintaining both? It means no difference in the code, but for the user it has a real benefit - user does not have to be an expert in cocoon caching, partial response caching will give him better performance without him expending an effort into optimizing his sitemap. Vadim
[jira] Created: (COCOON-2181) POM 'org.apache.cocoon:cocoon' not found in repository
POM 'org.apache.cocoon:cocoon' not found in repository -- Key: COCOON-2181 URL: https://issues.apache.org/jira/browse/COCOON-2181 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Priority: Blocker Fix For: 2.2-dev (Current SVN) My first attempt to build Cocoon after a long time of abstinence was not successful. I checked out Revision 641352. The command mvn -P allblocks install results in this stacktrace: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:cocoon-blocks-modules:pom:6-SNAPSHOT Reason: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1259) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:745) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.cocoon:cocoon at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:571) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:524) ... 19 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:324) at
[jira] Commented: (COCOON-2181) POM 'org.apache.cocoon:cocoon' not found in repository
[ https://issues.apache.org/jira/browse/COCOON-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582336#action_12582336 ] Reinhard Poetz commented on COCOON-2181: I'm aware of this because I'm creating release artifacts. I will fix this when the work is done. POM 'org.apache.cocoon:cocoon' not found in repository -- Key: COCOON-2181 URL: https://issues.apache.org/jira/browse/COCOON-2181 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Assignee: Reinhard Poetz Priority: Blocker Fix For: 2.2-dev (Current SVN) My first attempt to build Cocoon after a long time of abstinence was not successful. I checked out Revision 641352. The command mvn -P allblocks install results in this stacktrace: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:cocoon-blocks-modules:pom:6-SNAPSHOT Reason: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1259) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:745) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.cocoon:cocoon at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:571) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at
[jira] Assigned: (COCOON-2181) POM 'org.apache.cocoon:cocoon' not found in repository
[ https://issues.apache.org/jira/browse/COCOON-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz reassigned COCOON-2181: -- Assignee: Reinhard Poetz POM 'org.apache.cocoon:cocoon' not found in repository -- Key: COCOON-2181 URL: https://issues.apache.org/jira/browse/COCOON-2181 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Assignee: Reinhard Poetz Priority: Blocker Fix For: 2.2-dev (Current SVN) My first attempt to build Cocoon after a long time of abstinence was not successful. I checked out Revision 641352. The command mvn -P allblocks install results in this stacktrace: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:cocoon-blocks-modules:pom:6-SNAPSHOT Reason: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1259) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:745) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.cocoon:cocoon at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:571) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) at
[jira] Commented: (COCOON-2181) POM 'org.apache.cocoon:cocoon' not found in repository
[ https://issues.apache.org/jira/browse/COCOON-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582339#action_12582339 ] Grzegorz Kossakowski commented on COCOON-2181: -- FYI: You can monitor build status here: http://vmbuild.apache.org/continuum/buildResults.action?projectGroupId=23projectId=51 POM 'org.apache.cocoon:cocoon' not found in repository -- Key: COCOON-2181 URL: https://issues.apache.org/jira/browse/COCOON-2181 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Assignee: Reinhard Poetz Priority: Blocker Fix For: 2.2-dev (Current SVN) My first attempt to build Cocoon after a long time of abstinence was not successful. I checked out Revision 641352. The command mvn -P allblocks install results in this stacktrace: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:cocoon-blocks-modules:pom:6-SNAPSHOT Reason: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1259) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:745) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.cocoon:cocoon at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:571) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (107 issues) Subscriber: cocoon Key Summary COCOON-2178 Array-based constructors of TreeSelectionEvent used. https://issues.apache.org/jira/browse/COCOON-2178 COCOON-2177 ImageOp with requested height width both zero should be a no-op, instead it throws an exception https://issues.apache.org/jira/browse/COCOON-2177 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2109 Incorrent cleanup of expired continuations https://issues.apache.org/jira/browse/COCOON-2109 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2063 NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 https://issues.apache.org/jira/browse/COCOON-2063 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the servlet protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on
Re: Layered software designs
Steven Dolg wrote: Ralph Goers schrieb: Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. Just curious - do you have doubts, that this is achievable specifically with Java, or generally with any language? Taking 5 or 6 concepts (interfaces?) and trying to tie them together can get quite messy in Java. C++ could use multiple inheritence. While that would work it also brings along all the problems all the problems multiple inheritence introduces. I'm sure there are other languages that might tie these concepts better, but off hand I can't think of one. I'm also sure there are some interesting ways to do this in Java. Whether they end up being complicated (either to maintain or use) remains to be seen. I'm all for letting whoever wants to move forward on this and see what they come up with. But I won't be willing to accept it until it supports caching. Ralph
Re: Layered software designs
I'm with you, too. Just as an example, I think it might be useful to use Corona as the basis for a new Ant task called Pipeline. That task could do any number text transformations to a set of files as part of a build process. Here, caching is a non-issue for the most part since the point of using a pipeline would be to process each file only once. Rather than either java.net.URL or SourceResolve, we'd probably want to feed the pipeline based on Ant resources[1], just as the existing XSLT task is fed. It may be that SourceResolver and an AntResourceSource is the best way to solve the problem, but on a cursory glance it sure looks like it is difficult to separate the banana from the gorilla[2] that is Avalon. [1] http://ant.apache.org/manual/CoreTypes/resources.html [2] http://www.ddj.com/architect/184408251 Torsten Curdt wrote: On Mar 26, 2008, at 14:44, Ralph Goers wrote: Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Just lurking but I am with you guys. Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. IMO this would simplify a lot as it separates concerns and the inner guts can be used in other projects without the pain of dependencies we have right now. People have been asking for this for years. I really think think this is the right direction. cheers -- Torsten
[continuum] BUILD FAILURE: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=69397projectId=51 Build statistics: State: Failed Previous State: Building Started at: Wed 26 Mar 2008 16:14:15 -0700 Finished at: Wed 26 Mar 2008 16:14:34 -0700 Total time: 19s Build Trigger: Schedule Build Number: 234 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon Version: 6 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1261) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:747) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central
[jira] Closed: (COCOON-2181) POM 'org.apache.cocoon:cocoon' not found in repository
[ https://issues.apache.org/jira/browse/COCOON-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz closed COCOON-2181. -- Resolution: Fixed the M2 build should work again, however, more releases will follow which means that it might be temporarily broken. POM 'org.apache.cocoon:cocoon' not found in repository -- Key: COCOON-2181 URL: https://issues.apache.org/jira/browse/COCOON-2181 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Assignee: Reinhard Poetz Priority: Blocker Fix For: 2.2-dev (Current SVN) My first attempt to build Cocoon after a long time of abstinence was not successful. I checked out Revision 641352. The command mvn -P allblocks install results in this stacktrace: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:cocoon-blocks-modules:pom:6-SNAPSHOT Reason: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-blocks-modules:pom:6-SNAPSHOT for project null:cocoon-blocks-modules:pom:6-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1259) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:745) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.cocoon:cocoon at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:571) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:206) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73)
[continuum] BUILD FAILURE: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=69527projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Wed 26 Mar 2008 20:35:16 -0700 Finished at: Wed 26 Mar 2008 20:36:03 -0700 Total time: 46s Build Trigger: Schedule Build Number: 234 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.cocoon:cocoon-databases-impl POM Location: /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.springframework:spring-dao Reason: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:998) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:801) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ...
Re: JNet integration
On 26.03.2008 09:08, Carsten Ziegeler wrote: and want to add caching to it and therefore have to switch from URL to Source and from FileGenerator to CachingFileGenerator - sorry, but that's a mess since this means pretty much rewriting the application for adding caching. Why is this page so slow? Oh, sorry we forgot this pipeline to switch to caching ... Ah, no no, I'm not saying this :) There should only be one file generator. CachingFileGenerator was something Reinhard came up with - I only explained why I considered this as starting point for a mess which you disagreed with. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? To be honest, I don't care about caching or how complex it is. It has to work and it does it nicely in Cocoon. If your name isn't Ard ( ;-) ) you usually don't need to know more details. And that's what it is as Vadim pointed out: implementation details. Joerg
Re: Layered software designs
On 26.03.2008 09:14, Reinhard Poetz wrote: What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. See, one thing that I just don't get (and already asked) is how the pipeline API has anything to do with uri resolving. For me the latter (using java.net or source resolve) is an implementation detail. Our current pipeline interface [1] has no relationship to uri resolving. It only has a reference to SourceValidity because of caching [2]. If all this discussion is about removing this method (and the related getKeyForEventPipeline()) to get rid of this dependency I'm ok with it. The caching concern could be implemented in a separate Cacheable interface which should then also be decoupled from uri resolving (which seems to point to Peter's approach [3]). Joerg [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html [2] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html#getValidityForEventPipeline() [3] http://marc.info/?l=xml-cocoon-devm=120654005017297w=4
Re: Null pointer when using Cocoon
On 23.03.2008 06:47, FreddyFlint wrote: Am new to cocoon and think have managed to install it correctly and everything but get the following error when I start tomcat Hey Freddy, it seems you have a problem with your classpath. If you look at the following lines root cause java.lang.NoSuchFieldError: JAVA_VERSION_INT org.apache.cocoon.components.language.programming.java.JavaLanguage.parameterize(JavaLanguage.java:119) you will see that Cocoon tries to access a static field on commons-lang's SystemUtils: this.compilerComplianceLevel = SystemUtils.JAVA_VERSION_INT; Nothing fancy about it, plain Java. Since this code compiles, you must have an older commons-lang.jar (Cocoon uses 2.3) on your classpath during runtime. Joerg
Re: Javaflow - major memory issue
On 18.03.2008 03:07, footh wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? Joerg
[jira] Created: (COCOON-2182) Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl
Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl -- Key: COCOON-2182 URL: https://issues.apache.org/jira/browse/COCOON-2182 Project: Cocoon Issue Type: Bug Components: - Build System: Maven, Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Kuckartz Priority: Blocker Fix For: 2.2-dev (Current SVN) $ mvn install -P allblocks for revision 641707 results in: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.cocoon:cocoon-databases-impl POM Location: /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.springframework:spring-dao Reason: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/andreas/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:996) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:799) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:525) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:525) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD FAILURE: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=69579projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Wed 26 Mar 2008 22:47:36 -0700 Finished at: Wed 26 Mar 2008 22:48:24 -0700 Total time: 47s Build Trigger: Schedule Build Number: 234 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.cocoon:cocoon-databases-impl POM Location: /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.springframework:spring-dao Reason: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM for project org.apache.cocoon:cocoon-databases-impl at /home/continuum/data/working-directory/51/blocks/cocoon-databases/cocoon-databases-impl/pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:998) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:801) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ...
