Re: block-compile doesn't use source.vm property
Jean-Baptiste Quenot wrote:
* Andreas Hartmann:
the block-compile macro doesn't use the source.vm property.
Is this intentional?
javac destdir=${{build.blocks}}/@{{name}}/dest
debug=${{compiler.debug}}
optimize=${{compiler.optimize}}
deprecation=${{compiler.deprecation}}
+source=${{source.vm}}
target=${{target.vm}}
nowarn=${{compiler.nowarn}}
compiler=${{compiler}}
Hello,
What's this variable used for?
It determines the version of the Java source (1.2, 1.3, 1.4, ...).
I have a block which contains assert statements, and it won't compile
with the default setting. If I add the javac source attribute, it works.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Using trunk
David Crossley wrote:
Would someone please help to get started with Maven.
Too many days have been wasted.
I have today's Cocoon trunk. Installed Maven-2.0.2
$ cd cocoon-trunk
$ mvn -Dmaven.test.skip=true clean install
... watch thousands of warnings and stuff go by.
Then it gets to ...
Downloading:
http://snapshots.maven.codehaus.org/maven2//org/apache/cocoon/cocoon-default/1.0-SNAPSHOT/cocoon-default-1.0-SNAPSHOT.jar
[WARNING] Unable to get resource from repository maven-snapshot
(http://snapshots.maven.codehaus.org/maven2/)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
required artifacts missing:
org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
for the artifact:
org.apache.cocoon:cocoon-deployer-plugin-demo:jar:1.0-SNAPSHOT
from the specified remote repositories:
apache-maven2 (http://cvs.apache.org/maven-snapshot-repository),
central (http://repo1.maven.org/maven2),
maven-snapshot (http://snapshots.maven.codehaus.org/maven2/),
apache-cvs (http://cvs.apache.org/repository)
What do i do now? Thanks for any hints.
It's strange as cocoon-default-1.0-SNAPSHOT.jar, which is one of our *own*
modules should be build *locally* and put into your local repository and Maven
should be able to pick it up at build time.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: block-compile doesn't use source.vm property
* Andreas Hartmann: It determines the version of the Java source (1.2, 1.3, 1.4, ...). I have a block which contains assert statements, and it won't compile with the default setting. If I add the javac source attribute, it works. Committed, thanks! See http://svn.apache.org/viewcvs.cgi?rev=381601view=rev -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Block deployment
* Reinhard Poetz: uuups, the run.bat is obsolete. I've just removed it. Move to .\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and call mvn clean cocoon:simple-deploy from there. Yet another error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. required artifacts missing: org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT for the artifact: org.apache.cocoon:cocoon-deployer-plugin-demo:jar:1.0-SNAPSHOT from the specified remote repositories: apache-maven2 (http://cvs.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), maven-snapshot (http://snapshots.maven.codehaus.org/maven2/), apache-cvs (http://cvs.apache.org/repository) -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: block-compile doesn't use source.vm property
Jean-Baptiste Quenot wrote: * Andreas Hartmann: It determines the version of the Java source (1.2, 1.3, 1.4, ...). I have a block which contains assert statements, and it won't compile with the default setting. If I add the javac source attribute, it works. Committed, thanks! See http://svn.apache.org/viewcvs.cgi?rev=381601view=rev Thanks a lot! :) -- Andreas -- Andreas Hartmann Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Using trunk
Reinhard Poetz wrote: It's strange as cocoon-default-1.0-SNAPSHOT.jar, which is one of our *own* modules should be build *locally* and put into your local repository and Maven should be able to pick it up at build time. Yeah, i thought that it was very strange. Lets say i am a brand new developer, eager to try trunk. I can do svn stuff and have the checkout. The most recent Maven release 2.0.2 is installed and set the environment. Never used Maven before other than to do 'mvn --version'. What are the steps to see Cocoon running? I will write a quickstart Daisy doc. -David
Re: Block deployment
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
uuups, the run.bat is obsolete. I've just removed it.
Move to .\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and
call
mvn clean cocoon:simple-deploy
from there.
Yet another error:
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
required artifacts missing:
org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
for the artifact:
org.apache.cocoon:cocoon-deployer-plugin-demo:jar:1.0-SNAPSHOT
from the specified remote repositories:
apache-maven2 (http://cvs.apache.org/maven-snapshot-repository),
central (http://repo1.maven.org/maven2),
maven-snapshot (http://snapshots.maven.codehaus.org/maven2/),
apache-cvs (http://cvs.apache.org/repository)
I think David reported the same error. If you build the _complete_ trunk,
org.apache.cocoon:cocoon-deployer-plugin-demo should have been put into your
local repository. Are you sure that you haven't commented out the module in the
parent POM (./cocoon/trunk/pom.xml)?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Using trunk
Giacomo Pati wrote: Hi David Gidday ol' mate. Thanks for helping. David Crossley wrote: Would someone please help to get started with Maven. Too many days have been wasted. I have today's Cocoon trunk. Installed Maven-2.0.2 $ cd cocoon-trunk $ mvn -Dmaven.test.skip=true clean install ... watch thousands of warnings and stuff go by. I've very few WARNING messages (except those for old jar 'Not a v4.0.0 POM' ones, which come from 'legacy' Maven artifact. This was populating a brand new local repository. The WARNIN message you've included above come IIRC from network problems Maven encountered during download of artifacts. Just redo again until Maven was able to resolve all dependency (and thus has donwloaded all artifacts). Yeah i have been doing that. Gets to a different place each time. There are many warnings from various repos, but it usually gets each from one of the alternates. Also tried switching back to the EU mirror in ./settings.xml Currently failing at: Reason: Error getting POM for 'geronimo-spec:geronimo-spec-javamail' from the repository: Error transferring file geronimo-spec:geronimo-spec-javamail:pom:1.3.1-rc3 I can confirm, that my build runs almost all the time. Thanks, that helps :-) -David Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEA/lmLNdJvZjjVZARAjpfAJ9iT1k+Tp/tDszWos/Oxf0pDF8l+ACeM8Ll vgpvZdcwTBRTzbtV/4WvmRg= =jSys -END PGP SIGNATURE-
Re: Dependency on WebApplicationContext
Daniel Fagerstrom wrote: After you made the Settings object available on its own the Core doesn't seem to be used much anymore. So it seem like a good idea to remove it. The only remaining use seem to be as a shielding of the EnvironmentHelper. What is your plan for that functionality? I think we can make this available through the BeanFactory as well; but I'm not sure if this is a proper use of a bean factory. So basically, you have to lookup the bean each time you use it. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Reinhard Poetz schrieb: Carsten Ziegeler wrote: Reinhard Poetz wrote: As I wrote to you directly, the problem is that cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling mvn clean install from the project's base directory should solve the problem. I had to do this twice (strange), but now it works. Thanks! If you start Jetty then (mvn jetty6:run), and call http://localhost:/test, do you get an error (see below)? Is the global component registry, as implemented based on ECM, in place again? I'll test this tonight, Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Using trunk
David Crossley wrote:
Reinhard Poetz wrote:
It's strange as cocoon-default-1.0-SNAPSHOT.jar, which is one of our *own*
modules should be build *locally* and put into your local repository and
Maven should be able to pick it up at build time.
Yeah, i thought that it was very strange.
Lets say i am a brand new developer, eager to
try trunk. I can do svn stuff and have the checkout.
The most recent Maven release 2.0.2 is installed
and set the environment. Never used Maven before
other than to do 'mvn --version'.
What are the steps to see Cocoon running?
I will write a quickstart Daisy doc.
- install Maven as described in
http://maven.apache.org/download.html#installation
going through the tutorial in
http://maven.apache.org/guides/getting-started/index.html
is no mistake of course :-)
- Make sure, that mvn --version works for you
- checkout (update) ./cocoon/trunk
- call mvn clean install -Dmaven.test.skip=true from there
a) as long as you don't checkout again, you can always append
-o so that Maven is executed without connection to the network)
b) I'm used to call the clean goal first to be sure that everything
gets rebuild
- if trunk builds for you, follow the tutorial in
http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
(pls note: I'm not sure that my tutorial works. Yesterday it didn't
but last night (CET) Daniel checked in a fix that should have fixed
my problems. I'll report to the list as soon as I it works for
me again.)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Using trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 28 Feb 2006, David Crossley wrote: Date: Tue, 28 Feb 2006 21:15:37 +1100 From: David Crossley [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Using trunk Giacomo Pati wrote: Hi David Gidday ol' mate. Thanks for helping. No problem :-) David Crossley wrote: Would someone please help to get started with Maven. Too many days have been wasted. I have today's Cocoon trunk. Installed Maven-2.0.2 $ cd cocoon-trunk $ mvn -Dmaven.test.skip=true clean install ... watch thousands of warnings and stuff go by. I've very few WARNING messages (except those for old jar 'Not a v4.0.0 POM' ones, which come from 'legacy' Maven artifact. This was populating a brand new local repository. I've moved away my ~/.m2 directory as well just to see whethter I have the same problems as some of you guys had. It took quite awhile (~30 min) but I was able to compile hole trunk in one go. I have to admit that I'm using a Maven 2.1-SNAPSHOT build some weeks ago by myself (don't know if that has anything to do with it). I'm sitting here in the middle of Europe with quite a good Internet connectivity. The WARNIN message you've included above come IIRC from network problems Maven encountered during download of artifacts. Just redo again until Maven was able to resolve all dependency (and thus has donwloaded all artifacts). Yeah i have been doing that. Gets to a different place each time. There are many warnings from various repos, but it usually gets each from one of the alternates. Ok. Without having a ~/.m2 I got those lots of WARNING messages now as well. Also tried switching back to the EU mirror in ./settings.xml I do not even have a ~/.m2/settings.xml file. Most of the jars are downloaded from repo1.maven.org, some from cvs.apache.org AFAICS. Currently failing at: Reason: Error getting POM for 'geronimo-spec:geronimo-spec-javamail' from the repository: Error transferring file geronimo-spec:geronimo-spec-javamail:pom:1.3.1-rc3 I can confirm, that my build runs almost all the time. Thanks, that helps :-) Cool :-) Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEBC81LNdJvZjjVZARAnPiAKCrJaTtWQHDBWipGFCP9DfvO2qQHQCgkp0R H9OFj/9OEZbZFwRBYprZaZw= =4aCw -END PGP SIGNATURE-
environment errors
Dear all, I have a few errors here which I really cannot explain, maybe someone can shed some light on the matter? The weird thing is, the application works fine, despite the errors below... But I am very curious what could make these things happen. I have a creepy feeling that this might be only the tip of the iceberg... Number one: This one seems to be caused by a missing or empty EnvironmentStack.. I know too little about the deep internals to see what is going wrong. The funny thing is that no other pipeline seems to cause this error... 20060228105414614 ERROR sitemap.pipes.ecaching (cms.minfin.hat02:50103/editing/cf2/showForm/homepage//content/minfin/nl/documents/3830391d5f16882584601334453f74526e7e327f.continue) main-24/AbstractProcessingPipeline: Unable to release self from automatic release. org.apache.cocoon.ProcessingException: Unable to remove component from automatic release: no environment available. at org.apache.cocoon.components.CocoonComponentManager.removeFromAutomaticRelease(CocoonComponentManager.java:489) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.release(AbstractProcessingPipeline.java:184) at org.apache.cocoon.components.source.impl.SitemapSource.reset(SitemapSource.java:433) at org.apache.cocoon.components.source.impl.SitemapSource.recycle(SitemapSource.java:460) at org.apache.cocoon.components.source.impl.SitemapSourceFactory.release(SitemapSourceFactory.java:78) at org.apache.excalibur.source.impl.SourceResolverImpl.release(SourceResolverImpl.java:269) at org.apache.cocoon.components.CocoonComponentManager.release(CocoonComponentManager.java:548) at org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironment.java:565) at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:308) at org.apache.cocoon.sitemap.ContentAggregator.recycle(ContentAggregator.java:274) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.put(InstrumentedResourceLimitingPool.java:407) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:212) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:425) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:307) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:300) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:720) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:77) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:993) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.put(InstrumentedResourceLimitingPool.java:407) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:212) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:425) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:307) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:300) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:297) at org.apache.cocoon.components.EnvironmentDescription.release(CocoonComponentManager.java:678) at org.apache.cocoon.components.CocoonComponentManager.endProcessing(CocoonComponentManager.java:243) at org.apache.cocoon.Cocoon.process(Cocoon.java:719) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at nl.hippo.util.ResponseEncodingFilter.doFilter(ResponseEncodingFilter.java:36) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at
Re: Using trunk
Giacomo Pati wrote: David Crossley wrote: Giacomo Pati wrote: David Crossley wrote: Would someone please help to get started with Maven. Too many days have been wasted. I have today's Cocoon trunk. Installed Maven-2.0.2 $ cd cocoon-trunk $ mvn -Dmaven.test.skip=true clean install ... watch thousands of warnings and stuff go by. I've very few WARNING messages (except those for old jar 'Not a v4.0.0 POM' ones, which come from 'legacy' Maven artifact. This was populating a brand new local repository. I've moved away my ~/.m2 directory as well just to see whethter I have the same problems as some of you guys had. It took quite awhile (~30 min) but I was able to compile hole trunk in one go. I have to admit that I'm using a Maven 2.1-SNAPSHOT build some weeks ago by myself (don't know if that has anything to do with it). I'm sitting here in the middle of Europe with quite a good Internet connectivity. The WARNIN message you've included above come IIRC from network problems Maven encountered during download of artifacts. Just redo again until Maven was able to resolve all dependency (and thus has donwloaded all artifacts). Yeah i have been doing that. Gets to a different place each time. There are many warnings from various repos, but it usually gets each from one of the alternates. Ok. Without having a ~/.m2 I got those lots of WARNING messages now as well. Sounds like i need to just keep banging away with mvn install. Also tried switching back to the EU mirror in ./settings.xml I do not even have a ~/.m2/settings.xml file. $COCOON_HOME/settings.xml Most of the jars are downloaded from repo1.maven.org, some from cvs.apache.org AFAICS. And the failures here are mostly from snapshots.maven.codehaus.org and cvs.apache.org -David
Re: Using trunk
On 2/28/06, David Crossley [EMAIL PROTECTED] wrote: Giacomo Pati wrote: David Crossley wrote: Giacomo Pati wrote: David Crossley wrote: Would someone please help to get started with Maven. Too many days have been wasted. I have today's Cocoon trunk. Installed Maven-2.0.2 $ cd cocoon-trunk $ mvn -Dmaven.test.skip=true clean install ... watch thousands of warnings and stuff go by. I've very few WARNING messages (except those for old jar 'Not a v4.0.0 POM' ones, which come from 'legacy' Maven artifact. This was populating a brand new local repository. I've moved away my ~/.m2 directory as well just to see whethter I have the same problems as some of you guys had. It took quite awhile (~30 min) but I was able to compile hole trunk in one go. I have to admit that I'm using a Maven 2.1-SNAPSHOT build some weeks ago by myself (don't know if that has anything to do with it). I'm sitting here in the middle of Europe with quite a good Internet connectivity. The WARNIN message you've included above come IIRC from network problems Maven encountered during download of artifacts. Just redo again until Maven was able to resolve all dependency (and thus has donwloaded all artifacts). Yeah i have been doing that. Gets to a different place each time. There are many warnings from various repos, but it usually gets each from one of the alternates. Ok. Without having a ~/.m2 I got those lots of WARNING messages now as well. Sounds like i need to just keep banging away with mvn install. David, I have tried what Reinhard described above four times now. 1-Failed, 2-Failed, 3-Success, 4-Failed. It seems to fail at different locations for different reasons each time. --tim
Re: FYI: OSGi JSR
Daniel Fagerstrom wrote: Apache and some other well known organizations have started an JSR for dynamic component framework in Java SE based on OSGi. http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-for.html http://www.jcp.org/en/jsr/detail?id=291 4 months to get a JSR out of the door? whatever. This seems a rushed up battle against JSR 277, which states: The current version of the Open Services Gateway Initiative (OSGi) specification defines a framework that enables the deployment of service-oriented applications (called bundles). However, the framework only supports package dependency based on the minimum version of a specification, and there is no support for exact version or version range. The framework also supports package dependency based on an implementation, but there is no support for versioning. Moreover, the framework must choose one bundle that will be the provider of the exported package for all bundles which have dependencies on that package, so it is impossible to support more than one version of shared package at runtime. Besides, the selection of exported package provider is anonymous, and there is no way to influence the selection. Because the versioning semantics in the OSGi framework is simplistic, it is not a sufficient solution to address the JAR referencing problem. While JSR 291 states: No current JSR (either complete or in process) defines a dynamic component and lifecycle solution to run on top of the existing family of Java SE platforms. However, JSR 232 does include this capability to run on top of Java ME (CDC based platforms) along with a comprehensive set of mobility services. JSR 277 has been filed to examine changes to the static module definition to be used within the Java SE platform for Java 7 (Dolphin) and beyond. JSR 277 is targeted for specification delivery in 2H/2007 with RI/TCK delivery as an integral part of Dolphin in 2008. This JSR aims to address the current needs for dynamic components based on existing Java SE platforms. When Dolphin becomes available, the specification lead of this JSR will either perform a maintenance release of this JSR or raise a follow on JSR to add Dolphin to the list of compatible supported platforms and to exploit Dolphin technology for static modules, as appropriate. These two JSRs are heading on a massive collision course. -- Stefano Mazzocchi Research Scientist Digital Libraries Research Group Massachusetts Institute of Technologylocation: E25-131C 77 Massachusetts Ave telephone: +1 (617) 253-1096 Cambridge, MA 02139-4307 email: stefanom at mit . edu ---
Re: Block deployment
* Reinhard Poetz: I think David reported the same error. If you build the _complete_ trunk, org.apache.cocoon:cocoon-deployer-plugin-demo should have been put into your local repository. Are you sure that you haven't commented out the module in the parent POM (./cocoon/trunk/pom.xml)? After issuing « svn revert pom.xml » I issue a « mvn clean war:inplace » and get another error trying to build full trunk: [INFO] [INFO] Building cocoon-default [INFO]task-segment: [war:inplace] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. required artifacts missing: org.apache.cocoon:cocoon-sitemap-impl:jar:1.0-SNAPSHOT org.apache.cocoon:cocoon-blocks-fw-servlet-impl:jar:1.0-SNAPSHOT org.apache.cocoon:cocoon-blocks-fw-ecm-impl:jar:1.0-SNAPSHOT for the artifact: org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Block deployment
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
I think David reported the same error. If you build the
_complete_ trunk, org.apache.cocoon:cocoon-deployer-plugin-demo
should have been put into your local repository. Are you sure
that you haven't commented out the module in the parent POM
(./cocoon/trunk/pom.xml)?
After issuing « svn revert pom.xml » I issue a « mvn clean
war:inplace » and get another error trying to build full trunk:
[INFO]
[INFO] Building cocoon-default
[INFO]task-segment: [war:inplace]
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
required artifacts missing:
org.apache.cocoon:cocoon-sitemap-impl:jar:1.0-SNAPSHOT
org.apache.cocoon:cocoon-blocks-fw-servlet-impl:jar:1.0-SNAPSHOT
org.apache.cocoon:cocoon-blocks-fw-ecm-impl:jar:1.0-SNAPSHOT
for the artifact:
org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Have you called
mvn clean install -Dmaven.test.skip=true
from
./cocoon/trunk
?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: environment errors
* Max Pfingsthorn: org.apache.cocoon.ProcessingException: Unable to remove component from automatic release: no environment available. at org.apache.cocoon.components.CocoonComponentManager.removeFromAutomaticRelease(CocoonComponentManager.java:489) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.release(AbstractProcessingPipeline.java:184) at org.apache.cocoon.components.source.impl.SitemapSource.reset(SitemapSource.java:433) at org.apache.cocoon.components.source.impl.SitemapSource.recycle(SitemapSource.java:460) at org.apache.cocoon.components.source.impl.SitemapSourceFactory.release(SitemapSourceFactory.java:78) at org.apache.excalibur.source.impl.SourceResolverImpl.release(SourceResolverImpl.java:269) Same here. Happens when using « cocoon: » which is implemented by SitemapSource. This object is not properly released/recycled/reset upon concurrent requests. This does not happen on my development server, but happens on a production server. This is harmless but annoying. You may just disable the error reporting if you wish. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [CRAZY IDEA] sitemaps in javascript
On 2/27/06, Irv Salisbury [EMAIL PROTECTED] wrote: I have to admit that the cocoon sitemaps we use for our projects have gotten out of hand. If a new person started working on it, they would need a sitemap for the sitemaps. Because of the common stuff we want to do across projects, we actually start with sitemap xml snippets that we include with DTD includes. (Yes I know it is ugly but the best we could come up with for common sitemap stuff without true includes) I've just got to ask why you've got such a large amount of stuff going into the sitemap? Is there no back end database that can be used for configuration data once you've got the basic flow mapped out? We tend to use the sitemap at a very high level, only _major_ constructs have their own entries and these serve as generic entry points for the finer grained subcomponents based on them. This way, even without a back end database you can avoid having to configure everything in the sitemap. For example, we may have a matcher on things like: foo/*.display foo/*.edit foo/*.list foo/*.grid where display, edit, list and grid are main screen types. A generic generator then picks up the wild card pattern and uses it to effectively pick subclasses for these types (not necessarily literally, but you should get the idea?). Normal query parameters or whatever then do specific page selection and configure the resultant page more precisely. In our case we're currently have 12 or so generators that build 1000's of different screens. The main reason for even having this many generators is that they map to major orthogonal slices of the application (eg. validation, or page generation, or system wide data or authentication data) that have very different usage and caching patterns. In theory we'll eventually cut this number in half as we find the more general patterns of usage. We have 3 action handlers, one of which is used just for parameter forwarding, one for authentication and one for everything else... There's a single reader, a couple of modules, and 30 or so XSLT. We've still got a 1000 line sitemap, but probably about a 1/4 of that is for testing purposes and another 1/4 of it can eventually disappear as we refine things even further. snip/ -- Peter Hunsberger
Re: environment errors
Jean-Baptiste Quenot schrieb: * Max Pfingsthorn: org.apache.cocoon.ProcessingException: Unable to remove component from automatic release: no environment available. at org.apache.cocoon.components.CocoonComponentManager.removeFromAutomaticRelease(CocoonComponentManager.java:489) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.release(AbstractProcessingPipeline.java:184) at org.apache.cocoon.components.source.impl.SitemapSource.reset(SitemapSource.java:433) at org.apache.cocoon.components.source.impl.SitemapSource.recycle(SitemapSource.java:460) at org.apache.cocoon.components.source.impl.SitemapSourceFactory.release(SitemapSourceFactory.java:78) at org.apache.excalibur.source.impl.SourceResolverImpl.release(SourceResolverImpl.java:269) Same here. Happens when using « cocoon: » which is implemented by SitemapSource. This object is not properly released/recycled/reset upon concurrent requests. This does not happen on my development server, but happens on a production server. This is harmless but annoying. You may just disable the error reporting if you wish. It would be great if you or Max could come up with some test case so we can reproduce the problem and then try to fix it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FYI: OSGi JSR
On Tuesday 28 February 2006 21:20, Stefano Mazzocchi wrote: These two JSRs are heading on a massive collision course. Not if the people involved don't want that to happen. The most important difference (as I see it) between the two is that JSR-291 is a fast track add-on for those who want it now (debatable how long that is, as you pointed out). And for people like me, who are not on an upgrade train to JDK5 yet(!), which has been out ~2years already, and unlikely to run JDK7 for the next 4-5 years, I think JSR-291 is providing a reasonable middle-ground. Should it be a JSR?? Why not? Most JSRs are formalizations of stuff that already exist... And IIRC, Stefano, you are in the camp rather something that works today, than the perfect system in a few years ;o) If JSR-277 will come up with something that surpasses every bit and corner of the JSR-291, then GREAT! Let me remind you of a good enough collection API way back in time, I think it was simply called JCL. It was available in 1997 (perhaps earlier) and solved me a great deal of work back then. When the official Collection API came out, its purpose was ending... No shame in that. :o) Cheers Niclas
[jira] Created: (COCOON-1785) I18nMessage - null parameter values causes NPE
I18nMessage - null parameter values causes NPE -- Key: COCOON-1785 URL: http://issues.apache.org/jira/browse/COCOON-1785 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Attachments: I18nMessageNPE.txt Putting a null in a parameter value causes an NPE when creating the SAX events java.lang.NullPointerException at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128) at org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85) at org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453) at org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498) at org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292) Note: this NPE then causes the Ajax transformer to go wonky for all users in all sessions. I'm still digging into that one. I am attaching a patch (license granted to ASF) that allows null parameter values (using String.valueOf(parameters[i]) so that nulls are turned into null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1785) I18nMessage - null parameter values causes NPE
[ http://issues.apache.org/jira/browse/COCOON-1785?page=all ] Antonio Gallardo reassigned COCOON-1785: Assign To: Antonio Gallardo I18nMessage - null parameter values causes NPE -- Key: COCOON-1785 URL: http://issues.apache.org/jira/browse/COCOON-1785 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Assignee: Antonio Gallardo Attachments: I18nMessageNPE.txt Putting a null in a parameter value causes an NPE when creating the SAX events java.lang.NullPointerException at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128) at org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85) at org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453) at org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498) at org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292) Note: this NPE then causes the Ajax transformer to go wonky for all users in all sessions. I'm still digging into that one. I am attaching a patch (license granted to ASF) that allows null parameter values (using String.valueOf(parameters[i]) so that nulls are turned into null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dependency on WebApplicationContext
Carsten Ziegeler schrieb: Reinhard Poetz schrieb: Carsten Ziegeler wrote: Reinhard Poetz wrote: As I wrote to you directly, the problem is that cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling mvn clean install from the project's base directory should solve the problem. I had to do this twice (strange), but now it works. Thanks! If you start Jetty then (mvn jetty6:run), and call http://localhost:/test, do you get an error (see below)? Is the global component registry, as implemented based on ECM, in place again? I'll test this tonight, Ok, this works for me now; I get the simple xml page - no errors. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FYI: OSGi JSR
I think there are lots of politics involved. Peter Kriens, OSGi spec author, evangelist and old timer was rejected to become a member of JSR277, and is upset about it: http://www.aqute.biz/2006/02/osgi-and-jsr-277-bad-vibes.html, (he have written a number of times about it on his blog). Interesting enough Richard Hall, Felix lead and OSGi member, is part of both JSRs. All the issues with OSGi listed in the citation from JSR 277 are solved in OSGi R4. IBM seem to make a huge investment in OSGi while Sun doesn't, so I wouldn't be surprised if this is part of there fighting as well. Anyway, standardized Java modularization is needed now, so waiting to Java 7, seem less attractive. /Daniel Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Apache and some other well known organizations have started an JSR for dynamic component framework in Java SE based on OSGi. http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-for.html http://www.jcp.org/en/jsr/detail?id=291 4 months to get a JSR out of the door? whatever. This seems a rushed up battle against JSR 277, which states: The current version of the Open Services Gateway Initiative (OSGi) specification defines a framework that enables the deployment of service-oriented applications (called bundles). However, the framework only supports package dependency based on the minimum version of a specification, and there is no support for exact version or version range. The framework also supports package dependency based on an implementation, but there is no support for versioning. Moreover, the framework must choose one bundle that will be the provider of the exported package for all bundles which have dependencies on that package, so it is impossible to support more than one version of shared package at runtime. Besides, the selection of exported package provider is anonymous, and there is no way to influence the selection. Because the versioning semantics in the OSGi framework is simplistic, it is not a sufficient solution to address the JAR referencing problem. While JSR 291 states: No current JSR (either complete or in process) defines a dynamic component and lifecycle solution to run on top of the existing family of Java SE platforms. However, JSR 232 does include this capability to run on top of Java ME (CDC based platforms) along with a comprehensive set of mobility services. JSR 277 has been filed to examine changes to the static module definition to be used within the Java SE platform for Java 7 (Dolphin) and beyond. JSR 277 is targeted for specification delivery in 2H/2007 with RI/TCK delivery as an integral part of Dolphin in 2008. This JSR aims to address the current needs for dynamic components based on existing Java SE platforms. When Dolphin becomes available, the specification lead of this JSR will either perform a maintenance release of this JSR or raise a follow on JSR to add Dolphin to the list of compatible supported platforms and to exploit Dolphin technology for static modules, as appropriate. These two JSRs are heading on a massive collision course.
Re: Dependency on WebApplicationContext
Carsten Ziegeler wrote:
Carsten Ziegeler schrieb:
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base directory should solve the problem.
I had to do this twice (strange), but now it works. Thanks!
If you start Jetty then (mvn jetty6:run), and call http://localhost:/test,
do you get an error (see below)?
Is the global component registry, as implemented based on ECM, in place again?
I'll test this tonight,
Ok, this works for me now; I get the simple xml page - no errors.
Thanks, it works for me now too!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [CRAZY IDEA] sitemaps in javascript
Much of what you asking for is on its way and there is plenty of room for contributions ;) Sitemap inheritance (or actually servlet inheritance), is part of the block architecture and implemented nearly a year ago. The blocks architecture still need some polishing before its ready for prime time, but we are not that far away. With the blocks architecture the sitemap doesn't need to be the main controller anymore. It will be possible to have e.g. a flowscript controller (or any servlet) as the main controller instead. It could be implemented and integrated right away if someone is interested to work on it. For aggregation and content based routing, pull pipelines are superior. Axis2 have already developed much of the infrastructure that is needed. Sylvain started to look on how to integrate that in Cocoon during ther last ApacheCon. Pull pipelines also would make a huge difference in performance for work with huge XML documents from e.g. data bases. In short, there are some really interesting projects to work on for those who are interested :) /Daniel Irv Salisbury skrev: I have to admit that the cocoon sitemaps we use for our projects have gotten out of hand. If a new person started working on it, they would need a sitemap for the sitemaps. Because of the common stuff we want to do across projects, we actually start with sitemap xml snippets that we include with DTD includes. (Yes I know it is ugly but the best we could come up with for common sitemap stuff without true includes) Now, once you get past that, there are a ton of common resource calls with parameters. Each of these uses aggregation and the cinclude transformer. The cinclude transformer of course has calls to cocoon:// pipelines. So, now the spaghetti starts getting nasty. All of this is in the name of reuse and without having true inheritance and an easy aggregation mechanism, we have had to do these things. Add in the mix of flowscript and you really have a nightmare on your hands. We have tried to keep to rules of what goes where, but somebody new coming onto our project would need at least a couple weeks and a roadmap to find their way around. Having a nice, clean include mechanism and an easy inline way of doing aggregation, coupled with the ability to do easy content based routing (yeah don't get me started on that one) and our sitemap would be a LOT cleaner. We accomplish content based routing by using XMLBeans, calling a pipeline that fills up the bean in flowscript, checking the values, then calling the appropriate other pipelines. The back and forth of this is pretty nasty. So, I would wholeheartedly agree that either javascript or java (my preference) for a sitemap language would be great. To offer the possiblity of not having to pass XML through the pipeline would be even better. For performance reasons, if I could just manipulate java (using hibernate or the like) the only go to XML for the final step is great. This can be accomplished somewhat with the current system, but you still have to go back and forth from flowscript to sitemap, and get all the yuck with that. Irv On 2/1/06, *Antonio Gallardo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Sylvain Wallez wrote: Experience showed that the sitemap language is actually very simple, and that people quickly find it more productive to write their sitemap with a content-assist editor. In this regard, the WebTools XML editor auto-learning feature does quite a good job once a sitemap contains one instance of each of the base instructions (match, generate, transform, etc). Here a fully commented schema for all the cocoon special files will help a lot for newbies. Now, to speak clearly, I'm thinking about closing Lepido at Eclipse, first because for a number of reasons on which I could expand it didn't attract people, and because the future of Cocoon is so unclear to me that investing in the development of a tool that may quickly be obsolete looks like wasted energy. Wow! :-( I installed Lepido. I wanted to reach you sometimes to speak about the Lepido future and how to start working on it. Best Regards, Antonio Gallardo.
Building trunk - Maven is your friend
After some thinking I think I have a simple solution to our problem about how to build trunk with m2: it's simple, Maven can do this for us! The Maven war plugin is able to assemble the webapp by combining the contents of several war projects. So if we change all of our blocks projects (that have samples or web resources) from jar to war and then add the dependency to the war project in the pom in cocoon-webapp, Maven does everything for us. I just tried this with the cocoon-session-fw-sample block and it seems to work. Though I did not get everything working. See below Now - as always - there are some (minor) problems: - Currently Maven requires that a war has a web.xml: This requires to add a dummy web.xml to each sample block; this web.xml is later on ignored as the web.xml from the cocoon-webapp is used. I guess if we go this way, we can ask the maven guys to provide some option to make web.xml optional. - We have to restructure the directory layout of our blocks a little bit: all resources for the webapp should go to src/main/webapp. So, for example a block with a configuration (no sample block) has: src/main/webapp/WEB-INF/conf with the configuration files while a sample block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory. - This seems to require the development version of the webapp plugin and I wasn't able to include two webapps (session-fw-impl and session-fw). Though looking at the code, it should work, m2 refused to do this, but I had a week network connection, so it might be due to this?; I don't have time today to invest here further, but I'm sure it should work, so this should be a viable solution. I think someone recently raised the question, how we distinguish between sample and and functionality blocks. I think for now we can go with a naming convention: if you want the sample, you depend on the sample project, if not you depend on the impl. WDYT? -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Building trunk - Maven is your friend
Carsten Ziegeler wrote: After some thinking I think I have a simple solution to our problem about how to build trunk with m2: it's simple, Maven can do this for us! The Maven war plugin is able to assemble the webapp by combining the contents of several war projects. So if we change all of our blocks projects (that have samples or web resources) from jar to war and then add the dependency to the war project in the pom in cocoon-webapp, Maven does everything for us. I just tried this with the cocoon-session-fw-sample block and it seems to work. Though I did not get everything working. See below Now - as always - there are some (minor) problems: - Currently Maven requires that a war has a web.xml: This requires to add a dummy web.xml to each sample block; this web.xml is later on ignored as the web.xml from the cocoon-webapp is used. I guess if we go this way, we can ask the maven guys to provide some option to make web.xml optional. - We have to restructure the directory layout of our blocks a little bit: all resources for the webapp should go to src/main/webapp. So, for example a block with a configuration (no sample block) has: src/main/webapp/WEB-INF/conf with the configuration files while a sample block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory. - This seems to require the development version of the webapp plugin and I wasn't able to include two webapps (session-fw-impl and session-fw). Though looking at the code, it should work, m2 refused to do this, but I had a week network connection, so it might be due to this?; I don't have time today to invest here further, but I'm sure it should work, so this should be a viable solution. I think someone recently raised the question, how we distinguish between sample and and functionality blocks. I think for now we can go with a naming convention: if you want the sample, you depend on the sample project, if not you depend on the impl. I like it. Still I have one big issue with m2 webapp approach: mvn war:inplace copies all resources to cocoon-webapp/src/webapp directory. There is no mvn clean for that and no easy way to tell which file really belongs to cocoon-webapp/src/webapp/** and which one is copied over from another module (and under no circumstances should be commited to the repository). -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Dependency on WebApplicationContext
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: After you made the Settings object available on its own the Core doesn't seem to be used much anymore. So it seem like a good idea to remove it. The only remaining use seem to be as a shielding of the EnvironmentHelper. What is your plan for that functionality? I think we can make this available through the BeanFactory as well; but I'm not sure if this is a proper use of a bean factory. So basically, you have to lookup the bean each time you use it. WDYT? I'm not certain either. The solution with you choose with a statically available thread local, lead to less code, so it seem like a good solution :) /Daniel
Re: Building trunk - Maven is your friend
Carsten Ziegeler wrote:
After some thinking I think I have a simple solution to our problem
about how to build trunk with m2: it's simple, Maven can do this for us!
The Maven war plugin is able to assemble the webapp by combining the
contents of several war projects. So if we change all of our blocks
projects (that have samples or web resources) from jar to war and
please don't do this, I will explain later
then add the dependency to the war project in the pom in cocoon-webapp,
Maven does everything for us. I just tried this with the
cocoon-session-fw-sample block and it seems to work. Though I did not
get everything working. See below
Now - as always - there are some (minor) problems:
- Currently Maven requires that a war has a web.xml: This requires to
add a dummy web.xml to each sample block; this web.xml is later on
ignored as the web.xml from the cocoon-webapp is used. I guess if we go
this way, we can ask the maven guys to provide some option to make
web.xml optional.
- We have to restructure the directory layout of our blocks a little
bit: all resources for the webapp should go to src/main/webapp. So, for
example a block with a configuration (no sample block) has:
src/main/webapp/WEB-INF/conf with the configuration files while a sample
block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
no, please don't do this either. We need our resources in
src/main/resources/COB-INF to make them 'real blocks'. Doing something
different, would be a step into the wrong direction.
- This seems to require the development version of the webapp plugin and
I wasn't able to include two webapps (session-fw-impl and session-fw).
Though looking at the code, it should work, m2 refused to do this, but
I had a week network connection, so it might be due to this?; I don't
have time today to invest here further, but I'm sure it should work,
so this should be a viable solution.
I think someone recently raised the question, how we distinguish between
sample and and functionality blocks. I think for now we can go with a
naming convention: if you want the sample, you depend on the sample
project, if not you depend on the impl.
WDYT?
The problem is that the solution doesn't handle dependencies and we don't get a
wiring.xml. Both problems are solved by the block-deployer.
Please have a look at my both tutorials
http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
to get an idea how I think block deployment (and the creation of web
applications) should worl.
The first one already works and I will make the second one work ASAP (hopefully
this week) so that we can create a web application that consists of more than
one block.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Using trunk
David Crossley skrev: ... And the failures here are mostly from snapshots.maven.codehaus.org We should avoid the use of snapshots as far as possible. Besides the obvious wish to build Cocoon on stable ground, the snapshots complicates Maven use as Maven check the repositories for more recent snapshots at every build, instead of just when the needed version isn't in your local repository. This lead to much slower builds, and more stress on the repositories. And as they not are so stable, it is frustrating. Anyone knowing what we use from the above repository, I didn't find anything obvious. and cvs.apache.org Here we have the Cocoon snapshots, if we get them to start to be built automatically again, they will simplify life in the way that one only need to checkout the block one is working on. Recent builds of the dependent blocks will be downloaded during built. So here the advantage of snapshots probably is greater than the disadvantage. /Daniel
Re: Block deployment
These artifact is newer than the latest update of the snapshot repository, you need to compile and install cocoon-blocks-fw and cocoon-sitemap in you local repository to get it to work. And in general you need to get all Cocoon blocks from your local repository as the one from the snapshot repository are obsolete. Do a $ mvn -Dmaven.test.skip=true clean install from cocoon-trunk. /Daniel Jean-Baptiste Quenot skrev: * Reinhard Poetz: I think David reported the same error. If you build the _complete_ trunk, org.apache.cocoon:cocoon-deployer-plugin-demo should have been put into your local repository. Are you sure that you haven't commented out the module in the parent POM (./cocoon/trunk/pom.xml)? After issuing « svn revert pom.xml » I issue a « mvn clean war:inplace » and get another error trying to build full trunk: [INFO] [INFO] Building cocoon-default [INFO]task-segment: [war:inplace] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. required artifacts missing: org.apache.cocoon:cocoon-sitemap-impl:jar:1.0-SNAPSHOT org.apache.cocoon:cocoon-blocks-fw-servlet-impl:jar:1.0-SNAPSHOT org.apache.cocoon:cocoon-blocks-fw-ecm-impl:jar:1.0-SNAPSHOT for the artifact: org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2)
Re: Building trunk - Maven is your friend
Carsten Ziegeler wrote:
After some thinking I think I have a simple solution to our problem
about how to build trunk with m2: it's simple, Maven can do this for us!
The Maven war plugin is able to assemble the webapp by combining the
contents of several war projects. So if we change all of our blocks
projects (that have samples or web resources) from jar to war and
please don't do this, I will explain later
then add the dependency to the war project in the pom in cocoon-webapp,
Maven does everything for us. I just tried this with the
cocoon-session-fw-sample block and it seems to work. Though I did not
get everything working. See below
Now - as always - there are some (minor) problems:
- Currently Maven requires that a war has a web.xml: This requires to
add a dummy web.xml to each sample block; this web.xml is later on
ignored as the web.xml from the cocoon-webapp is used. I guess if we go
this way, we can ask the maven guys to provide some option to make
web.xml optional.
- We have to restructure the directory layout of our blocks a little
bit: all resources for the webapp should go to src/main/webapp. So, for
example a block with a configuration (no sample block) has:
src/main/webapp/WEB-INF/conf with the configuration files while a sample
block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
no, please don't do this either. We need our resources in
src/main/resources/COB-INF to make them 'real blocks'. Doing something
different, would be a step into the wrong direction.
- This seems to require the development version of the webapp plugin and
I wasn't able to include two webapps (session-fw-impl and session-fw).
Though looking at the code, it should work, m2 refused to do this, but
I had a week network connection, so it might be due to this?; I don't
have time today to invest here further, but I'm sure it should work,
so this should be a viable solution.
I think someone recently raised the question, how we distinguish between
sample and and functionality blocks. I think for now we can go with a
naming convention: if you want the sample, you depend on the sample
project, if not you depend on the impl.
WDYT?
The problem is that the solution doesn't handle dependencies and we don't get a
wiring.xml. Both problems are solved by the block-deployer.
Please have a look at my both tutorials
http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
to get an idea how I think block deployment (and the creation of web
applications) should worl.
The first one already works and I will make the second one work ASAP (hopefully
this week) so that we can create a web application that consists of more than
one block.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Building trunk - Maven is your friend
Reinhard Poetz skrev: Carsten Ziegeler wrote: After some thinking I think I have a simple solution to our problem about how to build trunk with m2: it's simple, Maven can do this for us! The Maven war plugin is able to assemble the webapp by combining the contents of several war projects. So if we change all of our blocks projects (that have samples or web resources) from jar to war and please don't do this, I will explain later then add the dependency to the war project in the pom in cocoon-webapp, Maven does everything for us. I just tried this with the cocoon-session-fw-sample block and it seems to work. Though I did not get everything working. See below Now - as always - there are some (minor) problems: - Currently Maven requires that a war has a web.xml: This requires to add a dummy web.xml to each sample block; this web.xml is later on ignored as the web.xml from the cocoon-webapp is used. I guess if we go this way, we can ask the maven guys to provide some option to make web.xml optional. - We have to restructure the directory layout of our blocks a little bit: all resources for the webapp should go to src/main/webapp. So, for example a block with a configuration (no sample block) has: src/main/webapp/WEB-INF/conf with the configuration files while a sample block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory. no, please don't do this either. We need our resources in src/main/resources/COB-INF to make them 'real blocks'. Doing something different, would be a step into the wrong direction. I agree with Reinhard to a large part, and would also like to add that the proposed solution will be quite heavy as each block will need a copy of cocoon-core and all its dependencies. OTH we badly need to get some limited samples working for trunk ASAP. So that the community can get its faith in trunk back. And so that the threshold for getting involved in trunk development and testing becomes lower. So I suggest that we follow Carstens suggestion for a few important samples like forms and portal samples. And make the cocoon-webapp dependent on these samples. But instead of moving the configuration files from src/main/resources, we should just copy them to the samples. Copying is of course not ideal, but it will only be for a few samples, so it shouldn't be that much work to keep in synch, and it is only for a limited time. I'm totally against moving the configuration files, as it will disturb the blocks work, and we are close to be able to deliver something much more usable than the above solution. /Daniel
Re: Using trunk
Tim Williams wrote: David Crossley wrote: Giacomo Pati wrote: David Crossley wrote: Yeah i have been doing that. Gets to a different place each time. There are many warnings from various repos, but it usually gets each from one of the alternates. Ok. Without having a ~/.m2 I got those lots of WARNING messages now as well. Sounds like i need to just keep banging away with mvn install. I have tried what Reinhard described above four times now. 1-Failed, 2-Failed, 3-Success, 4-Failed. It seems to fail at different locations for different reasons each time. I finally got it, continuing to do subsequent mvn install -Dmaven.test.skip=true the local repository gradually fills. Don't know if it helps, but getting subsequent failures on the same jar, then try switching mirrors in $COCOON_HOME/settings.xml -David
Quickstart to Cocoon-2.2 with Maven (Was: Using trunk)
David Crossley wrote: Reinhard Poetz wrote: David Crossley wrote: Lets say i am a brand new developer, eager to try trunk. I can do svn stuff and have the checkout. The most recent Maven release 2.0.2 is installed and set the environment. Never used Maven before other than to do 'mvn --version'. What are the steps to see Cocoon running? I will write a quickstart Daisy doc. - install Maven as described in http://maven.apache.org/download.html#installation going through the tutorial in http://maven.apache.org/guides/getting-started/index.html is no mistake of course :-) - Make sure, that mvn --version works for you - checkout (update) ./cocoon/trunk - call mvn clean install -Dmaven.test.skip=true from there a) as long as you don't checkout again, you can always append -o so that Maven is executed without connection to the network) b) I'm used to call the clean goal first to be sure that everything gets rebuild Well that is what i have been doing. Will keep trying. Thanks, i will follow up with the doc. Would some people with knowledge please check it. Quickstart to Cocoon-2.2 with Maven http://cocoon.zones.apache.org/daisy/documentation/g2/798.html -David
a bug in file upload widget
Hey: I find a bug when I use the file upload widget in my forms. In the form, I use a repeater , in it, have a file upload widget and an repeater-action widget. When I choose a file from my disk(with the filename in Chinese), and then save this form(if this validation is fail) or add a new file upload widget in my repeater, then the file name is wrong(with a incorrect encode), and if the form is save succeed, the fiel name is alse incorrect. What is the matter? Regards; Andrew
[jira] Closed: (COCOON-1778) NPE calling QuartzJobScheduler.fireJob if the job is a CronJob
[ http://issues.apache.org/jira/browse/COCOON-1778?page=all ]
Eric Meyer closed COCOON-1778:
--
Resolution: Fixed
Thanks, Antonio. -- Eric
NPE calling QuartzJobScheduler.fireJob if the job is a CronJob
--
Key: COCOON-1778
URL: http://issues.apache.org/jira/browse/COCOON-1778
Project: Cocoon
Type: Bug
Components: Blocks: Cron
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: quartz-job-scheduler-npe-job.patch.txt,
quartz-job-scheduler-npe.patch.txt
calling scheduler.fireJob (for example from flow) results in an NPE if the
job is a CronJob. This is because the JobExecutionContext is created without
a Trigger in the TriggerFiredBundle. The constructor for JobExecutionContext
requires that there be a trigger in the firebundle when it calls:
this.jobDataMap.putAll(trigger.getJobDataMap());
on line 139.
Here is some sample flowscript that fires a CronJob.
var scheduler =
cocoon.getComponent(Packages.org.apache.cocoon.components.cron.JobScheduler.ROLE);
try {
scheduler.fireJob(someJob);
} finally {
cocoon.releaseComponent(scheduler);
}
Here is a patch (license granted to ASF):
Index:
C:/opt/eclipse-rc/eclipse/workspace/cocoon-svn/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java
===
---
C:/opt/eclipse-rc/eclipse/workspace/cocoon-svn/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java
(revision 376375)
+++
C:/opt/eclipse-rc/eclipse/workspace/cocoon-svn/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java
(working copy)
@@ -704,10 +704,12 @@
final JobDetail detail = createJobDetail(name, jobDataMap);
-TriggerFiredBundle trigger = new TriggerFiredBundle(detail,
null, null, false, null, null, null, null);
+final Trigger trigger = new SimpleTrigger(name,
DEFAULT_QUARTZ_JOB_GROUP);
+TriggerFiredBundle fireBundle = new
TriggerFiredBundle(detail, trigger, null, false, null, null, null, null);
+
final Job executor = createJobExecutor();
-final JobExecutionContext context = new
JobExecutionContext(this.scheduler, trigger, executor);
+final JobExecutionContext context = new
JobExecutionContext(this.scheduler, fireBundle, executor);
this.executor.execute(new Runnable() {
public void run() {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1786) BrowserUpdateTransformer can get into invalid state - must override recycle()
BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1786 URL: http://issues.apache.org/jira/browse/COCOON-1786 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1787) BrowserUpdateTransformer can get into invalid state - must override recycle()
BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1787 URL: http://issues.apache.org/jira/browse/COCOON-1787 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1788) BrowserUpdateTransformer can get into invalid state - must override recycle()
BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1788 URL: http://issues.apache.org/jira/browse/COCOON-1788 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.2-dev (Current SVN) Reporter: Eric Meyer Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1787) BrowserUpdateTransformer can get into invalid state - must override recycle()
[ http://issues.apache.org/jira/browse/COCOON-1787?page=all ] Eric Meyer closed COCOON-1787: -- Resolution: Duplicate had network hicup. BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1787 URL: http://issues.apache.org/jira/browse/COCOON-1787 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1788) BrowserUpdateTransformer can get into invalid state - must override recycle()
[ http://issues.apache.org/jira/browse/COCOON-1788?page=all ] Eric Meyer closed COCOON-1788: -- Resolution: Duplicate had network hicup. BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1788 URL: http://issues.apache.org/jira/browse/COCOON-1788 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.2-dev (Current SVN) Reporter: Eric Meyer Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1786) BrowserUpdateTransformer can get into invalid state - must override recycle()
[ http://issues.apache.org/jira/browse/COCOON-1786?page=all ] Antonio Gallardo reassigned COCOON-1786: Assign To: Antonio Gallardo BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1786 URL: http://issues.apache.org/jira/browse/COCOON-1786 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Assignee: Antonio Gallardo Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1785) I18nMessage - null parameter values causes NPE
[ http://issues.apache.org/jira/browse/COCOON-1785?page=comments#action_12368215 ] Antonio Gallardo commented on COCOON-1785: -- String.valueOf() replace null -- null [1] Is this the expected behavior? Is not better to log the error or to throw the exception? [1] http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#valueOf(java.lang.Object) I18nMessage - null parameter values causes NPE -- Key: COCOON-1785 URL: http://issues.apache.org/jira/browse/COCOON-1785 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Assignee: Antonio Gallardo Attachments: I18nMessageNPE.txt Putting a null in a parameter value causes an NPE when creating the SAX events java.lang.NullPointerException at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128) at org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85) at org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453) at org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498) at org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292) Note: this NPE then causes the Ajax transformer to go wonky for all users in all sessions. I'm still digging into that one. I am attaching a patch (license granted to ASF) that allows null parameter values (using String.valueOf(parameters[i]) so that nulls are turned into null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1786) BrowserUpdateTransformer can get into invalid state - must override recycle()
[ http://issues.apache.org/jira/browse/COCOON-1786?page=all ] Antonio Gallardo updated COCOON-1786: - Thanks for the patch! The patch was applied. Please cross check and close the bug. BrowserUpdateTransformer can get into invalid state - must override recycle() - Key: COCOON-1786 URL: http://issues.apache.org/jira/browse/COCOON-1786 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Eric Meyer Assignee: Antonio Gallardo Attachments: BrowserUpdateTransformer-recycle-patch.txt If a form throws an exception during transformation (see https://issues.apache.org/jira/browse/COCOON-1785) then the BrowserUpdateTransformer gets into an invalid state, and futher request by any user or session that happens to use the invalid transformer receive the entire form document inside of the bu:document tag. The client side ajax javascript is then unable to process the resulting update. The attached patch (license granted to ASF) overrides recycle() and fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1778) NPE calling QuartzJobScheduler.fireJob if the job is a CronJob
[ http://issues.apache.org/jira/browse/COCOON-1778?page=all ]
Antonio Gallardo updated COCOON-1778:
-
Fix Version: 2.1.9-dev (current SVN)
NPE calling QuartzJobScheduler.fireJob if the job is a CronJob
--
Key: COCOON-1778
URL: http://issues.apache.org/jira/browse/COCOON-1778
Project: Cocoon
Type: Bug
Components: Blocks: Cron
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Fix For: 2.1.9-dev (current SVN)
Attachments: quartz-job-scheduler-npe-job.patch.txt,
quartz-job-scheduler-npe.patch.txt
calling scheduler.fireJob (for example from flow) results in an NPE if the
job is a CronJob. This is because the JobExecutionContext is created without
a Trigger in the TriggerFiredBundle. The constructor for JobExecutionContext
requires that there be a trigger in the firebundle when it calls:
this.jobDataMap.putAll(trigger.getJobDataMap());
on line 139.
Here is some sample flowscript that fires a CronJob.
var scheduler =
cocoon.getComponent(Packages.org.apache.cocoon.components.cron.JobScheduler.ROLE);
try {
scheduler.fireJob(someJob);
} finally {
cocoon.releaseComponent(scheduler);
}
Here is a patch (license granted to ASF):
Index:
C:/opt/eclipse-rc/eclipse/workspace/cocoon-svn/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java
===
---
C:/opt/eclipse-rc/eclipse/workspace/cocoon-svn/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java
(revision 376375)
+++
C:/opt/eclipse-rc/eclipse/workspace/cocoon-svn/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java
(working copy)
@@ -704,10 +704,12 @@
final JobDetail detail = createJobDetail(name, jobDataMap);
-TriggerFiredBundle trigger = new TriggerFiredBundle(detail,
null, null, false, null, null, null, null);
+final Trigger trigger = new SimpleTrigger(name,
DEFAULT_QUARTZ_JOB_GROUP);
+TriggerFiredBundle fireBundle = new
TriggerFiredBundle(detail, trigger, null, false, null, null, null, null);
+
final Job executor = createJobExecutor();
-final JobExecutionContext context = new
JobExecutionContext(this.scheduler, trigger, executor);
+final JobExecutionContext context = new
JobExecutionContext(this.scheduler, fireBundle, executor);
this.executor.execute(new Runnable() {
public void run() {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1368) [PATCH] HTTPRequestTransformer
[ http://issues.apache.org/jira/browse/COCOON-1368?page=all ] David Crossley updated COCOON-1368: --- Bugzilla Id: (was: 32541) Other Info: [Patch available] Description: I have created a transformer that allows to do HTTP requests (POST and GET) based on the Jakarta Commons HTTP Client project. Authentication (Basic, Digest and NTLM) and Cookies (with Cookie request header and Set-Cookie response header) are also supported. was: I have created a transformer that allows to do HTTP requests (POST and GET) based on the Jakarta Commons HTTP Client project. Authentication (Basic, Digest and NTLM) and Cookies (with Cookie request header and Set-Cookie response header) are also supported. [PATCH] HTTPRequestTransformer -- Key: COCOON-1368 URL: http://issues.apache.org/jira/browse/COCOON-1368 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Eric Jacob Assignee: Cocoon Developers Team Priority: Minor Attachments: HTTPIncludeTransformer.java, HTTPRequestTransformer.java I have created a transformer that allows to do HTTP requests (POST and GET) based on the Jakarta Commons HTTP Client project. Authentication (Basic, Digest and NTLM) and Cookies (with Cookie request header and Set-Cookie response header) are also supported. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1372) [PATCH] SmbAuthAction
[ http://issues.apache.org/jira/browse/COCOON-1372?page=all ] David Crossley updated COCOON-1372: --- Bugzilla Id: (was: 32587) Other Info: [Patch available] Description: Authenticates arbitrary user credentials against an NT domain based on the a href=http://jcifs.samba.org/;The Java CIFS Client Library (jCIFS)/a project. was: Authenticates arbitrary user credentials against an NT domain based on the a href=http://jcifs.samba.org/;The Java CIFS Client Library (jCIFS)/a project. [PATCH] SmbAuthAction - Key: COCOON-1372 URL: http://issues.apache.org/jira/browse/COCOON-1372 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Eric Jacob Assignee: Cocoon Developers Team Priority: Minor Attachments: SmbAuthAction.java Authenticates arbitrary user credentials against an NT domain based on the a href=http://jcifs.samba.org/;The Java CIFS Client Library (jCIFS)/a project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1185) [PATCH] BerkeleyDBStore
[ http://issues.apache.org/jira/browse/COCOON-1185?page=all ] David Crossley updated COCOON-1185: --- Bugzilla Id: (was: 29562) Other Info: [Patch available] Description: I've seen the discussion about the Sleepycat license, and realize this can't be a part of the distribution, but thought someone might find it useful. It is a bit raw and needs some polishing. Portions of this have been shamelessly cut and pasted from JCSDefaultStore. I haven't been brave enough to use this in production, but on staging servers it has been working nicely. was: I've seen the discussion about the Sleepycat license, and realize this can't be a part of the distribution, but thought someone might find it useful. It is a bit raw and needs some polishing. Portions of this have been shamelessly cut and pasted from JCSDefaultStore. I haven't been brave enough to use this in production, but on staging servers it has been working nicely. [PATCH] BerkeleyDBStore --- Key: COCOON-1185 URL: http://issues.apache.org/jira/browse/COCOON-1185 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Charles Yates Assignee: Cocoon Developers Team Attachments: BerkeleyDBStore.java, BerkeleyDBStore.java I've seen the discussion about the Sleepycat license, and realize this can't be a part of the distribution, but thought someone might find it useful. It is a bit raw and needs some polishing. Portions of this have been shamelessly cut and pasted from JCSDefaultStore. I haven't been brave enough to use this in production, but on staging servers it has been working nicely. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1220) [PATCH] PaginatedRepeater widget for CForms
[ http://issues.apache.org/jira/browse/COCOON-1220?page=all ] David Crossley updated COCOON-1220: --- Bugzilla Id: (was: 30213) Other Info: [Patch available] Description: This patch adds a new widget to CForms which extends the existing Repeater widget with support for pagination. was: This patch adds a new widget to CForms which extends the existing Repeater widget with support for pagination. [PATCH] PaginatedRepeater widget for CForms --- Key: COCOON-1220 URL: http://issues.apache.org/jira/browse/COCOON-1220 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Vilya Harvey Assignee: Cocoon Developers Team Attachments: paginated-repeater-patch.zip This patch adds a new widget to CForms which extends the existing Repeater widget with support for pagination. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1345) [PATCH] Suggestion for a conversion block
[ http://issues.apache.org/jira/browse/COCOON-1345?page=all ] David Crossley updated COCOON-1345: --- Bugzilla Id: (was: 32223) Other Info: [Patch available] Description: This patch is an attempt at creating a conversion block similar to what Daniel Fagerström has discussed (http://www.mail-archive.com/dev@cocoon.apache.org/msg24163.html) The conversion block can live by itself but the patch also includes changes to CForm so that it can use the convertors from the conversion block. Currently there are only two convertors implemented (DefaultDateConvertor and CustomDateConvertor). To test it out apply both patches start your servlet and then surf to: http://localhost:/samples/blocks/forms/conversion/ was: This patch is an attempt at creating a conversion block similar to what Daniel Fagerström has discussed (http://www.mail-archive.com/dev@cocoon.apache.org/msg24163.html) The conversion block can live by itself but the patch also includes changes to CForm so that it can use the convertors from the conversion block. Currently there are only two convertors implemented (DefaultDateConvertor and CustomDateConvertor). To test it out apply both patches start your servlet and then surf to: http://localhost:/samples/blocks/forms/conversion/ [PATCH] Suggestion for a conversion block - Key: COCOON-1345 URL: http://issues.apache.org/jira/browse/COCOON-1345 Project: Cocoon Type: Improvement Components: Blocks: (Undefined) Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jonas Ekstedt Assignee: Cocoon Developers Team Priority: Minor Attachments: conversion-block.patch This patch is an attempt at creating a conversion block similar to what Daniel Fagerström has discussed (http://www.mail-archive.com/dev@cocoon.apache.org/msg24163.html) The conversion block can live by itself but the patch also includes changes to CForm so that it can use the convertors from the conversion block. Currently there are only two convertors implemented (DefaultDateConvertor and CustomDateConvertor). To test it out apply both patches start your servlet and then surf to: http://localhost:/samples/blocks/forms/conversion/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1337) [PATCH] Suggestion for widget population
[ http://issues.apache.org/jira/browse/COCOON-1337?page=all ] David Crossley updated COCOON-1337: --- Bugzilla Id: (was: 32169) Other Info: [Patch available] Description: This patch enables CForm to only populate the widgets that has been rendered. Currently it only works if you use the src/blocks/forms/java/org/apache/cocoon/forms/generation/jx-macros.xml macro to render your widgets. It should be fully back-compatible as it introduces an additional flag in the Form.showForm function that flags whether population should be done old-style (recursively through all widgets) or with the new method. To use it in flow do: form.showForm(uri, bizData, true); Where true indicates that selective population should be used. If you instead do: form.showForm(uri, bizData) The recursive behaviour will be used. was: This patch enables CForm to only populate the widgets that has been rendered. Currently it only works if you use the src/blocks/forms/java/org/apache/cocoon/forms/generation/jx-macros.xml macro to render your widgets. It should be fully back-compatible as it introduces an additional flag in the Form.showForm function that flags whether population should be done old-style (recursively through all widgets) or with the new method. To use it in flow do: form.showForm(uri, bizData, true); Where true indicates that selective population should be used. If you instead do: form.showForm(uri, bizData) The recursive behaviour will be used. [PATCH] Suggestion for widget population Key: COCOON-1337 URL: http://issues.apache.org/jira/browse/COCOON-1337 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jonas Ekstedt Assignee: Cocoon Developers Team Priority: Minor Attachments: widgetpopulator-samples.patch, widgetpopulator.patch, widgetpopulator2.patch This patch enables CForm to only populate the widgets that has been rendered. Currently it only works if you use the src/blocks/forms/java/org/apache/cocoon/forms/generation/jx-macros.xml macro to render your widgets. It should be fully back-compatible as it introduces an additional flag in the Form.showForm function that flags whether population should be done old-style (recursively through all widgets) or with the new method. To use it in flow do: form.showForm(uri, bizData, true); Where true indicates that selective population should be used. If you instead do: form.showForm(uri, bizData) The recursive behaviour will be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-649) [PATCH] Made SQLTransformer paginatable
[ http://issues.apache.org/jira/browse/COCOON-649?page=all ]
David Crossley updated COCOON-649:
--
Bugzilla Id: (was: 19138)
Other Info: [Patch available]
Description:
Hi,
Thanks to idea and code from Irv Salisbury III, I made some
changes to src/blocks/database/.../transformation/SQLTransformer
and made it Paginatorable.
With this patch, you can set page-size and current-page via
the sitemap and have paging done via result set controls rather
than filtering through a Paginator Transformer.
While that transformer works, in the case of a database query,
it just seemed a tad wasteful not to do the paging at a lower
level.
I have made some changes to the Paginator code as well to allow
calls from PagingSQLTransformer to spit out paging related tags.
This will ease any transition of switching from using the
paginator transformer to using this PagingSQLTransformer.
Before using PagingSQLTransformer,
map:match pattern={1}/view/Show[:punct:]*([0-9]*)[:punct:]* type=regexp
map:generate src=xsp/view/display-all.xsp/
map:transform type=sql
map:parameter name=use-connection value=photo/
map:parameter name=show-nr-of-rows value=true/
/map:transform
map:transform type=paginator src=pagesheets/display.xml/
map:transform src=stylesheets/view/display-all.xsl/
map:act type=request
map:transform src=stylesheets/page/simple-page2html.xsl
map:parameter name=app-context value={context}/
map:parameter name=requestURI value={requestURI}/
/map:transform
/map:act
map:transform src=stylesheets/page/simple-pagination.xsl/
map:serialize/
/map:match
Using PagingSQLTransformer,
map:match pattern={1}/view/Show[:punct:]*([0-9]*)[:punct:]* type=regexp
map:generate src=xsp/view/display-all.xsp/
map:transform type=sql
map:parameter name=use-connection value=photo/
map:parameter name=show-nr-of-rows value=true/
map:parameter name=page-size value=10/
map:parameter name=current-page value={1}/
map:parameter name=pagesheet-source value=pagesheets/display.xml/
/map:transform
map:transform src=stylesheets/view/display-all.xsl/
map:act type=request
map:transform src=stylesheets/page/simple-page2html.xsl
map:parameter name=app-context value={context}/
map:parameter name=requestURI value={requestURI}/
/map:transform
/map:act
map:transform src=stylesheets/page/simple-pagination.xsl/
map:serialize/
/map:match
I made some patch to the Paginator code that should fix bug
#13865.
Further changes to the Paginator code now allows, multiple
range-links too.
One of the inconsistency (maybe) from all these changes is that
I make it so that page-size is configured for the SQLTransformer
and the pagesheet/rules/count/num is ignored. I have not figure
out a way to use both easily. I will have to do some more thinking
on that. What is easier to understand? Comments?
This is my first time contributing in a patch sort of way to
any open source project, so excuse me if I get any procedure
wrong.
Boon
was:
Hi,
Thanks to idea and code from Irv Salisbury III, I made some
changes to src/blocks/database/.../transformation/SQLTransformer
and made it Paginatorable.
With this patch, you can set page-size and current-page via
the sitemap and have paging done via result set controls rather
than filtering through a Paginator Transformer.
While that transformer works, in the case of a database query,
it just seemed a tad wasteful not to do the paging at a lower
level.
I have made some changes to the Paginator code as well to allow
calls from PagingSQLTransformer to spit out paging related tags.
This will ease any transition of switching from using the
paginator transformer to using this PagingSQLTransformer.
Before using PagingSQLTransformer,
map:match pattern={1}/view/Show[:punct:]*([0-9]*)[:punct:]* type=regexp
map:generate src=xsp/view/display-all.xsp/
map:transform type=sql
map:parameter name=use-connection value=photo/
map:parameter name=show-nr-of-rows value=true/
/map:transform
map:transform type=paginator src=pagesheets/display.xml/
map:transform src=stylesheets/view/display-all.xsl/
map:act type=request
map:transform src=stylesheets/page/simple-page2html.xsl
map:parameter name=app-context value={context}/
map:parameter name=requestURI value={requestURI}/
/map:transform
/map:act
map:transform src=stylesheets/page/simple-pagination.xsl/
map:serialize/
/map:match
Using PagingSQLTransformer,
map:match pattern={1}/view/Show[:punct:]*([0-9]*)[:punct:]* type=regexp
map:generate src=xsp/view/display-all.xsp/
map:transform type=sql
map:parameter name=use-connection value=photo/
map:parameter name=show-nr-of-rows value=true/
map:parameter name=page-size value=10/
map:parameter name=current-page value={1}/
map:parameter
[jira] Updated: (COCOON-719) [PATCH] Support for transactions in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-719?page=all ]
David Crossley updated COCOON-719:
--
Bugzilla Id: (was: 20631)
Other Info: [Patch available]
Description:
I asked about transaction support in the SQLTransformer and got some good
suggestions about using some DB specific SQL. I might have gone that way (we use
Oracle 9i), but I wanted something more portable.
Daniel Fagerstrom posted about a patch he wrote that allowed the SQLTransformer
to share a connection among top level queries. Great, half way there! (Here's
the link for that patch...
http://issues.apache.org/bugzilla/show_bug.cgi?id=16718).
I added in code to support setting a parameter like this;
map:transform type=sql
map:parameter name=use-connection value=mbrdb/
map:parameter name=enable-transaction value=true/
/map:transform
I put the code in the SQLTransformer to turn off the auto-commit flag and to
issue the appropriate commit/rollback calls (on error). It works for a couple
inserts I threw together. If I put an error in the second insert, the first is
rolled back. If both are good, they both are commited. :-)
I'm attaching the revised SQLTransformer. I know you guys like to see patches,
so I attached that also. For now, this code has Daniel's patch applied (onto the
2.0.4 version) and my additions are bounded by comments (i.e. // DAK:
Transaction and // DAK)
Is this something that can be put into the scratchpad? We could give it a
different package so people could just choose it in the sitemap.xmap
Here is the context diff with the 2.0.4 SQLTransformer (I added comments
surrounding my new code to make it easy to spot
*** SQLTransformer.java Sun May 18 17:48:50 2003
--- SQLTransformer.java.origTue May 13 22:20:36 2003
***
*** 102,110
public static final String MAGIC_PASSWORD = password;
public static final String MAGIC_NR_OF_ROWS = show-nr-of-rows;
public static final String MAGIC_QUERY = query;
- // DAK: Transaction
- public static final String MAGIC_TRANSACTION = enable-transaction;
- // DAK
public static final String MAGIC_VALUE = value;
public static final String MAGIC_DOC_ELEMENT = doc-element;
public static final String MAGIC_ROW_ELEMENT = row-element;
--- 102,107
***
*** 186,194
protected XMLDeserializer interpreter;
protected Parser parser;
- /** The connection used by all top level queries */
- protected Connection conn;
-
/**
* Constructor
*/
--- 183,188
***
*** 220,237
*/
public void recycle() {
super.recycle();
- try {
- // Close the connection used by all top level queries
- if (this.conn != null) {
- // DAK: Transaction
- this.conn.commit();
- // DAK
- this.conn.close();
- this.conn = null;
- }
- } catch ( SQLException e ) {
- getLogger().warn( Could not close the connection, e );
- }
this.queries.clear();
this.outUri = null;
this.outPrefix = null;
--- 214,219
***
*** 292,300
getLogger().debug( ROW-ELEMENT: + parameters.getParameter(
SQLTransformer.MAGIC_ROW_ELEMENT, row ) );
getLogger().debug( NS-URI: + parameters.getParameter(
SQLTransformer.MAGIC_NS_URI_ELEMENT, NAMESPACE ) );
getLogger().debug( NS-PREFIX: + parameters.getParameter(
SQLTransformer.MAGIC_NS_PREFIX_ELEMENT, ) );
- // DAK: Transaction
- getLogger().debug( TRANSACTION: + parameters.getParameter(
SQLTransformer.MAGIC_TRANSACTION, ) );
- // DAK
}
}
--- 274,279
***
*** 317,335
AttributesImpl attr = new AttributesImpl();
Query query = (Query) queries.elementAt( index );
boolean query_failure = false;
- Connection conn = null;
try {
try {
- if (index == 0) {
- if (this.conn == null) // The first top
level execute-query
- this.conn =
query.getConnection();
- // reuse the global connection
for all top level queries
- conn = this.conn;
- }
- else // index 0, sub queries are always
executed in an own connection
- conn = query.getConnection();
-
- query.setConnection(conn);
[jira] Updated: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ http://issues.apache.org/jira/browse/COCOON-1622?page=all ] David Crossley updated COCOON-1622: --- Bugzilla Id: (was: 36949) Other Info: [Patch available] [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: http://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Type: Bug Components: Blocks: Mail Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assignee: Jean-Baptiste Quenot Fix For: 2.1.9-dev (current SVN) Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1603) [PATCH] handling of alternatives in MailTransformer
[ http://issues.apache.org/jira/browse/COCOON-1603?page=all ] David Crossley updated COCOON-1603: --- Bugzilla Id: (was: 36718) Other Info: [Patch available] [PATCH] handling of alternatives in MailTransformer --- Key: COCOON-1603 URL: http://issues.apache.org/jira/browse/COCOON-1603 Project: Cocoon Type: Improvement Components: Blocks: Mail Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Ãric BURGHARD Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: SendMailTransformer.java.patch Enable alternative format for the same content in MailTransformer. For example you can write email:sendmail email:body mime-type=text/plain Hello World /email:body email:body mime-type=text/html html body h1Hello World/h1 /body /html /email:body /email:sendmail to enable a multipart/alternative sending. internaly, a body is just an attachment without name and without xml header. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1519) [PATCH] TeeTransformer refactoring
[ http://issues.apache.org/jira/browse/COCOON-1519?page=all ] David Crossley updated COCOON-1519: --- Bugzilla Id: (was: 35094) Other Info: [Patch available] Description: - delegate to XMLTeePipe now - variable cleanup and recycle() fixes was: - delegate to XMLTeePipe now - variable cleanup and recycle() fixes [PATCH] TeeTransformer refactoring -- Key: COCOON-1519 URL: http://issues.apache.org/jira/browse/COCOON-1519 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team Attachments: refactored.diff - delegate to XMLTeePipe now - variable cleanup and recycle() fixes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1394) [PATCH] Implementation of PortletRequest#getQueryString()
[ http://issues.apache.org/jira/browse/COCOON-1394?page=all ] David Crossley updated COCOON-1394: --- Bugzilla Id: (was: 32984) Other Info: [Patch available] [PATCH] Implementation of PortletRequest#getQueryString() - Key: COCOON-1394 URL: http://issues.apache.org/jira/browse/COCOON-1394 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.6 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Assignee: Cocoon Developers Team Attachments: RELEASE_2_1_6.patch_12.diff Uncompleted method PortletRequest#getQueryString() implemented. New implementation is aggregating all portlet request parameters and creates query string the same way as in they were from http request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1302) [Patch] Word Document Generator
[ http://issues.apache.org/jira/browse/COCOON-1302?page=all ] David Crossley updated COCOON-1302: --- Bugzilla Id: (was: 31724) Other Info: [Patch available] [Patch] Word Document Generator --- Key: COCOON-1302 URL: http://issues.apache.org/jira/browse/COCOON-1302 Project: Cocoon Type: Improvement Components: Blocks: POI Versions: 2.1.5 Environment: Operating System: other Platform: Other Reporter: Nicolas Maisonneuve Assignee: Cocoon Developers Team Priority: Minor Attachments: WordGenerator.zip, poi-scratchpad.jar, poi-word-sample.patch, wordgenerator.patch hy , i developed a word generator with the POI scratchpad for Word document (HWSF). So for use it , you must include the poi-scratchpad.jar + my code. Nicolas Maisonneuve -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1294) [PATCH] JavaClassWidgetListenerBuilder add LifeCycle
[ http://issues.apache.org/jira/browse/COCOON-1294?page=all ] David Crossley updated COCOON-1294: --- Bugzilla Id: (was: 31640) Other Info: [Patch available] [PATCH] JavaClassWidgetListenerBuilder add LifeCycle Key: COCOON-1294 URL: http://issues.apache.org/jira/browse/COCOON-1294 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Juergen Seitz Assignee: Cocoon Developers Team Attachments: JavaClassWidgetListenerBuilder_LifeCyclePatch.txt enables the listener to have access to the logger, the manager and/or the context -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1254) [Patch] OWQLTransformer + RDQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1254?page=all ] David Crossley updated COCOON-1254: --- Bugzilla Id: (was: 30995) Other Info: [Patch available] [Patch] OWQLTransformer + RDQLTransformer - Key: COCOON-1254 URL: http://issues.apache.org/jira/browse/COCOON-1254 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Halgurt Assignee: Cocoon Developers Team Priority: Minor Attachments: OWQLTransformer.java, RDQLTransformer.java SemWeb -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1272) [PATCH] Forms without continuation
[ http://issues.apache.org/jira/browse/COCOON-1272?page=all ] David Crossley updated COCOON-1272: --- Bugzilla Id: (was: 31312) Other Info: [Patch available] Description: I couldn't find any solution for how to use fully CForms without continuation. Finally I found myself some solution: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=109041564820149w=2 but it requires java actions and have many drawbacks. For me is obvious that there must be a nice way to use CForms without continuation (mainly for internet applications). Till now I couldn't find any good solution. was: I couldn't find any solution for how to use fully CForms without continuation. Finally I found myself some solution: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=109041564820149w=2 but it requires java actions and have many drawbacks. For me is obvious that there must be a nice way to use CForms without continuation (mainly for internet applications). Till now I couldn't find any good solution. [PATCH] Forms without continuation -- Key: COCOON-1272 URL: http://issues.apache.org/jira/browse/COCOON-1272 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Tomasz Bech Assignee: Cocoon Developers Team Priority: Minor Attachments: cforms-without-continuations-cocoon2_1.patch, cforms-without-continuations-cocoon2_trunk.patch, registration-nc_template.xml, registration_nc.js I couldn't find any solution for how to use fully CForms without continuation. Finally I found myself some solution: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=109041564820149w=2 but it requires java actions and have many drawbacks. For me is obvious that there must be a nice way to use CForms without continuation (mainly for internet applications). Till now I couldn't find any good solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1206) [PATCH] Cleanup transformer
[ http://issues.apache.org/jira/browse/COCOON-1206?page=all ] David Crossley updated COCOON-1206: --- Bugzilla Id: (was: 30018) Other Info: [Patch available] Description: Cleanup transformer: removes excess whitespace while adding some where needed for legibility. Also strips unwanted namespace prefix mappings. The following attachment, if accepted, is donated to the Apache Software Foundation to license and use as they see fit. was: Cleanup transformer: removes excess whitespace while adding some where needed for legibility. Also strips unwanted namespace prefix mappings. The following attachment, if accepted, is donated to the Apache Software Foundation to license and use as they see fit. [PATCH] Cleanup transformer --- Key: COCOON-1206 URL: http://issues.apache.org/jira/browse/COCOON-1206 Project: Cocoon Type: Improvement Components: Blocks: (Undefined) Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Miles Elam Assignee: Cocoon Developers Team Priority: Minor Attachments: CleanupTransformer.java Cleanup transformer: removes excess whitespace while adding some where needed for legibility. Also strips unwanted namespace prefix mappings. The following attachment, if accepted, is donated to the Apache Software Foundation to license and use as they see fit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Building trunk - Maven is your friend
Daniel Fagerstrom wrote:
OTH we badly need to get some limited samples working for trunk ASAP. So
that the community can get its faith in trunk back. And so that the
threshold for getting involved in trunk development and testing becomes
lower.
Yes, right. Please guys, give me time till Sunday to come up with something
useful. If I don't get it working (for whatever reason) we can go the way
Carsten proposed _for now_.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Updated: (COCOON-1203) [PATCH] inserver junit testing
[ http://issues.apache.org/jira/browse/COCOON-1203?page=all ] David Crossley updated COCOON-1203: --- Bugzilla Id: (was: 29970) Other Info: [Patch available] Description: This piece of code allows junit test in a normal server environment. mockup objects for building up an test environment not needed anymore. Automated testing of Cocoon components in a special servlet container like Weblogic should be easier now. Reporting is as for 'normal' JUnit tests. There is a CocoonTestCase extending TestCase having the objectmodel and servicemanager as member variables. This is the base class for testcases running on serverside. And there is a TestCaseReader to be included in the sitemap. Its for activating the testcases and sending back the results. See the README in the uploaded tgz. was: This piece of code allows junit test in a normal server environment. mockup objects for building up an test environment not needed anymore. Automated testing of Cocoon components in a special servlet container like Weblogic should be easier now. Reporting is as for 'normal' JUnit tests. There is a CocoonTestCase extending TestCase having the objectmodel and servicemanager as member variables. This is the base class for testcases running on serverside. And there is a TestCaseReader to be included in the sitemap. Its for activating the testcases and sending back the results. See the README in the uploaded tgz. [PATCH] inserver junit testing -- Key: COCOON-1203 URL: http://issues.apache.org/jira/browse/COCOON-1203 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Claas Thiele Assignee: Cocoon Developers Team Attachments: inserver-junit.tgz This piece of code allows junit test in a normal server environment. mockup objects for building up an test environment not needed anymore. Automated testing of Cocoon components in a special servlet container like Weblogic should be easier now. Reporting is as for 'normal' JUnit tests. There is a CocoonTestCase extending TestCase having the objectmodel and servicemanager as member variables. This is the base class for testcases running on serverside. And there is a TestCaseReader to be included in the sitemap. Its for activating the testcases and sending back the results. See the README in the uploaded tgz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1147) [PATCH] namespace issues with XMLDBTransformer
[ http://issues.apache.org/jira/browse/COCOON-1147?page=all ] David Crossley updated COCOON-1147: --- Bugzilla Id: (was: 28723) Other Info: [Patch available] [PATCH] namespace issues with XMLDBTransformer -- Key: COCOON-1147 URL: http://issues.apache.org/jira/browse/COCOON-1147 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Assignee: Cocoon Developers Team Attachments: browser output.txt, qeury result.txt, qeury result.txt, serializer.patch, sitemap.xmap Just clearing some of my mails. Some issues were reported according to namespaces with xmldb components: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107908325225663w=4 http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=108246750812702w=4 http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=108251828604092w=4 http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=108305770827148w=4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1125) [PATCH] Updated CastorTransformer + samples
[ http://issues.apache.org/jira/browse/COCOON-1125?page=all ] David Crossley updated COCOON-1125: --- Bugzilla Id: (was: 28334) Other Info: [Patch available] Description: submitted by Erwin van de Noort: http://marc.theaimsgroup.com/?t=10809810112r=1w=4n=3 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108161886623879w=4 was: submitted by Erwin van de Noort: http://marc.theaimsgroup.com/?t=10809810112r=1w=4n=3 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108161886623879w=4 [PATCH] Updated CastorTransformer + samples --- Key: COCOON-1125 URL: http://issues.apache.org/jira/browse/COCOON-1125 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.4 Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Assignee: Cocoon Developers Team Attachments: castor.patch, patch.txt submitted by Erwin van de Noort: http://marc.theaimsgroup.com/?t=10809810112r=1w=4n=3 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108161886623879w=4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1618) [PATCH] SoapGenerator/Serializer for Axis Block
[ http://issues.apache.org/jira/browse/COCOON-1618?page=all ] David Crossley updated COCOON-1618: --- Bugzilla Id: (was: 36868) Other Info: [Patch available] [PATCH] SoapGenerator/Serializer for Axis Block --- Key: COCOON-1618 URL: http://issues.apache.org/jira/browse/COCOON-1618 Project: Cocoon Type: Bug Components: Blocks: AXIS Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Stephan Zuercher Assignee: Cocoon Developers Team Attachments: soap-processing.tar.gz Patch provides a SoapGenerator and SoapSerializer with samples for the Axis block. The generator/serializer allow developers to process SOAP document-style requests with pipelines and describe a mechanism for generating SOAP faults when necessary. Could eventually be extended to handle RPC-style requests and SOAP headers, but currently does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-910) [PATCH] sitemap parameters support for SVGSerializer
[ http://issues.apache.org/jira/browse/COCOON-910?page=all ] David Crossley updated COCOON-910: -- Bugzilla Id: (was: 25100) Other Info: [Patch available] [PATCH] sitemap parameters support for SVGSerializer Key: COCOON-910 URL: http://issues.apache.org/jira/browse/COCOON-910 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Charles Borges Assignee: Cocoon Developers Team Attachments: SVGSerializer-patch.zip This patch aims to add support for sitemap parameters allowing a user to override the default configuration of the serializer with sitemap parameters. The main changes come with the implementation of the SitemapModelComponent interface and the use of a new inner class to keep information about the batik trancoding hints. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1418) [PATCH] CForm definitions using JXTemplate
[ http://issues.apache.org/jira/browse/COCOON-1418?page=all ]
David Crossley updated COCOON-1418:
---
Bugzilla Id: (was: 33237)
Other Info: [Patch available]
Description:
This is a patch that I needed to implement for a project I'm working on and that
someone else may find useful. I have CForm definitions being created with a
JXTemplate instead of a static XML file and needed to be able to pass some
objects through to the JXTemplate. This patch allows me to create forms like:
var form = new Form(cocoon:/form1.jx, {bean : bean});
form.createBinding(cocoon:/form1Bind.jx, null, {bean : bean});
and then from within the JXTemplate I can use the objects like ${bean.foo}
There's probably a better way to do the changes I made in Form.js, but this is
what I'm using in my project at the moment so hopefully someone will find it
useful.
was:
This is a patch that I needed to implement for a project I'm working on and that
someone else may find useful. I have CForm definitions being created with a
JXTemplate instead of a static XML file and needed to be able to pass some
objects through to the JXTemplate. This patch allows me to create forms like:
var form = new Form(cocoon:/form1.jx, {bean : bean});
form.createBinding(cocoon:/form1Bind.jx, null, {bean : bean});
and then from within the JXTemplate I can use the objects like ${bean.foo}
There's probably a better way to do the changes I made in Form.js, but this is
what I'm using in my project at the moment so hopefully someone will find it
useful.
[PATCH] CForm definitions using JXTemplate
--
Key: COCOON-1418
URL: http://issues.apache.org/jira/browse/COCOON-1418
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Versions: 2.1.8
Environment: Operating System: All
Platform: PC
Reporter: Adam Walsh
Assignee: Jean-Baptiste Quenot
Priority: Minor
Attachments: Form.js.diff, FormUtil.java, JXTemplateGenerator.java.diff
This is a patch that I needed to implement for a project I'm working on and
that
someone else may find useful. I have CForm definitions being created with a
JXTemplate instead of a static XML file and needed to be able to pass some
objects through to the JXTemplate. This patch allows me to create forms like:
var form = new Form(cocoon:/form1.jx, {bean : bean});
form.createBinding(cocoon:/form1Bind.jx, null, {bean : bean});
and then from within the JXTemplate I can use the objects like ${bean.foo}
There's probably a better way to do the changes I made in Form.js, but this is
what I'm using in my project at the moment so hopefully someone will find it
useful.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1515) [PATCH] Add remoteUser() information to RequestGenerator
[ http://issues.apache.org/jira/browse/COCOON-1515?page=all ] David Crossley updated COCOON-1515: --- Bugzilla Id: (was: 35051) Other Info: [Patch available] Description: Something I've occasionally found useful in the request generator when using the standard J2EE container security was to add the currently logged in user's ID (from request.remoteUser()). It doesn't necessarily get sent with every request, depending on the container and whether or not the request is for a protected page, but it's usually set on requests for secured HTML pages. I'm attaching the (fairly trivial) patch I used to add this, taken against the current SVN trunk. was: Something I've occasionally found useful in the request generator when using the standard J2EE container security was to add the currently logged in user's ID (from request.remoteUser()). It doesn't necessarily get sent with every request, depending on the container and whether or not the request is for a protected page, but it's usually set on requests for secured HTML pages. I'm attaching the (fairly trivial) patch I used to add this, taken against the current SVN trunk. [PATCH] Add remoteUser() information to RequestGenerator Key: COCOON-1515 URL: http://issues.apache.org/jira/browse/COCOON-1515 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Andrew Stevens Assignee: Cocoon Developers Team Priority: Minor Attachments: 35051.diff Something I've occasionally found useful in the request generator when using the standard J2EE container security was to add the currently logged in user's ID (from request.remoteUser()). It doesn't necessarily get sent with every request, depending on the container and whether or not the request is for a protected page, but it's usually set on requests for secured HTML pages. I'm attaching the (fairly trivial) patch I used to add this, taken against the current SVN trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-996) [PATCH] LuceneIndexContentHandler.java produces CLOBs
[ http://issues.apache.org/jira/browse/COCOON-996?page=all ] David Crossley updated COCOON-996: -- Bugzilla Id: (was: 25934) Other Info: [Patch available] Description: cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/components/search/LuceneIndexContentHandler.java produces something like a Character Large Object, because the text from all XML-elements is concatenated without whitespaces between them: listitemFoo/itemitemBar/item/list gets indexed as FooBar, which makes searching very hard. Adding a blank after an element might solve this problem, but might be wrong for other cases (but I don't know any at the moment) was: cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/components/search/LuceneIndexContentHandler.java produces something like a Character Large Object, because the text from all XML-elements is concatenated without whitespaces between them: listitemFoo/itemitemBar/item/list gets indexed as FooBar, which makes searching very hard. Adding a blank after an element might solve this problem, but might be wrong for other cases (but I don't know any at the moment) [PATCH] LuceneIndexContentHandler.java produces CLOBs - Key: COCOON-996 URL: http://issues.apache.org/jira/browse/COCOON-996 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.1.8 Environment: Operating System: Linux Platform: PC Reporter: Philipp Matthias Hahn Assignee: Cocoon Developers Team Priority: Minor Attachments: LICH.shouldwork.patch.txt, LICH.vadimjoerg.patch.txt, LuceneIndexContentHandler.java.diff cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/components/search/LuceneIndexContentHandler.java produces something like a Character Large Object, because the text from all XML-elements is concatenated without whitespaces between them: listitemFoo/itemitemBar/item/list gets indexed as FooBar, which makes searching very hard. Adding a blank after an element might solve this problem, but might be wrong for other cases (but I don't know any at the moment) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1332) [PATCH] content-length and content-type for portlet ActionRequest
[ http://issues.apache.org/jira/browse/COCOON-1332?page=all ] David Crossley updated COCOON-1332: --- Bugzilla Id: (was: 32159) Other Info: [Patch available] [PATCH] content-length and content-type for portlet ActionRequest - Key: COCOON-1332 URL: http://issues.apache.org/jira/browse/COCOON-1332 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Assignee: Cocoon Developers Team Attachments: RELEASE_2_1_6.patch_5.diff, release_2_1_5_1.patch_5.txt Request content length and content type are required in portlet ActionRequest for custom upload handling. Currently, methods Request.getContentLength() and Request.getContentType() are inherited from PortletRequest that returns '-1' and 'null' respectivelly. Thats correct only for render request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1489) [PATCH] XInclude transformer does not handle fallback correctly
[ http://issues.apache.org/jira/browse/COCOON-1489?page=all ] David Crossley updated COCOON-1489: --- Bugzilla Id: (was: 34325) Other Info: [Patch available] Description: When using the xi:fallback element, the XInclude transformer returns a not-well-formed document. Example: root xmlns:xi=http://www.w3.org/2001/XInclude; xi:include href=this_file_does_not_exist.xml xi:fallback elementThis should be here if the file was not found/element /xi:fallback /xi:include /root returns this, if the included resource does not exist: ?xml version=1.0 encoding=ISO-8859-1?root xmlns:xi=http://www.w3.org/2001/XInclude; elementThis should be here if the file was not found /xi:include /root was: When using the xi:fallback element, the XInclude transformer returns a not-well-formed document. Example: root xmlns:xi=http://www.w3.org/2001/XInclude; xi:include href=this_file_does_not_exist.xml xi:fallback elementThis should be here if the file was not found/element /xi:fallback /xi:include /root returns this, if the included resource does not exist: ?xml version=1.0 encoding=ISO-8859-1?root xmlns:xi=http://www.w3.org/2001/XInclude; elementThis should be here if the file was not found /xi:include /root [PATCH] XInclude transformer does not handle fallback correctly --- Key: COCOON-1489 URL: http://issues.apache.org/jira/browse/COCOON-1489 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Joachim Breitsprecher Attachments: cocoon-xinclude-transformer-patch.txt When using the xi:fallback element, the XInclude transformer returns a not-well-formed document. Example: root xmlns:xi=http://www.w3.org/2001/XInclude; xi:include href=this_file_does_not_exist.xml xi:fallback elementThis should be here if the file was not found/element /xi:fallback /xi:include /root returns this, if the included resource does not exist: ?xml version=1.0 encoding=ISO-8859-1?root xmlns:xi=http://www.w3.org/2001/XInclude; elementThis should be here if the file was not found /xi:include /root -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1587) [PATCH] Simple i18n support for selectionLists
[ http://issues.apache.org/jira/browse/COCOON-1587?page=all ] David Crossley updated COCOON-1587: --- Bugzilla Id: (was: 36436) Other Info: [Patch available] Description: Inserts an i18n:text tag, if the i18nSupport in the selectionList is set to true. The i18nSupport could be set by adding the attribute i18n-support=true to the selection-list tag in the forms definition file. ( Example: fd:selection-list i18n-support=true src=resources/selection-lists/tourart.xml/ ) In program code, you can add i18nSupport by using the SelectionList-Constructors with the additional boolean value for the i18n-support or the method setI18nSupport(true). If the i18nSupport ist set, the generation of SAX will insert an i18n.text-tag before the text of the label. The next step is using the i18n-Transformer. was: Inserts an i18n:text tag, if the i18nSupport in the selectionList is set to true. The i18nSupport could be set by adding the attribute i18n-support=true to the selection-list tag in the forms definition file. ( Example: fd:selection-list i18n-support=true src=resources/selection-lists/tourart.xml/ ) In program code, you can add i18nSupport by using the SelectionList-Constructors with the additional boolean value for the i18n-support or the method setI18nSupport(true). If the i18nSupport ist set, the generation of SAX will insert an i18n.text-tag before the text of the label. The next step is using the i18n-Transformer. [PATCH] Simple i18n support for selectionLists -- Key: COCOON-1587 URL: http://issues.apache.org/jira/browse/COCOON-1587 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Rolf Metternich Assignee: Cocoon Developers Team Attachments: patch.txt Inserts an i18n:text tag, if the i18nSupport in the selectionList is set to true. The i18nSupport could be set by adding the attribute i18n-support=true to the selection-list tag in the forms definition file. ( Example: fd:selection-list i18n-support=true src=resources/selection-lists/tourart.xml/ ) In program code, you can add i18nSupport by using the SelectionList-Constructors with the additional boolean value for the i18n-support or the method setI18nSupport(true). If the i18nSupport ist set, the generation of SAX will insert an i18n.text-tag before the text of the label. The next step is using the i18n-Transformer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1360) [patch] client side validation for CForms
[ http://issues.apache.org/jira/browse/COCOON-1360?page=all ] David Crossley updated COCOON-1360: --- Bugzilla Id: (was: 32419) Other Info: [Patch available] Description: This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field was: This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field [patch] client side validation for CForms - Key: COCOON-1360 URL: http://issues.apache.org/jira/browse/COCOON-1360 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Luca Garulli Assignee: Cocoon Developers Team Priority: Minor Attachments: clientside-validation.js, clientside-validation.js, clientside-validation.js, clientside-validation.xsl, clientside-validation.xsl, clientside-validation.xsl, date.js, readme.txt This enhancement allow client-side validation for CForms. Archive content: clientside-validation.js.: JS functions for validation clientside-validation.xsl: transformer to enhance the XML generated by CForm date.js..: Matt Kruse libraries ro check numbers and dateformats readme.txt...: description on usage To develop: - i18n - field mode with the management of onBlur event for each field -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1335) [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer
[ http://issues.apache.org/jira/browse/COCOON-1335?page=all ] David Crossley updated COCOON-1335: --- Bugzilla Id: (was: 32164) Other Info: [Patch available] Description: Inheritance from class FilterTransformer removed, required (useless) parameters for FilterTransformer are not needed anymore. was: Inheritance from class FilterTransformer removed, required (useless) parameters for FilterTransformer are not needed anymore. [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer -- Key: COCOON-1335 URL: http://issues.apache.org/jira/browse/COCOON-1335 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Assignee: Cocoon Developers Team Attachments: release_2_1_5_1.patch_11.txt, release_2_1_6.patch_9.diff, release_2_1_7.patch.diff Inheritance from class FilterTransformer removed, required (useless) parameters for FilterTransformer are not needed anymore. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1557) [PATCH] Change access to AbstractContinuable.getContext to protected
[ http://issues.apache.org/jira/browse/COCOON-1557?page=all ] David Crossley updated COCOON-1557: --- Bugzilla Id: (was: 35672) Other Info: [Patch available] [PATCH] Change access to AbstractContinuable.getContext to protected Key: COCOON-1557 URL: http://issues.apache.org/jira/browse/COCOON-1557 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jochen Kuhnle Assignee: Cocoon Developers Team Attachments: patch-continuablecontext.txt The attached patch changes the access of AbstractContinuable.getContext from private to protected so subclasses can access the context. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1556) [PATCH] Add a JXPathConvertor for conversion betwean beans and Strings
[ http://issues.apache.org/jira/browse/COCOON-1556?page=all ] David Crossley updated COCOON-1556: --- Bugzilla Id: (was: 35671) Summary: [PATCH] Add a JXPathConvertor for conversion betwean beans and Strings (was: [PATCH] Add a JXPatchConvertor for conversion betwean beans and Strings) Other Info: [Patch available] Description: The attached patch new files introduces a JXPathConvertor that allows conversion between Objects (form datatype bean) and Strings using JXPath expressions. The convertor allows access to the object model (request, session, context, continuation flowContext) through variables. was: The attached patch new files introduces a JXPathConvertor that allows conversion between Objects (form datatype bean) and Strings using JXPath expressions. The convertor allows access to the object model (request, session, context, continuation flowContext) through variables. [PATCH] Add a JXPathConvertor for conversion betwean beans and Strings -- Key: COCOON-1556 URL: http://issues.apache.org/jira/browse/COCOON-1556 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jochen Kuhnle Assignee: Cocoon Developers Team Priority: Minor Attachments: JXPathConvertor.java, JXPathConvertorBuilder.java, patch-jxpathconvertor.txt The attached patch new files introduces a JXPathConvertor that allows conversion between Objects (form datatype bean) and Strings using JXPath expressions. The convertor allows access to the object model (request, session, context, continuation flowContext) through variables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1506) [PATCH] Manually specifying a mounted sitemap's context
[ http://issues.apache.org/jira/browse/COCOON-1506?page=all ] David Crossley updated COCOON-1506: --- Bugzilla Id: (was: 34781) Other Info: [Patch available] Description: In http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111330062713083w=2 we discussed having a 'context' attribute for map:mount, so you can specify a context against which all relative URLs are resolved. Here is the patch. was: In http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111330062713083w=2 we discussed having a 'context' attribute for map:mount, so you can specify a context against which all relative URLs are resolved. Here is the patch. [PATCH] Manually specifying a mounted sitemap's context --- Key: COCOON-1506 URL: http://issues.apache.org/jira/browse/COCOON-1506 Project: Cocoon Type: Improvement Components: - Components: Sitemap Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Jochen Kuhnle Assignee: Cocoon Developers Team Priority: Minor Attachments: patch.txt In http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111330062713083w=2 we discussed having a 'context' attribute for map:mount, so you can specify a context against which all relative URLs are resolved. Here is the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1325) [PATCH] commons-fileupload based multipart parser
[ http://issues.apache.org/jira/browse/COCOON-1325?page=all ] David Crossley updated COCOON-1325: --- Bugzilla Id: (was: 32102) Other Info: [Patch available] Description: As discussed in [1], this patch replaces the current multipartparser with one based on commons-fileupload. Note that this patch does not take prisoners and breaks the current way of retrieving uploads. The abstract Part class, PartInMemory and PartOnDisk are not necessary anymore because commons-fileupload transparently keeps the files in memory or on disk based on a size threshold. The user just requests a byte[] or inputstream from the file without actually knowing how/where the file is stored. The attached action is an example of how to use it. Sorry for the formatting (is there a common cocoon eclipse formatting profile ?) was: As discussed in [1], this patch replaces the current multipartparser with one based on commons-fileupload. Note that this patch does not take prisoners and breaks the current way of retrieving uploads. The abstract Part class, PartInMemory and PartOnDisk are not necessary anymore because commons-fileupload transparently keeps the files in memory or on disk based on a size threshold. The user just requests a byte[] or inputstream from the file without actually knowing how/where the file is stored. The attached action is an example of how to use it. Sorry for the formatting (is there a common cocoon eclipse formatting profile ?) [PATCH] commons-fileupload based multipart parser - Key: COCOON-1325 URL: http://issues.apache.org/jira/browse/COCOON-1325 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team Attachments: fileupload-using-commons.zip As discussed in [1], this patch replaces the current multipartparser with one based on commons-fileupload. Note that this patch does not take prisoners and breaks the current way of retrieving uploads. The abstract Part class, PartInMemory and PartOnDisk are not necessary anymore because commons-fileupload transparently keeps the files in memory or on disk based on a size threshold. The user just requests a byte[] or inputstream from the file without actually knowing how/where the file is stored. The attached action is an example of how to use it. Sorry for the formatting (is there a common cocoon eclipse formatting profile ?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-988) [PATCH] StreamGenerator can't handle multipart request parameters correctly
[ http://issues.apache.org/jira/browse/COCOON-988?page=all ]
David Crossley updated COCOON-988:
--
Bugzilla Id: (was: 25594)
Other Info: [Patch available]
Description:
In the StreamGenerator class in line 140
String sXml = request.getParameter(parameter);
inputSource = new InputSource(new StringReader(sXml));
it is wrongly assumed that in case of multipart requests the xml data can
be retrieved via the normal request.getParameter() Method. In fact this code
results in a sXml String containing something
like [EMAIL PROTECTED] which is not the
xml content and therefore cannot be parsed.
Instead it should read like:
Object xmlObject = request.get(parameter);
Reader xmlReader = null;
if (xmlObject instanceof String){
xmlReader = new StringReader((String) xmlObject);
}
else if (xmlObject instanceof Part){
xmlReader = new InputStreamReader(((Part) xmlObject).getInputStream());
}
else{
throw new ProcessingException(Unknown request object encountred named +
parameter + : + xmlObject);
}
inputSource = new InputSource(xmlReader);
thx,
Gernot
was:
In the StreamGenerator class in line 140
String sXml = request.getParameter(parameter);
inputSource = new InputSource(new StringReader(sXml));
it is wrongly assumed that in case of multipart requests the xml data can
be retrieved via the normal request.getParameter() Method. In fact this code
results in a sXml String containing something
like [EMAIL PROTECTED] which is not the
xml content and therefore cannot be parsed.
Instead it should read like:
Object xmlObject = request.get(parameter);
Reader xmlReader = null;
if (xmlObject instanceof String){
xmlReader = new StringReader((String) xmlObject);
}
else if (xmlObject instanceof Part){
xmlReader = new InputStreamReader(((Part) xmlObject).getInputStream());
}
else{
throw new ProcessingException(Unknown request object encountred named +
parameter + : + xmlObject);
}
inputSource = new InputSource(xmlReader);
thx,
Gernot
[PATCH] StreamGenerator can't handle multipart request parameters correctly
---
Key: COCOON-988
URL: http://issues.apache.org/jira/browse/COCOON-988
Project: Cocoon
Type: Bug
Components: - Components: Sitemap
Versions: 2.2-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: Gernot Koller
Assignee: Cocoon Developers Team
In the StreamGenerator class in line 140
String sXml = request.getParameter(parameter);
inputSource = new InputSource(new StringReader(sXml));
it is wrongly assumed that in case of multipart requests the xml data can
be retrieved via the normal request.getParameter() Method. In fact this code
results in a sXml String containing something
like [EMAIL PROTECTED] which is not the
xml content and therefore cannot be parsed.
Instead it should read like:
Object xmlObject = request.get(parameter);
Reader xmlReader = null;
if (xmlObject instanceof String){
xmlReader = new StringReader((String) xmlObject);
}
else if (xmlObject instanceof Part){
xmlReader = new InputStreamReader(((Part) xmlObject).getInputStream());
}
else{
throw new ProcessingException(Unknown request object encountred named +
parameter + : + xmlObject);
}
inputSource = new InputSource(xmlReader);
thx,
Gernot
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1526) [PATCH] processToDOM returns a read-only DOM
[ http://issues.apache.org/jira/browse/COCOON-1526?page=all ] David Crossley updated COCOON-1526: --- Bugzilla Id: (was: 35273) Other Info: [Patch available] [PATCH] processToDOM returns a read-only DOM Key: COCOON-1526 URL: http://issues.apache.org/jira/browse/COCOON-1526 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Jeffrey Kirby Assignee: Cocoon Developers Team Attachments: PipelineUtil.java.diff, SourceUtil.java.diff, utils.patch When Saxon is the active XSLT processor, using the zero-argument constructor to DOMResult results in a read-only DOM being produced. This, in turn, means that a call to PipelineUtil.processToDOM() always returns a read-only DOM. The attached patch adds overloaded versions of PipelineUtil.processToDOM() and SourceUtil.toDOM() to allow the user to pass in an explicit Node object to be passed to DOMResult (via DOMBuilder). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1354) [Patch] status-code on serializer not expanding variables
[ http://issues.apache.org/jira/browse/COCOON-1354?page=all ]
David Crossley updated COCOON-1354:
---
Bugzilla Id: (was: 32336)
Other Info: [Patch available]
Description:
map:serialize type=html status-code={sc}/
does not return the resolved variable sc as HTTP status code but simply returns
200 OK as HTTP code. Some applications may want to store the status code in a
variable and pass this varibale to the serialzer, expecting it to expand it
(Cocoon-Lenya is an example).
Suggested enhancement patch to expand variables on the serializer is attached.
was:
map:serialize type=html status-code={sc}/
does not return the resolved variable sc as HTTP status code but simply returns
200 OK as HTTP code. Some applications may want to store the status code in a
variable and pass this varibale to the serialzer, expecting it to expand it
(Cocoon-Lenya is an example).
Suggested enhancement patch to expand variables on the serializer is attached.
[Patch] status-code on serializer not expanding variables
-
Key: COCOON-1354
URL: http://issues.apache.org/jira/browse/COCOON-1354
Project: Cocoon
Type: Improvement
Components: - Components: Sitemap
Versions: 2.1.8
Environment: Operating System: All
Platform: All
Reporter: Jochen Seifarth
Assignee: Cocoon Developers Team
Priority: Minor
Attachments: status-code.diff
map:serialize type=html status-code={sc}/
does not return the resolved variable sc as HTTP status code but simply
returns
200 OK as HTTP code. Some applications may want to store the status code in a
variable and pass this varibale to the serialzer, expecting it to expand it
(Cocoon-Lenya is an example).
Suggested enhancement patch to expand variables on the serializer is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1260) [PATCH] MultipartParser can now handle multipart/mixed
[ http://issues.apache.org/jira/browse/COCOON-1260?page=all ] David Crossley updated COCOON-1260: --- Bugzilla Id: (was: 31067) Other Info: [Patch available] Description: org.apache.cocoon.servlet.multipart.MultipartParser did not handle multipart/mixed attachments for multi-part/form-data HTTP POSTs. This patch adds the capability to handle multipart/mixed. Browsers don't tend to send multipart/mixed, but curl (http://curl.haxx.se) does. To test the support: the following will send one INPUT name=pictureFiles type=file... element with two files attached: % curl -b @cookie.jar -c cookie.jar -F [EMAIL PROTECTED],pic2.png http://localhost:8080/cocoon/upload-test was: org.apache.cocoon.servlet.multipart.MultipartParser did not handle multipart/mixed attachments for multi-part/form-data HTTP POSTs. This patch adds the capability to handle multipart/mixed. Browsers don't tend to send multipart/mixed, but curl (http://curl.haxx.se) does. To test the support: the following will send one INPUT name=pictureFiles type=file... element with two files attached: % curl -b @cookie.jar -c cookie.jar -F [EMAIL PROTECTED],pic2.png http://localhost:8080/cocoon/upload-test [PATCH] MultipartParser can now handle multipart/mixed -- Key: COCOON-1260 URL: http://issues.apache.org/jira/browse/COCOON-1260 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: other Platform: Other Reporter: lpb+apache Assignee: Cocoon Developers Team Attachments: multipart.patch org.apache.cocoon.servlet.multipart.MultipartParser did not handle multipart/mixed attachments for multi-part/form-data HTTP POSTs. This patch adds the capability to handle multipart/mixed. Browsers don't tend to send multipart/mixed, but curl (http://curl.haxx.se) does. To test the support: the following will send one INPUT name=pictureFiles type=file... element with two files attached: % curl -b @cookie.jar -c cookie.jar -F [EMAIL PROTECTED],pic2.png http://localhost:8080/cocoon/upload-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1266) [PATCH] Resource reader fails to add HTTP headers
[ http://issues.apache.org/jira/browse/COCOON-1266?page=all ]
David Crossley updated COCOON-1266:
---
Bugzilla Id: (was: 31243)
Other Info: [Patch available]
Description:
The resource reader does not add Last-Modified and Expires headers when serving
resources from the cocoon cache. This leads to unneccessary request from
clients. I think setting the headers in setup() instead of generate() should
fix this problem because generate will only be called for resources not already
in the cache.
Fixing this will trigger another bug introduced with patch #14048. This causes
all resources to be deliverd with a Vary:Host header unless an expiration time
has been set on the reader (which you usually won´t do). This causes IE to
read
the resource again and again. The correct solution is to add an Expires header
with a value of 0, but only if configured!
I prepared a small patch (against 2.1.5) to fix both problems:
diff -u -r1.1.1.3 -r1.5
--- ResourceReader.java 10 Jun 2004 11:23:49 - 1.1.1.3
+++ ResourceReader.java 10 Jun 2004 12:36:49 - 1.5
@@ -118,6 +118,15 @@
try {
inputSource = resolver.resolveURI(src);
+
+ if (expires = 0) {
+ response.setDateHeader(Expires, expires 0 ?
System.currentTimeMillis() + expires : 0);
+ }
+
+ long lastModified = getLastModified();
+ if (lastModified 0) {
+ response.setDateHeader(Last-Modified,
lastModified);
+ }
}
catch (SourceException se) {
throw SourceUtil.handle(Error during resolving of ' + src
+ '., se);
@@ -255,18 +264,6 @@
*/
public void generate() throws IOException, ProcessingException {
try {
-if (expires 0) {
-response.setDateHeader(Expires, System.currentTimeMillis() +
expires);
-}
-else {
-response.addHeader(Vary, Host);
-}
-
-long lastModified = getLastModified();
-if (lastModified 0) {
-response.setDateHeader(Last-Modified, lastModified);
-}
-
try {
inputStream = inputSource.getInputStream();
}
@@ -316,3 +313,4 @@
}
}
was:
The resource reader does not add Last-Modified and Expires headers when serving
resources from the cocoon cache. This leads to unneccessary request from
clients. I think setting the headers in setup() instead of generate() should
fix this problem because generate will only be called for resources not already
in the cache.
Fixing this will trigger another bug introduced with patch #14048. This causes
all resources to be deliverd with a Vary:Host header unless an expiration time
has been set on the reader (which you usually won´t do). This causes IE to
read
the resource again and again. The correct solution is to add an Expires header
with a value of 0, but only if configured!
I prepared a small patch (against 2.1.5) to fix both problems:
diff -u -r1.1.1.3 -r1.5
--- ResourceReader.java 10 Jun 2004 11:23:49 - 1.1.1.3
+++ ResourceReader.java 10 Jun 2004 12:36:49 - 1.5
@@ -118,6 +118,15 @@
try {
inputSource = resolver.resolveURI(src);
+
+ if (expires = 0) {
+ response.setDateHeader(Expires, expires 0 ?
System.currentTimeMillis() + expires : 0);
+ }
+
+ long lastModified = getLastModified();
+ if (lastModified 0) {
+ response.setDateHeader(Last-Modified,
lastModified);
+ }
}
catch (SourceException se) {
throw SourceUtil.handle(Error during resolving of ' + src
+ '., se);
@@ -255,18 +264,6 @@
*/
public void generate() throws IOException, ProcessingException {
try {
-if (expires 0) {
-response.setDateHeader(Expires, System.currentTimeMillis() +
expires);
-}
-else {
-response.addHeader(Vary, Host);
-}
-
-long lastModified = getLastModified();
-if (lastModified 0) {
-response.setDateHeader(Last-Modified, lastModified);
-}
-
try {
inputStream = inputSource.getInputStream();
}
@@ -316,3 +313,4 @@
}
}
[PATCH] Resource reader fails to add HTTP headers
-
Key: COCOON-1266
URL: http://issues.apache.org/jira/browse/COCOON-1266
Project: Cocoon
Type: Bug
Components: - Components: Sitemap
Versions: 2.1.5
Environment: Operating
[jira] Updated: (COCOON-1549) [PATCH] Batik Rhino support incompatible with Cocoon's
[ http://issues.apache.org/jira/browse/COCOON-1549?page=all ] David Crossley updated COCOON-1549: --- Bugzilla Id: (was: 35578) Other Info: [Patch available] [PATCH] Batik Rhino support incompatible with Cocoon's -- Key: COCOON-1549 URL: http://issues.apache.org/jira/browse/COCOON-1549 Project: Cocoon Type: Bug Components: Blocks: Batik Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Attachments: patch-rhinointerpreter A bug has been filed at Batik, but nobody has replied yet: http://issues.apache.org/bugzilla/show_bug.cgi?id=35233 The need is to use Batik's Rhino support for adding JavaScript to SVG. The problem is that Batik's RhinoInterpreter sets a custom security domain incompatible with Rhino context from Cocoon's FlowScript which doesn't set one. The idea is to remove Batik's Rhino security controller to ensure proper interoperability between Cocoon and Batik. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1340) [PATCH] lucene block contribution : a AnalyzerManager component
[ http://issues.apache.org/jira/browse/COCOON-1340?page=all ] David Crossley updated COCOON-1340: --- Bugzilla Id: (was: 32208) Other Info: [Patch available] [PATCH] lucene block contribution : a AnalyzerManager component --- Key: COCOON-1340 URL: http://issues.apache.org/jira/browse/COCOON-1340 Project: Cocoon Type: Improvement Components: Blocks: Lucene Versions: 2.1.5 Environment: Operating System: other Platform: Other Reporter: Nicolas Maisonneuve Assignee: Cocoon Developers Team Priority: Minor Attachments: AnalyzerManager.zip i was frusted with the LuceneIndexTransformer because i can use custom analyzer because the constructor needed parameters. So i developped a analyzerManager. The goal of the analyzerManager is to 1 - register all the necessary analyzers. Two main methods: public void register(key,analyzer); public analyzer get(key); (in a hacked version of LuceneIndexTransformer, in the xml input format you can replace analyzer=myclass by analyzer=mykey and access to all the analyzers you want) you can configure all the necessary analyzers in the cocoon.xconf 2 - allow to configure with a custom xml file a analyzer that need to be configured to work (PerFieldAnalyzer for multilingue document or a custom stopwordanalayzer).= allow multiple analyzers of the same class but with different configurations (see ConfigurableAnalyzer class) with build.xml to deploy to a cocoon webapp see analyzer_manager tag in the cocoon.xconf after the deployment Nicolas Maisonneuve -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1232) [PATCH] NEW--ModuleDB Action for ORACLE( auto. increment )
[ http://issues.apache.org/jira/browse/COCOON-1232?page=all ] David Crossley updated COCOON-1232: --- Bugzilla Id: (was: 30490) Other Info: [Patch available] [PATCH] NEW--ModuleDB Action for ORACLE( auto. increment ) -- Key: COCOON-1232 URL: http://issues.apache.org/jira/browse/COCOON-1232 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: T.C. Yu Assignee: Cocoon Developers Team Attachments: oraAutoInc.zip 2 impl. of autoincrement modules for ORACLE. Usage details are included in the source and will be available thru javadoc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-806) [PATCH]: HSSF Serializer does not process gmr:PrintInformation
[ http://issues.apache.org/jira/browse/COCOON-806?page=all ] David Crossley updated COCOON-806: -- Bugzilla Id: (was: 23002) Other Info: [Patch available] [PATCH]: HSSF Serializer does not process gmr:PrintInformation Key: COCOON-806 URL: http://issues.apache.org/jira/browse/COCOON-806 Project: Cocoon Type: Bug Components: Blocks: POI Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Antonio Gallardo Assignee: Cocoon Developers Team Attachments: EP_Grid.java.diff, EP_Orientation.java.diff, EP_Paper.java.diff, Sheet.java.diff The gmr:PrintInformation element is where we configure all the info related to print configuration of the stylesheet generated. For example: landscape orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring all the info the user send. Here is a example of the element: gmr:PrintInformation gmr:Margins gmr:top PrefUnit=cm Points=28.3/ gmr:bottom PrefUnit=cm Points=28.3/ gmr:left PrefUnit=cm Points=28.3/ gmr:right PrefUnit=cm Points=28.3/ gmr:header PrefUnit=cm Points=14.2/ gmr:footer PrefUnit=cm Points=14.2/ /gmr:Margins gmr:Scale percentage=100 type=percentage/ gmr:vcenter value=0/ gmr:hcenter value=0/ gmr:grid value=0/ gmr:even_if_only_styles value=0/ gmr:monochrome value=0/ gmr:draft value=0/ gmr:titles value=0/ gmr:repeat_top value=/ gmr:repeat_left value=/ gmr:orderr_then_d/gmr:order gmr:orientationlandscape/gmr:orientation gmr:Header Right= Middle=amp;[TAB] Left=/ gmr:Footer Right= Middle=Page amp;[PAGE] Left=/ gmr:paperA4/gmr:paper /gmr:PrintInformation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-881) [PATCH] file upload component for usage with flowscript
[ http://issues.apache.org/jira/browse/COCOON-881?page=all ] David Crossley updated COCOON-881: -- Bugzilla Id: (was: 24529) Other Info: [Patch available] Description: hy, i coded a basic upload component based on the upload action of the cocoon handbook: To use it, you must add the component role in a file user.xroles ?xml version=1.0 encoding=UTF-8? role-list role name=lab.crip5.ECR.cocoon.components.UploadManager shorthand=upload_manager default-class=lab.crip5.ECR.cocoon.components.UploadManagerImpl/ /role-list and setup the cocoon.xconf to use the file cocoon version=2.1 user-roles=/WEB-INF/user.xroles so now we can use the flowscript upload sample in the cocoon wiki ! was: hy, i coded a basic upload component based on the upload action of the cocoon handbook: To use it, you must add the component role in a file user.xroles ?xml version=1.0 encoding=UTF-8? role-list role name=lab.crip5.ECR.cocoon.components.UploadManager shorthand=upload_manager default-class=lab.crip5.ECR.cocoon.components.UploadManagerImpl/ /role-list and setup the cocoon.xconf to use the file cocoon version=2.1 user-roles=/WEB-INF/user.xroles so now we can use the flowscript upload sample in the cocoon wiki ! [PATCH] file upload component for usage with flowscript --- Key: COCOON-881 URL: http://issues.apache.org/jira/browse/COCOON-881 Project: Cocoon Type: Improvement Components: - Components: Avalon Versions: 2.0 Environment: Operating System: All Platform: All Reporter: Nicolas Maisonneuve Assignee: Cocoon Developers Team Priority: Minor Attachments: FileUploadManager.java, FileUploadManagerImpl.java hy, i coded a basic upload component based on the upload action of the cocoon handbook: To use it, you must add the component role in a file user.xroles ?xml version=1.0 encoding=UTF-8? role-list role name=lab.crip5.ECR.cocoon.components.UploadManager shorthand=upload_manager default-class=lab.crip5.ECR.cocoon.components.UploadManagerImpl/ /role-list and setup the cocoon.xconf to use the file cocoon version=2.1 user-roles=/WEB-INF/user.xroles so now we can use the flowscript upload sample in the cocoon wiki ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-825) [PATCH] Fix Bug: Better handling of CLOB in esql (get-xml) and handling of Oracle 'temporary lobs'
[ http://issues.apache.org/jira/browse/COCOON-825?page=all ] David Crossley updated COCOON-825: -- Bugzilla Id: (was: 23542) Other Info: [Patch available] Description: It concerns 2.0.3+ as well. Two changes to properly handle clob's for Oracle: 1. File esql.xsl: in xsl:template match=esql:row-results//esql:get-xml|esql:call-results//esql:get-xml instead of get-string use get-clob. Issue: or make it much cleaner - in get-string-encoded check if column is CLOB and call get-clob from there - I don't understand fully the issue with encoded. 2. Fix problem with temporary clob for Oracle When such a statement is used in esql: select something_what_returnes_temporary_clob from dual (it applies also for call statement) Oracle keeps return clob in TEMP segment and is not willing to free it. Solution: according to Oracle JDBC docs call freeTemporary! Patch: File EsqlHelper.java: In each place where the CLOB/BLOB is taken (getBlob, getClob), put before return: //ORACLE 'temporary lob' problem patch start if (dbClob.getClass().getName().equals(oracle.sql.CLOB)) dbClob.getClass().getMethod(freeTemporary, new Class[0]).invoke(dbClob, new Object[0]); //ORACLE 'temporary lob' problem patch end Hope it will be in the next release, if need some explanation feel free to use my email. Tomasz Bech was: It concerns 2.0.3+ as well. Two changes to properly handle clob's for Oracle: 1. File esql.xsl: in xsl:template match=esql:row-results//esql:get-xml|esql:call-results//esql:get-xml instead of get-string use get-clob. Issue: or make it much cleaner - in get-string-encoded check if column is CLOB and call get-clob from there - I don't understand fully the issue with encoded. 2. Fix problem with temporary clob for Oracle When such a statement is used in esql: select something_what_returnes_temporary_clob from dual (it applies also for call statement) Oracle keeps return clob in TEMP segment and is not willing to free it. Solution: according to Oracle JDBC docs call freeTemporary! Patch: File EsqlHelper.java: In each place where the CLOB/BLOB is taken (getBlob, getClob), put before return: //ORACLE 'temporary lob' problem patch start if (dbClob.getClass().getName().equals(oracle.sql.CLOB)) dbClob.getClass().getMethod(freeTemporary, new Class[0]).invoke(dbClob, new Object[0]); //ORACLE 'temporary lob' problem patch end Hope it will be in the next release, if need some explanation feel free to use my email. Tomasz Bech [PATCH] Fix Bug: Better handling of CLOB in esql (get-xml) and handling of Oracle 'temporary lobs' -- Key: COCOON-825 URL: http://issues.apache.org/jira/browse/COCOON-825 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Tomasz Bech Assignee: Cocoon Developers Team Attachments: esql.xsl.diff It concerns 2.0.3+ as well. Two changes to properly handle clob's for Oracle: 1. File esql.xsl: in xsl:template match=esql:row-results//esql:get-xml|esql:call-results//esql:get-xml instead of get-string use get-clob. Issue: or make it much cleaner - in get-string-encoded check if column is CLOB and call get-clob from there - I don't understand fully the issue with encoded. 2. Fix problem with temporary clob for Oracle When such a statement is used in esql: select something_what_returnes_temporary_clob from dual (it applies also for call statement) Oracle keeps return clob in TEMP segment and is not willing to free it. Solution: according to Oracle JDBC docs call freeTemporary! Patch: File EsqlHelper.java: In each place where the CLOB/BLOB is taken (getBlob, getClob), put before return: //ORACLE 'temporary lob' problem patch start if (dbClob.getClass().getName().equals(oracle.sql.CLOB)) dbClob.getClass().getMethod(freeTemporary, new Class[0]).invoke(dbClob, new Object[0]); //ORACLE 'temporary lob' problem patch end Hope it will be in the next release, if need some explanation feel free to use my email. Tomasz Bech -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1692) [PATCH] Tree widget not handling on-selection-change events correctly.
[ http://issues.apache.org/jira/browse/COCOON-1692?page=all ] David Crossley updated COCOON-1692: --- Other Info: [Patch available] [PATCH] Tree widget not handling on-selection-change events correctly. -- Key: COCOON-1692 URL: http://issues.apache.org/jira/browse/COCOON-1692 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN), 2.1.8 Reporter: Suzan Foster Attachments: Tree.java.patch In the current implementation field widgets that have their value changed from an on-selection-changed handler do not propagate these changes to the client. The patch, applied to current SVN, resolves this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1384) [PATCH] flow redirector should allow explicit 'cocoon:' scheme
[ http://issues.apache.org/jira/browse/COCOON-1384?page=all ] David Crossley updated COCOON-1384: --- Bugzilla Id: (was: 32762) Other Info: [Patch available] Description: 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. was: 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. [PATCH] flow redirector should allow explicit 'cocoon:' scheme -- Key: COCOON-1384 URL: http://issues.apache.org/jira/browse/COCOON-1384 Project: Cocoon Type: Bug Components: - Flowscript 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, 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1330) [PATCH] redirect to relative urls does not work correctly in Websphere 5.1
[ http://issues.apache.org/jira/browse/COCOON-1330?page=all ] David Crossley updated COCOON-1330: --- Bugzilla Id: (was: 32157) Other Info: [Patch available] [PATCH] redirect to relative urls does not work correctly in Websphere 5.1 -- Key: COCOON-1330 URL: http://issues.apache.org/jira/browse/COCOON-1330 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Assignee: Ralph Goers Attachments: release_2_1_5_1.patch_3.txt Critical for PortletPortalManager. IBM WAS 5.1 doesn't correctly handle redirects to relative urls i.e. httpResponse.sendRedirect(portal.html); at current uri http:/host/context/myportal/login.html - GET http:/host/context/myportal/portal.html (Tomcat 4.1) - GET http:/host/context/portal.html (IBM WAS 5.1) Absolute redirecting should probably go to http environment layer as a configurable feature (web.xml) in the future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1392) [PATCH] Form.js v1 create form with DOM Element
[ http://issues.apache.org/jira/browse/COCOON-1392?page=all ] David Crossley updated COCOON-1392: --- Bugzilla Id: (was: 32960) Other Info: [Patch available] Description: Version 1 of Form.js doesn't support the creation of a form with a DOM Element. This functionality was implemented with v2 but that version (in return) lacks some functionality of v1 (eg. passing of bizdata, which is an important one). In time there should be one version merged from the different current ones, and this may be one step further in that direction. Thus v1 should be extended with the functionality to create a form starting from a DOM Element (as in v2). A patch will be attached which incorporates this change. (while looking at the patch, the third option in DefaultFormManager: create form from source, is also available now). was: Version 1 of Form.js doesn't support the creation of a form with a DOM Element. This functionality was implemented with v2 but that version (in return) lacks some functionality of v1 (eg. passing of bizdata, which is an important one). In time there should be one version merged from the different current ones, and this may be one step further in that direction. Thus v1 should be extended with the functionality to create a form starting from a DOM Element (as in v2). A patch will be attached which incorporates this change. (while looking at the patch, the third option in DefaultFormManager: create form from source, is also available now). [PATCH] Form.js v1 create form with DOM Element --- Key: COCOON-1392 URL: http://issues.apache.org/jira/browse/COCOON-1392 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.8 Environment: Operating System: Windows XP Platform: PC Reporter: Jan Hoskens Assignee: Cocoon Developers Team Priority: Minor Attachments: [PATCH]-32960.diff Version 1 of Form.js doesn't support the creation of a form with a DOM Element. This functionality was implemented with v2 but that version (in return) lacks some functionality of v1 (eg. passing of bizdata, which is an important one). In time there should be one version merged from the different current ones, and this may be one step further in that direction. Thus v1 should be extended with the functionality to create a form starting from a DOM Element (as in v2). A patch will be attached which incorporates this change. (while looking at the patch, the third option in DefaultFormManager: create form from source, is also available now). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1027) [PATCH] CocoonBean add additional features for reprocessing pipelines and interrupt processing
[ http://issues.apache.org/jira/browse/COCOON-1027?page=all ] David Crossley updated COCOON-1027: --- Bugzilla Id: (was: 26657) Other Info: [Patch available] Description: This patch add some features to the Bean, this was short discussed on the user-list. http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107553588409081w=2 The patch only add additional methods and dont change the current behavior. It is now possible to reprocess pipelines without creating a new CocoonBean-instance. If the Bean is controlled from another Thread, it possible to interrupt the processing. This only work if you use process(Crawler). The interruption stop the processing of the next URI's, it dont stop the initialization and the processing of the current pipeline. But if you add a BeanListener, you can observe the stopping. The Bean sends the complete-message to the Listeners,after interruption. was: This patch add some features to the Bean, this was short discussed on the user-list. http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107553588409081w=2 The patch only add additional methods and dont change the current behavior. It is now possible to reprocess pipelines without creating a new CocoonBean-instance. If the Bean is controlled from another Thread, it possible to interrupt the processing. This only work if you use process(Crawler). The interruption stop the processing of the next URI's, it dont stop the initialization and the processing of the current pipeline. But if you add a BeanListener, you can observe the stopping. The Bean sends the complete-message to the Listeners,after interruption. [PATCH] CocoonBean add additional features for reprocessing pipelines and interrupt processing -- Key: COCOON-1027 URL: http://issues.apache.org/jira/browse/COCOON-1027 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Simon Mieth Assignee: Cocoon Developers Team Attachments: CocoonBean.patch This patch add some features to the Bean, this was short discussed on the user-list. http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107553588409081w=2 The patch only add additional methods and dont change the current behavior. It is now possible to reprocess pipelines without creating a new CocoonBean-instance. If the Bean is controlled from another Thread, it possible to interrupt the processing. This only work if you use process(Crawler). The interruption stop the processing of the next URI's, it dont stop the initialization and the processing of the current pipeline. But if you add a BeanListener, you can observe the stopping. The Bean sends the complete-message to the Listeners,after interruption. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
