Re: [PROPOSAL] Download of jars with Maven ant tasks

[Leszek Gawron]

Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and 
handling mechanism would greatly help Cocoon, because it makes it 
easy to share jars and to download only the ones needed.

Ivy was proposed as a possible solution, but I suggested instead to 
use the Maven code, for the sake of not duplicating efforts; 
unfortunately at that time it was not ready and the proposal stalled.

Finally, Maven has released tasks that enable Ant builds to use the 
artifact handling [1].

Isn't it time that we actually do it? :-)

+1

+1 as long as its somebody else doing it and as long as we retain the 
ability to distribute stuff that didn't make it in the maven repos yet.
 All of the tasks can optionally take one or more remote 
repositories to download from and upload to and a local repository to 
store downloaded and installed archives to.

So in order to be totally safe we could introduce cocoon specific jar 
repository.

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: [PROPOSAL] Download of jars with Maven ant tasks

[Leszek Gawron]

Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and 
handling mechanism would greatly help Cocoon, because it makes it easy 
to share jars and to download only the ones needed.

Ivy was proposed as a possible solution, but I suggested instead to use 
the Maven code, for the sake of not duplicating efforts; unfortunately 
at that time it was not ready and the proposal stalled.

Finally, Maven has released tasks that enable Ant builds to use the 
artifact handling [1].

Isn't it time that we actually do it? :-)
[1] http://maven.apache.org/maven2/ant-tasks.html
Do I get it right that I do not need maven installed to use it? Just a 
single JAR file? That would be lovely.

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

[JOB] Project Manager at Wyona

[Michael Wechner]

Hi
Wyona is looking for a Project Manager for its Boston/Cambridge (USA) 
office.
The requirements are:

- 3+ years project management experience in a distributed development 
environment
- Experience with managing Java related projects
- Enthusiasm for working in an Open Source environment
- Preferably experience with Lenya and Cocoon or other Apache projects
- Enthusiasm for interacting with software developers and customers

Please contact me off the list if you are interested 
([EMAIL PROTECTED])

Thanks
Michi
--
Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com  http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]

Re: [PROPOSAL] Download of jars with Maven ant tasks

[Stefano Mazzocchi]

Daniel Fagerstrom wrote:
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and 
handling mechanism would greatly help Cocoon, because it makes it easy 
to share jars and to download only the ones needed.

Ivy was proposed as a possible solution, but I suggested instead to 
use the Maven code, for the sake of not duplicating efforts; 
unfortunately at that time it was not ready and the proposal stalled.

Finally, Maven has released tasks that enable Ant builds to use the 
artifact handling [1].

Isn't it time that we actually do it? :-)
+1
+1 as long as its somebody else doing it and as long as we retain the 
ability to distribute stuff that didn't make it in the maven repos yet.

--
Stefano.

Re: [PROPOSAL] Download of jars with Maven ant tasks

[Daniel Fagerstrom]

Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and 
handling mechanism would greatly help Cocoon, because it makes it easy 
to share jars and to download only the ones needed.

Ivy was proposed as a possible solution, but I suggested instead to use 
the Maven code, for the sake of not duplicating efforts; unfortunately 
at that time it was not ready and the proposal stalled.

Finally, Maven has released tasks that enable Ant builds to use the 
artifact handling [1].

Isn't it time that we actually do it? :-)
+1
/Daniel

[PROPOSAL] Download of jars with Maven ant tasks

[Nicola Ken Barozzi]

Some time ago, it was noted that the usage of a jar download and 
handling mechanism would greatly help Cocoon, because it makes it easy 
to share jars and to download only the ones needed.

Ivy was proposed as a possible solution, but I suggested instead to use 
the Maven code, for the sake of not duplicating efforts; unfortunately 
at that time it was not ready and the proposal stalled.

Finally, Maven has released tasks that enable Ant builds to use the 
artifact handling [1].

