Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 81610 invoked from network); 4 Aug 2008 16:38:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Aug 2008 16:38:31 -0000 Received: (qmail 88440 invoked by uid 500); 4 Aug 2008 16:38:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 88376 invoked by uid 500); 4 Aug 2008 16:38:28 -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 88365 invoked by uid 99); 4 Aug 2008 16:38:28 -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:38:28 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [88.198.46.98] (HELO indoqa.com) (88.198.46.98) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2008 16:37:31 +0000 Received: from [192.168.0.193] (chello062178239020.5.15.vie.surfer.at [62.178.239.20]) by indoqa.com (Postfix) with ESMTP id 18F41255B2F for ; Mon, 4 Aug 2008 18:37:57 +0200 (CEST) Message-ID: <48973063.6010304@apache.org> Date: Mon, 04 Aug 2008 18:37:55 +0200 From: =?ISO-8859-1?Q?Reinhard_P=F6tz?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) 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> <48972F2C.3070005@tuffmail.com> In-Reply-To: <48972F2C.3070005@tuffmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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 ________________________________________________________________________