[jira] Updated: (COCOON-1691) ESQL compilation error
[ http://issues.apache.org/jira/browse/COCOON-1691?page=all ]
Alfred Nathaniel updated COCOON-1691:
-
Component: Blocks: Databases
(was: Blocks: XSP)
Fix Version: 2.1.9-dev (current SVN)
Damn it, the ESQL logicsheet escaped my renaming exercise. Our pre-release
testing really sucks...
Fix for 2.1.9-dev and trunk committed.
You can patch it relatively easy in a 2.1.8 source distribution. Edit
src/blocks/xsp/databases/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
and change xspAttr to _xspAttr in these two lines:
line 697: this._esql_printObject(_esql_struct[_esql_k],xspAttr);
line 708: this._esql_printObject(_esql_query.getResultSet().getObject(_esql_i),
xspAttr);
ESQL compilation error
--
Key: COCOON-1691
URL: http://issues.apache.org/jira/browse/COCOON-1691
Project: Cocoon
Type: Bug
Components: Blocks: Databases
Versions: 2.1.8
Reporter: Feliciano Borrego
Assignee: Alfred Nathaniel
Priority: Critical
Fix For: 2.1.9-dev (current SVN)
Attachments: xsp_esql-error.zip
In the Cocoon 2.1.7 version the sent file mis_referencias.xsp compiled and
run correctly.
org.apache.cocoon.components.language.LanguageException: Error compiling
mis_referencias_xsp:
ERROR 1
(org\apache\cocoon\www\file_\c_\Des\Proy\SigPortal\web\portal\xsp\mis_referencias_xsp.java):
...
);
_xspAttr.clear();
// start error (lines 687-687) xspAttr cannot be resolved
this._esql_printObject(_esql_struct[_esql_k],xspAttr);
// end error
this.contentHandler.endElement(
,
sql-row-item,
...
ERROR 2
(org\apache\cocoon\www\file_\c_\Des\Proy\SigPortal\web\portal\xsp\mis_referencias_xsp.java):
...
// postgres is broken as it doesn't allow getObject()
// to retrieve any type (i.e. bit and bit varying)
// so don't handle complex types different for postgres
if (!_esql_connection.getURL().startsWith(jdbc:postgresql:)) {
// start error (lines 713-713) xspAttr cannot be resolved
this._esql_printObject(_esql_query.getResultSet().getObject(_esql_i),
xspAttr);
// end error
break;
}
default:
...
Line 687, column 0: xspAttr cannot be resolved
Line 713, column 0: xspAttr cannot be resolved
--
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
WEB-INF/entities
Hi, Would it make sense to package up the entities stuff and include it in cocoon-core.jar or perhaps in cocoon-entities.jar ? Is this possible at all ? It would make it easier to manage them from a maven point of view, as the more we can put in jars the less we have to manage ourselves during deployment. Regards, Jorg Note: i have never knowingly used the entities, so bear with me if this sounds totally daft..
2.2 Documentation
was: Re: Planning 2.2 Ezkovich Glen wrote: ... I agree. But if you release today, then no one except those that have touched those things or followed the developer list will know what those features are much less how to use them. A 2.2 M1 is for the benefit of the community and early adapters rather than for a broad audience. It is for channeling community focus and energy, which will cretate value for a broader audience after a while. Neither the less we need to start a 2.2 Documentation effort: Point me in the right direction, give me a tentative release date and I will write up some documentation. Best offer I can give you today. Thanks for the offer. Can't give you a tentative release date, but at least some pointers: We need a 2.2 branch of our documentation (maybe there allready is one?) Documentation of (please everyone, provide relevant links to mail and other documentation): - ECM++ - Virtual sitemap components (not particullary mature yet, but start with http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111316710610638w=2 and ask on the list) - blocks (sitemap blocks, exposing blocks) Ongoing work, but the sitemap aspect http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111791016006393w=2 is based on a large amount of community driven design, so it might be worthwhile to start documenting. The component aspect, and the OSGi part need more work and discussion. - per sitemap reloading classloader (for dev) - reworked property management - Spring integration (Spring block) - possible to listen to sitemap events - refactoring of Javaflow (uses now the commons-javaflow project which was started by Thorsten) - introduction of CTemplate (refactoring of JXTemplate in 2.1.x) It should be completely back compatible with the original JXTG, but can also be used in non flow environment. Leszek have added some features, can you give links to relevant mails please. --- o0o --- I guess, collecting relevant links to mail and current documentation snippets in the Wiki or in Daisy, would be a good first step. WDYT? /Daniel
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Hmm, it's been a while since I've looked at this and the code base WRT the Cache/Store code has changed since in a way I didn't keep fully abreast of. The original intention of the EventAware code was to do exactly what you wanted. IIRC the Cache used to have a transient front-end backed by a persistent backend transparently. Since then the terminology and code was changed I think to have Stores be transient and Cache persistent. I see, so your suggestion would be to implement an EventAware MRUMemoryStore? And maybe also make the EHDefaultStore EventAware? I guess for that, an EventAwareManager would be required cause right now the JMSEventMessageListener looks up the EventAware cache by itself instead of getting a list of EventAwares and calling processEvent on them. One big problem though: Stores are deprecated... :( For your need, it may only be necessary to factor the relevant code out of the Cache to a more generic place where both Store and Cache can take advantage of it. Not sure if that is necessary. I can see that the functionality is rather the same, but making a wrapper around the ehcache Cache or something like that seems a little weird cause we would dictate which cache implementation to use. Maybe the EventAware interface is enough, but add a manager for them? I guess we could provide ready wrappers around different implementations, WDYT? I can't give it a lot of time at the moment, but do want to help make sure this is generally useful. Can you provide some more details of the problem as it exists now to help me get up to speed quickly? My problem is that I need to generate xml ( obviously ;) ), but the xml tree represents a directory tree on a webdav server. So, I don't need to walk over all collections to generate my xml, just over the ones that changed. For that, I'd like to keep two things in memory: A list of children per node and a set of attributes per node. These might not be Serializable (right now I just stuff the AttributesImpl object into a map)... So, what I want is a way to remove these two from the cache/store if a corresponding event comes in so they are regenerated, but I don't have to rebuild the complete structure. Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. WDYT? max
Re: 2.2 Documentation
Regarding the documentation of 2.2: Let me first give you some Daisy background to clarify things, before I explain what I have in mind. Note that this is the quick dirty explanation. The Outerthought boys can give a much more detailed overview. Daisy supports sites (the already mentioned Legacy docs and Documentation) and collections. A collection is merely a set of documents and a site can be considered as a view on one or more collections. That's what is currently the case in our Daisy setup in the zones: Collection legacydocs contains all documentation as it was present in the xdocs of BRANCH_2.1.X. Collection documentation contains all new documents that are written in Daisy. Bruno has marked documents part of legacydocs with a two line red warning at the top of the document. You can see this when you open such a page in Daisy. There are already two sites in Daisy: Legacy docs and Documentation. Both use documents from both collections. My idea was this: I've used Legacy docs site to recreate the old cocoon.apache.org site as best as possible. If this is not enough, a little bit of work needs to be done. This site will be restricted to the 2.1 branch. Since Cocoon 2.1 is frozen when it comes to new features, I suggest that the documentation is only updated when some blatant errors or typos are found. For the 2.2 version please use the Documentation site. That's where new documentation is supposed to be entered. This site also contains links to all available documents in the legacydocs collection, see the last line in the navigation bar. This is added for convenience: if you find documentation in the legacydocs that is still valid for the 2.2 version, just move the documentation from the legacydocs collection to the documentation collection. This has no impact on the documentation in the Legacydocs site. I know it's possible that a document resides in both collections, but I want to end up with a collection of legacydocs that holds information that is either completely outdated or only valid for the 2.1 branch. I know we can make branches in Daisy, but at the moment I don't think this is necessary. I'd rather use that feature when we move from 2.2 to 3.0. In summary: - don't use the legacydocs site - new documents, about new features of Cocoon 2.2, go into the Documentation site. They are part of the documentation collection (automatically if you have the Documentation site open) and they are of type Document (not SimpleDocument). - if the documentation you want to write is already present in the legacydocs and is valid for both versions, move the document to the documentation collection: - select the document, select edit (you have to be logged in), select the Misc tab and make sure the selected list contains only documentation. - if the documentation you want to write is already present in the legacydocs, but is not entirely correct: - are the changes you want to add also valid for 2.1? - yes: go ahead, change the document and move it from the legacydocs to documentation. - no: are the changes minor? - yes: add one or more notes (paragraphs marked Note) that explain the differences between 2.1 and 2.2 and move the document from the legacydocs to documentation. - no: create a new document in the documentation collection and write the information as if the legacydocs document didn't exist. - if you find documentation in the legacydocs that is outdated for both 2.1 and 2.2, then retire the document (Misc tab, under the Options section) - if you find documentation in the wiki that is useful: - copy the information to a Daisy document and finish this - mark the wiki page with a message that the information is added to the official Cocoon documentation. - if there is information in the mailing lists that is useful: - copy the information and elaborate it, turn it into a coherent piece of information. - if necessary, add the links to the relevant messages (each Daisy document has a separate links section that ends up at the bottom of the page). PLEASE DON'T SIMPLY REFER TO THE MAIL MESSAGES. Most of this info is also written on the home page of the Cocoon Documentation site in Daisy: http://cocoon.zones.apache.org/daisy/documentation/659.html If the above is clear, I'll update that page to reflect this information. Bye, Helma
Re: [jira] Commented: (COCOON-1689) Cannot save a cform containing a multivalued field with more than 9 values !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Nov 2005, Sylvain Wallez wrote: Date: Tue, 22 Nov 2005 17:58:01 +0100 From: Sylvain Wallez [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [jira] Commented: (COCOON-1689) Cannot save a cform containing a multivalued field with more than 9 values ! Giacomo Pati wrote: [ http://issues.apache.org/jira/browse/COCOON-1689?page=comments#action_12358249 ] Sylvain Wallez commented on COCOON-1689: We have no indication of the JXPath problem that led to avoiding the use of jxpathContext.removePath(). Giacomo, as the author of this change, can you give us more indications on what motivated it ? This was a workaround due to a bug in JXPath removePath() method reported by Jeremy and me prior to ApacheCon in Stuttgart. At that time it was fixed in their repository but not released (and we do not want to have unreleased jars in our repository). I'll check whether it works with current jxpath jar. Thanks! Workaround is still needed but bug fixed in SVN as reported by Philippe Gassmann (a patch would have been appreciated as the bug was quite trivial to fix after your analysis). I still didn't found the reason why the removeAll methods doesn't remove all items of a Collection (jxpath is quite complex). Will file a bug and a test case to commons-jxpath. Will also try to close jira bug COCOON-1689 - -- 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 (GNU/Linux) iD8DBQFDhF6cLNdJvZjjVZARArpwAJ9Hd9KTEhatBL4c2JwTaD4Bz2jwRACgk54g HNee/EUtR0K2XZTtKvSVwwU= =+Yib -END PGP SIGNATURE-
[jira] Closed: (COCOON-1689) Cannot save a cform containing a multivalued field with more than 9 values !
[ http://issues.apache.org/jira/browse/COCOON-1689?page=all ]
Giacomo Pati closed COCOON-1689:
Resolution: Fixed
Cannot save a cform containing a multivalued field with more than 9 values !
Key: COCOON-1689
URL: http://issues.apache.org/jira/browse/COCOON-1689
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
Reporter: Philippe Gassmann
Priority: Minor
An UnsupportedOperationException occurs when trying to save a form containing
a multivalued field with more that 9 values. Here is the explanation :
here is the incriminated code in MultiValueJXPathBinding.java:doSave():
Iterator rowPointers = multiValueContext.iteratePointers(this.rowPath);
List l = new ArrayList();
while( rowPointers.hasNext() )
{
Pointer p = (Pointer)rowPointers.next();
l.add(p.asPath());
}
Collections.sort(l);
for( int i = l.size()-1; i = 0; i-- )
{
multiValueContext.removePath((String)l.get(i));
}
This code is wrong :
The p.asPath returns something like /doc/node[x]
if the iterator contains more than 9 values x will be written in TWO
characters so, the result of Collections.sort(l) return for 10 values :
/doc/node[10]
/doc/node[1]
/doc/node[2]
/doc/node[3]
/doc/node[4]
/doc/node[5]
/doc/node[6]
/doc/node[7]
/doc/node[8]
/doc/node[9]
so the first node to be deleted is 9. the last is 10. but when trying to
delete the 10th node it does not exist anymore !
A UnsupportedOperationException is thrown.
--
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-1529) I18ntranformation output xmlns:i18n in the first element
[ http://issues.apache.org/jira/browse/COCOON-1529?page=comments#action_12358357 ] Juan Jose Pablos commented on COCOON-1529: -- It is a superfluous namespace declaration. I18ntranformation output xmlns:i18n in the first element - Key: COCOON-1529 URL: http://issues.apache.org/jira/browse/COCOON-1529 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Juan Jose Pablos Assignee: Cocoon Developers Team This is a strage bug. on http://localhost:/samples/i18n/simple.xml around line 183: annotation xmlns:i18n=http://apache.org/cocoon/i18n/2.1; This produces wrong xml output (extra xmlns:i18n attribute). now if you commented out the annotation element then the xmlns:i18n attribute goes to the next element: content xmlns:i18n=http://apache.org/cocoon/i18n/2.1; It looks like it goes to the parent element always. I wish that I could have more information about how to resolve this. -- 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: event aware object cache?
On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Hmm, it's been a while since I've looked at this and the code base WRT the Cache/Store code has changed since in a way I didn't keep fully abreast of. The original intention of the EventAware code was to do exactly what you wanted. IIRC the Cache used to have a transient front-end backed by a persistent backend transparently. Since then the terminology and code was changed I think to have Stores be transient and Cache persistent. I see, so your suggestion would be to implement an EventAware MRUMemoryStore? And maybe also make the EHDefaultStore EventAware? I guess for that, an EventAwareManager would be required cause right now the JMSEventMessageListener looks up the EventAware cache by itself instead of getting a list of EventAwares and calling processEvent on them. One big problem though: Stores are deprecated... :( I missed the deprecation of the Stores discussion. Do you have some pointers in the dev list archives? Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? For your need, it may only be necessary to factor the relevant code out of the Cache to a more generic place where both Store and Cache can take advantage of it. Not sure if that is necessary. I can see that the functionality is rather the same, but making a wrapper around the ehcache Cache or something like that seems a little weird cause we would dictate which cache implementation to use. Maybe the EventAware interface is enough, but add a manager for them? I guess we could provide ready wrappers around different implementations, WDYT? I can't give it a lot of time at the moment, but do want to help make sure this is generally useful. Can you provide some more details of the problem as it exists now to help me get up to speed quickly? My problem is that I need to generate xml ( obviously ;) ), but the xml tree represents a directory tree on a webdav server. So, I don't need to walk over all collections to generate my xml, just over the ones that changed. For that, I'd like to keep two things in memory: A list of children per node and a set of attributes per node. These might not be Serializable (right now I just stuff the AttributesImpl object into a map)... So, what I want is a way to remove these two from the cache/store if a corresponding event comes in so they are regenerated, but I don't have to rebuild the complete structure. Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. Geoff
[EMAIL PROTECTED]: Project cocoon-block-cron (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-cron has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-repository : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-23112005 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon-block-cron (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-cron has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-repository : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-23112005 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: [jira] Updated: (COCOON-1691) ESQL compilation error
Alfred Nathaniel (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1691?page=all ]
Alfred Nathaniel updated COCOON-1691:
-
Component: Blocks: Databases
(was: Blocks: XSP)
Fix Version: 2.1.9-dev (current SVN)
Damn it, the ESQL logicsheet escaped my renaming exercise. Our pre-release
testing really sucks...
Fix for 2.1.9-dev and trunk committed.
Still this change can break existing 3rd party logicsheets relying on existance
of xspAttr. I'd suggest adding a line...
138:public void generate() throws ... {
139: final AttributesImpl xspAttr = _xspAttr;
As well as changing line 122 to add final modifier:
122:private final AttributesImpl _xspAttr = new AttributesImpl();
Vadim
RE: [jira] Updated: (COCOON-1691) ESQL compilation error
Good idea, thanks. I'll do that.
Cheers, Alfred.
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 23. November 2005 14:10
To: dev@cocoon.apache.org
Subject: Re: [jira] Updated: (COCOON-1691) ESQL compilation error
Alfred Nathaniel (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1691?page=all ]
Alfred Nathaniel updated COCOON-1691:
-
Component: Blocks: Databases
(was: Blocks: XSP)
Fix Version: 2.1.9-dev (current SVN)
Damn it, the ESQL logicsheet escaped my renaming exercise. Our pre-release
testing really sucks...
Fix for 2.1.9-dev and trunk committed.
Still this change can break existing 3rd party logicsheets relying on existance
of xspAttr. I'd suggest adding a line...
138:public void generate() throws ... {
139: final AttributesImpl xspAttr = _xspAttr;
As well as changing line 122 to add final modifier:
122:private final AttributesImpl _xspAttr = new AttributesImpl();
Vadim
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender’s company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender’s company.
Re: Planning 2.2
- Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? -- Antonio
Re: Planning 2.2
Antonio Fiol Bonnín wrote: - Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? IMO it would be better to contribute a script that automates this process. That would avoid both a giant patch and some potential merge problems if the code changes while you're removing the tags. My 0.02 euros... Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[jira] Updated: (COCOON-1350) XUpdate bug
[ http://issues.apache.org/jira/browse/COCOON-1350?page=all ] Vadim Gritsenko updated COCOON-1350: Bugzilla Id: (was: 32274) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: XUpdate does not remove the temporary tree it creates while updating a resource. Please, see http://marc.theaimsgroup.com/?l=xindice-usersm=109949860123580w=2 was: XUpdate does not remove the temporary tree it creates while updating a resource. Please, see http://marc.theaimsgroup.com/?l=xindice-usersm=109949860123580w=2 XUpdate bug --- Key: COCOON-1350 URL: http://issues.apache.org/jira/browse/COCOON-1350 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.5 Environment: Operating System: Windows 2000 Platform: PC Reporter: Timur Izhbulatov Assignee: Cocoon Developers Team XUpdate does not remove the temporary tree it creates while updating a resource. Please, see http://marc.theaimsgroup.com/?l=xindice-usersm=109949860123580w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: ... I missed the deprecation of the Stores discussion. Do you have some pointers in the dev list archives? Oh, no, nevermind. The Store interfaces moved into excalibur(?), but the stores in general aren't deprecated... My mistake. Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? Well, I was thinking of registering event awares with that manager so its more up to the components... Then again, if you have multiple jms providers, you might want to listen to a specific topic, or only forward events to a subset of EAs... Its hard to do this kind of thing with lookup IoC. Also, its a tradeoff between configuring the connections between source and sink of the events (e.g. the path between the jms listener and the cache) as roles to look up or as some sort of routing configuration. We could do this by: 1. Letting event awares choose sources/topics to listen to 2. Configuring a name per event source Then, a listener can say, I want to listen to topic foo, no matter where from, or even listen to bar only from source baz and bas. WDYT? ... Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. I don't really see that problem as you still have to configure which cache to use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of course you need both blocks... I don't really understand the false dependency, can you explain? max
Re: event aware object cache?
On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: ... I missed the deprecation of the Stores discussion. Do you have some pointers in the dev list archives? Oh, no, nevermind. The Store interfaces moved into excalibur(?), but the stores in general aren't deprecated... My mistake. Ah, good. I didn't think I could miss something that big, but you never know. Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? Well, I was thinking of registering event awares with that manager so its more up to the components... Then again, if you have multiple jms providers, you might want to listen to a specific topic, or only forward events to a subset of EAs... Its hard to do this kind of thing with lookup IoC. Also, its a tradeoff between configuring the connections between source and sink of the events (e.g. the path between the jms listener and the cache) as roles to look up or as some sort of routing configuration. We could do this by: 1. Letting event awares choose sources/topics to listen to 2. Configuring a name per event source Then, a listener can say, I want to listen to topic foo, no matter where from, or even listen to bar only from source baz and bas. WDYT? Yes, that sounds about right though I haven't fully thought it through. ... Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. I don't really see that problem as you still have to configure which cache to use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of course you need both blocks... I don't really understand the false dependency, can you explain? I thought I had remembered that the EventAware interfaces and implementations were all in the two blocks, but now that I think of it, I guess EventAware itself is in core? I just switched to a new laptop recently and don't even have a local copy of the source on it yet. Anyway, it's almost certainly not important to consider at the moment. Geoff
Re: Planning 2.2
2005/11/23, Sylvain Wallez [EMAIL PROTECTED]: Antonio Fiol Bonnín wrote: - Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? IMO it would be better to contribute a script that automates this process. That would avoid both a giant patch and some potential merge problems if the code changes while you're removing the tags. My 0.02 euros... Sylvain You're right... If what we need is removing all @author tags in all javadoc on all .java files, and it is easily done (in an ant script): replaceregexp byline=true regexp pattern=\*([EMAIL PROTECTED])/ substitution expression=*/ fileset dir=. includes=**/*.java / /replaceregexp This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. -- Antonio
Re: Planning 2.2
2005/11/23, Antonio Fiol Bonnín [EMAIL PROTECTED]: 2005/11/23, Sylvain Wallez [EMAIL PROTECTED]: Antonio Fiol Bonnín wrote: - Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? IMO it would be better to contribute a script that automates this process. That would avoid both a giant patch and some potential merge problems if the code changes while you're removing the tags. My 0.02 euros... Sylvain You're right... If what we need is removing all @author tags in all javadoc on all .java files, and it is easily done (in an ant script): replaceregexp byline=true regexp pattern=\*([EMAIL PROTECTED])/ substitution expression=*/ fileset dir=. includes=**/*.java / /replaceregexp This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. Please note it leaves the * at the beginning of the line (so it leaves a blank javadoc line). -- Antonio
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? Well, I was thinking of registering event awares with that manager so its more up to the components... Then again, if you have multiple jms providers, you might want to listen to a specific topic, or only forward events to a subset of EAs... Its hard to do this kind of thing with lookup IoC. Also, its a tradeoff between configuring the connections between source and sink of the events (e.g. the path between the jms listener and the cache) as roles to look up or as some sort of routing configuration. We could do this by: 1. Letting event awares choose sources/topics to listen to 2. Configuring a name per event source Then, a listener can say, I want to listen to topic foo, no matter where from, or even listen to bar only from source baz and bas. WDYT? Yes, that sounds about right though I haven't fully thought it through. Okay. What about routing tables? Like the one shown under Internet Routing - Internal Routing Tables in [1], we could make a list of routing rules: Source | Topic | Listener - foo| bar | baz means topic bar from source foo should be delivered to listerner baz * | barr | baz baz should also get any message with topic barr from any source foo| * | foolist foolist listens to any topic from source foo foo| bing | *foo distributes any bing message to any listener foobar | * | *foobar distributes any message to any listener * | bang | *bang messages are always delivered to all listeners from any source * | * | bazz bazz listens to any message Now, this table can be configured for the EventAwareManager in cocoon.xconf. I would also add methods such that listeners can add/remove rules, or have some way to do this during runtime in any case. Maybe with an interface using cforms? :D Covers all cases, right? ... Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. I don't really see that problem as you still have to configure which cache to use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of course you need both blocks... I don't really understand the false dependency, can you explain? I thought I had remembered that the EventAware interfaces and implementations were all in the two blocks, but now that I think of it, I guess EventAware itself is in core? I just switched to a new laptop recently and don't even have a local copy of the source on it yet. EventAware, EventAwareCacheImpl, EventRegistry, JMSEventMessageListener, etc are all in the eventcache block. JMSEventMessageListener extends AbstractMessageListener from the jms block. I just don't see how you can use the eventcache or eventaware block without needing the jms block... at least right now. Maybe we can factor out an interface for a generic EventSource which associates with the EventAwareManager (or maybe EventMultiplexer?) to deliver events? Then the jms block can provide a jms implementation of it (the JMSEventMessageListener) and there you go, blocks decoupled! :) WDYT? Anyway, it's almost certainly not important to consider at the moment. Okay. Am I ready to roll, then? max [1] http://www.scit.wlv.ac.uk/~jphb/comms/iproute.html
Help! Redirect to cocoon:/ always redirects to root sitemap
I just ported our application from cocoon 2.1.6 to 2.1.8.
Most things work fine, there only seems to be a problem with the cocoon:
protocol.
My root sitemap called sitemap.xmap contains the following fragment:
map:match pattern=flow/**
map:mount src=flow.xmap uri-prefix= check-reload=true
reload-method=synchron/
/map:match
So if a uri starts with flow, it is offered to the flow.xmap, which does
the following:
map:pipeline
map:match pattern=flow/*/**
map:redirect-to uri=cocoon:/{1}/flow/{2}/
/map:match
/map:pipeline
I.e. it swaps the first two components in the uri and redirects to itself.
(Some background: we have divided our webapp in publications which can be
recognized by te first name in the uri, flow is used to identify internal
requests originating from flow script (sendPage) and therefore we swap in
order to have the publication name in front again).
This worked with 2.1.6, but with 2.1.8 the redirect is done to the root
sitemap.xmap i.s.o. the current flow.xmap as can be seen from this fragment
of the sitemap log file:
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared
pattern 'flow/*/**' at map:match -
file:/C:/OsrDev/xenopsis/build/webapp/flow.xmap:61:38
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/InvokeContext:
Current Sitemap Parameters:
LEVEL 1
PARAM: '2' VALUE: 'portal/index.html'
PARAM: '0' VALUE: 'flow/xenopsis/portal/index.html'
PARAM: '1' VALUE: 'xenopsis'
INFO (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/RedirectToURINode: Redirecting to
'cocoon:/xenopsis/flow/portal/index.html' at map:redirect-to -
file:/C:/OsrDev/xenopsis/build/webapp/flow.xmap:62:54
INFO (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/ForwardRedirector: Redirecting to
'cocoon:/xenopsis/flow/portal/index.html'
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/EnvironmentWrapper: Setting uri (prefix=null,
uris=xenopsis/flow/portal/index.html)
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared
pattern '**' at map:match -
file:/C:/OsrDev/xenopsis/build/webapp/sitemap.xmap:258:31
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/InvokeContext:
Current Sitemap Parameters:
LEVEL 2
PARAM: '0' VALUE: 'xenopsis/flow/portal/index.html'
PARAM: '1' VALUE: 'xenopsis/flow/portal/index.html'
LEVEL 1
PARAM: '../2' VALUE: 'portal/index.html'
PARAM: '../0' VALUE: 'flow/xenopsis/portal/index.html'
PARAM: '../1' VALUE: 'xenopsis'
I observed the same behaviour for uri's used in sendPage and not starting
with a '/'. They were also redirected to the root sitemap.
I didn't make any modifications in our sitemaps or in our java scripts
during the port. They have been ported unchanged from 2.1.6 to 2.1.8.
What am I doing wrong? Or is this a bug?
Rob Berens
Osirion B.V.
The Netherlands
E-mail: [EMAIL PROTECTED]
Re: Help! Redirect to cocoon:/ always redirects to root sitemap
Try using src=./flow.xmap
It worked for me, and I sent an e-mail on that some time ago (I use 2.1.7).
--
Antonio
2005/11/23, Rob Berens [EMAIL PROTECTED]:
I just ported our application from cocoon 2.1.6 to 2.1.8.
Most things work fine, there only seems to be a problem with the cocoon:
protocol.
My root sitemap called sitemap.xmap contains the following fragment:
map:match pattern=flow/**
map:mount src=flow.xmap uri-prefix= check-reload=true
reload-method=synchron/
/map:match
So if a uri starts with flow, it is offered to the flow.xmap, which does
the following:
map:pipeline
map:match pattern=flow/*/**
map:redirect-to uri=cocoon:/{1}/flow/{2}/
/map:match
/map:pipeline
I.e. it swaps the first two components in the uri and redirects to itself.
(Some background: we have divided our webapp in publications which can be
recognized by te first name in the uri, flow is used to identify internal
requests originating from flow script (sendPage) and therefore we swap in
order to have the publication name in front again).
This worked with 2.1.6, but with 2.1.8 the redirect is done to the root
sitemap.xmap i.s.o. the current flow.xmap as can be seen from this fragment
of the sitemap log file:
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared
pattern 'flow/*/**' at map:match -
file:/C:/OsrDev/xenopsis/build/webapp/flow.xmap:61:38
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/InvokeContext:
Current Sitemap Parameters:
LEVEL 1
PARAM: '2' VALUE: 'portal/index.html'
PARAM: '0' VALUE: 'flow/xenopsis/portal/index.html'
PARAM: '1' VALUE: 'xenopsis'
INFO (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/RedirectToURINode: Redirecting to
'cocoon:/xenopsis/flow/portal/index.html' at map:redirect-to -
file:/C:/OsrDev/xenopsis/build/webapp/flow.xmap:62:54
INFO (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/ForwardRedirector: Redirecting to
'cocoon:/xenopsis/flow/portal/index.html'
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/EnvironmentWrapper: Setting uri (prefix=null,
uris=xenopsis/flow/portal/index.html)
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared
pattern '**' at map:match -
file:/C:/OsrDev/xenopsis/build/webapp/sitemap.xmap:258:31
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/InvokeContext:
Current Sitemap Parameters:
LEVEL 2
PARAM: '0' VALUE: 'xenopsis/flow/portal/index.html'
PARAM: '1' VALUE: 'xenopsis/flow/portal/index.html'
LEVEL 1
PARAM: '../2' VALUE: 'portal/index.html'
PARAM: '../0' VALUE: 'flow/xenopsis/portal/index.html'
PARAM: '../1' VALUE: 'xenopsis'
I observed the same behaviour for uri's used in sendPage and not starting
with a '/'. They were also redirected to the root sitemap.
I didn't make any modifications in our sitemaps or in our java scripts
during the port. They have been ported unchanged from 2.1.6 to 2.1.8.
What am I doing wrong? Or is this a bug?
Rob Berens
Osirion B.V.
The Netherlands
E-mail: [EMAIL PROTECTED]
--
Antonio
Re: event aware object cache?
On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? Well, I was thinking of registering event awares with that manager so its more up to the components... Then again, if you have multiple jms providers, you might want to listen to a specific topic, or only forward events to a subset of EAs... Its hard to do this kind of thing with lookup IoC. Also, its a tradeoff between configuring the connections between source and sink of the events (e.g. the path between the jms listener and the cache) as roles to look up or as some sort of routing configuration. We could do this by: 1. Letting event awares choose sources/topics to listen to 2. Configuring a name per event source Then, a listener can say, I want to listen to topic foo, no matter where from, or even listen to bar only from source baz and bas. WDYT? Yes, that sounds about right though I haven't fully thought it through. Okay. What about routing tables? Like the one shown under Internet Routing - Internal Routing Tables in [1], we could make a list of routing rules: Source | Topic | Listener - foo| bar | baz means topic bar from source foo should be delivered to listerner baz * | barr | baz baz should also get any message with topic barr from any source foo| * | foolist foolist listens to any topic from source foo foo| bing | *foo distributes any bing message to any listener foobar | * | *foobar distributes any message to any listener * | bang | *bang messages are always delivered to all listeners from any source * | * | bazz bazz listens to any message Gotcha. If you have a need for this now, great - seems like maybe YAGNI would apply otherwise. Now, this table can be configured for the EventAwareManager in cocoon.xconf. I would also add methods such that listeners can add/remove rules, or have some way to do this during runtime in any case. Maybe with an interface using cforms? :D Covers all cases, right? ... Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. I don't really see that problem as you still have to configure which cache to use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of course you need both blocks... I don't really understand the false dependency, can you explain? I thought I had remembered that the EventAware interfaces and implementations were all in the two blocks, but now that I think of it, I guess EventAware itself is in core? I just switched to a new laptop recently and don't even have a local copy of the source on it yet. EventAware, EventAwareCacheImpl, EventRegistry, JMSEventMessageListener, etc are all in the eventcache block. JMSEventMessageListener extends AbstractMessageListener from the jms block. Ah, right (memory's not as bad as I thought). So if you wanted a more generic implementation of an EventAware component that wasn't a Cache or Store, you'd still have to rely on the eventaware cache block, and probably would have a event-based cache set up in your .xconf though you may not need it. No biggie for now. I just don't see how you can use the eventcache or eventaware block without needing the jms block... at least right now. Well, the eventcache block works now without JMS. You can have http-based events (the sample does this). Before my work on this there was (and maybe still is) a commercial cocoon add-on which did something similar using database triggers in Oracle to access URLs to do just this - without JMS. Can't remember the name at the moment. Also, at the time I was also working on a filesytem listener to listen to OS-specific events at the file system level to let you do your uncaching automatically only when files were updated, without polling. IIRC, Windows, Linuxes, and Solaris all supported the basic plumbing to allow this to happen with some native code. So that would just need
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... Source | Topic | Listener - foo| bar | baz means topic bar from source foo should be delivered to listerner baz * | barr | baz baz should also get any message with topic barr from any source foo| * | foolist foolist listens to any topic from source foo foo| bing | *foo distributes any bing message to any listener foobar | * | *foobar distributes any message to any listener * | bang | *bang messages are always delivered to all listeners from any source * | * | bazz bazz listens to any message Gotcha. If you have a need for this now, great - seems like maybe YAGNI would apply otherwise. Yeah.. Had a slight ring of overkill to it... ... Am I ready to roll, then? max I'd say so! Great! I'll keep you posted on my progress :) max
[jira] Geschlossen: (COCOON-1529) I18ntranformation output xmlns:i18n in the first element
[ http://issues.apache.org/jira/browse/COCOON-1529?page=all ] Jörg Heinicke closed COCOON-1529: - Resolution: Invalid So I hope your are ok with closing the bug. Issues with superfluous namespace declarations have to be fixed in the pipeline (if they need to be fixed at all), e.g. by adding an additional transformer or the infamous stylesheet: http://wiki.apache.org/cocoon/RemoveNamespaces. I18ntranformation output xmlns:i18n in the first element - Key: COCOON-1529 URL: http://issues.apache.org/jira/browse/COCOON-1529 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Juan Jose Pablos Assignee: Cocoon Developers Team This is a strage bug. on http://localhost:/samples/i18n/simple.xml around line 183: annotation xmlns:i18n=http://apache.org/cocoon/i18n/2.1; This produces wrong xml output (extra xmlns:i18n attribute). now if you commented out the annotation element then the xmlns:i18n attribute goes to the next element: content xmlns:i18n=http://apache.org/cocoon/i18n/2.1; It looks like it goes to the parent element always. I wish that I could have more information about how to resolve this. -- 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: [zone] keeping copies of the zone's config files
On Sat, 2005-11-19 at 12:05 +0100, Bertrand Delacretaz wrote: I have copied important config files (maybe not all of them, a double-check would be welcome) to the committer's private SVN area, see https://svn.apache.org/repos/private/committers/pmc/cocoon/ cocoon.zones.apache.org/README.txt I've used a simple copy (described in that file) to bring the configs to my local SVN sandbox for committing, this is not optimal but at least we now have a safe copy of those files. I haven't included anything from the Daisy setup, if someone who knows Daisy better than me could do that, please have a look at https://svn.apache.org/repos/private/committers/pmc/cocoon/ cocoon.zones.apache.org/zone-config-files/UPDATING.txt and update accordingly. We do indeed need to look at this, Daisy is currently not being backed up AFAIK (both data config). I might have a look at this some time, but no promises. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: 2.2 Documentation
On Wed, 2005-11-23 at 12:58 +0100, hepabolu wrote: Regarding the documentation of 2.2: Let me first give you some Daisy background to clarify things, before I explain what I have in mind. Note that this is the quick dirty explanation. The Outerthought boys can give a much more detailed overview. Daisy supports sites (the already mentioned Legacy docs and Documentation) and collections. A collection is merely a set of documents and a site can be considered as a view on one or more collections. That's what is currently the case in our Daisy setup in the zones: Collection legacydocs contains all documentation as it was present in the xdocs of BRANCH_2.1.X. Collection documentation contains all new documents that are written in Daisy. Bruno has marked documents part of legacydocs with a two line red warning at the top of the document. You can see this when you open such a page in Daisy. There are already two sites in Daisy: Legacy docs and Documentation. Both use documents from both collections. My idea was this: I've used Legacy docs site to recreate the old cocoon.apache.org site as best as possible. If this is not enough, a little bit of work needs to be done. This site will be restricted to the 2.1 branch. Since Cocoon 2.1 is frozen when it comes to new features, I suggest that the documentation is only updated when some blatant errors or typos are found. For the 2.2 version please use the Documentation site. That's where new documentation is supposed to be entered. This site also contains links to all available documents in the legacydocs collection, see the last line in the navigation bar. This is added for convenience: if you find documentation in the legacydocs that is still valid for the 2.2 version, just move the documentation from the legacydocs collection to the documentation collection. This has no impact on the documentation in the Legacydocs site. I know it's possible that a document resides in both collections, but I want to end up with a collection of legacydocs that holds information that is either completely outdated or only valid for the 2.1 branch. I know we can make branches in Daisy, but at the moment I don't think this is necessary. I'd rather use that feature when we move from 2.2 to 3.0. Are you sure this is unnecessary? The current setup shares the same documents in the new docs and the legacy docs. Thus when the new docs are updated, refactored, retired etc, this influences the legacy docs too. This was fine as long as the legacy docs served exactly for this purpose, but now the legacy docs have turned into the official 2.1.8 documentation. If we don't make a branch for 2.1.8, there's no way the 2.1.x docs can still be produced and maintained in the future. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: 2.2 Documentation
Bruno Dumon wrote: Are you sure this is unnecessary? The current setup shares the same documents in the new docs and the legacy docs. Thus when the new docs are updated, refactored, retired etc, this influences the legacy docs too. This was fine as long as the legacy docs served exactly for this purpose, but now the legacy docs have turned into the official 2.1.8 documentation. If we don't make a branch for 2.1.8, there's no way the 2.1.x docs can still be produced and maintained in the future. Hmm. Currently there is so much crap (i.e. outdated documents or documents describing ideas rather than real implementations) among the documentation in the legacydocs collection, that I'm all for retiring documents in that collection or slightly modifying the ones that are still mostly valid. That would improve the 2.1.8 documentation as well as the 2.2 documentation. OTOH you're right that over time, the documentation of the 2.1 branche would change too, which is unwanted. My suggestion is a temporary solution, a kind of transition phase when 2.1.X is becoming obsolete and 2.2 is taking over. Once the official 2.2 is released, we should create a branch to ensure that 2.1.X is frozen. At that time, we might also decide that there will be no more changes in the 2.1.X documentation at which point they will be removed from Daisy entirely and the only copy resides in the SVN repository. Bye, Helma
[jira] Closed: (COCOON-1363) [Scratchpad] bugs in CookieCreatorAction
[ http://issues.apache.org/jira/browse/COCOON-1363?page=all ] Vadim Gritsenko closed COCOON-1363: --- Fix Version: 2.2-dev (Current SVN) Resolution: Fixed fixed [Scratchpad] bugs in CookieCreatorAction Key: COCOON-1363 URL: http://issues.apache.org/jira/browse/COCOON-1363 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Dean Cording Assignee: Cocoon Developers Team Fix For: 2.2-dev (Current SVN) The documentation regarding cookie maxage parameter is incorrect. maxage shold be set to -1 define a session cookie or to 0 to delete the cookie. The action also returns a null map, which result in anything contained in the action never being run as null is considered an action failure. Should return an empty Map object instead. -- 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-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Vadim Gritsenko closed COCOON-1520: --- Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed The issue is caused by database pool configuration. You should not be using blocking pool without specifying any timeout -- if you want your xsp page execution to finish in this millenium. Please take a look at excalibur docs for pool config, or check out latest src/blocks/databases/conf/datasources.xconf file. Database / avalon problems -- Key: COCOON-1520 URL: http://issues.apache.org/jira/browse/COCOON-1520 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.7 Environment: Operating System: other Platform: PC Reporter: Hugo Marcelino Assignee: Cocoon Developers Team Fix For: 2.1.9-dev (current SVN) Hi developers. My name is Hugo Marcelino, and i come across with this bug. If you setup a connection pool to a database in cocoon.xconf and the connection is not available, you will get the web page working and never terminating, just like it is waiting for an answer. (no timeout). this situation happens if you refresh (ctrl + f5) your page about three times, and at the third time you'll see this happening, but at the first two , it works ok(just doesn't return anything, witch is ok!). This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector For a better cocoon... Hugo Marcelino 31-05-2005 -- 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] Reopened: (COCOON-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Vadim Gritsenko reopened COCOON-1520: - changing resolution Database / avalon problems -- Key: COCOON-1520 URL: http://issues.apache.org/jira/browse/COCOON-1520 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.7 Environment: Operating System: other Platform: PC Reporter: Hugo Marcelino Assignee: Cocoon Developers Team Fix For: 2.1.9-dev (current SVN) Hi developers. My name is Hugo Marcelino, and i come across with this bug. If you setup a connection pool to a database in cocoon.xconf and the connection is not available, you will get the web page working and never terminating, just like it is waiting for an answer. (no timeout). this situation happens if you refresh (ctrl + f5) your page about three times, and at the third time you'll see this happening, but at the first two , it works ok(just doesn't return anything, witch is ok!). This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector For a better cocoon... Hugo Marcelino 31-05-2005 -- 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-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Vadim Gritsenko closed COCOON-1520: --- Resolution: Won't Fix Database / avalon problems -- Key: COCOON-1520 URL: http://issues.apache.org/jira/browse/COCOON-1520 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.7 Environment: Operating System: other Platform: PC Reporter: Hugo Marcelino Assignee: Cocoon Developers Team Fix For: 2.1.9-dev (current SVN) Hi developers. My name is Hugo Marcelino, and i come across with this bug. If you setup a connection pool to a database in cocoon.xconf and the connection is not available, you will get the web page working and never terminating, just like it is waiting for an answer. (no timeout). this situation happens if you refresh (ctrl + f5) your page about three times, and at the third time you'll see this happening, but at the first two , it works ok(just doesn't return anything, witch is ok!). This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector For a better cocoon... Hugo Marcelino 31-05-2005 -- 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-1694) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ] Pier Fumagalli updated COCOON-1694: --- Attachment: (was: patch.txt) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore --- Key: COCOON-1694 URL: http://issues.apache.org/jira/browse/COCOON-1694 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Every time Cocoon is shut down, I can see this exception: [2005/11/22 21:38:34.063] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose(EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) Any clue about what's going on? -- 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-1694) Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ] Pier Fumagalli updated COCOON-1694: --- Attachment: patch.txt The previous patch wouldn't have fixed the problem in all cases: a race condition might have occurred between checking the status, and actually shutting down the CacheManager. This patch synchronizes on the Cache instance and prevents this from happening. Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore --- Key: COCOON-1694 URL: http://issues.apache.org/jira/browse/COCOON-1694 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Attachments: patch.txt Every time Cocoon is shut down, I can see this exception: [2005/11/22 21:38:34.063] WARN [manager] Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore java.lang.IllegalStateException: The cocoon-ehcache-1 Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:713) at net.sf.ehcache.Cache.dispose(Cache.java:618) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:382) at org.apache.cocoon.components.store.impl.EHDefaultStore.dispose(EHDefaultStore.java:229) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(DefaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(ThreadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(ExcaliburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentManager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:536) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1554) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:518) at org.mortbay.jetty.servlet.ServletHolder.stop(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.ServletHttpContext.doStop(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.http.HttpContext.stop(Unknown Source) at org.mortbay.http.HttpServer.doStop(Unknown Source) at org.mortbay.util.Container.stop(Unknown Source) at org.mortbay.jetty.Server$ShutdownHookThread.run(Unknown Source) Any clue about what's going on? -- 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-1697) Allow request parameters to be used in for (var k in h) kind of Javascript Loops
Allow request parameters to be used in for (var k in h) kind of Javascript
Loops
--
Key: COCOON-1697
URL: http://issues.apache.org/jira/browse/COCOON-1697
Project: Cocoon
Type: Improvement
Components: - Flowscript, * Cocoon Core
Versions: 2.1.8
Reporter: Pier Fumagalli
Priority: Minor
Attachments: patch.txt
As far as I can see, in the cocoon object passed to the flow environment, I
always have to access the request parameter names and all values as Java
Enumeration(s), therefore, I can't use the for (var name in array) kind of
loop.
All I want to do is something extremely simple, like this:
for (var name in cocoon.request.parameters) {
print(PARAMETER - + name);
print(VALUE - + cocoon.request.parameters[name]);
print( LENGTH - + cocoon.request.parameters[name].length);
for (var position in cocoon.request.parameters[name]) {
var value = cocoon.request.parameters[name][position];
print ( @[ + position + ] = + value);
}
}
Apparently, but I might have overlooked something, there's currently no way of
doing this.
I've created a simple patch, that allows the above mentioned flowscript to work.
--
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: Planning 2.2
On 23.11.2005 16:33, Antonio Fiol Bonnín wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. Jörg
Re: Planning 2.2
Antonio Fiol Bonnín wrote: replaceregexp byline=true regexp pattern=\*([EMAIL PROTECTED])/ substitution expression=*/ fileset dir=. includes=**/*.java / /replaceregexp This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. I'ld say just give it a spin on a checked out copy of trunk, then have a look at the diff. It should be fairly easy to spot if things went wrong. Now i'm not sure if we wanted to collect all removed authors as well, my memory is failing me :( It might make the task a bit more interesting though ;) Jorg
Re: [jira] Geschlossen: (COCOON-1529) I18ntranformation output xmlns:i18n in the first element
Jörg Heinicke (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1529?page=all ] Jörg Heinicke closed COCOON-1529: - Resolution: Invalid So I hope your are ok with closing the bug. Issues with superfluous namespace declarations have to be fixed in the pipeline (if they need to be fixed at all), e.g. by adding an additional transformer or the infamous stylesheet: http://wiki.apache.org/cocoon/RemoveNamespaces. Hey, I am a bit lost here with this bug, are you saying that from: foo to foo xmlns:i18n=http://apache.org/cocoon/i18n/2.1; after a transformation is not a bug?
Re: Planning 2.2
On 11/23/05, Jorg Heymans [EMAIL PROTECTED] wrote: Antonio Fiol Bonnín wrote: replaceregexp byline=true regexp pattern=\*([EMAIL PROTECTED])/ substitution expression=*/ fileset dir=. includes=**/*.java / /replaceregexp This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. I'ld say just give it a spin on a checked out copy of trunk, then have a look at the diff. It should be fairly easy to spot if things went wrong. Now i'm not sure if we wanted to collect all removed authors as well, my memory is failing me :( It might make the task a bit more interesting though ;) If you do the diff would give them to you on one nice single spot :-) -- Peter Hunsberger
author tags (Was: Planning 2.2)
Joerg Heinicke wrote: Antonio Fiol Bonn?n wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. Exactly. If it was an easy job, then we would have done it by now. There is discussion in the archives about how the attribution should be done. One suggestion was adding to the status.xml file so that they get listed at the changes.html page. Another suggestion was a contrib type file. http://search.gmane.org/?query=author+tagsemail=group=gmane.text.xml.cocoon.devel ... as you can see there is lots of discussion. There were various votes and polls. Here is one: http://thread.gmane.org/gmane.text.xml.cocoon.devel/34114 -David
Re: author tags (Was: Planning 2.2)
David Crossley wrote: Joerg Heinicke wrote: Antonio Fiol Bonn?n wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. Exactly. If it was an easy job, then we would have done it by now. There is discussion in the archives about how the attribution should be done. One suggestion was adding to the status.xml file so that they get listed at the changes.html page. Another suggestion was a contrib type file. Status.xml already supports authors: developers !-- in fifo order -- person name=Stefano Mazzocchiemail=[EMAIL PROTECTED] id=SM / person name=Sam Ruby email=[EMAIL PROTECTED] id=SR / It's a small job to modify the Forrest projectInfo plugin to render these in changes or any other location. I want to do a little work on that plugin anyway so that the sorting of actions can be turned off (i.e. display them chronologically), I can do this at the same time. Ross
Re: author tags (Was: Planning 2.2)
Ross Gardler wrote: David Crossley wrote: Joerg Heinicke wrote: Antonio Fiol Bonn?n wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. Exactly. If it was an easy job, then we would have done it by now. There is discussion in the archives about how the attribution should be done. One suggestion was adding to the status.xml file so that they get listed at the changes.html page. Another suggestion was a contrib type file. Status.xml already supports authors: developers !-- in fifo order -- person name=Stefano Mazzocchiemail=[EMAIL PROTECTED] id=SM / person name=Sam Ruby email=[EMAIL PROTECTED] id=SR / It's a small job to modify the Forrest projectInfo plugin to render these in changes or any other location. That is not what i was referring to. Rather i meant the attribute due-to=Donald Duck. The contributor is not always a committer. It is just a matter of making sure that there is an entry for each major contribution. -David I want to do a little work on that plugin anyway so that the sorting of actions can be turned off (i.e. display them chronologically), I can do this at the same time. Ross
