On Wednesday 09 February 2005 15:47, Bart Molenkamp wrote:
I guess it is because of two
incompatible versions of JCL?
It is because WebSphere doesn't hide its own implementation classes in a
separate classloader tree, as a proper container should.
Niclas
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33420.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32988.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Wed, 9 Feb 2005, Hugo Burm wrote:
Hello Ralph,
Can you comment on how you debug Cocoon with IDEA (isn't IntelliJ/Jetbrains
the name of the company?)? Can you set breakpoints and step through the
code?
Just for your reference, this is how I debug a Cocoon block:
Have to do this one
Ken Wasetis wrote:
Hello,
I saw a recent post regarding the DOMStreamer patch and related Cocoon Initialization Error after a full Cocoon rebuild (though with a status of 'successful'.)
I don't think these are related, but it's rather that I just noted there is
another problem and Vadim hinted
hi ralph
could you please add a wiki page (LoadInIDEA) with your instructions?
thnx
--stavros
On Tue, 8 Feb 2005, Ralph Goers wrote:
This can be done fairly easily. I'll outline the steps I use.
1. Create a directory named cocoon.
2. Do svn co
Stefano Mazzocchi wrote:
I don't want to go into a bikeshedding war about logging but *EVERY
SINGLE TIME* I install a cocoon application I have to completely rewrite
the logging defaults.
Not tweak or improve: start over! And it's starting to piss me off.
It's insane the amount of crap that
Stefano Mazzocchi wrote:
I don't want to go into a bikeshedding war about logging but *EVERY
SINGLE TIME* I install a cocoon application I have to completely
rewrite the logging defaults.
Not tweak or improve: start over! And it's starting to piss me off.
It's insane the amount of crap that
Hugo Burm wrote:
Hello Ralph,
Can you comment on how you debug Cocoon with IDEA (isn't IntelliJ/Jetbrains
the name of the company?)? Can you set breakpoints and step through the
code?
Just for your reference, this is how I debug a Cocoon block:
Have to do this one time:
- Build the whole Cocoon
We some blocks that depend on XSP just because they provide some
logigsheets (session, databases etc.), so as soon as you want to use
them you *have* to include XSP although you don't use it at all.
We discussed this already, but didn't change anything :(
I see two solutions:
1) either move all
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33460.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
We some blocks that depend on XSP just because they provide some
logigsheets (session, databases etc.), so as soon as you want to use
them you *have* to include XSP although you don't use it at all.
We discussed this already, but didn't change anything :(
I see two
Carsten Ziegeler wrote:
We some blocks that depend on XSP just because they provide some
logigsheets (session, databases etc.), so as soon as you want to use
them you *have* to include XSP although you don't use it at all.
We discussed this already, but didn't change anything :(
I see two
On 8 Feb 2005, at 21:31, Stefano Mazzocchi wrote:
1) logkit has the most unintuitive configuration schema ever imagined.
Wait until you see the Log4J XML configuration.
Pier
smime.p7s
Description: S/MIME cryptographic signature
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
We some blocks that depend on XSP just because they provide some
logigsheets (session, databases etc.), so as soon as you want to use
them you *have* to include XSP although you don't use it at all.
We discussed this already, but didn't change
On Wednesday 09 February 2005 16:51, Sylvain Wallez wrote:
There's something that must be cleaned up: some of the subclasses of
CascadingException log the exception and the chained exceptions, when
JDK since version 1.4 (or 1.3?) does the same itself. So we could reduce
the amount of redundant
Hi,
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33462.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Mie, 9 de Febrero de 2005, 4:52, Andrew Savory dijo:
Hi,
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
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-template has an issue affecting its community integration.
This
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
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
We some blocks that depend on XSP just because they provide some
logigsheets (session, databases etc.), so as soon as you want to use
them you *have* to include XSP although you don't use it at all.
We discussed this already,
On Wednesday 09 February 2005 15:47, Bart Molenkamp wrote:
I've managed to get Cocoon 2.1 working on WebSphere 5.1. That's not very
special, as many threads in mail-archives specify how to realize this,
and the page on the Wiki [1] also tells me how to do this.
Also, Ceki just announced a page
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context that shows their
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33451.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Wed, 09 Feb 2005 16:05:26 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is
Peter Hunsberger wrote:
On Wed, 09 Feb 2005 16:05:26 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the
On Wed, 09 Feb 2005 16:32:28 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip/
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context that
In an attachment there is a patch that:
1. Makes vertical text orientation possible.
2. Caches fonts used in workbook, since there could be an error in MS
Excel that maximal numer of fonts used in workbook is exceeded.
Please, if there is a POI-block developer on the list, could you look at
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33470.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33470.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33470.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
I just did a check which blocks require xsp:
- python
Uses the xsp core, so this is ok
- chaperon,
- lucene
- eventcache
All these three use xsp just for the samples, so we should imho
simply rewrite the samples.
- databases
- session-fw.
These two are the only blocks that have own
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context
Il giorno 09/feb/05, alle 18:37, Carsten Ziegeler ha scritto:
So I would suggest to rewrite the samples and simply move the
logicsheets to the xsp blocks; imho it's not worth creating new blocks
just because of these two logicsheets. WDYT?
+1
--
Ugo Cei - http://agylen.com/blojsom/blog/
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now unrestricted.
The only difference with the real objects is that a special wrapper
is used for
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now unrestricted.
The only
Sylvain Wallez wrote:
Great! Why do we need this special wrapper?
Because removing it means a backwards incompatible change!
Sounds familiar ;)
It adds small syntactic sugar by allowing you to write
'cocoon.session.blah' instead of 'cocoon.session.getAttribute(blah)'
and the same on request and
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33473.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Bart Molenkamp wrote:
Should these problems be documented somewhere? Maybe create a page
that tracks various problems for various containers, and document the
solutions?
absolutely. there are some parts on the wiki already, so some
consolidation would be helpful.
we are working to get cocoon
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
I don't want to go into a bikeshedding war about logging but *EVERY
SINGLE TIME* I install a cocoon application I have to completely
rewrite the logging defaults.
Not tweak or improve: start over! And it's starting to piss me off.
It's insane the
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
I don't want to go into a bikeshedding war about logging but *EVERY
SINGLE TIME* I install a cocoon application I have to completely
rewrite the logging defaults.
Not tweak or improve: start over! And it's starting to piss me off.
It's insane the
Carsten Ziegeler wrote:
I just did a check which blocks require xsp:
- python
Uses the xsp core, so this is ok
- chaperon,
- lucene
- eventcache
All these three use xsp just for the samples, so we should imho
simply rewrite the samples.
- databases
- session-fw.
These two are the only
Stefano Mazzocchi wrote:
I really think that having one log channel with one log configuration
file and one log level would be just fine. People might decide to tune
it later, if they need and don't use the 'tail|grep' filtering tecnique
(or log4j chainsaw kindatools, which work the same way)
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from different
sources (the object itself and some other data), especially when one of
the sources comes from the browser.
And what about conflicts? Fortunately the object is
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request,
Le 9 févr. 05, à 21:03, Stefano Mazzocchi a écrit :
...I really think that having one log channel with one log
configuration file and one log level would be just fine...
+1, that's what I do all the time (using log4j - Ceki is my friend
since someone made me notice that he lives so close ;-)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from
different sources (the object itself and some other data), especially
when one of the sources comes from the browser.
And what about conflicts?
Le 9 févr. 05, à 21:27, Carsten Ziegeler a écrit :
...Unfortunately, I fear that this is common use, so let's deprecate
it with 2.1.x and remove for 2.2 completly
+1
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
snip/
Oh f*ck, that's even worse than I thought. It now returns the request
*attributes* because I was fooled by the implementation of FOM_Request
which was buggy: getIds() which lists the object's properties was
This is now official: http://www.orbeon.com/company/pr-objectweb
Last attempt before dying, or will they attract a community? Time will
tell...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{
On Mie, 9 de Febrero de 2005, 16:40, Sylvain Wallez dijo:
This is now official: http://www.orbeon.com/company/pr-objectweb
Last attempt before dying, or will they attract a community? Time will
tell...
I have a friend working in Costa Rica. while chatting last week, he told
me they are
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-template has an issue affecting its community integration.
This
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
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from
different sources (the object itself and some other data), especially
when one of the sources comes from the browser.
And what
Carsten Ziegeler wrote:
I think this should be as simple as possible. What about a static
accessor, e.g. on the Core object?
I meant the Cocoon object here (we are talking about 2.1.x).
You might want to use this logger
where you don't want to either implement Serviceable nor
57 matches
Mail list logo
