Re: [RT] Logging in 2.2

Stefano Mazzocchi wrote: Carsten Ziegeler wrote: How about leaving everything as is and just change the default logger to be log4j instead of logkit? Hm, yeah, why not :( It seems that everyone is using different logging approaches, so a consensus is impossible. Sigh. Carsten

Re: [RT] Logging in 2.2

Ralph Goers wrote: Stefano Mazzocchi wrote: Why can't you write a log4j appender that talks to your system? I'm not trying to be dense, I'm just trying to understand. That would mean that I would be using log4j's configuration and filtering. If that was what I wanted I would just write my own log

Re: [RT] Logging in 2.2

Carsten Ziegeler wrote: Hmm, I'm a little bit lost in this thread :( The easiest thing of course would be to just leave everything as it is and move to a different subject. But using a logging framework that noone else uses just feels not right for me. Has anyone a clue on how to procede? How ab

Re: [RT] Escaping Sitemap Hell

Daniel Fagerstrom wrote: (was: Splitting xconf files step 2: the sitemap) Although the Cocoon sitemap is a really cool innovation it is not entierly without problems: * Sitemaps for large webapps easy becomes a mess * It sucks as a map describing the site [1] * It doesn't give that much support

Re: [RT] Logging in 2.2

Stefano Mazzocchi wrote: Why can't you write a log4j appender that talks to your system? I'm not trying to be dense, I'm just trying to understand. That would mean that I would be using log4j's configuration and filtering. If that was what I wanted I would just write my own log4j appenders. To fe

Re: [RT] Logging in 2.2

On Jan 6, 2005, at 5:27 PM, Stefano Mazzocchi wrote: As far as I'm concerned, Cocoon can use log4j or the JDK logger as long as it is done through an abstraction layer. Why can't you write a log4j appender that talks to your system? I'm not trying to be dense, I'm just trying to understand. You do

Re: [RT] Logging in 2.2

Ralph Goers wrote: I cannot have a direct dependency on any logging implementation that does not let me replace it. We use our own logging framework that, believe it or not, is somewhat more advanced. As far as I'm concerned, Cocoon can use log4j or the JDK logger as long as it is done through an

Re: [RT] Logging in 2.2

Gianugo Rabellino wrote: On Wed, 05 Jan 2005 15:42:08 -0500, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: Nicola Ken Barozzi wrote: Antonio Gallardo wrote: I saw that too, but UGLI should not need that extra isLogEnabled stuff in any case. How so? What am I missing? As noted in my previous messa

Re: [BUG?] JavaFlow and getComponent

What is "cocoon-trunk"? That would be the one from svn :) Being a versioning system there are different branches. Trunk is the main development branch. https://svn.apache.org/repos/asf/cocoon/trunk/ This might also help http://wiki.apache.org/cocoon/SubversionMigration Thanks -- Torsten

Re: [BUG?] JavaFlow and getComponent

It would also be great if you could try cocoon-trunk and report back. What is "cocoon-trunk"? The nightly build or the version out from subversion? Stephan

RE: context: protocol not available?

> From: Mark Lundquist [mailto:[EMAIL PROTECTED] > > [..snip..] > > Yes, this absolutely is supposed to work! :-) > > org.apache.xalan.processor.TransformerFactoryImpl implements > javax.xml.transform.TransformerFactory, which provides the > setURIResolver() > method. > > And we want that to be..

Re: JXTemplate import + JSPGenerator = ClassCastException

On 05.01.2005 23:46, Stephan Coboos wrote: The according pipline parses a JSP an returns the result as XML: Using the protocol cocoon:/ to retrieve the JSP result causes an ClassCastException. Calling test.jsp directly (without JXTemplate) works well. http://issues.

Re: [BUG?] JavaFlow and getComponent

> Can someone please verify whether it is really a bug or just a mistake of mine? It's a bug. The class verification failed. Please try to use a literal String for the ROLE. It would also be great if you could try cocoon-trunk and report back. Thanks for reporting! cheers -- Torsten

RE: context: protocol not available?

