From dev-return-100113-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Mon Aug 04 16:33:40 2008 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 65828 invoked from network); 4 Aug 2008 16:33:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Aug 2008 16:33:40 -0000 Received: (qmail 79545 invoked by uid 500); 4 Aug 2008 16:33:38 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 79460 invoked by uid 500); 4 Aug 2008 16:33:38 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 79449 invoked by uid 99); 4 Aug 2008 16:33:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2008 09:33:38 -0700 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates 216.86.168.178 as permitted sender) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2008 16:32:42 +0000 Received: from [192.168.1.235] (unknown [217.116.183.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6FDBB23E4A0 for ; Mon, 4 Aug 2008 12:33:07 -0400 (EDT) Message-ID: <48972F2C.3070005@tuffmail.com> Date: Mon, 04 Aug 2008 18:32:44 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Release subprojects References: <4892D370.9090005@apache.org> <4893238E.3020309@tuffmail.com> <489601E0.3020106@apache.org> In-Reply-To: <489601E0.3020106@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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? 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. >> 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. >> In short: go ahead and thanks! :) > > I will create the release artifacts tomorrow or on Tuesday. Great. Now I should follow with mine releases... -- Grzegorz Kossakowski