You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jörn Nettingsmeier <ne...@apache.org> on 2007/04/05 17:33:54 UTC

2.1 trunk broken? problem with jxtemplate component...

hi everyone!


i've just updated my lenya tree, and the servlet engine bails out on 
startup with this error message:

org.apache.avalon.framework.service.ServiceException: Could not find 
component (key 
[org.apache.cocoon.template.expression.StringTemplateParser/jxtg]) 
(Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg')

a quick check shows that this component is declared in lenya's cocoon 
2.1.11-dev external, which is why i'm posting here. can anyone reproduce 
the problem?

the relevant portion of my servlet engine log is attached below.

if you want to see the problem for yourself, check out 
http://lenya.zones.apache.org:9999.

any enlightenment is appreciated :)


best,

jörn




main DEBUG core.manager - ComponentFactory creating new instance of 
org.apache.cocoon.template.expression.JXTGStringTemplateParser.
main DEBUG core.manager - no logger attribute available, using standard 
logger
main DEBUG core.manager - ComponentHandler initialized for: 
org.apache.cocoon.template.expression.JXTGStringTemplateParser
main DEBUG core.manager - Adding 
org.apache.cocoon.template.expression.JXTGStringTemplateParser for hint 
[jxtg]
main DEBUG core.manager - ComponentFactory creating new instance of 
org.apache.cocoon.template.expression.DefaultStringTemplateParser.
main DEBUG core.manager - no logger attribute available, using standard 
logger
main DEBUG core.manager - ComponentHandler initialized for: 
org.apache.cocoon.template.expression.DefaultStringTemplateParser
main DEBUG core.manager - Adding 
org.apache.cocoon.template.expression.DefaultStringTemplateParser for 
hint [default]
main DEBUG core.manager - ComponentHandler initialized for: 
org.apache.cocoon.components.ExtendedComponentSelector
main DEBUG core.manager - ComponentFactory creating new instance of 
org.apache.cocoon.template.script.DefaultScriptManager.
main DEBUG core.manager - no logger attribute available, using standard 
logger
main DEBUG core.manager - ComponentFactory creating new instance of 
org.apache.cocoon.template.script.DefaultInstructionFactory.
main DEBUG core.manager - no logger attribute available, using standard 
logger
main DEBUG core.manager - Resolving 
'resource://org/apache/cocoon/template/template-instructions.xml' with 
base 'null' in context 'file:/b
uild/lenya-trunk-rework-pubconf/build/lenya/webapp/'
main DEBUG core.manager - Resolved to systemID : 
resource://org/apache/cocoon/template/template-instructions.xml
main DEBUG core.manager - Creating source object for 
resource://org/apache/cocoon/template/template-instructions.xml
main DEBUG core.manager - Releasing source object for 
resource://org/apache/cocoon/template/template-instructions.xml
main DEBUG core.manager - ComponentHandler initialized for: 
org.apache.cocoon.template.script.DefaultInstructionFactory
main DEBUG core.manager - Could not find component for role: 
org.apache.cocoon.template.expression.StringTemplateParser/jxtg
main ERROR core.manager - Caught an exception trying to initialize the 
component handler.
org.apache.avalon.framework.service.ServiceException: Could not find 
component (key [org.apache.cocoon.template.expression.StringTemplateP
arser/jxtg]) 
(Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg')
         at 
org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:80)
         at 
org.apache.cocoon.template.script.DefaultScriptManager.service(DefaultScriptManager.java:68)
         at 
org.apache.avalon.framework.container.ContainerUtil.service(ContainerUtil.java:143)
         at 
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:271)
         at 
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:108)
         at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:524)
         at 
org.apache.cocoon.components.CocoonComponentManager.initialize(CocoonComponentManager.java:583)
         at 
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244)
         at org.apache.cocoon.Cocoon.initialize(Cocoon.java:345)
         at 
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244)
         at 
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1429)
         at 
org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:499)
         at 
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383)
         at 
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
         at 
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:445)
         at 
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:323)
         at 
org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:511)
         at 
