> It looks like ApacheCon US is going to be Oct 9-13 in Austin,
> TX. Given that the GetTogether is normally around this same
> time frame I'm afraid it will be virtually impossible for me
> to attend both. While it wasn't clear in the email, it
> appears to me that ApacheCon is a little dif
[ http://issues.apache.org/jira/browse/COCOON-1606?page=all ]
Antonio Gallardo updated COCOON-1606:
-
Hi Thomas, I tested before the patch and after the patch and I cannot see
different behavior. Perhaps it is already fixed. Would you test it again in
c
[ http://issues.apache.org/jira/browse/COCOON-1489?page=all ]
Antonio Gallardo closed COCOON-1489:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks Jason for the patch. It was applied wit
[ http://issues.apache.org/jira/browse/COCOON-1489?page=all ]
Antonio Gallardo reassigned COCOON-1489:
Assign To: Antonio Gallardo
> [PATCH] XInclude transformer does not handle fallback correctly
> ---
[ http://issues.apache.org/jira/browse/COCOON-1489?page=all ]
Jason Johnston updated COCOON-1489:
---
Attachment: COCOON-1489.diff
Patch fixes issue with ill-formed result from xi:include within a fallback. The
JUnit testcase for that functionality had a
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
It's already there :) In the webapp under samples/spring. The last time
I checked it (some weeks ago) it worked using:
http://localhost:/samples/spring.
Thanks, I found the samples and they still work :-)
Reinhard Poetz wrote:
> a) Everybody learns to run the release plugin and produces artifacts
> himself and can deploy them to his own repositories. Question (to Jorg):
> Is this possible at all (IIUC the release plugin automatically tags your
> release in SVN)? And if yes, how difficult is it?
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
But a listener has the advantage that the context is
available to other servlets (!= Cocoon) as well.
yes, then it makes sense indeed.
Besides that using a listener means that we separate the component
management from th
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
It's already there :) In the webapp under samples/spring. The last time
I checked it (some weeks ago) it worked using:
http://localhost:/samples/spring.
Thanks, I found the samples and they still work :-)
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I'm sorry if you felt attacked, I had no intension to attack you or
anyone else. There was a problem that needed to be solved so that I
could continue to work.
Ok, perhaps I overreacted a little bit. Sorry for that.
Of course I could have solv
[ http://issues.apache.org/jira/browse/COCOON-1854?page=all ]
Jorg Heymans updated COCOON-1854:
-
Summary: [PATCH] Browser selector should have Opera before MSIE (was:
Browser selector should have Opera before MSIE)
> [PATCH] Browser selector should hav
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
But a listener has the advantage that the context is
available to other servlets (!= Cocoon) as well.
yes, then it makes sense indeed.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source,
Reinhard Poetz wrote:
> hmm, yes, this could be a general solution for people that want to add their
> own
> listeners without losing the possibility of using the paranoid classloader
> and
> the reloading classloader.
>
> Just for Spring I prefer adding
>
>
>
> to cocoon.xconf.
> Is there
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
I'm wondering why we have a META-INF and a src/main/resources/META-INF
directory with overlapping content in cocoon-core?
That's because of a limitation of the Eclipse PDE plugin. It doesn't support
that META-INF/manifes
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
ok. Than I will try to use the standard Spring way:
contextConfigLocation
/WEB-INF/applicationContext.xml
org.springframework.web.context.ContextLoaderListener
in the cocoon-22-webapp-archetype but I guess this w
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> I'm wondering why we have a META-INF and a src/main/resources/META-INF
>> directory with overlapping content in cocoon-core?
>
> That's because of a limitation of the Eclipse PDE plugin. It doesn't support
> that META-INF/manifest.mf is located s
Carsten Ziegeler escribió:
Antonio Gallardo schrieb:
Hi,
While merging from 2.1 XInclude fallback tests, they don't pass due
[1]. Since XIncludeTransformer is an Avalon component, he does not
recognize Spring exceptions at all. I am sure we need to address this
because we are going to hi
Carsten Ziegeler wrote:
I'm wondering why we have a META-INF and a src/main/resources/META-INF
directory with overlapping content in cocoon-core?
That's because of a limitation of the Eclipse PDE plugin. It doesn't support
that META-INF/manifest.mf is located somewhere else than in the root di
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> ok. Than I will try to use the standard Spring way:
>>
>>
>>contextConfigLocation
>>/WEB-INF/applicationContext.xml
>>
>>
>>
>> org.springframework.web.context.ContextLoaderListener
>>
>>
>> in the cocoon-22-webapp-archetype but I guess
I'm wondering why we have a META-INF and a src/main/resources/META-INF
directory with overlapping content in cocoon-core?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Antonio Gallardo schrieb:
> Hi,
>
> While merging from 2.1 XInclude fallback tests, they don't pass due
> [1]. Since XIncludeTransformer is an Avalon component, he does not
> recognize Spring exceptions at all. I am sure we need to address this
> because we are going to hit the same error in o
Reinhard Poetz wrote:
yes, when we know that it works at all, I will follow your advice.
thanks.
Having my Cocoon PMC member hat on, I have another problem with Maven
artifacts: They don't contain licensing information or a NOTICE file.
As in the future, Maven artifacts will be our actual r
[ http://issues.apache.org/jira/browse/COCOON-1803?page=all ]
Antonio Gallardo updated COCOON-1803:
-
Component: Blocks: XSP
(was: * Cocoon Core)
> Logicsheet Cache Double Request Compile Bug
> --
[ http://issues.apache.org/jira/browse/COCOON-1713?page=all ]
Antonio Gallardo updated COCOON-1713:
-
Component: - Documentation
(was: * Cocoon Core)
> [LINK] www.mw-import.de
> ---
>
> Key: COCOON-1713
[ http://issues.apache.org/jira/browse/COCOON-1730?page=all ]
Antonio Gallardo updated COCOON-1730:
-
Component: - Documentation
(was: * Cocoon Core)
> [Link] Computer Science Department 2 - University of Erlangen-Nuremberg
> --
[ http://issues.apache.org/jira/browse/COCOON-1266?page=all ]
Antonio Gallardo closed COCOON-1266:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks for the patch. It was applied with mino
[ http://issues.apache.org/jira/browse/COCOON-1266?page=all ]
Antonio Gallardo reassigned COCOON-1266:
Assign To: Antonio Gallardo (was: Cocoon Developers Team)
> [PATCH] Resource reader fails to add HTTP headers
> --
[
http://issues.apache.org/jira/browse/COCOON-476?page=comments#action_12413722 ]
Antonio Gallardo commented on COCOON-476:
-
This issue was filled for cocoon 2.0.3. In the mean time the patch was added by
closing COCOON-1424.
Above Simone comment is
Is it correct that the load and save model events are never send? It
seems that the listeners get never notified when these phases end. Is
this true or did I oversee something?
If it's not implemented, does anyone have an idea where to implement it?
Carsten
--
Carsten Ziegeler - Open Source Grou
[ http://issues.apache.org/jira/browse/COCOON-1294?page=all ]
Carsten Ziegeler closed COCOON-1294:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
This has been fixed recently.
> [PATCH] JavaC
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>
>> This side note makes me shudder. Does this mean you commit new features
>> without even checking if they work?
>
> Hmm, hmm, what do you think I'm doing? As we have a commit-then-review policy
> would this make a difference?
>
Yes, it
Reinhard Poetz wrote:
> ok. Than I will try to use the standard Spring way:
>
>
>contextConfigLocation
>/WEB-INF/applicationContext.xml
>
>
>
> org.springframework.web.context.ContextLoaderListener
>
>
> in the cocoon-22-webapp-archetype but I guess this will not work together
> wit
Carsten Ziegeler wrote:
Hmm, I don't know what's best, but there is no default automatic include
for this, so you have to add an include in the sitemap anyway. Imho you
should move your configuration into a subdirectory and not in the same
as the sitemap itself.
ok, didn't know this as the inc
Sylvain Wallez wrote:
>
> This side note makes me shudder. Does this mean you commit new features
> without even checking if they work?
>
Hmm, hmm, what do you think I'm doing? As we have a commit-then-review
policy would this make a difference?
Anyways, I tested this long time ago but in the m
[ http://issues.apache.org/jira/browse/COCOON-1527?page=all ]
Antonio Gallardo updated COCOON-1527:
-
Bugzilla Id: (was: 35275)
Component: Blocks: XSP
(was: * Cocoon Core)
> [PATCH] Cache control logic sheets for XSP to ov
Issue Subscription
Filter: COCOON-open-with-patch (91 issues)
Subscriber: cocoon
Key Summary
COCOON-1825 Ajax errror when an active state widget become invisible state
widget
http://issues.apache.org/jira/browse/COCOON-1825
COCOON-1811 [PATCH] Flow Script: Allow dynamic loadi
Carsten Ziegeler wrote:
>> I would prefer having some global mechanism, similar to WEB-INF/xconf for
>> Spring beans. We could introduce something like WEB-INF/spring/ into which
>> you can put as many bean definition files as you want.
>>
> Oh, this already works! Just put a:
>
> http://bl
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 29 May 12:09 PM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2006-05-29 12:02:09
... Rendering docs in
/export/home/confi
[ http://issues.apache.org/jira/browse/COCOON-1840?page=all ]
Antonio Gallardo closed COCOON-1840:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks for the patch. It was applied in 2.1.10
[EMAIL PROTECTED] wrote:
> Author: antonio
> Date: Mon May 29 05:04:52 2006
> New Revision: 410084
>
> URL: http://svn.apache.org/viewvc?rev=410084&view=rev
> Log:
> Fix typo. Thanks to Carten. :-)
>
LOL
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.o
Carsten Ziegeler escribió:
[EMAIL PROTECTED] wrote
Author: antonio
Date: Mon May 29 04:44:49 2006
New Revision: 410078
+if (this.form_encoding == null || this.form_encoding == null || value
== null) {
I think you have to check "this.form_encoding" only once for null
[ http://issues.apache.org/jira/browse/COCOON-1840?page=all ]
Antonio Gallardo reassigned COCOON-1840:
Assign To: Antonio Gallardo
> [PATCH] XMLFileModule file-specific configuration ignored
> -
[EMAIL PROTECTED] wrote
> Author: antonio
> Date: Mon May 29 04:44:49 2006
> New Revision: 410078
>
> +if (this.form_encoding == null || this.form_encoding == null ||
> value == null) {
I think you have to check "this.form_encoding" only once for null.
Carsten
--
Carsten Ziegeler - O
[ http://issues.apache.org/jira/browse/COCOON-1625?page=all ]
Antonio Gallardo updated COCOON-1625:
-
Bugzilla Id: (was: 36967)
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
> redundant copying between container an
[ http://issues.apache.org/jira/browse/COCOON-1625?page=all ]
Antonio Gallardo closed COCOON-1625:
Resolution: Fixed
Thanks for the patch. It was applied in 2.1.10-dev and 2.2-dev. Feel free to
reopen the issue if needed.
> redundant copying b
[ http://issues.apache.org/jira/browse/COCOON-1625?page=all ]
Antonio Gallardo reassigned COCOON-1625:
Assign To: Antonio Gallardo (was: Cocoon Developers Team)
> redundant copying between container and form encoding
> --
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>> It's already there :) In the webapp under samples/spring. The last time
>> I checked it (some weeks ago) it worked using:
>> http://localhost:/samples/spring.
>
> Thanks, I found the samples and they still work :-)
Great, thanks for testing
On Monday 29 May 2006 18:40, Reinhard Poetz wrote:
> Having my Cocoon PMC member hat on, I have another problem with Maven
> artifacts: They don't contain licensing information or a NOTICE file. As in
> the future, Maven artifacts will be our actual releases (everything else is
> just for demos), I
On Monday 29 May 2006 05:17, Daniel Fagerstrom wrote:
> > Is it possible to have an OSGi bundle which exports classes of two jars?
>
> A bundle is packaged as a jar, so it is not possible for two separate
> jars. A bundle can contain internal jars that are added to the bundle
> internal classpath.
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ]
Antonio Gallardo closed COCOON-1694:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks for the patch. It was applied with mino
Niclas Hedhman wrote:
On Monday 29 May 2006 16:24, Reinhard Poetz wrote:
Having a "-SNAPSHOT"-dependency is not an option for several reasons
(snapshots are changing, you can't release your own artifacts if you depend
on snapshots).
I agree myself that this is a common "problem".
So what
Carsten Ziegeler wrote:
It's already there :) In the webapp under samples/spring. The last time
I checked it (some weeks ago) it worked using:
http://localhost:/samples/spring.
Thanks, I found the samples and they still work :-)
- o -
I'm not perfectl
On Monday 29 May 2006 16:24, Reinhard Poetz wrote:
> Having a "-SNAPSHOT"-dependency is not an option for several reasons
> (snapshots are changing, you can't release your own artifacts if you depend
> on snapshots).
I agree myself that this is a common "problem".
> So what are the possible solu
[
http://issues.apache.org/jira/browse/COCOON-1625?page=comments#action_12413702
]
aleksander.bandelj commented on COCOON-1625:
In HttpRequest.java located
cocoon 2.0:
core/cocoon-core/src/main/java/org/apache/cocoon/environment/http/HttpReque
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ]
Antonio Gallardo reassigned COCOON-1694:
Assign To: Antonio Gallardo
> Error decommissioning component:
> org.apache.cocoon.components.store.impl.EHDefaultStore
>
[ http://issues.apache.org/jira/browse/COCOON-1625?page=all ]
Antonio Gallardo updated COCOON-1625:
-
Would you provide a patch?
> redundant copying between container and form encoding
> -
>
>
[ http://issues.apache.org/jira/browse/COCOON-1839?page=all ]
Antonio Gallardo closed COCOON-1839:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks for the patch. Patch applied in 2.1.10-
[ http://issues.apache.org/jira/browse/COCOON-1839?page=all ]
Antonio Gallardo reassigned COCOON-1839:
Assign To: Antonio Gallardo
> exception2html.xslt causes IE display problem
>
>
>
[
http://issues.apache.org/jira/browse/COCOON-1815?page=comments#action_12413689
]
Antonio Gallardo commented on COCOON-1815:
--
The code was applied to cocon-2.1.10-dev and 2.2.-dev. Would you test it?
> CopySourceAction generate NPE
>
Carsten Ziegeler escribió:
Antonio Gallardo wrote:
Hi,
While merging from 2.1 XInclude fallback tests, they don't pass due
[1]. Since XIncludeTransformer is an Avalon component, he does not
recognize Spring exceptions at all. I am sure we need to address this
because we are going to hit
Reinhard Poetz wrote:
> I see that there is no component
> org.apache.excalibur.source.SourceFactory/file
> available. Try to add it to the components part and run the tests again.
If you extend the SitemapComponentTestCase (like the XInclude test
does), the source resolver should be set up autom
Niclas Hedhman wrote:
On Thursday 25 May 2006 04:06, Reinhard Poetz wrote:
But basically you're right that we have to clarify the situation in
general. How shall we proceed to get an answer to the question of
"unofficial" artifact releases? Is the [EMAIL PROTECTED] in the position to
decide
su
Antonio Gallardo wrote:
> Hi,
>
> While merging from 2.1 XInclude fallback tests, they don't pass due
> [1]. Since XIncludeTransformer is an Avalon component, he does not
> recognize Spring exceptions at all. I am sure we need to address this
> because we are going to hit the same error in oth
Daniel Fagerstrom wrote:
> I'm sorry if you felt attacked, I had no intension to attack you or
> anyone else. There was a problem that needed to be solved so that I
> could continue to work.
Ok, perhaps I overreacted a little bit. Sorry for that.
> Of course I could have solved it without asking
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 24 May 2006, Reinhard Poetz wrote:
Date: Wed, 24 May 2006 18:46:29 +0200
From: Reinhard Poetz <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Automatic releases
Is there any possi
Antonio Gallardo wrote:
Reinhard Poetz escribió:
IIUC this exception means that your testcase xconf doesn't provide a
bean with the name "org.apache.excalibur.source.SourceFactory/file",
does it?
Would you explain more? :-)
First, I'm not a specialist in our junit testing mechanisms and I
[ http://issues.apache.org/jira/browse/COCOON-1515?page=all ]
Antonio Gallardo closed COCOON-1515:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks for the patch. It was applied in 2.1.10
Reinhard Poetz escribió:
Antonio Gallardo wrote:
Hi,
While merging from 2.1 XInclude fallback tests, they don't pass due
[1]. Since XIncludeTransformer is an Avalon component, he does not
recognize Spring exceptions at all. I am sure we need to address this
because we are going to hit the s
Ralph Goers wrote:
So, in short, I think your proposal is a good idea if done across the
board as long as we update the documentation at the same time.
Working on a non-monolitic documentation is on my radar (see
http://marc.theaimsgroup.com/?t=11416611477&r=1&w=2) - I will continue as
s
Antonio Gallardo wrote:
Hi,
While merging from 2.1 XInclude fallback tests, they don't pass due
[1]. Since XIncludeTransformer is an Avalon component, he does not
recognize Spring exceptions at all. I am sure we need to address this
because we are going to hit the same error in other compone
[ http://issues.apache.org/jira/browse/COCOON-1515?page=all ]
Antonio Gallardo reassigned COCOON-1515:
Assign To: Antonio Gallardo (was: Cocoon Developers Team)
> [PATCH] Add remoteUser() information to RequestGenerator
> ---
[ http://issues.apache.org/jira/browse/COCOON-1110?page=all ]
Antonio Gallardo closed COCOON-1110:
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Thanks for reporting. The issue was fixed in 2
72 matches
Mail list logo
