cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: Release subprojects
Date Mon, 04 Aug 2008 16:37:55 GMT
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Grzegorz Kossakowski wrote:
>>> Reinhard Pötz pisze:
>>>>
>>>> As announced some weeks ago, I want to release
>>>>
>>>>  . cocoon-servlet-service-impl-1.1.0
>>>>    A new minor release is necessary because after some refactorings
>>>>    the dependency on SourceResolve is gone.
>>>
>>> I thought that both SSF and Configurator are not back-compatible. Am 
>>> I wrong?
>>
>> Here is the relevant change of 
>> ServletServiceContext#getResource(String path)
>>
>> old implementation:
>> -------------------
>>
>> public URL getResource(String path) throws MalformedURLException {
>>     // hack for getting a file protocol or other protocols that
>>     // can be used as context
>>     // path in the getResource method in the servlet context
>>     if (!(contextPath.startsWith("file:") || contextPath.startsWith("/")
>>           || contextPath.indexOf(':') == -1)) {
>>         SourceResolver resolver = null;
>>         Source source = null;
>>         try {
>>           BeanFactory factory = 
>> WebApplicationContextUtils.getRequiredWebApplicationContext(this);
>>           resolver = (SourceResolver)
>>                      factory.getBean(SourceResolver.ROLE);
>>             source = resolver.resolveURI(contextPath);
>>             contextPath = source.getURI();
>>         } catch (IOException e) {
>>             throw new MalformedURLException("Could not resolve "
>>                 + contextPath + " due to " + e);
>>         } finally {
>>             if (resolver != null) {
>>                 resolver.release(source);
>>             }
>>         }
>>     }
>>
>>     // HACK: allow file:/ URLs for reloading of sitemaps
>>     // during development
>>     if (this.contextPath.startsWith("file:")) {
>>         return new URL("file", null,
>>           this.contextPath.substring("file:".length()) + path);
>>     }
>>
>>     if (this.contextPath.length() != 0 && this.contextPath.charAt(0)
>>          != '/') {
>>         throw new MalformedURLException("The contextPath must "
>>             + "be empty or start with '/' " + this.contextPath);
>>     }
>>
>>     // prefix the path with the servlet context resolve and
>>     // resolve in the embedding
>>     // servlet context
>>     return super.getResource(this.contextPath + path);
>> }
>>
>> new implementation:
>> -------------------
>>
>> public URL getResource(String path) throws MalformedURLException {
>>     if (path == null || !path.startsWith("/")) {
>>         throw new MalformedURLException("The path must begin " +
>>                 + "with a '/' and is interpreted "
>>                 + "as relative to the current context root.");
>>     }
>>
>>     // lazy initialization of the base URL
>>     synchronized (this) {
>>         if (this.contextPathURL == null) {
>>             this.contextPathURL = new URL(this.contextPath);
>>         }
>>     }
>>
>>     return new URL(this.contextPathURL, path.substring(1));
>> }
>>
>> The problem with the old SSF was that it _only_ worked, if it was used 
>> together with Cocoon 2.2. After this change the SSF completely relies 
>> on the standard URL handling and can really be used now in every 
>> environment and not only together with Cocoon 2.2.
> 
> Yes, as we can see in the old implementation SSF depended on 
> SourceResolver for which the only implementation is the 
> CocoonSourceResolver. That means basically, that SSF had a hidden 
> dependency on cocoon-core.
> 
>> This requires some changes in Cocoon (-> use JNet to resolve 
>> blockcontext:/ URLs) but since we can be sure that nobody else than 
>> Cocoon 2.2 was able to use the SSF 1.0, I think that a release of 1.1 
>> is appropriate in this case.
> 
> Isn't it that SSF depends now on JNet?

If you want to support other protocols than those that are supported by 
the JVM you have to register them. JNet is one possibility.

> Even if there is a new dependency I would go with 1.1 version. We are 
> not really breaking any kind of back-compatibility as there was hardly a 
> defined contract that we are breaking. It's more that now we introduce 
> one which deserves minor release.

Ok, then we agree on this :-)

> 
>>> I've just committed missing entry describing ResourceFilter feature 
>>> I've introduced. The missing items are:
>>> 1. Migration document that describes briefly how to migrate to 2.0.0 
>>> of Configurator.
>>> 2. Documentation of ResourceFilter.
>>>
>>> Even if both of them are not blockers it would be nice if you could 
>>> prepare migration document and I'll take care of the second one. If 
>>> you are really busy, then I could write this migration document but 
>>> that would involve some research on what back-incompatibilities have 
>>> been introduced.
>>
>> I can't promise too much but I will see what I can do.
> 
> Ok. Don't forget to change version of Xml Schema for Spring Configurator 
> to 2.0.

thanks for the reminder!

>>> In short: go ahead and thanks! :) 
>>
>> I will create the release artifacts tomorrow or on Tuesday.
> 
> Great. Now I should follow with mine releases...

:-)

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                          http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Mime
View raw message