cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Releasing Cocoon 2.2, finally!
Date Sat, 08 Mar 2008 15:38:42 GMT
Grzegorz Kossakowski pisze:
> Reinhard Poetz pisze:
>> It's time to release Cocoon 2.2, finally! We have been working on it for
>> years and I think it's time to ship the *final* release. I want to do
>> this in three phases:
>>
>> 1) During the first phase I will release our two sub-projects "Cocoon
>> Configuration" and "Cocoon Servlet-Service-Framework". This time I will
>> create the Maven 2 release artifacts and "normal" zip/tar release
>> artifacts for non-Maven users.
>>
>> I think that I will be able to finish it by the end of next week.
>>
> 
> There is a subtle problem I discovered few days ago but I haven't reported up to date
because I
> hadn't enough free time to confirm if this problem really exist. Anyway, I think that
> cocoon-servlet-service-impl is not really Cocoon-independent because of this line:
> 
>   resolver = (SourceResolver) factory.getBean(SourceResolver.ROLE);
> 
> of getResource() method from ServletServiceContext class. The problem I can see here
is that if
> cocoon-servlet-service-impl is used outside the Cocoon there is no default implementation
of
> SourceResolver registered as a Spring bean. It's not a big deal, because Excalibur provides
such
> implementation but we would need to figure out how to register and properly set up this
component.
> 
> Actually, I see whole getResource() method flawed because it calculates contextPath when
used first
> time and I think this code should belong to the setup (not runtime) phase of ServletServiceContext.
> I already tried to move this code (I paste the patch at the end of this e-mail) but stumbled
across
> some NPEs for specific servlet bean configurations and I haven't had enough free time
to dig into
> this. I planned to take care of it during upcoming weekend because I finally get done
with all these
> exams at my university.
> 
> The root motivation for me taking a look at this code was some experimentation with Micro
Cocoon.
> Specifically, I tried to make CocoonSourceResolver casual Spring bean and due to flawed
contextPath
> initialization I ran into cyclic dependency chain.
> 
> To be honest, I don't have an idea if we should consider this a blocker. I lean towards
not
> considering this a blocker but once we sort this out we will need to release 1.1.0 version
of
> cocoon-servlet-service-impl. If I come up with the fix until Monday, do you think it's
a good idea
> to commit it just before final release? (I think it shouldn't harm and I would give it
very
> throughout testing)

Since I got no feedback I decided to commit my changes. I gave it quite detailed testing and
I don't
think it may break anything.
Anyway, if you have spare cycles, it would be great if you could test if everything still
works ok.

-- 
Grzegorz Kossakowski

Mime
View raw message