Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 46052 invoked from network); 24 Dec 2009 22:27:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Dec 2009 22:27:42 -0000 Received: (qmail 67785 invoked by uid 500); 24 Dec 2009 22:27:40 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 67692 invoked by uid 500); 24 Dec 2009 22:27:40 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 67681 invoked by uid 99); 24 Dec 2009 22:27:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Dec 2009 22:27:40 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.44.55] (HELO smtp110.prem.mail.sp1.yahoo.com) (98.136.44.55) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 24 Dec 2009 22:27:32 +0000 Received: (qmail 81865 invoked from network); 24 Dec 2009 22:27:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=wbRoX7SBZvdMN88bHaoIW675qy3Cee4xDT+8OUxST7YCO82qh1BFra3mA0FXAn7ynoYS4KKs+Zv4ocZOf4HQOWs1bk5Yy4X/+2G1rgmaChp0ZQdbQYcLlGj1Z08dgS60vdlgQC2zoxAOxQDYIfVzuIaOP6xAYM2QEJXU0LdqRdY= ; Received: from 076-076-148-215.pdx.net (david_jencks@76.76.148.215 with plain) by smtp110.prem.mail.sp1.yahoo.com with SMTP; 24 Dec 2009 14:27:10 -0800 PST X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: LgulWsIVM1lr5lU6wWwKQ14dWaVH5449mLmIE.KeT4H0CuXm.pbxGUNZNTPzF8PlueIx.UdLBkUhQFoVfP2SL_IQ_fv8VwnM3bJeBykIdPpS8hIq7A07YtCisdhUCWi5cLZu0YL66ouYdppHbqdL7G8od2PP1rLtuCw_dyAyLMk2scHtlfv7ql_IK_nIIGaX5ChNjqibLViUjSEPay_y1diRB.QalPSCwzrAnJUGukgwEfqGlXh9r6j5YBuA2s.WarlRnoH3kZp0nJTOh0BjbJ8UZnmlSwhd0W8- X-Yahoo-Newman-Property: ymail-3 Message-Id: <6D1F3A01-A23F-459E-9CDD-509FF530E419@yahoo.com> From: David Jencks To: "Tomcat Developers List" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Problem loading classes with Class.forName() in StandardContext.createWrapper() Date: Thu, 24 Dec 2009 14:27:09 -0800 References: X-Mailer: Apple Mail (2.936) X-Virus-Checked: Checked by ClamAV on apache.org I'd like to encourage a little more discussion on this topic. Mark commented on the bugzilla entry to the effect, IIUC, that he thought this was a geronimo problem. I did some more experimentation and I'm pretty sure it has nothing to do with geronimo specifically, but relates to how Class.forName works in osgi. I've concluded from my experiments that Class.forName in osgi will only load classes from the current bundle and not from any bundles wired to the current bundle through package-imports. I think this means that with the current code all listeners have to be in the same jar as the catalina.jar classes or in a fragment bundle attached to it. I haven't tried using a fragment bundle so I don't know if it would actually work. So, my conclusion is that the current code forces: if you want listeners that don't come with tomcat, you have to put them in a fragment bundle or repackage all of tomcat to include them. Is this really the policy tomcat wants to adopt towards osgi environments? I would think that delegating all reflective class loading to a pluggable component would be a more extension-friendly approach. BTW, has anyone tried to find out if the split into catalina.jar and coyote.jar works in osgi? thanks david jencks On Dec 19, 2009, at 5:12 PM, David Jencks wrote: > In the tomcat-7 geronimo/osgi integration we've run into a problem > when tomcat loads listener classes using Class.forName. Using the > InstanceManager to just create the objects works fine for us. > > In geronimo at the moment the InstanceManager has access to both > application and system classes, so it can load just about anything > that is supplied as a listener class. If listeners are supposed to > only be system classes, perhaps adding another method to > InstanceManager to create system objects would be appropriate. > > If changing this is unacceptable for some reason we do have a couple > of other solutions available such as overriding the method or adding > the geronimo listener classes in a fragment bundle, but I think > using the InstanceManager would be a more elegant solution. > > See https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 (patch > included) and https://issues.apache.org/jira/browse/GERONIMO-4992 > > Many thanks! > david jencks > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org > For additional commands, e-mail: dev-help@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org