Re: Help... how can I setFeature() on JaxpParser
On Aug 28, 2008, at 3:18 PM, Thorsten Scherler wrote:
not sure whether you are aware of
http://svn.apache.org/viewvc/forrest/branches/update_cocoon_2.1.12-dev/main/webapp/WEB-INF/cocoon.xconf?diff_format=hview=markup
entity-resolver logger=core.resolver
parameter name=catalog value=resources/schema/catalog.xcat/
parameter name=verbosity value=$
{org.apache.xml.resolver.verbosity}/
/entity-resolver
maybe that helps.
Thx for the reply, Thorsten! Yes, I'm aware of Cocoon's catalog
entity resolver. I've got this transformer written a long time ago by
somebody else, that uses Xerces but was not supplying any entity
resolver, so I changed it to use Cocoon's catalog-based resolver, and
it worked a lot better but was still making some network connections
in spite of this (and for some reason, I'm getting a lot of
connection refused from w3.org, all starting a couple of weeks ago,
which is weird and is what started me down this whole path of looking
at this transformer).
Finally I figured out that if I stick the whole DTD into a catalog,
Xerces no longer makes these network connections. Maybe that is what
you were getting at above. Anyway, I figured it out through kind of a
roundabout way. My original question was about setting the load-
external-dtd feature, because a guy on the Xerces list told me that
would magically fix this problem. I went ahead and did that, but it
was bum advice... it does not fix the problem, and indeed looking at
the Xerces source code I see that it has nothing to do with it. Then
I ran across this post:
http://tersesystems.com/post/658.jhtml
which confirmed what I a was seeing from experience and also looking
at the Xerces source. He goes one to describe the crushingly
obvious solution of writing a wrapper class for the EntityResolver.
But if you consider what his wrapper class is actually doing, it's
acttually a kind of degenerate, hard-coded catalog! So if you have a
catalog entity resolver already, the even more crushingly obvious
solution is to enter the DTD in a catalog. Poofo, problem solved! :-)
cheers thx again,
—ml—
Help... how can I setFeature() on JaxpParser
Hi, I very much need to set the feature http://apache.org/xml/features/nonvalidating/load-external-dtd (see http://xerces.apache.org/xerces-j/features.html#load-external-dtd) on the Xerces parser wrapped by a JaxpParser instance (returned by manager lookup of SAXParser.role). I don't see a way to do it... it looks like JaxpParser doesn't expose an interface for it. JaxpParser buries the factory instances and the parser instances pretty thoroughly and doesn't provide any handles to set features, even in the component configuration. This is for a project that's stuck on Cocoon 2.1.8, BTW. I guess I can always just create my own parser instance if it comes down to that. Before I bother, does anybody know of a way to avoid the bother? Maybe I'm missing something... cheers, —ml—
Re: Help... how can I setFeature() on JaxpParser
Never mind. I went ahead as described, creating an XMLReader and setting the EntityResolver by hand, then setting the feature. It turns out I was given some bad advice that setting the load-external-dtd feature to false would solve my problem (Xerces trying to connect to w3c.org in spite of catalog-based EntityResolver), but it doesn't fix it anyway, so... back to the drawing board. —ml— On Aug 28, 2008, at 10:22 AM, Mark Lundquist wrote: Hi, I very much need to set the feature http://apache.org/xml/features/nonvalidating/load-external-dtd (see http://xerces.apache.org/xerces-j/features.html#load-external-dtd) on the Xerces parser wrapped by a JaxpParser instance (returned by manager lookup of SAXParser.role). I don't see a way to do it... it looks like JaxpParser doesn't expose an interface for it. JaxpParser buries the factory instances and the parser instances pretty thoroughly and doesn't provide any handles to set features, even in the component configuration. This is for a project that's stuck on Cocoon 2.1.8, BTW. I guess I can always just create my own parser instance if it comes down to that. Before I bother, does anybody know of a way to avoid the bother? Maybe I'm missing something... cheers, —ml—
Standalone block sample w/ RCL?
I'm back to trying to run the ImageOp samples as a block in Jetty. I
added this to cocoon-imageop-sample/pom.xml:
build
plugins
plugin
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-maven-plugin/artifactId
version1.0.0-RC1-SNAPSHOT/version
executions
execution
idprepare/id
phasecompile/phase
goals
goalprepare/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version6.1.7/version
configuration
connectors
connector
implementation=org.mortbay.jetty.nio.SelectChannelConnector
port/port
maxIdleTime3/maxIdleTime
/connector
/connectors
webAppSourceDirectory${project.build.directory}/rcl/
webapp/webAppSourceDirectory
contextPath//contextPath
systemProperties
systemProperty
nameorg.apache.cocoon.mode/name
valuedev/value
/systemProperty
/systemProperties
/configuration
/plugin
plugin
artifactIdmaven-jar-plugin/artifactId
version2.1/version
configuration
archive
manifestEntries
Cocoon-Block-Name${pom.artifactId}/Cocoon-Block-Name
/manifestEntries
/archive
/configuration
/plugin
plugin
artifactIdmaven-eclipse-plugin/artifactId
version2.5/version
/plugin
/plugins
/build
Then I did mvn jetty:run, and I get this exception:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'org.apache.cocoon.imageop.sample.servlet'
defined in URL [file:/Users/ml/software/Cocoon/cocoon/git/dev/blocks/
cocoon-imageop/cocoon-imageop-sample/target/classes/META-INF/cocoon/
spring/cocoon-imageop-sample-blockServlet.xml]: Initialization of bean
failed; nested exception is
org.springframework.beans.InvalidPropertyException: Invalid property
'contextPath' of bean class
[org.apache.cocoon.sitemap.SitemapServlet]: No property 'contextPath'
found
at
org
.springframework
.beans
.factory
.support
.AbstractAutowireCapableBeanFactory
.doCreateBean(AbstractAutowireCapableBeanFactory.java:480)
However, the cocoon-imageop-sample-blockServlet.xml referenced by the
exception message contains this:
bean name=org.apache.cocoon.imageop.sample.servlet
class=org.apache.cocoon.sitemap.SitemapServlet
servlet:context mount-path=/cocoon-imageop-sample context-
path=blockcontext:/cocoon-imageop-sample/
servlet:connections
entry key=style-default value-
ref=org.apache.cocoon.samples.style.default.servlet/
/servlet:connections
/servlet:context
/bean
Isn't it looking to convert that context-path attribute? If so, how
come it's not working?
Thanks a lot for any help,
— Mark
Re: Proposal - JS Reader
I guess a JS reader could be helpful for applications where all resources are served directly by raw Cocoon, i.e. if any compression is to be done then Cocoon has to do it. But don't most applications in a Web setting run Cocoon behind an Apache front-end? Then you can just have Apache gzip whatever you want, all outside of Cocoon, right? And wouldn't that take care of whatever one might want to gain from using a special compressing/minifying component for a specific resource type? I could be totally wrong about this, but that's just how it seemed to me... anyway, is the use case for this specifically the scenario where un-Apache-front-ended Cocoon is being used to serve resources directly? cheers, —ml—
[jira] Created: (COCOON-2233) Update archetypes to current trunk artifact versions
Update archetypes to current trunk artifact versions Key: COCOON-2233 URL: https://issues.apache.org/jira/browse/COCOON-2233 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Patch updates artifact versions in cocoon archetypes to the current trunk versions. * Also adds BlockDeploymentServletContextListener to web.xml in the webapp archetype as required in trunk. * Some cosmetic cleanup as well -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2233) Update archetypes to current trunk artifact versions
[ https://issues.apache.org/jira/browse/COCOON-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-2233: --- Attachment: PATCH-2233 Update archetypes to current trunk artifact versions Key: COCOON-2233 URL: https://issues.apache.org/jira/browse/COCOON-2233 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Attachments: PATCH-2233 Patch updates artifact versions in cocoon archetypes to the current trunk versions. * Also adds BlockDeploymentServletContextListener to web.xml in the webapp archetype as required in trunk. * Some cosmetic cleanup as well -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON-2233) Update archetypes to current trunk artifact versions
On Aug 10, 2008, at 8:59 PM, Mark Lundquist (JIRA) wrote: Update archetypes to current trunk artifact versions Key: COCOON-2233 URL: https://issues.apache.org/jira/browse/COCOON-2233 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Patch updates artifact versions in cocoon archetypes to the current trunk versions. * Also adds BlockDeploymentServletContextListener to web.xml in the webapp archetype as required in trunk. * Some cosmetic cleanup as well I would also suggest that the cocoon-22-archetype-* Maven projects be renamed to just cocoon-archetype-*. I think it is confusing having the 22 in there. Is there a reason it has to be there? cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
debug using Jetty Launcher?
Hi, I followed the instructions here: http://cocoon.apache.org/1301_1_1.html and am able to run my Cocoon (trunk) webapp. However... maybe I'm missing something, but those instructions don't seem to say how to _debug_ the application, and the Eclipse debug start/stop controls are deactivated. What am I missing here? Also: in order to get those instructions to work, I had to tell the Jetty Launcher where to find the webapp created by the cocoon-maven- plugin. It might be worth mentioning that on this page, but I'm not exactly sure how to document that correctly. thx, —ml—
Re: debug using Jetty Launcher?
On Aug 9, 2008, at 2:21 AM, Mark Lundquist wrote: Hi, I followed the instructions here: http://cocoon.apache.org/1301_1_1.html and am able to run my Cocoon (trunk) webapp. However... maybe I'm missing something, but those instructions don't seem to say how to _debug_ the application, and the Eclipse debug start/stop controls are deactivated. What am I missing here? Never mind, figured it out. —ml— smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (COCOON-2232) Error in comment causes confusing documentation to be generated
Error in comment causes confusing documentation to be generated --- Key: COCOON-2232 URL: https://issues.apache.org/jira/browse/COCOON-2232 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Wrong Mojo name appears here: http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/prepare-mojo.html ...due to bad (old?) name in comment: --- a/tools/cocoon-maven-plugin/src/main/java/org/apache/cocoon/maven/rcl/PrepareWebappMojo.java +++ b/tools/cocoon-maven-plugin/src/main/java/org/apache/cocoon/maven/rcl/PrepareWebappMojo.java @@ -65,7 +65,8 @@ import org.w3c.dom.Document; import org.xml.sax.SAXException; /** - * The ReloadingWebappMojo creates a web application environment for a Cocoon block. + * Create a web application environment for a Cocoon block, including support + * for the reloading classloader. * * @goal prepare * @requiresProject true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How do I enable the reloading classloader in core/cocoon-webapp?
The subject says it all :-) Thx-in-advance, —ml— smime.p7s Description: S/MIME cryptographic signature
Re: How do I enable the reloading classloader in core/cocoon-webapp?
On Aug 7, 2008, at 10:13 AM, Reinhard Pötz wrote: Mark Lundquist wrote: The subject says it all :-) Thx-in-advance, —ml— The reloading classloader is only integrated with the prepare goal of the Cocoon Maven plugin. And the prepare goal creates a simple wrapper web application for a block. In regard of your question this means that there is no way to use it together with the cocoon-webapp module. All right then — well, how would I make a Cocoon webapp that can serve the samples blocks, and which uses the reloading classloader? —ml— smime.p7s Description: S/MIME cryptographic signature
Re: How do I enable the reloading classloader in core/cocoon-webapp?
On Aug 7, 2008, at 10:29 AM, Mark Lundquist wrote: All right then — well, how would I make a Cocoon webapp that can serve the samples blocks, and which uses the reloading classloader? Don't answer that, I'm gonna try to figure it out on my own. I'll ask again if I get stuck :-) cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
Re: Build samples in trunk?
On Aug 5, 2008, at 12:52 AM, Grzegorz Kossakowski wrote: Just checkout trunk (master in Git) and say: mvn clean install [-P allblocks] This -P allblocks switch is optional and probably self-explaining. right... been there and done that, but I didn't know that this built the samples too (hadn't noticed core/cocoon-webapp) then go to core/cocoon-webapp and run: mvn jetty:run right — actually have to do mvn -P allblocks jetty:run to get all the samples, I guess. Okay, my next question is: how do I turn on the reloading classloader for this webapp? thx, —ml— smime.p7s Description: S/MIME cryptographic signature
CForms version (was Re: artifact versions, samples)
On Jul 29, 2008, at 11:14 PM, Reinhard Pötz wrote: All released modules have a Download section that also contain information about how to add them as dependencies to a POM. E.g.http://cocoon.apache.org/2.2/blocks/forms/1.0/1444_1_1.html well, speaking of that one in particular... the blocks listing page http://cocoon.apache.org/2.2/blocks/ gives version 1.0 for Forms. But the site you reference above: http://cocoon.apache.org/2.2/blocks/forms/1.0/1444_1_1.html (which is linked to from the blocks listing page) gives 1.1.0 as the version. The latter appears correct, since I see: http://svn.apache.org/viewvc/cocoon/tags/cocoon-2.2/cocoon-forms-impl/cocoon-forms-impl-1.1.0/ So, questions: 1) Is the blocks listing page wrong? 2) How about the Download page? The version info on the page is correct, but shouldn't the URI be something like http://cocoon.apache.org/2.2/blocks/forms/1.1.0/whatever.html ^ ^^ ?? and, 3) What is the deal with http://svn.apache.org/viewvc/cocoon/tags/cocoon-2.2/cocoon-forms/ Does that have any function, other than to confuse people who are trying to come to grips with the tag scheme? :-) Should it be deleted? thx-a-lot... cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
Build samples in trunk?
Hi, how can I build my own samples webapp? I guess it can be done: http://cocoon.zones.apache.org/demos/trunk/ :-) I thought maybe mvn install in dists/cocoon-dist-samples, but no go; it was missing these dependencies: org.apache.cocoon:cocoon-blocks-fw-demo1:jar:1.0.0-SNAPSHOT org.apache.cocoon:cocoon-blocks-fw-demo2:jar:1.0.0-SNAPSHOT org.apache.cocoon:cocoon-blocks-fw-sample:jar:1.0.0-SNAPSHOT but that was just a guess anyway... maybe I was barking up the wrong tree here? thx, —ml— smime.p7s Description: S/MIME cryptographic signature
Re: Can somebody explain to me the tags / POM versioning / release scheme?
Okay, I'm slowly getting my head around all this. Just one thing left, I think. In order to actually build the stuff, I'm going to need a build root, i.e. an instance of project cocoon-project. I figured how which directories in tags/ correspond to things in the directory tree of this root project (e.g. core/, blocks/, parent/, tools/ etc.) (and I still have to work out how to check those modules out to a particular version in git, but I'm sure I'll be able to figure that out); however I don't see where cocoon-project itself is tagged anywhere. So... I assume that I should branch from trunk at the Subversion rev. when the cocoon-6 tags (at least for the core stuff?) were made. Is that right? I want to make sure I get pom.xml and settings.xml (anything else?) that are correct for building Cocoon 2.2 (or parts of it, anyway). What about branches/, is there anything I need to be aware of there? thx-a-lot, Mark smime.p7s Description: S/MIME cryptographic signature
Re: Can somebody explain to me the tags / POM versioning / release scheme?
On Jul 30, 2008, at 1:23 AM, Grzegorz Kossakowski wrote: Any chance for you to create a similar page documenting your new approach? I'm sure that there would be a people benefiting from a nice cook-book document. Gladly. Once I get it worked out, I'll document it (maybe Daisy would be the place for that). [...snip] Interesting. I'm not sure but when we have discussed Git advantages over svn on infrastructure lists that point has not been discussed. Even if only for that purpose it makes sense to provide Git clones of Apache repositories. I agree! This morning I was worried that I gave too much background in my email. I thought nobody will care enough to read through all this crap! I'm glad people seem to recognize this as a valid use case, not just some goof-ball cowboy idea... Anyway, I hope there will be other use-cases for Git at Apache... Me, too... I think it's inevitable :-) I would like to add only one note to Reinhard's answer: Various parts of Cocoon are now released independently so version numbers can be completely different. Anyway, in most cases it's ok if you just checkout certain module and patch it. Right. I still have to figure out how I'm going to handle that in my git setup, but I think you and Reinhard have set me on the right track here. Fortunately, repositories provided by Jukka track all these branches and tags for different modules so you will have no trouble with such setup. Yes. thanks a _lot_, Mark No problem. Next time it's better to discuss such things publicly (yes, I'm sorry that I didn't respond to your e-mail - as usual lack of free time). :-) Actually, the only reason I emailed you first was specificatlly that I didn't know how publicized Jukka wanted this to be. I mean it's no big secret, he posted it on infra, but... still I didn't want to be the one to say hey everybody... git party at Jukka's server! :-) I guess he did say he could probably handle a few hundred users... cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
[C2.2] ImageOp block
Hi, What's left to do to make the ImageOp block ready for release? Maybe I can try and do my bit... cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
Can somebody explain to me the tags / POM versioning / release scheme?
Hi Devs, I need some help understanding the temple of mystery that is http://svn.apache.org/repos/asf/cocoon/tags/ . If I wanted to build my own 2.2 artifacts, how would I do that? Some background, I'll *try* to make it as short as possible :-/ (and while it involves git, you don't need to understand git to be able to follow it)... I use Cocoon to implement dozens of customer web sites/applications. I develop on my laptop when possible, and we have a development server for staging and some content updates, and a production server. A few years ago, I realized that I needed to be able to maintain the Cocoon source tree (the parts of it I needed) in my own Subversion repository. The main reason for this was to be able to upgrade projects to new versions of Cocoon in a controlled way, as smoothly as possible. Also, on rare occasions I would find a bug and submit a patch for the fix, and I needed the ability to push that fix into production in the version of Cocoon that my project builds were using. To make all this possible, I developed an application of the Vendor Branch Strategy described in the Subversion book, and documented it here: http://wiki.apache.org/cocoon/CocoonVendorBranch. Unfortunately, that technique still turned out to be too labor- intensive, to the point where it failed to accomplish its main goal of giving me an easy way to upgrade Cocoon versions. Meanwhile... the lack of merge tracking and offline commits in Subversion was making it harder and harder to get work done, so I started using SVK (http://svk.bestpractical.com ) as my front-end to Subversion on my laptop. After a little bit of experience with SVK, I realized that it provided the ability to radically simplify my vendor branch strategy. All I needed to do was to create a local SVK mirror of the ASF Cocoon repository and I would be off and running. Unfortunately... it didn't work, the mirror sync operation would always fail with a low-level error in the Subversion layer. So I gave up for a while. Then, last month I started researching the problem again, and learned that the problem had been due to the Apache mod_dontdothat policy implemented by Apache infra in order to thwart some kind of abuse that had been going on. Sadly, this also made it impossible for SVK to mirror the repository. About that time, Grzegorz was running into the same problem, but he was trying create a git-svn mirror of the repository. That was fortuitous for me, because I was getting seriously interested in git (having experienced that SVK is broken, and come to the realization that the whole concept is lipstick on a pig). There was this whole long discussion on the infra list, and they finally reached a compromise where mod_dontdothat would be turned off... but only on eu.svn.apache.org, and only in the https:// scheme, which would then be subject to authentication — so, this was available to committers only. There was actually a brief window of time when mod_dontdothat was turned off for Europe, and during that time I was able to 'git-svn clone' the repository. But a few weeks later, I tried to rebase my git-svn mirror (like doing svn up) and it failed because by then eu infra had closed off non-mod_dontdothat'd access on http://, so... back where I started. BUT THEN... one of the Apache committers put a lot of work into figuring out how to create a git-clonable, public git-svn mirror of an Apache project... and he did it, and published mirrors of a bunch of Apache projects, including Cocoon. It's brilliant. It took me 20 minutes to git-clone the mirror, vs. the 40 hours of running time to make my own (short-lived) git-svn mirror. I just rebased to pick up the last week's worth of changes to the repo, and it just took a couple of seconds. And in my local git repository, I can do *anything* that's possible in git. I really think this is the answer to my problem. NOW... I want to start porting all my Cocoon projects, which are all stuck on Cocoon 2.1, to a Cocoon build based on the 2.2 release. This would be 2.2 + a couple of minor bug fixes which did not make it into the 2.2 release, so it needs to be from my own local (git) branch... plus, this puts me on the right path to do everything I originally was trying to do with subversion vendor branch, i.e. controlled Cocoon upgrades in the future w/ minimal hassle, continuing to add minor local patches as necessary so I can use them before they appear in a release, etc... except that it will actually *work*. All that's missing is being able to identify the baseline of source code that was used to build the 2.2 release. I need to be able to build the core and a few modules. Can somebody help me figure this out? thanks a _lot_, Mark smime.p7s Description: S/MIME cryptographic signature
artifact versions, samples
Hi, a couple more questions... 1) In my hello world Cocoon app created by following http://cocoon.apache.org/2.2/1159_1_1.html , I look at the POM and I see a different version ID for each dependency, and I understand why that is... but so, suppose now my application is going to need some more blocks, e.g. cocoon-forms, cocoon-batik, cocoon-imageop etc. How do I figure out what version ID to use for those blocks? 2) I can do mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org and pick from a menu of archetypes to get one of several flavors of hello world starter Cocoon configurations. How come there isn't a cocoon-22-archetype-samples? Would that not make sense or something? thanks, Mark smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1384) [PATCH] flow redirector should allow explicit 'cocoon:' scheme
[ https://issues.apache.org/jira/browse/COCOON-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-1384: --- Attachment: (was: patch) [PATCH] flow redirector should allow explicit 'cocoon:' scheme -- Key: COCOON-1384 URL: https://issues.apache.org/jira/browse/COCOON-1384 Project: Cocoon Issue Type: Bug Components: - Flowscript Affects Versions: 2.1.8 Environment: Operating System: Mac OS X 10.0 Platform: Macintosh Reporter: Mark Lundquist Assignee: Cocoon Developers Team Priority: Minor Attachments: patch.32762 Prohibiting an explicit scheme unduly disallows the valid use of colons in the scheme-specific portion of the URI. With this patch, an explicit 'cocoon:' scheme is allowed, which permits URIs such as cocoon:/something:foo/bar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-2169: --- Attachment: smime.p7s height = 0, width 0 :: set width as given and scale uniformly height 0, width = 0 :: set height as given and scale uniformly height = 0, width = 0 :: pass image through without change ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Priority: Minor Attachments: smime.p7s Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610665#action_12610665 ] Mark Lundquist commented on COCOON-2169: Slight correction/clarification: the behavior described for height and width both zero is only obtained if COCOON-2177 is fixed :-) ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Priority: Minor Attachments: smime.p7s Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2177) ImageOp with requested height width both zero should be a no-op, instead it throws an exception
ImageOp with requested height width both zero should be a no-op, instead it
throws an exception
-
Key: COCOON-2177
URL: https://issues.apache.org/jira/browse/COCOON-2177
Project: Cocoon
Issue Type: Bug
Components: Blocks: ImageOp
Affects Versions: 2.1.11, 2.1.10, 2.1.9, 2.1.8, 2.1.12-dev (Current SVN),
2.2-dev (Current SVN)
Reporter: Mark Lundquist
Priority: Minor
When the resize height and width are both zero, the resize operation throws:
java.awt.image.ImagingOpException: Unable to invert transform
AffineTransform[[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]]
Note, if COCOON-2169 is fixed, this happens when no height or width parameter
is passed from the sitemap. In this case, the resize effect should simply pass
through the unaltered image... it should be a no-op.
The patch is too small to bother attaching, here it is:
===
---
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(revision 635771)
+++
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(working copy)
@@ -57,6 +57,9 @@
if( ! enabled ) {
return image;
}
+if ( this.width == 0 this.height == 0 ) {
+return image;
+}
double height = image.getHeight();
double width = image.getWidth();
double xScale = this.width / width
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-2169: --- Component/s: (was: Blocks: (Undefined)) Blocks: ImageOp Affects version (Component): Parent values: Blocks: ImageOp(10334). Fix version (Component): Parent values: Blocks: ImageOp(10336). ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: (Undefined) Affects Versions: 2.1.11, 2.1.10, 2.1.9, 2.1.8, 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: File Upload/Download
On Mar 6, 2007, at 9:37 AM, wc184 wrote: Hi, I'm trying to implement a file upload/download feature in my application using Cocoon. I've tried searching for revelant information on this but I can't seem to find anything decent. Any pointers would be appreciated. WC Hi WC, Yeah, this is more of a question for users@cocoon.apache.org, rather than the devs list. Anyway, have you looked at the file upload example in the Forms block sample from the Cocoon distribution? For downloading, often you just want to set the mime type and/or content disposition headers in the HTTP response, as a hint to the browser to download the file (or present a download vs. open dialog) instead of displaying the file inline. If you have any trouble figuring that out, please post on the users' list and somebody will help you out :-) cheers, —ml—
[jira] Created: (COCOON-2020) CAPTCHA input element should have autocomplete=off
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.10, 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.11-dev (Current
SVN), 2.2-dev (Current SVN)
Reporter: Mark Lundquist
Priority: Trivial
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all Cocoon
versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
cocoon.processPipelineTo()
Hi, I seem to remember from a long time ago, some mention of something that could be used in place of processPipelineTo(). Something that might have been better, or... not sure. Anyway, does this ring any bells? I can't seem to find the reference now... best regards, —ml—
[ASF] = Subversion 1.4?
Hi, sorry for the OT... I checked at apache.org and I got the impression that the relevant forums for this question are open only to committers, thought someone here might have some inside knowledge... Anyway, Q.: Why is svn.apache.org still running Subversion 1.3, and when are they going to upgrade? Thx, —ml—
[jira] Commented: (COCOON-1959) o.a.c.environment.Request'setParameter()
[ https://issues.apache.org/jira/browse/COCOON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472942 ] Mark Lundquist commented on COCOON-1959: The idea is to be able to add a new parameter to the current request (and maybe also change existing ones, I guess), before forwarding to another Cocoon pipeline. Sorry, I don't recall exactly what my use case was for this. Most likely, the workaround would have been to bung a query-string onto the request URI, which I would have found bletcherous... o.a.c.environment.Request'setParameter() Key: COCOON-1959 URL: https://issues.apache.org/jira/browse/COCOON-1959 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.10, 2.2-dev (Current SVN) Reporter: Mark Lundquist Assigned To: Carsten Ziegeler Priority: Minor I would like to add a setParameter() method to o.a.c.environment.Request. I think this would be useful for setting up internal forwards. Please let me know if (a) this isn't going to work the way I want it to, or (b) there's some other reason not to do this, e.g. oh, we're changing everything and that class is going away :-). If I don't hear any -1, I'll write a patch to do this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [graphics] New version of masthead
On Feb 6, 2007, at 8:22 AM, hepabolu wrote: I agree that asking for more opinions will only give you more _different_ opinions. I'd say the discussion about the new website design is a privilege of the committers. Well maybe I can get a special dispensation, because IIRC this masthead revision was at my instigation... :-) I think it looks pretty good. Notes: 1) This latest version of the layout is robust w.r.t. window resizes (an improvement on the first one where the green boxes were floated). The new page does pretty well with the text scale-up test... no blowouts except in the green box content (at least, in Safari and Mozilla where I've tested). Don't know if you want to fix that or not...? 2) Would that page corner fold graphic be a link to more info? Seems like that's usually what it means... 3) W.r.t. the masthead itself... I meant to comment on this before, but never got to it until now so I understand if it's too late to do anything about it. Anyway, seeing it now in the context of a full web page strengthens my feeling about this design that the color palette is a little bit bland and boring. How about this... Thien, if you were to just take 3-4 of the blocks near the bottom-right corner of the block field — where that one block is sort of breaking away from the rest — and give them new colors outside of the blue shade scale used for the other blocks (I'm thinking purple, orange, bright green?) — that would break up the mum's kitchen tile effect and liven up the color scheme. How hard would that be to try? Just a suggestion from one of the sheep farmers :-) cheers, —ml—
Re: [graphics] New version of masthead
On Feb 5, 2007, at 6:34 AM, hepabolu wrote: Please note that shrinking the masthead will also take the air out of the design and I suspect that it will give a cluttered and crammed look. I agree. -1 on shrinking the masthead. —ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 27, 2007, at 6:39 AM, Jorg Heymans wrote: Mark Lundquist wrote: :-/ It's also kind of a heavy-handed kluge that goes against the spirit of Maven (IMHO alternative local repo locations should only be used for testing purposes), but that's a secondary issue. well that's what you were describing no? Not really, by testing I mean testing Maven, or testing repositories, etc. Thanks for your interesting thoughts! Y.W... After bumbling my way through learning more about Maven, e.g. profiles, what dependencyManagement is/isn't supposed to be able to do, etc., I'm convinced it's primary Maven functionality that's required by this scenario. I've just posted a request for discussion on the Maven dev list, if anybody cares to follow along (or chip in! :-) over there... cheers, —ml—
load flow scripts from directory...?
I think I remember some discussion about map:script being able to scan a directory and load any scripts it finds... can somebody refresh my memory? thx, —ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 3:01 AM, Giacomo Pati wrote: On Wed, 24 Jan 2007, Alexander Klimetschek wrote: But as we are having our own version of cocoon 2.2 including our patches during development, I know the problem of going through all poms and changing the version number... At least there is this pom-updater tool in tools/ which automatically modifies all poms. It can be modified quite easily (it's XSLT) to do other things with the version number. We've managed other projects with lots of module by the dependencyManagement section in the root pom where all dependencies are listed with version numbers. Module poms will thus never have a version defined in their dependencies. For the standard case (not my local branch problem), I think dependencyManagement could be used and we could get rid of the pom-updater. At first I (Maven noob) thought it wouldn't work because Cocoon is no longer a monolithic project, i.e. a person should be able to do an isolated checkout of a block and build and develop on it, without having all of trunk checked out. But then I realized (d'oh!) that the root pom and other aggregating poms are in artifacts that will be fetched into the local maven repo, they don't have to be built locally. So, it looks like using the standard dependencyManagement instead of custom pom-updater is using the right tool for the right job, WDOT? Now can we please get back to talking about my local branch problem? :-) dependencyMangement of course does not help me, because the only things you can set in an ad hoc local profile are repository locations and properties. Everything else was deemed too dangerous [1] by the Maven developers, because it militates against build reproducibility (they call it portability). IMHO, that was a bad decision and the wrong solution to the reproducibility problem! How can I have multiple local builds of the same artifact coexisting on my machine, without modifying any Subversion-controlled resources (e.g. poms)? That's the question. I'm in need of some brilliant ideas here, does somebody have any? thx, —ml— [1] http://maven.apache.org/guides/introduction/introduction-to- profiles.html
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote: countervailing decomposition by hierarchical project aggregation, mind if i use that one in my next presentation to senior management? :P Ha Jorg, I *challenge* you to slip it in somewhere into your very next presentation to senior management, whatever that may be! :-) :-) —ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote: How about having 2 local repositories ? Put a settings.xml in your reference checkout and invoke maven using -s settings.xml. Do the same for your local dev checkout and make sure that the localRepository element [1] in both is different. LOL, Reinhard suggested the same thing earlier on in this thread. I might end up trying to do it this way temporarily, if that's what it takes to get some work done. The main problem with it is that because it's not location-dependent, it's not set-and-forget, which means it's not foolproof, which means that ML is guaranteed to cock it up within the first 24 hours (either through confusion or sheer forgetfulness) :-/ It's also kind of a heavy-handed kluge that goes against the spirit of Maven (IMHO alternative local repo locations should only be used for testing purposes), but that's a secondary issue... Maven2 is not bug-free by any means, and some of its advertised ways of how it should work (eg dependencyManagement) simply don't. For example, my experience with version properties in the root pom is that the variable interpolation on artifact deployment time is buggy. Perhaps this has been fixed already, if so then great but everyone will need to upgrade to 2.0.5-SNAPSHOT for it to work. Right, and I realize that Maven 2 is a work in progress. In spite of that, and even though it gets harshed on by a lot of people in the Java world, I think the Mavenization of Cocoon will turn out to have been one of the best decisions for Cocoon ever. That and the Springification... so 2.2 is really something to hang your hat on. Many thx to all you guys for all the great work. Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond said, all bugs are shallow given enough eyeballs, and there are a lot of eyeballs on Maven right now, so I think it will get better. Also, if you cram the dependencies of 100+ modules and their version numbers in the root pom then this can become a management bottleneck as well as this pom will need to be managed and included in the release process of every module. Yes — a pain. I don't like centralizing this. Anyway, w.r.t. while there may yet be a role for dependencyManagement in our build system, it looks to me like it does not help with the intra-project dependencies, because it only addresses the dependent side and not the installing side. The reference [1] doesn't say anything about dependencyManagement affecting the version of any artifact being built. It just says anybody that uses artifact Foo, you get version XYZ of it. If I'm actually building Foo though, this doesn't make it build version XYZ, it still builds whatever its project/version says. cheers, —ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 11:12 AM, Alexander Klimetschek wrote: Mark Lundquist schrieb: dependencyMangement of course does not help me, because the only things you can set in an ad hoc local profile are repository locations and properties. Everything else was deemed too dangerous [1] by the Maven developers, because it militates against build reproducibility (they call it portability). IMHO, that was a bad decision and the wrong solution to the reproducibility problem! Full ACK. When I read about what you can put in a profile and what not, I was thinking the same thing. They should have simply allowed it, but with a big warning sign in the documentation to not use it the wrong way... Well, I've been studying this some more, and I think that even if dependencyManagement were overridable within an external profile, it would not be enough (see my recent reply to Jorg)... How can I have multiple local builds of the same artifact coexisting on my machine, without modifying any Subversion-controlled resources (e.g. poms)? That's the question. I'm in need of some brilliant ideas here, does somebody have any? What's with the properties idea you suggested? Put properties for all child-pom-versions in the root pom and overwrite them in your profile. It's just sort of disgusting :-/. I think it would work, but... there are like 248 poms in Cocoon, up to 4 levels deep. I doubt we really want to mirror that structure in the root pom. This would have to be kept in sync with the source tree at all times, even for local changes, and that introduces new friction for refactoring efforts, or even just adding a new block. Also, modules will go away and people will forget to delete the corresponding properties from the root pom, so it will get cluttered with obsolete stuff. As I was thinking about this, at one point just a bit ago it seemed to me that this really cries out for IOC for poms! I was thinking, what if your external profile could intercept any pom in the build and override something therein? Then I started looking through the pom elements, and it appears the only thing that's at all reasonable to override on an ad hoc basis (i.e. without touching controlled files like poms) is the version id for subprojects. I also realized that I was too liberal in my criticism of the Maven approach to ad hoc profiles, because this is a very legitimate measure to preserve build reproducibility in the committer = repository direction. Everything else in the pom would break reproducibility under local overriding, but this one thing does not: the version id to use for (a) building module X and (b) for satisfying dependencies on X within this top-level project. So we don't need or want a general-purpose IOC here. What we need is a very specific profile-driven mechanism in Maven for addressing the specific problem of allowing multiple coexisting project builds on one machine so as to not result in artifact clashes in the repository. That's it. A very quick and dirty workaround would be to for Maven to introduce a localRepository element (a la settings.xml) in an external profile. It's un-Maveny and inelegant, but it would be relatively easy and low-risk. cheers, —ml—
Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 21, 2007, at 12:09 PM, Mark Lundquist wrote: I need to learn how to manage multiple local artifact sets in my Maven repo. I have *two* different trunk build areas on my machine under svk (my local mirror of the ASF repo, and a local development branch), but I haven't put all the pieces of that story together w.r.t. Maven... I think what is standing in my way right now is all the hard-coded version ids in poms. What's the deal with that? There are a handful of unique ones in trunk right now, there must be some reason why they are all hardcoded into the individual project poms instead of defined as properties in the root pom or the several intermediate parent poms... and I just don't know the reason? If they were properties, then I could trigger a profile using file activation in my settings.xml and override the version property/ies, setting them uniquely for whatever local branch I'm building in. ??? —ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Hi Alex,
On Jan 24, 2007, at 5:10 AM, Alexander Klimetschek wrote:
I think the idea is to have separate release cycles and thus different
versions for each block. So there is no general cocoon version any
more, this version, like currently 2.2, only regards the core modules.
Right, but still... :-)
But as we are having our own version of cocoon 2.2 including our
patches during development, I know the problem of going through all
poms and changing the version number... At least there is this
pom-updater tool in tools/ which automatically modifies all poms. It
can be modified quite easily (it's XSLT) to do other things with the
version number.
The pom-updater is unsatisfactory for this because it still doesn't
really allow multiple builds of Cocoon to co-exist on my machine. At
best it just makes it slightly less tedious to set up the builds in the
first place, but still, installing either of the builds renders the
other unusable (until the other in turn is rebuilt).
What I'm trying to have is (a) a reference build of trunk that does
not have any of my local fingerprints on it, and (b) a local
development build (or even, potentially, more than one of those). Then
I can play with the reference build it or debug it and see oh, this is
how it's supposed to work... or, maybe sometimes I would see ah, so
this is really broken in trunk, it's not the fault of my local
changes, etc. This is not possible right now, and I think it's the
hard-coded versions numbers that are standing in the way. If they were
implemented with properties, I could override them in a profile.
The other bad thing currently would be having local mods in my
development poms — if I'm going to submit a patch then I have to make
sure to strip out those local changes before generating the patch...
but that's not sustainable going forward because it defeats the purpose
of maintaining a local development branch, e.g. in svk. For you
committers it's no big, because you don't have to JIRA a patch and then
wait 'til when and if your patch gets accepted, you just commit it and
then you are in sync again. For other contributors it is harder, and
local development branches have the potential to make Cocoon
development tractable in the Mavenized world... but only if they work
:-/
I'm still pretty much a noob to the ways of Maven so bear with me for a
moment... but instead of inheriting version in the aggregated project
poms, suppose (just for the sake of discussion!) that the root-level
pom defined a tree of parameters that is isomorphic to the project
hierarchy, like this:
property
cocoon.version2.2.whatever/cocoon.version !-- (e.g.) --
cocoon.version.core${cocoon.version}/cocoon.verision.core
cocoon.version.core.cocoon-core${cocoon.version.core}/
cocoon.version.core.cocoon-core
cocoon.version.core.cocoon-pipeline${cocoon.version.core}/
cocoon.version.core.cocoon-pipeline
.
.
cocoon.version.blocks${cocoon.version}cocoon.version.blocks
cocoon.version.blocks.ajax${cocoon.version.blocks}cocoon.version.bloc
ks.ajax
.
.
Each lower-level pom would use the appropriate ${cocoon.verision...}
property in setting its version, and would similarly use these
properties to define versions of its dependencys. If e.g. trunk
development requires, say, that some level have a different version
number, then it would be changed at that level in the root pom's tree
of version property definitions. (I'm talking about controlled changes
in Subversion here, not local changes). (Note, there would be no more
need for the pom-updater in this scheme).
Now, this breaks good design because the root pom has to know details
about the whole project tree, which countervails decomposition by
hierarchal project aggregation. But... it does allow me to have
multiple builds that can coexist because they do not create artifact
clashes in my local maven repo, because I can trigger a build profile
that overrides whichever version properties I require to be unique for
that build.
So the question is, is there another way that can work like this idea,
but without the smelliness of the root pom having to contain details
about the whole hierarchy?
cheers,
—ml—
Re: Extension of PropertiesFileModule
On Jan 24, 2007, at 5:35 AM, Nicole Hochleiter wrote: Hi, I need to extend the PropertiesFileModule (in fact I already have implemented my own Version of the class and use it). But I wonder if the community would like to have this extension in the project: instead of only reading one file to one name I read several files which can contain the same properties and the last one in the list is taken. This is interesting e.g. if you have a default.properties and a local.properties file where in the default you can define the default values and if a local installation needs to add specific properties or only specific values this can be configured in the local.properties which overwrite the default. Hi Nicole, In terms of the current code base, for overriding one properties file with another the most parsimonious solution is to instantiate a ChainMetaModule in cocoon.xconf. Declare it to chain two PropertiesFileModule instances — first the one for local.properties, then the one for default.properties. No new classes required :-) But maybe it will be felt that supporting multiple properties files in a single output module is desirable — in that case, it might be better to just enhance PropertiesFileModule rather than add an additional class? cheers, —ml—
Re: Sprinifying CForms
On Jan 23, 2007, at 6:54 AM, Ralph Goers wrote: How will you make this compatibile with 2.1.x? The code base is shared. Is it time to make it not shared anymore? —ml—
[(slightly) OT] Re: Multiple local snapshots in Maven (was Re: Trouble w/ Eclipse Jetty Launcher again...)
On Jan 22, 2007, at 2:38 AM, Reinhard Poetz wrote: Never tried it myself but according to the Maven documentation you can set an alternative path to the settings.xml file when you invoke maven (-s switch). In settings.xml you can set the path to you local Maven repo. Yes... that would work, thx for the suggestion. It's not really what I'm after, because (a) a completely separate maven local repo is a little heavy-handed, and (b) this would depend on my environment/invocation instead of location, which means I am prone to botch it, i.e. install artifacts built from area A as snapshot B and then have a confusing mess to clean up. I'm now learning about Maven profiles [1], it look like they may be what I am looking for... cheers, —ml— [1] http://maven.apache.org/guides/introduction/introduction-to- profiles.html
[RT] wiki = user list
Should the wiki be set up to email update notifiers to the user list (like it does today to the doc list)? That might help the user community to become more aware of the wiki (assuming that'd be a good thing? :-) WDYT? —ml—
Multiple local snapshots in Maven (was Re: Trouble w/ Eclipse Jetty Launcher again...)
On Jan 21, 2007, at 6:03 AM, Daniel Fagerstrom wrote: You might have forgotten to do mvn eclipse:eclipse which is needed for updating the Eclipse configuration files. You also need refresh your Eclipse projects if you change the projects outside Eclipse. Also you might have missed to import some dependency into Eclipse. I see the problem... none of the above, but it was my bad. Sorry to trouble you, I should have looked more closely at that exception trace... :-/ I need to learn how to manage multiple local artifact sets in my Maven repo. I have *two* different trunk build areas on my machine under svk (my local mirror of the ASF repo, and a local development branch), but I haven't put all the pieces of that story together w.r.t. Maven... thx, —ml—
Re: [RT] wiki = user list
On Jan 21, 2007, at 11:37 AM, Reinhard Poetz wrote: Joerg Heinicke wrote: On 21.01.2007 18:07, Mark Lundquist wrote: Should the wiki be set up to email update notifiers to the user list (like it does today to the doc list)? That might help the user community to become more aware of the wiki (assuming that'd be a good thing? :-) WDYT? Please not. At other places [1] I try to get more readable archives and here we go the other way around? The wiki is mentioned on the Cocoon homepage, so I can't think of much more awareness. fully agreed you guys are totally right... it would mostly be spam like ml changed 'glad' to 'happy' on page X... —ml—
[mvn] off-line builds?
Hi, last night I had my laptop somewhere where there was no WiFi... I tried to do mvn install and it just totally bonked... all these messages about repos being blacklisted, and then BUILD FAILED :-(. What's the trick to being able to build w/o internet access? thx, —ml—
Re: [mvn] off-line builds?
On Jan 20, 2007, at 9:13 AM, Mark Lundquist wrote: Hi, last night I had my laptop somewhere where there was no WiFi... I tried to do mvn install and it just totally bonked... all these messages about repos being blacklisted, and then BUILD FAILED :-(. What's the trick to being able to build w/o internet access? never mind, found it... mvn -o, eh? cheersm —ml—
Re: What's up with 2.2 ?
On Jan 20, 2007, at 2:24 AM, Reinhard Poetz wrote: That's my fault. documentation was our first attempt but didn't fit our main goal of having separate deployment units. I will add a warning message to the sites overview. Thanks, and that is great for when someone is visiting the listing page as their entry point. But maybe it's still potentially confusing?... It doesn't look like Google's ever crawled daisy, but... people may still reach these pages via links from emails in the archives. How hard would it be to insert a big warning box at the top of every page in the documentation/ tree? (Is there an area-wide template that can be modified?) Better yet would be, in addition to the above, if every page in documentation/ that is obsoleted by a page in cdocs/ could get a notice and a link to the current page...? cheers, —ml—
Re: [docs] Working with Cocoon from trunk
On Jan 20, 2007, at 5:56 AM, Reinhard Poetz wrote: I tidied up the available Working with Cocoon from trunk documentation (http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/g1/ 798.html) and moved all docs from documentation to cdocs-site-main which is the appropriate place for them. I also tried to review them but I'm sure that there is still information missing in order to understand the big picture. Feedback is very much appreciated. OK... so what is the deal with http://cocoon.zones.apache.org/daisy/cdocs-site-main/g1/1285.html vs. http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g1/1285.html Looks like identical page content, but the nav tree is different...? cheers, —ml—
[docs] hr?
How do I insert a horizontal rule in the Daisy editor? thx, —ml—
Re: [docs] hr?
On Jan 20, 2007, at 10:45 AM, Mark Lundquist wrote: How do I insert a horizontal rule in the Daisy editor? Note, I tried switching to the HTML editor... did [Save] from there but it appears to have lost my changes... —ml—
Re: [docs] hr?
On Jan 20, 2007, at 12:03 PM, Grzegorz Kossakowski wrote: That's expected, Daisy does not support hr/ tag, see: http://cocoondev.org/daisydocs-1_5/daisywiki/general/24.html Makes sense, OK... Heading 2 has the look I want (with its bottom border) — at least in Daisy, not sure when it gets exported to Forrest... thx, —ml—
Trouble w/ Eclipse Jetty Launcher again...
Hi, sorry to be such a pain — dunno whether this is my fault or not, and in any case I've no clue how to fix it... I had Cocoon working in Eclipse using the Jetty Launcher. Then earlier today, I did svn up from trunk root and then mvn -Dallblocks clean install. Now whenever I try to run or debug in Eclipse, I get this: 15:11:56.534 ERROR! [main] org.springframework.web.context.ContextLoader.initWebApplicationContext( ContextLoader.java:205) 09 Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Unable to read Avalon configuration from 'resource://org/apache/cocoon/cocoon.xconf'.; nested exception is org.apache.avalon.framework.configuration.ConfigurationException: Unable to create class for component with role org.apache.excalibur.source.SourceFactory/servlet with class: org.apache.cocoon.servletservice.components.ServletSourceFactory Caused by: org.apache.avalon.framework.configuration.ConfigurationException: Unable to create class for component with role org.apache.excalibur.source.SourceFactory/servlet with class: org.apache.cocoon.servletservice.components.ServletSourceFactory at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.creat eConfig(BridgeElementParser.java:204) . . . Then the same exception trace repeats 9 times. Each one is a new exception trace, not another level of wrapping, but it's still just a single ERROR! message to the log, not 9 of them. However, mvn jetty:run still works fine. Any clues? Did I botch something up somewhere along the line, or is this a new bug? thx, —ml—
Re: What's up with 2.2 ?
On Jan 19, 2007, at 10:04 AM, Grzegorz Kossakowski wrote: I see. It means that documentation [1] is little bit outdated. Could you please fix it or give me necessary rights allowing me to do so? My login is 'grek'. [1] http://cocoon.zones.apache.org/daisy/documentation/g1/756.html Well, I guess I to am a little confused that we have both http://cocoon.zones.apache.org/daisy/cdocs/ and http://cocoon.zones.apache.org/daisy/documentation/ Can somebody clarify? thx, —ml—
Re: [graphics] Masthead artwork for cocoon.apache.org
On Jan 19, 2007, at 11:14 AM, Vadim Gritsenko wrote: Joerg Heinicke wrote: On 19.01.2007 12:01, Jeroen Reijn wrote: wow great designs Thien! I really like 2-4. #3 has a nice touch with the 'blocks', but somehow #4 was the first one that appealed to me. It's kind of playfull and dreamy. I really like it. It's a bit too dreamy IMO. :-) I prefer #2 and #3. Same here. Great job! +1 +1 Vadim Same here, I would say #2 is my favorite, followed by #3. Really nice work Thien, thanks a lot! Helma, your comments cracked me up... because #4 struck me as too cartoony, and I was also going to describe it as like WinXP meets Teletubbies :-) :-) My only quibble about #2 I have always disliked that phrase web glue for your web application development needs. Maybe I just don't have positive associations with glue; anyway, when I work with Cocoon it does not particularly feel like I am working with something gluey. The qualities of glueyness are not ones that one associates with a framework. Glue IMHO doesn't harmonize well with the idea of contracts, which Cocoon pushes a little bit (maybe not quite as much now as in the past, but IMHO that's a good thing). The #2 design incorporating that text sort of elevates this phrase to the level of a slogan, which I don't like. OTOH, I think something needs to go there :-).. the design now would, to my eye, look incomplete without it! Some kind of text, but what? anyway, great stuff, thx again! :-) —ml—
Re: what does this mean?
This means that your bank uses Apache Cocoon to develop their website, and they have a problem with it. We at Apache cannot really help you with a problem on your bank's site - you'll have to find a way to contact them directly. Do we still have that copy in the error pages? If so I think it should be removed. Its audience is developers, who already know that information. But when the developers don't provide custom error pages for applications that face out into the wilderness... ;-/ OK I just checked, it's still in error2html.xsl. In exception2html.xsl, it's commented out, with a comment that says the same as what I said above... :-) —ml—
[jira] Created: (COCOON-1984) o.a.c.environment.TemplateObjectModelHelper.ParametersMap does not override toString()
o.a.c.environment.TemplateObjectModelHelper.ParametersMap does not override
toString()
--
Key: COCOON-1984
URL: https://issues.apache.org/jira/browse/COCOON-1984
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Mark Lundquist
Priority: Minor
...and as a result, the object displays as empty, e.g. when debugging in
Eclipse. I added
public String toString() {
return wrappedParameters.toString();
}
and that fixed it. Although, I am puzzled as to why this class both extends
the Avalon Parameters class and is implemented using a delegate
('wrappedParameters') of that type. Why is not extending Parameters enough?
The delegate seems like an unnecessary complication.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Input modules samples broken in trunk
On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:
The modules samples are broken...
1) For the jxpath modules, an exception is thrown:
org.apache.commons.jxpath.JXPathException: Cannot access
property:
rg.apache.cocoon.environment.wrapper.RequestWrapper.attributeNames; No
read method
2) For the rest, the Accessor/Value table displays as empty.
Well, I finally got the chance to come back to this...
Problem #2 involves this line in
cocoon-core-additional-sample/.../modules/properties.xml:
jx:forEach var=name items=${cocoon.parameters.names}
cocoon.parameters is of class
o.a.c.environment.TemplateObjectModelHelper.ParametersMap. The class
itself is protected, but the getNames() method is public. It turns out
that if I change the JXT to
jx:forEach var=name items=${cocoon.parameters.getNames()}
then the page works correctly.
Is this a JExL bug/features, and/or a known incompatibility in the new
JXTG, or is it something that can be fixed?
—ml—
Re: Input modules samples broken in trunk
On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:
1) For the jxpath modules, an exception is thrown:
org.apache.commons.jxpath.JXPathException: Cannot access
property:
rg.apache.cocoon.environment.wrapper.RequestWrapper.attributeNames; No
read method
I thought I saw an error (obviously slightly different) on at least one
other jxpath input module, but now I can't reproduce it... maybe I was
goofed before. But anyway, the RequestModule does get the above
exception for the 'attributeNames' path, but other properties can be
accessed with no problem. If I comment this out of the sitemap:
map:parameter name=attributeNames
value={request:attributeNames}/
...then the sample works.
I'm not sure what causes the problem here; RequestWrapper implements
Request, which contains the getAttributeNames() signature. Any ideas?
cheers,
—ml—
Re: What is the deal with pipelines :-) (was Re: What is the deal with blocks)
On Jan 10, 2007, at 7:35 PM, Vadim Gritsenko wrote: You might find this useful. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101053457412921 Yes I do :-). I haven't had a chance to go through it to any depth, but IMHO this is about the level of formalism that we need from the user documentation standpoint. Just to have a consistent, well-defined and documented nomenclature would be great. —ml—
[jira] Created: (COCOON-1981) Allow map:call to call any function
Allow map:call to call any function - Key: COCOON-1981 URL: https://issues.apache.org/jira/browse/COCOON-1981 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Currently, map:call can only call a function that is a property of the flowscript global scope itself. This patch allows it to call any function in the global scope, e.g. foo.bar.baz. I provided this code change originally to Jeremy Quinn who committed it to BRANCH_2_1_X, but it has not yet been incorporated into trunk. The only additional thing I would suggest... would it be worth it to test if funName.contains (.), and if so look up the function the old way? Don't know if that's significantly faster... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow map:call to call any function
[ https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-1981: --- Attachment: 1981.patch Allow map:call to call any function - Key: COCOON-1981 URL: https://issues.apache.org/jira/browse/COCOON-1981 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: 1981.patch Currently, map:call can only call a function that is a property of the flowscript global scope itself. This patch allows it to call any function in the global scope, e.g. foo.bar.baz. I provided this code change originally to Jeremy Quinn who committed it to BRANCH_2_1_X, but it has not yet been incorporated into trunk. The only additional thing I would suggest... would it be worth it to test if funName.contains (.), and if so look up the function the old way? Don't know if that's significantly faster... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow map:call to call any function
[ https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-1981: --- Attachment: 1981.patch Allow map:call to call any function - Key: COCOON-1981 URL: https://issues.apache.org/jira/browse/COCOON-1981 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: 1981.patch, 1981.patch Currently, map:call can only call a function that is a property of the flowscript global scope itself. This patch allows it to call any function in the global scope, e.g. foo.bar.baz. I provided this code change originally to Jeremy Quinn who committed it to BRANCH_2_1_X, but it has not yet been incorporated into trunk. The only additional thing I would suggest... would it be worth it to test if funName.contains (.), and if so look up the function the old way? Don't know if that's significantly faster... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow map:call to call any function
[ https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-1981: --- Attachment: 1981.patch Allow map:call to call any function - Key: COCOON-1981 URL: https://issues.apache.org/jira/browse/COCOON-1981 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: 1981.patch, 1981.patch, 1981.patch Currently, map:call can only call a function that is a property of the flowscript global scope itself. This patch allows it to call any function in the global scope, e.g. foo.bar.baz. I provided this code change originally to Jeremy Quinn who committed it to BRANCH_2_1_X, but it has not yet been incorporated into trunk. The only additional thing I would suggest... would it be worth it to test if funName.contains (.), and if so look up the function the old way? Don't know if that's significantly faster... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1981) Allow map:call to call any function
[ https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464680 ] Mark Lundquist commented on COCOON-1981: Please delete the first two of the three attached files. The first one was too big a diff and included unrelated changes to a different file. The second is identical (botched attempt to correct the first). The third file is the good patch file. Allow map:call to call any function - Key: COCOON-1981 URL: https://issues.apache.org/jira/browse/COCOON-1981 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: 1981.patch, 1981.patch, 1981.patch Currently, map:call can only call a function that is a property of the flowscript global scope itself. This patch allows it to call any function in the global scope, e.g. foo.bar.baz. I provided this code change originally to Jeremy Quinn who committed it to BRANCH_2_1_X, but it has not yet been incorporated into trunk. The only additional thing I would suggest... would it be worth it to test if funName.contains (.), and if so look up the function the old way? Don't know if that's significantly faster... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Importing Cocoon projects into Eclipse
On Jan 11, 2007, at 12:35 PM, Grzegorz Kossakowski wrote: You have to set up variable 'M2_REPO' in Eclipse (in build classpath settings somewhere) to point on the directory where your Maven's repo sit. yes... thanks :-) —ml—
Re: module naming
On Jan 15, 2007, at 3:08 AM, Leszek Gawron wrote: We should come up with some agreement on how to name the modules. That reminds me, I was wondering about the artifactIds / names of module directories in the svn tree... why do they all start w/ cocoon-? It seems kinda redundant since the groupId is org.apache.cocoon. I'm sure there must have been a reason, I'm just curious what it is :-). Also it occurs to me that org.apache.cocoon.core and org.apache.cocoon.blocks could be used as groupIds if that were thought to help make things clearer... —ml—
trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
Hi, When I run cocoon-webapp using mvn jetty:run, it works fine. When I launch it from Eclipse using the Jetty plugin, I get this: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. I configured the Jetty Launcher like so... webapp root: target/webapp context name: / Any clues? thx, —ml—
Re: trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
On Jan 15, 2007, at 1:16 PM, Daniel Fagerstrom wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116756809412994w=2 Thanks, Daniel. I think I must be misunderstanding something, though. When I pull up the Jetty Web configuration panel, it doesn't have Use custom webdefaults config file exactly, but I have a box marked Use a Jetty XML configuration file and I presume that's the same thing. When I select that option with webdefault.xml, it breaks with this: java.io.IOException: Jetty configuration problem: java.lang.IllegalStateException: Unknown tag: description at org.mortbay.jetty.Server.init(Server.java:124) at com.iw.plugins.jettyrunner.PluginRunner.launchWithXML(PluginRunner.java: 226) at com.iw.plugins.jettyrunner.PluginRunner.launch(PluginRunner.java:91) at com.iw.plugins.jettyrunner.PluginRunner.main(PluginRunner.java:75) (description is the first child of web-app in the webdefault.xml file). Sorry for being so lame, to atone for it I will add all this to the docs once I have it working :-/ thx, —ml— P.S. The comment in webdefault.xml seems awfully disparaging about RequestAttributeListeners, whatever those are...
Re: trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
On Jan 15, 2007, at 3:04 PM, Daniel Fagerstrom wrote: I don't think they are the same thing. In my Jetty launcher plugin (1.4.1), both of the fields are there and I use the field connected to the use custom webdefaults config file. ohh... you mean, right there in front of me? :-/ Seriously... this is why I do so much better with command-line tools :-/ java.io.IOException: Jetty configuration problem: java.lang.IllegalStateException: Unknown tag: description Which shows that the Jetty XML configuration file field doesn't understand the scheme of an ordinary webapp file. Yes... hence my befuddlement. thx, —ml—
Re: module naming
On Jan 15, 2007, at 6:20 PM, Jason Johnston wrote: One possible reason is that the resulting JAR artifacts only contain the artifact name (and version), so having the 'redundant' identifier makes the JAR file more identifiable once everything's flattened into e.g. WEB-INF/lib. I think that's it (I'd been trying to remember from some previous discussion...). A prefix configuration element for the jar plugin would be nice. thx, —ml—
Re: call a function not in global object in map:call
On Jan 13, 2007, at 11:58 PM, Rice Yeh wrote: Then, should I report this problem to JIRA. Or there is other concern not to include this function in trunk? I'll do it, 'cause I can supply my svn diff as a patch... :-) —ml—
Re: call a function not in global object in map:call
On Jan 13, 2007, at 2:21 AM, Rice Yeh wrote:
Do you have an example about how to pass the namespace object? I use
it like the following:
map:call function=xs.party.use
map:parameter name=flowpath value={0}/
/map:call
, but it does not work.
That should work if there is a function xs.party.use() at the global
scope. E.g., something like:
var xs = {};
.
.
.
xs.party = {};
.
.
.
xs.party.use =
function() {
.
.
};
What do you mean by it does not work?
cheers,
—ml—
Re: call a function not in global object in map:call
On Jan 13, 2007, at 11:11 AM, Rice Yeh wrote: By studying the source code, I do not think call a function not in global object in map:call is supported in trunk because function is still gotten in thrScope. Am I right? I don't think so. What scope do you think it should compile in? —ml—
Re: call a function not in global object in map:call
I just tested like this:
var flowTest =
{
foo: {}
}
flowTest.foo.bar =
function() {
print (Hello from flowTest());
};
...and like this...
map:call function=flowTest.foo.bar /
and it worked fine...
???
—ml—
Re: call a function not in global object in map:call
On Jan 13, 2007, at 1:41 PM, Mark Lundquist wrote: I just tested like this: [...snip..] and it worked fine... Note, actually I tested in 2.1.11(dev), not trunk, because that was more convenient ATM... but it's the exact same code in FOM_JavascriptInterpreter. cheers, —ml—
Re: call a function not in global object in map:call
On Jan 13, 2007, at 11:11 AM, Rice Yeh wrote:
The fun is not gotten by the code at line 591 in
FOM_JavaScriptInterpreter.java
Object fun = ScriptableObject.getProperty(thrScope, funName);
hold on, I did not read the above very carefully the first time,
sorry... :-/
By studying the source code, I do not think call a function not in
global object in map:call is supported in trunk
OK, the code you excerpted above is not from trunk HEAD (or
BRANCH_2_1_X HEAD either. What version are you looking at there,
anyway? The current versions have my change, which looks like this:
// Resolve function name
//
Object fun;
try {
fun = context.compileString (funName, null, 1,
null)
.exec (context, thrScope);
} catch (EcmaError ee) {
throw new ResourceNotFoundException (
Function \javascript: + funName + ()\
not found
);
}
HTH,
—ml—
Re: call a function not in global object in map:call
On Jan 13, 2007, at 8:02 PM, Rice Yeh wrote: It is sured that this function is not in trunk. Bah, you are right, sorry, my bad... so I guess it is in BRANCH_2_1_X but not in trunk yet. It turns out that I had this file checked out in trunk and was looking at my own checked-out version. —ml—
Re: call a function not in global object in map:call
On Jan 11, 2007, at 1:36 AM, Rice Yeh wrote: Does anyone know whether the function mentioned in http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works now? phooey... I forgot to submit this patch to JIRA :-(. Doing it now... —ml—
Re: call a function not in global object in map:call
On Jan 11, 2007, at 6:08 AM, Mark Lundquist wrote: On Jan 11, 2007, at 1:36 AM, Rice Yeh wrote: Does anyone know whether the function mentioned in http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works now? phooey... I forgot to submit this patch to JIRA :-(. Doing it now... Never mind! :-) I never submitted it to JIRA because I didn't need to. Jeremy Quinn asked for this feature, and that reminded me how it was something I had wanted also, so I made a patch and emailed it so he could try it out — I think I didn't JIRA it at first because I wasn't sure if the committers would think it was the right way to implement it (not that I think there's anything wrong with it :-). Anyway, it turns out that Jeremy committed this along with some of his other changes. So this made it into the 2.1.10 release, and it's also in trunk. —ml—
Re: Input modules samples broken in trunk
On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote: try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html OK, so let me make sure I understand... I want to make changes to sitemap, XLST, XML sources etc. within a block and have those changes take effect immediately in the running Cocoon. IIUC, there are two ways to do this: 1) By using the reloading classloader; 2) By using the Eclipse Jetty Launcher. Is that right? —ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 10, 2007, at 10:20 PM, Reinhard Poetz wrote: I just tried setting up the RCL per http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that the solution I'm after? I added the rcl.properties to cocoon-core-addition-sample/pom.xml and tweaked the cocoon-webapp/pom.xml, ran mvn rcl:webapp there... but when I request the webapp site root in my browser, I get: Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but that's all the sitemap.xmap etc., are all missing. After running rcl:webapp, have you tried to start the created webapp? Yes, I'm sorry, I see where in my original email I left a place to paste in the reply from Cocoon, but then I forget to do it. Here's what I see in the browser: HTTP ERROR: 503 SERVICE_UNAVAILABLE RequestURI=/ Powered by jetty:// There is no need for a global sitemap.xmap anymore. You mount one of your blocks to the root of your webapp (/). No, no... this is core/cocoon-webapp where I have done this. I did it there, in situ, just temporarily while I (hopefully) test some changes in trunk. cocoon-webapp does have global (self-contained root-level) resources (sitemap.xmap, welcome.xml, stylesheets/ etc.). I know how to do it the block way, that's not the issue... I'm just trying to quick-'n'-dirty configure my own local build of cocoon-webapp to use the RCL, and it doesn't appear to be working right — which is probably All My Fault somewhere, and I'm trying to figure out where I went wrong :-). target/rcl/webapp/ should (I presume) end up containing everything that target/webapp does, right? My target/rcl/webapp contains only the WEB-INF, but nothing else. Any ideas? —ml—
Re: every new webapp a block?
On Jan 10, 2007, at 10:42 PM, Reinhard Poetz wrote: Maybe we should change the wording to [...] Cocoon web application should be done [...] to make the statement less exclusive. Though, in tutorials we should encourage our users to go down this path. This way they learn how to modularize a Cocoon webapp right from the beginning. Is it just so that new webapps don't have to bring along their own WEB-INF/? In return for that, they just have to provide a META-INF/cocoon/spring/core/whatever-block.xml, right? IIRC META-INF/cocoon/spring/whatever-block.xml, no core. right... brain spaz :-) So, OK... the rationale for the statement is really pedagogically motivated. Fair enough... :-) thx for the explanation... —ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 11, 2007, at 7:56 AM, Reinhard Poetz wrote: The RCL only works for blocks ATM. Ah! OK. So I'll just servletize the samples app and then I should be able to see the RCL in action. thx a lot, —ml—
RAD (was Re: Input modules samples broken in trunk)
On Jan 11, 2007, at 8:35 AM, Daniel Fagerstrom wrote: I described how to use Eclipse as that is what I have experience with. But if you can ensure that the Maven Jetty plugin gets the blocks as directories rather than jars at its classpath, that should work as well. That was going to be my next question... :-) One of my clients has other people who work on Cocoon web sites that I create. They do content updates, and one of them can do some CSS and a few elementary things in XSLT to tweak the site layout/styling. But these are pretty much non-technical peeps; for them Eclipse is a chewing gum [1]. And they don't know how to build these webapps on their own computers and run them locally, that's just beyond them. They work by remotely editing files in place in a development instance of the application running up on a server. Then, one of them I've taught how to do svn commits from dev and then update into the production instance (sometimes it gets botched and I have to go clean up a subversion mess by hand, but 95% of the time this works OK). So to move these apps forward to 2.2, I will need a no-brainer way for them to make live changes on the development instance in a server environment. But I think now that I understand all about what we're discussing here [2], I will probably end up keeping root-level application resources directly in the webapp module instead of servletizing them in a separate block. I think that will take care of most of our issues. [1] - http://www.wrigley.com/wrigley/products/products_eclipse.asp [2] - sorry, no reference for discussion thread every new webapp a block? — I can't find it on marc.theaimsgroup.com for some reason? thx, —ml—
Re: every new webapp a block?
I just added a section to http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1159.html explaining how to mount myBlock1 to the root context. I figure that's one of the first things a newbie is going to want to understand. I'm not really a newbie, but the first time(s) I read this tutorial I kept thinking yeah, but I don't want to make a block, I want to make my root-level webapp! cheers, —ml—
Re: Importing Cocoon projects into Eclipse
On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote: File - Import ... - General - Existing projects into workspace - Point on a directory that contains the project, it will be scanned for Eclipse project descriptors. It takes some time for Eclipse to scan all of cocoon-trunk. Choose the projects you want. D'oh, I've always just used this to import a single project, never noticed the scanning business :-o Take a look at properties - Java build path for the project, to see what other projects it depends on and make sure that you import all dependencies. Well, I'm really a little too lazy for that, but if that's what I have to do... :-/. Has anyone tried the Eclipse Maven plugin [1] ? —ml— [1] http://m2eclipse.codehaus.org/
Re: Importing Cocoon projects into Eclipse
On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote: File - Import ... - General - Existing projects into workspace - Point on a directory that contains the project, it will be scanned for Eclipse project descriptors. It takes some time for Eclipse to scan all of cocoon-trunk. Choose the projects you want. Take a look at properties - Java build path for the project, to see what other projects it depends on and make sure that you import all dependencies. I just imported all the projects in trunk. I get all kinds of errors of this sort: Unbound classpath variable: 'M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar' in project cocoon-core —ml—
Re: Input modules samples broken in trunk
On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote: [..snip] 4) If I want to debug this, I'm going to fiddle around with resources in the cocoon-core-additional-sample block (like the sitemap, JXTs etc.). How do I set things up so that those changes will take effect on the fly, without having to do some mvn install thing and restart Jetty? Any clues? —ml—
RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote: On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote: [..snip] 4) If I want to debug this, I'm going to fiddle around with resources in the cocoon-core-additional-sample block (like the sitemap, JXTs etc.). How do I set things up so that those changes will take effect on the fly, without having to do some mvn install thing and restart Jetty? Any clues? —ml— I just tried setting up the RCL per http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that the solution I'm after? I added the rcl.properties to cocoon-core-addition-sample/pom.xml and tweaked the cocoon-webapp/pom.xml, ran mvn rcl:webapp there... but when I request the webapp site root in my browser, I get: Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but that's all the sitemap.xmap etc., are all missing. Any ideas? —ml—
every new webapp a block?
Hi, just curious about something... The Getting Started page http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1159.html says, The development of any Cocoon web application is done within a block. What's the rationale for that? I'm just curious, that's all. Is it just so that new webapps don't have to bring along their own WEB-INF/? In return for that, they just have to provide a META-INF/cocoon/spring/core/whatever-block.xml, right? thx, —ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote: Don't know how rcl work, it is mainly for recompiling Java classes on the fly IIUC. Yes... what got me thinking RCL was this thread: http://marc.theaimsgroup.com/?t=11683427565r=1w=2 For resources it works as you want OOTB, if you run from Eclipse. What is important is that you run mvn eclipse:eclipse from top level. If you do that (and import the needed projectts into Eclipse), you can just run the Eclipse Jetty plugin and change the resources in the blocks and get result immediately. If you instead run eclipse:eclipse from within a project, you will instead get the installed jars in your Maven repository as dependencies and the you have to rebuild and restart. OK, thanks... I'll try it. It is also important to have -Dorg.apache.cocoon.mode=develop as argument to the Jetty launcher, otherwise the tree processor will not reload the resources when they change. JOOC, where's that implmented? Anyway... for whoever's interested, it seems like setting up cocoon-webapp for the RCL did not work as advertised for me, maybe I was doing something wrong? In any case I'll be moving on to try my luck with the Eclipse Jetty plugin. Thx a lot, —ml—
Importing Cocoon projects into Eclipse
OK... On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote: For resources it works as you want OOTB, if you run from Eclipse. What is important is that you run mvn eclipse:eclipse from top level. If you do that (and import the needed projectts into Eclipse), I ran mvn eclipse:eclipse; now which projects do I need to import, and what's the easiest way to do it? :-) (again, my goal here is to run the cocoon-webapp w/ samples using the Eclipse Jetty plugin...) thx, —ml—
project/description request
Hi, I'd like to make a modest request... if those who know how could add a little something to the description element in the various poms, I think it would help make the source base more broadly accessible, i.e. beyond the inner circle of people who have done the heavy lifting... :-) And going forward, IMHO all new modules should include some kind of what is this? readme info in the pom description. For instance (and this is just a for instance...), I see that we have cocoon-sitemap-components and cocoon-pipeline-components, and I have no clue why a component should be in one module vs. the other. Maybe I don't really have an urgent need to know, but probably knowing why there are both modules and what the difference is would help me to understand the Cocoon architecture better. WDYAT? —ml—
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
Hi Lars, On Jan 9, 2007, at 9:49 AM, Lars Huttar wrote: Ah, wait... I get it. By clicking on 422ms (how intuitive!), or xslt (testpage.xsl) (better), you get the XML output. Then you dig through the sample code, and discover that the profile generator takes URL parameters (not sitemap parameters) result and component that tell it to emit information about a particular output of a particular component. E.g. http://localhost/samples/blocks/profiler/profile.html?key= -9147137934425539743result=0component=1cocoon-view=content I guess the profile2.html view makes this a little more obvious, but only after you discover that the 0 under Last is a link, and that it might be something worthwhile to click on! If you want to improve the profiler web interface and you have the time to do it, please do it and drop a patch on JIRA (see below)... http://cocoon.apache.org/2.1/userdocs/profile-generator.html has some of this information; it would be good to have a link from http://cocoon.apache.org/2.1/userdocs/concepts/profiler.html to the latter. I've added a comment to that page in Daisy (does anybody read those comments?) Not sure... :-/ It would also be helpful to put an explanatory note about that on the sample page: http://localhost/samples/blocks/profiler/profile.html?key= -9147137934425539743 could say at the top, Click on a time to view the relevant XML result from that component. I agree, this is very useful functionality, but not very easy to discover. Hence its value for newcomers, who need it most, is greatly diminished. I think I would like to rework this sample to be more illuminating, and submit it for committing. I think ideally if you could make the profiler page itself more intuitive and/or add some explanatory text there (maybe)... then if more is needed on the sample page, it could be added. In other words, if the profiler page sucks, let's not just leave it that way and rely on the sample page to explain it, instead let's improve it as much as possible and if it still isn't self-explanatory, enhance the sample to bridge the gap. I would also be happy to work on improving the documentation pages. That would be great, too. You'll need to spend a little time in the docs area at cocoon.zones.apache.org to orient yourself, and Helma or Reinhard or somebody can hook you up with a Diasy login with doc-editor privileges, then you are set. Can somebody tell me the process for getting changes approved and committed? Right here: http://cocoon.apache.org/2.1/1177.html As for getting them approved, it seems like it's more of a do first approach in this community. You'll have to show them what you've got, in the form of a patch... and then, hopefully someday the patch will be accepted. You don't need any pre-approval to submit a patch, but neither is there any guarantee it'll be accepted. Sometimes further discussion is warranted, or the patch will be accepted w/ some modifications. I have a few patches in limbo on JIRA that I'd very much like to see accepted, so maybe it's time I made some noise :-) In any case, you're to be commended for wanting to improve both the code and the docs together :-) :-) :-) best regards, —ml—
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
On Jan 9, 2007, at 2:22 PM, Mark Lundquist wrote: [...] You'll need to spend a little time in the docs area at cocoon.zones.apache.org to orient yourself, and Helma or Reinhard or somebody can hook you up with a Diasy login with doc-editor privileges, then you are set. I think, to initially set up the account you select Register from the User: menubar item and create up your own account. (Maybe you've done that already, if you've submitted comments... I think having a registered user id is what enables you to comment? Not sure...) Anyway, once you're registered, then you just give a shout to the list, hey, I need the doc-editors role. cheers, —ml—