org.mortbay.jetty.plus.PlusWebAppContext.doStart(PlusWebAppContext.java:149)
         at org.mortbay.util.Container.start(Container.java:72)
         at org.mortbay.http.HttpServer.doStart(HttpServer.java:753)
         at org.mortbay.jetty.plus.Server.doStart(Server.java:153)
         at org.mortbay.util.Container.start(Container.java:72)
         at org.mortbay.jetty.plus.Server.main(Server.java:202)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at Loader.invokeMain(Unknown Source)
         at Loader.run(Unknown Source)
         at Loader.main(Unknown Source)
Caused by: org.apache.avalon.framework.component.ComponentException: 
Could not find component (key [org.apache.cocoon.template.expression.
StringTemplateParser/jxtg])
         at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:265)
         at 
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:354)
         at 
org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:68)
         ... 29 more
main ERROR access - Exception reloading
org.apache.avalon.framework.service.ServiceException: Could not find 
component (key [org.apache.cocoon.template.expression.StringTemplateP
arser/jxtg]) 
(Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg')
         at 
org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:80)
         at 
org.apache.cocoon.template.script.DefaultScriptManager.service(DefaultScriptManager.java:68)
         at 
org.apache.avalon.framework.container.ContainerUtil.service(ContainerUtil.java:143)
         at 
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:271)
         at 
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:108)
         at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:524)
         at 
org.apache.cocoon.components.CocoonComponentManager.initialize(CocoonComponentManager.java:583)
         at 
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244)
         at org.apache.cocoon.Cocoon.initialize(Cocoon.java:345)
         at 
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244)
         at 
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1429)
         at 
org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:499)
         at 
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383)
         at 
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
         at 
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:445)
         at 
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:323)
         at 
org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:511)
         at 
org.mortbay.jetty.plus.PlusWebAppContext.doStart(PlusWebAppContext.java:149)
         at org.mortbay.util.Container.start(Container.java:72)
         at org.mortbay.http.HttpServer.doStart(HttpServer.java:753)
         at org.mortbay.jetty.plus.Server.doStart(Server.java:153)
         at org.mortbay.util.Container.start(Container.java:72)
         at org.mortbay.jetty.plus.Server.main(Server.java:202)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at Loader.invokeMain(Unknown Source)
         at Loader.run(Unknown Source)
         at Loader.main(Unknown Source)
Caused by: org.apache.avalon.framework.component.ComponentException: 
Could not find component (key [org.apache.cocoon.template.expression.
StringTemplateParser/jxtg])
         at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:265)
         at 
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:354)
         at 
org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:68)
         ... 29 more

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.04.2007 18:09, Joern Nettingsmeier wrote:

> in case it turns out to be a hard problem or you are short on time, 
> could you tell me at which revision the issue was introduced, so that i 
> can roll back?

Information can be found at http://marc.info/?t=117534524500002&r=1&w=4.

Regards
Jörg

Re: cocoon syncing

Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2007-05-21 at 08:23 -0500, Richard Frovarp wrote:
> Bob Harner wrote:
...
> > I'm sorry to bring this up again, but another month and a half has
> > past and Lenya's SVN external for Cocoon is still pointing to the
> > unreleased Cocoon trunk rather than a released version.  Remember, the
> > Lenya 1.4 release needs to be based on (and thoroughly tested on) a
> > released version of Cocoon, and for all anybody really knows the
> > 2.1.11 release of Cocoon might take a while longer.  Meanwhile Cocoon
> > is likely to change even while a Lenya code freeze is in place.  And
> > we have yet to test whether the released version of 2.1.10 works with
> > the Lenya trunk.
> >
> > Maybe as a compromise the policy should be that whenever a freeze is
> > announced, the SVN external is pointed at the then-released version of
> > Cocoon.  We can always point at the 2.1.11 version if and when it is
> > released.
> >
> +1

Thanks Bob to remind about this issue.

