Re: InputModule assistance
I haven't gotten a response to this on user@, so I'm trying again on d...@. Can anyone point me on the right path? Thanks, --tim On Mon, Nov 9, 2009 at 9:28 PM, Tim Williams wrote: > In Forrest we've got a Locationmap InputModule. How at runtime might > we determine the sitemap context for a given request? For example, > inside getAttribute(), we'd like to have some context (e.g. called > from sitemap.xmap) for the request. I've output the objectModel map, > but nothings jumping out at me. Can anyone point me on the right > path? This request relates to FOR-770[1], btw... > > Thanks, > --tim > > [1] - https://issues.apache.org/jira/browse/FOR-770 >
XPathXMLFileModule differences
Is the new XPathXMLFileModule not a drop-in replacement for the
XMLFileModule? I'm wondering if we may have been depending on some
[?undocumented?] lazy-loading behavior of the old one or something.
In the xconf file I have:
Leading to complaints of the absence of a src attribute. Our "
It seems that the old version doesn't assume the file element exists
in the configure method:
Configuration[] files = config.getChildren("file");
for (int i = 0; i < files.length; i++) {
but the new one does...
Configuration fileConfig = config.getChild("file");
this.src = fileConfig.getAttribute("src");
I admit that I've been away from forrest for some time so perhaps
there's something I'm missing here? Any pointers appreciated...
Thanks,
--tim
Re: [RANT] This Maven thing is killing us....
On 7/2/06, Sylvain Wallez <[EMAIL PROTECTED]> wrote: Carsten Ziegeler wrote: > Now, m2 is theoretically a very good tool :) Stefano principle: you need good ideas and bad code to grow a community. I like this Stefano guy more and more every day, as I have a tendency towards both of these things, with a heavier weighting on the later;) The application of this principle in Maven is different than usual, as it forces other projects (and not only its own developers) to endure the consequences of its bugs. And this actually endangers these other projects by forbidding their developers from concentrating on actual productive work. Cocoon with all its dependencies is certainly an extreme use case for Maven compared to all others, and broken builds led some of Cocoon's major contributors to not even try 2.2 for months. And now we're wondering if users will even be able to build Cocoon if they dare to download it. The project is in danger. I discussed with several people from other projects at ApacheCon and they all report the same kind of problems: non-repeatability of builds. It works one day, but not the day after without anything having changed. Maven has gained a lot of mindshare because everybody's talking about it. Does everybody talk about their Ant build system? No, because it just works. Given Mr. Mazzocchi's principle above, I'll take this opportunity to introduce a principle from the American South (at least I think that's where it's from)... anyway... The "If it ain't broke, don't fix it" Principle. Ant has just worked in the past, I wasn't around or probably smart enough to understand why the move to maven but I can say from a user perspective it "don't work". I'm over at forrest and, for learning purposes, like to maintain a buildable trunk of Cocoon. That has been impossible since the move to maven. I obviously understand that progress happens in the face of this principle, but there are some cases where it should be respected. On a side note, I use the Cocoon code to learn forrest internals and that task has even been increasingly more difficult since the directory restructoring, which seems random at best. As you proceed with this discussion, I hope you'll appreciate that there are indirect/non-cocooners who are effected by the decisions you make... Anyway, just another perspective... And, thanks too:) --tim
Re: [RT] a simple release plan
On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote: > Reinhard Poetz wrote: > > Upayavira wrote: > > > >> Carsten has offered a suggestion that _he_ is prepared to implement. I > >> would like to hear other proposals from people of things that _they_ are > >> prepared to implement. Only that way will we move beyond this impass. > > > > There are many documents that explain the roadmap Daniel and I follow > > ATM. The only thing we are asking for is that we all work on trunk. > > Everything else is another internal fork (didn't we agree that this was > > a bad idea?) and we have to make sure again that everything gets synced > > again and again. That's the reason for the -1 on Carsten's proposal of > > Daniel and me. > > > > So what's the overhead for people that want to work on trunk? They > > should make sure that the testcases run through and they should run the > > samples before they commit. Is this such a special requirement? Does > > somebody have to understand in detail what the testcases cover? > > > > If a testcase gets broken *locally* by a developer, the developer should > > discuss the change on [EMAIL PROTECTED] and then people can decide together > > how > > to proceed. That should be the standard procedure in every development > > project, may it be opensource or commercial. > > > > Can we agree on these very basic rules? > > The overhead for people to work on trunk is that trunk is largely > unknown. It is my perception that many people have little confidence > that trunk actually works. Fear that it will change frequently, and that > they will have to invest a lot of effort (time which they don't have) in > order to keep up. > > That's the concern I'm trying to address. Not whether trunk _actually_ > works, but how people in our community _feel_ about it. It may be just Some comments from the peanut gallery... I used to keep a trunk updated and build periodically. My ability to do that went away with Mavenization. I was willing to climb a Maven learning curve, but I lost confidence when I tried to build, say 4 times, and it succeeds one time out of 4 for some unknown reason even though I didn't change anything in between builds - simply built one after another. If one can't reliably/consistently build without having to worry about lunar alignment, then they won't have confidence. This has been a long way of saying that my loss of confidence in Cocoon's trunk relates to Maven not blocks. Fix maven so that it consistently builds and you'll be a long way towards restoring trust in trunk I think. I'll just add that this previous paragraph is about my perception, not necessarily trunk's reality. In other words, it may be that I'm doing something wrong, but I've followed the various threads and instructions faithfully. --tim > 'emotion', but it really is important, as, IMO, emotion (or could I say > emotional investment) is the fundamental underpinning of our community. > If that fades away, away with it goes our community. > > I'm looking for ideas of ways and suggestions as to how our community > can move on with this more 'fuzzy' stuff - and get more of us developing > and innovating again. > > Upayavira >
Re: Using trunk
On 2/28/06, David Crossley <[EMAIL PROTECTED]> wrote: > Giacomo Pati wrote: > > David Crossley wrote: > > >Giacomo Pati wrote: > > >>David Crossley wrote: > > >>> > > >>>Would someone please help to get started with Maven. > > >>>Too many days have been wasted. > > >>> > > >>>I have today's Cocoon trunk. Installed Maven-2.0.2 > > >>> > > >>>$ cd cocoon-trunk > > >>>$ mvn -Dmaven.test.skip=true clean install > > >>>... watch thousands of warnings and stuff go by. > > >> > > >>I've very few WARNING messages (except those for old jar 'Not a v4.0.0 > > >>POM' ones, which come from 'legacy' Maven artifact. > > > > > >This was populating a brand new local repository. > > > > I've moved away my ~/.m2 directory as well just to see whethter I have > > the same problems as some of you guys had. > > > > It took quite awhile (~30 min) but I was able to compile hole trunk in > > one go. I have to admit that I'm using a Maven 2.1-SNAPSHOT build some > > weeks ago by myself (don't know if that has anything to do with it). > > > > I'm sitting here in the middle of Europe with quite a good Internet > > connectivity. > > > > >>The WARNIN message you've included above come IIRC from network problems > > >>Maven encountered during download of artifacts. Just redo again until > > >>Maven was able to resolve all dependency (and thus has donwloaded all > > >>artifacts). > > > > > >Yeah i have been doing that. Gets to a different place > > >each time. There are many warnings from various repos, > > >but it usually gets each from one of the alternates. > > > > Ok. Without having a ~/.m2 I got those lots of WARNING messages now > > as well. > > Sounds like i need to just keep banging away > with "mvn install". David, I have tried what Reinhard described above four times now. 1-Failed, 2-Failed, 3-Success, 4-Failed. It seems to fail at different locations for different reasons each time. --tim
Re: questions on store usage
On 2/20/06, David Crossley <[EMAIL PROTECTED]> wrote: > I am answering so as to keep the thread alive, > not because i know anything about stores. > > Would someone who does know, please help Tim. > Being a Forrest committer, when we get him over the > learning hump, he might be able to help fix various > Cocoon issues. > > Tim Williams wrote: > > In forrest we've got an input module that currently has it's own > > simple hashmap-caching. The assumption is that the right thing to do > > is move away from our homegrown-cache to use the cocoon store > > (TRANSIENT_STORE). > > I presume that you are referring to the Locationmap. > > The Cocoon LinkRewriterTransformer has a similar issue > http://issues.apache.org/jira/browse/COCOON-1574 > "Memory Leak with XMLFileModule" > > It has comments about needing to use the Cocoon cache. > Perhaps Ralph and Jörg can help. > > > In doing this, I've got some potentially dumb > > questions. > > Nothing is dumb. > > > Is the store somehow magically isolated or is it a global environment > > thing? In other words do I need to prefix my keys with the input > > module name to attempt to attain uniqueness? > > See a Cocoon status page and the Key id for various keys > in the current caches. Yes it needs to be unique. > http://cocoon.zones.apache.org/demos/release/samples/ > > There are docs at > "CacheableProcessingComponent Contracts" > http://cocoon.zones.apache.org/daisy/documentation/writing/corecontracts/675.html > > "Performance Tips" > http://cocoon.apache.org/2.1/performancetips.html > ... has some about the keys. > > > Do I need to do anything on dispose() to explicitly clean out my > > stored items or assume it'll push them out if it needs to? > > The store mechanism will take care of itself according to our > configuration. At Forrest we ae just using the default config > provided by Cocoon. Perhaps we need to tweak that. > > Here is a reading list, in case you had missed some :-) > Not sure how up-to-date any of it is. Also Forrest > is using Cocoon-2.2 (prior to Mavenisation) so will be > different. > > "Writing Cache Efficient Components" > http://cocoon.zones.apache.org/daisy/documentation/writing/690.html > > "Cocoon Source Resolving - Store Components" > http://cocoon.apache.org/2.1/developing/stores.html > > "Caching" > http://cocoon.apache.org/2.1/userdocs/concepts/caching.html > > "StoreJanitor" > http://cocoon.apache.org/2.1/userdocs/concepts/storejanitor.html > > -David Thanks David, After getting a little further, I have come to understand that the default transient store (MRUMemoryStore) can't handle null values[1] which we need for caching locationmap entries. The only answer so far (thanks Ralph) has been to create our own store. Since all our input module needs to cache is simple strings, I don't, at this point, think it's worth creating a custom store for forrest. --tim [1] - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113995314926899&w=2
another simple Store question
I need to be able to store null values in the "Store". I think this is causing me problems because of MRUMemoryStore. The MRUMemoryStore docs say that it's a HashMap implementation which would support my needs well. After running out of places to look, I decided to take a look at its implementation and appears to be Hash*table* implementation after all, thus apparently causing my problems. As I described in [1], we're trying to use the store in an input module but this appears to be a show-stopper. Can anyone give me an idea of what to do next? Is there a store implementation that does support null values? Is it pluggable like that? I'm very much still learning Cocoon and am at the end of where my current knowledge will take me. Any pointers would be greatly appreciated... Thanks, --tim [1] - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113977723621498&w=2
questions on store usage
In forrest we've got an input module that currently has it's own simple hashmap-caching. The assumption is that the right thing to do is move away from our homegrown-cache to use the cocoon store (TRANSIENT_STORE). In doing this, I've got some potentially dumb questions. Is the store somehow magically isolated or is it a global environment thing? In other words do I need to prefix my keys with the input module name to attempt to attain uniqueness? Do I need to do anything on dispose() to explicitly clean out my stored items or assume it'll push them out if it needs to? Also, if you can think of anything that uses the store in this way that I could use as an example I'd appreciate it -- I've yet to find anything. Thanks, --tim
[jira] Created: (COCOON-1744) NullPointerException in template block
NullPointerException in template block -- Key: COCOON-1744 URL: http://issues.apache.org/jira/browse/COCOON-1744 Project: Cocoon Type: Bug Components: Blocks: Templating Versions: 2.2-dev (Current SVN) Reporter: Tim Williams Priority: Minor Attachments: template_block.patch I have been unsuccessful actually building Cocoon so this is an untested patch. Can someone take a look and, if ok, apply to the template block? Thanks, --tim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Extending the image reader
On 1/30/06, Upayavira <[EMAIL PROTECTED]> wrote: > Tim Williams wrote: > > I want the image reader to accept a variant name (e.g. "thumb", > > "small") and then write the newly created image variant to disk before > > sending the output. In other words, so that a given image > > "IMG001.jpg" might be "read" with a variant "thumb" and on disk would > > now be: > > IMG001.jpg > > IMG001.thumb.jpg > > > > Obviously, a hefty cost for the first time through on each image but > > just reading afterwards. I've initially done this by just copying the > > entire ImageReader into a new PersistentImageReader and inserting the > > applicable code in setup() and processStream(). Now that it's working > > how I'd like, I figured I'd just extend the ImageReader and only > > implement these two methods. The only way I can think to do it is > > somehow redirect the output into a buffer, write the buffer, then send > > it out. Is there a better way to extend a reader? Anyone have any > > clues as to how I might be able to buffer the ImageReader's output? > > Well, sounds like you're trying to achieve something similar to caching. > I wonder if the caching system might be an alternative approach to > achieving the same thing. > > Anyway, to answer your question directly... > > The AbstractReader class has a setOutputStream method. You could, in > your generate() method: > * check to see if the resource has already been generated. If it has, >set the inputSource to that of your cached version and proceed as >normal (calling super.generate()) > * Otherwise, take a copy of the existing output stream, set the output >stream (using setOutputStream) to your own buffering version. Proceed >as normal. At the end of the generate method you write the contents >of buffer to disc, then copy contents of buffer to original output >stream. > > I think that would work. And this should work as an extension of the > ImageReader class as you suggest. > > Have I understood your question? > > Regards, Upayavira Exactly, I'll give these a try and see what I can manage. It is essentially the same as caching but I need something that can work in both webapp and cli modes in forrest. Thanks, --tim
Extending the image reader
I want the image reader to accept a variant name (e.g. "thumb", "small") and then write the newly created image variant to disk before sending the output. In other words, so that a given image "IMG001.jpg" might be "read" with a variant "thumb" and on disk would now be: IMG001.jpg IMG001.thumb.jpg Obviously, a hefty cost for the first time through on each image but just reading afterwards. I've initially done this by just copying the entire ImageReader into a new PersistentImageReader and inserting the applicable code in setup() and processStream(). Now that it's working how I'd like, I figured I'd just extend the ImageReader and only implement these two methods. The only way I can think to do it is somehow redirect the output into a buffer, write the buffer, then send it out. Is there a better way to extend a reader? Anyone have any clues as to how I might be able to buffer the ImageReader's output? Thanks, --tim
[jira] Commented: (COCOON-1542) File generator resolves to root context with empty src attribute
[
http://issues.apache.org/jira/browse/COCOON-1542?page=comments#action_12359173
]
Tim Williams commented on COCOON-1542:
--
Copied over from Bugzilla...
Wrapping it would help in that we would get an understandable message in return.
Why even try to resolve the src attribute if it's a null value? In other
words, why not check for a null value prior to even attempting the resolution?
Is this behavior (""==sitemaprootdir) expected/required in other parts of
Cocoon?
Thanks,
--tim
> File generator resolves to root context with empty src attribute
>
>
> Key: COCOON-1542
> URL: http://issues.apache.org/jira/browse/COCOON-1542
> Project: Cocoon
> Type: Bug
> Components: * Cocoon Core
> Versions: 2.2-dev (Current SVN)
> Environment: Operating System: All
> Platform: PC
> Reporter: Tim Williams
> Assignee: Cocoon Developers Team
> Priority: Minor
>
> When passing an empty string/null value to a file generator's "src"
> attribute, it seems to resolve to the root context (sitemap
> directory).
> For example,
>
>
>
>
>
>
>
>
>
> ...
> In the above snippet, {lm:tabs.xml} returns null but the generator
> resolves to (on my box) "C:\src\apache-forrest-lm\main\webapp" which
> throws an Access Denied exception. What I would have expected is a
> SourceNotFoundException because, after all, an empty source couldn't
> be found.
> Discussion was here:
> http://marc.theaimsgroup.com/?t=11199637902&r=1&w=2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Implementing in Forrest Locationmap
-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Hi Ross! Great to see Forrest is finally making use of the locationmap.
>I've been using it successfully myself for quite a while now.
>
>Ross Gardler wrote:
>> Quite some time ago Unico created a Locationmap module for Forrest.
>> This allows us to specify where the source file for a request is
>> located independently of the client request URL. this excellent code
>> has sat in our SVN for far too long, waiting for someone with a
>> strong enough itch to make real use of it. With the release of 0.7
>> and therefore the start of 0.8 development it has come out of hiding
>> and is now enabled in our core. It is a key part of integrating
>> repositories and CMSs such as Slide, Daisy and Lenya.
>>
>> The Locationmap code [1] reuses code from Cocoon rather than starting
>> from scratch.
>
>The part of Cocoon that is reused are Matchers and Selectors and some
>ideas in the treeprocessor package, but not the parsing and interpreting
>code of the treeprocessor itself which among other things concerns mounting.
>
>> We now need to enhance the code to allow the mounting
>> of sub-locationmaps in the same way that Cocoon can mount
>> sub-sitemaps. We are hoping that this can be done through a simple
>> reuse of Cocoon code. Unfortunately, nobody in Forrest knows the
>> insides of Cocoon well enough at this time so it would seem now is
>> time for some of us to learn...
>
>No problem, I don't think it will be too difficult. I'll try to answer
>any questions you may have as accurately as possible.
>
>> A locationmap consists of a number of matchers, for example:
>>
>> > src="http://svn.apache.org/repos/asf/forrest/trunk/site-author/content/xdocs/{1}.xml
\
>> " />
>>
>> For a complete locationmap file see
>> http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs
\
>> /docs_0_80/locationmap.xml?rev=210059
>>
>>
>> The map is built by the build(...) method in
>> org.apache.forrest.locationmap.lm.LocationMap (see
>> http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/java/org/apache/forrest/locatio
\
>> nmap/lm/LocationMap.java?view=markup )
>>
>> As can be seen in this code Unico reused much of the sitemap code
>> from Cocoon. My question is, can we also leverage the
>> code? Any pointers as to how to do this would be greatly appreciated.
>
>I mostly only reused the XML syntax not the actual tree building code
>from the treeprocessor package. For instance treeprocessor distinguishes
>between NodeBuilders and Nodes itself, I did not deem that neccessary
>for the locationmap because it is much simpler and limited in scope. But
>the mount mechanism should be similar.
I, too, would first like to say thanks for the locationmaps
I'm obviously not as familiar with Cocoon internals as I should be,
but I wonder since much of Forrest is about location resolution is
there a reason we wouldn't want to fully implement a locationmap
language? In other words, it seems like the original idea [and
perhaps the current idea] is simple and limited, but why not poise lm
for growth.
Specifically, why not extend our own DefaultTreeBuilder with
LocationmapLanguage, create a locationmap-language.xml and have a
foundation that can grow in the exact same way the sitemap language
can grow? Could the TreeProcessor not handle the two "languages"
together? Is it overkill?
>Here's a rough list of what it involves to implement:
>
>- - Create a new class MountNode that represents a statement.
>- - Add code that creates and builds new MountNode objects whenever
> is encountered (duh)
>- - Implement MountNode:locate. You'll need the same code that is in
>LocationMapModule:getLocationMap() Probably factor out into an
>accessable static method for reuse. Then call LocationMap:locate with
>the rest of the hint.
>- - There may be a need to pass the parent LocationMap's InvokeContext
>along to the child LocationMap but probably not. You'd need to change
>LocationMap:locate method signature for that and then pass the parent
>InvokeContext when constructing the child InvokeContext (I think).
>
>Hope that helps :)
It certainly does...
--tim
