Thanks Stuart. The exception was catched and the getMessage method
called, so I've
hacked a bit more, but the following patch seems to work great for me.
Index: src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
===================================================================
--- src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
(revision 630863)
+++ src/main/java/org/apache/felix/moduleloader/ModuleImpl.java (working copy)
@@ -147,10 +147,17 @@
}
catch (ClassNotFoundException ex)
{
- m_logger.log(
- Logger.LOG_WARNING,
- ex.getMessage(),
- ex);
+ // Diagnosing the class loader error is very costly, so only
+ // perform this call (indirectly through ex.getMessage())
+ // if necessary.
+ // See R4SearchPolicyCore#findClass
+ if (m_logger.getLogLevel() >= Logger.LOG_WARNING)
+ {
+ m_logger.log(
+ Logger.LOG_WARNING,
+ ex.getMessage(),
+ ex);
+ }
}
return null;
}
Index:
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===================================================================
---
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(revision 630863)
+++
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(working copy)
@@ -178,7 +178,7 @@
return null;
}
- public Class findClass(IModule module, String name)
+ public Class findClass(final IModule module, final String name)
throws ClassNotFoundException
{
try
@@ -191,8 +191,13 @@
}
catch (ClassNotFoundException ex)
{
- String msg = diagnoseClassLoadError(module, name);
- throw new ClassNotFoundException(msg, ex);
+ throw new ClassNotFoundException("", ex)
+ {
+ public String getMessage()
+ {
+ return diagnoseClassLoadError(module, name);
+ }
+ };
}
// We should never reach this point.
On Mon, Feb 25, 2008 at 3:37 PM, Stuart McCulloch
<[EMAIL PROTECTED]> wrote:
> On 25/02/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> >
> > I'm currently working on ServiceMix 4 which uses Felix.\
> >
> > I have some really important performance problems in classloading.
> > When loading JBI applications (they have some very specific
> > classloading architecture
> > that must be implemented to be JBI compliant), 95% of the time is
> > spent in the following method:
> > R4SearchPolicyCore.diagnoseClassLoadError()
> > which is not really acceptable.
> >
> > The problem is that the classloader is built dynamically and does not
> > completely rely on
> > OSGi. For this reason, the classloader of JBI artifacts delegates to
> > the parent classloader,
> > then looks inside its own jar. This means there will be lots of
> > ClassNotFoundException thrown
> > by the parents classloader (ultimately by Felix).
> >
> > Is there any way to maybe speed / disable the diagnoseClassLoadError
> > method call which
> > is purely informative ?
>
>
> we could try a lazy-load approach (ie. only construct the string in the
> getMessage method)
> for example, you might want to see if the following patch helps, based on
> the current trunk:
>
> Index:
> src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
> ===================================================================
> ---
> src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
> (revision 630859)
> +++
> src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
> (working copy)
> @@ -178,7 +178,7 @@
> return null;
> }
>
> - public Class findClass(IModule module, String name)
> + public Class findClass(final IModule module, final String name)
> throws ClassNotFoundException
> {
> try
> @@ -191,8 +191,14 @@
> }
> catch (ClassNotFoundException ex)
> {
> - String msg = diagnoseClassLoadError(module, name);
> - throw new ClassNotFoundException(msg, ex);
> + // lazy construction of exception message
> + throw new ClassNotFoundException("", ex)
> + {
> + public String getMessage()
> + {
> + return diagnoseClassLoadError(module, name);
> + }
> + };
> }
>
> // We should never reach this point.
> @@ -3272,4 +3278,4 @@
>
> return sb.toString();
> }
> -}
> \ No newline at end of file
> +}
>
> although lazy construction might cause problems if people hold onto
> the exception for a long time, but I don't think this is usually the case
>
>
>
> I know the design of the JBI classloaders is not really a good fit in
> > OSGi, so I will investigate
> > a better solution (leveraging more of OSGi classloaders) anyway, but I
> > still wanted to report
> > the problem.
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Cheers, Stuart
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
