Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E39427664 for ; Mon, 10 Oct 2011 14:15:37 +0000 (UTC) Received: (qmail 83719 invoked by uid 500); 10 Oct 2011 14:15:37 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 83669 invoked by uid 500); 10 Oct 2011 14:15:37 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 83662 invoked by uid 99); 10 Oct 2011 14:15:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 14:15:37 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xhhsld@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-ww0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 14:15:29 +0000 Received: by wwe3 with SMTP id 3so8725610wwe.31 for ; Mon, 10 Oct 2011 07:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6BgJpSjGR/aJLdRBcbEJnLfkjv3Y3AhR8wdmk73SlL8=; b=E1KVw15dyiHnN8VVzBvnHuBkQ26IuHDQN5+FG6oHCq0THg7S7TPapWSOczUQGrjxKQ GG3xbZFSZg2Ndf3xPH2hSNYvp0lEGzv21c2e7+lLcFCvdL/N7dJZEkz6hQ4hBgOfaQ1K mq88joD7eDmY5DZkWcOYLdL9Kk8KS1qvxxPoM= MIME-Version: 1.0 Received: by 10.216.73.147 with SMTP id v19mr4757549wed.20.1318256109217; Mon, 10 Oct 2011 07:15:09 -0700 (PDT) Received: by 10.216.24.196 with HTTP; Mon, 10 Oct 2011 07:15:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Oct 2011 22:15:09 +0800 Message-ID: Subject: Re: GERONIMO-6185: SchemaFactory.newInstance() fails on IBM JDK From: Ivan To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=00504502cf391ce79404aef26b33 X-Virus-Checked: Checked by ClamAV on apache.org --00504502cf391ce79404aef26b33 Content-Type: text/plain; charset=ISO-8859-1 I read those comments on this JIRA, seems we have many solutions, I listed them all, so that we could compare them clearly. Personally, I like the option b and e. a. Use the equonix specific compatible bootdelegation For this, I am not sure whether Equonix provides a filter option, so it only will try those classes from system classloader as the last try. While I guess that, in most scenario, this will not bring any issue. The only problem, I think is that whether we would support other OSGi framework, and actually, we ship Felix. b. Use JVM specific bootdelegation properties I think that this option is fine, and I saw that we have already added some com.ibm.... packages in the bootdelgation configuration. c. Replicate SchemaFactory I am not sure I understand this correctly, if it means to create same name classes with OSGi searching algorithm, so do we need to fork all those classes ? d. Set the context classloader with null. This may require the users to update their codes, guess that it is not a good idea. e. Create a wrapper SchemaFactory implementation Geronimo could provide a wrapper implementation for the SchemaFactory, and we could do any hack in the class, it is also require to configure a global system property and export that class in the org.osgi.framework.system.packages.extra property. 2011/10/8 Jarek Gawor > Hi all, > > Just looking for opinions on GERONIMO-6185 and what we can do about > it. For example, should we have JVM specific bootdelegation > properties? Or should we find some way to replicate SchemaFactory > class with our own that has some fall back mechanism? Other ideas? > > Thanks, > > Jarek > -- Ivan --00504502cf391ce79404aef26b33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I read those comments on this JIRA, seems we have many solutions, I listed = them all, so that we could compare them clearly. Personally, I like the opt= ion b and e.
a. Use the equonix specific compatible bootdelegation
=A0=A0=A0 For this, I am not sure whether Equonix provides a filter option,= so it only will try those classes from system classloader as the last try.= While I guess that, in most scenario, this will not bring any issue. The o= nly problem, I think is that whether we would support other OSGi framework,= and actually, we ship Felix.

b. Use JVM specific bootdelegation properties
=A0=A0=A0 I think that= this option is fine, and I saw that we have already added some com.ibm....= packages in the bootdelgation configuration.

c. Replicate SchemaFa= ctory
=A0=A0=A0 I am not sure I understand this correctly, if it means to create = same name classes with OSGi searching algorithm, so do we need to fork all = those classes ?

d. Set the context classloader with null.
=A0=A0= =A0 This may require the users to update their codes, guess that it is not = a good idea.
=A0 =A0=A0 =A0=A0=A0
e. Create a wrapper SchemaFactory implementation=A0 =A0 Geronimo could provide a wrapper implementation for the SchemaFac= tory, and we could do any hack in the class, it is also require to configur= e a global system property and export that class in the org.osgi.framework.= system.packages.extra property.


2011/10/8 Jarek Gawor = <jgawor@gmail.com>
=
Hi all,

Just looking for opinions on GERONIMO-6185 and what we can do about
it. For example, should we have JVM specific bootdelegation
properties? Or should we find some way to replicate SchemaFactory
class with our own that has some fall back mechanism? Other ideas?

Thanks,

Jarek



--
Ivan
--00504502cf391ce79404aef26b33--