Hi Lars & everyone, > From: Lars Huttar [mailto:[EMAIL PROTECTED] > > Mark Lundquist wrote (on users@cocoon.apache.org): > > > Hi, > > > > I have some stylesheets containing: > > > > > > > > In 2.1.6, this causes: > > > > java.net.MalformedURLException: unknown protocol: context > >

[BUG?] JavaFlow and getComponent

Hello, it's possible that I have found another bug in Cocoon. Using getComponent within a JavaFlow causes a cryptical exception. I wrote an example using Cocoon 2.1.6 which doesn't work. Can someone please verify whether it is really a bug or just a mistake of mine? # The Component Interface: p

Re: [RT] Escaping Sitemap Hell

On Jan 6, 2005, at 11:12 AM, Daniel Fagerstrom wrote: How much work you should spend in creating "cool" URLs in your webapp, varies of course from application to application. I just wanted to point out that we can do more than 123456.cont if we want to. I have used more than one webapp that goes

Re: [RT] Logging in 2.2

Ralph Goers wrote: I guess I would just leave the Avalon Logger constructs in and change the default implementation to use the JDK logger. Lose the dependency on logkit. Yes, loosing the dependency on logkit is imho good; but in the long term we want to loose the dependency to avalon as well (re

Re: Splitting xconf files step 2: the sitemap

Reinhard Poetz wrote: Daniel Fagerstrom wrote: 2.) ECM has to "ask" the BlockManager which blocks exist and include all block specific component declarations: /WEB-INF/blocks/4711/block.xconf /WEB-INF/blocks/4712/block.xconf ... This is natural to do based on the current "g

Re: [RT] Logging in 2.2

Ralph Goers wrote: I guess I would just leave the Avalon Logger constructs in and change the default implementation to use the JDK logger. Lose the dependency on logkit. ...and provide good documentation on how to hook in other log implementations. Does not sound too bad to me. What about just4log

Re: [RT] Escaping Sitemap Hell

Ugo Cei wrote: Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto: The requested resource will often be based on some content or combination of content that we can access from Cocoon. The content can be a file, data in a db, result from a business object etc. Let us assume that it res

Re: [RT] Escaping Sitemap Hell

On Thu, 06 Jan 2005 01:54:09 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > (was: Splitting xconf files step 2: the sitemap) > Interesting thoughts, I didn't get much sleep last night, so excuse me if any of the following comes across as a bit grumpy, no flames or criticism is intended...

Re: [RT] Logging in 2.2

I guess I would just leave the Avalon Logger constructs in and change the default implementation to use the JDK logger. Lose the dependency on logkit. Carsten Ziegeler said: > Hmm, I'm a little bit lost in this thread :( > > The easiest thing of course would be to just leave everything as it is

DO NOT REPLY [Bug 27484] - NPE - Cocoon attempts to resolve input source incorrectly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Splitting xconf files step 2: the sitemap

Daniel Fagerstrom wrote: Reinhard Poetz wrote: Apart from this, let's look at what's missing to make the next step towards real blocks: As said, a block is located in WEB-INF/blocks/[block-id]. There is one central configuration file knowing how a particular block is configured, which ID it ha

[SUMMARY] Logging in 2.2

On Jan 6, 2005, at 9:46 AM, Carsten Ziegeler wrote: Hmm, I'm a little bit lost in this thread :( The easiest thing of course would be to just leave everything as it is and move to a different subject. But using a logging framework that noone else uses just feels not right for me. Has anyone a cl

Re: [RT] Escaping Sitemap Hell - side note

On Thu, 6 Jan 2005 09:29:14 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Daniel, > In short, the ideas of cool URLs is great, but the implementation domain > might require otherwise. I'm going to try and find time to respond to Daniel in more detail, but I think the most important th

Re: [RT] Escaping Sitemap Hell - side note

[EMAIL PROTECTED] wrote: Daniel, First off: great post. I agree with your ideas and reading through this post I realised I have tried implementing my URL space along these lines, ending up with a huge and very unclear sitemap, so every improvement is welcome. Nice, I had the same realization when I

Re: [RT] Escaping Sitemap Hell

Ugo Cei wrote: Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto: The requested resource will often be based on some content or combination of content that we can access from Cocoon. The content can be a file, data in a db, result from a business object etc. Let us assume that it res

Re: [RT] Logging in 2.2

Hmm, I'm a little bit lost in this thread :( The easiest thing of course would be to just leave everything as it is and move to a different subject. But using a logging framework that noone else uses just feels not right for me. Has anyone a clue on how to procede? Carsten

Re: [RT] Escaping Sitemap Hell

Daniel Fagerstrom wrote: The layout actually separates the site layout from the sitemap quite nicely. Care to explain what I should look for, and in what document I find the info? The easiest way to see what I am talking about is to look at the portal sample site. Look at build/webapp/sam

Re: [RT] Logging in 2.2

On Jan 6, 2005, at 3:10 AM, Carsten Ziegeler wrote: the only difference is that we move away from LogEnabled and that we directly use an existing logging api. I'd be vehemently -1 on a change to tie cocoon to a concrete logging api. I like how it only depends on a logging abstraction at the moment

Re: [RT] Escaping Sitemap Hell

Ralph Goers wrote: Daniel Fagerstrom wrote: Is it a Map of the Site? The Forrest people don't think that the sitemap is enough as map of the site. They have a special linkmap [1] that gives a map over the site and that is used for internal navigation and for creating menu

Re: [RT] Escaping Sitemap Hell

On Thursday 06 January 2005 19:37, Daniel Fagerstrom wrote: > >As a sidenote; Tapestry is battling with these types of problems as well > > (but a somewhat different level), and handles it by allowing an > > interceptor in the URL encoding/decoding phase. > > Do you have any references that sumari

Re: [RT] Escaping Sitemap Hell

Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto: The requested resource will often be based on some content or combination of content that we can access from Cocoon. The content can be a file, data in a db, result from a business object etc. Let us assume that it resides in some ki

Re: URLSource bug?

Hi Paul! On 04-01-2005 22:03, "Paul Christmann" <[EMAIL PROTECTED]> wrote: > I've written two tests (I didn't see a URLSourceTestCase anywhere?): > one with an invalid http URL (http://localhost/garbage) and one with a > valid http url (http://www.example.com), and the exists method returns > tru

Re: [RT] Escaping Sitemap Hell

Niclas Hedhman wrote: On Thursday 06 January 2005 08:54, Daniel Fagerstrom wrote: Good post ! Thanks :) But you shouldn't require your user to remember different URLs for different clients, thats a task for server driven content negotiation. Using .html is not especially future proof, should all li

Cocoon-2.1.X Tests Failure 01/06/05

Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20050106.log Last messages from the log file: == [foreach] reader-mime-type.xml:39

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32961] New: - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: [RT] Escaping Sitemap Hell - side note

Daniel, First off: great post. I agree with your ideas and reading through this post I realised I have tried implementing my URL space along these lines, ending up with a huge and very unclear sitemap, so every improvement is welcome. However, the example below is a bad one from a privacy/securit

Re: [RT] Logging in 2.2

Sylvain Wallez wrote: Carsten Ziegeler wrote: Nono, the performance problem is in Log4J itself: checking if a log level is enabled on a category is costly and involves crawling up the category tree up to finding an ancestor which has an explicit setting for this (see Category.isDebugEnabled and