tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Date Tue, 05 Jan 2010 19:26:09 GMT
I've uploaded a couple patches to https://issues.apache.org/bugzilla/show_bug.cgi?id=48414

  with a new newSystemInstance method.  I'm not sure why this doesn't  
need to be in a protected block like much of the code that creates  
objects for the app, but the original code wasn't in such a block so  
I'm assuming it's not really needed.

thanks
david jencks

On Jan 5, 2010, at 9:41 AM, David Jencks wrote:

>
> On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote:
>
>> On 04/01/2010 02:46, Tim Whittington wrote:
>>>
>> No need to re-post. A ping would have sufficed.
>>
>>> We've experienced similar issues integrating lots of third party  
>>> libraries (Tomcat being one of them) into our OSGi runtime.
>>
>> Thanks for your input. I can't speak for the other Tomcat  
>> committers but
>> I know very little about OSGI so it is useful to have input from  
>> those
>> more experienced.
>>
>>> Essentially this boils down to OSGi liking extension functionality  
>>> to be provided by instantiation in the providing bundles, and  
>>> publication using OSGi services.
>>> (i.e. pure OSGi services or declarative services etc.). Put  
>>> another way, the concepts of global application classloaders where  
>>> Class.forName works (ala Java EE etc.) break down in OSGi.
>>>
>>> Libraries that use the TCCL in preference to Class.forName help,  
>>> but in cases like the one you describe where there's no direct  
>>> invocation from the bundle that has access to the classes it  
>>> doesn't help. Fragment bundles (and Eclipse specific buddy  
>>> classloaders) also help, and we've had to use them with tools like  
>>> Hibernate, but they're less than ideal.
>>>
>>> I think the conclusion you've reached is correct - either fragment  
>>> bundles (which is a sub-optimal solution) or a pluggable extension  
>>> loading framework could be the solution.
>>
>> OK. The consensus amongst those that know OSGI seems to be some  
>> form for
>> pluggable extension point.
>>
>>> I believe we ran into issues like this when integrating Tomcat 5.5  
>>> into our OSGi runtime - we had to patch up the web app  
>>> ClassLoaders at runtime to make taglib loading work.
>>> In that case we were able to wrap the ClassLoaders with the help  
>>> of some declarative metadata in bundles containing taglibs.
>>>
>>> If you can tell which bundles can contain implementions of  
>>> whatever it is you're trying to instantiate, you can construct a  
>>> ClassLoader spanning those bundles yourself and use that (you'd  
>>> only want to use it for loading these extensions, as it defeats  
>>> the purpose/nature of OSGi to some extent to do this).
>>> It might be that the web application bundles would be all you need  
>>> (and the upcoming OSGi Enterprise Spec will give you a standard  
>>> way of locating these), and that'd probably be a reasonable  
>>> limitation, or you could accomodate applications partitioned to a  
>>> finer degree by some additional marker to include other bundles.
>>>
>>> The other, more OSGi approach would be for listeners to be  
>>> published as OSGi services with target properties, that are then  
>>> just looked up by name by the OSGi version of the extension loader  
>>> (as opposed to instantiating them).
>>> i.e. an instance of the Listener interface is published by a  
>>> bundle as an OSGi service with a property  
>>> tomcatClassName=org.myproject.impl.MyListener. The extension  
>>> loader then looks up the service with a property filter on  
>>> 'tomcatClassName' to find the available extension.
>>> OSGi apps using Tomcat would simply publish these using  
>>> Declarative Services or similar, and this would be a very natural  
>>> approach for an OSGi app.
>>
>> Using Services does seem more in the spirit of OSGI.
>>
>>> With this latter approach you have delightful lifecycle management  
>>> issues because of the dynamic nature of OSGi (extension bundles  
>>> starting after the Tomcat bundles for instance). We solve some of  
>>> these with a combination of declarative only metadata (using the  
>>> Eclipse Extension Registry) to advertise extension existence on  
>>> bundle resolution, and Declarative Services to instantiate and  
>>> publish the actual extension, and some by having the framework  
>>> accept dynamic injection of extensions (Listeners come and go).
>>
>> Glad I don't have to worry about those issues :)
>>
>> The main purpose of the InstanceManager is meet some of the  
>> requirements
>> for annotations support. As such, it is only used for instances  
>> that may
>> have annotations. There is one InstanceManager instance per web  
>> application.
>>
>> One thing that isn't clear to me is whether the requirement is for an
>> extension point for web application related instances (ie things  
>> that in
>> a J2EE environment would be bundled in the WAR) or for container  
>> related
>> instances such as LifecycleListeners. The current patch in bug 48414
>> seems to focussed on Tomcat internals and I don't understand how the
>> line was drawn between what to access via the InstanceManager and  
>> what
>> not to.
>
> Thanks for taking another look at this subject. I've been thinking  
> of the InstanceManager as the extension point for creating objects  
> by reflection rather than as the annotation handler, perhaps because  
> of how the Geronimo InstanceManager happens to be implemented.  So,  
> it seems to me that adding a newSystemInstance method to it for  
> creating objects that are expected to come from the system rather  
> than application classes is reasonable.  I'll try to come up with a  
> patch using this additional method in the next day or two.
>
> thanks again!
> david jencks
>
>
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message