Hi Werner, Joachim, Bernhard,
even if the OSGI suggest to use Class.forName() instead of
ClassLoader.loadClass() there is no need for big changes or to use any
strategy pattern. If you look at source Class.forName() of e.g. Java 5
you will find.
/**
* Returns the <code>Class</code> object associated with the class
* or interface with the given string name. Invoking this method is
* equivalent to:
*
* <blockquote><pre>
* Class.forName(className, true, currentLoader)
* </pre></blockquote>
*
* where <code>currentLoader</code> denotes the defining class
* loader of the current class.
*
* <p> For example, the following code fragment returns the
* runtime <code>Class</code> descriptor for the class named
* <code>java.lang.Thread</code>:
*
* <blockquote><pre>
* Class t = Class.forName("java.lang.Thread")
* </pre></blockquote>
* <p>
* A call to <tt>forName("X")</tt> causes the class named
* <tt>X</tt> to be initialized.
*
* @param className the fully qualified name of the desired class.
* @return the <code>Class</code> object for the class with the
* specified name.
* @exception LinkageError if the linkage fails
* @exception ExceptionInInitializerError if the initialization
* provoked by this method fails
* @exception ClassNotFoundException if the class cannot be located
*/
public static Class<?> forName(String className)
throws ClassNotFoundException {
return forName0(className, true,
ClassLoader.getCallerClassLoader());
}
As you see they say that Class.forName(classname) is equal to calling
Class.forName(classname, true, ClassLoader.getCallerClassLoader()). If
we initialize our class loader property with
ClassLoader.getCallerClassLoader() by default we get exactly the
behaviour suggested by OSGI but still keep the possibility to overwrite
the default class loader.
Regards
Ralf
Bernhard Woditschka schrieb:
> Hi Werner,
>
> I think it should be possible to refrain managing classloaders for the
> common deployment scenarios while still supporting the early Servlet/EJB
> containers you mentioned.
>
> This could be done e.g by refactoring the lookup of a class by it's name
> into a strategy pattern which defaults to a version without using
> classloaders while still allowing to swap in a strategy that supports
> early Servlet/EJB containers.
>
> no worries, Bernhard
>
>
>> Hi Bernhard,
>>
>> any chances to get a longer summary (sic!) of this discussion .. ;-).
>> Yes, I agree with the general statement. But we have to live with a
>> reality, and unfortunately this is a bit different from where we should
>> be. And I am not saying that we should not change things.
>>
>> Having said that, please see inline as well.
>>
>> Werner
>>
>> Bernhard Woditschka wrote:
>>> Hi,
>>>
>>> I'd Ilke to contribute a summary of a discussion with Joachim on
>>> classloaders:
>>>
>>> OSGI based deployment scenarios are emerging (e.g. Eclipse RCP, Spring
>>> DM,...), I think it should be considered to discuss if Castor should
>>> manage classloaders at all.
>> Most likely .. no. Problem is, we already do. As such, the solution
>> would be to find a way to make this work without doing so. As far as I
>> remember, things have been added so that Castor was capable of working
>> together with early Servlet/EJB containers (where class loading was a
>> single big mess initially). As such, it was perfectly understandable
>> that class loader management was added back then.
>>
>>> To manage (one or multiple) classloaders
>>> will most likly create problems within these deployment scenarios as
>>> OSGIs main concern is classloading.
>> Agreed.
>>>
>>> A solution to load classes by name in a way that would work in all
>>> envirements could be to use Class.forName() and avoid using
>>> ClassLoader.loadClass. This should render the management of classloaders
>>> obsolete.
>> I would have a few concerns here, to be honest. Whilost I can see this
>> working with all major deployment forms where Castor is used (e.g.
>> stand-alone, JEE, ....), there's a few issues that should be discussed,
>> namely loading of (generated) descriptor classes.
>>
>>>
>>> No worries, Bernhard
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. +49 7071 3690 52
Mobil: +49 173 9630135
Fax +49 7071 3690 98
Internet: www.syscon.eu
E-Mail: [EMAIL PROTECTED]
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