Isn't it time that we actually do it? :-)
[1] http://maven.apache.org/maven2/ant-tasks.html
PS:  Please no discussions about Ant sucks, Maven sucks, mine is bigger 
than your's.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: New JCR block

[Stefano Mazzocchi]

Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I just committed a new JCR block. This block provides two features: a 
Repository component, and a "jcr:" protocol.

Awesome news!
The Repository component is nothing more than the standard 
javax.jcr.Repository interface, but provides a way to centrally 
define how to access the repository (Jackrabbit conf file, JNDI, etc) 
and how to obtain credentials to log into the repository. There's 
currently only one concrete implementation that uses Jackrabbit.

That's very cool... I needed something like this for Linotype.
The JCR source factory is more interesting, as it provides a 
traversable and modifiable source that hides away the details of the 
repository structure and node types. To achieve this, we need to 
configure it by defining a mapping from node types to "files" and 
"folders" that will be visible through the "jcr:" protocol.

The result is that we can now use a JCR repository in Cocoon just 
like we use the regular filesystem.

As an example, here's how this source factory is configured for the 
standard filesystem-like node types defined by JCR:

  
  
  
  
  
content-prop="jcr:data"
mimetype-prop="jcr:mimeType"
lastmodified-prop="jcr:lastModified"
validity-prop="jcr:lastModified"/>


how do you expand the prefixes in the attribute values?

I don't ;-)
All methods in the JCR API use prefixed names, and prefix mappings are 
stored within the repository itself.
well, this is not entirely correct. you can overload the prefixes in 
your workspace ;-)

So I expect the mapping writer to 
be consistent with prefixes defined in the repository.
this is a huge mistake. if I take my content and your content and merge 
them into a single repository, then we could have the exact same 
prefixes, mapped to a different namespace and the JCR API is totally 
consistent as long as you specify that prefix in the workspace you are 
using.

I agree that by default the default prefix is good enough, but in the 
long term we might want to keep the door open for overloading prefixes 
in the workspace.

Now if we want to use full namespace URIs, we can also accept the 
notation that's used in some places in JCR, i.e. "{full-uri}name".
that's ugly :-) I'd much rather use the XSLT-like prefix expansion based 
on the current namespace prefix description of the element contenxt in 
the XML infoset.

More detailed information about this configuration is given in 
o.a.c.jcr.source.JCRSourceFactory's javadoc.

This source factory is still a bit primitive regarding all features 
provided by JCR. Future enhancements include querying the repository, 
handling workspaces, node properties, versions, etc.

Your feedback and opinions about this initial implementation and its 
future evolutions are more than welcome!

In linotype, what I needed was a way to store new items in the 
repository and then query the repository for the last n in reversed 
chronological order (LIFO).

There are many ways we can glue query capabilities to JCR in cocoon, I 
would like to discuss with you people what is best way to do that and 
what are the requirements.

My initial thoughts about this is to use URI parameters for querying, 
e.g. "jcr://?xpath=/news/items[position() < 10]" and have this return a 
collection source, i.e. one that has children that would be the query 
results.

The parameter name is the query language to be used (e.g. xpath, sql, etc).
sure, that's a start, let's see how far along we can go with that.
--
Stefano.

Context.javaToJS nagging

[Leszek Gawron]

"file:/J:/projects/mkupon/build/webapp/mobile/flow/main.js", line 34: RHINO 
USAGE WARNING: Missed Context.javaToJS() conversi
on:
Rhino runtime detected object [EMAIL PROTECTED] of class org.apache.cocoon.com
ponents.source.CocoonSourceResolver where it expected String, Number, Boolean 
or Scriptable instance. Please check your code
for missig Context.javaToJS() call.
RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object [EMAIL PROTECTED] of class org.apache.cocoon.com
ponents.source.CocoonSourceResolver where it expected String, Number, Boolean 
or Scriptable instance. Please check your code
for missig Context.javaToJS() call.
Shouldn't we wrap every component in cocoon.getComponent()?
--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r164568 - /cocoon/trunk/src/webapp/WEB-INF/logkit.xconf

