Yeah, I'm not really sure either what it does. Might be a fix for the problem I just described. Anyway, we don't want people to have to configure an extra search path for every component jar they introduce, right? This stuff should be automatic.

Eelco


Juergen Donnerstag wrote:

there is a OsgiPath.java. I don't know the details, but it was
provided to use OSGI containers like Oscar.

Juergen

On 8/15/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Well, it wasn't actually a concrete proposal yet. I'd like your opinions
on how to fix this. For instance, are all resources (in the end) coupled
to a component?

Eelco

Martijn Dashorst wrote:

+1 (obviously) :) and a backport to 1.0.

Martijn

Eelco Hillenius wrote:

There is a problem with how we currently load markup. In
ClassLoaderResourceStreamLocator, which is the default thing to use
in Wicke:

  protected IResourceStream locate(final String path)
  {
      // Ensure classloader
      if (classloader == null)
      {
          classloader = getClass().getClassLoader();
      }

      // Log attempt
      log.debug("Attempting to locate resource '" + path + "' using
classloader " + classloader);

      // Try loading path using classloader
      final URL url = classloader.getResource(path);
      if (url != null)
      {
          return new UrlResourceStream(url);
      }
      return null;
  }

The problem with this is that it allways uses the classloader of
ClassLoaderResourceStreamLocator, or in other words, the classloader
that is used to load wicket.jar. This is a problem for components
with markup that are /not/ loaded that way. Martijn just found out
when running in JBoss with Oscar, but it is obviously a problem anyway.

A fix would be to pass the component for which the markup should be
loaded and use it's classloader, like:

  protected IResourceStream locate(final Component callee, final
String path)
  {
      // Ensure classloader
      if (classloader == null)
      {
          classloader = callee.getClass().getClassLoader();
      }
      ...
  }

etc. That would mean passing the calling component everywhere, but I
think it is the only way to get it right.

Your thoughts?

Eelco


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to