Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed
of the deprecated features they use (in the case of Javascript,
there's no compiler warning like in Java).
That would make a new log file (e.g. deprecated.log), but IMO that
one deserves to exist.
Yes, and we should really try to add *all* deprecated log messages
there.
And punish those that fail to use it once it's in place ;-)
Where can we put that deprecation logger? What comes to mind is
either the Avalon Context, or a component, i.e. lookup(Logger.ROLE +
deprecated).
WDYT?
I think this should be as simple as possible. What about a static
accessor, e.g. on the Core object? You might want to use this logger
where you don't want to either implement Serviceable nor
Contextualizable, so imho it should be easier.
Yeah, I thought about a static accessor also, but I'm fearing some
problems with classloading. Well, if any such problem arises, we'll be
able to solve it withing the accessor's code.
So let's go for Cocoon.getDeprecationLogger().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: Thinking further, I don't think we should attach this to the Cocoon object as we may want to use this in classes also used outside the Cocoon machinery. Outside the Cocoon machinery? What do you mean by this? So what about a dedicated o.a.c.util.Deprecation class? Sylvain -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Hmm... the problems is that cocoon.request.blah was released and maybe is used is used (by us and other people?) in a lot of places and maybe other peopl! :-( Sorry for peecking into this post but till today I thought cocoon.request.blah was a normal call, and seemed quite natural ;) in a users perspective. I do use it massively. So the correct way of doing this would be cocoon.request.getParameter(blah) then ? before it blows off with 2.2 Thanks Tibor
FYI: javaflow can potentially be serialized
Just a short head up... as you know I moved the a javaflow implementation over to jakarta commons. http://jakarta.apache.org/commons/sandbox/javaflow/ I did a couple of API changes... http://vafer.org/blog/tcurdt/archives/000179.html So now the latest trunk version supports continuation serialization. This does not yet apply to the cocoon javaflow because our continuation management machinery also would need to support persistence. But although there are some restrictions and (of course) some work left... at least the testcases show green now :) Enjoy! -- Torsten signature.asc Description: OpenPGP digital signature
[GUMP@brutus]: Project cocoon-block-scratchpad (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-scratchpad has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 2 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-mail : Java XML Framework - cocoon-block-scratchpad : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-scratchpad/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [scratchpad-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://brutus.apache.org/gump/public/cocoon/cocoon-block-scratchpad/gump_work/build_cocoon_cocoon-block-scratchpad.html Work Name: build_cocoon_cocoon-block-scratchpad (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=10022005 -Dblock-name=scratchpad gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
Outside the Cocoon machinery? What do you mean by this?
I mean not tied to a class that provides other features than deprecation
logging. And the Cocoon class provides so much more ;-)
Hence the specific Deprecation class below, which will of course be in
the org.apache.cocoon package hierarchy.
So what about a dedicated o.a.c.util.Deprecation class?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FYI: javaflow can potentially be serialized
Torsten Curdt wrote:
Just a short head up... as you know I moved
the a javaflow implementation over to jakarta
commons.
http://jakarta.apache.org/commons/sandbox/javaflow/
I did a couple of API changes...
http://vafer.org/blog/tcurdt/archives/000179.html
So now the latest trunk version supports continuation
serialization. This does not yet apply to the
cocoon javaflow because our continuation management
machinery also would need to support persistence.
But although there are some restrictions and (of
course) some work left...
at least the testcases show green now :)
Mate, you rock!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rant] am I the only one that thinks that our logging defaults are completely bogus?
Sylvain Wallez wrote: Now what I personally do when starting a new Cocoon app is to trash the whole category configuration in logkit.xconf and log everything in a single file (+ the filter for error.log). Same here. Let's simplify default config. Some fancy stuff can still be there - in comments. Vadim
Re: [RT] Remove dependencies to XSP
Antonio Gallardo wrote: On Mie, 9 de Febrero de 2005, 4:52, Andrew Savory dijo: On 9 Feb 2005, at 09:20, Carsten Ziegeler wrote: 2) create two blocks for each block that supports xsp: for example a databases and a databases-xsp block I suspect this is the easiest option. Forget to say the obvious: this is of course only for trunk. Hmm - any reason why it can't happen in BRANCH_2_1_X too? It's not a change in functionality, afaict... +1 +1 Vadim Best Regards, Antonio Gallardo
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
oceatoon wrote:
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite natural ;) in a
users perspective. I do use it massively.
So the correct way of doing this would be
cocoon.request.getParameter(blah) then ?
Exactly. Don't know yet how/if parameters will be available as
properties in the future, but for sure cocoon.request.getParameter()
will always work.
before it blows off with 2.2
Poof :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[Fwd: RE: Open Source developer's license]
I thought you might be interested... This is for the IntelliJ license. Original Message Subject:RE: Open Source developer's license Date: Thu, 10 Feb 2005 16:01:09 +0300 From: Ilia Dumov [EMAIL PROTECTED] To: 'Ralph Goers' [EMAIL PROTECTED] Hi Ralph, Thank you for your interest in our product! You are the second person to ask for license for Apache Cocoon project :-) Your workmate Ricardo Rocha has already asked the license. The point is that we provide licenses on per-project base; therefore each project will take one common key, which can be used on each workstation - even if they all work in one network simultaneously. The project seems to meet our requirements, but due to top-management whishes to consider each request individually, for each particular candidate, the approval procedure may take some time. I hope we will get back to you with concrete reply during the next week. Sorry for delay. We very much hope for a nice and fruitful cooperation :-) Thanks again for your interest! Best regards Ilia Dumov Product Manager JetBrains, Inc http://www.jetbrains.com Develop with pleasure -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 11:25 PM To: [EMAIL PROTECTED] Subject: Open Source developer's license My employer already has paid for a license for me, but I would like a personal license as well for my work on Apache Cocoon. Thanks, Ralph Goers Project website: http://cocoon.apache.org/2.1/ Project community: http://cocoon.apache.org Proof of participation: http://cocoon.apache.org/community/members.html and my [EMAIL PROTECTED] email address which routes to this email account. License should be held by me, Ralph Goers
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: I mean not tied to a class that provides other features than deprecation logging. And the Cocoon class provides so much more ;-) Hence the specific Deprecation class below, which will of course be in the org.apache.cocoon package hierarchy. Ok: +1 - I would choose a different name than Deprecation (DeprecationUtil or DeprecationLogger), but that's not that important. Choose whatever you think is best. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FYI: javaflow can potentially be serialized
Torsten Curdt wrote: Just a short head up... as you know I moved the a javaflow implementation over to jakarta commons. http://jakarta.apache.org/commons/sandbox/javaflow/ I did a couple of API changes... http://vafer.org/blog/tcurdt/archives/000179.html So now the latest trunk version supports continuation serialization. This does not yet apply to the cocoon javaflow because our continuation management machinery also would need to support persistence. But although there are some restrictions and (of course) some work left... at least the testcases show green now :) oo man! orthogonal persistance of frames! you rock! -- Stefano, who now needs to find an image of Torsten to play with... ;-)
Re: [rant] am I the only one that thinks that our logging defaults are completely bogus?
Vadim Gritsenko wrote: Sylvain Wallez wrote: Now what I personally do when starting a new Cocoon app is to trash the whole category configuration in logkit.xconf and log everything in a single file (+ the filter for error.log). Same here. Let's simplify default config. Some fancy stuff can still be there - in comments. All right, we seem to be having consensus. Anybody wants to do this or should I? -- Stefano.
Re: [rant] am I the only one that thinks that our logging defaults are completely bogus?
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Now what I personally do when starting a new Cocoon app is to trash
the whole category configuration in logkit.xconf and log everything
in a single file (+ the filter for error.log).
Same here. Let's simplify default config. Some fancy stuff can still
be there - in comments.
All right, we seem to be having consensus. Anybody wants to do this or
should I?
AFAIK you have commit rights on Cocoon ;-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rant] am I the only one that thinks that our logging defaultsare completely bogus?
On Jue, 10 de Febrero de 2005, 10:38, Stefano Mazzocchi dijo: Vadim Gritsenko wrote: Sylvain Wallez wrote: Now what I personally do when starting a new Cocoon app is to trash the whole category configuration in logkit.xconf and log everything in a single file (+ the filter for error.log). Same here. Let's simplify default config. Some fancy stuff can still be there - in comments. All right, we seem to be having consensus. Anybody wants to do this or should I? What are you waiting for? Please commit! ;-) Best regards, Antonio Gallardo.
Re: [rant] am I the only one that thinks that our logging defaultsare completely bogus?
Antonio Gallardo wrote: On Jue, 10 de Febrero de 2005, 10:38, Stefano Mazzocchi dijo: Vadim Gritsenko wrote: Sylvain Wallez wrote: Now what I personally do when starting a new Cocoon app is to trash the whole category configuration in logkit.xconf and log everything in a single file (+ the filter for error.log). Same here. Let's simplify default config. Some fancy stuff can still be there - in comments. All right, we seem to be having consensus. Anybody wants to do this or should I? What are you waiting for? Please commit! ;-) I can't believe I'm getting shy... must be the age :-( -- Stefano.
Status new Cocoon documentation
Last week Upayavira and I spent some time to overhaul the structure of the
two
document repositories:
- http://brutus.apache.org/docs/build/cocoon-doco-2-2/
- http://brutus.apache.org/docs/build/cocoon-doco-global/
We think that it covers all Cocoon relevant topics and is a good starting point
to evaluate and move over all existing documents. As this will be a lot of work
we need all the help we can get.
Check out http://wiki.apache.org/cocoon/CocoonDocumentationSystemHowTo what you
have to do actually.
Apart from helping to move over docs into our new repositories, my next
steps
are to:
1. finish my work on forrest repositories (comment and metadata part)
2. make the two repositories (currently they are in
http://svn.a.o/r/a(cocoon/whiteboard/doc-repos) the official doc repositories
of Cocoon 2.2 and move them over to the appropriate places (I will call for a
vote on this very soon)
3. call for help on [EMAIL PROTECTED] (writing docs)
4. work the online editor for docs (Jeremy, thanks again for your work on how
to access SVN using webdav!!!)
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Blocks documentation
While Upayavira and I were discussing the documentation, we also came
across the
question, where we should put the documentation of blocks within our navigation
structure. To keep things easy for now, we propose following:
- Core blocks
- non-core blocks
- external blocks
*Core blocks* are technically independent from Cocoon but as they will be
important for many (most) of our users, they should show up very high in our
documentation.
This is necessary because users will not necessarily have grasped the 'blocks'
system before they start researching how to handle forms, for example. They need
to find form handling very high up in the Cocoon documentation. To treat it as
just another block would mean it would get lost in the midst of quite a few
minor Cocoon blocks.
The blocks that we consider as core blocks are Cocoon Forms, Javaflow and the
XML-Templating block.
*Non-core blocks* will be documented within their own documentation repository.
We already have two repositories: global and 2.2, so adding others for the other
blocks doesn't make the docs system too much more complex. This way, we would
have, for example, http://cocoon.apache.org/blocks/portal/1.0/ as the place for
all Portal documentation.
The first priority of this project is to document the Cocoon core, and the Core
blocks - maybe the Portal block is an exception here as it alreay has a lot of
users. For this purupose I will set up a seperate doc repository for the
portal block.
All other non-core blocks can be documented and handled afterwards. Otherwise
the workload becomes way too high.
*External blocks* are blocks that are currently hosted somewhere else than in
our SVN and we want to link to them. This section contains a list with links to
those blocks.
WDOT?
[Please let's concentrate on the 'documentation of blocks' part here. If nobody
beats me, I will start a separate discussion about cleaning up Cocoon very soon.]
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r153227 - in cocoon/trunk: src/blocks/deli/conf/ src/blocks/html/java/org/apache/cocoon/generation/ src/blocks/linotype/samples/ src/blocks/mail/samples/sendmail/ src/blocks/portal/samples/ src/blocks/scratchpad/java/org/apache/cocoon/transformation/ src/blocks/scratchpad/samples/sitemap-viewer/ src/blocks/scratchpad/samples/sitemap-viewer/xml/ src/blocks/session-fw/WEB-INF/xconf/ src/blocks/session-fw/conf/ src/blocks/taglib/samples/ src/blocks/template/java/org/apache/cocoon/template/jxtg/ src/blocks/webdav/samples/davmap/ src/blocks/xsp/conf/ src/documentation/ src/documentation/xdocs/developing/ src/documentation/xdocs/faq/ src/documentation/xdocs/snippet/ src/documentation/xdocs/tutorial/ src/documentation/xdocs/userdocs/matchers/ src/documentation/xdocs/userdocs/readers/ src/documentation/xdocs/userdocs/serializers/ src/java/org/apache/cocoon/generation/ src/java/org/apache/cocoon/serialization/ src/java/org/apache/cocoon/transformation/ src/webapp/ src/webapp/WEB-INF/xconf/ tools/src/anttasks/
Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: Author: cziegeler Date: Thu Feb 10 07:00:57 2005 New Revision: 153227 URL: http://svn.apache.org/viewcvs?view=revrev=153227 Log: pool-min and pool-grow have been removed from pooling long time ago in excalibur Same is true for 2.1 branch, AFAIKT, right? Yes, I will apply the changes asap. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
