You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2006/02/25 19:46:33 UTC
Dependency on WebApplicationContext
I'm trying to get the blocks fw working again after the switch to
Spring. It doesn't seem to be particularly easy as the tree processor
now is sprinkled with concrete references to
CocoonXmlWebApplicationContext which in turn extends the
org.springframework.web.context.support.XmlWebApplicationContext which
has one of the more bloated APIs that I have had the misfortune to see
http://www.springframework.org/docs/api/org/springframework/web/context/support/XmlWebApplicationContext.html.
I thought that we had the goal to make Cocoon layered and make e.g. the
sitemap processor usable outside Cocoon. And that the point with Spring
was to make Cocoon independent of the container. With the concrete
references to the above monster of a class we make Cocoon (if possible)
even more monolithic.
I'm completely against having the treeprocessor hardwired to that freak
class. The treeprocessor should depend on a (small) interface that
describe what it actually need from its container.
Right now it feels like there are hours an hours of work before I get
back to have a working block implementation again.
Carsten, the next time you feel like doing a major refactoring of
something that affects other developers, I would really appreciate if
you discussed the design for a while, so that the rest of us can give
some input.
It would also be better if you made sure that major pieces actually work
before throwing away the old working code, and destroy the work for
others (me).
/Daniel
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
The problem here is that our snapshot repository isn't updated anymore.
Jorg automated snapshots:
http://marc.theaimsgroup.com/?t=113710209200005&r=1&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113785932205693&w=2
But as can be seen in
http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/ they
are not built anymore. Probably one just need to restart the Continuum,
anyone who knows how to do that?
If we don't succeed in starting the automated build, we should probably
remove the reference to the snapshot repository as it will confuse
people if they build a newly updated block with one and a half month old
dependent blocks.
/Daniel
Reinhard Poetz skrev:
> Carsten Ziegeler wrote:
>> Reinhard Poetz wrote:
>>
>>> Carsten, can you call it again and add a few parameters:
>>>
>>> mvn cocoon:simple-deploy -e -X >stacktrace.txt
>>>
>>> and send me the file? Thank you!
>>>
>>
>> Sure, I'll send it to you directly (because of the size)
>
> As I wrote to you directly, the problem is that
> cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
>
> mvn clean install
>
> from the project's base directory should solve the problem.
Re: Dependency on WebApplicationContext
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Carsten Ziegeler schrieb:
>
>>Reinhard Poetz schrieb:
>>
>>>Carsten Ziegeler wrote:
>>>
>>>>Reinhard Poetz wrote:
>>>>
>>>>
>>>>>As I wrote to you directly, the problem is that
>>>>>cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
>>>>>
>>>>>mvn clean install
>>>>>
>>>>
>>>>>from the project's base directory should solve the problem.
>>>>I had to do this twice (strange), but now it works. Thanks!
>>>
>>>If you start Jetty then (mvn jetty6:run), and call http://localhost:8888/test,
>>>do you get an error (see below)?
>>>
>>>Is the global component registry, as implemented based on ECM, in place again?
>>
>>I'll test this tonight,
>>
>
> Ok, this works for me now; I get the simple xml page - no errors.
Thanks, it works for me now too!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler schrieb:
> Reinhard Poetz schrieb:
>> Carsten Ziegeler wrote:
>>> Reinhard Poetz wrote:
>>>
>>>> As I wrote to you directly, the problem is that
>>>> cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
>>>>
>>>> mvn clean install
>>>>
>>> >from the project's base directory should solve the problem.
>>> I had to do this twice (strange), but now it works. Thanks!
>> If you start Jetty then (mvn jetty6:run), and call http://localhost:8888/test,
>> do you get an error (see below)?
>>
>> Is the global component registry, as implemented based on ECM, in place again?
> I'll test this tonight,
>
Ok, this works for me now; I get the simple xml page - no errors.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz schrieb:
> Carsten Ziegeler wrote:
>> Reinhard Poetz wrote:
>>
>>> As I wrote to you directly, the problem is that
>>> cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
>>>
>>> mvn clean install
>>>
>> >from the project's base directory should solve the problem.
>> I had to do this twice (strange), but now it works. Thanks!
>
> If you start Jetty then (mvn jetty6:run), and call http://localhost:8888/test,
> do you get an error (see below)?
>
> Is the global component registry, as implemented based on ECM, in place again?
I'll test this tonight,
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>
>>As I wrote to you directly, the problem is that
>>cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
>>
>>mvn clean install
>>
>>from the project's base directory should solve the problem.
>>
>
> I had to do this twice (strange), but now it works. Thanks!
If you start Jetty then (mvn jetty6:run), and call http://localhost:8888/test,
do you get an error (see below)?
Is the global component registry, as implemented based on ECM, in place again?
14014 [BoundedThreadPool0-1] WARN / - BlocksManager: [DEBUG] Handler type = org.
apache.cocoon.core.container.handler.ThreadSafeComponentHandler
14014 [BoundedThreadPool0-1] WARN / - BlocksManager: [DEBUG] ComponentFactory cr
eating new instance of org.apache.cocoon.components.source.CocoonSourceResolver.
14014 [BoundedThreadPool0-1] WARN / - BlocksManager: [WARNING] ComponentLocator
exception from parent SM during lookup.
java.lang.NullPointerException
at org.apache.cocoon.core.container.CoreServiceManager.lookup(CoreServic
eManager.java:378)
at org.apache.cocoon.core.container.CoreServiceManager.lookup(CoreServic
eManager.java:373)
at org.apache.cocoon.container.ECMBlockServiceManager.lookup(ECMBlockSer
viceManager.java:212)
at org.apache.cocoon.sitemap.SitemapServlet.init(SitemapServlet.java:90)
at org.apache.cocoon.blocks.servlet.BlockManager.init(BlockManager.java:
144)
at org.apache.cocoon.blocks.servlet.BlocksManager.init(BlocksManager.jav
a:185)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.jav
a:377)
at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java
:322)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:400
)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
50)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
95)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:164)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:5
36)
at org.mortbay.jetty.Server.handle(Server.java:309)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:364)
at org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:46)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpCo
nnection.java:612)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:485)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:194)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:298)
at org.mortbay.jetty.nio.SelectChannelConnector$HttpEndPoint.run(SelectC
hannelConnector.java:710)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:412)
14014 [BoundedThreadPool0-1] WARN / - BlocksManager: [DEBUG] Could not find comp
onent for role: [org.apache.cocoon.core.Settings]
14014 [BoundedThreadPool0-1] WARN org.mortbay.log - /favicon.ico:
org.apache.cocoon.core.container.ServiceNotFoundException: Could not find compon
ent for role: [org.apache.cocoon.core.Settings] (Key='org.apache.cocoon.core.Set
tings')
at org.apache.cocoon.core.container.CoreServiceManager.lookup(CoreServic
eManager.java:439)
at org.apache.cocoon.container.ECMBlockServiceManager.lookup(ECMBlockSer
viceManager.java:212)
at org.apache.cocoon.sitemap.SitemapServlet.init(SitemapServlet.java:90)
at org.apache.cocoon.blocks.servlet.BlockManager.init(BlockManager.java:
144)
at org.apache.cocoon.blocks.servlet.BlocksManager.init(BlocksManager.jav
a:185)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.jav
a:377)
at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java
:322)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:400
)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
50)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
95)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:164)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:5
36)
at org.mortbay.jetty.Server.handle(Server.java:309)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:364)
at org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:46)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpCo
nnection.java:612)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:485)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:194)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:298)
at org.mortbay.jetty.nio.SelectChannelConnector$HttpEndPoint.run(SelectC
hannelConnector.java:710)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:412)
14014 [BoundedThreadPool0-1] WARN org.mortbay.log - /favicon.ico
org.apache.cocoon.core.container.ServiceNotFoundException: Could not find compon
ent for role: [org.apache.cocoon.core.Settings] (Key='org.apache.cocoon.core.Set
tings')
at org.apache.cocoon.core.container.CoreServiceManager.lookup(CoreServic
eManager.java:439)
at org.apache.cocoon.container.ECMBlockServiceManager.lookup(ECMBlockSer
viceManager.java:212)
at org.apache.cocoon.sitemap.SitemapServlet.init(SitemapServlet.java:90)
at org.apache.cocoon.blocks.servlet.BlockManager.init(BlockManager.java:
144)
at org.apache.cocoon.blocks.servlet.BlocksManager.init(BlocksManager.jav
a:185)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.jav
a:377)
at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java
:322)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:400
)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
50)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
95)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:164)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:5
36)
at org.mortbay.jetty.Server.handle(Server.java:309)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:364)
at org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:46)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpCo
nnection.java:612)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:485)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:194)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:298)
at org.mortbay.jetty.nio.SelectChannelConnector$HttpEndPoint.run(SelectC
hannelConnector.java:710)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:412)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> As I wrote to you directly, the problem is that
> cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
>
> mvn clean install
>
> from the project's base directory should solve the problem.
>
I had to do this twice (strange), but now it works. Thanks!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>
>>Carsten, can you call it again and add a few parameters:
>>
>>mvn cocoon:simple-deploy -e -X >stacktrace.txt
>>
>>and send me the file? Thank you!
>>
>
> Sure, I'll send it to you directly (because of the size)
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base directory should solve the problem.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> Carsten, can you call it again and add a few parameters:
>
> mvn cocoon:simple-deploy -e -X >stacktrace.txt
>
> and send me the file? Thank you!
>
Sure, I'll send it to you directly (because of the size)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
>>Could somebody of you have a look at this? If you want to reproduce this
>>exception, go into
>>.\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and call
>>
>>mvn cocoon:simple-deploy jetty6:run
>>
>
> I can't get this running; I get a NoSuchMethodError in the
> SingleBlockDeployMojo#execute method.
Carsten, can you call it again and add a few parameters:
mvn cocoon:simple-deploy -e -X >stacktrace.txt
and send me the file? Thank you!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom schrieb:
>
>> For your questions about creating Core and Settings I use a
>> o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
>> and flexibility compared to the ordinary one, it just use the servlet
>> config as input. It is used within the ECMBlocksServiceManager.
>>
> Ok, can we try to use the same code (= same CoreUtil); I think this
> would avoid duplicate efforts. I cleaned up the core CoreUtil a little
> bit and the BootstrapEnvironment interface got a lot smaller; I think I
> can get away with most of the other methods there as well, leaving just
> some configuration hooks. And this would then make the
> BootstrapEnvironment optional. So you could just invoke the CoreUtil
> with a o.a.c.environment.Context object (which inherits from
> ServletContext). Would this work for you?
It would work for me.
The reason that I used an own refactored and simplified version of the
CoreUtil was that I had a number of requirements that I didn't see how
to fulfill in the original one without risking to affect the rest of Cocoon.
* I wanted to get rid of the complications with several environments by
just using a servlet context. - No problem anymore.
* I needed to get rid of the state fullness. Before the CoreUtil kept
some state so that it wasn't enough to use it on setup, it was to be
kept and used later. I see that you have removed most of that, the only
essential part remaining is the processor reloading. And I don't need to
use that so it doesn't hurt.
* I needed to be able to create Core, Settings and Avalon Context one at
a time, due to various life cycle issues in the block architecture and
component manager bridge. This is the only remaining issue. But it
shouldn't be that hard impose the same structure of the original
CoreUtil as I did in the servlet.CoreUtil. I think that such a change
make the code easier to follow as well.
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> Daniel Fagerstrom wrote:
>>
>>> After you made the Settings object available on its own the Core doesn't
>>> seem to be used much anymore. So it seem like a good idea to remove it.
>>> The only remaining use seem to be as a shielding of the
>>> EnvironmentHelper. What is your plan for that functionality?
>>>
>> I think we can make this available through the BeanFactory as well; but
>> I'm not sure if this is a proper use of a bean factory. So basically,
>> you have to lookup the bean each time you use it. WDYT?
>
> I'm not certain either. The solution with you choose with a statically
> available thread local, lead to less code, so it seem like a good
> solution :)
>
Yes :) Now, the idea with the Core object was to provide a "cleaner"
interface to the static methods. I think, I'll create a utility class
with static methods that wrap the environment helper stuff. This allows
us to later change the internal stuff (environment helper etc) if
required with breaking any api.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>
>> After you made the Settings object available on its own the Core doesn't
>> seem to be used much anymore. So it seem like a good idea to remove it.
>> The only remaining use seem to be as a shielding of the
>> EnvironmentHelper. What is your plan for that functionality?
>>
> I think we can make this available through the BeanFactory as well; but
> I'm not sure if this is a proper use of a bean factory. So basically,
> you have to lookup the bean each time you use it. WDYT?
I'm not certain either. The solution with you choose with a statically
available thread local, lead to less code, so it seem like a good
solution :)
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> After you made the Settings object available on its own the Core doesn't
> seem to be used much anymore. So it seem like a good idea to remove it.
> The only remaining use seem to be as a shielding of the
> EnvironmentHelper. What is your plan for that functionality?
>
I think we can make this available through the BeanFactory as well; but
I'm not sure if this is a proper use of a bean factory. So basically,
you have to lookup the bean each time you use it. WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Carsten Ziegeler schrieb:
>> Daniel Fagerstrom schrieb:
>>
>>> For your questions about creating Core and Settings I use a
>>> o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
>>> and flexibility compared to the ordinary one, it just use the servlet
>>> config as input. It is used within the ECMBlocksServiceManager.
>>>
>> Ok, can we try to use the same code (= same CoreUtil); I think this
>> would avoid duplicate efforts. I cleaned up the core CoreUtil a little
>> bit and the BootstrapEnvironment interface got a lot smaller; I think I
>> can get away with most of the other methods there as well, leaving just
>> some configuration hooks. And this would then make the
>> BootstrapEnvironment optional. So you could just invoke the CoreUtil
>> with a o.a.c.environment.Context object (which inherits from
>> ServletContext). Would this work for you?
>>
> The BootstrapEnvironment is now optional and all you need is a
> o.a.c.e.Context
> object for the CoreUtil.
Thanks!
> I'm also wondering if we can remove the Core object as we could imho
> provide the whole functionality through the BeanFactory.
After you made the Settings object available on its own the Core doesn't
seem to be used much anymore. So it seem like a good idea to remove it.
The only remaining use seem to be as a shielding of the
EnvironmentHelper. What is your plan for that functionality?
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler schrieb:
> Daniel Fagerstrom schrieb:
>
>> For your questions about creating Core and Settings I use a
>> o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
>> and flexibility compared to the ordinary one, it just use the servlet
>> config as input. It is used within the ECMBlocksServiceManager.
>>
> Ok, can we try to use the same code (= same CoreUtil); I think this
> would avoid duplicate efforts. I cleaned up the core CoreUtil a little
> bit and the BootstrapEnvironment interface got a lot smaller; I think I
> can get away with most of the other methods there as well, leaving just
> some configuration hooks. And this would then make the
> BootstrapEnvironment optional. So you could just invoke the CoreUtil
> with a o.a.c.environment.Context object (which inherits from
> ServletContext). Would this work for you?
>
The BootstrapEnvironment is now optional and all you need is a
o.a.c.e.Context
object for the CoreUtil.
I'm also wondering if we can remove the Core object as we could imho
provide the whole functionality through the BeanFactory.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom schrieb:
>
> For your questions about creating Core and Settings I use a
> o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
> and flexibility compared to the ordinary one, it just use the servlet
> config as input. It is used within the ECMBlocksServiceManager.
>
Ok, can we try to use the same code (= same CoreUtil); I think this
would avoid duplicate efforts. I cleaned up the core CoreUtil a little
bit and the BootstrapEnvironment interface got a lot smaller; I think I
can get away with most of the other methods there as well, leaving just
some configuration hooks. And this would then make the
BootstrapEnvironment optional. So you could just invoke the CoreUtil
with a o.a.c.environment.Context object (which inherits from
ServletContext). Would this work for you?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
I don't understand why you get these problems. When I run the test cases
in the cocoon-blocks-fw-servlet-impl, I first got problems with setting
up a logger that depended on a Settings object in the BlocksServlet. I
replaced the logger with a ServletLogger, to get further.
The next (and worse problem) is that I get a NPE in line 137 in
SitemapLanguage, the problem here is that the blocks fw use the now
obsolete ECMBlocksServiceManager for creating components. But the
SitemapLanguage implements BeanFactoryAware and assumes that the factory
give it a BeanFactory, something the ECM++ of course is completely
unaware about.
There are two solutions to this. One is to make the component manager
more "optional" in the tree processor, so that the tree processor only
is required to be served by the Spring container if there actually are
configurations inside the sitemap. This seem to be a feasible solution
as discussed in other mails in this thread. It would give us the
possibility to continue the work on blocks fw and deployer, although
with a little bit reduced functionality.
The other possibility, and the one that we should implement eventually
is to replace the ECMBlocksServiceManager with one that use the new
Spring container. As said we should absolutely do this, but I don't
suspect it to be that easy, so I would prefer to be able to not need to
do this immediately.
For your questions about creating Core and Settings I use a
o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
and flexibility compared to the ordinary one, it just use the servlet
config as input. It is used within the ECMBlocksServiceManager.
/Daniel
Carsten Ziegeler skrev:
> Reinhard Poetz wrote:
>> AFAIU the initialization of Cocoon has changed from within the blocks-fw. IIUC
>> CoreUtil is never initialized and therefore the settings object isn't
>> initialized either.
>>
>> I get a NullPointException in line 174 of the ApplicationContextFactory:
>>
>> final File logSCDir = new File(settings.getWorkDirectory(), "cocoon-logs");
>>
>> (settings.getWorkDirectory() returns null)
>>
> Yes, this is the problem I tried to explain in this thread :) The core
> is structured in a way that it assumes to have a Core object and a
> global settings object containing most of the configuration for the
> whole installation (like working directory etc.) Without this, several
> parts of Cocoon will fail.
> Now, with the blocks-fw in place, is there anything wrong with this
> assumption? Can we setup the Core and settings object somewhere? Or do
> we need a different solution?
> A workaround for the NPE would be to set the working directory in the
> BlocksManager#init(ServletConfig) method.
>
>> Could somebody of you have a look at this? If you want to reproduce this
>> exception, go into
>> .\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and call
>>
>> mvn cocoon:simple-deploy jetty6:run
>>
> I can't get this running; I get a NoSuchMethodError in the
> SingleBlockDeployMojo#execute method.
>
> Carsten
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> AFAIU the initialization of Cocoon has changed from within the blocks-fw. IIUC
> CoreUtil is never initialized and therefore the settings object isn't
> initialized either.
>
> I get a NullPointException in line 174 of the ApplicationContextFactory:
>
> final File logSCDir = new File(settings.getWorkDirectory(), "cocoon-logs");
>
> (settings.getWorkDirectory() returns null)
>
Yes, this is the problem I tried to explain in this thread :) The core
is structured in a way that it assumes to have a Core object and a
global settings object containing most of the configuration for the
whole installation (like working directory etc.) Without this, several
parts of Cocoon will fail.
Now, with the blocks-fw in place, is there anything wrong with this
assumption? Can we setup the Core and settings object somewhere? Or do
we need a different solution?
A workaround for the NPE would be to set the working directory in the
BlocksManager#init(ServletConfig) method.
>
> Could somebody of you have a look at this? If you want to reproduce this
> exception, go into
> .\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and call
>
> mvn cocoon:simple-deploy jetty6:run
>
I can't get this running; I get a NoSuchMethodError in the
SingleBlockDeployMojo#execute method.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> I'm sorry for that. Of course this was not my intention. Where exactly
>> are your problems? For me at least everything compiles.
>
>
> My testcases:
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/java/org/apache/cocoon/blocks/servlet/BlocksManagerTestCase.java,
> doesn't work anymore. The blocks samples
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/,
> doesn't work anymore. Reinhard's work on block deployment
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/,
> doesn't work anymore.
AFAIU the initialization of Cocoon has changed from within the blocks-fw. IIUC
CoreUtil is never initialized and therefore the settings object isn't
initialized either.
I get a NullPointException in line 174 of the ApplicationContextFactory:
final File logSCDir = new File(settings.getWorkDirectory(), "cocoon-logs");
(settings.getWorkDirectory() returns null)
Could somebody of you have a look at this? If you want to reproduce this
exception, go into
.\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and call
mvn cocoon:simple-deploy jetty6:run
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
I cleaned up the implementation: we now just depend on a
ConfigurableBeanFactory - we can make use of the ConfigurableBeanFactory
as it supports kind of a shutdown functionality.
Now, I think the next step should really be to separate the container
creation for a sitemap from creating the processing tree for this
sitemap. I think if we go this way, we have a clean separation and the
tree processor should be completly independent from it's container.
If noone objects I can try this in the next days.
Carsten
Carsten Ziegeler wrote:
> Carsten Ziegeler wrote:
>
>> Ok, I start to see your point; may be we should forget about the whole
>> application context and just use the bean factory. I'll see if this
>> works out.
>>
> I'm currently refactoring the core to just use a bean factory and remove
> some
> of the dependencies between the tree processor and the container.
>
> Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Ok, I start to see your point; may be we should forget about the whole
> application context and just use the bean factory. I'll see if this
> works out.
>
I'm currently refactoring the core to just use a bean factory and remove
some
of the dependencies between the tree processor and the container.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> Carsten Ziegeler skrev:
>>> Daniel Fagerstrom wrote:
>> ...
>>>> IMO the use of both application contexts and service managers in the
>>>> tree processor is not such a good idea. It makes the code really hard to
>>>> follow, we should avoid mixed models in the same piece of code.
>>> Absolutely; remember :) this is the first version which aim was to "just
>>> work"; so removing all the Avalon based stuff should be the next step.
>> Hmm, here we need to discuss what we aiming for. Replacing our own ECM
>> with Spring for creating Avalon components is great as we don't need to
>> support our own container anymore. Giving users a better possibility to
>> use Spring for their applications is also great.
>>
>> Giving us and them the possibility to mix Spring and Avalon setup in the
>> same block and even in the same component is less great IMO.
> I agree to "within the same component"; I don't agree totally to "within
> the same block" as you can use your own "legacy avalon" components in a
> block while adding new spring based ones. Though I agree that these are
> rare cases which should disappear over time.
There might be cases. If a block is so large that we don't want to
switch component management style in one go, it might be that the block
would better be split into several blocks.
It is enough work to learn to understand one component management system
for someone who want to contribute to a block. Needing to learn to would
be a rather forbidding threshold.
>> It would IMO be a step forward if we could replace most uses of
>> Serviceable with setter injection, this would lead to components that
>> are easier to reuse and test. But making a mechanical replacement of
>> ServiceManager with BeanFactory will be much work with questionable
>> advantages.
> Agreed.
>
>> Also Spring configurations are not exactly easier to manage than our
>> current configuration files,
>> http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/applicationContext.xml.
>>
>> So before we run away and remove all the Avalon stuff we need to make
>> clear what we aiming for.
> Exactly - now, I think we should not convert all of our stuff; the only
> component I think were it makes sense to do it today is the tree
> processor; this would imho clean up this code and make it even more
> understandable for others.
I'd prefer if we start splitting up core in smaller parts before we do
such operations. The we can try the consequences of changing component
management in the tree processor in a branch first.
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> Daniel Fagerstrom wrote:
> ...
>>> IMO the use of both application contexts and service managers in the
>>> tree processor is not such a good idea. It makes the code really hard to
>>> follow, we should avoid mixed models in the same piece of code.
>> Absolutely; remember :) this is the first version which aim was to "just
>> work"; so removing all the Avalon based stuff should be the next step.
>
> Hmm, here we need to discuss what we aiming for. Replacing our own ECM
> with Spring for creating Avalon components is great as we don't need to
> support our own container anymore. Giving users a better possibility to
> use Spring for their applications is also great.
>
> Giving us and them the possibility to mix Spring and Avalon setup in the
> same block and even in the same component is less great IMO.
I agree to "within the same component"; I don't agree totally to "within
the same block" as you can use your own "legacy avalon" components in a
block while adding new spring based ones. Though I agree that these are
rare cases which should disappear over time.
>
> It would IMO be a step forward if we could replace most uses of
> Serviceable with setter injection, this would lead to components that
> are easier to reuse and test. But making a mechanical replacement of
> ServiceManager with BeanFactory will be much work with questionable
> advantages.
Agreed.
>
> Also Spring configurations are not exactly easier to manage than our
> current configuration files,
> http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/applicationContext.xml.
>
> So before we run away and remove all the Avalon stuff we need to make
> clear what we aiming for.
Exactly - now, I think we should not convert all of our stuff; the only
component I think were it makes sense to do it today is the tree
processor; this would imho clean up this code and make it even more
understandable for others.
> Yes I know that Spring can make all kinds of things and provide a lot of
> flexibility. For Cocoon core parts we should choose one style and stick
> with that. Mixing styles makes the code hard to understand and support.
Agreed
>> I absolutely agree; I think we should move the container code out of the
>> tree processor, so the tree processor is just for processing the
>> pipelines and parsing *that* part of the sitemap. The container code
>> will also read the sitemap, but only the components part. This requires
>> to read the sitemap twice, but cleans up the concerns. WDYT?
>
> Agree. One possibility would be to make a component of the
> SitemapLanguage.createApplicationContext method (except maybe for the
> listener setup in the end). It could be BeanFactoryAware and LogEnabled,
> and have the createApplicationContext method as its API. AFAICS it would
> only be needed to be created if the sitemap actually contain a
> configuration element. Which would make the treeprocessor container
> dependent only when it needs internaly configured components.
Yepp, agree; i'll have a loot at this stuff today.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Daniel Fagerstrom skrev:
> Carsten Ziegeler skrev:
>> Daniel Fagerstrom wrote:
...
>>> Of course we need to create the container somewhere. But that code
>>> should be isolated, we should really avoid having dependencies on
>>> heavy weight containers all other the place.
>> I absolutely agree; I think we should move the container code out of the
>> tree processor, so the tree processor is just for processing the
>> pipelines and parsing *that* part of the sitemap. The container code
>> will also read the sitemap, but only the components part. This requires
>> to read the sitemap twice, but cleans up the concerns. WDYT?
>
> Agree. One possibility would be to make a component of the
> SitemapLanguage.createApplicationContext method (except maybe for the
> listener setup in the end). It could be BeanFactoryAware and LogEnabled,
> and have the createApplicationContext method as its API. AFAICS it would
> only be needed to be created if the sitemap actually contain a
> configuration element. Which would make the treeprocessor container
> dependent only when it needs internaly configured components.
I made a hack that means that the sitemap local bean factory only is
setup when there actually is a sitemap local component configuration.
This means that the still ECM dependent blocks fw work with limited
functionality again. The test cases without sitemap internal components
succeeds.
It should be possible to continue the work on the blocks deployer.
I will of course work on switching the blocks fw to the new container,
but now we can focus on getting the new contaner stable first.
/Daniel
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
...
>> IMO the use of both application contexts and service managers in the
>> tree processor is not such a good idea. It makes the code really hard to
>> follow, we should avoid mixed models in the same piece of code.
> Absolutely; remember :) this is the first version which aim was to "just
> work"; so removing all the Avalon based stuff should be the next step.
Hmm, here we need to discuss what we aiming for. Replacing our own ECM
with Spring for creating Avalon components is great as we don't need to
support our own container anymore. Giving users a better possibility to
use Spring for their applications is also great.
Giving us and them the possibility to mix Spring and Avalon setup in the
same block and even in the same component is less great IMO.
It would IMO be a step forward if we could replace most uses of
Serviceable with setter injection, this would lead to components that
are easier to reuse and test. But making a mechanical replacement of
ServiceManager with BeanFactory will be much work with questionable
advantages.
Also Spring configurations are not exactly easier to manage than our
current configuration files,
http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/applicationContext.xml.
So before we run away and remove all the Avalon stuff we need to make
clear what we aiming for.
>> It might be that we at some point want to switch from Avalon style to
>> setter injection in our components. But that must be done one component
>> at the time not for parts of the component.
> Please note, that with spring you do not depend on setter injection. You
> can get the application context (= service manager) and then dynamically
> lookup the components *if* you want; but of course this is not the
> "clean spring way of doing it".
Yes I know that Spring can make all kinds of things and provide a lot of
flexibility. For Cocoon core parts we should choose one style and stick
with that. Mixing styles makes the code hard to understand and support.
>>> Hmm, I see that ECMBlockServiceManager has several problems; for example
>>> it creates a Core and a settings object which it definitly should not as
>>> there should only be one Core object and settings object for the whole
>>> Cocoon installation.
>> Then we need to change the Core as it contain the current ServletContext
>> which is block local. Each block is an isolated unit with its own
>> context. Because of this I needed one Core for each block. On a
>> different note most of the methods in Core doesn't seem to be used anywhere.
> Not yet, they are a try to move away from the avalon Context object; but
> I understand your concern with the servlet context. Hmm, I'll have a
> look at that as well.
Good.
>> The Settings could probably be made global.
> Hmm, I think perhaps a hierarchy of settings would make sense: one for
> the core and then a settings object per block which inherits global
> settings from the core settings object.
That could work.
>>> Now, I see that the current ECMBlockServiceManager implements the usual
>>> Avalon stuff; can we assume that the service manager which is feed into
>>> the service() method is either the root service manager or a child of
>>> it? In that case, that one already contains the Core object etc.
>> There is no real root service manager in the current blocks fw, the
>> service managers of the blocks are siblings. The parent manager for the
>> blocks is just the service manager registry that redirect the look up to
>> the block that contains the component.
> Hmm, is there no "core" or some equivalent to that, which sets up the
> blocks system?
The BlocksManager sets up the blocks. When we move it to OSGi there will
be a small set of services: log service, http service (bridge),
configurations service, declarative components service and maybe a
preferences service, that are started before all the blocks and that
provide commonly needed functionality and settings.
>> and then in practice we depend on an interface with maybe 100 methods.
>>
> The question is: is the dependency wrong or is the interface wrong?
Booth ;)
>>> If we don't want this dependency
>>> then I fear we have to create our own "container" interface as
>>> ServiceManager is definitly not enough. For example, we need a way to
>>> get the parent container
>> If we use Spring, HierarchicalBeanFactory should be enough.
>>
>>> and we need a way to shutdown the container and
>>> it's childs etc.
>> DisposableBean
> No, this is not enough because of the hierarchy. We can dispose a tree
> processor using DisposableBean, but in this case all childs of this tree
> processor must be disposed as well. I think, we can get this running
> somehow.
Sounds good.
>> Not convinced. As said above: Setter injection, yes. Minimal service
>> manager or bean factory type interfaces, yes. ApplicationContext, no thanks.
>>
> Ok, I start to see your point; may be we should forget about the whole
> application context and just use the bean factory. I'll see if this
> works out.
Great!
>> Of course we need to create the container somewhere. But that code
>> should be isolated, we should really avoid having dependencies on heavy
>> weight containers all other the place.
> I absolutely agree; I think we should move the container code out of the
> tree processor, so the tree processor is just for processing the
> pipelines and parsing *that* part of the sitemap. The container code
> will also read the sitemap, but only the components part. This requires
> to read the sitemap twice, but cleans up the concerns. WDYT?
Agree. One possibility would be to make a component of the
SitemapLanguage.createApplicationContext method (except maybe for the
listener setup in the end). It could be BeanFactoryAware and LogEnabled,
and have the createApplicationContext method as its API. AFAICS it would
only be needed to be created if the sitemap actually contain a
configuration element. Which would make the treeprocessor container
dependent only when it needs internaly configured components.
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> Made some work in that direction. Now only the SitemapLanguage has a
> direct dependency on XmlWebApplicationContext. I'll see if I can find a
> way to make that dependency stricter as well.
>
Great
> I introduced a NameForAliasAware interface in the process. Didn't know
> enough about the alias handling to know if the knowledge about alias
> really is necessary outside the container.
I'll have a look at that.
>
> IMO the use of both application contexts and service managers in the
> tree processor is not such a good idea. It makes the code really hard to
> follow, we should avoid mixed models in the same piece of code.
Absolutely; remember :) this is the first version which aim was to "just
work"; so removing all the avalon based stuff should be the next step.
>
> It might be that we at some point want to switch from Avalon style to
> setter injection in our components. But that must be done one component
> at the time not for parts of the component.
Please note, that with spring you do not depend on setter injection. You
can get the application context (= service manager) and then dynamically
lookup the components *if* you want; but of course this is not the
"clean spring way of doing it".
>> Hmm, I see that ECMBlockServiceManager has several problems; for example
>> it creates a Core and a settings object which it definitly should not as
>> there should only be one Core object and settings object for the whole
>> Cocoon installation.
>
> Then we need to change the Core as it contain the current ServletContext
> which is block local. Each block is an isolated unit with its own
> context. Because of this I needed one Core for each block. On a
> different note most of the methods in Core doesn't seem to be used anywhere.
Not yet, they are a try to move away from the avalon Context object; but
I understand your concern with the servlet context. Hmm, I'll have a
look at that as well.
>
> The Settings could probably be made global.
Hmm, I think perhaps a hierarchy of settings would make sense: one for
the core and then a settings object per block which inherits global
settings from the core settings object.
>
>> Now, I see that the current ECMBlockServiceManager implements the usual
>> Avalon stuff; can we assume that the service manager which is feed into
>> the service() method is either the root service manager or a child of
>> it? In that case, that one already contains the Core object etc.
>
> There is no real root service manager in the current blocks fw, the
> service managers of the blocks are siblings. The parent manager for the
> blocks is just the service manager registry that redirect the look up to
> the block that contains the component.
Hmm, is there no "core" or some equivalent to that, which sets up the
blocks system?
>
> and then in practice we depend on an interface with maybe 100 methods.
>
The question is: is the dependency wrong or is the interface wrong?
>> If we don't want this dependency
>> then I fear we have to create our own "container" interface as
>> ServiceManager is definitly not enough. For example, we need a way to
>> get the parent container
>
> If we use Spring, HierarchicalBeanFactory should be enough.
>
>> and we need a way to shutdown the container and
>> it's childs etc.
>
> DisposableBean
No, this is not enough because of the hierarchy. We can dispose a tree
processor using DisposableBean, but in this case all childs of this tree
processor must be disposed as well. I think, we can get this running
somehow.
>
> Not convinced. As said above: Setter injection, yes. Minimal service
> manager or bean factory type interfaces, yes. ApplicationContext, no thanks.
>
Ok, I start to see your point; may be we should forget about the whole
application context and just use the bean factory. I'll see if this
works out.
> Of course we need to create the container somewhere. But that code
> should be isolated, we should really avoid having dependencies on heavy
> weight containers all other the place.
I absolutely agree; I think we should move the container code out of the
tree processor, so the tree processor is just for processing the
pipelines and parsing *that* part of the sitemap. The container code
will also read the sitemap, but only the components part. This requires
to read the sitemap twice, but cleans up the concerns. WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> The users are not the only stakeholders the developers are at least as
>> important, especially in an open source community. One of the recurring
>> themes in all the NG discussions is that people are deeply frustrated
>> with not being able to try their new ideas because of the complexity of
>> Cocoon. This must be solved by simplify Cocoon and by making the
>> contracts between different parts clearer.
> I totally agree here.
>
>> IMO the direct dependence of
>> the XmlWebApplicationContext is a step in the opposite direction.
> Not necessarily - XmlWebApplicationContext has a hugh interface, but in
> fact this one is easy and everyone who knows spring knows this one
> anyway. But if we can get this one out of the tree processor, I'm all
> for it.
Made some work in that direction. Now only the SitemapLanguage has a
direct dependency on XmlWebApplicationContext. I'll see if I can find a
way to make that dependency stricter as well.
I introduced a NameForAliasAware interface in the process. Didn't know
enough about the alias handling to know if the knowledge about alias
really is necessary outside the container.
IMO the use of both application contexts and service managers in the
tree processor is not such a good idea. It makes the code really hard to
follow, we should avoid mixed models in the same piece of code.
It might be that we at some point want to switch from Avalon style to
setter injection in our components. But that must be done one component
at the time not for parts of the component.
>> Most of the code in the ecm block service manager
>> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-ecm-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java,
>> is about setting up a block local source resolver, which not is as easy
>> as one might assume.
>>
>> That particular mechanism for having a block local service manager that
>> makes components available for other blocks was mainly designed for ecm.
>> So we can do it in some other way for a Spring block service manager.
>>
>> Any ideas about how to proceed?
>>
> Hmm, I see that ECMBlockServiceManager has several problems; for example
> it creates a Core and a settings object which it definitly should not as
> there should only be one Core object and settings object for the whole
> Cocoon installation.
Then we need to change the Core as it contain the current ServletContext
which is block local. Each block is an isolated unit with its own
context. Because of this I needed one Core for each block. On a
different note most of the methods in Core doesn't seem to be used anywhere.
The Settings could probably be made global.
> Now, I see that the current ECMBlockServiceManager implements the usual
> Avalon stuff; can we assume that the service manager which is feed into
> the service() method is either the root service manager or a child of
> it? In that case, that one already contains the Core object etc.
There is no real root service manager in the current blocks fw, the
service managers of the blocks are siblings. The parent manager for the
blocks is just the service manager registry that redirect the look up to
the block that contains the component.
> But in the end, we have the same problem here as the tree processor has:
> we need to setup a Spring application context which should have a parent
> Spring application context. Setting up this context is easy, the problem
> is getting the parent context. And this is imho exactly the point where
> we depend on the container implementation. The current block
> implementation uses the Avalon interfaces which we could for example
> replace with the Spring application context (no dependency to Avalon
> anymore).
After having taking a closer look at the Spring APIs I fail to feel
enthusiastic about this scenario. Setter injection is nice and the
BeanFactory is OK, but the rest of the interfaces looks like a mess IMO.
And makes me better appreciate the elegance of the Avalon interfaces.
I would rather stay away from the fatter breed of interfaces from Spring.
> Agreed, the Spring application context interface is bigger than the
> simple ServiceManager interface, but again - it's well known - and it
> provides more useful functionality.
I find it quite ironic that Spring aim that:
* Your application code should not depend on Spring APIs
http://www.springframework.org/about
and then in practice we depend on an interface with maybe 100 methods.
> If we don't want this dependency
> then I fear we have to create our own "container" interface as
> ServiceManager is definitly not enough. For example, we need a way to
> get the parent container
If we use Spring, HierarchicalBeanFactory should be enough.
> and we need a way to shutdown the container and
> it's childs etc.
DisposableBean
> But we would again create interfaces noone knows
> upfront, increasing the learning curve.
> So I suggest, let us base all the component stuff on Spring, use the
> Spring application context (or more precisley the CocoonXml...) and
> continue from there.
Not convinced. As said above: Setter injection, yes. Minimal service
manager or bean factory type interfaces, yes. ApplicationContext, no thanks.
Of course we need to create the container somewhere. But that code
should be isolated, we should really avoid having dependencies on heavy
weight containers all other the place.
> This would mean, first seeing how this block registry could look like
> and from there implement the spring blocks impl which should be really
> trivial.
OK.
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> The users are not the only stakeholders the developers are at least as
> important, especially in an open source community. One of the recurring
> themes in all the NG discussions is that people are deeply frustrated
> with not being able to try their new ideas because of the complexity of
> Cocoon. This must be solved by simplify Cocoon and by making the
> contracts between different parts clearer.
I totally agree here.
> IMO the direct dependence of
> the XmlWebApplicationContext is a step in the opposite direction.
Not necessarily - XmlWebApplicationContext has a hugh interface, but in
fact this one is easy and everyone who knows spring knows this one
anyway. But if we can get this one out of the tree processor, I'm all
for it.
> Most of the code in the ecm block service manager
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-ecm-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java,
> is about setting up a block local source resolver, which not is as easy
> as one might assume.
>
> That particular mechanism for having a block local service manager that
> makes components available for other blocks was mainly designed for ecm.
> So we can do it in some other way for a Spring block service manager.
>
> Any ideas about how to proceed?
>
Hmm, I see that ECMBlockServiceManager has several problems; for example
it creates a Core and a settings object which it definitly should not as
there should only be one Core object and settings object for the whole
Cocoon installation.
Now, I see that the current ECMBlockServiceManager implements the usual
Avalon stuff; can we assume that the service manager which is feed into
the service() method is either the root service manager or a child of
it? In that case, that one already contains the Core object etc.
But in the end, we have the same problem here as the tree processor has:
we need to setup a Spring application context which should have a parent
Spring application context. Setting up this context is easy, the problem
is getting the parent context. And this is imho exactly the point where
we depend on the container implementation. The current block
implementation uses the Avalon interfaces which we could for example
replace with the Spring application context (no dependency to Avalon
anymore).
Agreed, the Spring application context interface is bigger than the
simple ServiceManager interface, but again - it's well known - and it
provides more useful functionality. If we don't want this dependency
then I fear we have to create our own "container" interface as
ServiceManager is definitly not enough. For example, we need a way to
get the parent container and we need a way to shutdown the container and
it's childs etc. But we would again create interfaces noone knows
upfront, increasing the learning curve.
So I suggest, let us base all the component stuff on Spring, use the
Spring application context (or more precisley the CocoonXml...) and
continue from there.
This would mean, first seeing how this block registry could look like
and from there implement the spring blocks impl which should be really
trivial.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Dependency on WebApplicationContext
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
...
>> I'm completely against having the treeprocessor hardwired to that freak
>> class. The treeprocessor should depend on a (small) interface that
>> describe what it actually need from its container.
> Yeah, sure. The tree processor has a long history and as we changed the
> underlying container now twice the code got not better from that :( I'm
> +1 for cleaning up the tree processor. But imho it's a little bit
> difficut to make it independent from the container as we have a
> hierarchy of sitemaps, creating a hierarchy of containers. So the tree
> processor needs a way to setup a container a get the parent container
> for that. Or maybe the code could be moved out of the tree processor to
> separate this.
> But on the other hand, the tree processor is working. So, is there a
> real problem (apart from being ugly) with it? If you want to use the
> tree processor, just look it up from the component manager and use it.
> It's transparent to users how it does things inside.
The users are not the only stakeholders the developers are at least as
important, especially in an open source community. One of the recurring
themes in all the NG discussions is that people are deeply frustrated
with not being able to try their new ideas because of the complexity of
Cocoon. This must be solved by simplify Cocoon and by making the
contracts between different parts clearer. IMO the direct dependence of
the XmlWebApplicationContext is a step in the opposite direction.
>> Right now it feels like there are hours an hours of work before I get
>> back to have a working block implementation again.
> I'm sorry for that. Of course this was not my intention. Where exactly
> are your problems? For me at least everything compiles.
My testcases:
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/java/org/apache/cocoon/blocks/servlet/BlocksManagerTestCase.java,
doesn't work anymore. The blocks samples
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/,
doesn't work anymore. Reinhard's work on block deployment
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/,
doesn't work anymore.
...
> Again, what is not working? As you and others have said in recent
> threads, the core is working again; there was a problem with the default
> handling of sitemap components which should be fixed now. I guess there
> are more of these minor issues which we can fix easily as soon as they
> turn up. I'm sorry that my work made your work harder, but I wasn't
> aware of any such thing; the only piece of code I'm sure I broke is the
> ecm block implementation,
Yes, that is what broke, and the blocks depend on it. Now it need to be
replaced with a new implementation that embeds the Spring bridge, as the
treeprocessor internals depends on that the parent manager respects
ApplicationContextAware.
> which I simply do not understand to get it
> fixed but I'm here to help getting that work again.
The main idea is that each block manage its own sets of components, that
it make available to the other blocks.
In the ECM block manager that is solved by the use of a global service
manager registry
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java,
the service manager within a specific block register each component id
(role) together with a reference to it self in the service manager
registry. The service manager registry is also a service manager that is
used as parent manager to all the blocks service managers, and it is
used for getting components that are managed from other blocks.
Most of the code in the ecm block service manager
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-ecm-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java,
is about setting up a block local source resolver, which not is as easy
as one might assume.
That particular mechanism for having a block local service manager that
makes components available for other blocks was mainly designed for ecm.
So we can do it in some other way for a Spring block service manager.
Any ideas about how to proceed?
> But on the other hand I did you a favour and now the Context object
> extends the ServletContext :)
:)
/Daniel
Re: Dependency on WebApplicationContext
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> I'm trying to get the blocks fw working again after the switch to
> Spring. It doesn't seem to be particularly easy as the tree processor
> now is sprinkled with concrete references to
> CocoonXmlWebApplicationContext which in turn extends the
> org.springframework.web.context.support.XmlWebApplicationContext which
> has one of the more bloated APIs that I have had the misfortune to see
> http://www.springframework.org/docs/api/org/springframework/web/context/support/XmlWebApplicationContext.html.
>
> I thought that we had the goal to make Cocoon layered and make e.g. the
> sitemap processor usable outside Cocoon. And that the point with Spring
> was to make Cocoon independent of the container. With the concrete
> references to the above monster of a class we make Cocoon (if possible)
> even more monolithic.
Hmm, not sure if we really have these goals. I guess some of us have
while others not. I think, again the open question of a common vision.
What's the real use of making the sitemap processor usable outside
Cocoon? If someone needs something like that it would be much easier to
grep the code and start a new project. Imho, Cocoon can't be made
independent of the container and I see no real benefit of trying to do
this. Imho, you loose more than you win from that.
But as I always said, the current Spring based implementation is a first
version which can be seen as a proof of concept. So we can make
everything even better from this point on.
>
> I'm completely against having the treeprocessor hardwired to that freak
> class. The treeprocessor should depend on a (small) interface that
> describe what it actually need from its container.
Yeah, sure. The tree processor has a long history and as we changed the
underlying container now twice the code got not better from that :( I'm
+1 for cleaning up the tree processor. But imho it's a little bit
difficut to make it independent from the container as we have a
hierarchy of sitemaps, creating a hierarchy of containers. So the tree
processor needs a way to setup a container a get the parent container
for that. Or maybe the code could be moved out of the tree processor to
separate this.
But on the other hand, the tree processor is working. So, is there a
real problem (apart from being ugly) with it? If you want to use the
tree processor, just look it up from the component manager and use it.
It's transparent to users how it does things inside.
>
> Right now it feels like there are hours an hours of work before I get
> back to have a working block implementation again.
I'm sorry for that. Of course this was not my intention. Where exactly
are your problems? For me at least everything compiles.
>
> Carsten, the next time you feel like doing a major refactoring of
> something that affects other developers, I would really appreciate if
> you discussed the design for a while, so that the rest of us can give
> some input.
As I outlined above, I had no design to discuss; I had a prototype which
I commited days ago and then tried to clean up in the last days. The
trickiest part in fact was the tree processor; But we now have a
starting point: we know what we want and we know how we want it; so
everything what is left is cleaning up.
>
> It would also be better if you made sure that major pieces actually work
> before throwing away the old working code, and destroy the work for
> others (me).
Again, what is not working? As you and others have said in recent
threads, the core is working again; there was a problem with the default
handling of sitemap components which should be fixed now. I guess there
are more of these minor issues which we can fix easily as soon as they
turn up. I'm sorry that my work made your work harder, but I wasn't
aware of any such thing; the only piece of code I'm sure I broke is the
ecm block implementation which I simply do not understand to get it
fixed but I'm here to help getting that work again.
But on the other hand I did you a favour and now the Context object
extends the ServletContext :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/