[Leszek Gawron]

Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Mon Apr 25 06:15:33 2005
New Revision: 164568
URL: http://svn.apache.org/viewcvs?rev=164568&view=rev
Log:
exceptions are not logged anywhere
-  %5.5{priority} %{time} [%{category}] 
(%{uri}%{query}) %{thread}/%{class:short}: %{message}\n
+  %5.5{priority} %{time} [%{category}] 
(%{uri}%{query}) %{thread}/%{class:short}: 
%{message}\n%{throwable}
   

rootThrowable probably is better; and can you please update 
documentation (comments above this line) as well?
what is the difference between rootThrowable and throwable? Does the 
first one support chained exceptions or is it something else?

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r164568 - /cocoon/trunk/src/webapp/WEB-INF/logkit.xconf

[Leszek Gawron]

Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Mon Apr 25 06:15:33 2005
New Revision: 164568
URL: http://svn.apache.org/viewcvs?rev=164568&view=rev
Log:
exceptions are not logged anywhere
-  %5.5{priority} %{time} [%{category}] 
(%{uri}%{query}) %{thread}/%{class:short}: %{message}\n
+  %5.5{priority} %{time} [%{category}] 
(%{uri}%{query}) %{thread}/%{class:short}: 
%{message}\n%{throwable}
   

rootThrowable probably is better; and can you please update 
documentation (comments above this line) as well?
ok
--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r164568 - /cocoon/trunk/src/webapp/WEB-INF/logkit.xconf

[Vadim Gritsenko]

