Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44023B5E.9020704@nada.kth.se>
Date: Mon, 27 Feb 2006 00:35:58 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Dependency on WebApplicationContext
References: <4400A609.2080104@nada.kth.se> <4400AED4.7080106@apache.org>
 <4400BB69.1090009@nada.kth.se> <4401D7BF.3080902@apache.org>
 <4401EC19.8070106@apache.org>
In-Reply-To: <4401EC19.8070106@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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