Your answer seems to be what I need. But I am confused with how 'servlet://'
in dojo.registerModulePath("cocoon.ajax",
"servlet://resource/external/ajax/js") in manifest.js is translated?
Rice
On 5/3/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
Rice Yeh napisał(a):
> Hi,
> I have a bock
Online report :
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/132347
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed, 2 May 2007 16:02:29 -0700
Finished at: Wed, 2 May 2007 16:02:39 -0700
Total time: 1
org.apache.cocoon.generation.FileGeneratorBeanTestCase.txt:Tests run: 1,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.137 sec <<< FAILURE!
org.apache.cocoon.generation.FileGeneratorTestCase.txt:Tests run: 1,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.256 sec <<< FAILURE!
The b
[
https://issues.apache.org/jira/browse/COCOON-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-2029.
Resolution: Fixed
fixed, thanks for reporting.
> Missing dependency in cocoon-databases-impl?
> -
[
https://issues.apache.org/jira/browse/COCOON-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-1646.
Resolution: Fixed
> [M10N] release plugin
> -
>
> Key: COCOON-
[
https://issues.apache.org/jira/browse/COCOON-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-1634.
Resolution: Fixed
> [M10N] - archetype example
> --
>
> Ke
[
https://issues.apache.org/jira/browse/COCOON-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-1632.
Resolution: Fixed
> [M10N] - osgi integration
> -
>
> Key:
[
https://issues.apache.org/jira/browse/COCOON-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-1633.
Resolution: Fixed
> [M10N] - pom corrections
>
>
> Key: C
[
https://issues.apache.org/jira/browse/COCOON-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-1645.
Resolution: Fixed
> [M10N] deployment plugin
>
>
> Key: C
[
https://issues.apache.org/jira/browse/COCOON-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-1631.
Resolution: Fixed
> [M10N] - block layout
> -
>
> Key: COCOON-
Grzegorz Kossakowski wrote:
For now i've excluded commons-logging explicitly from commons-jxpath, it
is brought in by several other blocks anyway.
I'm puzzled now a little. Do we have some exclusion guidelines? Previously, I
thought we had to exclude only
avalon-framework but you excluded com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> Reinhard Poetz wrote:
>>> Giacomo Pati wrote:
>>
Now this seems to me that some changes with the RCL prevents third
party servlet filters to access
the ApplicationContext, or am I wrong?
>
Rice Yeh napisał(a):
Hi,
I have a bock which provides some widgets based on dojo. Now, my
problem is how to do dojo.registerModulePath without directly
modifying forms-field-styling.xsl?
I do not understand your question. Why do you need to modify
forms-field-styling.xsl? To register your widg
Online report :
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/132055
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed, 2 May 2007 10:58:54 -0700
Finished at: Wed, 2 May 2007 10:59:07 -0700
Total time: 1
Hi,
I have a bock which provides some widgets based on dojo. Now, my problem
is how to do dojo.registerModulePath without directly modifying
forms-field-styling.xsl?
Regards,
Rice
Issue Subscription
Filter: COCOON-open-with-patch (102 issues)
Subscriber: cocoon
Key Summary
COCOON-2054 StatusGenerator must now show default Store explicitly (because no
longer part of StoreJanitor)
https://issues.apache.org/jira/browse/COCOON-2054
COCOON-2052 Allow Ajax s
Online report :
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/132000
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed, 2 May 2007 09:00:59 -0700
Finished at: Wed, 2 May 2007 09:01:13 -0700
Total time: 1
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals
as needed. Hence I propose that we merge the deployer and
Felix Knecht napisał(a):
>
>> I would like to hear if there are other problems or you managed to get Forms
>> and Ajax working
>> again.
>>
>
> Not yet, but it's hard to say if it's a problem of forms/ajax or a
> problem with the new cocoon-maven-plugin I'm fighting with ... (sitting
> beside
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Now this seems to me that some changes with the RCL prevents third
party servlet filters to access
the ApplicationContext, or am I wrong?
no, that's my interpretation of the stacktrace too
Any pointers?
The problem is that when
Felix Knecht napisał(a):
>>> Why not put the
>>>
>>> >> src="org.apache.cocoon.ajax.AjaxRequestSelector"/>
>>>
>>> into a cocoon-ajx-impl/.../META-INF/cocoon/avalon/sitemap.xmap? That's
>>> easier than put the need to everybody to add it to his sitemap and that's
>>> IMO the place
>> Why not put the
>>
>> > src="org.apache.cocoon.ajax.AjaxRequestSelector"/>
>>
>> into a cocoon-ajx-impl/.../META-INF/cocoon/avalon/sitemap.xmap? That's
>> easier than put the need to everybody to add it to his sitemap and that's
>> IMO the place where it should be placed.
>>
> Thanks for your comments.
Your welcome ;-)
> I would like to hear if there are other problems or you managed to get Forms
> and Ajax working
> again.
>
Not yet, but it's hard to say if it's a problem of forms/ajax or a
problem with the new cocoon-maven-plugin I'm fighting with ... (sittin
Felix Knecht napisał(a):
> org.apache.avalon.framework.configuration.ConfigurationException: Type
> 'servletLinkRewriting' does not exist for 'map:transform'
>
> because of
>
>
>
> Where is it defined? I can't find it - or do you mean "servletLinkRewriter"?
Yeah, it wasa typo. Fixed, thanks.
>> Have you followed migration guides?:
>>
>> http://cocoon.zones.apache.org/daisy/cdocs/g1/g2/g7/1351.html
>>
>>
>>
>
> Following the migration guides I'm getting the error:
>
> org.apache.avalon.framework.configuration.ConfigurationException: Type
> 'servletLinkRewriting' does n
Grzegorz Kossakowski schrieb:
> Giacomo Pati napisał(a):
>
>> See my other mail.
>>
>> After hopefully fixing my flowscripts and sitemaps according to the new
>> resource accessing URIs I get:
>>
>
> Have you followed migration guides?:
>
> http://cocoon.zones.apache.org/daisy/cdocs/g1/
Online report :
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/131891
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed, 2 May 2007 06:59:24 -0700
Finished at: Wed, 2 May 2007 06:59:37 -0700
Total time: 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> Now this seems to me that some changes with the RCL prevents third
>> party servlet filters to access
>> the ApplicationContext, or am I wrong?
>
> no, that's my interpretation of the stacktrace too
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> BTW: Can we have a released deployer plugin as well.
>
> I think that Cocoon should only have one Maven plugin with as many goals
> as needed. Hence I propose that we merge the deployer and the reloadin
Online report :
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/131836
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed, 2 May 2007 05:44:57 -0700
Finished at: Wed, 2 May 2007 05:45:09 -0700
Total time: 1
Carsten Ziegeler napisał(a):
> Yes, I think so - at least for new code we should use the new interfaces.
> Actually I forgot the main reason for the new stuff :) The Avalon
> version is pooled which does not fit nicely into the bean approach (and
> Spring); we have supported for pooling Avalon com
Giacomo Pati wrote:
Well, it happens on the first request. Does your scenario apply to the first
request as well?
actually unnecessary but yes, there is something that triggers a reload already
on the first request.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> java.lang.IllegalStateException: BeanFactory not initialized or
>> already closed - call 'refresh'
>> before accessing beans via the ApplicationContext
>> at
>> org.springframework.context.suppo
Reinhard Poetz napisał(a):
> Reinhard Poetz wrote:
>
> I wrote some initial documentation that can be found at
> http://cocoon.zones.apache.org/daisy/cdocs-maven-plugin/g1/1295.html.
> Feedback or even better, contributions are welcome!
>
Great job, Reinhard! I fixed some small mistakes but didn
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals
as needed. Hence I propose that we merge the deployer and the reloading
classloader plugin into a single one:
cocoon:depl
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Is it ok to set the path back to what it was or did you had some
reason to change it?
some time ago we decided to have all or stuff under META-INF/cocoon. I
don't think that this should be an exception, shouldn't it?
Ok.
Sure,
Giacomo Pati napisał(a):
> See my other mail.
>
> After hopefully fixing my flowscripts and sitemaps according to the new
> resource accessing URIs I get:
Have you followed migration guides?:
http://cocoon.zones.apache.org/daisy/cdocs/g1/g2/g1/1350.html
http://cocoon.zones.apache.org/daisy/cdocs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> Is it ok to set the path back to what it was or did you had some
>> reason to change it?
>
> some time ago we decided to have all or stuff under META-INF/cocoon. I
> don't think that this should be an
Giacomo Pati wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
The second one allows "patching" the web.xml by adding snippets from
META-INF/cocoon/xpatch to it. It also supports a feature that reverses
the classloader hierarchy in a web application b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giacomo Pati wrote:
>
>
> Giacomo Pati wrote:
>
>> Reinhard Poetz wrote:
>>> Giacomo Pati wrote:
Reinhard Poetz wrote:
>>> The second one allows "patching" the web.xml by adding snippets from
>>> META-INF/cocoon/xpatch to it. It also
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giacomo Pati wrote:
>
>
> Reinhard Poetz wrote:
>> Giacomo Pati wrote:
>>> Reinhard Poetz wrote:
>> The second one allows "patching" the web.xml by adding snippets from
>> META-INF/cocoon/xpatch to it. It also supports a feature that revers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> Reinhard Poetz wrote:
> The second one allows "patching" the web.xml by adding snippets from
> META-INF/cocoon/xpatch to it. It also supports a feature that reverses
> the classloader hierarc
[EMAIL PROTECTED] napisał(a):
> Online report :
> http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/131727
> Build statistics:
> State: Failed
> Previous State: Ok
> Started at: Wed, 2 May 2007 02:59:53 -0700
> Finished at: Wed, 2
Online report :
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/291/buildId/131727
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed, 2 May 2007 02:59:53 -0700
Finished at: Wed, 2 May 2007 03:00:08 -0700
Total time: 14s
Jorg Heymans napisał(a):
> Grzegorz Kossakowski wrote:
>
>> I meant 2.0.5 or higher but if works already we can push it
>> to 2.0.6+. So, does it work already?
>
> Not without quirks [1] , but basically yes.
I set 2.0.6 as minimal Maven version required to build Cocoon. I hope it's not
much tr
Giacomo Pati wrote:
Reinhard Poetz wrote:
The second one allows "patching" the web.xml by adding snippets from
META-INF/cocoon/xpatch to it. It also supports a feature that reverses
the classloader hierarchy in a web application by using a shielding
classloader.
But can only be used if packagin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
>>> The second one allows "patching" the web.xml by adding snippets from
>>> META-INF/cocoon/xpatch to it. It also supports a feature that reverses
>>> the classloader hierarchy in a web application by using a shielding
>>> clas
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm still trying to migrate my project from deployer to rcl plugin with no
success (and now not even
the old one works) :-(
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm still trying to migrate my project from deployer to rcl plugin with no
success (and now not even
the old one works) :-(
Reinhard Poetz wrote:
> Reinhard Poetz wrote:
>> Giacomo Pati wrote:
>>> BTW: Can we have a released deployer plugin as well.
Jorg Heymans napisał(a):
> http://jira.codehaus.org/browse/MECLIPSE-262 seems to be somewhat
> similar to our problem, I've added our findings there.
Thanks Jorg.
> For now i've excluded commons-logging explicitly from commons-jxpath, it
> is brought in by several other blocks anyway.
I'm puzzle
Hi,
On 1 May 2007, at 23:33, Reinhard Poetz wrote:
I've done the work (sorry Andrew that I committed at the wrong
moment) today. I successfully run mvn clean install -P allblocks
with an empty repository this evening.
Cool, works for me. I've just fixed the maven cocoon archetype to use
51 matches
Mail list logo