I agree and to make sure we all pay sufficient attention to this issue
you may call a vote. I am +1 on your proposal.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: cocoon syncing

Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Bob Harner wrote:
> On 4/5/07, Bob Harner <bo...@gmail.com> wrote:
>> On 4/5/07, Joern Nettingsmeier <ne...@folkwang-hochschule.de> wrote:
>> > Bob Harner wrote:
>> > >
>> > > As an aside, this seems to illustrate why it would be much better to
>> > > base ongoing Lenya development on a *released* version of cocoon and
>> > > not its trunk, right?  If 1.4 is to be released in a few weeks, it
>> > > would have to be based on Cocoon's most recent release, right?  
>> That's
>> > > 2.1.10.  The last I heard was that most Lenya developers are 
>> using the
>> > > Cocoon trunk rather than the 2.1.10 release (is this still the 
>> case?),
>> > > which means that significant extra testing (and patching?) would 
>> need
>> > > to be done before releasing 1.4.
>> >
>> > important point. but the 2.1.11 release is imminent, and so we might
>> > have a good chance of a sync'ed release.
>> >
>> > in general, i prefer following the cocoon trunk during most of the
>> > development cycle (continous integration among apache projects does
>> > create some friction, but it's generally a Good Thing imho), but i 
>> agree
>> > that we should "freeze" our cocoon external a lot earlier in future
>> > releases, to guarantee proper testing.
>>
>> Are there features/fixes in Cocoon 2.1.11 that Lenya requires?  Does
>> anybody even know?
>>
>> Continuous integration is great for developers who are working closely
>> together.  It is often a nightmare for those who aren't.  Hopefully
>> 2.1.11 will come out soon and it won't matter -- but that would just
>> be good luck, not good planning, right?
>>
>> >
>> > after 1.4 is out the door, we should talk about cocoon 2.2 anyways, 
>> and
>> > iiuc they are considering block-wise releases, which might 
>> complicate a
>> > few things for us...
>> >
>> >
>> > regards,
>> >
>> > jörn
>
>
> I'm sorry to bring this up again, but another month and a half has
> past and Lenya's SVN external for Cocoon is still pointing to the
> unreleased Cocoon trunk rather than a released version.  Remember, the
> Lenya 1.4 release needs to be based on (and thoroughly tested on) a
> released version of Cocoon, and for all anybody really knows the
> 2.1.11 release of Cocoon might take a while longer.  Meanwhile Cocoon
> is likely to change even while a Lenya code freeze is in place.  And
> we have yet to test whether the released version of 2.1.10 works with
> the Lenya trunk.
>
> Maybe as a compromise the policy should be that whenever a freeze is
> announced, the SVN external is pointed at the then-released version of
> Cocoon.  We can always point at the 2.1.11 version if and when it is
> released.
>
+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: cocoon syncing

Posted by Bob Harner <bo...@gmail.com>.
On 4/5/07, Bob Harner <bo...@gmail.com> wrote:
> On 4/5/07, Joern Nettingsmeier <ne...@folkwang-hochschule.de> wrote:
> > Bob Harner wrote:
> > >
> > > As an aside, this seems to illustrate why it would be much better to
> > > base ongoing Lenya development on a *released* version of cocoon and
> > > not its trunk, right?  If 1.4 is to be released in a few weeks, it
> > > would have to be based on Cocoon's most recent release, right?  That's
> > > 2.1.10.  The last I heard was that most Lenya developers are using the
> > > Cocoon trunk rather than the 2.1.10 release (is this still the case?),
> > > which means that significant extra testing (and patching?) would need
> > > to be done before releasing 1.4.
> >
> > important point. but the 2.1.11 release is imminent, and so we might
> > have a good chance of a sync'ed release.
> >
> > in general, i prefer following the cocoon trunk during most of the
> > development cycle (continous integration among apache projects does
> > create some friction, but it's generally a Good Thing imho), but i agree
> > that we should "freeze" our cocoon external a lot earlier in future
> > releases, to guarantee proper testing.
>
> Are there features/fixes in Cocoon 2.1.11 that Lenya requires?  Does
> anybody even know?
>
> Continuous integration is great for developers who are working closely
> together.  It is often a nightmare for those who aren't.  Hopefully
> 2.1.11 will come out soon and it won't matter -- but that would just
> be good luck, not good planning, right?
>
> >
> > after 1.4 is out the door, we should talk about cocoon 2.2 anyways, and
> > iiuc they are considering block-wise releases, which might complicate a
> > few things for us...
> >
> >
> > regards,
> >
> > jörn


I'm sorry to bring this up again, but another month and a half has
past and Lenya's SVN external for Cocoon is still pointing to the
unreleased Cocoon trunk rather than a released version.  Remember, the
Lenya 1.4 release needs to be based on (and thoroughly tested on) a
released version of Cocoon, and for all anybody really knows the
2.1.11 release of Cocoon might take a while longer.  Meanwhile Cocoon
is likely to change even while a Lenya code freeze is in place.  And
we have yet to test whether the released version of 2.1.10 works with
the Lenya trunk.

Maybe as a compromise the policy should be that whenever a freeze is
announced, the SVN external is pointed at the then-released version of
Cocoon.  We can always point at the 2.1.11 version if and when it is
released.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: cocoon syncing

Posted by Bob Harner <bo...@gmail.com>.
On 4/5/07, Joern Nettingsmeier <ne...@folkwang-hochschule.de> wrote:
> Bob Harner wrote:
> >
> > As an aside, this seems to illustrate why it would be much better to
> > base ongoing Lenya development on a *released* version of cocoon and
> > not its trunk, right?  If 1.4 is to be released in a few weeks, it
> > would have to be based on Cocoon's most recent release, right?  That's
> > 2.1.10.  The last I heard was that most Lenya developers are using the
> > Cocoon trunk rather than the 2.1.10 release (is this still the case?),
> > which means that significant extra testing (and patching?) would need
> > to be done before releasing 1.4.
>
> important point. but the 2.1.11 release is imminent, and so we might
> have a good chance of a sync'ed release.
>
> in general, i prefer following the cocoon trunk during most of the
> development cycle (continous integration among apache projects does
> create some friction, but it's generally a Good Thing imho), but i agree
> that we should "freeze" our cocoon external a lot earlier in future
> releases, to guarantee proper testing.

Are there features/fixes in Cocoon 2.1.11 that Lenya requires?  Does
anybody even know?

Continuous integration is great for developers who are working closely
together.  It is often a nightmare for those who aren't.  Hopefully
2.1.11 will come out soon and it won't matter -- but that would just
be good luck, not good planning, right?

>
> after 1.4 is out the door, we should talk about cocoon 2.2 anyways, and
> iiuc they are considering block-wise releases, which might complicate a
> few things for us...
>
>
> regards,
>
> jörn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


cocoon syncing

Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Bob Harner wrote:
>
> As an aside, this seems to illustrate why it would be much better to
> base ongoing Lenya development on a *released* version of cocoon and
> not its trunk, right?  If 1.4 is to be released in a few weeks, it
> would have to be based on Cocoon's most recent release, right?  That's
> 2.1.10.  The last I heard was that most Lenya developers are using the
> Cocoon trunk rather than the 2.1.10 release (is this still the case?),
> which means that significant extra testing (and patching?) would need
> to be done before releasing 1.4.

important point. but the 2.1.11 release is imminent, and so we might 
have a good chance of a sync'ed release.

in general, i prefer following the cocoon trunk during most of the 
development cycle (continous integration among apache projects does 
create some friction, but it's generally a Good Thing imho), but i agree 
that we should "freeze" our cocoon external a lot earlier in future 
releases, to guarantee proper testing.

after 1.4 is out the door, we should talk about cocoon 2.2 anyways, and 
iiuc they are considering block-wise releases, which might complicate a 
few things for us...


regards,

jörn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Bob Harner wrote:
> On 4/5/07, Joern Nettingsmeier <ne...@folkwang-hochschule.de> wrote:
>> vadim,
>>
>> Vadim Gritsenko wrote:
>> > Yes it's a known problem. Please bear with me (us? :), I'll try to fix
>> > it as soon as I can...
>>
>> thanks for your quick reply. i rest assured that the problem is in
>> capable hands :)
>>
>> in case it turns out to be a hard problem or you are short on time,
>> could you tell me at which revision the issue was introduced, so that i
>> can roll back?
>>
>> thanks,
>>
>> jörn
>
> As an aside, this seems to illustrate why it would be much better to
> base ongoing Lenya development on a *released* version of cocoon and
> not its trunk, right?  If 1.4 is to be released in a few weeks, it
> would have to be based on Cocoon's most recent release, right?  That's
> 2.1.10.  The last I heard was that most Lenya developers are using the
> Cocoon trunk rather than the 2.1.10 release (is this still the case?),
> which means that significant extra testing (and patching?) would need
> to be done before releasing 1.4.
>
+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Michael Wechner <mi...@wyona.com>.
Bob Harner wrote:

> On 4/5/07, Joern Nettingsmeier <ne...@folkwang-hochschule.de> wrote:
>
>> vadim,
>>
>> Vadim Gritsenko wrote:
>> > Yes it's a known problem. Please bear with me (us? :), I'll try to fix
>> > it as soon as I can...
>>
>> thanks for your quick reply. i rest assured that the problem is in
>> capable hands :)
>>
>> in case it turns out to be a hard problem or you are short on time,
>> could you tell me at which revision the issue was introduced, so that i
>> can roll back?
>>
>> thanks,
>>
>> jörn
>
>
> As an aside, this seems to illustrate why it would be much better to
> base ongoing Lenya development on a *released* version of cocoon and
> not its trunk, right?  If 1.4 is to be released in a few weeks, it
> would have to be based on Cocoon's most recent release, right?  That's
> 2.1.10.  The last I heard was that most Lenya developers are using the
> Cocoon trunk rather than the 2.1.10 release (is this still the case?),
> which means that significant extra testing (and patching?) would need
> to be done before releasing 1.4.


I also think the release and all tests should be based on a stable 
Cocoon version.

One might develop based on the trunk version of Cocoon, but I think the 
condition should be that all such development also needs to be tested 
with the stable version of Cocoon. A working "cruise-control" would 
certainly help with this, but
I am afraid it's not sufficient. Which means all devs wanting to develop 
with the most recent trunk version of Cocoon should also have a version 
based on the stable Cocoon version and test there before checking in.

Cheers

Michael

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org
+41 44 272 91 61


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Bob Harner <bo...@gmail.com>.
On 4/5/07, Joern Nettingsmeier <ne...@folkwang-hochschule.de> wrote:
> vadim,
>
> Vadim Gritsenko wrote:
> > Yes it's a known problem. Please bear with me (us? :), I'll try to fix
> > it as soon as I can...
>
> thanks for your quick reply. i rest assured that the problem is in
> capable hands :)
>
> in case it turns out to be a hard problem or you are short on time,
> could you tell me at which revision the issue was introduced, so that i
> can roll back?
>
> thanks,
>
> jörn

As an aside, this seems to illustrate why it would be much better to
base ongoing Lenya development on a *released* version of cocoon and
not its trunk, right?  If 1.4 is to be released in a few weeks, it
would have to be based on Cocoon's most recent release, right?  That's
2.1.10.  The last I heard was that most Lenya developers are using the
Cocoon trunk rather than the 2.1.10 release (is this still the case?),
which means that significant extra testing (and patching?) would need
to be done before releasing 1.4.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joern Nettingsmeier wrote:
> vadim,
> 
> Vadim Gritsenko wrote:
>> Yes it's a known problem. Please bear with me (us? :), I'll try to fix 
>> it as soon as I can...
> 
> thanks for your quick reply. i rest assured that the problem is in 
> capable hands :)
> 
> in case it turns out to be a hard problem or you are short on time, 

