Re: Update to util.concurrent 1.3.3
On 28 Feb 2004, at 02:36, Antonio Gallardo wrote: Hi: Another needed to be updated is util.concurrent: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ intro.html Look at the bottom of the release history. ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Configuration of own roles in external file?
Hello, long long time ago I had heard that own roles can be configured in a separate config file. But I have forgotten which structure this file must have and how to set the path to this file. The only thing I know is there was an attribuite in cocoon/ of cocoon.xconf to set the path, but which? Maybe roles=... ? Thank you. Regards
Re: Configuration of own roles in external file?
Stephan Coboos wrote: Hello, long long time ago I had heard that own roles can be configured in a separate config file. But I have forgotten which structure this file must have and how to set the path to this file. The only thing I know is there was an attribuite in cocoon/ of cocoon.xconf to set the path, but which? Maybe roles=... ? *cocoon* *user*-*roles*=WEB-INF/myroles.xconf Regards, Upayavira
Re: Configuration of own roles in external file?
Upayavira wrote: Stephan Coboos wrote: Hello, long long time ago I had heard that own roles can be configured in a separate config file. But I have forgotten which structure this file must have and how to set the path to this file. The only thing I know is there was an attribuite in cocoon/ of cocoon.xconf to set the path, but which? Maybe roles=... ? *cocoon* *user*-*roles*=WEB-INF/myroles.xconf Regards, Upayavira Ahh yes. Thank you. Which structure must myroles.xconf have? This: user-roles component .../ /user-roles Thank you. Regards
qdox block broken (was: cvs commit: cocoon-2.1/legal LICENSE.quartz)
Le Samedi, 28 fév 2004, à 05:23 Europe/Zurich, [EMAIL PROTECTED] a écrit : Added: src/blocks/qdox/lib qdox-1.3.jar src/blocks/cron/lib quartz-1.3.2.jar Removed: src/blocks/qdox/lib qdox-1.2.jar src/blocks/cron/lib quartz-1.2.3.jar Antonio, did you check the qdox block samples after updating the qdox jar? They fail here (macosx, JDK 1.4.1) with the current CVS: http://localhost:/samples/qdox/javadoc/java.util.HashMap fails with java.lang.NullPointerException at org.apache.cocoon.components.source.impl.QDoxSource.outputInheritStartEl ement(QDoxSource.java:1023) at org.apache.cocoon.components.source.impl.QDoxSource.outputClassInheritan ce(QDoxSource.java:562) -Bertrand
RE: [Avalon][PMC:VOTE/Release] Check 'em out!
+1 for release I just updated our Cocoon versions to the jars you provided and the first (quick) tests are successful. There is a minor incompatibility in excalibur-logger between the version we used and the new one, but that's obviously our problem and I fixed this. So, I think the release candidates are fine! Many thanks, Leo! Carsten -Original Message- From: Leo Sutic [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 12:19 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Avalon][PMC:VOTE/Release] Check 'em out! AVALON PMC MEMBERS == The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and vote for release: +1 from me. I'd like to have this vote done by the end of today, since that means I can release them without having to worry about the license change. COCOON DEVELOPERS = The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and let me know if there are any immediate issues. /LS
RE: Update to util.concurrent 1.3.3
Where do you need help? Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Saturday, February 28, 2004 2:37 AM To: [EMAIL PROTECTED] Subject: Update to util.concurrent 1.3.3 Hi: Another needed to be updated is util.concurrent: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/conc urrent/intro.html Please help. Best Regards, Antonio Gallardo
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception [EMAIL PROTECTED] changed: What|Removed |Added Version|2.1.3 |Current CVS 2.0 --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 11:21 --- I've been able to reproduce the problem with the current CVS version. Did not happen when committing a minimal sitemap (request generator + xml serializer), I had to take the exact same application tree that ran under cocoon-2.1rc2-dev in my app. Here's the scenario, I'll attach the logs if someone wants to analyze them: 1. empty all logs, set all logs to DEBUG 2. start Cocoon, make a request (with pass1=true so it can be found in the logs), request processed ok 3. make some change to the sitemap (in XML comments) 4. request with pass2=true, ok 5. commit sitemap changes to my CVS 6. request with pass3=true, get disposed ComponentLocator exception 7. add one space to sitemap after ?xml...? to cause it to reload 8. request with pass4=true, ok So the problem exists in the current CVS. It's no big deal as such but probably hides something else.
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 11:22 --- Created an attachment (id=10604) Complete DEBUG logs of the above scenario
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 11:24 --- Note also that when the problem happens it persists after a restart of Cocoon, even if I delete /tmp/Jetty____/. Only editing the sitemap makes it go away. I'm doing all these tests with Jetty, ./cocoon.sh servlet, macosx, JDK 1.4.1
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 11:30 --- Next attachment is a smaller log, where just one request after startup causes the problem (which was present before stopping Cocoon). /tmp/Jetty____/ was deleted before restart. Should be the smallest set of log messages where the problem happens.
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 11:31 --- Created an attachment (id=10605) smaller DEBUG log, where error happens on first request after restart
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 12:48 --- Bertrand, 1 Did you really mean to change to current _2.0_ for this bug? 2 Are you using eclipse (for cvs commit)? Geoff
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception [EMAIL PROTECTED] changed: What|Removed |Added Version|Current CVS 2.0 |Current CVS 2.1 --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 13:20 --- 1 Did you really mean to change to current _2.0_ for this bug? Sorry no, fixed it 2 Are you using eclipse (for cvs commit)? No, command-line CVS. But I haven't been able to reproduce the problem with simple sitemaps, for now I only see it in my application. In the meantime I have added log messages to the CocoonComponentManager, which show the problem: IIUC the sitemap component manager is disposed, and later on AbstractEnvironment calls lookup() on this disposed manager, causing the ExcaliburComponentManager to complain. The attached logs show the problem, search for CocoonComponentManager.dispose in sitemap.log (next attachment log with additional CCM messages) I don't know enough about CocoonComponentManager to go further - either it is disposed at the wrong time, or its sourceResolver should not be set to null in dispose(). The relation to the CVS commit is still a mystery though, but the above failure scenario with CVS works every time here ;-)
DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249 You cannot lookup components on a disposed ComponentLocator exception --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 13:22 --- Created an attachment (id=10606) Logs with additional CCM messages, show the dispose() problem
RE: [Avalon][PMC:VOTE/Release] Check 'em out!
There is one problem with the release, the licence is not correct in some files. The correct name is The Apache Software Foundation and not just Apache Software Foundation. I'm just in the process of updating the CVS. Carsten -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Saturday, February 28, 2004 12:11 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Avalon][PMC:VOTE/Release] Check 'em out! +1 for release I just updated our Cocoon versions to the jars you provided and the first (quick) tests are successful. There is a minor incompatibility in excalibur-logger between the version we used and the new one, but that's obviously our problem and I fixed this. So, I think the release candidates are fine! Many thanks, Leo! Carsten -Original Message- From: Leo Sutic [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 12:19 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Avalon][PMC:VOTE/Release] Check 'em out! AVALON PMC MEMBERS == The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and vote for release: +1 from me. I'd like to have this vote done by the end of today, since that means I can release them without having to worry about the license change. COCOON DEVELOPERS = The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and let me know if there are any immediate issues. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FORMS]
Hi all, I'm working on bidirectional AggregateField - meaning, it will allow to have one value in a backend model, splitted to the several on the form, or vice versa. This field is needed in many common scenarios such as telephone entry fields represented as [ ] - [ ] - [] x [] on the form, and should obviously go into one database field as 999-999-x; or date entry fileds, where day / month / year are select boxes, and in the back end it is one value. I do not have examples for the other direction, but because it was already supported by AggregateField, I'll leave this functionality in. Objections? Vadim
DO NOT REPLY [Bug 27165] - Chaperon wiki syntax: italic inside bullet point closes bullet point
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27165 Chaperon wiki syntax: italic inside bullet point closes bullet point [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 14:51 --- The problem is that the grammar ambiguous, like most grammars. In cases of ambiguities a deterministic parser select only one action of several actions. Such cases are called shift/reduce and reduce/reduce conflicts. These conflicts can most resolved by priorities and associativities. In your case I rearrange the priorities of the terminals.
Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)
Am Fr, den 27.02.2004 schrieb Tim Larson um 16:25: On Fri, Feb 27, 2004 at 11:33:32AM +0100, Dirk-Willem van Gulik wrote: On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote: I don't think the ASF should discourage developers from keeping useful metadata about the code inside the source files. What better place to put the metadata than in the code? This makes it more likely to be used and kept up to date than if it was stored somewhere else, IMHO. One way to look at this is that @author tags are in a way factually 'wrong'; in most cases it just signals which person wrote the first skeleton of that code; but subsequently it was fixes, peer-reviewed and looked at by a whole community. Also do not forget the many people in your community which help with QA, Documentation, user-feedback and so on. To put one person in the (hot) seat for what is essentially a group effort is not quite right. Looking through the CVS logs of a few tomcat files: each block of 30 lines seems to have had commits of at least 5 persons; with a median of 6 and an average of 9. The average number of @author tags on those arbitrary blocks is about 0.5. And that is not counting QA, docs, suggestions of mailing lists, bug resolutions, user support. I.e. those things which make tomcat such a great supported product. Searching the CVS logs for an author is nonsense, since the history get lost if we move the files around or create new repositories, like we do in the past. And the CHANGES are not really complete. Using AUTHOR tags in the source files is a good practice, IMHO. -1, Stephan.
Re: [RT] Cocoon Input Model
I agree that more sophisticated input handing would make general web applications much easier to write in Cocoon... here are some more random thoughts on the subject: Input can come from many sources: - http query string - http post stream - http cookie - user session object (from disk? database?) - raw socket? - any of the above interpreted as XML The purpose of input handing should be to massage and validate data sent over HTTP to something that you can confidently hand over to a strongly typed business object. Here are some of the things that, in my experience, this usually amounts to: - required value checking - datatype checking and casting (is it a date? then make it a j.u.Date) - min/max string length or value checking - value formatting - database value checking (is that state_id the user sent really in my table of states?) - hash check of fields (to verify the data has not been modified over the round trip -- does this hash match the hash of these other fields?) - converting the value of a single field, or the entire input stream, to XML - decrypting of a single field into multiple fields (and then apply the above to the decrypted fields) This, of course, sounds a whole lot like forms processing, and I don't see any reason why it shouldn't be handled by cforms. The input pipeline would look something like: 1. A deserializer component is used to convert the raw input into XML. A deserializer component would be mated to each type of input -- for example, the HTTPDeserializer would turn HTTP headers into a simple XML document (or just selected parts of the header based on a parameter). 2. More than one deserializer could be employed for a particular request -- the result would be aggregated into a single document. 3. cforms validation 4. transformations** 5. either make result XML available as input to a pipeline (as a generator) or bind to a Java object for use in an action/flow/jxtemplate. ** Including transformation steps in this pipeline might seem like overkill, however I would find it very useful. If the user sends an ID, a SQLTransformer here could be used to convert that ID into more information from the database. This is _not_ the same as using a SQLTransformer in the output pipeline since we want to be able to access this data from flow through the Java object produced in step 5. Now where does this belong in the sitemap? I think these input pipelines should be separate from the main pipelines, and be called similar to the way actions do: map:input-pipeline name=orders map:aggregate map:generate type=httpdeserializer map:parameter name=query value=customerid,orderid/ /map:generate map:transform type=sql/ map:serialize type=object/ /map:input-pipeline ... map:pipeline match=/orders map:input name=orders/ map:generate type=jx/ map:transform orders.xslt/ map:serialize/ /map:pipleline ~~ Of course, this also opens a lot of questions on how cforms is integrated into cocoon... and where do input pipelines end and where output pipelines begin? cheers, -steve
Re: Configuration of own roles in external file?
Stephan Coboos wrote: Upayavira wrote: Stephan Coboos wrote: Hello, long long time ago I had heard that own roles can be configured in a separate config file. But I have forgotten which structure this file must have and how to set the path to this file. The only thing I know is there was an attribuite in cocoon/ of cocoon.xconf to set the path, but which? Maybe roles=... ? *cocoon* *user*-*roles*=WEB-INF/myroles.xconf Regards, Upayavira Ahh yes. Thank you. Which structure must myroles.xconf have? This: user-roles component .../ /user-roles Same as cocoon.roles, IIUC. Upayavira
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Thanks for the info. I tried replacing the Cocoon jars: batik-all-1.5.jar fop-0.20.5.jar with the FOP 0.20.5 jars (fop.jar batik.jar) in that case no SVG is rendered at all because there is a problem with use and url(#), even though the reference is resolved within the same svg element (and resolves correctly when using FOP standalone...must be relying on different behavior than the Cocoon URI resolving provides?). If I just try to use the FOP version of Batik (Cocoon fop-0.20.5.jar) I get a No Such Method in Batik. java.lang.NoSuchMethodError: org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/parser/UnitProcessor$Context; So it looks like Cocoon's version of FOP is using a different (newer?) version of Batik. But that raises the question, was the Cocoon version of FOP taken from CVS and is really post 0.20.5 release? I also tried with the maintenance branch CVS head of FOP with no difference. I think I'll look into writing a Serializer that invokes the standalone FOP as though it was an external program so I can pickup the versions of FOP/Batik I need to make this work. Thanks for your help, Steve From: J.Pietschmann Torsten Curdt wrote: Can anyone tell me how the Cocoon fop and batik jar files are generated and how that is different from the jars supplied with FOP? THere were some Cocoon releases which shipped with a different Batik jar than the corresponding FOP release, partly due to interface changes in Batik which forced FOP to use a CVS snapshot. I don't know of the current state, but the latest Batik was released after the latest FOP release, if Cocoon grabbed the latest Batik jar, there are certainly some differences. _ Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
Re: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license
[EMAIL PROTECTED] wrote: Start placing license next to the jars. This enables us - to check which licenses are missing - to write tools to check this - to easily update a license of a jar if the license changes But does it make any sense? I don't see it. legal/ was much more elegant - and user friendly. PS cvs up, clean build, localhost:, result: Message: Lookup of serializer 'html' failed at file:/C:/Work/OCTOWorkspace/cocoon-2.1/build/webapp/sitemap.xmap:781:45 Cause: org.apache.avalon.framework.configuration.ConfigurationException: No value is associated with the configuration element cdata-section-elements at file:/C:/Work/OCTOWorkspace/cocoon-2.1/build/webapp/sitemap.xmap:212:182 What could be the reason? Vadim
RE: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license
PS cvs up, clean build, localhost:, result: Message: Lookup of serializer 'html' failed at file:/C:/Work/OCTOWorkspace/cocoon-2.1/build/webapp/sitemap.xm ap:781:45 Cause: org.apache.avalon.framework.configuration.ConfigurationException: No value is associated with the configuration element cdata-section-elements at file:/C:/Work/OCTOWorkspace/cocoon-2.1/build/webapp/sitemap.xm ap:212:182 I guess it's the update to avalon framework 4.1.5. Strange... Carsten
Licenses of Libraries [was Re: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license]
Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: Start placing license next to the jars. This enables us - to check which licenses are missing - to write tools to check this - to easily update a license of a jar if the license changes But does it make any sense? Sure :) I don't see it. legal/ was much more elegant - and user friendly. Was it? It seems that it is more user friendly but I think it's not. How do you know, which libraries we have are covered by licenses in the legal/ directory and which library is coverd by which file? E.g. if you have an excalibur.*.jar or a commons-*.jar, how can you see that this is covered by the LICENSE.Avalon resp. the for jakarta commons? Even worse with the next releases of Apache projects, they use the new 2.0 license, so in the case of Avalon you have subprojects that have been released with the old and others that have been released with the new one. THen you need a way to tell which library uses what license. There was the strong feeling in the pmc list days ago that we need a tool to check if every lib in our cvs is covered by a license. With the current structure, this is impossible. So, we need one license file per library and the easiest way is to give it the same name as the library itself. So, checking is easy. And we saw (with JISP, but also with the ASF projects changing to 2.0) that licenses for a project change. I bet that usually we only update the jar file but never touch the license that our stored somewhere else. WIth this approach, you have at least to rename the license and this should help in keeping the license upto date. This has discussed a while ago I think on the committers list (or somewhere else) and the output was that each jar should have the license directly next to the jar. I mentioned this days ago on the PMC list and noone disagreed, so... :) Ok, I really thing that we need a license file per lib. Otherwhise tracking is impossible. And giving this file the same name as the jar (including version) makes imho sense as well. If these are stored in the /legal directly or right next to the jars is imho not so important. WDYT? Carsten
RE: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license
Carsten Ziegeler [mailto:[EMAIL PROTECTED] PS cvs up, clean build, localhost:, result: Message: Lookup of serializer 'html' failed at file:/C:/Work/OCTOWorkspace/cocoon-2.1/build/webapp/sitemap.xm ap:781:45 Cause: org.apache.avalon.framework.configuration.ConfigurationException: No value is associated with the configuration element cdata-section-elements at file:/C:/Work/OCTOWorkspace/cocoon-2.1/build/webapp/sitemap.xm ap:212:182 I guess it's the update to avalon framework 4.1.5. Strange... Ok, got it: there is an incompatible change between 4.1.4 and 4.1.5 in the DefaultConfiguration implementation :( If you do a getChild(xyx) for a Configuration if the child does not exist it is created new. In this case the child got until 4.1.4 the location - which is tested in some serializers. With 4.1.5 the location is generated* :( So, I think our assumption that the location is always - if the child has been created new is wrong and we have to change our code... Carsten
RE: Update to util.concurrent 1.3.3
Carsten Ziegeler dijo: Where do you need help? Can I compile for JSDK 1.3 with JSDK 1.4.2? I am not sure if this is posible. Best Regards, Antonio Gallardo Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Saturday, February 28, 2004 2:37 AM To: [EMAIL PROTECTED] Subject: Update to util.concurrent 1.3.3 Hi: Another needed to be updated is util.concurrent: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/conc urrent/intro.html Please help. Best Regards, Antonio Gallardo
[ANN] GUIapplication for Offline Processing
Dear Cocoon community, I want today announce my small GUIapplication, which uses the CocoonBean. I started for developing a small OfflineCMS with cocoon-inside. During working with the OpenOfficeBean (only available for Windows and Linux/Unix) and the nessecity to use dynamic classloading, i got the idea to try it with CocoonBean too. After getting a friendly hint from Upayavira to announce here and look if there is some interest. I have setup a small page with some documentation and binary and source-packages. the url: http://www.mieth-xml.de/openproject/cligui/ It is not a stable release yet and currently my OpenOfficePlugin is broken in some cases under Windows. A workaround is *dont* use Quit from OpenOffice File-menu, otherwise OO and the application hangs and the TaskManager will be your friend. :-( It is more a snapshot of what I'm doing, but it can simple launch Cocoon for Offline generation. Only open the cli.xconf from a Cocoon-distribution and hit process. Best Regards and Thanx again to Upayavira, Simon pure-OT After breaking my OpenOfficePlugin and searching for days, where I shot self in the foot. I'm feeling like this guy from this short movie ;-) (3 MB) http://files.purempegs.com/files/aliensong.mpeg /pure-OT
Re: [JXTemplate] weird problem w/ formatDate
I'm unable to recreate this problem. Can you provide more information?
--
Chris
Mark Lundquist wrote:
Hi,
(I'm using Cocoon 2.1.3...)
I have something like this in a JXTemplate:
jx:formatDate value=${theDate} /
and it barfs:
Cannot format given Object as a Date
But if I change the template to
jx:out value=${theDate} /
...then I get this:
Fri Feb 27 15:47:51 PST 2004
!!?!?!?! Clearly this /is/ a Java Date object...
Not only that, but...
There are a number of places where dates have to display on this page.
I don't have a real model yet, so for right now I'm just prototyping
the VC of my MVC :-), using flow and JXTemplate, with mockup data
hardcoded in the flowscript. So anyway currently all the date
objects that get passed in (via the context object passed to
sendPageAndWait) are the identical object. In the flowscript:
var now = new Packages.java.util.Date();
So they're /all/ 'now' (once again, intentionally), but some of the
'nows' JXTemplate chokes on, and some of them it's fine!
So... here's what I tried next:
1) Created my own Java.text.DateFormat object in the flowscript, and
used it to format all my dates there
2) Changed the JXTemplate to use jx:out to interpolate all my date
displays, since they are now strings at this point.
The result: nice dates, no problem.
Mark
Author Tags, Re: cvs commit: cocoon-2.1/src/blocks/woody/conf woody-expression.xconf
[EMAIL PROTECTED] wrote: * @author a href=http://cocoon.apache.org/;The Apache Cocoon Team/a Is this what we want? I think it's not necessary to have mail list address there, and that link to the website is enough. Thoughts? Vadim
Re: Author Tags, Re: cvs commit: cocoon-2.1/src/blocks/woody/conf woody-expression.xconf
Vadim Gritsenko dijo: [EMAIL PROTECTED] wrote: * @author a href=http://cocoon.apache.org/;The Apache Cocoon Team/a Is this what we want? I think it's not necessary to have mail list address there, and that link to the website is enough. Thoughts? As a side efect: Mail addresses there are used mainly for spam purposes. Best Regards, Antonio Gallardo. Vadim
Re: Licenses of Libraries [was Re: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license]
Carsten Ziegeler wrote: Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: Start placing license next to the jars. This enables us - to check which licenses are missing - to write tools to check this - to easily update a license of a jar if the license changes But does it make any sense? Sure :) I don't see it. legal/ was much more elegant - and user friendly. Was it? It seems that it is more user friendly but I think it's not. How do you know, which libraries we have are covered by licenses in the legal/ directory I had not said anything about dev-friendly :-) and which library is coverd by which file? E.g. if you have an excalibur.*.jar or a commons-*.jar, how can you see that this is covered by the LICENSE.Avalon resp. the for jakarta commons? I would expect LICENSE.excalibur and LICENSE.commons files to be in legal/ Alternatively, jars should be named avalon-excalibur-*; so there would be no place for ambiguity, one way or another. Even worse with the next releases of Apache projects, they use the new 2.0 license, so in the case of Avalon you have subprojects that have been released with the old and others that have been released with the new one. THen you need a way to tell which library uses what license. Well, this is transient issue. But I'd expect all excalibur-* libraries to be re-released with license v2 more or less simulteneously. There was the strong feeling in the pmc list days ago that we (and we had strong feelings against it as well) need a tool to check if every lib in our cvs is covered by a license. With the current structure, this is impossible. Possible, if license file starts with (LICENSE.excalibur) or ends with (excalibur.LICENSE) beginning of the JAR file name (excalibur-bla-bla-bla). So, we need one license file per library and the easiest way is to give it the same name as the library itself. So, checking is easy. One license per project is more appropriate, and checking is still possible. And we saw (with JISP, but also with the ASF projects changing to 2.0) that licenses for a project change. I bet that usually we only update the jar file but never touch the license that our stored somewhere else. WIth this approach, you have at least to rename the license and this should help in keeping the license upto date. But from the users POV, licenses are all spread across module - instead of one (convinient) location. This has discussed a while ago I think on the committers list (or somewhere else) and the output was that each jar should have the license directly next to the jar. I mentioned this days ago on the PMC list and noone disagreed, so... :) Oops. Did I miss my chance? Ok, I really thing that we need a license file per lib. Otherwhise tracking is impossible. And giving this file the same name as the jar (including version) makes imho sense as well. If these are stored in the /legal directly or right next to the jars is imho not so important. Well, it's really not so important; I guess it's matter of taste. Vadim
Re: Author Tags, Re: cvs commit: cocoon-2.1/src/blocks/woody/conf woody-expression.xconf
Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: * @author a href=http://cocoon.apache.org/;The Apache Cocoon Team/a Is this what we want? I think it's not necessary to have mail list address there, and that link to the website is enough. Thoughts? People, let's not be silly. It's obvious that if its in our database it's our stuff! Even for documents, just remove the entire authorship and let's move on. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: qdox block broken
Hi Bertrand:
I checked it. The problem seems again to be related to getJavaClass(String
className) method returnig null at line 778. Seems like another problem
with the source resolver URI:
At line 749-755 there is:
JavaClass jClass = null;
SourceResolver resolver = null;
try {
resolver = (SourceResolver) manager.lookup(SourceResolver.ROLE);
Source source = resolver.resolveURI(javadoc: + className);
if (source instanceof QDoxSource) {
The if-condition is false (not success) and the code inside the
if-block not run. This code use QDocSource to parse the javaclass.Because
the code is not called, then the getJavaClass() method return null. This
happen while resolving the java.util.Map class. After this happen we see
the error page.
AFAIK, this is not a problem of the new library, but a problem related to
resolver.resolveURI that does not return the right type (QDoxSource).
Is this correct?
I wonder if the code worked before the update. Can someone confirm if the
qdox block worked before with qdox.jar 1.2? (Cocoon 2.1.4 for example).
Best Regards,
Antonio Gallardo
Re: qdox block broken (was: cvs commit: cocoon-2.1/legal LICENSE.quartz)
Hi Bertrand: It is fixed in the CVS. The error was not related to the qdox.jar 1.3. Please cross check. Best Regards, Antonio Gallardo
Re: [Avalon][PMC:VOTE/Release] Check 'em out!
Couple of nitpicks: excalibur-logger-1.1-src.(tar.gz|zip) doesn't actually contain the sources... avalon-fortress-tools-1.1.jar still contains some test-cases (org/apache/avalon/fortress/testcase/FortressTestCase.class) avalon/fortress/container/impl/extensions/package.html avalon/fortress/container/impl/factory/package.html JavaDoc complains and generates 2 errors Body tag missing from HTML On a related item... Can the excalibur-instrument-manager-1.0.jar split up in two? It contains references to the AltRMI project, which is in incubation, without any release, and so on and so forth... I'm trying to do a clean build from all released sources, and for the Avalon/Fortress/Excalibur core that's the only thing I require but that doesn't have a release... I know it's stupid, and that it's not even used, but that's the only thing that somehow sneaks in and makes us depend on something which doesn't have a release (if you wanted to build world from sources) By the way, if someone wants to take a look at the javadoc for Avalon/Fortress/Excalibur and related friends, here are all 45 megabytes: http://www.betaversion.org/~pier/avalon/ And I'm starting to get scared as this is bigger than J2EE :-) Pier On 27 Feb 2004, at 11:19, Leo Sutic wrote: AVALON PMC MEMBERS == The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and vote for release: +1 from me. I'd like to have this vote done by the end of today, since that means I can release them without having to worry about the license change. COCOON DEVELOPERS = The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and let me know if there are any immediate issues. /LS
