Re: every new webapp a block?
Mark Lundquist wrote:
Hi, just curious about something...
The Getting Started page
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1159.html says, "The
development of any Cocoon web application is done within a block".
What's the rationale for that? I'm just curious, that's all.
Maybe we should change the wording to "[...] Cocoon web application should be
done [...]" to make the statement less exclusive. Though, in tutorials we should
encourage our users to go down this path. This way they learn how to modularize
a Cocoon webapp right from the beginning.
Is it
just so that new webapps don't have to bring along their own WEB-INF/?
In return for that, they just have to provide a
META-INF/cocoon/spring/core/whatever-block.xml, right?
IIRC META-INF/cocoon/spring/whatever-block.xml, no core.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Managing "changes" information
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
Yes. Then I will setup the src/changes/changes.xml files in our
modules because I guess that nobody wants to write a "StatusReport"
module for Maven.
As I said before this solution comes with the downside that the
description doesn't allow mixed content. Instead of having no
changes reports this is acceptable ;-)
What do you mean by "mixed content"?
e.g. ordered lists --> foobar
I looked into the sources of the Maven report generation mechanism
and AFAICT this API makes it difficult (impossible?) to provide
support for it.
see
http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/changes-report.html.
The description of a particular change can only contain text.
This last change surely would be more readable if it was formatted with
list or something.
Definitly
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
Mark Lundquist wrote:
On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote:
On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:
[..snip]
4) If I want to debug this, I'm going to fiddle around with resources
in the cocoon-core-additional-sample block (like the sitemap, JXTs
etc.). How do I set things up so that those changes will take effect
on the fly, without having to do some mvn install thing and restart
Jetty?
Any clues?
—ml—
I just tried setting up the RCL per
http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that
the solution I'm after?
I added the rcl.properties to cocoon-core-addition-sample/pom.xml and
tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there... but
when I request the webapp site root in my browser, I get:
Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but
that's all the sitemap.xmap etc., are all missing.
There is no need for a global sitemap.xmap anymore. You mount one of your blocks
to the root of your webapp ("/").
After running rcl:webapp, have you tried to start the created webapp?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Input modules samples broken in trunk
Mark Lundquist wrote:
On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote:
[..snip]
4) If I want to debug this, I'm going to fiddle around with resources
in the cocoon-core-additional-sample block (like the sitemap, JXTs
etc.). How do I set things up so that those changes will take effect
on the fly, without having to do some mvn install thing and restart
Jetty?
Any clues?
try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Managing "changes" information
Reinhard Poetz wrote: Reinhard Poetz wrote: Ralph Goers wrote: Reinhard Poetz wrote: Yes. Then I will setup the src/changes/changes.xml files in our modules because I guess that nobody wants to write a "StatusReport" module for Maven. As I said before this solution comes with the downside that the description doesn't allow mixed content. Instead of having no changes reports this is acceptable ;-) What do you mean by "mixed content"? e.g. ordered lists --> foobar I looked into the sources of the Maven report generation mechanism and AFAICT this API makes it difficult (impossible?) to provide support for it. see http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/changes-report.html. The description of a particular change can only contain text. This last change surely would be more readable if it was formatted with list or something. Vadim
Re: What is the deal with "pipelines" :-) (was Re: What is the deal with "blocks")
Mark Lundquist wrote: On Jan 3, 2007, at 9:29 AM, Alexander Klimetschek wrote: BTW: In sitemaps you have multiple usage of the term "pipeline": there is the element which typically contains multiple matcher with their own pipeline - so you have pipelines there. And inside of act statements you have "internal" pipelines where at the same time you can declare a as internal-only="true"... All a bit confusing to me ;-) Yes... informally we use the term "pipeline" all the time to mean "matcher or selector", which is different from the formal meaning of the sitemap (which is more like a network of pipes than a single pipe). I've never been able come up with a satisfying unambiguous nomenclature. You might find this useful. http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101053457412921 Vadim
request
Hi, I'd like to make a modest request... if those who know how could add a little something to the element in the various poms, I think it would help make the source base more broadly accessible, i.e. beyond the inner circle of people who have done the heavy lifting... :-) And going forward, IMHO all new modules should include some kind of "what is this?" readme info in the pom description. For instance (and this is just a "for instance"...), I see that we have cocoon-sitemap-components and cocoon-pipeline-components, and I have no clue why a component should be in one module vs. the other. Maybe I don't really have an urgent need to know, but probably knowing why there are both modules and what the difference is would help me to understand the Cocoon architecture better. WDYAT? —ml—
Importing Cocoon projects into Eclipse
OK... On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote: For resources it works as you want OOTB, if you run from Eclipse. What is important is that you run "mvn eclipse:eclipse" from top level. If you do that (and import the needed projectts into Eclipse), I ran "mvn eclipse:eclipse"; now which projects do I need to import, and what's the easiest way to do it? :-) (again, my goal here is to run the cocoon-webapp w/ samples using the Eclipse Jetty plugin...) thx, —ml—
Re: RFC: CForms Roadmap
Alexander Klimetschek wrote:
Hi Jeremy, hi all,
I have another feature request for Cforms: change the widget hierarchy
separator from "." to something else ("_"), eg. having a form called
"myform" containing a widget named "somefield" would result in the fully
qualified widget id "myform_somefield".
The problem is that having a dot in the ids makes it very hard to do CSS
styling for the final HTML version of the form. This is because CSS id
selectors cannot contain a ".", that is reserved for class selectors.
Can't you just escape the "."?
#myform\.somefield {...}
I remember CSS selectability was discussed back when the id naming rules
were being proposed, and I thought I remembered this working correctly
in the major browsers.
Here's some thread linkage:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=css+escape+cforms+widget+id&q=b
For example:
#myform.somefield {
// styling...
}
is incorrect CSS or at least is interpreted as
#myform .somefield {
// styling..
}
aka "element with id myform and below any element with the class
somefield".
A way to work around is either to define your special classes via
fi:styling or to write complicated selectors that take the structure of
the HTML document into account (div.someclass div.foobar input.forms
...). Both are very limited: fi:styling is difficult if you are using
custom styled elements (=custom XSL) where you cannot easily set a class
and it does not work if you want to use it together with the standard
classes like "active" or "output". And it requires the CSS designer to
change the form templates probably on each modification, which IMHO
violates separation of concerns. The other solution I don't wanna talk
about... ;-)
Jeremy you said that the dot separator is basic assumption for all the
cforms java code, so that it would be a massive change. Nevertheless I
find it quite a major flaw in the cforms design (the only one I know of
;-).
WDYT?
Alex
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote: Don't know how rcl work, it is mainly for recompiling Java classes on the fly IIUC. Yes... what got me thinking RCL was this thread: http://marc.theaimsgroup.com/?t=11683427565&r=1&w=2 For resources it works as you want OOTB, if you run from Eclipse. What is important is that you run "mvn eclipse:eclipse" from top level. If you do that (and import the needed projectts into Eclipse), you can just run the Eclipse Jetty plugin and change the resources in the blocks and get result immediately. If you instead run eclipse:eclipse from within a project, you will instead get the installed jars in your Maven repository as dependencies and the you have to rebuild and restart. OK, thanks... I'll try it. It is also important to have -Dorg.apache.cocoon.mode=develop as argument to the Jetty launcher, otherwise the tree processor will not reload the resources when they change. JOOC, where's that implmented? Anyway... for whoever's interested, it seems like setting up cocoon-webapp for the RCL did not work as advertised for me, maybe I was doing something wrong? In any case I'll be moving on to try my luck with the Eclipse Jetty plugin. Thx a lot, —ml—
every new webapp a block?
Hi, just curious about something... The Getting Started page http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1159.html says, "The development of any Cocoon web application is done within a block". What's the rationale for that? I'm just curious, that's all. Is it just so that new webapps don't have to bring along their own WEB-INF/? In return for that, they just have to provide a META-INF/cocoon/spring/core/whatever-block.xml, right? thx, —ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
Mark Lundquist skrev: On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote: On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote: [..snip] 4) If I want to debug this, I'm going to fiddle around with resources in the cocoon-core-additional-sample block (like the sitemap, JXTs etc.). How do I set things up so that those changes will take effect on the fly, without having to do some mvn install thing and restart Jetty? Any clues? —ml— I just tried setting up the RCL per http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that the solution I'm after? I added the rcl.properties to cocoon-core-addition-sample/pom.xml and tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there... but when I request the webapp site root in my browser, I get: Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but that's all the sitemap.xmap etc., are all missing. Any ideas? Don't know how rcl work, it is mainly for recompiling Java classes on the fly IIUC. For resources it works as you want OOTB, if you run from Eclipse. What is important is that you run "mvn eclipse:eclipse" from top level. If you do that (and import the needed projectts into Eclipse), you can just run the Eclipse Jetty plugin and change the resources in the blocks and get result immediately. If you instead run eclipse:eclipse from within a project, you will instead get the installed jars in your Maven repository as dependencies and the you have to rebuild and restart. It is also important to have -Dorg.apache.cocoon.mode=develop as argument to the Jetty launcher, otherwise the tree processor will not reload the resources when they change. /Daniel
RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 10, 2007, at 2:04 PM, Mark Lundquist wrote: On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote: [..snip] 4) If I want to debug this, I'm going to fiddle around with resources in the cocoon-core-additional-sample block (like the sitemap, JXTs etc.). How do I set things up so that those changes will take effect on the fly, without having to do some mvn install thing and restart Jetty? Any clues? —ml— I just tried setting up the RCL per http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that the solution I'm after? I added the rcl.properties to cocoon-core-addition-sample/pom.xml and tweaked the cocoon-webapp/pom.xml, ran "mvn rcl:webapp" there... but when I request the webapp site root in my browser, I get: Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but that's all the sitemap.xmap etc., are all missing. Any ideas? —ml—
Re: Input modules samples broken in trunk
On Jan 4, 2007, at 4:51 PM, Mark Lundquist wrote: [..snip] 4) If I want to debug this, I'm going to fiddle around with resources in the cocoon-core-additional-sample block (like the sitemap, JXTs etc.). How do I set things up so that those changes will take effect on the fly, without having to do some mvn install thing and restart Jetty? Any clues? —ml—
Re: RFC: CForms Roadmap
Hi Jeremy, hi all,
I have another feature request for Cforms: change the widget hierarchy
separator from "." to something else ("_"), eg. having a form called
"myform" containing a widget named "somefield" would result in the fully
qualified widget id "myform_somefield".
The problem is that having a dot in the ids makes it very hard to do CSS
styling for the final HTML version of the form. This is because CSS id
selectors cannot contain a ".", that is reserved for class selectors.
For example:
#myform.somefield {
// styling...
}
is incorrect CSS or at least is interpreted as
#myform .somefield {
// styling..
}
aka "element with id myform and below any element with the class somefield".
A way to work around is either to define your special classes via
fi:styling or to write complicated selectors that take the structure of
the HTML document into account (div.someclass div.foobar input.forms
...). Both are very limited: fi:styling is difficult if you are using
custom styled elements (=custom XSL) where you cannot easily set a class
and it does not work if you want to use it together with the standard
classes like "active" or "output". And it requires the CSS designer to
change the form templates probably on each modification, which IMHO
violates separation of concerns. The other solution I don't wanna talk
about... ;-)
Jeremy you said that the dot separator is basic assumption for all the
cforms java code, so that it would be a massive change. Nevertheless I
find it quite a major flaw in the cforms design (the only one I know of ;-).
WDYT?
Alex
Jeremy Quinn schrieb:
Hi All
Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid
platform to complete the modernisation of CForms client-side code.
I hope the main outcomes of this will be :
Leaner: only the resources that are used will be loaded by cforms
Richer: more interactive widgets with wider x-platform support
Cleaner: eliminate most of the messy
Re: [jira] Commented: (COCOON-1975) cocoon-core-M2 could not be runned because of missing dependencies on avalon-framework-api-4.3 and excalibur-instrument-api-2.1
Reinhard Poetz napisał(a): ok, I will release the archetypes again with the next series of module releases that I plan to do in about 2 or 3 weeks. Thanks for your work!!! No problem. I'm going to fix the issue in Maven, but the code where the bug seems to lay in is piece of crap (opinion of Maven dev ;)) so it's quite difficult to figure out exact place of faluty code. I'm also having exams on University so I won't be able to do this now, though. I'll report on progress (if any) in 3 weeks or so. -- Grzegorz Kossakowski
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (89 issues) Subscriber: cocoon Key Summary COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for "generator/reader already set" should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1955 [Patch] Allow shielded class loading for a single block https://issues.apache.org/jira/browse/COCOON-1955 COCOON-1954 [Patch] RequestProcessor swallows exceptions in blocks case https://issues.apache.org/jira/browse/COCOON-1954 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice https://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin https://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element https://issues.apache.org/jira/browse/COCOON-1893 COCOON-1887 Host selector should be case insensitive https://issues.apache.org/jira/browse/COCOON-1887 COCOON-1877 [PATCH] Pageable Repeater https://issues.apache.org/jira/browse/COCOON-1877 COCOON-1870 Lucene block does not store attributes when instructed so https://issues.apache.org/jira/browse/COCOON-1870 COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE https://issues.apache.org/jira/browse/COCOON-1846 COCOON-1843 LDAPTransformer: add-entry tag doesn't work https://issues.apache.org/jira/browse/COCOON-1843 COCOON-1842 LDAPTransformer: ClassCastException with Binary fields https://issues.apache.org/jira/browse/COCOON-1842 COCOON-1838 Always use 3-digit version number https://issues.apache.org/jira/browse/COCOON-1838 COCOON-1810 [PATCH] JMSEventMessageListener does not work https://issues.apache.org/jira/browse/COCOON-1810 COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding https://issues.apache.org/jira/browse/COCOON-1794 COCOON-1738 double-listbox problem in repeaters https://issues.apache.org/jira/browse/COCOON-1738 COCOON-1726 Implementation of Source that supports conditional GETs https://issues.apache.org/jira/browse/COCOON-1726 COCOON-1717 Use custom cache keys for caching uri coplets using input modules. https://issues.apache.org/jira/browse/COCOON-1717 COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter https://issues.apache.org/jira/browse/COCOON-1703 COCOON-1697 Allow request parameters to be used in "for (var k in h)" kind of Javascript Loops https://issues.apache.org/jira/browse/COCOON-1697 COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace. https://issues.apache.org/jira/browse/COCOON-1686 COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms https://issues.apache.org/jira/browse/COCOON-1648 COCOON-1622 [PATCH] SendMailTransformer and HTML body https://issues.apache.org/jira/browse/COCOON-1622 COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block https://issues.apache.org/jira/browse/COCOON-1618 COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able to pass a locale https://issues.apache.org/jira/br
Re: Problems with hsqldb
Ok, just ignore this - I found the reason: the newer versions seem to require a call setDatabaseName() in addition to setDatabasePath(). Carsten Carsten Ziegeler wrote: > Hi, > > I'm experiencing problems with later hsqldb versions, the latest version > working for me is 1.8.0.2. Using a later version, everything seems to be > ok (no exceptions, no log statements etc.), but although the code is > executing, the database is not available. > > Is anyone else having similar problems or is a newer version working for > someone? The simplest way to test this is replacing the version in 2.1.x > and seeing if the database comes up. > > Thanks > Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Problems with hsqldb
Hi, I'm experiencing problems with later hsqldb versions, the latest version working for me is 1.8.0.2. Using a later version, everything seems to be ok (no exceptions, no log statements etc.), but although the code is executing, the database is not available. Is anyone else having similar problems or is a newer version working for someone? The simplest way to test this is replacing the version in 2.1.x and seeing if the database comes up. Thanks Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1980) Build error with Java 6
Build error with Java 6
---
Key: COCOON-1980
URL: https://issues.apache.org/jira/browse/COCOON-1980
Project: Cocoon
Issue Type: Bug
Components: Blocks: Databases
Affects Versions: 2.1.10
Reporter: Markus Wolf
Priority: Minor
Building the database block with Java 6 results in the following exception:
.../cocoon-2.1.10/src/blocks/databases/java/org/apache/cocoon/databases/ibatis/ExcaliburDataSourceFactory.java:82:
org.apache.cocoon.databases.ibatis.ExcaliburDataSourceFactory.DataSourceWrapper
is not abstract and does not override abstract method
isWrapperFor(java.lang.Class) in java.sql.Wrapper
protected static final class DataSourceWrapper implements DataSource {
^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
BUILD FAILED
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Cocoon API still refers to cocoon 2.1.9
Hi guys, how come http://cocoon.apache.org/2.1/apidocs/index.html still points to API 2.1.9? Or is only the name wrong? Cheers, Robby Pelssers
[jira] Closed: (COCOON-574) [PATCH] fixed redirect under JRun 3.1
[ https://issues.apache.org/jira/browse/COCOON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-574. --- Resolution: Won't Fix Thanks for the info! > [PATCH] fixed redirect under JRun 3.1 > - > > Key: COCOON-574 > URL: https://issues.apache.org/jira/browse/COCOON-574 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.0.5-dev (Current CVS), 2.1.10 > Environment: Operating System: All > Platform: All >Reporter: Michal Durdina > Assigned To: Carsten Ziegeler > Attachments: HttpEnvironment.java.diff, release_2_1_5_1.patch_3.txt > > > Proposed WebSphere 4.0/4.0.1 response.encodeRedirectURL() bug fix (by VG) > doesn't work for JRun 3.1. It produces double base path fragment on the > resulting URL, when it mistakenly assumes WS bug. > I.e. for redirect to "../myfile.html" at "http://host/webapp/mydir/main.html"; > the result is "http://host/webapp/mydir/webapp/mydir/../myfile.html"; on JRun. > The patch adds additional check for output from encodeRedirectURL() and ONLY > IF > it actually does not contain expected base path, it adds one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-574) [PATCH] fixed redirect under JRun 3.1
[ https://issues.apache.org/jira/browse/COCOON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463521 ] Michal Durdina commented on COCOON-574: --- Hello, you can close it, regardless bug is still existing or not. I have no way to test it, we are no longer deploying C2 to JRun, we switched to Tomcat. Bye, Michal > [PATCH] fixed redirect under JRun 3.1 > - > > Key: COCOON-574 > URL: https://issues.apache.org/jira/browse/COCOON-574 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.0.5-dev (Current CVS), 2.1.10 > Environment: Operating System: All > Platform: All >Reporter: Michal Durdina > Assigned To: Carsten Ziegeler > Attachments: HttpEnvironment.java.diff, release_2_1_5_1.patch_3.txt > > > Proposed WebSphere 4.0/4.0.1 response.encodeRedirectURL() bug fix (by VG) > doesn't work for JRun 3.1. It produces double base path fragment on the > resulting URL, when it mistakenly assumes WS bug. > I.e. for redirect to "../myfile.html" at "http://host/webapp/mydir/main.html"; > the result is "http://host/webapp/mydir/webapp/mydir/../myfile.html"; on JRun. > The patch adds additional check for output from encodeRedirectURL() and ONLY > IF > it actually does not contain expected base path, it adds one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1961) Cocoon deployer plugin given null pointer cause of maven limitations on subclassing
[ https://issues.apache.org/jira/browse/COCOON-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON-1961: - Priority: Critical (was: Blocker) > Cocoon deployer plugin given null pointer cause of maven limitations on > subclassing > --- > > Key: COCOON-1961 > URL: https://issues.apache.org/jira/browse/COCOON-1961 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Simone Gianni >Priority: Critical > > Currently, trying to build (mvn package for example) a dist, throws a null > pointer exception. Stack trace follows. > The problem is that the property archiverManager of AbstractWarMojo is null. > The problem is simply summarized here : > http://www.mail-archive.com/dev@maven.apache.org/msg60770.html , a mojo > should not subclass another mojo cause the super one will not be inited by > maven. > In that mail is written "You'll need to redefine that parameter if you want > to use it in the xdoclet [subclass] plugin". Don't know exactly what this > means, cause redefining a private field will not fill the super one and AFAIK > there is no way to define a maven @parameter not associated to a declared > field. > I've opened an issue on maven jira about subdividing the WAR plugin in > separate goals, so that it will be possible to write plugins that operates on > the WAR directory structure, and stack them in the package lifecycle phase in > an order like "war:prepare, cocoon:deploy, what:else, war:package". This is > http://jira.codehaus.org/browse/MWAR-86 . > I will try to modify the war plugin this way, and test it with a mock plugin. > In case someone manages to have it working, then we could rewrite the cocoon > deployer in a way that does not subclass the war mojo, but only operates on > the war directory structure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-574) [PATCH] fixed redirect under JRun 3.1
[ https://issues.apache.org/jira/browse/COCOON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463511 ] Carsten Ziegeler commented on COCOON-574: - Is this still an issue? If I get no response in the next weeks, I'll close this bug with "wont fix" > [PATCH] fixed redirect under JRun 3.1 > - > > Key: COCOON-574 > URL: https://issues.apache.org/jira/browse/COCOON-574 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.0.5-dev (Current CVS), 2.1.10 > Environment: Operating System: All > Platform: All >Reporter: Michal Durdina > Assigned To: Carsten Ziegeler > Attachments: HttpEnvironment.java.diff, release_2_1_5_1.patch_3.txt > > > Proposed WebSphere 4.0/4.0.1 response.encodeRedirectURL() bug fix (by VG) > doesn't work for JRun 3.1. It produces double base path fragment on the > resulting URL, when it mistakenly assumes WS bug. > I.e. for redirect to "../myfile.html" at "http://host/webapp/mydir/main.html"; > the result is "http://host/webapp/mydir/webapp/mydir/../myfile.html"; on JRun. > The patch adds additional check for output from encodeRedirectURL() and ONLY > IF > it actually does not contain expected base path, it adds one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-574) [PATCH] fixed redirect under JRun 3.1
[ https://issues.apache.org/jira/browse/COCOON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned COCOON-574: --- Assignee: Carsten Ziegeler (was: Cocoon Developers Team) > [PATCH] fixed redirect under JRun 3.1 > - > > Key: COCOON-574 > URL: https://issues.apache.org/jira/browse/COCOON-574 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.0.5-dev (Current CVS), 2.1.10 > Environment: Operating System: All > Platform: All >Reporter: Michal Durdina > Assigned To: Carsten Ziegeler > Attachments: HttpEnvironment.java.diff, release_2_1_5_1.patch_3.txt > > > Proposed WebSphere 4.0/4.0.1 response.encodeRedirectURL() bug fix (by VG) > doesn't work for JRun 3.1. It produces double base path fragment on the > resulting URL, when it mistakenly assumes WS bug. > I.e. for redirect to "../myfile.html" at "http://host/webapp/mydir/main.html"; > the result is "http://host/webapp/mydir/webapp/mydir/../myfile.html"; on JRun. > The patch adds additional check for output from encodeRedirectURL() and ONLY > IF > it actually does not contain expected base path, it adds one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1624) reader caching does not consider mime-type
[ https://issues.apache.org/jira/browse/COCOON-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463510 ] Carsten Ziegeler commented on COCOON-1624: -- I think we have to fix this in the pipeline implementations. A reader never gets the configured mime-type from the sitemap. I guess we have to improve our caching implementations to better support mime-types (and perhaps http headers) anyway. > reader caching does not consider mime-type > -- > > Key: COCOON-1624 > URL: https://issues.apache.org/jira/browse/COCOON-1624 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: other > Platform: Other >Reporter: Jörg Heinicke > Assigned To: Cocoon Developers Team > > Changing the mime type on a reader in a caching pipeline does not invalidate > its > former usage with another mime type. > Sample: > > > > changed to > >mime-type="application/vnd.mozilla.xul+xml"/> > > still results in delivery with text/xml. Carsten already saw it at the > hackathon > when I played around with XUL. > Jörg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON-1979: - Affects Version/s: (was: 2.1.11-dev (Current SVN)) (was: 2.2-dev (Current SVN)) > [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via > cocoon.load > -- > > Key: COCOON-1979 > URL: https://issues.apache.org/jira/browse/COCOON-1979 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Rob Berens > Assigned To: Carsten Ziegeler > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: patch-1.txt, patch-2.txt > > > When a script is loaded via cocoon.load the refresh parameter for > CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In > 2.1.8 this parameter was incorrectly ignored, when checking the compile time > against the last modified time in > CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 > or 2.1.10. The side effect however is that scripts loaded via cocoon.load are > never checked for modification, as > FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the > getScript method with refresh = false. > In the supplied patched (patch-1.txt and patch-2.txt) the compileScript > method now sets the refresh indicator dependent on the reload-script and > check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-1979. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Oh, yes - you're right of course. Your patch is applied - please cross check > [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via > cocoon.load > -- > > Key: COCOON-1979 > URL: https://issues.apache.org/jira/browse/COCOON-1979 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Rob Berens > Assigned To: Carsten Ziegeler > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: patch-1.txt, patch-2.txt > > > When a script is loaded via cocoon.load the refresh parameter for > CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In > 2.1.8 this parameter was incorrectly ignored, when checking the compile time > against the last modified time in > CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 > or 2.1.10. The side effect however is that scripts loaded via cocoon.load are > never checked for modification, as > FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the > getScript method with refresh = false. > In the supplied patched (patch-1.txt and patch-2.txt) the compileScript > method now sets the refresh indicator dependent on the reload-script and > check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (COCOON-1975) cocoon-core-M2 could not be runned because of missing dependencies on avalon-framework-api-4.3 and excalibur-instrument-api-2.1
Grzegorz Kossakowski wrote:
Grzegorz Kossakowski napisał(a):
Reinhard Poetz napisał(a):
I've haunted some Maven insider (Kenney Westerhof) for us on IRC. :)
After quite long discussion, we agreed that there is some kind of bug in
Maven. The result is that he has filled report in JIRA and I've managed
to focus some interest on it. I'll watch this issues and do my best to
resolve it. If it's confirmed, I think the best workaround for now is to
release new artifacts that contain directly declaration of apache.snapshot.
I meant "release new archetypes".
ok, I will release the archetypes again with the next series of module releases
that I plan to do in about 2 or 3 weeks.
Thanks for your work!!!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[jira] Commented: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463489 ] Rob Berens commented on COCOON-1979: The additional check: boolean needsRefresh = reloadScripts && (entry.getCompileTime() + checkTime < System.currentTimeMillis()); is needed to comply to the specifcation of the check-time parameter in the configuration of java script flow interpreter in the cocoon.xconf. The check time is the time in miliseconds between the checks for the last modification date of script file. See also line 553 in FOM_JavaScriptInterpreter.java for modification checks for the top level scripts. > [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via > cocoon.load > -- > > Key: COCOON-1979 > URL: https://issues.apache.org/jira/browse/COCOON-1979 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Rob Berens > Assigned To: Carsten Ziegeler > Attachments: patch-1.txt, patch-2.txt > > > When a script is loaded via cocoon.load the refresh parameter for > CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In > 2.1.8 this parameter was incorrectly ignored, when checking the compile time > against the last modified time in > CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 > or 2.1.10. The side effect however is that scripts loaded via cocoon.load are > never checked for modification, as > FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the > getScript method with refresh = false. > In the supplied patched (patch-1.txt and patch-2.txt) the compileScript > method now sets the refresh indicator dependent on the reload-script and > check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RFC: CForms Roadmap
Max Pfingsthorn wrote > By the way, has anything improved authentication-wise in Cocoon? We have the simple CAuth framework in Cocoon which you could use for authentication, but I think especially with Cocoon 2.2 which comes with Spring, using Spring Acegi Security is a good choice. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463487 ] Carsten Ziegeler commented on COCOON-1979: -- Although your patch fixes the problem, I'm wondering why a compiledScript = entry.getScript(cx, this.scope, reloadScripts, this); doesn't do the job as well. The getScript method compares already the timestamps for reloading. > [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via > cocoon.load > -- > > Key: COCOON-1979 > URL: https://issues.apache.org/jira/browse/COCOON-1979 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Rob Berens > Assigned To: Carsten Ziegeler > Attachments: patch-1.txt, patch-2.txt > > > When a script is loaded via cocoon.load the refresh parameter for > CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In > 2.1.8 this parameter was incorrectly ignored, when checking the compile time > against the last modified time in > CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 > or 2.1.10. The side effect however is that scripts loaded via cocoon.load are > never checked for modification, as > FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the > getScript method with refresh = false. > In the supplied patched (patch-1.txt and patch-2.txt) the compileScript > method now sets the refresh indicator dependent on the reload-script and > check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned COCOON-1979: Assignee: Carsten Ziegeler > [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via > cocoon.load > -- > > Key: COCOON-1979 > URL: https://issues.apache.org/jira/browse/COCOON-1979 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Rob Berens > Assigned To: Carsten Ziegeler > Attachments: patch-1.txt, patch-2.txt > > > When a script is loaded via cocoon.load the refresh parameter for > CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In > 2.1.8 this parameter was incorrectly ignored, when checking the compile time > against the last modified time in > CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 > or 2.1.10. The side effect however is that scripts loaded via cocoon.load are > never checked for modification, as > FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the > getScript method with refresh = false. > In the supplied patched (patch-1.txt and patch-2.txt) the compileScript > method now sets the refresh indicator dependent on the reload-script and > check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