Try current branch...

Vadim

Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
vadim,

Vadim Gritsenko wrote:
> Yes it's a known problem. Please bear with me (us? :), I'll try to fix 
> it as soon as I can...

thanks for your quick reply. i rest assured that the problem is in 
capable hands :)

in case it turns out to be a hard problem or you are short on time, 
could you tell me at which revision the issue was introduced, so that i 
can roll back?

thanks,

jörn



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
vadim,

Vadim Gritsenko wrote:
> Yes it's a known problem. Please bear with me (us? :), I'll try to fix 
> it as soon as I can...

thanks for your quick reply. i rest assured that the problem is in 
capable hands :)

in case it turns out to be a hard problem or you are short on time, 
could you tell me at which revision the issue was introduced, so that i 
can roll back?

thanks,

jörn



Re: 2.1 trunk broken? problem with jxtemplate component...

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jörn Nettingsmeier wrote:
> hi everyone!
> 
> i've just updated my lenya tree, and the servlet engine bails out on 
> startup with this error message:
> 
> org.apache.avalon.framework.service.ServiceException: Could not find 
> component (key 
> [org.apache.cocoon.template.expression.StringTemplateParser/jxtg]) 
> (Key='org.apache.cocoon.template.expression.StringTemplateParser/jxtg')
> 
> a quick check shows that this component is declared in lenya's cocoon 
> 2.1.11-dev external, which is why i'm posting here. can anyone reproduce 
> the problem?

Yes it's a known problem. Please bear with me (us? :), I'll try to fix it as 
soon as I can...

Vadim