[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Mon Apr 25 06:15:33 2005
New Revision: 164568
URL: http://svn.apache.org/viewcvs?rev=164568&view=rev
Log:
exceptions are not logged anywhere
-  %5.5{priority} %{time} [%{category}] (%{uri}%{query}) 
%{thread}/%{class:short}: %{message}\n
+  %5.5{priority} %{time} [%{category}] (%{uri}%{query}) 
%{thread}/%{class:short}: %{message}\n%{throwable}
   
rootThrowable probably is better; and can you please update documentation 
(comments above this line) as well?

Thanks,
Vadim

DO NOT REPLY [Bug 33545] - [Enh] Make StatusGenerator show Cocoon version information

[bugzilla]

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_bug.cgi?id=33545





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 15:36 ---
(In reply to comment #9)
> Should be enough to add a list to jars in WEB-INF/lib?

Won't work for endorsed libs - which are not in WEB-INF/lib and will override
those in WEB-INF/lib.

I'd suggest adding some code to StatusGenerator to check some basic stuff as
Xerces and Xalan version programmatically, using their's API or Constants class
or somesuch. It should also handle situation when Xerces or Xalan is missing.

Vadim


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.

[Lepido] Feedback wanted: what do you want your Cocoon IDE to be?

[Sylvain Wallez]

Hi all,
As you hopefully know, the Lepido Cocoon IDE project is in the proposal 
phase at Eclipse [1].

This phase is dedicated at gathering feedback on the project proposal to 
enhance it and ensure there is enough interest so that a community 
emerges around the project.

This community is not only about developpers (even if we need them of 
course) but also about testers, users, and companies that would use 
Lepido for their business, either to promote Cocoon or in a larger offering.

If you're interested in Lepido, please say so and make your voice heard 
so that we all can build an IDE that suits your needs and expectations.

There are two ways for you to provide feeback:
- the Eclipse newsgroup [2] or its web front-end [3] (registration 
required for antispam reasons [4]).
- the Lepido wiki pages [5] where we build the feature list.

Thanks for your participation,
Sylvain
[1] http://www.eclipse.org/proposals/eclipse-lepido/
[2] news://news.eclipse.org/eclipse.technology.lepido
[3] 
http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.lepido
[4] http://www.eclipse.org/newsgroups/index.html
[5] http://wiki.apache.org/cocoon/Lepido

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

DO NOT REPLY [Bug 20508] - [PATCH] Namespace cleanup in HTMLSerializer

[bugzilla]

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_bug.cgi?id=20508





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 15:23 ---
(In reply to comment #6)
> IMHO, we can refactor the patch to add an optional parameter that will strip 
> the
> namespaces when the use set it. To keep backward compatibility, the current
> approach (include whatever namespace) should be the default behavior.
> 
> Is that OK?

Strip *all* namespaces, configurable - that's acceptable patch.

Vadim


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34386] - NPE by adding an extra HTML tag in hello.xml

[bugzilla]

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_bug.cgi?id=34386





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 15:04 ---
(In reply to comment #2)
> The solution is comment lines from 726 to 731 and 840 to 845 in
> org.apache.xml.serializer.ToHTMLStream.java (current CVS).

http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xml/serializer/ToHTMLStream.java?annotate=1.37

The code you are referring to was written 2 years ago (revision 1.1). Are you
sure that it is the cause of the problem? I'm not sure that we had this bug for
2 years, it seems that this is recent bug. WDYT?


> Can I commit a fixed xalan.jar?

I'd wait for response from xalan team first.

Vadim


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.

DO NOT REPLY [Bug 34572] - ehcache disk store path with spaces fails under Windows

[bugzilla]

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_bug.cgi?id=34572


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 12:45 ---
Thanks for reporting back this is fixed on the SVN.

Since ehcache 1.1 is in 2.1 and 2.2. I close this bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

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 has an issue affecting its community integration.
This issue affects 42 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -DEBUG- Dependency on avalon-framework-api exists, no need to add for property 
avalonapi.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 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/java/build/xercesImpl.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-25042005.jar
 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-25042005.jar
 -Dbuild=build/cocoon-25042005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/classes:/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/deprecated:/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/test:/usr/local/gump/public/workspace/cocoon/build/cocoon-25042005/mocks:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/tools/loader:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/publi

DO NOT REPLY [Bug 34572] - ehcache disk store path with spaces fails under Windows

[bugzilla]

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_bug.cgi?id=34572


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 11:58 ---
In fact I had the same problem as Michael (comment #1): As my C:\tmp\ had never
been used for ehcaching yet, I only realized that at the 2nd restart.

So I tried what he and Antonio suggested (replacing ehcache-1.0.jar with
ehcache-1.1.jar): it seems to work perfectly now!

Seems the only bug fix to ehcache from 1.0 to 1.1[1] fixed it. As I cannot find
the bug related to comment #1 I close this one, but a release note on ehcache
upgrade explaining that it fixes something would be nice! :)
[1] :
http://sourceforge.net/tracker/index.php?func=detail&aid=1063908&group_id=93232&atid=603559

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re:Authentication ??? Tomcat5 deploy

[oceatoon]

Thanks Roy
This isn't promissing (well blocking )at all for deploying Cocoon Apps in
newer version of Tomcat5.
If they aren't going  to change it, we should add it to the docs because
this impacts quite seriously apllication structural choices.

Maybe Cocoon devers would like to participate in the issue this might get
Tomcat devers to reconcider their structural decision which blocks us from
using higher versions of Tomcat then 4.1 ?

Thanks 
Regards
Tibor

roy huang wrote:

> Hi,Tibor
> I met this problem too and send mail for help several months ago and
> can't find any solutions.Today I search tomcat dev mail archives and
> found this:http://issues.apache.org/bugzilla/show_bug.cgi?id=32424.
> You can check this and find an another way. BTW,I am still using
> tomcat 4.1 because this problem.
> 
> Roy Huang

Re: Initial version of spring-app block

[Carsten Ziegeler]

Rolf Kulemann wrote:

> 
> The problem here is that I haveto  add an empty applicationContext.xml
> or add an empty , which is not nice. So, I want
> that only my parent context is used. Carsten, would it be ok, if I
> change the SpringComponentLocator to fall back to parent only, if
> applicationContext.xml is not available and
>  is null?
> 
Sure, go ahead and thanks for fixing the bug with the configuration.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/